green merges itself, and the judge ships unread

The four questions carried over from the contribution-architecture round, answered.

Auto-merge on full green. A pull request whose required checks all pass merges without a maintainer click. This is the architecture's own conclusion rather than a convenience: the gates decide correctness, and if they do, a person in the path adds delay and not a check. What review still decides — fit, naming, provenance labelling, whether both registers are present, whether a result belongs in the program — is judgment about work already merged, raised as an issue or a follow-up like anything else.

Two existing gates make it safe rather than reckless, and neither was added for this. A non-maintainer pull request touching a specification path cannot go green, because path-gate fails it — so full green already means the change is confined to the open layer. And conservativity fails anything adding an axiom, changing specification shape, or altering the axiom output of an existing declaration.

It is GitHub's auto-merge, not a workflow, and that is forced. A bot that merges needs write scope, and CI holds zero secrets, permanently is a rule this ledger does not get to spend on convenience. A merge performed by GitHub against the required-check list grants this repository nothing. .github/apply-branch-protection.sh now enables the setting and reads it back.

Applied in the same sitting and verified by read-back: seven required checks, zero required approvals, code-owner reviews off, enforce-for-admins on, force-pushes and deletion blocked, auto-merge on, and the check count agreeing with the payload. The decision is live rather than recorded — which is the distinction the settings-side rename failure exists to remind this ledger of.

The checker harness ships unread, and the repository says so. The maintainer declined the reading pass, and that is recorded as a decision rather than an omission: three files and three docstrings are the entire meaning of every Python claim this repository will make, and no maintainer has read them. Nothing changes in what is claimed — witness-checked and enumeration-verified already mean what the harness does, and the harness is ci-only in PROVENANCE.md like everything else. The entry stays in the queue because deferring it does not make it go away.

The resource budgets are confirmed as proposed — 200,000 enumeration points per claim, 25 minutes of Lean build per pull request, no separate enumeration wall-time cap. They are calibrated guesses against measured build times rather than derived values, and a pull request needing more is a conversation and not an override.

The permissive default for unlisted paths is confirmed and stays. A path matching neither layer is contributable, so a genuinely new kind of file does not need a maintainer before anyone can work. The cost is that it fails silently in the granting direction, which it just did — RESEARCH_STATE.md was contributor-editable until someone noticed by hand. The answer is a check that every root-level document classifies into exactly one layer, filed under Workspace friction, not a change of default. The enumeration itself is not re-approved: it has changed several times since it was proposed, and approving the version in that report would have approved a list that no longer exists.

A stale literal was found and fixed in the same pass. The branch-protection read-back required exactly eight checks; the payload has carried seven since frozen-integrity was retired, so the script would have reported correct protection as wrong. It now counts what the payload declares. A verifier with a hardcoded expectation of the thing it verifies is a verifier that drifts, and this one drifted in the direction that cries wolf rather than granting a pass — which is the harmless direction, and still wrong.