@nklisch/pi-agile-workflow 0.15.3 → 0.16.1

package/skills/autopilot/SKILL.md

@@ -45,8 +45,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 +57,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 +101,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 +158,19 @@ 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. 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 +197,50 @@ 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:
+After every bounce:
 
-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.
+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
+   through review again.
+4. Continue until review approves the item or autonomous work reaches a genuine
+   hard blocker under `principles/SKILL.md` Part III.
 
-Escalated items make the final goal outcome blocked unless the user resolves
-them before the run ends.
+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
+intervention solely because a counter reached two (or any other number).
 
 ### Phase 6: Refactor Cadence (`--all` Only)
 
@@ -249,10 +271,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,25 +286,30 @@ 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.
+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. For every substantive accepted finding:
    - Small and clearly safe fix: fix it immediately, run verification, commit,
      and rebuild the queue.
@@ -308,20 +336,24 @@ 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; include accepted findings fixed/filed and rejected
+  findings summary
 - 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 and all accepted findings have been fixed or filed back into the
+  queue.
 - 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

package/skills/convert/SKILL.md

@@ -447,6 +447,9 @@ Run an interactive interview via structured question tool. Six questions, in ord
    leak to future agents. Offer `retain-bodies` only for projects that deliberately keep full terminal
    bodies on disk (same `archived_atop`/late-binding semantics, bodies just not pruned).
 
+Review weight is deliberately not another interview question. Bootstrap writes the balanced default
+in Phase 5; callers can change the project convention later or override it per invocation.
+
 ### Phase 4: Create substrate skeleton
 
 ```bash
@@ -467,11 +470,23 @@ environment, locate the plugin source via the active skill/plugin path or manife
 
 ### Phase 5: Write CONVENTIONS.md
 
-Write `.work/CONVENTIONS.md` from the interview answers, following the format in SPEC.md. The
-`## Terminal-tier retention` section is **value-only** — write the bare `delete-refs`/`retain-bodies`
-value the user chose, not the merged prose (the prose lives in SPEC.md, never duplicated per project).
-This bare-value form is exactly what a later sync classifies as `match`, so a freshly bootstrapped
-repo never self-reports terminal-retention drift.
+Write `.work/CONVENTIONS.md` from the interview answers, following the format in SPEC.md. Also add
+this non-interactive project default:
+
+```markdown
+## Review weight
+review_weight: standard
+```
+
+Allowed values are `none | light | standard | thorough | maximum`. The setting is optional: when it
+is absent, review and autopilot resolve it to `standard`. Keep the level semantics and selection
+policy in `principles/SKILL.md` Part IV and `review/SKILL.md`; do not duplicate their review matrix or
+model guidance here.
+
+The `## Terminal-tier retention` section is **value-only** — write the bare
+`delete-refs`/`retain-bodies` value the user chose, not the merged prose (the prose lives in SPEC.md,
+never duplicated per project). This bare-value form is exactly what a later sync classifies as
+`match`, so a freshly bootstrapped repo never self-reports terminal-retention drift.
 
 ### Phase 6: Write the canonical AGENTS.md section
 
@@ -1047,6 +1062,10 @@ path list), plus deeper checks:
   - `.claude/rules/patterns.md` state (legacy content vs AGENTS shim)
   - `.work/CONVENTIONS.md` load-bearing tag entries (see below). The rest of
     CONVENTIONS is user-owned and untouched.
+  - `.work/CONVENTIONS.md` `review_weight` — preserve any existing value unchanged; review validates
+    the five-value boundary when it consumes the setting. Absence is also valid and resolves to
+    `standard`, so sync neither inserts the default into older projects nor asks a migration question.
+    The allowed values and canonical policy are in Phase 5.
   - `.work/CONVENTIONS.md` **Terminal-tier retention** state (the merged convention — see
     "Terminal-tier retention drift" below). The per-project CONVENTIONS template is **value-only** (a
     `## Terminal-tier retention` heading + a bare `delete-refs`/`retain-bodies` value); the merged
@@ -1337,9 +1356,10 @@ These are NEVER touched in sync mode:
   user confirmation, are: (a) load-bearing tag entries (`refactor`, `perf`) when they match a known
   prior plugin default verbatim, and (b) the `## Terminal-tier retention` convention when it is
   `missing`/`partial`/a bespoke `## Done-item archival` overlap (add / reconcile / converge). A bare
