1.35.0: acceptance checklist coverage, spec-review verdict fixes

• Every review checks the spec's acceptance list. Top-level criteria become A1, A2, … and each task's acceptance lines become T1.1, T1.2, … The reviewer reports each one through pb_report_findings as met with evidence, not met, or not verified; an omitted item is never a pass. A not met item blocks like a P0/P1, while any unverified item ends the review unverified and leaves the phase where it was. Follow-up reviews carry the previous statuses and require every current id. The spec format and configuration do not change, and a manual /pb:review during a build uses the same list.
• Read the plan yourself, in a deliberate order. The guide now walks Goal and Out of scope, acceptance criteria, Decisions, Contracts/Migration/Threats, Tasks and Findings, so a plan that is checkable but aimed at the wrong outcome is caught before T1.
• A spec-review block can no longer read as a pass. Findings written as Markdown list or heading lines (- [P1] …) were stored as a block with zero findings, so the summary said "pass, no findings" while the next line said T1 was blocked. The parser now accepts list, heading and bold forms; a block always posts "changes needed before T1" (with the transcript as fallback when nothing parses), and an unchanged block with no recorded findings is re-reviewed instead of re-posted empty.

1.34.0: repo-grounded specs, Contracts and migration gates, configurable spec reviewer

• A spec is checked against the repo, not only against itself. Ready specs reject a path:line that does not exist (new files need no line), require Contracts for any external surface even with one task, and require Migration and rollback when data or a stored format outlives the change. A section that does not apply is one line, none — why.
• The pre-T1 spec review knows what to check. It now opens the paths the spec names, checks test commands against the repo, and flags missing Contracts, migrations and threat answers instead of only judging the prose. specReviewer: {"model": "provider/id", "thinking": "high"} runs the same pass on another model, such as the implementer's; unset keeps the session model.
• The implementer validates the plan before T1. The build asks it to check the spec's paths, interfaces, test commands and assumptions against the repo, and stop rather than code around a wrong spec.

1.33.0: spec-review live feedback, report-not-revert, per-run review state, queue and resume fixes

1.33.0

• The spec review is visible while it runs. It announces its start, keeps a live widget with the elapsed time and the last tool call (a heartbeat keeps a slow run from reading as a hang), links the full transcript when the verdict lands, and posts a clean pass instead of leaving it silent; notify sends the verdict to your desktop too, for when you're elsewhere. The pre-approval dry-run gets the same live widget, naming the command (n/total) and its elapsed seconds.

• Stray writes are reported, never silently reverted. A review no longer puts back files that changed while it ran — a file touched in that window is as likely to be your own edit as the reviewer's — and lists the paths in its result instead; the next review's delta still starts from the snapshot taken before it. The explorer, trier, spec reviewer, dry-run and cartographer still put back what they changed, but the notification now names the paths and the post-run snapshot, so an edit of yours made meanwhile is recoverable. Untracked files over 20 MB are named in the brief and the result: no snapshot or diff contains them.

• Reviews keep their own state. Resume state is one file per run under .pi/pb/review-runs/, so two reviews no longer overwrite each other and finishing one doesn't delete another's; archive GCs a spec's runs, starting a review clears superseded runs from that session (including crashes that left no resume marker), and the legacy review-run.json migrates once.

• A prose-only pass gives no verdict, not a clean one. When a finished pass reported only in prose and nothing parseable came back, the result says ⚠ NO VERDICT and the phase stays short of reviewed, instead of waving the change through. A recorded diff base that no longer resolves falls back to HEAD with a warning rather than diffing as nothing, and a follow-up no longer says "nothing changed" when only a large untracked file moved.

• A stopped run no longer strands the queue. A fresh run aborted while waiting for a concurrency slot leaves the queue and the next free slot skips it, so the runs behind it start; runs that outlive their session (a switch mid-run) put back and clean up without touching the replaced session.

• Resume follows the spec as it is now. A spec rewrite that renumbers a task no longer leaves the build claiming a task that no longer exists; it resumes at the next todo instead of reporting nothing left to build.

1.31.0: lint final gate, proof-marker resolution, red fingerprint, review evidence

