@nklisch/pi-agile-workflow 0.16.1 → 0.16.4

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)
@@ -295,9 +303,11 @@ When the scoped queue appears drained:
    - `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
+   Ask for bugs, missed acceptance criteria, unreviewed risks, false/stale/
+   contradictory foundation-doc assertions, and substrate-state inconsistencies
+   that would make "complete" premature. Foundation-doc omissions and
+   unimplemented future-state claims are not findings. 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
@@ -310,20 +320,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 +358,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 +367,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

@@ -514,7 +514,9 @@ parent, and dependency. Common patterns:
 - `work-view --help` for the full flag set
 
 Foundation docs in `docs/` describe the system's current state or intended
-future state, never the past; git history is the audit trail. Item files are
+future state, never the past; git history is the audit trail. Review existing
+assertions only: missing coverage and unimplemented future intent are not drift;
+flag only false, stale, or contradictory claims. Item files are
 the durable state: update the body with implementation discoveries, review
 findings, blockers, and decisions instead of relying on chat history.
 
@@ -628,6 +630,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 +661,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 +677,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 +696,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.>

package/skills/feature-design/SKILL.md

@@ -146,9 +146,9 @@ The body should already have a brief from `scope`. Use it as the seed for design
 
 ### 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 docs that
@@ -281,6 +281,17 @@ For each unit, specify:
 
 Make strong decisions about abstractions, naming, and module boundaries.
 
+#### 5d. Elimination and cleanup pass
+
+Before adding another unit or abstraction, ask what this feature can delete,
+inline, consolidate, or make unnecessary in the area it touches. Consider code,
+tests, checks, configuration, compatibility paths, and existing abstractions.
+Fold safe cohesive cleanup into a unit. Create explicit `[refactor]` or
+`[cleanup]` child stories when the cleanup is worthwhile but independently
+reviewable; park broader work. If a candidate reduces behavior or guarantees,
+record it as a design decision for user confirmation rather than assuming
+removal.
+
 ### Phase 5.5: Pre-mortem
 
 Before finalizing, attack the design:
@@ -295,12 +306,20 @@ feature body.
 
 ### Phase 6: Test approach
 
-For each unit, design:
-- **Unit tests** — behaviors to verify, edge cases, error paths
-- **Integration points** — where does this unit meet other units; what tests prove the seams
-- **Test data** — fixtures, factories, seed data needed
-
-If a unit is hard to test, the design is probably wrong. Note it and revise.
+Design the smallest useful test surface:
+- **Interface tests** — important behavior at stable public boundaries and
+  cross-unit seams
+- **Regression tests** — bugs or demonstrated risks this work must not repeat
+- **Unit tests** — only for genuinely complex isolated logic where examples add
+  confidence
+- **Test removal** — duplicate, tautological, obsolete, or implementation-bound
+  tests this change can safely retire
+- **Test data** — only fixtures or factories the chosen tests actually need
+
+Do not create a test for every unit, branch, edge, or acceptance statement by
+default. State what risk or contract each proposed test protects. Hard-to-test
+important behavior may indicate a bad boundary; simple code needing no isolated
+test is not itself a design flaw.
 
 ### Phase 7: Order and child stories
 
@@ -379,9 +398,13 @@ Update the feature file. Append (after the existing brief) sections like:
 1. <unit / story>
 2. <unit / story>
 
+## Simplification
+- <code/tests/checks/abstractions removed, consolidated, or intentionally retained>
+- <cleanup/refactor stories, if any>
+
 ## Testing
-### Unit Tests: `tests/path/<name>.test.ext`
-<test approach for each unit>
+- <interface, regression, or complex-unit tests and the value each protects>
+- <low-value tests to remove, if any>
 
 ## Risks
 <from pre-mortem, if any>

package/skills/gate-cruft/SKILL.md

@@ -1,9 +1,10 @@
 ---
 name: gate-cruft
 description: >
-  Cruft gate that scans the items bound to a release for AI-accumulated debris (dead code, stale
-  comments, compatibility shims, defensive bloat, over-abstraction) introduced or revealed by the
-  bundle. Delegates the full scan to a deep cleanup scanner agent which runs language-aware
+  Cruft gate focused on release-bound items that may follow relevant evidence into adjacent or
+  system-wide code. Finds dead code, stale comments, low-value tests and checks, compatibility
+  shims, defensive bloat, and over-abstraction, including whole systems that may no longer earn
+  their cost. Delegates the scan to a deep cleanup scanner agent which runs language-aware
   detection plus heuristic pattern-matching, then returns findings. The orchestrator converts findings
   into items in .work/active/ with gate_origin:cruft and tags:[cleanup]. Auto-triggers during
   /agile-workflow:release-deploy.
@@ -11,11 +12,14 @@ description: >
 
 # Gate-Cruft
 
-You orchestrate a cruft gate over the items bound to a release. The actual
-scan runs inside a **deep cleanup scanner agent** (a generic sub-agent prompted with the scanner posture from `../principles/references/subagents.md`); your role is to prepare the bundle context,
+You orchestrate a cruft gate focused on the items bound to a release. Bound
+items establish the center of gravity, not a hard file boundary: the scanner may
+follow relevant call paths, dependencies, shared infrastructure, tests, or
+system-wide mechanisms needed to understand whether complexity still earns its
+cost. The actual scan runs inside a **deep cleanup scanner agent** (a generic sub-agent prompted with the scanner posture from `../principles/references/subagents.md`); your role is to prepare the bundle context,
 dispatch the scanner, and convert the findings it returns into items in the
 substrate. Findings get `gate_origin: cruft`,
-`tags: [cleanup]`, with severity tier shaping the stage.
+`tags: [cleanup]`, with confidence shaping placement and stage.
 
 Scanner strength is explicit: spawn exactly one source-read-only deep cleanup
 scanner with the strongest inspection/reviewer setting the host exposes. Use a generic sub-agent prompted with the scanner posture from `../principles/references/subagents.md`. Use extra-high reasoning
@@ -70,9 +74,10 @@ confidence, and returns structured findings.
 **Brief template**:
 
 > You are conducting a cruft scan for release `<version>` as an agile-workflow
-> scanner. Use read/search/shell tools as needed. Audit ONLY the bundle's
-> changed files — not the whole repo. Do not spawn nested sub-agents or implement
-> fixes.
+> scanner. Use read/search/shell tools as needed. Start with the bundle's
+> changed files, then follow relevant evidence into adjacent dependencies,
+> shared infrastructure, tests, or system-wide mechanisms. Do not perform an
+> aimless whole-repo sweep, spawn nested sub-agents, or implement fixes.
 >
 > **Bundle scope**:
 > ```
