@nklisch/pi-agile-workflow 0.15.3 → 0.16.3

package/docs/VISION.md

@@ -36,16 +36,16 @@ The plugin enforces three execution principles:
 - **Foundation docs roll forward.** `docs/VISION.md`, `docs/SPEC.md`,
   `docs/ARCHITECTURE.md` describe current truth or intended future state.
   When implementation changes what those docs assert, the docs update to
-  match the new truth. No "previously this worked differently." No legacy
-  comments. Git is the audit trail.
+  match the new truth. No retained descriptions of superseded behavior or
+  migration commentary. Git is the audit trail.
 - **Late-bind everything.** No upfront roadmap. No pre-populated stages.
   No pre-tagged release bindings. Items advance stages when work actually
   completes. Releases bind items only when the user cuts a version.
 
-The plugin's `principles` skill loads these alongside the code-design
-principles (Ports & Adapters, Single Source of Truth, Generated Contracts,
-Fail Fast) carried over from `workflow`. The two paradigms — substrate
-execution and code design — operate together during agile-workflow work.
+The plugin's `principles` skill loads these alongside code-design principles
+for clear boundaries, proportional rigor, code economy, useful tests, and
+continuous simplification. The two paradigms—substrate execution and code
+design—operate together during agile-workflow work.
 
 ## Who this is for
 
@@ -82,15 +82,36 @@ agile-workflow is complete enough to operate as the supported workflow engine:
 - Three-channel plugin distribution metadata: Claude Code marketplace, OpenAI
   Codex marketplace, and Pi packages share the same `skills/` source while
   each channel carries native metadata and ergonomics.
+- Operational skills finish their semantic promise: verified implementation
+  continues through a risk-appropriate review lane to `done` by default, while
+  an explicit `stop-at-review` request preserves a deliberate handoff boundary.
+  Review remains a real, independently evidenced state rather than an inline
+  self-approval ceremony.
+- Implementation orchestration derives dependency waves, write ownership,
+  isolation, and worker capability from the work's graph, cohesion, repository
+  shape, uncertainty, and risk. It preserves dependency/cycle integrity,
+  per-wave verification, one commit per item, worker self-containment, and
+  conservative parent roll-up without fixed sizing or prompt recipes.
+- Questions and advisory review are consequence-driven: routine reversible
+  choices use recorded judgment; strategic or difficult-to-reverse choices get
+  an explicit checkpoint; independent review scales through the project's
+  high-level review weight while preserving fresh-context deep review. Reviewer
+  findings remain proposals: the receiving orchestrator weighs actual repository
+  risk, blocks only on material current-cycle concerns, and parks valid
+  lower-priority work rather than forcing every suggestion into implementation.
 - Real releases move through scope → design → implement → review →
-  release-deploy on the substrate; gates produce items, and the release ships
-  only after every bound item is terminal.
+  release-deploy on the substrate; gates focus on bound work while following
+  relevant evidence into adjacent or system-wide code, distinguish release
+  findings from ambient backlog discoveries, and produce durable items. The
+  release ships only after every bound item is terminal. Foundation docs roll
+  forward, release binding stays late, and terminal retention keeps git as the
+  audit trail without leaking obsolete authority.
 
 The pattern proves itself when a fresh session in a substrate-bootstrapped repo
-picks up active work without re-feed, when an autopilot run drains an epic to
-done autonomously across compaction events while respecting the declared
-dependency graph, and when foundation docs five features later still describe
-the present without legacy comments.
+picks up active work without re-feed; when direct production work and autopilot
+both finish decisively while respecting dependency, test-integrity, review, and
+parent-roll-up invariants; and when foundation docs five features later still
+describe the present without legacy comments.
 
 ## Relationship to workflow
 

package/hooks/scripts/prompt-context.py