1.31.0

• The final gate runs lint and your own checks. New lint config (auto uses package.json's lint script; other stacks set it explicitly) and extraChecks (project commands, e.g. standards scripts) run after the suite at the final gate, failing the build like any check. Each task is also compiled when done under taskChecks: "end" when a compile command exists, so type drift fails fast at the task. A red lint/project baseline warns before building but never blocks alone.
• Proof markers must name real tests. (tests: …) entries resolve mechanically at write time: a T1-style entry means the task's own Test: run, a path-like entry must exist in the repo, anything else must occur in the test files. Unresolvable names are rejected; stragglers past the gate (hand edits) reach the reviewer as faked-mapping P1 candidates.
• The red proof is bound to the test files. pb_tests_red fingerprints the test files' content; editing, swapping or weakening them afterwards re-requires proof at pb_task_done, like a rewritten Test: command does.
• Reviews judge evidence, not claims. Follow-up reviews get the fix laps' own reports (fixed/skipped plus test results), an acceptance-drift advisory when acceptance lines moved during the build, and the proof-mapping check above.
• Final surfaces show what changed where. The completion summary and the final-failure brief list changed files per task, harness-computed from checkpoints.
• Fresh-run guards everywhere. The spec reviewer and the cartographer snapshot and put back like the explorer, so a stray write can't leak into the build; the dry-run's artifacts are put back too, and the baseline worktree borrows local untracked files (including dot-env) so suites needing them don't fail environmentally.
• Smaller integrity fixes. * Acceptance bullets pass every gate - does; staleness parses UTC like the store writes it; suspiciousCommand catches && and background &; the fresh-run spawner kills the process group and no longer reuses a foreign host script; advisories print as "Advised", not "Decided without you".

v1.30.0 — pi-plan-build

• The spec review keeps stopping. Any finding stops the build before T1, so the review is read before anything builds: P0/P1 to amend (or rebut in Decisions), P2/P3 to decide on. Running /pb:build again judges each earlier finding against the new text first, then reviews the rest — stop, amend, rebuild, until the text passes. Unchanged text re-posts the standings instead of paying for the same review twice, and /pb:build --force builds the spec as it stands, recording the skip (standing findings included) as accepted.
• Only the way into a build is gated. Once T1 has started, spec edits are the code reviewer's to judge — a resume or restart never re-litigates them. A pass answers for the exact text it saw: a spec edited while it was under review is re-reviewed, not built on the stale verdict.
• Quieter reviews by default. The adversarial pass defaults to auto — it runs when the change looks sensitive; "reviewer": {"security": "always"} runs it on every review, off never.
• Restores fail closed. When the guard snapshot can't be taken, nothing is put back — planning drift, /pb:undo and review cleanup say so instead of pretending the tree was clean.
• Parallel sessions stop fighting over the index. Snapshots and restores use a private git index per process, cleaned up on shutdown; a shared index left by an older pb is inert.
• Interrupted reviews carry on honestly. A compacted review resets to its role, the brief, the findings and the files read; findings written between compactions count as progress, so writing is not mistaken for circling; a session compacting with nothing new wraps up with what it has; and a stall from an earlier run never marks a later review of the same spec.
• Writers and readers agree, and failed writes say so. One section-heading matcher, so ## Decisions: takes decisions, answers and build guidance the same way everywhere; a call that makes the spec ready runs the full senior gates, whatever else it wrote; "documentation-only" tasks count as doc-only; Reason: counts as a reason; and text the spec can't take (a timed-out answer, guidance that would break the parse) is reported with how to record it, instead of vanishing.
• Spec names can't reach paths. The one place a name becomes a path validates it (.. and separators refused; legacy names already on disk stay readable), /pb:build and /pb:review refuse path-like arguments, and an archive collision never lands in a folder that already exists.

v1.29.3 — pi-plan-build

• Senior shape at write time. Ready specs are held to mechanically checkable senior rules: Threats-and-abuse when Goal/Tasks look sensitive, measurements or Assumption: form for quantitative claims, Contracts when tasks share a seam (disjoint slices stay advisory), evidence per Findings bullet, a reason per Decisions bullet. Planning checkpoints stay exempt and readers stay lenient, so in-flight specs keep working.
• Review quality. Same-fix findings merge into one (highest priority, every symptom titled) in the prompts and deterministically in the harness; spec-framing nits calibrate to P3 via the reasonable-reader test; the spec-review gate probes empty paths (silent on "nothing to do" now blocks load-bearing gaps pre-build). The verifier and map widgets went activity-only.
• Build reports with hooks. pb_task_done reports changed/caveat/rejected/open (each required, "none" when genuinely nothing); state summaries show the hooks and hide nones. Each task prompt names the files finished tasks touched, harness-computed from checkpoints.
• Surviving real sessions. Long awaits (spec review, dry runs, dialogs) end quietly instead of throwing stale-context errors when the human moved on; human spec edits save visibly as overrides the reviewer sees; /pb:plan keeps the verbatim request in the transcript and the checkpoint; /pb:fix documents its P0–P2 scope everywhere it appears.

v1.29.2 — pi-plan-build

• Planning ends decided, specs transcribe. An unanswered question in planning (or while the spec is being written) stays an open question — silence is never recorded as an Assumption, and planning stays incomplete. Spec writers may only transcribe what was agreed; anything undecided keeps the spec at Status: planning.
• Plain questions, honest gates. pb_ask dialogs use plain words, one trade-off line per option, one plain reason for the recommendation. Planning carries an attack-checklist exit criteria, and the spec-review gate defers to decided points absent new evidence.

v1.29.1 — pi-plan-build

• README catches up with 1.29.0: /pb:fix in the command list, the spec-review gate in the flow, acceptance markers in the spec example, and the per-session state files on disk. No code changes.

v1.29.0 — pi-plan-build

• /pb:fix [ids]: fix review findings in a fresh fenced session — seed, fence and completion report, then /pb:review checks the delta. Unknown ids refused, never guessed; laps repeat to a cap of 3 then escalate as silent or stuck; spec-revision items never start a lap.
• Spec-review gate: fresh eyes attack the ready spec's Decisions before the first task — P0/P1 block T1 until amended or rebutted (exactly once, never re-gated); P2/P3 travel on with the build for the code reviewer.
• Acceptance↔test mapping: every - Acceptance: line on a tested task names its proof (tests: …) or its exemption (non-testable: why) — enforced at write time, and faked or dodged mappings are P1 at review. Tasks without a Test: line stay covered by the gate suite and never block docs or config changes.
• Store races closed: planning sessions, review sessions, pending builds and fixes sessions are per-session files (migrated once from the legacy maps); asked.json is append-only. Parallel sessions stop clobbering each other's state.
• Clearer handoffs: plan args are one-lined and capped with disclosure; near-miss spec names redirect instead of starting silent duplicate plans; planning gets a widget; /pb:build validates names, records trailing guidance, warns on a misplaced --fresh, confirms takeovers, and refuses a readable file under an invalid name; a mid-build review can no longer strand the build as reviewed; all What-now blocks rewritten in plain language with an example each.

v1.28.0 — pi-plan-build

• /pb:approach [idea]: mid-discussion, hear how Pi would approach the implementation — understanding, seams, non-goals, test strategy, alternatives, risks, assumptions, open questions (listed, never asked). Chat only: nothing is written, so /pb:spec still does the settling. With an idea it expands that one; without, it infers the one from the discussion (or compares several with a recommendation)
• Planning that pushes back: the plan, continued-plan and approach prompts share one senior-engineer stance — disagree when the idea is second-best, no objection without evidence (file:line, a constraint, or a failing test; never taste), severity labels (blocker/suggestion/nit), what would change its mind, and teaching the better idea (trade-off, principle, where the codebase already applies it). Small change, small pushback
• Plan-method fixes: baselines are per planning session (parallel planners no longer clobber baseline.json); continuing a spec in a fresh session clears the old one when it has no specs left, snapshots in the new session's tree, and tracks specs that have no progress yet; a missing snapshot warns at review time instead of silently keeping; the large-file warning lists only files changed while planning
• Follow-ups from the fresh /pb:plan review are listed in TODO.md