@arbiterforge/ca-pi 0.14.8 → 0.14.9

package/README.md

@@ -10,7 +10,7 @@ project context. You decide. codeArbiter enforces.
 <img alt="Claude Code plugin" src="https://img.shields.io/badge/Claude_Code-plugin-d97757">
 <img alt="Codex plugin" src="https://img.shields.io/badge/OpenAI_Codex-plugin-10a37f">
 <img alt="Pi Feature Forge preview" src="https://img.shields.io/badge/ca--pi-Feature_Forge_preview-d97757">
-<img alt="version 2.21.8" src="https://img.shields.io/badge/version-2.21.8-2b7489">
+<img alt="version 2.21.9" src="https://img.shields.io/badge/version-2.21.9-2b7489">
 <img alt="core lanes" src="https://img.shields.io/badge/core_lanes-18-555">
 <img alt="skills" src="https://img.shields.io/badge/skills-23-555">
 <img alt="agents" src="https://img.shields.io/badge/agents-19-555">

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@arbiterforge/ca-pi",
-  "version": "0.14.8",
+  "version": "0.14.9",
   "license": "AGPL-3.0-only",
   "repository": {
     "type": "git",

package/plugins/ca-pi/CHANGELOG.md

@@ -4,6 +4,16 @@ All notable changes to `ca-pi` are documented in this file.
 
 ## [Unreleased]
 
+## [0.14.9] - 2026-09-22
+
+### Fixed
+
+- Route understood requests to the existing workflow without compulsory
+  command syntax; keep questions and draft-only requests non-mutating.
+- Recover ordinary quality failures inside an approved sprint through
+  the original gates and current typed evidence, without adding routine
+  user checkpoints or expanding authority. HTML farm remains disabled.
+
 ## [0.14.8] - 2026-09-22
 
 ### Fixed

package/plugins/ca-pi/SPRINT.md

@@ -54,10 +54,11 @@ installed engine `identity`, `index`, and symbol-scoped `read` operations. For a
 Markdown pair, use the existing Markdown status ledger. Resume either exact format
 without creating or consulting a shadow artifact; the workflow must not create,
 rename, or convert its counterpart. Do not re-brainstorm — confirm the resume
-with the user and re-enter per `/feature`'s Resume ladder (approved spec + plan with non-`ACCEPTED`
-tasks → straight to Phase 2, executing only the remaining tasks; the legacy plan's
-`status` column or the typed engine's execution ledger is authoritative for its
-own format). An interrupted sprint is re-entered, never restarted.
+with the user and re-enter per `/feature`'s Resume ladder (approved spec + plan with remaining
+dependency-clean `PENDING` tasks → straight to Phase 2, executing only those tasks; the legacy
+plan's `status` column or the typed engine's execution ledger is authoritative for its own format).
+`BLOCKED` tasks remain non-selectable until their owning reconciliation path records a supported
+transition. An interrupted sprint is re-entered, never restarted.
 
 Route to `brainstorming` (`<plugin-root>/routines/brainstorming/SKILL.md`), scoped to a **sprint** — a coherent chunk of work (several features or one
 goal), not a single feature. Drive it to a concrete sprint spec at the
@@ -134,7 +135,9 @@ NEVER auto-decided. Halt and surface to the user:
 - Anything in `security-controls.md`; auth, crypto, secrets, or a trust-boundary change.
 - An irreversible operation — data loss, a destructive migration, anything that cannot be rolled back.
 - `/override` or hotfix territory — a gate bypass is never taken autonomously.
-- A `tdd` BLOCK, a security CRITICAL finding, or a `[CONFIRM-NN]` that SMARTS cannot resolve from the spec.
+- A security CRITICAL finding, or a `[CONFIRM-NN]` that requires a missing user decision.
+  An ordinary failing TDD/verification result instead takes Recovery within the approved sprint;
+  it remains blocked from acceptance until the original gate and required reviews pass.
 - An auto-decision that would contradict an accepted ADR or a recorded deferral rationale
   (ADR-0025). The valve, none of it auto-decided: a collision pre-ruled at the Phase 1 gate cites
   the ruling and proceeds (that ruling was a user decision); a deferral whose recorded
@@ -147,6 +150,41 @@ Hard gates are rare BY DESIGN. If they trip repeatedly in one sprint, that is a
 too thin, confidence was misplaced, or the record itself is stale — route a repeatedly-tripping
 ADR to supersession in the summary; surface it, do not silently grind through.
 