-  `delete-refs`/`retain-bodies` value is `match` and is left untouched. Everything
-  else in CONVENTIONS — release mapping, project tags, slug conventions, gate config, any user
-  prose — is untouched.
+  `delete-refs`/`retain-bodies` value is `match` and is left untouched. `review_weight` is optional
+  and is never added, reset, or rewritten by sync; preserve an existing value byte-for-byte, while
+  absence continues to mean `standard`. Everything else in CONVENTIONS — release mapping, project
+  tags, slug conventions, gate config, any user prose — is untouched.
 - Everything under `.work/active/`, `.work/backlog/`, `.work/releases/`,
   `.work/archive/`
 - User-authored rule references under `.agents/skills/refactor-conventions/`.

package/skills/epic-design/SKILL.md

@@ -248,76 +248,25 @@ decomposition. Child briefs note "mockups pending — see parent epic" so
 
 Skip this phase entirely if `ux-ui-design` is not installed.
 
-### Phase 4.7: Surface high-level design ambiguities
-
-Read the epic and the candidate decomposition you've sketched, and derive
-specific, concrete high-level design questions about *this* epic's actual
-work. These are the directional choices that, if locked in now, will keep
-every child feature's later design pass aligned. Examples of the *shape* of
-question to surface (the actual content must come from the epic):
-
-- "For this epic's auth surface, do we use OAuth via the existing provider,
-  or roll a local session model?"
-- "Should the new sync engine push from server to client, pull from client
-  on-demand, or both?"
-- "Are we committing to multi-tenant data isolation in this epic, or is
-  single-tenant acceptable for v1?"
-- "Does the import pipeline need to handle CSV and Parquet, or just CSV?"
-
-These are product/architecture/scope questions specific to the epic in
-front of you — not generic prompts about boundaries, naming, or sizing.
-Skip anything you can answer from the epic body, foundation docs, or
-codebase. Skip anything that's safely a downstream feature-design call
-(function signatures, exact file paths, per-unit test approach).
-
-Aim for the smallest set of questions that meaningfully resolve direction
-— typically 2-5. Zero is fine if the epic body and foundation docs already
-pin every directional choice.
-
-**Cross-model advisory review under autopilot.** If this skill is running as a
-delegation from active autopilot, the epic has large/risky architectural
-decisions, and the body does not already contain useful `## Design decisions`
-from a prior `--only-questions` pass, apply the cross-model advisory review
-policy from `principles/SKILL.md` before resolving the questions yourself.
-
-Use one focused `peer` pass only when a different model class is available.
-Ask for missing questions, risks, ambiguous constraints, and alternatives for
-this epic's decomposition — not for a final verdict. Do not run the multi-pass
-`peer-review` loop during routine autopilot design. If peeragent is
-unavailable, the peer would use the same model class, or the invocation fails,
-continue with host judgment and note that the advisory pass was skipped.
-If the peeragent target is Claude Opus, allow 10 to 30 minutes for a large
-review; no return after a few minutes is not evidence that it has hung.
-
-Summarize the useful output under `## Other agent review` in the epic body and
-fold accepted questions/risks into the decisions you log. Do not paste the peer
-transcript into the item.
-
-If this skill is running **as a delegation from an active autopilot run or
-harness goal**, resolve each question with judgment (prioritize: consistent
-with foundation docs > simpler option > defers irreversible decisions) and log
-under `## Design decisions` in the epic body:
-
-```markdown
-## Design decisions
-- **<question>**: <choice> — <one-line rationale>
-```
-
-In every other invocation — including direct user invocation under harness
-auto mode (`permissions.defaultMode: "auto"`) — ask the user via
-`structured question tool` before locking in, then write the answers under `## Design
-decisions` in the epic body. Harness-level "work without pausing" reminders
-do **not** suppress these checkpoints. See `principles/SKILL.md` Part III
-for the full caller-awareness rule.
-
-The child feature briefs you write in Phase 6 should reference the relevant
-design decisions so each feature's later design pass inherits the locked-in
-direction.
-
-The exception under autopilot: a 50/50 between two large irreversible
-choices (e.g., SQL vs document store for this epic's persistence layer).
-Append a `## Blocker` section and return without advancing — autopilot will
-skip and surface the blocker.
+### Phase 4.7: Resolve high-level design decisions
+
+Identify the epic-specific product, architecture, scope, and decomposition
+decisions that must align its child features. Ignore points settled by the epic,
+foundation docs, code, or an existing `## Design decisions` section, and leave
+function signatures, file paths, and unit-level tests to feature design. Zero
+open decisions is valid.
+
+Apply `principles/SKILL.md` Part III exactly: resolve routine, reversible points
+with judgment and a logged rationale; reserve structured questions for product
+direction, external contracts, and expensive hard-to-reverse choices. Apply
+Part IV's risk-driven advisory policy in both direct and autopilot modes; do not
+restate reviewer topology here.
+
+Record decisions under `## Design decisions`. When autopilot is the active
+driver, it never asks; use evidence and the least irreversible sound choice.
+Only contradictory state that Part III identifies as a hard halt blocks
+advancement. Child briefs reference the decisions relevant to their later design
+passes.
 
 ### Phase 5: Pre-mortem
 

package/skills/feature-design/SKILL.md

@@ -201,68 +201,29 @@ agent rules (tag semantics, test integrity, review policy). Treat AGENTS as
 canonical if they disagree. Recency improves adherence. Confirm your approach
 aligns with project conventions.
 
-### Phase 4.5: Surface ambiguities
-
-Read the feature brief and the design space you've started to map, and
-derive specific, concrete design questions about *this* feature's actual
-work — requirements gaps, architecture trade-offs, scope boundaries,
-integration assumptions, UX decisions. The questions must come from the
-feature in front of you; examples of the *shape* only:
-
-- "Should the cache invalidate on write or rely on TTL only?"
-- "Does the upload accept multipart, or a presigned URL flow?"
-- "When the parser hits a malformed row, do we skip and continue or fail
-  the whole batch?"
-- "Is paging cursor-based or offset-based?"
-
-Skip anything the brief, parent epic body, foundation docs, or codebase
-already pin. Skip anything that's safely an implementation-time call.
-
-Aim for the smallest set of questions that meaningfully resolve direction
-— typically 2-5. Zero is fine if everything's already pinned.
-
-**Cross-model advisory review under autopilot.** If this skill is running as a
-delegation from active autopilot, the feature has large/risky architectural
-decisions, and the body does not already contain useful `## Design decisions`
-from a prior `--only-questions` pass, apply the cross-model advisory review
-policy from `principles/SKILL.md` before resolving the questions yourself.
-
-Use one focused `peer` pass only when a different model class is available.
-Ask for missing questions, risks, ambiguous constraints, and alternatives for
-this feature's design — not for a final verdict. Do not run the multi-pass
-`peer-review` loop during routine autopilot design. If peeragent is
-unavailable, the peer would use the same model class, or the invocation fails,
-continue with host judgment and note that the advisory pass was skipped.
-If the peeragent target is Claude Opus, allow 10 to 30 minutes for a large
-review; no return after a few minutes is not evidence that it has hung.
-
-Summarize the useful output under `## Other agent review` in the feature body
-and fold accepted questions/risks into the decisions you log. Do not paste the
-peer transcript into the item.
-
-If this skill is running **as a delegation from an active autopilot run or
-harness goal**, resolve each question with judgment (prioritize: consistent
-with foundation docs > simpler option > defers irreversible decisions) and log
-under `## Design decisions` in the body:
+### Phase 4.5: Resolve design decisions
+
+Identify concrete decisions raised by this feature's requirements, architecture,
+scope, integrations, and UX. Ignore points already settled by the brief, parent,
+foundation docs, code, or an existing `## Design decisions` section, and defer
+safe implementation details. Zero open decisions is valid.
+
+Apply `principles/SKILL.md` Part III exactly: resolve routine, reversible points
+with judgment and a logged rationale; reserve structured questions for product
+direction, external contracts, and expensive hard-to-reverse choices. Apply
+Part IV's risk-driven advisory policy in both direct and autopilot modes; do not
+restate reviewer topology here.
+
+Record decisions in the feature body:
 
 ```markdown
 ## Design decisions
-- **<question>**: <choice> — <one-line rationale>
+- **<decision>**: <choice> — <one-line rationale>
 ```
 
-If the body already contains a `## Design decisions` section (from a prior
-`--only-questions` pass or from `epic-design` Phase 4.7), treat those
-locked-in answers as inputs — do NOT re-ask them.
-
-In every other invocation — including direct user invocation under harness
-auto mode (`permissions.defaultMode: "auto"`) — ask the user via
-`structured question tool` before locking in. Harness-level "work without pausing"
-reminders do **not** suppress these checkpoints. See `principles/SKILL.md`
-Part III for the full caller-awareness rule.
-
-The exception under autopilot: a 50/50 between two large irreversible choices
-(e.g., SQL vs document store). Append a `## Blocker` section and return
-without advancing — autopilot will skip and surface the blocker.
+When autopilot is the active driver, it never asks; use evidence and the least
+irreversible sound choice. Only contradictory state that Part III identifies as
+a hard halt blocks advancement.
 
 ### Phase 4.6: UI surface fallback (runs when ux-ui-design is installed)