Bulma Code Review

Sequential phases per PR. Depth adapts to review history. Multi-PR: one subagent per PR (see §0). CI fork: GRAPH.md · LOOP.md. Pending required CI allows pinned code review, then waits with retained analysis and does not post. Red CI still DEFERS. CI that cannot be read is unverified: review continues, and the artifact says so. It does not defer on its own. Draft DEFER is unchanged.

Invariants — never break

1. Subagents. Multi-PR: one fresh subagent per PR; the orchestrator must not review diffs itself. Single-PR: at most one high-risk critic (nodes/critic.md). That spawn is not a second GitHub artifact and does not fan out.
2. Exactly one artifact per PR — one review (inline comments in the same call) or one issue comment. Never both. Never two of either on the same PR. Dismissing my own stale approval and resolving my own fixed threads are state changes, not artifacts.
3. Never APPROVE while any required check is failed, pending, unknown or unverified. out_of_scope is not unknown: the repo's own workflows never build or test PRs into this base (PREFLIGHT.md §CI out of scope).
4. Never invent a finding. A finding with no concrete trigger is dropped in silence — not downgraded, not mentioned.
5. Nits never block, and most stay silent. A nit reaches the PR only inside the collapsed Nits block (§9), only with a concrete path:line, max 5 per run, and never changes the verdict. Always silent regardless: praise, generic refactor advice, speculative perf, pre-existing debt the diff neither changed nor broke. A break this diff causes in an unchanged file (a caller, a test) is not pre-existing; it is a finding with cause_path/cause_line (§5 Phase 10). "Could be cleaner" is silent except the one code-judo nit in Phase 8, which must name a layer, branch, or helper to delete.
6. Voice. GitHub text and chat follow Voice (just above §9). Teammate English on the PR. Chat: bulma-memory. Never caveman. Never a form.
7. Fixed output template (§9). Section order never changes; empty sections vanish. Every verdict body includes the executing reviewer's Model and Reasoning effort rows. Resolve both through bulma-host; use unknown per unavailable field.
8. Phases run in order. Do not start a phase before the previous one is done.
9. Read the room before approving. Follow PREFLIGHT.md before pass selection and again before publishing. Verdicts are APPROVE, REQUEST_CHANGES or DEFER only; never a COMMENT review. An open change request does not skip the diff: review the code and DEFER reason=review_pending when it is clean. A dismissed change request is closed and never blocks. Unresolved threads and unanswered questions still block approval (DEFER review_pending). A thread whose author approved this head does not. QA BLOCKED (could not run) never gates. A status whose text starts with FAIL does not by itself block approval. Never dismiss another reviewer's review. Never post a Deferred comment for an access or tooling error. --force cannot bypass these approval gates.
10. My own open findings never expire silently. A prior finding of mine is dropped only after it is re-verified against the head SHA (§4.2).
11. Patch bind. After Phase 10, every finding goes through scripts/bind-findings.py. A path:line that is not in this pass's patch (or a carry-forward allow-path) cannot be inline. A defect this diff causes elsewhere carries cause_path/cause_line and lands in the script's body bucket. Exit 3 means a blocker or major sits outside the inline set: it still blocks APPROVE. Binding failure is not evidence that a High disappeared. A finding with no axis must be completed before publishing.
12. High-risk critic. When scripts/classify-risk.py prints high, spawn the critic before verdict. The critic walks contracts, integration/state, and security/data-loss on one spawn, without voting findings off. When the script prints low, skip the spawn. High risk with no completed critic posts nothing that run (retry once first), marker critic=failed.
13. Approve the reviewed head only. Pin the full reviewed SHA, re-review any new commits, and verify CI execution on that SHA. Skipped or missing build/test jobs are not green, unless ci-scope.py proves the base is out of scope. Recheck before promotion and retry too.
14. Own Critical/High means no approval. Reconcile body, inline comments, carried findings and critic output with the verdict before POST.
15. Sensitive paths stay off the PR. Workflows, Terraform, auth, billing/seats and secrets are listed by classify-risk.py --human-signoff. That list goes in STATE and the private job report only. It does not DEFER, does not block APPROVE, and is not a review row. Use the full PR file list, including renames, even during light review.
16. Preserve the checkout. Review through pinned source reads. Never edit, stage, switch, stash, reset, clean, rebase or move existing branches in the user's checkout. Fetch commits and run checks in an isolated review checkout. Inspect changed scripts and configuration before executing them. Follow EVIDENCE.md for test and rollout proof.
17. The gate script decides, not memory. Every review POST runs as scripts/gate.py ... && gh api .../reviews (nodes/publish.md). Exit 1 → do not APPROVE (REQUEST_CHANGES for a defect, DEFER for CI). Exit 4 → DEFER reason=review_pending, linking the open change request or thread. Exit 5 → DEFER reason=ci_unknown, CI not verified (tooling); other read errors stay in the private job report. Another bot's approval never turns an APPROVE into a COMMENT. Never post an APPROVE the gate did not pass, and never post a COMMENT review.
18. Dismiss my approval only for a code defect on a new head. A blocked pass, a DEFER, or an open change request does not dismiss it. Dismiss only when this pass posts REQUEST_CHANGES for a blocker or major and that approval's commit is not the live head (PREFLIGHT.md §Retire my stale approval).
19. A flip needs a full look. APPROVE after my own REQUEST_CHANGES, or after an older DEFER or COMMENT of mine for coverage, uncertainty or critic_failed, needs a deep pass on the full PR diff. A delta-only light pass or an empty commit cannot clear it.
20. Converge, do not loop. One finding per defect class, with its other instances. A published finding is carried, never re-posted as new. A rebase that keeps the same change re-verifies the ledger only. From my third REQUEST_CHANGES on a PR, new majors in lines unchanged since my first pass do not block, and the body asks the author to rethink the area (nodes/pass_decision.md §Convergence). Proven blockers always block.
21. Project knowledge stays in the project. Repo rules come from the repo's own files, including REVIEW.md. Domain facts come from the ## Gotchas section of project memory (bulma-memory). This skill carries no product, company or vendor knowledge.

Caps

Large PR (additions + deletions > 2500 or changedFiles > 25): keep the caps, review hotspots first (auth, permissions, data writes, migrations, public API, money, PII), and declare uncovered files in the Coverage block.

Very large PR (more than 50 changed files, more than 5000 changed lines, or a diff the GitHub API refuses with HTTP 406): a deep pass runs in batches of at most 15 files, each with the deep caps, and merges them into one review artifact (nodes/batches.md). Only scripts/batch-plan.py decides this. Smaller PRs never batch.

Where the rest lives

SKILL.md carries the invariants and the caps. Each step is its own file so a pass loads only what it needs.

Correctness, Standards, and Self-verify are never skippable. A large diff is not a reason.

Loaded by another reviewer

A caller that borrows this engine's phases (nodes/review.md, references/EVIDENCE.md, nodes/verdict.md) instead of running the whole skill still owns the approval gates. Hand over, with those files:

• references/PREFLIGHT.md, including §Sensitive changes
• the classify-risk.py --human-signoff JSON for the full PR file list and patch, kept in the private job report and STATE, not in the GitHub review
• scripts/gate.py and scripts/bind-findings.py

The caller runs the gate before its own APPROVE. A nonempty sensitive-path list does not block the caller. A caller that cannot run the gate does not approve; it posts REQUEST_CHANGES for a blocker/major or DEFERs. It does not post a Deferred comment for an access or tooling error.