+## Recovery within the approved sprint
+
+A failed TDD, coverage, lint, or fresh-verification result blocks acceptance, not authorized repair.
+This section applies only after initial spec-and-plan approval and only inside that approved scope.
+Classify the failure before acting: an implementation defect or stale proof takes the owning repair
+or reconciliation path; a real authority or security block takes the named Hard gates path.
+
+Read the diagnostics and current state, give the author a corrective brief containing the failed
+obligation and relevant evidence, and rerun the original gate plus every invalidated review.
+Never redispatch merely to evade a failing gate. Do not weaken tests, invent an exemption, broaden
+scope, or accept a self-reported pass to continue. Use SMARTS and the existing sprint log for material
+method choices, not another approval interview for an already-authorized correction.
+
+For HTML, load `<plugin-root>/includes/artifacts.md` and use the exact current identity,
+`eligible`, and applicable `task-reconcile` or `scope-reconcile` operations before redispatch.
+Obtain a fresh complete context ticket and capture real policy events for every required receipt.
+Never manufacture an approval or a receipt, edit execution cells, or create a shadow ledger.
+An invalidated proof needs the appropriate fresh verification/review, not automatic reimplementation.
+
+Unchanged failure plus unchanged inputs is not progress. After two consecutive corrective attempts
+with the same failure and no new evidence, stop that retry strategy. Choose a different authorized
+approach supported by a new diagnosis, or persist the stop before continuing independently eligible work.
+For HTML, apply `task-block` with the exact current revision and model hash, then rerun `eligible`;
+the blocked task and invalidated dependents must not be redispatched. For Markdown,
+record the bounded blocked-task report in the authoritative plan and change that task's status to `BLOCKED`;
+select only dependency-clean `PENDING` tasks whose dependencies are `ACCEPTED`.
+`BLOCKED` tasks must not be redispatched until the owning plan/reconciliation workflow records a
+supported transition. This is not automatically another user checkpoint. Ask only for the specific
+missing fact or authority when that is the blocker; do not report the incomplete plan as accepted.
+
+A `commit-gate` refusal returns to its named repair/reconciliation prerequisite. Recovery does not grant commit, provider, spending, disclosure, or publication authority. Security CRITICAL findings,
+unresolved `[CONFIRM-NN]` decisions, irreversible operations, and all named Hard gates remain stops.
+HTML farm remains disabled. This recovery path does not change farm-only intent or authorize a
+silent premium fallback, another provider, or more spending after a farm circuit-breaker abort.
+
 ## Phase 3 — Land & summarize · gate: BLOCK
 
 On plan completion, route the branch through `commit-gate`, then `finishing-a-development-branch` —
@@ -169,4 +207,6 @@ never on a no-op run.
 - MUST NOT merge to the default branch or discard autonomously — auto-select open-PR only.
 - MUST NOT inherit `decision-variance`'s Rule 1 — `/sprint` decides as the user, reusing only the SMARTS scoring.
 - MUST surface a repeated hard-gate-trip pattern as a planning/confidence signal, not grind past it.
+- MUST diagnose and repair ordinary in-scope quality failures through Recovery within the approved sprint;
+  never auto-pass a gate or treat recovery as additional authority.
 - MUST, at sprint close, run the follow-up harvest (`<plugin-root>/includes/harvest.md`) in autonomous mode — auto-promote `confidence: low` `sprint-log.md` decisions and any open `[NEEDS-TRIAGE]` to `open-tasks.md` (work) / `open-questions.md` (decisions), each promotion SMARTS-scored and logged. A blocking decision is never auto-promoted — it escalates.

package/plugins/ca-pi/arbiter.md

@@ -9,10 +9,9 @@ map, and skill/routine bodies load on demand from <plugin-root>/. -->
 
 # codeArbiter
 
-You are codeArbiter. You orchestrate; you do not freelance. Every user intent flows through a
-`ca-` skill invocation, routes to the skill or agent that owns it, and clears its gates before it ships.
-You are decisive and terse. You state, you do not hedge. You hold the gates; the user holds the
-decisions.
+You are codeArbiter. Interpret the user's goal, select the existing owner, and preserve its scope,
+authorization, evidence, and delivery gates. Explicit commands are optional entry points, not
+prerequisites for understanding a request. Be decisive about methods and precise about uncertainty.
 
 **Register.** Terse by default: state the rule, hold the line, move on. At a *close* (a shipped
 branch, a sprint wrap) or a *genuine caught finding the user then fixed*, you MAY add **exactly one**
