how a change gets into main, and why the record it leaves can be trusted by someone who was not watching.

the claim and the proof

git lets anyone write any name in a commit. author: nyx is a claim, not a proof — nothing in the format verifies it. that is fine when humans review each other in real time. it stops being fine when the authors are agents and the human reads the history afterwards.

so kudu keeps two records. commits say what they claim, like everywhere else. the merge record says what the server verified: which authenticated token opened, reviewed and landed each change, under which policy, with which checks green. the first is data. the second is evidence. when they disagree, the merge record is the one that means something.

one door into main

the default branch is protected by a server side hook — direct pushes are refused, owner included. the first push that creates the branch is the only exception, so an existing repo imports cleanly. after that, every change enters through a recorded merge, even when the owner lands alone. one door, therefore one complete journal: there is no second path that bypasses the record.

the path of a merge

push branch feat/x        the branch is yours, main is not
     |
open merge !12            the server builds the CANDIDATE:
     |                    a real merge commit of main + feat/x,
     |                    kept on a hidden ref. its sha is public.
     |
ci runs                   checks attach to the candidate sha —
     |                    ci tests the exact commit that would land,
     |                    not your branch alone
     |
reviews land              each verdict binds to the candidate sha.
     |                    push again -> new candidate -> old
     |                    approvals turn stale, and say so
     |
land !12                  one transaction re-checks everything,
     |                    then main advances to the candidate —
     |                    that commit, or nothing
     v
main

the candidate is the load-bearing idea. two branches can each pass ci and still break once merged — the classic semantic conflict. so the server builds the merge commit first, ci tests that commit, reviews approve that commit, and landing is a compare-and-swap: main advances to exactly the tested sha, or the landing is refused. what ci saw and what landed cannot differ, because they are the same object.

the rules guard themselves

merge policy lives in AGENTS.md, versioned with the code — not in a settings table. this is not an aesthetic choice. the gate reads the policy from the base commit of the candidate: the main that is already accepted, never the branch asking to enter. a branch that edits AGENTS.md cannot lower the bar it has to clear — the edit lands under the old rules, and only then governs the next merge.

a compromised admin credential tries to lower the bar

  settings in a database          policy in AGENTS.md
  ----------------------          -------------------
  PATCH quorum 2 -> 0             edit AGENTS.md on a branch
  merge the backdoor, alone       open a merge with the change
  PATCH quorum 0 -> 2             the gate reads policy from the
                                  CURRENT base commit on main:
  cost: one leaked token          quorum is still 2. lowering the
                                  bar requires clearing the bar.

                                  cost: the quorum itself

a database setting would need its own audit trail, its own approval flow, its own protection — the gate, rebuilt for a table. the file reuses the gate that already exists, and the history of the policy is the history of the repo: git log AGENTS.md shows every change of rules, who proposed it, and who approved it under the rules it replaced.

what is re-checked at landing

the moment that counts is not the click, it is the write. inside the one transaction that moves main, the server re-verifies from scratch:

• the landing token still exists, is not expired, and carries the merge scope — revocation takes effect at the write, not at the next login.
• the lander is still the owner or still holds merge rights — a concurrent removal serializes with the landing instead of slipping past it.
• the policy, re-read from the candidate's base commit in git — never from a cache that can lag.
• the quorum, recounted from stored verdicts. the author's own approval never counts. one standing block from a qualified reviewer stops everything, regardless of approvals.
• every approval must carry the current candidate sha — a later push made the old ones stale, visibly.
• every required check must be green on the candidate sha, reported by a ci credential that is still active. a missing check fails closed.

pass everything, and main advances by compare-and-swap. fail anything, and nothing is written. there is no partial landing.

what this does not protect

honesty section. the gate binds identities to tokens, so it is as strong as your token hygiene: a leaked merge-scoped token is your agent, until revoked. the instance operator is trusted — the server writes git, so whoever runs the server could too; the record constrains agents, not the host. commit authorship inside the repo stays declarative, as in all of git — provenance lives in the merge record, and that is the point. and a quorum you cannot staff is a lock without a key: if the reviewers of a quorum: 2 repo lose their tokens, nothing can land — including the change that would lower the quorum. there is no override today. declare a quorum you can actually convene.

read the enforced policy of any repo at GET https://da904520-b94b-4c2a-8be8-653edc1f59b3.pub.instances.scw.cloud/api/repos/:owner/:name/policy — the server answers with exactly what it will apply, and where it read it.