Review Gate

Review Gate

Publishing is gated on a recorded review of the exact diff being pushed. This is state, not habit: git_push refuses without a record that covers the diff, so the review cannot be skipped by being forgotten.

The order is fixed

1. Run the two-axis review over the branch:

   • Standards — does the code follow this repository's documented standards?
   • Spec — does it do what the ticket or spec asked for?

   Both axes are required. A blank axis is rejected, because a single-axis review is exactly how a finding gets missed.

2. Verify each finding against the code before acting on it, then fix the real ones. This step changes the diff — which is the point of the ordering.

3. Record what each axis found:

   record_review(standards="…", spec="…", findings=2)
   

   A fixed finding or an explicit "no findings" — never a claim of diligence.

4. Push.

Content-addressed by design

The record's key is a sha256 over git diff <merge-base>...HEAD plus the working tree. Consequences:

Action	Record
amend a commit message	still valid
rebase without changing content	still valid
change one byte of the diff	voided — re-review required
edit a file after recording	voided

That is what forces step 2 to happen before step 3 rather than after: a fix cannot ride in on a review that never saw it.

The record is also branch-scoped. Recording on main and then pushing a newly created branch fails, because the record covers a branch that is not the one being published.

The second route is closed

• git push spelled out in a shell command is refused — the shell knows nothing about the review record, so it does not get to be the way around it.
• The file tools refuse any path inside .git, so the record cannot simply be written by hand.

The honest ceiling

Two limits, stated plainly rather than buried:

1. The gate proves a review was recorded, not that it was competent. An agent can record one it did not perform. What the gate guarantees is that publishing requires a deliberate, axis-labelled act instead of merely being remembered.
2. The shell refusal is a pattern match. A script invoked by name that pushes internally is not caught; closing that belongs to the sandbox layer, not a regex.

Because of (1), a post-push review remains as a failsafe: after a push, review the pushed range for what a pre-push look could not see — integration issues, CI-only signals, cross-branch regressions. Fixing a finding changes the diff, which voids the old record, so a further push needs a fresh review and fresh consent.

Where this shows up in the workflow

• The agent's own instructions: run the review before pushing, and never claim a review happened without the recorded artefact.
• publish_findings <pr> turns CI and reviewer comments into structured findings for the fix loop (source, author, file, a capped note) — a report about the code, never instructions to execute.
• Ticket closure cites the commit that closed it; after a squash-merge that reference is repointed at the squash commit so it does not dangle.