Deduplication ledger

Several Forgejo models appear in more than one endpoint group. User is embedded in issues, pull requests, repositories, comments, releases and notifications; Label and Milestone appear in issues and pulls; Repository appears inside pull requests and notifications.

The rule from PLAN.md §7: the first wave that needs a shared model owns it. Later waves import it and must not redefine, fork, or "temporarily" copy it. A duplicated model is a review-blocking defect — and it is what PMD CPD catches. The duplication gate is now real: scripts/cpd.sh runs PMD 7.26.0's Scala tokenizer over the production sources and, at the 40-token threshold, reports 378 duplication groups as of 2026-08-09. Several of them are exactly the helpers this file lists below. ./verify.sh --with-slow does not fail on that number by itself — it compares it against CPD_BASELINE_GROUPS in verify.sh, which records today's count, and fails on any increase. Bringing the count down is what closes these entries; the baseline is then lowered in the same commit so the ground gained is held.

This file records who owns what. A wave updates it as part of its definition of done, in the same commit that introduces the model.

Ownership

Two rows of that table were written before the waves ran and predicted a reuse that did not happen. Both are corrected rather than deleted, because the prediction is what a later reader would otherwise repeat:

• RepositoryPermissions is not consumed by orgs. Wave 5 needed a team's permission over a repository, which Forgejo models as the string enum none|read|write|admin|owner, not as the three booleans in RepositoryPermissions. It owns organizations.TeamPermission instead. These are different concepts with the same English name; collapsing them would have produced a type that answers admin = true for a team whose permission is owner and lose the ordering that TeamPermission.allows depends on.
• PullRequest is not embedded in a notification. Forgejo's notification subject is a flat {type, title, state, url, …} object with no pull-request body inside it, so wave 6 owns NotificationSubject and links out by URL. The notification group consumes repositories.Repository and nothing from …pulls.

Shared identifiers (Owner, RepoName, RepoSlug) and the shared value types (ApiToken, Page, PageParams, CodebergError, CallContext) are foundation types, owned by the domain module and predating every wave.

Wire DTOs

Each domain model has exactly one wire DTO in modules/codec, in the matching …​.wire package, with its ReadWriter beside it. The ownership rule applies identically: UserDto is written once, by wave 1.

Where the API embeds a reduced form of a model — Forgejo sometimes returns a User with only id, login and avatar_url inside an embedded object — do not introduce a second DTO. Widen the existing DTO's optionality and record the observed shape in docs/HAZARDS.md, so the golden fixture that proves it stays discoverable.

Additions made during implementation

Every wave introduced models the original table did not anticipate. They follow the same ownership rule.

Wave 4 — pulls

Wave 5 — organizations

Organization.visibility is users.UserVisibility, not a forked OrgVisibility. This is a deliberate reuse, not an oversight. Forgejo has one visibility concept — the public|limited|private triple on structs.User — and serves the identical string in the identical key for an organisation, because in Gitea's data model an organisation is a user row. golden/organization/ shows the same three values as golden/user/. Wave 5 therefore consumes users.UserVisibility and users.wire's parsing of it. A second enum would have had the same three cases, the same wire strings and the same parser, and would have been exactly the duplication CPD exists to catch. The cost is a …users import inside …organizations, which the ownership rule explicitly permits: first wave to need a shared model owns it, later waves import it.

Wave 6 — notifications

Username deliberately does not reuse Owner. The two overlap in practice but not in meaning: an Owner may be an organisation, a Username is always a person. Collapsing them would let an organisation name reach an endpoint that only accepts a user.

RepositoryMetaDto (in …issues.wire) is not a reduced Repository and must not be decoded as one — Forgejo's RepositoryMeta carries owner as a bare login string rather than a User object, so RepositoryDto fails on it.

An earlier revision of this file predicted that pull requests and notifications would meet the same object and reuse this DTO. They do not, and the code is the authority: RepositoryMetaDto has exactly one consumer, IssueDto. PullRequestBranchDto and NotificationThreadDto both decode a full repositories.wire.RepositoryDto, because the repository a PR branch points at and the repository a notification belongs to are sent in full — including owner as a User object and, in golden/pull/single-open.json, a populated parent on a fork. Choosing the meta DTO there would fail every payload.

Helpers awaiting promotion

Several lanes independently needed the same helpers and, being unable to edit a package they did not own, wrote local copies. CPD now flags them, and they should be promoted and the copies deleted. Waves 4–6 made this neither better nor worse: they consumed the existing copies rather than adding new ones, except for the paging pair, which grew by three.

CPD's own top findings confirm the list and add one the ledger had missed: issues.FilterToken.from and repositories.PathSegment.from are the same four-line validator with one character different, and PathSegment duplicates itself internally. That is the third row below — the one about path-segment validation — showing up as a measured 41-token clone rather than as a note.

Pending claims

None outstanding. Waves 4, 5 and 6 each needed models from earlier waves — users.User, users.UserVisibility, repositories.Repository, repositories.Commit, repositories.CommitSha, repositories.BranchName, repositories.CommitFileStatus, issues.Label, issues.Milestone, issues.LabelId, issues.MilestoneId, issues.StateFilter, issues.IssueStateChange — and every one was imported rather than redefined. No wave had to add a model in an earlier wave's package, so no out-of-order ownership was recorded.

A wave that discovers it needs a model an earlier wave should have owned adds a row here, implements it in the earlier wave's package, and notes the out-of-order ownership in the commit body.