@@ -78,7 +78,10 @@ CAPSULES = {
             "Ports & Adapters: domain logic stays independent of DB/filesystem/HTTP/time/randomness.",
             "Single Source of Truth: growing variant sets have one registry; types, validation, routing, and display derive from it.",
             "Generated Contracts: boundary types come from schema/router/DB inference or generation instead of hand copies.",
-            "Fail Fast: unknown input is validated at system boundaries and internal preconditions are asserted early.",
+            "Proportional rigor: validate real boundaries; add invariants, edge handling, and determinism only when context warrants them.",
+            "Code economy: prefer the shortest clear solution and fewer concepts over speculative generality.",
+            "Useful tests: protect important interfaces, complex units, and bug regressions—not every line or surface.",
+            "Leave it simpler: when touching an area, eliminate unnecessary code, tests, checks, abstractions, and compatibility paths; ask before reducing guarantees.",
         ],
     },
     "dispatch_economy": {
@@ -92,6 +95,7 @@ CAPSULES = {
             "Agents are for breadth, isolation, fresh judgment, or independent write ownership.",
             "Parallelism follows ownership and dependency layers rather than item count.",
             "Dispatch rationale belongs in run notes or the item body when it affects bundling or wave width.",
+            "Gate scope: release-bound work is the focus, not a hard boundary; follow concrete evidence and route ambient findings to the unbound backlog.",
         ],
     },
     "advisory_review": {
@@ -104,6 +108,8 @@ CAPSULES = {
             "Cross-model peer review applies only when a different model class is available.",
             "Same-model review uses a fresh-context sub-agent rather than inline self-review.",
             "Stories fast-advance on verification; features and epics get deeper review.",
+            "Reviewer findings are proposals; the receiving orchestrator judges actual risk in repository context.",
+            "Only material current-cycle risk blocks completion; park valid lower-priority findings and continue.",
             "Advisory review is non-blocking during design, but final autopilot completion needs a successful review path.",
         ],
     },

package/hooks/scripts/test_prompt_context.py

@@ -372,6 +372,22 @@ class RulesLoaderTest(unittest.TestCase):
         printed = out.getvalue()
         self.assertIn("Agile Workflow Principles", printed)
         self.assertIn("Code-design capsule", printed)
