bulletproof

Bulletproof Pre-Ship Review

Overview

Produce an honest, evidence-backed release verdict. Passing checks are supporting evidence; the core job is to determine whether the changed system still preserves its contracts across real user, data, provider, and recovery paths.

Core principle: review the failure semantics before selecting gates. Never turn a review request into unauthorized implementation or release work.

Choose the operating mode

Infer only what the user actually authorized. When unclear, use audit-only.

Mode	Allowed work	Not implied
Audit-only (default)	Inspect code, PR state, history, CI, and docs; fetch remote refs; run safe diagnostic checks; use disposable local resources	Source edits, test creation, commits, pushes, PR comments, issue changes, merge, deploy
Audit-and-fix	Audit plus the specifically authorized code/test changes and local verification	Push, PR mutation, merge, deploy
Release execution	Only the external mutations the user explicitly requested	Any adjacent publication, rollout, or cleanup

Updating a remote branch is a separate mutation. If requested, determine whether the user means local integration or the remote PR branch. Record the remote SHA before the update, use the repository's accepted merge/rebase policy without rewriting history unless explicitly authorized, and verify the final remote SHA and ancestry. Do not treat “review,” “ship,” or “bulletproof” alone as permission to push.

In audit-only mode, continue gathering independent findings after discovering a blocker. Do not “stop and fix,” create regression tests, save reports in the repository, or edit the PR.

Establish the exact review state

1. Read the applicable instruction hierarchy and project release/migration/runbook documents. Do not assume a particular instruction filename, package manager, runtime, framework, base branch, or CI system.
2. Resolve the PR's actual base and head from current remote evidence. Record base SHA, head SHA, merge base, divergence, worktree status, and whether required checks belong to that exact head.
3. Preserve user work. If the checkout is dirty, or a command may write caches, generated files, dependencies, databases, or build output, use an isolated worktree or other disposable environment. Never stash, switch, clean, or delete caches in the user's active dirty checkout.
4. If a base update was authorized, perform it before the substantive review. Report before/after SHAs, integration method, conflicts, push status, and final ancestry. Substantive conflict resolution is code authorship; do it only when authorized.
5. Review the post-integration diff. Distinguish the code reviewed, remote CI, merge state, deployment, and live behavior; none proves the others.