@nklisch/pi-agile-workflow 0.16.1 → 0.16.3

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "agile-workflow",
   "description": "Markdown-based work-tracking substrate for AI-driven projects. Items as files in .work/, late-binding releases, gates that produce items, goal-backed autopilot queue runner. See docs/VISION.md.",
-  "version": "0.16.1",
+  "version": "0.16.3",
   "author": {
     "name": "nklisch"
   },

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "agile-workflow",
-  "version": "0.16.1",
+  "version": "0.16.3",
   "description": "Markdown-based work-tracking substrate for AI-driven projects. Items as files in .work/, late-binding releases, gates that produce items, goal-backed autopilot queue runner.",
   "author": {
     "name": "nklisch"

package/docs/ARCHITECTURE.md

@@ -369,7 +369,10 @@ Advisory review follows risk in both direct and autopilot design. Independent
 review uses completeness/advisory before adversarial posture, is labeled
 cross-model only for a known different model class, and is non-blocking at
 design time. Final autopilot completion still requires the successful review
-path selected by the effective review weight.
+path selected by the effective review weight. The receiving orchestrator owns
+finding disposition: it verifies reviewer proposals in repository context,
+keeps only credible material current-cycle risks blocking, and parks valid
+lower-priority work in the unbound backlog.
 
 ### Queue selection algorithm
 
@@ -397,11 +400,12 @@ path selected by the effective review weight.
 7. Re-read substrate state after the production skill returns; it may already
    have completed review and eligible parent roll-up. Commit each item
    transition separately.
-8. If review bounced an item, treat its durable findings as the next
-   implementation input and keep cycling implementation → verification → review.
-   Bounce count is diagnostic history, never a stop condition. Recurring findings
-   trigger deeper root-cause/design diagnosis and fresh context where useful,
-   not a human handoff.
+8. If review bounced an item, treat only receiver-confirmed material blockers as
+   the next implementation input and keep cycling implementation → verification
+   → review. Park valid lower-priority findings unbound; they do not reopen the
+   scoped queue. Bounce count is diagnostic history, never a stop condition.
+   Recurring blockers trigger deeper root-cause/design diagnosis and fresh
+   context where useful, but repetition alone does not elevate severity.
 9. Goto 1 unless a stop condition applies.
 ```
 
@@ -500,6 +504,9 @@ session epoch:
 Code-design capsule:
 - Ports & Adapters: keep domain logic independent of DB/filesystem/HTTP/time/randomness.
 - Single Source of Truth: define growing variant sets once; derive downstream behavior.
+- Proportional rigor: validate real boundaries; add invariants, edge handling, and determinism only when context warrants them.
+- Code economy: prefer the shortest clear solution; test useful interfaces, complex units, and bug regressions.
+- Leave it simpler: eliminate unnecessary code, tests, checks, abstractions, and compatibility paths; ask before reducing guarantees.
 ...
 ```
 
@@ -548,14 +555,19 @@ Override via `gates_for_release` in `.work/CONVENTIONS.md`.
 
 ### Gate-as-item-producer pattern
 
-Each gate scans the bundle of items at `release_binding: <current-version>`
-and produces new items rather than emitting a pass/fail report:
+Each gate focuses on the bundle of items at
+`release_binding: <current-version>` and produces new items rather than
+emitting a pass/fail report. The bundle is a center of gravity, not a hard scan
+boundary: gates may follow concrete evidence into adjacent dependencies, shared
+infrastructure, or system-wide mechanisms. Findings caused by, exposed by, or
+materially relevant to the release bind to it; merely ambient discoveries go
+to the unbound backlog so the gate does not silently expand release scope.
 
 | Gate | What it scans | What it produces |
 |---|---|---|
 | `gate-security` | Bound items' code changes against security checklist | Items with `gate_origin: security`, tagged `[security]`, `release_binding` set |
-| `gate-tests` | Coverage of bound items' acceptance criteria | Items with `gate_origin: tests`, tagged `[testing]` for gaps |
-| `gate-cruft` | Dead code introduced or revealed by the bundle | Items with `gate_origin: cruft`, tagged `[cleanup]` |
+| `gate-tests` | Useful coverage at stable interfaces, complex units, and bug regressions; low-value tests exposed by the bundle | Items with `gate_origin: tests`, tagged `[testing]` for valuable gaps or removals |
+| `gate-cruft` | Local or system-wide code, tests, checks, compatibility paths, and abstractions that may no longer earn their cost | Items with `gate_origin: cruft`, tagged `[cleanup]`; guarantee-reducing removals require user confirmation |
 | `gate-docs` | Foundation-doc alignment with the bundle's behavior changes | Items with `gate_origin: docs`, tagged `[documentation]` — enforces rolling-foundation |
 | `gate-patterns` | Reusable patterns that emerged in the bundle | Detailed pattern-skill files in `.agents/skills/patterns/` (single source of truth) with optional Claude mirror, the generated hook-loaded `.agents/rules/patterns.md` digest (slug+one-liner index pointing back at the skill, with banner + source hash), plus a tracking item with `gate_origin: patterns` |
 
@@ -741,7 +753,7 @@ configured in `CONVENTIONS.md` (default: security → tests → cruft → docs
 
 | Skill | Role | Notes |
 |---|---|---|
-| `principles` | Loads code-design + substrate-execution principles | Code-design (Ports & Adapters, SSOT, Generated Contracts, Fail Fast) carried from workflow; substrate-execution (item-IS-the-work, rolling-foundation, late-binding) added |
+| `principles` | Loads code-design + substrate-execution principles | Code-design includes clear boundaries, proportional rigor, code economy, useful tests, and continuous simplification; substrate-execution includes item-IS-the-work, rolling-foundation, and late-binding |
 | `research` | Investigate libraries/APIs | Carried; produces research docs in `docs/research/` (separate from `.work/`) |
 | `refactor-conventions-creator` | Create project-specific refactor conventions skill | Carried |
 

package/docs/PRINCIPLES.md

@@ -2,8 +2,8 @@
 
 The plugin's `principles` skill loads two distinct paradigms:
 
-- **Code-design principles** — Ports & Adapters, Single Source of Truth,
-  Generated Contracts, Fail Fast. Carried from the `workflow` plugin.
+- **Code-design principles** — clear boundaries and sources of truth,
+  proportional rigor, code economy, useful tests, and continuous simplification.
   These tell the agent how to write good code at design time and
   implementation time.
 - **Substrate-execution principles** — Item-IS-the-Work, Rolling-Foundation,
@@ -18,7 +18,7 @@ shapes how work moves through the system.
 
 # Part I — Code-Design Principles
 
-These four principles govern both architectural decisions and how code is
+These principles govern both architectural decisions and how code is
 written. Each section has guidance for design time and implementation time.
 
 ## 1. Ports & Adapters
@@ -213,21 +213,20 @@ If a generated type needs extending, use
 `type MyType = GeneratedType & { extra: string }` — extend the source of
 truth, don't replace it.
 
-## 4. Fail Fast (implementation only)
+## 4. Fail Fast—Where It Matters
 
-Catch bad data at the door, not three calls deep where the stack trace is
-useless. Validate inputs at the entry point of every function or system
-boundary.
+Catch bad data at real trust boundaries, not three calls deep. Validate
+untrusted input and required external contracts before domain logic runs. Add
+internal checks only where a violated precondition is plausible and
+consequential for this project.
 
 - At system boundaries (HTTP handlers, CLI args, external API responses,
-  config files): parse with Zod or equivalent before any logic runs
-- At internal function boundaries: assert preconditions at the top of the
-  function — guard clauses, not nested ifs
-- Prefer `throw`/`return early` over propagating bad state deep into call
-  chains
-- Errors should be loud and specific at the point of violation —
-  "expected positive number, got -3" beats a cryptic null reference five
-  layers down
+  config files): parse before logic runs
+- At internal boundaries: add guards when they protect a real invariant, not
+  mechanically at every function
+- Prefer early, specific failure when failure is part of the required contract
+- Do not manufacture exhaustive edge handling, invariants, retries, or firm
+  determinism that the project's scope and consequences do not need
 
 **Good:**
 ```typescript
@@ -250,6 +249,73 @@ function processOrder(input: any) {
 }
 ```
 
+## 5. Code Economy
+
+Short, direct code is a virtue when it stays clear. Prefer fewer concepts,
+layers, branches, options, and lines over speculative generality. Terse does not
+mean cryptic: simplify the model first, then its expression. Every abstraction
+or extension point must earn its maintenance cost in current scope.
+
+### At design time
+
+- Start with the most direct solution that satisfies the actual brief
+- Reject hypothetical flexibility without a current second use or committed need
+- Compare approaches by concepts removed as well as capabilities added
+
+### At implementation time
+
+- Delete obsolete paths and incidental machinery exposed by the change
+- Inline or consolidate before extracting another abstraction
+- Match rigor to the project's context rather than treating every codebase as
+  critical infrastructure
+
+## 6. Tests Earn Their Keep
+
+Tests are maintained code. Prioritize stable public interfaces, important seams,
+high-consequence behavior, and regressions learned from real bugs. Unit tests
+belong around genuinely complex isolated logic, not every wrapper, branch, or
+line. Coverage numbers are evidence, not goals.
+
+### At design time
+
+- Name the interface, risk, or regression each proposed test protects
+- Prefer one useful interface test over several implementation-bound unit tests
+- Do not require one automated test per unit, edge, or acceptance statement
+
+### At implementation time
+
+- Add regression tests when bugs reveal meaningful risk
+- Remove duplicate, tautological, brittle, obsolete, or low-value tests
+- Keep simple code simple when an isolated test adds no useful confidence
+
+## 7. Leave It Simpler
+
+Exploration, design, and implementation include an elimination pass. Look for
+code, tests, checks, abstractions, configuration, and compatibility paths the
+feature can make unnecessary. Fold safe cohesive cleanup into the task or create
+explicit cleanup/refactor stories; park broader opportunities.
+
+Question whole systems, not only local fragments. A validation layer, invariant
+system, test suite, compatibility mechanism, or defensive subsystem may no
+longer justify its cost. Removing behavior, guarantees, validation, determinism,
+compatibility, or safety is a product decision: explain the trade-off and ask
+the user rather than silently weakening it.
+
+### Review proportionality
+
+Reviewer output is evidence, not authority. The receiving agent verifies claims
+and judges their current-cycle risk against the repository's acceptance criteria,
+supported users and deployment shape, likelihood, blast radius, recoverability,
+safeguards, and delay cost. Credible material risks to required correctness,
+security, data, public contracts, acceptance, release safety, or trustworthy
+verification block. Valid lower-priority concerns are parked unbound; nits stay
+in review notes; unsupported advice is rejected with a brief rationale.
+
+A successful independent review path requires adjudicating every proposal, not
+implementing every suggestion. A rare severe case may still block, while a real
+corner case with negligible consequence need not. Reviewer labels, model
+strength, and repeated mention do not replace the receiving agent's judgment.
+
 ---
 
 # Part II — Substrate-Execution Principles
@@ -259,7 +325,7 @@ shape stage transitions, item bodies, foundation-doc evolution, and
 release binding. The agent applies these whenever operating on `.work/`
 or `docs/`.
 
-## 5. Item-IS-the-Work
+## 8. Item-IS-the-Work
 
 The unit of work is its file. The brief, the design, the implementation
 notes, and the review findings all accumulate in the item's body as
@@ -314,7 +380,7 @@ stages advance. Reading the file IS reading the state of the work.
 - [ ] Item body at completion is a complete record
 - [ ] Code does not reference item IDs; only logical concepts
 
-## 6. Rolling-Foundation
+## 9. Rolling-Foundation
 
 Foundation docs (`docs/VISION.md`, `docs/SPEC.md`, `docs/ARCHITECTURE.md`,
 and any others) describe the project's vision (future-looking) and current
@@ -398,7 +464,7 @@ which timing style was used.
 - [ ] `git log docs/<file>.md` shows the audit trail; the doc shows the
       present
 
-## 7. Late-Binding
+## 10. Late-Binding
 
 Items advance stages when work actually completes. Releases bind items
 only when the user cuts a version. Foundation docs are not pre-decided

package/docs/SPEC.md

@@ -95,7 +95,9 @@ item kind as a starting heuristic. Low-risk stories can close from recorded
 green verification, while risky stories, features, and epics receive the
 fresh-context coverage allowed by the effective weight. Child completion may
 make a parent eligible for its own review, but never approves the parent by
-itself.
+itself. Fresh-reviewer findings are proposals: the receiving agent verifies and
+classifies them against repository context. Only credible material current-cycle
+risk blocks advancement; valid lower-priority findings are parked unbound.
 
 ### Questions and advisory review
 
@@ -125,7 +127,13 @@ convention, then `standard`:
   available for the highest-risk scopes.
 
 These levels state review intent and ceilings, not fixed reviewer counts or pass
-recipes.
+recipes. A successful review path requires every proposed finding to be
+adjudicated, not implemented. The receiving orchestrator weighs acceptance
+criteria, supported users and deployment shape, likelihood, blast radius,
+recoverability, safeguards, and delay cost. It fixes or activates material
+current-cycle blockers, parks valid lower-priority concerns in the unbound
+backlog, and rejects unsupported advice with a rationale. Reviewer labels and
+repetition are evidence, not authority.
 
 ### Backlog item shape
 
@@ -204,6 +212,15 @@ backlog_staleness_days: 90
 The default `gates_for_release` order is fixed: **security → tests → cruft
 → docs → patterns**. Override only if the project has a justified reason.
 
+Release-bound items define each gate's focus, not a hard scan boundary. A gate
+may follow concrete evidence into adjacent dependencies, shared infrastructure,
+or system-wide mechanisms. Findings caused by, exposed by, or materially
+relevant to the release bind to it. Merely ambient discoveries must be written
+to the unbound backlog, so wider inspection does not silently expand release
+scope. Any cruft proposal that reduces behavior, validation, determinism,
+compatibility, safety, or another meaningful guarantee requires explicit user
+confirmation before it becomes active removal work.
+
 **`gate-refactor` is an opt-in gate** — not in the default list. Add it when your project has
 scan-rule libraries installed under `gate_refactor_scan_library_roots` (defaults:
 `{project}/.agents/skills/scan-*/SKILL.md`, then

package/docs/VISION.md

@@ -42,10 +42,10 @@ The plugin enforces three execution principles:
   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
 
@@ -95,9 +95,14 @@ agile-workflow is complete enough to operate as the supported workflow engine:
 - 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.
+  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 durable findings, and the
+  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.

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.16.1",
+  "version": "0.16.3",
   "description": "Markdown-based work-tracking substrate for AI-driven projects.",
   "author": {
     "name": "nklisch"

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.16.1"
+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
@@ -166,8 +167,11 @@ this caller note in every delegated prompt:
 > 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. Peer failures during design are non-blocking. Preserve
-> complementary→adversarial order when both phases run. For reviewer posture and
+> 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.
@@ -227,19 +231,23 @@ bounces[<item-id>] = times this item has gone implementing -> review -> implemen
 
 After every bounce:
 
-1. Confirm the review left concrete, durable findings in the item body.
-2. Rebuild the queue so the item naturally re-enters implementation.
-3. Implement the findings, run the relevant verification, and send the item
+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.
-4. Continue until review approves the item or autonomous work reaches a genuine
+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 substantive finding survives more
-than one correction pass, treat recurrence as evidence that the attempted fix or
-design model is 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. Do not park the item at `review`, label it stuck, or require human
+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)
@@ -310,20 +318,25 @@ When the scoped queue appears drained:
    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. 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.
+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
@@ -343,8 +356,8 @@ Narrate briefly as items advance. Final 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; include accepted findings fixed/filed and rejected
-  findings summary
+  fresh-context, or failed; summarize blockers fixed/activated, lower-risk
+  findings parked, and proposals rejected
 - Goal outcome: complete, blocked, or interrupted
 
 ## Guardrails
@@ -352,11 +365,13 @@ Narrate briefly as items advance. Final summary:
 - 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 at the effective
-  review weight and all accepted findings have been fixed or filed back into the
-  queue.
+  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`.

package/skills/convert/SKILL.md

@@ -628,6 +628,22 @@ must already exist at their new home or the dense content is lost.
    All other tags are project-specific (see `.work/CONVENTIONS.md`) and do not
    affect skill routing.
 
+   ### Engineering posture
+
+   Prefer short, clear code and context-appropriate rigor over speculative
+   generality. Not every project needs exhaustive invariants, edge handling,
+   firm determinism, or universal coverage. Test important interfaces, complex
+   units, and regressions learned from bugs—not every line. When touching an
+   area, eliminate unnecessary code, tests, checks, abstractions, and
+   compatibility paths; leave it simpler. Ask before removing meaningful
+   behavior, guarantees, validation, compatibility, or safety.
+
+   Release-bound items define a gate's focus, not a hard scan boundary. Gates
+   may follow concrete evidence into adjacent dependencies, shared
+   infrastructure, or system-wide mechanisms. Bind release-relevant findings;
+   route merely ambient discoveries to the unbound backlog so a scan does not
+   silently expand a release.
+
    ### Test integrity
 
    When running, writing, or modifying tests:
@@ -643,6 +659,11 @@ must already exist at their new home or the dense content is lost.
      green again, if a parked production bug is small enough for a single
      stride, pick it up immediately as `/agile-workflow:scope` → design →
      implement. Larger bugs stay in backlog for prioritization.
+   - **Tests must earn their upkeep.** Prefer tests at stable interfaces,
+     regression tests for real bugs, and unit tests for genuinely complex
+     units. Do not add tests merely to cover every line or surface; remove
+     duplicate, tautological, implementation-bound, or obsolete tests when
+     they add less confidence than maintenance cost.
    - **NEVER game a test to make it pass.** A failing test that documents
      *why* it fails — an inline comment naming the bug, a `skip` linked to a
      backlog id, an `xfail` with a reason — is more honest than a green test
@@ -654,8 +675,11 @@ must already exist at their new home or the dense content is lost.
    override agile-workflow defaults. When peeragent is available with a different
    model class, large/risky autopilot design decisions may use one advisory pass;
    small/low-risk work skips it. Autopilot also runs a final peer-review loop
-   before reporting completion and fixes or files accepted findings first.
-   Same-model peers fall back to local sub-agents instead. Claude Opus peeragent
+   before reporting completion. Reviewer findings are proposals: the receiving
+   orchestrator verifies them against repository context and actual risk. Only
+   credible material current-cycle risks block; park valid lower-priority
+   findings in the unbound backlog and continue. Same-model peers fall back to
+   local sub-agents instead. Claude Opus peeragent
    calls can take 10 to 30 minutes on large reviews; no return after a few minutes
    is not evidence that the call has hung.
 
@@ -670,7 +694,7 @@ must already exist at their new home or the dense content is lost.
    this managed-section overwrite — content verification, NOT just a non-empty +
    end-marker check): confirm `.agents/rules/agile-workflow.md` exists AND that the
    dense rule content the slim removes from AGENTS actually landed there — each
-   section is present (`### Tag semantics`, `### Test integrity`, the
+   section is present (`### Tag semantics`, `### Engineering posture`, `### Test integrity`, the
    advisory-review paragraph, and Broad entry points), or recompute per the Phase
    1.8 provenance check. Only when the content is verified present do you write or
    refresh the slim AGENTS section (Phase 6), overwriting the managed AGENTS block.

package/skills/epic-design/SKILL.md

@@ -125,9 +125,9 @@ Instead:
 
 ### Phase 2: Ground yourself
 
-The principles skill auto-loads — both code-design (Ports & Adapters, SSOT,
-Generated Contracts, Fail Fast) and substrate-execution (Item-IS-the-Work,
-Rolling-Foundation, Late-Binding) are active.
+The principles skill auto-loads — code-design includes proportional rigor, code
+economy, useful tests, and leaving touched areas simpler; substrate-execution
+includes Item-IS-the-Work, Rolling-Foundation, and Late-Binding.
 
 Read:
 1. `docs/VISION.md`, `docs/SPEC.md`, `docs/ARCHITECTURE.md` — foundation that
@@ -207,6 +207,17 @@ Aim for 2-6 child features per epic. Fewer than 2 means the epic was probably
 sized as a feature; flag the user. More than 6 means you're slicing too thin;
 collapse.
 
+### Phase 4.4: Identify simplification arcs
+
+For each area the epic touches, ask what capabilities, code, tests, checks,
+abstractions, compatibility paths, or whole subsystems the new direction can
+make unnecessary. Prefer feature arcs that replace and remove over arcs that
+only layer on more machinery. Fold cohesive elimination into the owning feature
+brief or create an explicit `[refactor]`/`[cleanup]` child feature when it needs
+independent design and review. Park unrelated cleanup. Any arc that removes
+behavior or meaningful guarantees becomes a high-level design decision for user
+confirmation, not an assumed refactor.
+
 ### Phase 4.5: Identify cross-feature dependencies
 
 For each candidate feature, ask:
@@ -309,6 +320,9 @@ capability it covers, why it exists in this epic, what it does NOT cover>
 - Position in epic: <e.g., "foundation feature — others depend on its types"
   / "consumer of feature-X" / "independent capability">
 
+## Simplification opportunity
+- <what this feature should delete, consolidate, replace, or deliberately retain>
+
 ## Foundation references
 - `docs/VISION.md` — relevant section(s) (only if directly relevant)
 - `docs/ARCHITECTURE.md` — relevant component(s)
@@ -362,6 +376,10 @@ feature lands.">
 - `<feature-id-2>` — <one-line description> — depends on: `[<feature-id-1>]`
 - `<feature-id-3>` — <one-line description> — depends on: `[<feature-id-1>]`
 
+### Simplification arcs
+
+- <feature-id> — <code/tests/checks/abstractions/subsystems it should remove or consolidate>
+
 ### Decomposition risks
 
 <from pre-mortem, if any. Otherwise omit the section.>