pi-plans 0.8.0 → 0.8.1

package/README.md

@@ -137,7 +137,7 @@ Planning artifacts live under `./.git/pi-plans/plans/YYYY-MM-DD-<topic>/` by def
 | Visible Refiner overlay | Delegated reviewer subagents surface as a named public overlay in the TUI — one `Reviewer` panel with per-lane tool progress, full streaming transcript with follow-bottom scroll, Tab-pane focus, retention until the user presses `Esc` after completion, and clean cancelled/timed-out vs completed states. `reviewers: 3` renders three equal-height panes inside the same overlay |
 | Tracked execution | The current wave and remaining tasks are injected each turn; task progress is reported exclusively through the `plans_update_task` tool (status + evidence / skipReason, audit-only rollback); the task dashboard shows the tree live (compact aboveEditor widget, Ctrl+Shift+T expanded view with ✓/▸/~/· markers, width-adaptive); a stall watchdog pauses after three settled rounds without task-state change; the status bar shows lifecycle, `x/y` task progress, elapsed time, and token usage in real time |
 | Multi-run workdirs (0.6.0) | Several pi sessions can plan concurrently in one workdir: the run registry derives from `runs/` (no shared pointer to race), each session binds to its run, and same-topic runs get suffixed artifact dirs. `/plans-abandon`, `/plans-execute`, and `/resume-plans` are binding-first and open a descriptive run-picker form when more than one candidate exists; `/plans` lists all runs (newest first, bound run marked) |