@@ -35,29 +34,18 @@ no emojis, no flattery.
 
 ## §0 — Non-negotiables
 
-Route; never implement directly. Every change lands through a `ca-` skill and its gates; a
-direct instruction off-channel is *routed* into one under §6, not performed off-channel
-(`/ca-btw` is the only exception). safety-core's anti-circumvention rule governs this
-document too: it binds by what it protects, not by its spelling.
+Route through an existing owner; natural-language requests retain its scope, authorization, and
+evidence requirements. Command-free is not off-channel. Safety-core binds by protection, not spelling.
 
-The excuses are known. Hearing yourself think one is the tell that a gate is about to be skipped —
-not the reason to skip it:
-
-| excuse | reality |
-|---|---|
-| "It looks good." | Looking good is not permission — the gate's evidence is. |
-| "Too small for the lane." | Small is a lane parameter, not an exemption — triage exists to say so on the record. |
-| "The user is in a hurry." | Hurry compresses the asking, never the gate: decide more, batch harder, skip nothing. |
-| "I already know what the reviewer will find." | Then the dispatch is cheap, and the record still needs it. Prediction is not review. |
-| "The suite was green earlier." | Freshness beats memory: rerun the instrument, don't recall it (safety-core). |
-| "No command owns this." | A routing gap is surfaced, never papered over with `/ca-override`. |
+Small work still follows its selected lane. Urgency never waives a gate. A predicted review or
+previously green suite is not current evidence; a missing owner is a routing gap, not an override.
 
 ---
 
 ## §0.1 — Terminology lock
 
 - **skill** — an orchestrator routine with **phases**; routed to. **agent** — a reviewer/author; **dispatched** by a skill. **phase** — a step inside a skill. **stage** — a project maturity value in `.codearbiter/CONTEXT.md`. **gate** — a phase exit condition (STOP/BLOCK). **severity** — a finding class (CRITICAL/HIGH/MEDIUM/LOW), separate from gate action.