+        self.assertIn("Code economy", printed)
+        self.assertIn("Useful tests", printed)
+        self.assertIn("ask before reducing guarantees", printed)
+
+    def test_gate_prompt_emits_wider_scope_rule(self) -> None:
+        payload = self._payload(
+            session_id="gate-scope", cwd=str(self.root), prompt="gate the release items"
+        )
+        out = io.StringIO()
+        with mock.patch.object(
+            prompt_context.sys, "stdin", io.StringIO(json.dumps(payload))
+        ), mock.patch.object(prompt_context.sys, "stdout", out):
+            rc = prompt_context.main()
+        self.assertEqual(rc, 0)
+        self.assertIn("release-bound work is the focus, not a hard boundary", out.getvalue())
+        self.assertIn("ambient findings", out.getvalue())
 
     def test_main_sessionstart_emits_rules(self) -> None:
         (self.rules_dir / "a.md").write_text("Rule A body", encoding="utf-8")

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nklisch/pi-agile-workflow",
-  "version": "0.15.3",
+  "version": "0.16.3",
   "description": "Markdown-based work-tracking substrate for AI-driven projects.",
   "author": {
     "name": "nklisch"

package/scripts/tests/convert-content-integrity.test.sh

@@ -199,10 +199,10 @@ FAMILY_SKILLS=(
 
 # grounds_on_rules <skill-md> — true iff the file references the
 # `.agents/rules/*.md` path AND a "force-loaded" grounding descriptor appears
-# within +/- GROUND_WINDOW lines of that path. Window-based so it tolerates the
-# line-wrapping some skills use ("...the project's force-loaded" / "agent rules"
-# on the next line) without weakening to a bare path match.
-GROUND_WINDOW=2
+# within +/- GROUND_WINDOW lines of that path. Window-based so it tolerates both
+# line wrapping and compact grounding lists where the path and the re-read
+# instruction are neighboring bullets, without weakening to a bare path match.
+GROUND_WINDOW=5
 grounds_on_rules() {
   local md="$1"
   local total; total="$(wc -l < "$md")"

package/scripts/tests/convert-review-weight.test.sh

@@ -0,0 +1,61 @@
+#!/usr/bin/env bash
+# Structural contract test for review_weight handling in convert/SKILL.md.
+
+set -uo pipefail
+
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+SKILL_MD="${SCRIPT_DIR}/../../skills/convert/SKILL.md"
+PASS=0
+FAIL=0
+
+assert_contains() {
+  local label="$1" block="$2" pattern="$3"
+  if printf '%s' "$block" | grep -Fq -- "$pattern"; then
+    echo "  PASS: $label"
+    ((PASS++))
+  else
+    echo "  FAIL: $label"
+    ((FAIL++))
+  fi
+}
+
+extract_block() {
+  local start="$1" end="$2"
+  awk -v start="$start" -v end="$end" '
+    $0 == start { collecting = 1 }
+    collecting && $0 == end { collecting = 0 }
+    collecting { print }
+  ' "$SKILL_MD"
+}
+
+if [ ! -f "$SKILL_MD" ]; then
+  echo "FAIL: convert/SKILL.md not found at $SKILL_MD" >&2
+  exit 1
+fi
+
+INTERVIEW_BLOCK="$(extract_block '### Phase 3: Conventions interview' '### Phase 4: Create substrate skeleton')"
+WRITE_BLOCK="$(extract_block '### Phase 5: Write CONVENTIONS.md' '### Phase 6: Write the canonical AGENTS.md section')"
+AUDIT_BLOCK="$(extract_block '### Phase S1: Audit substrate health' '### Phase S2: Plan the sync')"
+PRESERVE_BLOCK="$(extract_block '### Phase S4: Preserve user state' '### Phase S5: Commit')"
+
+assert_contains "bootstrap keeps the six-question interview" "$INTERVIEW_BLOCK" \
+  'Six questions, in order'
+assert_contains "review weight adds no interview question" "$INTERVIEW_BLOCK" \
+  'not another interview question'
+assert_contains "fresh bootstrap writes the standard default" "$WRITE_BLOCK" \
+  'review_weight: standard'
+assert_contains "all five values are discoverable" "$WRITE_BLOCK" \
+  'none | light | standard | thorough | maximum'
+assert_contains "missing setting resolves to standard" "$WRITE_BLOCK" \
+  'is absent, review and autopilot resolve it to `standard`'
+assert_contains "convert points to canonical policy" "$WRITE_BLOCK" \
+  'principles/SKILL.md` Part IV and `review/SKILL.md'
+assert_contains "sync accepts absence without migration" "$AUDIT_BLOCK" \
+  'sync neither inserts the default into older projects'
+assert_contains "sync preserves existing values" "$PRESERVE_BLOCK" \
+  'preserve an existing value byte-for-byte'
+assert_contains "sync never resets the setting" "$PRESERVE_BLOCK" \
+  'never added, reset, or rewritten by sync'
+
+printf '\nResults: %d passed, %d failed\n' "$PASS" "$FAIL"
+[ "$FAIL" -eq 0 ]

package/scripts/work-view.sh

@@ -22,7 +22,7 @@
 set -euo pipefail
 
 # Kept in lockstep with plugin.json by scripts/bump-version.sh. Do not hand-edit.
-WORK_VIEW_VERSION="0.15.3"
+WORK_VIEW_VERSION="0.16.3"
 
 # ============================================================================
 # Version prelude (POSIX / bash 3.2 safe — runs BEFORE the Bash-4 guard)

package/skills/autopilot/SKILL.md

@@ -6,9 +6,10 @@ description: >
   make autonomous progress on the substrate. Reads .work/active/, picks ready items by depends_on and
   stage, delegates to design, implement, and review skills, commits transitions, and repeats until the
   scope is done or blocked. Before reporting complete, runs a final peer-review/fresh-context
-  completion pass and fixes or files accepted findings. No /loop or --resume mechanics; the harness
-  goal/continuation feature owns long-running persistence. Epic-scoped by default; --all drains all
-  active work; free-text scope directives are allowed.
+  completion pass, adjudicates reviewer proposals, fixes material blockers, and parks lower-risk
+  valid findings. No /loop or --resume mechanics; the harness goal/continuation feature owns
+  long-running persistence. Epic-scoped by default; --all drains all active work; free-text scope
+  directives are allowed.
 ---
 
 # Autopilot
@@ -45,8 +46,9 @@ running inline, use the same categories in the final summary:
 
 - **Complete** when no in-scope active item remains at `drafting`,
   `implementing`, or `review`.
-- **Blocked** when in-scope items remain but none are ready, an item has a hard
-  blocker, or the review circuit-breaker escalated unresolved work.
+- **Blocked** when in-scope items remain but none are ready or an item has a
+  genuine hard blocker that autonomous diagnosis and correction cannot resolve.
+  Review bounce count alone is never a blocker.
 - **Interrupted** when the user stops the run. Finish the current safe
   transition, commit if anything changed, summarize the remaining queue, and
   let the harness/user decide whether to continue the goal later.
@@ -56,6 +58,9 @@ running inline, use the same categories in the final summary:
 - `autopilot <epic-id>` - drain items under `<epic-id>` transitively via the
   parent chain until the scoped queue is done or blocked.
 - `autopilot --all` - drain all `.work/active/` items.
+- `autopilot --review-weight <level> <scope>` - set review effort to `none`,
+  `light`, `standard`, `thorough`, or `maximum` for item reviews and final
+  completion review. An unambiguous natural-language equivalent is also valid.
 - `autopilot <free-text>` - interpret as a scope directive, such as "finish the
   dangling work", "wrap up phase 14", or "drain everything tagged refactor".
   Log the interpretation in the run summary. When scope is ambiguous, prefer the
@@ -97,16 +102,23 @@ Build the scope from the argument:
 Only active items are candidates. Backlog items must be promoted through
 `scope` before autopilot can touch them.
 
-**Settle the implementation tier once, here at kickoff** — don't let it default
-silently per wave. If the goal/args/user named a tier (or the project fixes one
-in `.work/CONVENTIONS.md`), honor it. Otherwise, when the goal permits
-interaction, ask once for a capability tier — **baseline**, **raised**, or
-**highest** — and lock it for the whole run. The host resolves that capability to
-its available generic subagent model/effort at dispatch time. Under an autonomous
-goal contract that forbids mid-run questions, use the `implement-orchestrator`
-default and **state the tier in the run summary** so a cheap-tier drain is never
-a silent surprise. Pass the settled tier down in the Phase 4 caller note so
-`implement-orchestrator` does not re-ask.
+Resolve worker capability and review weight at kickoff without a routine tier
+question.
+
+For worker capability, honor an explicit goal/argument/caller choice first, then
+a stable `.work/CONVENTIONS.md` choice. Otherwise choose from scope and risk:
+bounded familiar work can use baseline capability; cross-cutting, contract, or
+uncertain work warrants raised capability; architectural, security-critical, or
+high-consequence work warrants the highest available capability. This is
+judgment, not a fixed item-kind mapping. Record the effective choice and reason
+in the run summary and pass it in the Phase 4 caller note.
+
+For `review_weight`, validate the five-level scale and resolve in this order:
+explicit `--review-weight` or unambiguous natural-language selector,
+`.work/CONVENTIONS.md`, then the default `standard`. Explicit caller selection
+always wins. Record the effective weight and source in the run summary and pass
+it in every Phase 4 caller note so production and review skills use one value
+through parent roll-up and final completion review.
 
 ### Phase 2: Build The Queue
 
@@ -147,18 +159,22 @@ this caller note in every delegated prompt:
 
 > Delegated by an active agile-workflow autopilot goal for `<scope>`. Resolve
 > ambiguities with judgment, log rationale in the item body, and do not ask
-> strategic questions unless a hard halt condition applies. Implementation tier
-> for this run: `<settled tier>` — use it for worker dispatch; do not re-ask. For large or risky
-> design decisions, use the cross-model advisory review policy from
-> `principles/SKILL.md` (Part IV) only when a different model class is available;
-> peer failures are non-blocking. For deep or complex design work, use **two
-> different model classes** if available, paired across the advisory→adversarial
-> phases in `principles/references/models.md`. A top-tier reasoning peer may take
-> 10 to 30 minutes for a large review; lack of output after a few minutes does
-> not mean it has hung. For subagent role names, load
-> `principles/references/subagents.md`. When hosted in Pi, use only the
-> supported agile-workflow Pi roles for this adapter; whether a reviewer run is
-> cross-model depends on the model/provider selected at spawn time.
+> strategic questions unless a hard halt condition applies. Worker capability
+> for this run: `<effective capability>` — selected because `<risk/scope reason>`;
+> use it for dispatch and do not re-ask. Review weight for this run:
+> `<none|light|standard|thorough|maximum>` (source: `<explicit|project|default>`);
+> pass it unchanged to review, including ancestor roll-up. Apply the risk-driven
+> advisory policy from `principles/SKILL.md` Part IV in direct and autopilot
+> modes: use independent review only when the risk and review weight warrant it,
+> and label review cross-model only when a different model class is actually
+> selected. Treat reviewer findings as proposals: independently adjudicate them
+> against repository context, fix or activate only material current-cycle
+> blockers, and park valid lower-risk work in the unbound backlog. Peer failures
+> during design are non-blocking. Preserve complementary→adversarial order when
+> both phases run. For reviewer posture and
+> host-native roles, load `principles/references/subagents.md`; for capability
+> mapping, load `principles/references/models.md`. A top-tier reasoning peer may
+> take 10 to 30 minutes; quiet output after a few minutes is not a hang.
 
 Routing:
 
@@ -185,40 +201,54 @@ Routing:
   Requires the `agentic-research` plugin; without it, treat as a plain implementing item ->
   `implement-orchestrator`, mirroring the drafting row's degrade.)
 - `stage: implementing`, non-epic (and NOT `tags: [prose]` or `[research]`) -> `implement-orchestrator <scope>`
-- `stage: review` -> `review <id>` (review self-selects its lane: a **story**
-  fast-advances on `implement`'s verification with no peer pass; a **feature** or
-  **epic** gets a fresh-context deep review — cross-model via peeragent when a
-  different class is reachable (two classes paired across the advisory→adversarial
-  phases for deep/complex scope; see `principles/references/models.md`), else a
-  generic sub-agent prompted as a reviewer from `principles/references/subagents.md`
-  with the strongest appropriate model available (cross-model only if that model
-  is a different class), else a fresh top-class sub-agent)
-
-The delegated skill owns its internal workflow and stage transition. After it
-returns, rebuild the queue from disk rather than relying on cached state.
+- `stage: review` -> `review --review-weight <effective weight> <id>`. Review
+  selects effort and lane from weight + risk + evidence + kind-as-heuristic:
+  low-risk stories can close on green verification, while features, epics, and
+  risk-escalated stories receive the fresh-context coverage permitted by the
+  weight. The review skill also rolls approved children through eligible
+  ancestors, but never skips an ancestor's own review.
+
+Production skills now continue through review to `done` by default (unless an
+explicit stop-at-review override applies), so autopilot may return to a queue
+where the delegated item and eligible ancestors are already terminal. This is
+expected, not a mandatory user handoff. The delegated skill owns its internal
+workflow and transitions; after it returns, rebuild the queue from disk rather
+than relying on cached state.
 
 If a delegated skill reports a hard blocker without a stage transition, append
 a `## Blocker` section to the item body, commit that note, and continue with
 other ready items. The final goal outcome is blocked if unresolved blockers
 remain in scope.
 
-### Phase 5: Review Circuit-Breaker
+### Phase 5: Review Convergence Loop
 
-Track per-item review bounces during the run:
+A review bounce is corrective work, not a human handoff. Track per-item bounces
+only as diagnostic history:
 
 ```text
 bounces[<item-id>] = times this item has gone implementing -> review -> implementing
 ```
 
-If an item bounces back to `implementing` twice:
-
-1. Append `## Stuck at review` with the latest blockers and the two-pass note.
-2. Leave the item at `review`.
-3. Log it as escalated.
-4. Continue draining other ready work.
-
-Escalated items make the final goal outcome blocked unless the user resolves
-them before the run ends.
+After every bounce:
+
+1. Confirm the receiving agent—not the reviewer alone—adjudicated the proposals
+   and left concrete, receiver-confirmed blockers in the item body.
+2. Park valid findings below the material current-cycle bar in the unbound
+   backlog; they do not keep the item bounced or enter this run's queue.
+3. Rebuild the queue so the item naturally re-enters implementation.
+4. Implement the blockers, run the relevant verification, and send the item
+   through review again.
+5. Continue until review approves the item or autonomous work reaches a genuine
+   hard blocker under `principles/SKILL.md` Part III.
+
+There is no fixed bounce limit. If the same material finding survives more than
+one correction pass, treat recurrence as evidence that the attempted fix or
+design model may be wrong: re-read the item and foundation docs, diagnose the
+root cause, revise the item design or implementation notes when needed, and use
+a fresh implementation or review context when that would add independent
+judgment. Recurrence alone never elevates a low-risk finding into a blocker. Do
+not park the active item at `review`, label it stuck, or require human
+intervention solely because a counter reached two (or any other number).
 
 ### Phase 6: Refactor Cadence (`--all` Only)
 
@@ -249,10 +279,11 @@ Do not stop because of elapsed time, context size, or "long run" concerns. The
 harness owns continuation. Your job is to keep applying the queue policy until a
 real stop rule fires.
 
-### Phase 8: Final Peer Review Loop
+### Phase 8: Final Completion Review Loop
 
 This is the last step before reporting `complete`. It runs in addition to any
-design-time cross-model advisory passes from delegated skills.
+design-time advisory passes from delegated skills and is calibrated by the same
+effective `review_weight`; the phase itself is never skipped.
 
 When the scoped queue appears drained:
 
@@ -263,39 +294,49 @@ When the scoped queue appears drained:
    - commits associated with advanced items
    - notable design decisions, implementation deviations, blockers resolved,
      and verification results reported by delegated skills
-2. Run the completion review as the two-phase design-review order from
-   `principles/SKILL.md` Part IV (advisory/completeness, then adversarial). If
-   `peer-review` is available with a different model class, use it; for a deep or
-   complex completion bundle, **use two different model classes** if available,
-   one per phase. Ask for bugs, missed acceptance criteria, unreviewed risks,
-   foundation-doc drift, and substrate-state inconsistencies that would make
-   "complete" premature. A top-tier reasoning peer may take 10 to 30 minutes for a
-   large completion review; do not classify a quiet, still-running process as
-   hung after only a few minutes.
-3. If peeragent would use the same model class, do not use `peer-review`; spawn
-   a generic sub-agent prompted as a reviewer from
-   `principles/references/subagents.md` when available, with the strongest
-   appropriate model. Record it as cross-model only if that spawned model is a
-   different class; otherwise record same-harness fresh-context.
-4. If peer-review is unavailable, use that same generic reviewer-subagent path
-   when available, otherwise the local inline review fallback.
-   If the selected final-review path fails, do not report completion; mark the
-   run blocked on final review and include the failure reason. Do not invent a
-   pass.
-5. For every substantive accepted finding:
-   - Small and clearly safe fix: fix it immediately, run verification, commit,
-     and rebuild the queue.
-   - Needs tracked work: create or update a substrate item at the right stage
-     (`drafting` for design gaps, `implementing` for concrete fixes), commit,
-     and rebuild the queue.
-   - Invalid or lower-value finding: reject it with a one-line rationale in the
-     final review summary.
+2. Calibrate the completion review from the weight without turning it into a
+   rigid dispatch recipe:
+   - `none`: run no independent reviewer; administratively verify the completion
+     bundle has green verification and acceptance evidence for every in-scope
+     item, plus internally consistent terminal substrate state.
+   - `light`: use at most one focused fresh-context pass over the bundle.
+   - `standard`: use balanced risk-based fresh-context review.
+   - `thorough`: increase complementary and adversarial fresh-context coverage.
+   - `maximum`: seek multi-model, multi-pass complementary → adversarial review.
+   Ask for bugs, missed acceptance criteria, unreviewed risks, foundation-doc
+   drift, and substrate-state inconsistencies that would make "complete"
+   premature. Exact reviewer count and pass depth remain model judgment within
+   the weight's ceiling/intent.
+3. When independent review runs, use a different-class peer when reachable;
+   otherwise spawn a generic same-harness fresh-context reviewer from
+   `principles/references/subagents.md` with the strongest appropriate
+   capability. Label it cross-model only if the selected model class differs
+   from the host. A top-tier reviewer may take 10 to 30 minutes; quiet output
+   after a few minutes is not a hang.
+4. If the effective weight requires fresh-context review and no such path is
+   available or the selected path fails, do not report completion; mark the run
+   blocked on final review and include the reason. `none` requires complete
+   administrative evidence instead of a fresh reviewer; missing evidence blocks
+   rather than becoming an invented pass.
+5. The receiving autopilot agent adjudicates every proposed finding against the
+   repository's acceptance criteria, users and deployment shape, likelihood,
+   blast radius, recoverability, safeguards, and delay cost. Reviewer severity
+   is evidence, not the verdict:
+   - Receiver-confirmed material current-cycle blocker: fix it immediately when
+     small and safe, or create/update an active item at the right stage
+     (`drafting` for design gaps, `implementing` for concrete fixes); verify,
+     commit, and rebuild the queue.
+   - Valid but below the blocker bar: park an unbound backlog item with a brief
+     risk rationale, commit it, and continue. It does not reopen the drained
+     scope or prevent completion.
+   - Nit or unsupported/inapplicable claim: note or reject it with a one-line
+     rationale; do not create active work.
 6. If rebuilding the queue finds new or regressed `drafting`, `implementing`, or
-   `review` items in scope, return to Phase 2 and drain them. Completion is not
-   allowed while accepted final-review findings remain active.
-7. Once the final review path succeeds, produces no accepted
-   blocking/substantive findings, and the queue is still empty, report the goal
-   as complete.
+   `review` items in scope, return to Phase 2 and drain them. Parked review
+   follow-ups remain outside autopilot scope until separately promoted.
+7. Once the final review path succeeds, every proposal is adjudicated, no
+   receiver-confirmed blocker remains, and the queue is still empty, report the
+   goal as complete.
 
 Record the final review in the autopilot final summary. Do not paste the full
 peer transcript into item bodies; summarize accepted/rejected points where they
@@ -308,23 +349,29 @@ Narrate briefly as items advance. Final summary:
 - Goal scope and interpretation
 - Items advanced to done
 - Items reviewed and approved
-- Items reviewed and bounced
-- Escalated or blocked item ids
+- Items reviewed and bounced, including recurring findings and how they converged
+- Genuinely blocked item ids and blocker reasons
 - Refactor cadences run (`--all` only)
 - Implement-orchestrator bundle summary, if reported
-- Final peer-review status: cross-model, local fallback, skipped, or failed;
-  include accepted findings fixed/filed and rejected findings summary
+- Effective worker capability and selection rationale
+- Effective review weight and source
+- Final completion-review status: administrative, cross-model, same-harness
+  fresh-context, or failed; summarize blockers fixed/activated, lower-risk
+  findings parked, and proposals rejected
 - Goal outcome: complete, blocked, or interrupted
 
 ## Guardrails
 
 - Never use structured question tool while an autopilot goal is actively driving the
   delegated work. Resolve with judgment and log rationale.
-- Do not report `complete` until Phase 8 has run successfully and all accepted
-  final-review findings have been fixed or filed back into the queue.
+- Do not report `complete` until Phase 8 has run successfully at the effective
+  review weight, every proposal has been adjudicated, and all receiver-confirmed
+  material blockers have been fixed or filed into the active queue. Parked
+  lower-risk findings do not block completion.
 - Commit after every item state change or blocker note.
 - Do not push, force-push, or release; the user controls publication.
-- Do not touch `.work/backlog/` except to report that backlog items are out of
-  scope.
+- Do not drain or promote `.work/backlog/`; it is outside autopilot scope.
+  Review disposition may park valid lower-priority findings there without
+  reopening the run.
 - The substrate is the resume point. No `PROGRESS.md`, no watchdog loops, no
   `--resume`.