Readiness check: a PR that adds a decision awaiting acceptance is red #101

Source: the principal, 5 October 2026, after the #92 review established that nothing in this repository's tooling or CI makes a PR with proposed decisions red. PRD: docs/decision-registry-prd.md §4 rule 2 ("A PR with proposed decisions is red on the ledger verify check and nothing else") and rule 5 (merge policy is the repository's). Size: M. Depends on: #92 (merged): verify --base and its landing against the base are what this reads. Must land: before the agent protocol in registry PRD §6 is used.

Why

Today a branch that adds proposed decisions is green:

• ledger verify --export (the CI step "Ledger gate" in .github/workflows/product-ci.yml) exits 1 only when verify::Report::is_conformant() is false. That reads findings, graph, the export stage and signers.
• An allocated decision awaiting acceptance is placed in Report::awaiting_acceptance and printed as status ("the gate polices violations, not pendency", verify/disposition.rs).
• --gate completeness does not change that, because VerifyClass::in_gate only filters findings, and awaiting acceptance is not one.
• An unallocated decision is red (L001), but that is a violation, not pendency.

So rule 2 of the PRD is not enforced. Rule 5's default ("a branch may not merge with proposed decisions") rests only on a ruleset this repository does not contain.

What to build

• A readiness check. It fails when the branch, judged against --base, adds a decision version that is awaiting acceptance: one the base does not hold as awaiting. Pendency already on the base does not fail a branch that leaves it alone. The PR chooses and states one of:
  • (a) a verify mode, for example ledger verify --base <ref> --gate ready, adding a gate rather than a class: no format change, and L001–L014 stay closed;
  • (b) a separate command, for example ledger ready --base <ref>, with exit codes 0 ready, 1 awaiting, 2 could not run.
• It names --base explicitly and never relies on origin/HEAD, as the inbox does.
• Output. Each added awaiting decision with its key, set and namespace; --json.
• Not counted: decisions held or forked (already their own findings); versions the branch supersedes before merging; and anything the repository's merge policy exempts. The allowed alternative in rule 5 (merge with proposed decisions to a non-release branch, by accepted decision) is how a repository opts out. The PR says how that opt-out is read, or leaves it to the ruleset and says so.
• A CI step that runs it on pull requests, against github.event.pull_request.base.sha, as the diff-contracts step already does.
• docs/decision-registry-prd.md §4 rule 2, amended to name the check. Until it lands, the rule must say that nothing makes such a PR red. That sentence can go in now, ahead of the code.

Tests

• A branch adding a decision that awaits acceptance fails the check; the same branch with the decision accepted passes.
• A branch that only touches other files, while the base already holds an awaiting decision, passes.
• A partially accepted branch (two decisions proposed, one accepted) fails, naming the other. This is the case ledger: ledger inbox — the R0 decision registry over local clones (#79) #92's accepting_one_of_a_branchs_two_proposed_decisions_pushes_it_and_the_other_stays_listed leaves green today.
• No --base and no origin/HEAD: exit 2 with the reason, never a silent pass.
• The CI step is red on a fixture PR with an awaiting decision.