@@ -90,8 +95,9 @@ confidence, and returns structured findings.
 >    `Cargo.toml`, `go.mod`, `pyproject.toml`, `Makefile`. This determines
 >    which language-aware detection tools are available.
 >
-> 2. **Language-aware detection (high confidence)** — run against the
->    bundle's changed files only:
+> 2. **Language-aware detection (high confidence)** — run against the bundle
+>    files first; expand a tool's scope only when needed to establish callers,
+>    duplication, reachability, ownership, or system-level cost:
 >    - **TypeScript/JavaScript** — `tsc --noUnusedLocals --noUnusedParameters
 >      --noEmit`, eslint unused rules
 >    - **Python** — `ruff check --select F811,F841,F401`, `vulture`
@@ -99,7 +105,8 @@ confidence, and returns structured findings.
 >    - **Rust** — compiler warnings for `#[warn(dead_code)]`
 >    Capture output and parse into findings.
 >
-> 3. **Heuristic pattern-matching** via Grep on bundle files:
+> 3. **Heuristic pattern-matching** via Grep, beginning with bundle files and
+>    following concrete references where the evidence leads:
 >
 >    **Medium confidence:**
 >    - Comments containing "removed", "backwards compat", "for backwards
@@ -117,12 +124,27 @@ confidence, and returns structured findings.
 >    - Single-use helper functions that could be inlined
 >    - Config/options parameters that only ever receive one value
 >    - Abstractions with a single implementation
+>    - Duplicate, tautological, obsolete, or implementation-bound tests
+>    - Validation/check layers whose guarantees exceed the project's actual scope
 >
-> 4. **Cross-check existing patterns** — read `.agents/skills/patterns/` and
+> 4. **System-level challenge** — inspect whether an entire validation layer,
+>    invariant/check system, test suite, compatibility mechanism, defensive
+>    subsystem, or abstraction family exposed by the bundle still justifies its
+>    maintenance cost. State its current purpose, evidence of cost, what removal
+>    would simplify, and which behavior or guarantee would be lost. Classify
+>    these as `Decision required`; never assume the guarantee should disappear.
+>
+> 5. **Cross-check existing patterns** — read `.agents/skills/patterns/` and
 >    legacy `.claude/skills/patterns/` if
 >    present. Intentional repetition documented as a pattern is NOT cruft.
 >
-> 5. **Triage by confidence**:
+> 6. **Triage by confidence, release relevance, and decision need**:
+>    - `Release-relevant`: caused by, exposed by, or materially affects the bundle.
+>    - `Ambient`: useful discovery outside release scope; propose as unbound backlog.
+>    - `Decision required: yes`: any whole-system removal candidate, especially
+>      one that changes behavior or guarantees; ask before creating removal work.
+>
+>    Then triage confidence:
 >    | Confidence | Stage of produced item |
 >    |---|---|
 >    | High (tool-detected) | `stage: implementing` |