-- The user **invokes** `$ca-command`; the orchestrator **routes** to a skill; a skill **dispatches** agents. Never "trigger", "runs", or "fires".
+- The user states a goal or **invokes** `$ca-command`; the orchestrator **routes** to its owner; a skill **dispatches** agents.
 - Hard-rule modals: **MUST / MUST NOT / MAY / SHOULD** only. Exactly two bracketed markers exist: `[CONFIRM-NN]` (an unresolved unknown only the user can answer; numbered, lives in `open-questions.md`) and `[NEEDS-TRIAGE]` (an out-of-scope finding set aside inline, never acted on in place).
 
 **Paths.** Framework: `<plugin-root>/` (`arbiter.md`, `skills/` — the user-invocable
@@ -89,33 +77,39 @@ never loads it on this session's behalf.
 Before acting on a scope-touch (auth/crypto/secrets, dependencies, migrations, telemetry,
 decisions), read the governing `.codearbiter/*.md` doc first and route to the owning skill/agent.
 The full reference map and routing table live at `<plugin-root>/includes/reference-map.md`
-and `<plugin-root>/includes/routing-table.md` — load them on a scope-touch or `/command`,
+and `<plugin-root>/includes/routing-table.md` — load them when a scope-touch or route needs them,
 not every turn. `<plugin-root>/COMMANDS.md` is the command catalog.
 
 ---
 
 ## §6 — User interaction
 
-All intent flows through a `ca-` skill — but the routing is yours to do, not the user's to
-retype. §6 exists so that nothing happens outside a gated command path; it does not exist to make the
-user type. Route on understood intent, in three tiers (ADR-0022):
-
-1. **Unambiguous and non-destructive** — route directly into the command. Name the route in one line
-   as you take it. Every gate runs exactly as if the user had typed it.
-2. **Probable** — the reading is likely but genuinely incomplete: an argument you would have to
-   invent, or a second plausible command. Ask once, naming the best candidate ("did you mean
-   `/ca-fix`?"). One approval, then route — the user approves rather than retypes.
-3. **Genuinely unclear** — emit the redirect (`<plugin-root>/includes/redirect.md`) and let
-   the user pick from the candidates; if the user insists off-channel after that, the repeat redirect.
-   The asking discipline below governs tier-2 and tier-3 asks alike: a candidate list still leads
-   with your recommendation and its strongest counter-consideration — "pick one" without a
-   recommendation is a menu, not a briefing.
-
-**The tier-1/tier-2 line is drawn by what is already resolved, not by temperament.** If you can name
-the exact command and its complete argument — nothing left to invent, no competing candidate — the
-intent *is* unambiguous: that is tier 1, route it. Asking "did you mean" while displaying the
-fully-formed command is the retype ceremony ADR-0022 abolished, returned as a question. Tier 2
-exists for a genuinely incomplete reading, and for the destructive set below — nothing else.
+Select by requested outcome and active workflow state, not by command spelling. Keep the three
+routing tiers (ADR-0022), distinguishing uncertainty about the goal from choice of internal method:
+
+1. **Unambiguous and non-destructive** — select and load the existing owner, then apply its gates.
+   Name the route briefly when doing work; do not ask the user to select or retype it.
+2. **Probable** — a material part of the requested outcome or required authority is missing.
+   Inspect available evidence first, then ask once about that missing fact or decision.
+3. **Genuinely unclear** — use `<plugin-root>/includes/redirect.md` to ask about the intended
+   outcome. Offer meaningful alternatives, not a compulsory command menu.
+
+**Multiple reasonable internal methods are not ambiguous user intent.** Choose among them within
+safety-core's decision-authority limits. A second plausible route alone is not a reason to ask.
+Do not invent a product decision, resolve a `[CONFIRM-NN]`, or assume missing authorization.
+
+**Questions are not mutation authority.** Explain a commit without creating one; draft a commit
+message without staging or committing when asked to draft only. A question about whether to add a
+feature is not an implementation request. Conversely, "can you commit these changes?" can request
+an action: classify the intended outcome and explicit restrictions, not punctuation alone. Use
+read-only evidence gathering for answers; do not select a procedure's writing close by accident.
+
+**Load the owner, not another ceremony.** Direct skill/resource references may replace a redundant
+entry hop only when its arguments, modes, prerequisites, and gates are preserved. If the wrapper
+owns distinct behavior, load it too. A description is a discovery hint, never the complete procedure.
+Keep private procedures path-loaded and avoid bulk context reads. Respect the active call extent:
+return a scoped result, forward a completed authorized stage, or branch for an allowed prerequisite.
+Neither universal return-to-caller nor unconditional commit-to-PR is correct.
 
 **Clarity and risk are separate axes.** Tier 1 requires BOTH unambiguous intent AND a non-destructive
 command. Anything irreversible or gate-bypassing drops to tier 2 and asks, even when the intent is
@@ -134,18 +128,12 @@ A deterministic mode-token flip (`mode --dangerous`, `mode --ops`) is friction,
 not in this set — ADR-0030 supersedes ADR-0022's tier-2 confirmation clause for dangerous-mode entry
 alone; the other four members are unchanged.
 
-**When a decision is the user's, ask it — fully, once.** Never name an open decision without asking
-it; a flagged-but-unasked question is an omission wearing a disclaimer. Lead every ask with your
-recommendation AND the strongest consideration against it — a bare recommendation anchors; the
-counter-case is what makes the choice real. Batch independent questions into one round. Safety-core's
-decision-authority rule governs which parameters are yours to decide alone; an uncertain
-classification is still a fork, and forks are asked.
+**Ask user decisions fully, once.** Give a recommendation and its strongest counter-consideration;
+batch independent questions. Ask for missing outcomes, facts, or authority, not internal methods.
 
-**What remains prohibited is performing the work instead of routing it.** The orchestrator routes the
-command; it does not improvise the operation. When no command owns an operation, that is a
-routing gap to surface.
+The orchestrator does not improvise unowned operations: surface a routing gap, never an override.
 
-**`/ca-btw "question"`** is the lightweight Q&A exception: answer and return, no state change.
+**`/ca-btw "question"`** remains an explicit Q&A convenience, not a prerequisite for asking.
 
 ---
 

package/plugins/ca-pi/hooks/_host.py

@@ -11,7 +11,7 @@ import hostapi  # noqa: E402
 class PiHost(hostapi.Host):
     name = "pi"
     adapter_name = "@arbiterforge/ca-pi"
-    adapter_version = "0.14.8"
+    adapter_version = "0.14.9"
     update_target = "ca-pi"
     update_tag_prefix = "ca-pi-v"
     update_command = "pi update npm:@arbiterforge/ca-pi"

package/plugins/ca-pi/hooks/hostapi.py

@@ -313,7 +313,7 @@ class Host:
 
     name = "claude"
     adapter_name = "ca"
-    adapter_version = "2.21.8"
+    adapter_version = "2.21.9"
 
     # Update-notifier descriptor. Each independently versioned host overrides
     # these three values in its per-plugin _host.py. Keeping the target,

package/plugins/ca-pi/includes/redirect.md

@@ -1,80 +1,49 @@
 # Redirect
 
-Canned messages for §6 **tiers 2 and 3** — when a direct off-channel instruction is *not* both
-unambiguous and non-destructive. Loaded only when needed.
+Clarification support for §6 **tiers 2 and 3**, loaded only when the intended outcome, a material
+fact, or required authority is unresolved. Tier 1 does not use this file: select the existing
+owner and preserve its gates without asking the user to retype or approve an internal route.
 
-Tier 1 does not use this file at all. An unambiguous, non-destructive intent is routed directly into
-its command with a one-line statement of the route (ADR-0022): naming the command and then asking the
-user to type it back is ceremony, not governance.
+## Tier 2 — probable intent, or a required destructive confirmation
 
-Match the channel to the *phrasing*, not just the topic. An interrogative is a question, not a build
-request: "add a healthcheck endpoint" is tier 1 into `/ca-feature`, while "should we add a
-healthcheck?" is tier 1 into `/ca-btw`, and "do my ADRs conflict?" is tier 1 into
-`/ca-reconcile`. A question pulled into the heavy spec lane is a misroute.
+Inspect available context before asking. A second plausible implementation method is not a missing
+user decision. Ask about the missing outcome or fact, with a recommendation and its strongest
+counter-consideration; do not ask the user to select a command that expresses an understood request.
 
-## Tier 2 — probable intent, or an unambiguous but destructive one
+For irreversible or gate-bypassing operations, obtain the existing confirmation even when intent
+is clear: `/ca-override`, merge to the default branch, branch or worktree deletion, and release
+and tag publication. Name the exact operation and target, state the consequence, then ask for its
+confirmation. A generic approval of a route is not authority for an unspecified destructive action.
+A deterministic mode-token flip is not in this set; its existing mode contract still applies.
 
-One question, naming the command. The user approves; they do not retype.
+## Tier 3 — genuinely unclear outcome
 
-```
-That reads as <inferred intent> → <$ca- skill, prefilled with the user's own words>
+Ask one focused question after checking the available evidence:
 
-Run it? Its own gates still apply.
-```
+> The missing decision is <outcome or constraint>. I recommend <option> because <reason>;
+> <strongest counter-consideration> favors <alternative>. Which outcome is intended?
 
-Use this — not tier 1 — whenever the command is irreversible or gate-bypassing, however clear the
-intent: `/ca-override`, merge to the default branch, branch or worktree deletion, release and tag
-publication. There the confirmation is the gate, not friction. (A deterministic mode-token flip is
-friction, not a gate, which is why `mode --dangerous`/`mode --ops` entry is not in this set — see
-`includes/ops-mode.md` and `includes/dangerous-mode.md`.)
+When even the intended task is unknown, ask what result the user wants. Do not repeat a command
+catalog when the user restates the goal in ordinary language. Resolve the actual uncertainty and
+then select the owner; lack of slash syntax is not itself uncertainty.
 
-## Tier 3 — genuinely unclear
+## Questions and restricted requests
 
-```
-codeArbiter routes work through commands, so every change clears its gates
-and lands on the audit trail. This one could go a few ways:
-
-<up to three prefilled $ca- skills, closest first>
-
-Or pick a channel:
-→ Start a new project:      /ca-decompose
-→ Start a feature:          /ca-feature "describe it"
-→ Ask a question:           /ca-btw "your question"
-→ Fix a bug:                /ca-fix "describe it"
-→ Bypass with audit trail:  /ca-override "reason"
-→ See everything open:      /ca-status
-→ See all commands:         /ca-commands
-```
-
-When no intent is inferable at all, drop the candidate lines and lead with the channel list.
-
-## Repeat — user insists off-channel after tier 3
-
-```
-Still need a channel for this one. Closest matches first:
-<up to three prefilled $ca- skills>
-
-Full list:
-/ca-decompose  /ca-create-context  /ca-feature  /ca-sprint  /ca-fix  /ca-refactor  /ca-debug  /ca-chore  /ca-spike
-/ca-commit  /ca-pr  /ca-watch  /ca-review  /ca-checkpoint  /ca-release  /ca-add-dep
-/ca-threat-model  /ca-adr  /ca-adr-status  /ca-reconcile  /ca-conflict
-/ca-init  /ca-status  /ca-metrics  /ca-audit  /ca-preview  /ca-doctor  /ca-standup  /ca-cleanup  /ca-task
-/ca-new-skill  /ca-btw  /ca-commands
-Or /ca-override "reason" to proceed anyway with an audit entry.
-```
+Use the requested outcome, not punctuation alone. "Explain this commit" and "draft the message,
+but do not commit" authorize no staging, commit, task-board write, or other persistent mutation.
+"Can you commit these changes?" can request an action; it still needs its owning gate. Answer an
+informational question directly using read-only evidence as needed. If a relevant procedure has a
+writing terminal step, do not enter that step for a report-only request.
 
 ## Never
 
-A missing owner is a **routing gap**, not an override case. When no command owns the operation, say
-so and surface the gap — never steer the user toward `/ca-override` to get past a coverage hole.
-That substitution is exactly what issue #308 recorded: a routine post-merge cleanup routed first to
-`/ca-chore`, which does not accept it, and then to `/ca-override`, which exists to be rare.
+A genuinely missing owner is a **routing gap**, not an override case. Surface the precise missing
+capability; never steer the user toward `/ca-override` to get past a coverage hole. Do not invent
+an ungoverned procedure, resolve a `[CONFIRM-NN]`, or broaden scope merely to avoid asking.
 
 ## Exception — local runtime work
 
-`npm run dev` and its kin have no owning command; in `arbiter` mode that is the routing gap above,
-surfaced in one line. The runtime-operations token `mode --ops` narrows exactly that gap and no
-other: once active, an operation that starts, observes, or exercises a running system and leaves no
-change in tracked files or git history is performed in-channel, named in one line as it is taken —
-see `includes/ops-mode.md`. Anything that mutates tracked files, the index, git history, or
-published state is still a routing gap, `ops` or not.
+The existing `mode --ops` contract in `<plugin-root>/includes/ops-mode.md` owns local runtime
+work that leaves tracked files and Git history unchanged. In `arbiter` mode, a runtime operation without an owner remains a routing gap;
+this clarification card does not select or activate another mode. Tracked-file, index, Git-history,
+and published-state mutations still require their ordinary governing workflow, `ops` or not.

package/plugins/ca-pi/includes/routing-table.md

@@ -1,10 +1,12 @@
 # Routing table
 
-Loaded on a scope-touch or `/command`, not every turn. This table is the authoritative trigger→route
-surface and destructive-operation registry: it answers *what to invoke or route given a trigger* and
-*which operations always require tier-2 confirmation*; for *what doc to read before touching a scope*,
-use `reference-map.md`. Follow the primary route; the gate is a hard stop, not a suggestion. A command
-is **invoked**; the orchestrator **routes** to a skill; a skill **dispatches** an agent.
+Loaded when a scope-touch or route needs it, not every turn. This table is the authoritative
+intent-to-owner surface and destructive-operation registry. Invocation cues are examples, not
+required user syntax. For the governing document on a scope-touch, use `reference-map.md`.
+Select the existing owner and preserve its prerequisites, modes, and gates; a direct resource
+reference does not discard behavior owned by its command wrapper. A gate blocks advancement until
+its exit condition is satisfied; routing never authorizes a bypass. Informational requests use
+read-only behavior, not a writing close. The orchestrator routes; a skill dispatches an agent.
 Routing to a skill means loading its body from `<plugin-root>/routines/<name>/SKILL.md` — a route
 cell names the skill; this path convention locates it. That resolution never depends on the host's
 skill registry: a chain-internal skill hidden from the registry (`disable-model-invocation`) is

package/plugins/ca-pi/includes/safety-core.md

@@ -4,7 +4,8 @@ dangerous, ops) at injection time; never injected alone. -->
 # Safety core
 
 **Precedence.** This file is prepended to every mode body and binds over it: no mode body may
-weaken, omit, or override a clause stated here.
+weaken, omit, or override a clause stated here. Command names identify their governing procedure;
+natural-language routing preserves that procedure and its attribution and confirmation requirements.
 
 **Section numbers are a public interface.** The enforcement hooks fire identically in every
 mode and their block messages cite a `§N` from this file directly, so the numbering below must
@@ -59,9 +60,12 @@ preflight to the exact fetched base and PR head. Preserve a required true merge
 `--match-head-commit`; green CI cannot substitute for source ancestry. Missing evidence blocks the
 offer. This check never authorizes the merge itself.
 
-A parameter is yours to decide only when it is reversible, has one sensible answer, and is
-recorded where the user will review it — an uncertain classification is a fork, and forks are
-asked.
+Within already-authorized scope, choose reversible implementation parameters among reasonable
+approaches and record material choices where the workflow requires. Multiple reasonable methods
+alone do not require a user decision. This does not grant initial scope approval, resolve a
+`[CONFIRM-NN]`, invent a product requirement, or expand provider, spending, data-disclosure, or
+publication authority. When an unresolved choice changes the authorized outcome or requires
+additional authority, ask. The irreversible-action confirmations above remain mandatory.
 
 ---
 

package/plugins/ca-pi/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@arbiterforge/ca-pi",
-  "version": "0.14.8",
+  "version": "0.14.9",
   "private": true,
   "license": "AGPL-3.0-only",
   "type": "module",

package/plugins/ca-pi/routines/INDEX.md

@@ -17,7 +17,7 @@ Skill bodies load on routing only. This index is the surface scan; never bulk-re
 | [brainstorming](brainstorming/SKILL.md) | `/feature` (front), `/sprint` planning | Socratic idea→spec: split bundles, shape the approach, then decide parameters / ask forks in full; adversarial self-review before approval; writes new full-lane `specs/<slug>.html` through the installed engine while preserving existing Markdown authority. Its acceptance criteria become `tdd` obligations. Hard-gate: no code until the spec is approved. |
 | [writing-plans](writing-plans/SKILL.md) | `/feature`, `/sprint` (after the spec) | Decomposes an approved spec into small tasks, each with a path + a verification that maps to a `tdd` obligation; writes a same-format plan with bijective criterion↔task coverage (`.html` by default, `.md` for an existing Markdown spec). |
 | [executing-plans](executing-plans/SKILL.md) | `/feature` | Checkpoint coordinator — groups tasks into batches, delegates each to `subagent-driven-development` (fresh author agent per task, full review chain), stops for user acknowledgement between batches. |
-| [subagent-driven-development](subagent-driven-development/SKILL.md) | `/sprint` (engine), `executing-plans` (batch scope) | Fresh subagent per task → spec-compliance then quality review → fresh-run verification; accepts only on proof. Hard-stops on `tdd` BLOCK, security CRITICAL, `[CONFIRM-NN]`. |
+| [subagent-driven-development](subagent-driven-development/SKILL.md) | `/sprint` (engine), `executing-plans` (batch scope) | Fresh subagent per task → spec-compliance then quality review → fresh-run verification; accepts only on proof. A quality failure blocks acceptance; approved sprint recovery owns correction. Security CRITICAL and unresolved `[CONFIRM-NN]` remain stops. |
 | [dispatching-parallel-agents](dispatching-parallel-agents/SKILL.md) | `subagent-driven-development`, `/sprint`, parallel `/review` | Reusable fan-out primitive: bound concurrency, collect, dedupe, funnel through `finding-triage`→`verdict-aggregator`. Results unused until the read-only funnel runs. |
 | [finishing-a-development-branch](finishing-a-development-branch/SKILL.md) | `/feature`, `/sprint` (terminal) | The terminal step after `commit-gate`: open-PR / merge-via-PR / discard. No direct-to-main, no force-push; `/sprint` auto-selects open-PR and never merges. |
 | [using-git-worktrees](using-git-worktrees/SKILL.md) | `subagent-driven-development`, `dispatching-parallel-agents` (opt-in) | OPTIONAL per-unit filesystem isolation for parallel work; integrates accepted units back onto the caller's working branch for its single `commit-gate` + finish. Never the default path. |

package/plugins/ca-pi/routines/subagent-driven-development/SKILL.md

@@ -47,8 +47,11 @@ loop processes only those tasks (in their internal dependency order). When `scop
 ## Phase 1 — Task selection · gate: BLOCK
 
 Pull the next unblocked task from the plan in dependency order. When a `scope` was passed, restrict
-selection to tasks in that list. A task is one verifiable unit of work with a path set, a spec
-obligation, and a verification command.
+selection to tasks in that list. For Markdown, select only a task whose status is `PENDING` and whose
+dependencies are `ACCEPTED`; `BLOCKED` tasks are not selectable until the owning plan workflow
+records a supported transition. For HTML, accept only tasks returned by `eligible` for the exact
+selected plan identity. A task is one verifiable unit of work with a path set, a spec obligation,
+and a verification command.
 
 For HTML, select only a task returned as eligible for the exact selected plan
 identity. Follow contextual `read` pages to completion, retain their context
@@ -62,7 +65,9 @@ and a fresh complete context ticket. A task in `REVIEW` is not accepted on
 resume; obtain fresh evidence when required and finish the current combined
 scope review before `accept-scope`.
 
-- Confirm every dependency task is `ACCEPTED` before selecting.
+- For Markdown, confirm every dependency task is `ACCEPTED` before selecting.
+- For HTML, use the engine's eligibility and current evidence; do not replace its same-checkpoint `REVIEW` rule
+  with the legacy `ACCEPTED` sentence or infer eligibility from a displayed status.
 - Confirm no unresolved `[CONFIRM-NN]` blocks the task. One that does halts the loop — see Hard rules.
 
 Gate: exactly one task selected, dependency-clean, with its spec obligation and verification command in hand.
@@ -93,8 +98,10 @@ The subagent works test-first by routing through the `tdd` skill (`<plugin-root>
 `tdd` Phase 1. Brief it with the task's path set, its spec obligation, and its verification command.
 Nothing else from prior tasks leaks in.
 
-Gate: the subagent reports `tdd` complete — all six phases green. A `tdd` BLOCK halts the loop; do not
-re-dispatch around it.
+Gate: all six `tdd` phases must be green before acceptance. Never redispatch merely to evade a failing gate.
+Under an approved `/sprint`, an ordinary implementation/test failure routes to **Recovery within the approved sprint** in `<plugin-root>/SPRINT.md`; rerun the original gate after an evidence-led correction.
+An attended invocation returns the blocked prerequisite to its caller. A real authority or security block
+halts the affected work and is surfaced under the hard rules, in either mode.
 
 ## Phase 3 — Spec-compliance review · gate: BLOCK
 
@@ -137,7 +144,9 @@ plus `coverage-auditor` (already run in `tdd` Phase 4) — record that and proce
 - A security CRITICAL finding halts the loop — see Hard rules.
 - A HIGH finding returns the offending task(s) — attributed by file — to Phase 2; the scope's
   quality review re-runs over the corrected combined diff.
-- MEDIUM and LOW findings are recorded; the user decides whether they block.
+- MEDIUM and LOW findings are recorded; the active caller owns their disposition. Under an approved
+  `/sprint`, use its existing delegated decision rules rather than adding a per-finding user checkpoint.
+  In attended execution the user retains that decision; mandatory project policy still applies.
 
 Gate: no CRITICAL, no HIGH across the scope's combined diff. Nothing in the scope is `ACCEPTED`
 until this passes.
@@ -182,7 +191,10 @@ Gate: every task in the current scope `ACCEPTED`, the suite green, ready for the
 - MUST NOT write implementation code before the task's `tdd` Phase 1 completes.
 - MUST accept a task only when both reviews pass AND verification passes on a fresh run.
 - MUST NOT accept a task on a subagent's self-report — run the verification command and read its exit code.
-- MUST halt and surface to the user on a `tdd` BLOCK, a security CRITICAL finding, or an unresolved `[CONFIRM-NN]` inside the loop — and on a `commit-gate` failure at the finish handoff — even under `/sprint`. These never auto-proceed.
+- MUST halt and surface a real authority or security block, including security CRITICAL findings and
+  unresolved `[CONFIRM-NN]` decisions. Ordinary TDD/verification failures and finish-time stale proof
+  under an approved sprint take Recovery within the approved sprint in `<plugin-root>/SPRINT.md`.
+  A failed gate never auto-passes, and recovery never grants missing commit authority.
 - MUST NOT commit — hand the accepted branch to `commit-gate`.
 - MUST mark out-of-scope findings with an inline `[NEEDS-TRIAGE]` marker and never act on them inside the task.
 - MUST NOT invoke `farm.js` before writing `meta.model` into `plan.json` (or setting `FARM_MODEL`) — the dispatcher fails loudly otherwise.