C Ownership:\sthe\sdeed,\sthe\snamespace\sand\sthe\sletters
D 2026-09-13T16:59:34.189
E 2026-09-13T16:59:34.189 99b48223e87cf9fd2a1ebc5cf63dc6f2b62c3d95
N text/markdown
U zeitgeist
W 3592
# Who owns what on this forge
Three facts about a repository are deliberately kept apart. Most forges
merge them, and merging them is what makes ownership a label the
operator grants rather than something that is true.
**The deed** is an account. A person holds the repository. It is a
stored column, `repo.owner`, not something inferred from who happens to
hold a capability letter today. It is what makes deletion, transfer and
succession expressible at all: you cannot hand over, or inherit, a fact
that is only ever recomputed.
**The namespace** is where the repository appears: a team when a team
holds it, the owner's handle otherwise. A team holds the path, never the
deed. That is the whole reason dissolving a team is safe -- the
repositories survive it and simply appear somewhere else, because they
still have an owner to fall back to. RFC 0018 requires this; the code
enforces it by writing both in one transaction, and a migration repairs
any row that ever disagreed.
**The letters** are fossil capabilities (RFC 0004), unchanged. They say
what somebody may do inside a repository. Granting `a` to a
co-maintainer gives them everything except the things that belong to the
deed. Ownership sits beside the letters rather than replacing them.
## What creation does
Anyone with an account may create a repository. The creator is recorded
as owner and granted admin in the same operation, and if that grant
fails the creation is rolled back -- a repository is never left that
only a site admin can see. A repository created with no author stays
forge-held with an empty owner rather than being attributed to whoever
ran the command. Empty is a real state and means the forge serves this
store on nobody's behalf: eighteen of the mirrors here are in it.
A forge-held repository can be claimed by an account that already
administers it, or handed to another of its admins. Claiming refuses a
repository that already has an owner, because changing hands is a
transfer and a transfer needs the recipient's consent.
## What is NOT true yet, stated plainly
The deed is recorded and populated, and it authorises nothing. It is
read in exactly one place, the claim operation. Deleting and removing a
repository are still gated on the admin letter, so an admin
collaborator can delete a repository they do not own. The rule that the
destructive and alienating verbs belong with the deed rather than with
the role is written down and not implemented.
A site admin's effective set includes the setup letter, and the
capability check answers yes to any letter when setup is present. So a
site admin passes every gate on every repository. The limits described
for the operator -- not changing roles, not deleting, not reaching into
a repository they do not own -- are a design position, not an enforced
one.
Paths are still flat. Every repository URL is now built in one function
rather than in 316 hand-written places, which is the prerequisite for
namespaced paths, but no URL has changed.
There is no audit ledger. Operator power here is narrower than on other
forges and still invisible to the owner, which is the half that would
make it different rather than merely smaller.
## Why it is written down before it is finished
The gap between the model and the code is the useful part of this note.
A model that exists only in someone's head gets re-derived differently
each time, and a model described as finished when it is half-built is
worse than no description. What is above is checkable: the columns
exist, the claim works, the team fallback holds, and the gating does
not.
Z b9079db5499dc878561f6b48bbc24c04