@@ -139,7 +161,11 @@ confidence, and returns structured findings.
 > - **Confidence**: High | Medium | Low
 > - **Category**: unused import | dead function | stale comment |
 >   compatibility shim | passthrough wrapper | defensive try/catch |
->   single-use helper | over-abstraction
+>   single-use helper | over-abstraction | low-value test | redundant checks |
+>   system-level simplification
+> - **Relevance**: Release-relevant | Ambient
+> - **Decision required**: yes | no
+> - **Guarantee affected**: none | <behavior/validation/determinism/compatibility/safety>
 > - **Location**: `<file>:<line>`
 > - **Evidence**:
 >   ```<lang>
@@ -162,7 +188,8 @@ confidence, and returns structured findings.
 > ```
 >
 > **Rules**:
-> - Scan only Bundle scope. Don't expand.
+> - Bundle scope is the focus, not a hard boundary. Expand only by following
+>   concrete evidence; record why each out-of-bundle file or system was inspected.
 > - Cite file:line for every finding.
 > - Don't fabricate. If a tool produces no output, don't invent findings.
 > - Skip already-tracked. Patterns documented in
@@ -172,9 +199,19 @@ confidence, and returns structured findings.
 >   used externally?" — if you can't confirm zero callers, downgrade to
 >   medium confidence rather than high).
 
-### Phase 4: Convert findings to items
+### Phase 4: Resolve system-level removal decisions
+
+For each `Decision required` candidate, present the system's purpose, current
+cost, proposed simplification, and guarantees or behavior removal would weaken.
+Ask the user whether to remove, reduce, retain, or park it. Group related
+candidates and use the structured question tool in batches when available.
+Never turn a guarantee-reducing proposal into active work without confirmation.
+In a non-interactive gate path, write an unbound backlog decision proposal and
+continue; do not assume consent or block unrelated release work.
 
-For each finding the scanner returned:
+### Phase 5: Convert findings to items
+
+For each confirmed or ordinary finding the scanner returned:
 
 Read `gate_finding_routing` from `.work/CONVENTIONS.md` before writing items.
 If absent, use the default routing below. Normalize cruft confidence to routing
@@ -191,7 +228,7 @@ stage: implementing | drafting    # by confidence
 tags: [cleanup]
 parent: null
 depends_on: []
-release_binding: <version>
+release_binding: <version> | null  # null for ambient or unconfirmed decision proposals
 gate_origin: cruft
 created: YYYY-MM-DD
 updated: YYYY-MM-DD
@@ -217,12 +254,17 @@ High | Medium | Low
 <what to remove and what to fix in the surroundings — imports, whitespace, etc.>
 ```
 
+Release-relevant findings use the normal confidence mapping and bind to the
+release. Ambient findings and unconfirmed decision proposals always go to the
+unbound backlog regardless of confidence. A confirmed system removal may bind
+only when the user explicitly includes it in the current release.
+
 Default confidence -> placement mapping:
 - **High** → `stage: implementing` in `.work/active/stories/`
 - **Medium** → `stage: drafting` in `.work/active/stories/`
 - **Low** → backlog file in `.work/backlog/`
 
-### Phase 5: Commit
+### Phase 6: Commit
 
 ```bash
 git add .work/active/stories/ .work/backlog/
@@ -233,7 +275,7 @@ git commit -m "gate-cruft: <N> findings for <version>"
 
 In conversation:
 - **Bundle**: `<version>` — `<N>` items audited, `<M>` files changed
-- **Findings**: count by confidence (High / Medium / Low)
+- **Findings**: count by confidence and relevance (release / ambient / decision)
 - **Items created**: count, with new ids
 - **Already-tracked**: count skipped
 
@@ -247,10 +289,13 @@ and parallelizes well."
 
 - **The scan happens in the scanner agent, not here.** Your job is bundle
   prep, dispatch, and item-writing. Don't replicate the scanner's analysis.
-- Audit only the bundle's changed files, not the whole repo.
+- Release-bound items define focus, not a hard boundary. Follow concrete
+  evidence into adjacent or system-wide code, but do not turn the gate into an
+  unfocused whole-repo audit.
 - Never remove code in this skill — produce items only.
-- Cleanup items must be surgical when implemented. They remove cruft and fix
-  the immediate surroundings only. They do NOT improve, refactor, or enhance.
+- Local cleanup items should stay surgical. Whole-system simplification is
+  allowed as a proposal, but any reduction in behavior or guarantees requires
+  explicit user confirmation and appropriately scoped design work.
 - Patterns documented in `.agents/skills/patterns/` or legacy
   `.claude/skills/patterns/` are intentional, not
   cruft. The scanner cross-checks; don't override.