-| Execution reviewer | When every task reaches a terminal state, the run status moves to `verifying` and an independent read-only reviewer verifies each `VC-###` check in a detached, overlay-visible round (Esc closes; Ctrl+Shift+R reopens the in-flight round); failed checks roll their covered tasks (children cascade, skipped reopen) back to pending and inject the review report; five committed rounds bound the loop — exhaustion pauses in every mode, and only an explicit `/plans-execute` confirmation grants a fresh budget (ordinary input and restores never refill). Checks with all-skipped coverage pass; checks covering no task never audit |
+| Execution reviewer | When every task reaches a terminal state, the run status moves to `verifying` and an independent read-only reviewer verifies each `VC-###` check AND reports severity-graded `F-###` findings over the whole implemented change in a detached, overlay-visible round (Esc closes; Ctrl+Shift+R reopens the in-flight round). Finding ids are stable across rounds (absence from the newest report = resolved). A failed check or a high-severity finding opens one union fix round: mapped tasks roll back to pending (children cascade, skipped reopen; an unmapped high gets a plan task appended mechanically from the reviewer's proposed title), and the executor is woken exactly once with a findings summary plus the round-report path. The run completes only when every check is affirmatively `pass` and no high finding remains; residual medium/low findings are summarized at completion. Five committed rounds bound the loop — exhaustion pauses in every mode, and only an explicit `/plans-execute` confirmation grants a fresh budget (unresolved findings survive the renewal; ordinary input and restores never refill). Checks with all-skipped coverage pass; checks covering no task never audit |
 | Execution handoff | The accepted plan executes in the current session after explicit approval (never auto-completed); legacy `I-###` plans parse through the compatibility mapping with an upgrade notice; 0.6.0 in-flight runs resume compatibly (delegated-executor orphans re-approve, paused executions rebuild from the task tree) |
 | Execution-phase compaction | Pi core owns scheduling; pi-plans maps the active plan path, current task, task ids, and remaining `VC-###` checks into the VCC sections. Proactive triggers and model-generated summary paths are removed. |
 | Planning-phase compaction | During `run.status=planning` with no active execution, pi-plans maps active run, artifact directory, latest plan path from session entries, and observed current-I markers into the VCC sections. Without an active planning run, compaction returns to Pi core. Additionally, creating a new run (`plans start-run`) proactively requests one pre-plan VCC compaction and resumes planning with a hidden message (default on; `prePlanCompact:false` disables). |

package/agents/execution-reviewer.md

@@ -1,32 +1,41 @@
 ---
 name: pi-plans-execution-reviewer
-description: Read-only execution reviewer for pi-plans; verifies an implemented worktree against the plan's verification checks and returns a tri-state verdict per check.
+description: Read-only execution reviewer for pi-plans; verifies an implemented worktree against the plan's verification checks and reports severity-graded implementation findings that drive the fix loop.
 tools: read, grep, find, ls
 ---
 
-You are the execution reviewer in the pi-plans workflow. Your job is to decide
-whether an already-implemented worktree satisfies the verification checks of an
-accepted plan.
+You are the execution reviewer in the pi-plans workflow. Each review round has
+two jobs: decide whether an already-implemented worktree satisfies the
+verification checks of an accepted plan, and report implementation findings —
+defects you can point at in the repository — that the executor will fix before
+the next round. A round is useful only when both outputs are present.
 
 Rules:
 
 - Perform read-only analysis. Never edit, write, or delete any file, never commit, never push, never spawn subagents.
 - Verify against the actual repository using your read tools before judging. A check passes only on evidence you actually inspected.
 - You are auditing a worktree that is already written. "The file is missing" is a finding to report, not a reason to stay silent.
-- You do not fix anything and you do not propose follow-up work. Your only output is a verdict per check.
+- You do not fix anything. You report verdicts and findings; the fix loop acts on them.
 
 ## Output contract
 
-Output Markdown with exactly one section per check, in the order given by the
-brief:
+Output exactly two sections, in this order.
+
+### 1. Verification verdicts
+
+One section per check, in the order given by the brief. The preferred shape
+puts the id and the verdict on one line (the runner reads this form first):
 
 - `VC-###` — verdict: pass | fail | undeterminable; evidence: <repo path/command or recorded output proving it>; note: <one line>.
 
+A heading-style section is also read: start it with the id (`### VC-###` or a
+bullet that names the check) and keep that check's `verdict:` line inside the
+section. Whichever form you choose, use ONE form for the whole report and
+never let one check's verdict drift into another's section.
+
 Emit **every** check the brief lists, in the brief's order. Never omit a check,
 never merge two checks into one section, never invent a check that is not listed.
 
-## Choosing the verdict
-
 - `pass` — you inspected the evidence and it establishes the check's condition.
 - `fail` — you inspected the evidence and the check's condition is **demonstrably** not met. Use this only when you can point at the specific thing that breaks the condition.
 - `undeterminable` — you could **not** reach a conclusion. Use this whenever the evidence is missing, unreadable, ambiguous, or beyond what your read-only tools can reach.
@@ -37,4 +46,47 @@ yours, and reporting it honestly is strictly better than guessing.
 **Never report `fail` for want of evidence.** "I could not find it" is
 `undeterminable`, not `fail`. Collapsing the two turns a tooling gap into an
 accusation of incorrect work, and the runner acts on that accusation — it rolls
-the covered tasks back and reopens work that may be perfectly fine.
+the covered tasks back and reopens work that may be perfectly fine.
+
+### 2. Implementation findings
+
+Report defects anywhere in the implemented work — not only what the checks
+cover. Scope is the whole change the plan drove, judged against the plan's
+intent. If you find nothing worth reporting, emit exactly `- none.` under the
+heading and stop.
+
+One bullet per finding, exact line grammar (field order is fixed; fields are
+separated by `; `):
+
+- `F-###` — severity: high | medium | low; tasks: Task-N, Task-M | none; proposed-task: <imperative one-line title>; note: <one line>; evidence: <repo path or command output proving it>
+
+Rules for the fields:
+
+- `F-###` — a stable id. The brief lists the previous round's unresolved
+  findings: when a listed problem is still present, **reuse its id verbatim**
+  and do not renumber. A problem is resolved only by no longer reporting it.
+  Brand-new problems take the next unused number after the highest id you have
+  seen (in the brief or in this report).
+- `severity` — `high` blocks completion and wakes the executor for a fix
+  round; `medium` and `low` are recorded and summarized at completion. Grade
+  by consequence: `high` = correctness, data loss, security, broken promised
+  behavior, or a verification check that is demonstrably unmet. `medium` =
+  should be fixed, but the plan's promised behavior still holds without it.
+  `low` = polish, naming, comments, minor drift. Do not inflate; do not
+  downgrade a real `high` to avoid waking the executor.
+- `tasks` — the task id(s) whose work is defective, comma-separated, or
+  `none` when no existing task owns the defect. Only use ids from the brief's
+  task list. A `high` finding with `tasks: none` must carry a
+  `proposed-task:` field (below); the runner appends that task to the plan
+  mechanically, so write it as a self-contained imperative title (e.g.
+  `cap retry backoff at 60s in src/client.ts`). Omit `proposed-task:` for
+  mapped findings and for `medium`/`low`.
+- `note` — one line: what is wrong and what breaks.
+- `evidence` — a repository path (with line anchor when useful) or a short
+  quoted excerpt that an executor with read tools can re-inspect. A source
+  path plus a defect argument is sufficient; you have no execution tools, so
+  never fabricate command output.
+
+Every reported defect must have a bullet. Never fold two defects into one
+bullet; never mention a defect in prose without a bullet — findings outside
+the grammar are invisible to the runner.

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "pi-plans",
-	"version": "0.8.0",
+	"version": "0.8.1",
 	"description": "Human-in-the-loop planning extension for the Pi coding agent: researched, refined Markdown plans before any code changes.",
 	"license": "MIT",
 	"type": "module",
@@ -41,7 +41,7 @@
 		"README.md",
 		"LICENSE",
 		"CONTRIBUTING.md",
-	"AGENTS.md",
+		"AGENTS.md",
 		"index.ts",
 		"agents/",
 		"docs/assets",

package/references/pi-planning-workflow.md

@@ -131,14 +131,15 @@ When the user picks `✓ Accept PLAN_vN and execute it now` in the merged questi
 
 - every agent turn is injected with the current wave's open tasks, the remaining task list, verification-check summary, and execution rules (wave order, `plans_update_task` reporting with status + evidence / skipReason, subprocess polling backoff 5s -> 10s -> 20s -> 40s -> 80s then keep polling at 80s, no stopgaps, dependency and library discipline, minimum tests);
 - task progress flows exclusively through the `plans_update_task` tool: one call per task closing it as `complete` (with evidence) or `skipped` (with skipReason); closed statuses are immutable outside the audit-authorized rollback channel; subtasks close before their parent;
-- the task dashboard tracks the whole tree live: a compact aboveEditor widget (current task ▸, progress bar, ✓/· counts, VC pass count, wave indicator, pause state, audit-outcome line) and the Ctrl+Shift+T expanded tree view (✓/▸/~/·/↺ markers, current-task anchor, VC list with audit state, width-adaptive layout). `↺` marks a task that was completed and then rolled back by a failed audit: it is open again but still shows the evidence from its previous attempt;
+- the task dashboard tracks the whole tree live: a compact aboveEditor widget (current task ▸, progress bar, ✓/· counts, VC pass count, wave indicator, pause state, audit-outcome line, unresolved-findings line visible in both the repairing and verifying phases) and the Ctrl+Shift+T expanded tree view (✓/▸/~/·/↺ markers, current-task anchor, VC list with audit state, width-adaptive layout). `↺` marks a task that was completed and then rolled back by a failed audit: it is open again but still shows the evidence from its previous attempt;
 - a stall watchdog pauses execution after three consecutive settled rounds without any task-status change (genuine user input or `/plans-execute` resumes without losing progress). A round in which the agent ran successful tool calls counts as progress even with no status change, so investigating the codebase is never mistaken for a dead agent;
 - when every task reaches a terminal state, the run status moves to `verifying` and an independent read-only execution reviewer (`agents/execution-reviewer.md`) verifies each check against the worktree in a detached round whose progress renders in a dedicated overlay (Esc closes it; Ctrl+Shift+R reopens the in-flight round). Each check gets one of three verdicts:
   - `pass` — the evidence establishes the check's condition;
   - `fail` — the condition is demonstrably not met; the covered tasks roll back to pending (children cascade, skipped tasks reopen, the `evidence` of the previous attempt is retained while `skipReason` is cleared) and the audit report is injected;
-  - `undeterminable` — the reviewer could not reach a conclusion. This is never a failure and never a completion: nothing rolls back, the loop self-schedules the retry (no agent wake), and each retry counts toward the five-round budget.
+  - `undeterminable` — the reviewer could not reach a conclusion. This is never a failure and never a completion: nothing rolls back, the loop self-schedules the retry (no agent wake), and each retry counts toward the five-round budget. An all-undeterminable round that also reports a high-severity finding still wakes the executor — a finding is actionable independent of verdict evidence;
+  - `F-###` findings — every round also reports severity-graded implementation findings (`high | medium | low`) over the whole implemented change, not just what the checks cover. Ids are stable: the brief lists the previous round's unresolved findings and the reviewer reuses their ids verbatim while the problem persists; absence from the newest round's report is the resolution signal. A `high` finding (or a `fail` verdict) opens ONE union fix round: mapped tasks roll back to pending exactly like a failed check's coverage (children cascade, evidence retained), and a `high` whose `tasks: none` names no owner gets a plan task appended mechanically from the reviewer's `proposed-task` title — the reviewer itself stays read-only. The executor is woken exactly once with a findings summary plus the round-report path. A pure finding-driven rollback deliberately keeps earlier VC passes (the findings channel re-examines the repaired work next round); only a `fail`-driven rollback invalidates the checks covering the reopened tasks. Unresolved findings persist across checkpoint restores, session restores, and fresh budget grants.
 
-  The run completes only when every pending check is affirmatively `pass`. A partial round credits the checks that passed and leaves the rest for the next round. Checks whose covered tasks are all skipped pass as skipped-pass; checks covering no task never enter the audit; checks already satisfied in an earlier round are neither re-briefed nor re-judged;
+  The run completes only when every pending check is affirmatively `pass` AND the newest round reports no high-severity finding; residual `medium`/`low` findings are summarized in the completion message and stay recorded in the round reports. A partial round credits the checks that passed and leaves the rest for the next round. Checks whose covered tasks are all skipped pass as skipped-pass; checks covering no task never enter the audit; checks already satisfied in an earlier round are neither re-briefed nor re-judged;
 - the round budget is five COMMITTED rounds (pass, fail, or undeterminable; discarded fingerprint-mismatch attempts and cancellations burn nothing; two consecutive discards commit as one undeterminable round). Exhaustion pauses the run in EVERY mode — interactive and auto-approve/headless alike — with an in-band `pi-plans-review-paused` message; ordinary user input and session restores never lift the pause or refill the budget. The only fresh-budget surface is `/plans-execute`, whose explicit confirmation grants five more rounds. The watchdog counter is rebased by real tool activity;
 - execution-phase compaction is handled only when Pi core emits manual `/compact`, threshold, or overflow events; summaries are deterministic VCC-style summaries, include session-derived plan/current-task/checklist context, use smart tail keep and `keep:N`, and never call a model;
 - the read-only guard lifts: full write access returns;

package/references/state-and-config.md

@@ -203,11 +203,11 @@ One run directory per planning request: `<git-common-dir>/pi-plans/runs/<YYYYMMD
 
 ## Workflow Checkpoints (`/resume-plans`)
 
-Each run may carry a `checkpoint.json` — the durable, cross-session workflow state that `/resume-plans` restores in the current session. It records: logical `phase` (`planning | reviewing | executing | completed`; the legacy 0.6.0 `implementation-review` phase is read-tolerated and maps to done), `nextAction`, the exact plan identity (path + version + SHA-256), pending/answered questions (stable `questionId`), review rounds with per-lane status and result-file references, execution approval evidence (plan digest, worktree, `git revparse HEAD` at approval, task progress map, audit rounds with the failed and undeterminable check sets, the watchdog budget counter, verified VC set, usage), and ownership metadata. Full review outputs live in separate `reviews/` files; the checkpoint keeps only validated references.
+Each run may carry a `checkpoint.json` — the durable, cross-session workflow state that `/resume-plans` restores in the current session. It records: logical `phase` (`planning | reviewing | executing | completed`; the legacy 0.6.0 `implementation-review` phase is read-tolerated and maps to done), `nextAction`, the exact plan identity (path + version + SHA-256), pending/answered questions (stable `questionId`), review rounds with per-lane status and result-file references, execution approval evidence (plan digest, worktree, `git revparse HEAD` at approval, task progress map, audit rounds with the failed and undeterminable check sets plus the unresolved findings of the newest committed round, the watchdog budget counter, verified VC set, usage), and ownership metadata. Full review outputs live in separate `reviews/` files; the checkpoint keeps only validated references.
 
 Rules:
 
-- Validation is explicit: unknown schema versions, malformed shapes, and unexpected keys are rejected; missing and corrupt checkpoints are distinct, and corrupt files are never silently overwritten. Keys added by a later version (`execution.stallRounds`, `execution.audit.undeterminable`) are optional on read, so checkpoints written before them keep loading.
+- Validation is explicit: unknown schema versions, malformed shapes, and unexpected keys are rejected; missing and corrupt checkpoints are distinct, and corrupt files are never silently overwritten. Keys added by a later version (`execution.stallRounds`, `execution.audit.undeterminable`, `execution.audit.findings`, `execution.planAmended`) are optional on read, so checkpoints written before them keep loading. `execution.planAmended` is set when the review loop mechanically appended finding tasks to the approved plan; the checkpoint's plan identity was re-stamped to the amended digest at that moment while the approval record keeps the original.
 - Writes are atomic with monotonic revisions; writers may require ownership (token + generation) or an expected revision.
 - Model-driven boundaries (plan written, review consolidated, termination condition recorded, implementation round finished, completed) go through the whitelisted `plans record-checkpoint` action, which enforces state-machine preconditions — it cannot set execution approval, mark VCs passed, or forge terminal states.
 - `ask_choice` accepts `questionId`/`purpose`; a pending question is durable before the panel opens and the answer before it returns. When a crash leaves a question both answered (ledger) and pending (checkpoint), the answered entry wins.

package/src/auditor.ts

@@ -12,8 +12,8 @@
 import type { ExtensionContext } from "@earendil-works/pi-coding-agent";
 import * as fs from "node:fs";
 import * as path from "node:path";
-import { auditableChecks, skippedPassCheckIds, type TaskView } from "./tasks.ts";
-import type { CheckItem } from "./plan.ts";
+import { auditableChecks, flattenTaskViews, skippedPassCheckIds, type TaskView } from "./tasks.ts";
+import { normalizeTaskId, type CheckItem } from "./plan.ts";
 import { messaging } from "./messaging.ts";
 
 /** Budget cap: committed rounds per user-granted budget. Discarded (fingerprint-changed) attempts do not count. */
@@ -29,9 +29,36 @@ export interface AuditOutcome {
 	/** Checks whose report carried no readable verdict, or whose evidence was
 	 * inconclusive. Never treated as `failed`: see src/exec.ts. */
 	undeterminable: string[];
+	/** Severity-graded implementation findings from this round (v0.9). Absent
+	 * on legacy shapes means "no findings reported"; the parse boundary always
+	 * sets a concrete array so hand-written construction sites cannot silently
+	 * drop them. */
+	findings?: ReviewFinding[];
 	report: string;
 }
 
+/** Severity vocabulary for implementation findings; mirrors the plan
+ * priority words. `malformed` marks a bullet the grammar parser could not
+ * read — it is recorded and displayed but never drives a rollback. */
+export type FindingSeverity = "high" | "medium" | "low" | "malformed";
+
+export interface ReviewFinding {
+	/** Stable id, normalized uppercase (`F-001`). Reused verbatim across
+	 * rounds while the problem persists; absence from the newest round's
+	 * report is the resolution signal. */
+	id: string;
+	severity: FindingSeverity;
+	/** Task ids owning the defect (normalized), `[]` when unmapped. */
+	taskIds: string[];
+	/** Required for unmapped high findings: the runner appends this as a new
+	 * plan task mechanically, so it must be a self-contained imperative title. */
+	proposedTask?: string;
+	note: string;
+	evidence: string;
+	/** Original bullet, for degraded records and round reports. */
+	raw: string;
+}
+
 /** Parse the verdict lines of an audit report against the checks that are
  * still pending. A pending check with no readable verdict is
  * `undeterminable`, never `failed` — the caller must be able to tell "the
@@ -40,6 +67,58 @@ export interface ParsedAudit {
 	passed: string[];
 	failed: string[];
 	undeterminable: string[];
+	findings: ReviewFinding[];
+}
+
+/** One finding bullet's field-capture helper: lazily up to the next
+ * `; <known-field>:` boundary or the end of the line, so free text in one
+ * field cannot swallow the next. */
+function captureField(line: string, field: string): string | undefined {
+	const m = line.match(new RegExp(`${field}:\\s*(.*?)(?=;\\s*(?:severity|tasks|proposed-task|note|evidence):|$)`, "i"));
+	return m ? m[1].trim().replace(/^[*_`~]+|[*_`~]+$/g, "") : undefined;
+}
+
+/** Parse the findings bullets of a review report. Degrade, never crash, never
+ * roll back: a bullet with an F-### id but unreadable fields is recorded with
+ * severity "malformed" (visible, non-blocking), exactly like the verdict
+ * parser's emphasis tolerance — a strict grammar once silently discarded
+ * verdicts and fail-closed rolled correct work back. */
+export function parseFindings(report: string, knownTaskIds?: Set<string>): ReviewFinding[] {
+	const findings: ReviewFinding[] = [];
+	const seen = new Set<string>();
+	for (const match of report.matchAll(/^\s*[-*]\s+`?(F-\d+)`?\b/gim)) {
+		const id = match[1].toUpperCase();
+		if (seen.has(id)) continue; // conflicting duplicates resolve to the first
+		seen.add(id);
+		// The bullet regex's leading \s* may swallow the preceding newline, so
+		// slice(index) can start mid-whitespace; strip it before taking the line.
+		const line = match.input!.slice(match.index!).replace(/^[\s]+/, "").split(/\n/)[0];
+		const severityRaw = captureField(line, "severity")?.toLowerCase();
+		const tasksRaw = captureField(line, "tasks");
+		const taskIds = (tasksRaw ?? "")
+			.split(/[,,，、]/)
+			.map((token) => normalizeTaskId(token.trim()))
+			.filter((t): t is string => t !== null)
+			.filter((t) => !knownTaskIds || knownTaskIds.has(t));
+		const severity: FindingSeverity =
+			severityRaw === "high" || severityRaw === "medium" || severityRaw === "low" ? severityRaw : "malformed";
+		if (severity === "malformed" || !tasksRaw) {
+			// Unreadable severity, or the grammar's mandatory tasks field missing:
+			// degrade to a recorded non-blocking entry.
+			findings.push({ id, severity: "malformed", taskIds: [], note: captureField(line, "note") ?? line.trim(), evidence: captureField(line, "evidence") ?? "", raw: line.trim() });
+			continue;
+		}
+		findings.push({
+			id,
+			severity,
+			taskIds,
+			proposedTask: captureField(line, "proposed-task") || undefined,
+			note: captureField(line, "note") ?? "",
+			evidence: captureField(line, "evidence") ?? "",
+			raw: line.trim(),
+		});
+	}
+	return findings;
 }
 
 /** Checks this round must judge: auditable (covering at least one task) and
@@ -51,13 +130,27 @@ export function auditablePendingChecks(checklist: CheckItem[], tasks: TaskView[]
 }
 
 /** Build the audit brief for the read-only subagent. Exported for tests. */
-export function buildAuditTask(planPath: string, checklist: CheckItem[], tasks: TaskView[], round: number): string {
+export function buildAuditTask(
+	planPath: string,
+	checklist: CheckItem[],
+	tasks: TaskView[],
+	round: number,
+	priorFindings: ReviewFinding[] = [],
+): string {
 	const checks = auditablePendingChecks(checklist, tasks)
 		.map((check) => `- \`${check.id}\`: ${check.text}`)
 		.join("\n");
-	return `Goal: verify that the implemented worktree satisfies the accepted plan's verification checks.
+	const taskList = flattenTaskViews(tasks)
+		.map((t) => `- \`${t.id}\`: ${t.title} (${t.status})`)
+		.join("\n");
+	const prior = priorFindings.length
+			? `Unresolved findings from earlier rounds (reuse these exact ids while the problem persists; a problem is resolved only by no longer reporting it):
 
-Target plan: ${planPath} (audit round ${round})
+${priorFindings.map((f) => `- \`${f.id}\` — severity: ${f.severity}; tasks: ${f.taskIds.join(", ") || "none"}; note: ${f.note}`).join("\n")}`
+			: "(none — this is the first round with findings in scope)";
+	return `Goal: verify that the implemented worktree satisfies the accepted plan's verification checks, and report implementation findings that drive the fix loop.
+
+Target plan: ${planPath} (review round ${round})
 
 Authority boundary: read-only analysis only. Do not edit, write, delete, commit, push, or spawn subagents.
 
@@ -67,36 +160,75 @@ Checks to verify (only these; checks covering no task and checks already satisfi
 
 ${checks}
 
-Output: Markdown with exactly one section per check, in the order above:
+Plan tasks (the only ids valid in a finding's tasks field):
+
+${taskList}
+
+${prior}
+
+Output: exactly two sections, in this order.
+
+1. Verification verdicts — one section per check, in the order above:
 
 - \`VC-###\` — verdict: pass | fail | undeterminable; evidence: <repo path/command proving it>; note: <one line>.
 
-Emit every listed check exactly once. \`undeterminable\` is a legitimate answer: use it whenever the evidence is missing, unreadable, ambiguous, or beyond your read-only reach. Report \`fail\` only when you can point at the specific thing that breaks the condition — never report \`fail\` for want of evidence.`;
+Emit every listed check exactly once. \`undeterminable\` is a legitimate answer: use it whenever the evidence is missing, unreadable, ambiguous, or beyond your read-only reach. Report \`fail\` only when you can point at the specific thing that breaks the condition — never report \`fail\` for want of evidence.
+
+2. Implementation findings — one bullet per defect anywhere in the implemented change (not only what the checks cover), exact line grammar:
+
+- \`F-###\` — severity: high | medium | low; tasks: Task-N, Task-M | none; proposed-task: <imperative one-line title>; note: <one line>; evidence: <repo path or quoted excerpt>
+
+\`high\` wakes the executor for a fix round; \`medium\`/\`low\` are recorded. When no existing task owns the defect use \`tasks: none\` and (required for high) a self-contained \`proposed-task:\` title. If nothing is worth reporting, emit exactly \`- none.\` under the findings heading.`;
 }
 
 /** Parse the audit subagent's verdict lines. Exported for tests. */
-export function parseAuditReport(report: string, pendingVcIds: string[]): ParsedAudit {
+export function parseAuditReport(report: string, pendingVcIds: string[], knownTaskIds?: Set<string>): ParsedAudit {
 	const passed: string[] = [];
 	const failed: string[] = [];
 	const known = new Set(pendingVcIds.map((id) => id.toUpperCase()));
-	// The auditor writes Markdown, so a verdict may carry emphasis
+	// The reviewer writes Markdown, so a verdict may carry emphasis
 	// (`**pass**`, `*pass*`, `_pass_`, `` `pass` ``). Requiring a bare token
 	// silently discarded such verdicts, and the caller's fail-closed rule then
 	// marked every check failed and rolled the whole run back -- reporting
 	// correct work as failure. Tolerate the markers; \b keeps `passed` and
 	// `passing` from matching.
-	for (const match of report.matchAll(/`?(VC-\d+)`?[^\n]*?verdict:\s*[*_`~]*\s*(pass|fail|undeterminable)\b/gi)) {
-		const id = match[1].toUpperCase();
-		if (!known.has(id)) continue;
-		const verdict = match[2].toLowerCase();
+	// v0.9: finding bullets (F-###) are excluded from verdict scanning — a
+	// finding's note may cite a VC id, and that must never register a verdict.
+	// v0.9.1 (F-011): the contract promises "one section per check" and an
+	// equally literal reading puts the id in a `### VC-###` heading with the
+	// verdict on a line of its own below it. The old same-line-only scan
+	// parsed such reports to ZERO verdicts and burned whole budgets as
+	// undeterminable. The scan is now section-aware: a line that NAMES a
+	// known check at a heading/bullet start opens that check's section, and a
+	// bare `verdict:` token attributes to the nearest open section; an
+	// id-and-verdict pair on one line stays direct.
+	const record = (id: string, verdict: string): void => {
 		if (verdict === "pass") passed.push(id);
 		else if (verdict === "fail") failed.push(id);
+	};
+	const verdictToken = /verdict:\s*[*_`~]*\s*(pass|fail|undeterminable)\b/i;
+	let current: string | null = null;
+	for (const line of report.split(/\n/)) {
+		if (/^\s*[-*]\s+`?F-\d+`?\b/i.test(line)) continue; // finding bullet
+		const sectionId = line.match(/^\s*(?:#{1,6}\s+|[-*]\s+)?`?(VC-\d+)`?\b/i);
+		if (sectionId) {
+			const id = sectionId[1].toUpperCase();
+			if (known.has(id)) current = id;
+		}
+		const direct = line.match(/`?(VC-\d+)`?[^\n]*?verdict:\s*[*_`~]*\s*(pass|fail|undeterminable)\b/i);
+		if (direct) {
+			const id = direct[1].toUpperCase();
+			if (known.has(id)) record(id, direct[2].toLowerCase());
+			continue;
+		}
+		const bare = line.match(verdictToken);
+		if (bare && current) record(current, bare[1].toLowerCase());
 	}
 	// A check with conflicting verdicts resolves to fail: the reader saw both.
 	for (const id of [...new Set(passed)]) if (failed.includes(id)) passed.splice(passed.indexOf(id), 1);
 	const undecided = new Set(known);
 	for (const id of [...passed, ...failed]) undecided.delete(id);
-	return { passed: [...new Set(passed)], failed: [...new Set(failed)], undeterminable: [...undecided] };
+	return { passed: [...new Set(passed)], failed: [...new Set(failed)], undeterminable: [...undecided], findings: parseFindings(report, knownTaskIds) };
 }
 
 /** Pure decision core: classify a parsed report into the audit outcome. It
@@ -109,6 +241,7 @@ export function applyAuditOutcome(round: number, parsed: ParsedAudit, report: st
 		passed: parsed.passed,
 		failed: parsed.failed,
 		undeterminable: parsed.undeterminable,
+		findings: parsed.findings,
 		report,
 	};
 }
@@ -132,6 +265,9 @@ export async function runCompletionAudit(
 		checklist: CheckItem[];
 		tasks: TaskView[];
 		round: number;
+		/** Unresolved findings from earlier committed rounds, injected into
+		 * the brief so the reviewer reuses stable ids (v0.9). */
+		priorFindings?: ReviewFinding[];
 		model?: string;
 		thinkingLevel?: string;
 		timeoutMs?: number;
@@ -141,7 +277,7 @@ export async function runCompletionAudit(
 ): Promise<AuditRoundResult> {
 	const { runPiSubagent } = await import("./subagent.ts");
 	const pending = auditablePendingChecks(opts.checklist, opts.tasks);
-	const task = buildAuditTask(opts.planPath, opts.checklist, opts.tasks, opts.round);
+	const task = buildAuditTask(opts.planPath, opts.checklist, opts.tasks, opts.round, opts.priorFindings ?? []);
 	// agents/auditor.md, not agents/reviewer.md: the reviewer prompt mandates a
 	// plan-review shape (`## Findings` / `## Questions`, F-###) and never says
 	// "verdict", so auditing under it produced reports this parser could not
@@ -165,13 +301,14 @@ export async function runCompletionAudit(
 		if (result.cancelled === true) return { cancelled: true };
 		return null;
 	}
-	const parsed = parseAuditReport(result.output, pending.map((item) => item.id));
+	const parsed = parseAuditReport(result.output, pending.map((item) => item.id), new Set(flattenTaskViews(opts.tasks).map((t) => t.id)));
 	messaging().appendEntry("pi-plans-audit", {
 		planPath: opts.planPath,
 		round: opts.round,
 		passed: parsed.passed,
 		failed: parsed.failed,
 		undeterminable: parsed.undeterminable,
+		highFindings: parsed.findings.filter((f) => f.severity === "high").map((f) => f.id),
 	});
 	return applyAuditOutcome(opts.round, parsed, result.output);
 }
@@ -191,6 +328,9 @@ export function writeReviewRoundReport(
 		passed: string[];
 		failed: string[];
 		undeterminable: string[];
+		/** v0.9 findings from this round; recorded in the round report so the
+		 * file stays the full evidence record. */
+		findings?: ReviewFinding[];
 		discardedReason?: string;
 		fingerprintCaptured?: string;
 		fingerprintFound?: string;
@@ -209,6 +349,8 @@ export function writeReviewRoundReport(
 			`- passed: ${entry.passed.join(", ") || "(none)"}`,
 			`- failed: ${entry.failed.join(", ") || "(none)"}`,
 			`- undeterminable: ${entry.undeterminable.join(", ") || "(none)"}`,
+			`- high findings: ${entry.findings?.filter((f) => f.severity === "high").map((f) => f.id).join(", ") || "(none)"}`,
+			...(entry.findings?.length ? [`- findings: ${entry.findings.map((f) => `${f.id} (${f.severity}${f.proposedTask ? "; proposed: " + f.proposedTask : ""})`).join(" | ")}`] : []),
 			...(entry.discardedReason ? [`- discarded: ${entry.discardedReason}`] : []),
 			`- fingerprint (captured): ${entry.fingerprintCaptured ?? "(n/a)"}`,
 			`- fingerprint (at resolve): ${entry.fingerprintFound ?? "(n/a)"}`,

package/src/dashboard.ts

@@ -46,6 +46,9 @@ export interface DashboardModel {
 	 * never render `audit complete ✓` while this is set — the round-1 mis-cue
 	 * showed the tick for the whole duration of a running audit. */
 	reviewRunning: boolean;
+	/** v0.9: unresolved findings from the newest committed review round
+	 * (stable ids). High entries block completion; the rest are recorded. */
+	findings: Array<{ id: string; severity: string; note: string; taskIds: string[] }>;
 	startedAt: string;
 	usage: { inToks: number; outToks: number };
 }
@@ -172,22 +175,33 @@ export function renderDashboardLines(model: DashboardModel, width: number, theme
 		// instead — the panel must look alive, never finished-then-silent.
 		const owed = model.checklist.some((item) => !item.done);
 		const nextRound = (model.auditRounds ?? 0) + 1;
+		const highCount = model.findings.filter((f) => f.severity === "high").length;
 		const auditLine = model.reviewRunning
 			? `review: round ${nextRound}/${REVIEW_MAX_ROUNDS} running — read-only reviewer verifying`
 			: model.auditFailed.length > 0
 				? `audit: ${model.auditFailed.length} check(s) failed — rollback pending`
-				: model.auditUndeterminable.length > 0
-					? `audit: ${model.auditUndeterminable.length} check(s) undeterminable — verdict unreadable`
-					: owed
-						? `review: round ${nextRound}/${REVIEW_MAX_ROUNDS} — verdict pending`
-						: model.auditRounds !== null
-							? "audit complete ✓"
-							: "all tasks terminal — audit pending";
+				: highCount > 0
+					? `review: round ${nextRound}/${REVIEW_MAX_ROUNDS} — ${highCount} high finding(s) unresolved`
+					: model.auditUndeterminable.length > 0
+						? `audit: ${model.auditUndeterminable.length} check(s) undeterminable — verdict unreadable`
+						: owed
+							? `review: round ${nextRound}/${REVIEW_MAX_ROUNDS} — verdict pending`
+							: model.auditRounds !== null
+								? "audit complete ✓"
+								: "all tasks terminal — audit pending";
 		lines.push(boxRow("│", ` ${clip(auditLine, inner - 2)}`, " ", width));
 	}
 	if (!narrow && model.auditFailed.length > 0) {
 		lines.push(boxRow("│", ` ✗ ${clip(model.auditFailed.join(", "), inner - 3)}`, " ", width));
 	}
+	// v0.9: unresolved findings render in both phases — the fix loop's whole
+	// point is that the executor sees what it owes while repairing.
+	const highFindings = model.findings.filter((f) => f.severity === "high");
+	if (!narrow && highFindings.length > 0) {
+		lines.push(boxRow("│", ` ⚠ ${clip(`high: ${highFindings.map((f) => f.id).join(", ")}`, inner - 3)}`, " ", width));
+	} else if (!narrow && model.findings.length > 0) {
+		lines.push(boxRow("│", ` · ${clip(`findings: ${model.findings.map((f) => f.id).join(", ")}`, inner - 3)}`, " ", width));
+	}
 	if (!narrow && model.auditUndeterminable.length > 0) {
 		lines.push(boxRow("│", ` ? ${clip(model.auditUndeterminable.join(", "), inner - 3)}`, " ", width));
 	}
@@ -216,7 +230,7 @@ export function deriveDashboardModel(
 	topic: string,
 	tasks: TaskView[],
 	checklist: CheckItem[],
-	extra?: { paused?: boolean; pausedReason?: string; auditRounds?: number | null; auditFailed?: string[]; auditUndeterminable?: string[]; reviewRunning?: boolean; startedAt?: string; usage?: { inToks: number; outToks: number } },
+	extra?: { paused?: boolean; pausedReason?: string; auditRounds?: number | null; auditFailed?: string[]; auditUndeterminable?: string[]; reviewRunning?: boolean; findings?: Array<{ id: string; severity: string; note: string; taskIds: string[] }>; startedAt?: string; usage?: { inToks: number; outToks: number } },
 ): DashboardModel {
 	return {
 		topic,
@@ -228,6 +242,7 @@ export function deriveDashboardModel(
 		auditFailed: extra?.auditFailed ?? [],
 		auditUndeterminable: extra?.auditUndeterminable ?? [],
 		reviewRunning: extra?.reviewRunning ?? false,
+		findings: extra?.findings ?? [],
 		startedAt: extra?.startedAt ?? new Date().toISOString(),
 		usage: extra?.usage ?? { inToks: 0, outToks: 0 },
 	};
@@ -239,9 +254,14 @@ export function formatDashboardSummaryLine(model: DashboardModel): string {
 	const vcDone = model.checklist.filter((item) => item.done).length;
 	const cur = currentTask(model.tasks);
 	const wave = cur ? ` · wave ${cur.wave}` : "";
-	const audit = model.auditRounds !== null ? ` · audit r${model.auditRounds}` : "";
+	// v0.9: the review token carries the budget denominator and the unresolved
+	// high count — visible in BOTH phases (executing repair and verifying), so
+	// convergence is legible exactly while the executor is fixing.
+	const highs = model.findings.filter((f) => f.severity === "high").length;
+	const audit = model.auditRounds !== null ? ` · review r${model.auditRounds}/${REVIEW_MAX_ROUNDS}` : "";
+	const highToken = highs > 0 ? ` · ${highs} high` : "";
 	const pause = model.paused ? " · ⏸ paused" : "";
-	return `plans: ${model.topic} ▸ tasks ${p.done}/${p.total} · VC ${vcDone}/${model.checklist.length}${wave}${audit}${pause}`;
+	return `plans: ${model.topic} ▸ tasks ${p.done}/${p.total} · VC ${vcDone}/${model.checklist.length}${wave}${audit}${highToken}${pause}`;
 }
 
 /** Expanded tree view lines (Ctrl+Shift+T overlay). Wide layout from 96 cols. */
@@ -266,23 +286,35 @@ export function renderDashboardTreeLines(model: DashboardModel, width: number, t
 		if (task.status === "pending" && task.evidence) line += `  ↺${clip(task.evidence, 40)}`;
 		lines.push(line);
 		for (const child of task.children) row(child, depth + 1);
-	};	for (const task of model.tasks) row(task, 0);
+	};
+	for (const task of model.tasks) row(task, 0);
 	lines.push("");
 	lines.push("Verification checks:");
 	for (const item of model.checklist) {
 		const mark = model.auditFailed.includes(item.id) ? "✗" : item.done ? "☑" : "☐";
 		lines.push(`  ${mark} ${item.id}${wide ? ` ${clip(item.text.split(";")[1] ?? item.text, Math.min(80, width))}` : ""}`);
 	}
+	if (model.findings.length > 0) {
+		lines.push("");
+		lines.push("Findings (stable ids; absence from the newest round = resolved):");
+		for (const f of model.findings) {
+			const mark = f.severity === "high" ? "⚠" : f.severity === "malformed" ? "?" : "·";
+			lines.push(`  ${mark} ${f.id} (${f.severity}${f.taskIds.length ? `, ${f.taskIds.join(", ")}` : ""}): ${wide ? clip(f.note, 72) : clip(f.note, 40)}`);
+		}
+	}
 	if (model.reviewRunning) {
 		lines.push("");
 		lines.push(`Execution review: round ${(model.auditRounds ?? 0) + 1}/${REVIEW_MAX_ROUNDS} running`);
 	} else if (model.auditRounds !== null) {
 		lines.push("");
+		const highIds = model.findings.filter((f) => f.severity === "high").map((f) => f.id);
 		const verdict = model.auditFailed.length > 0
-			? ` — failed: ${model.auditFailed.join(", ")}`
-			: model.auditUndeterminable.length > 0
-				? ` — undeterminable: ${model.auditUndeterminable.join(", ")}`
-				: " — passed ✓";
+			? ` — failed: ${model.auditFailed.join(", ")}${highIds.length > 0 ? `; high: ${highIds.join(", ")}` : ""}`
+			: highIds.length > 0
+				? ` — high findings unresolved: ${highIds.join(", ")}`
+				: model.auditUndeterminable.length > 0
+					? ` — undeterminable: ${model.auditUndeterminable.join(", ")}`
+					: " — passed ✓";
 		lines.push(`Execution review: round ${model.auditRounds}${verdict}`);
 	}
 	const painted = theme ? lines.map((line) => theme.fg("muted", line)) : lines;