@arbiterforge/ca-pi 0.14.9 → 0.14.12

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

@@ -79,10 +79,11 @@ python "<plugin-root>/hooks/_approvallib.py" cancel --root "<project-root>" --ar
 ```
 
 Cancellation records no authority. Other workflow authorities must use their
-corresponding host-owned adapters; never call `capture` with request-authored
-`authority_kind`, verdict, actor, or source-text labels, and never create an
-authority source merely to satisfy an artifact transition.
-`capture` does not change approval state. `approve` checks the resulting receipt
+corresponding host-owned adapters. Legacy `capture` events remain readable for
+inventory but are inspection-only: the engine refuses to wrap them in a current
+receipt. Current authority requires `capture-observation` over a closed producer
+profile and engine-issued evidence context; never create an authority source
+merely to satisfy an artifact transition. `approve` checks the resulting receipt
 against current ready content. A missing or changed receipt, captured event, or
 still-present policy source returns `AUTHORITY_UNVERIFIED`. Receipt format 0.1.0
 remains readable for inspection after upgrade but is not authority-bearing; the
@@ -91,11 +92,20 @@ approval, dispatch, acceptance, commit proof, or finalization. This is the
 repository's cooperative same-user attestation model, not cryptographic identity
 proof or protection from an unrestricted same-user filesystem writer.
 
-Create a plan as `draft_preview`, consume existing criterion IDs, then `plan-bind`
-to the approved spec. Approve the plan through the applicable existing workflow.
+For ordinary sequential planning, create a plan as `draft_preview`, consume existing criterion IDs,
+then `plan-bind` to the approved spec and approve the plan through its existing workflow. Initial
+combined HTML sprint review uses the explicit paired path below instead of separate approvals.
 A normative change invalidates its approval. Rebinding is explicit and preserves
 history; it does not waive coverage or permit silent reinterpretation.
 
+## Initial sprint pair and delegated methods
+
+Only when preparing initial combined approval, replaying an observed reply, or revising a task's
+method under its existing grant, load `<plugin-root>/includes/sprint-authority.md`. That private
+card owns the `arm-sprint` / `resume-sprint` / `smarts` bridge and the native pair/method operations.
+Do not bulk-load it for ordinary task reads. Scoring is not consent; the initial observed user reply,
+protected scope, real producer, current evidence and existing security/permission gates remain required.
+
 ## Reading and dispatch
 
 Use `index`, then `outline`, then symbol-scoped `read`. Exact reads are explicitly
@@ -147,8 +157,8 @@ python "<plugin-root>/hooks/_prerequisitelib.py" supersede --root "<project-root
 ```
 
 The adapter fixes `authority_kind: user_workflow` and `verdict: satisfied`;
-there is no caller-selected authority or bulk-satisfaction path. SMARTS remains
-unsupported until a real policy-owned SMARTS decision producer exists. Pi has no
+there is no caller-selected authority or bulk-satisfaction path. SMARTS prerequisite satisfaction remains unsupported; the plan-method producer below does not
+grant prerequisite, security, backend or publication authority. Pi has no
 qualified pre-model prompt seam and must remain blocked. Do not infer eligibility from one satisfied prerequisite:
 rerun `eligible`, and resolve each remaining record independently against the
 new current plan identity.
@@ -161,10 +171,87 @@ verification and spec review. Across checkpoints, dependencies require accepted
 scope evidence. Provisional progress never counts as completion.
 
 The orchestrator executes the declared verification through its existing governed
-execution tool, captures actual named-test outcomes and output hashes, and obtains
-a separate spec review. `task-review` records those receipts. After every task in
-the scope reaches `REVIEW`, reverify against one current source snapshot, review
-the combined scope, and use `accept-scope` once. Do not accept tasks individually.
+execution tool through the installed production authority adapter; it never
+constructs a successful workflow event itself. Arm an exact task request first.
+Verification and review authority below is currently Codex-only. On Claude or
+Pi, stop at this boundary rather than treating model-authored results as
+authority; their installed prompt approval seams do not imply verification or
+review support.
+Every distinct `cwd` label in the engine context must be mapped once to an exact
+linked Git worktree root. Mapped worktrees must share the artifact repository's
+Git common directory, and the adapter freezes their filesystem identity, HEAD,
+status digest, effective argv, and executable bytes:
+
+```sh
+python "<plugin-root>/hooks/artifact-authority.py" arm --root "<project-root>" --artifact-id <plan-id> --record-id <task-id> --activity verification --workspace "candidate worktree=<absolute-worktree>" --workspace "baseline-evidence worktree=<absolute-worktree>"
+```
+
+Use only the mappings actually named by that task; missing or extra labels fail
+closed. Run the returned request through one plain governed exec invocation (no
+compound shell expression), then publish only after the host's matching
+`PostToolUse` has corroborated the wrapper's completed request-bound result:
+
+```sh
+python "<plugin-root>/hooks/artifact-authority.py" verify --root "<project-root>" --request-id <request-id>
+python "<plugin-root>/hooks/artifact-authority.py" publish --root "<project-root>" --request-id <request-id>
+```
+
+The verifier launches exact engine-declared argv without a shell, supervises the
+whole process tree, bounds output, requires exact named outcomes, and rejects
+workspace or executable drift. If an attempt is interrupted, use the adapter's
+`recover` operation to retain it as failed or abandoned; never rerun an uncertain
+attempt under the same request.
+
+For `spec_review` or `quality_review`, arm the corresponding activity without
+workspace mappings and dispatch the returned `launch_envelope` unchanged to one
+fresh host subagent. The Codex hooks bind the exact spawn call, child start and
+child stop; a pasted or coordinator-authored decision is not review authority.
+Publish the completed request through the same `publish` command. `task-review`
+records the separate verification and spec-review receipts. After every task in
+the scope reaches `REVIEW`, reverify against one current source snapshot, run the
+combined quality review, and use `accept-scope` once. Do not accept tasks
+individually.
+
+An interrupted or `BLOCKED` HTML task never resumes by editing its status. Arm
+the installed reconciliation adapter for the exact task or scope, present its
+returned reply verbatim, and let `UserPromptSubmit` capture and apply the observed
+user decision across repositories:
+
+```sh
+python "<plugin-root>/hooks/artifact-reconcile.py" --root "<project-root>" --artifact-id <plan-id> --target-id <task-id> --operation task-reconcile --target-state PENDING --reason "<reviewed reason>" --assessment "<reviewed assessment>"
+python "<plugin-root>/hooks/artifact-reconcile.py" --root "<project-root>" --artifact-id <plan-id> --target-id <checkpoint-id> --operation scope-reconcile --assessment "<reviewed assessment>"
+```
+
+Ambiguous armed requests, changed identities, stale inputs, wrong replies, or a
+foreign Git repository all fail closed. Re-run `eligible` after reconciliation;
+the prompt reply itself is not proof that the lifecycle mutation committed.
+If a mutation response is lost, submit the same exact reply again: the adapter
+replays its durable operation ID and receipt without recapturing authority. A
+request that has not reached mutation can be cancelled with:
+
+```sh
+python "<plugin-root>/hooks/artifact-reconcile.py" --root "<project-root>" --artifact-id <plan-id> --cancel --prompt "<exact returned reply>"
+```
+
+If a crash left a complete pending request before its prompt route was
+registered, use this command instead. It refuses an active route or any
+in-flight mutation:
+
+```sh
+python "<plugin-root>/hooks/artifact-reconcile.py" --root "<project-root>" --artifact-id <plan-id> --cancel-orphan
+```
+
+If a durable mutation attempt exists, neither cancellation path can clear it.
+Replay the exact stored operation and receipt under the reconciliation lock:
+
+```sh
+python "<plugin-root>/hooks/artifact-reconcile.py" --root "<project-root>" --artifact-id <plan-id> --recover
+```
+
+Recovery clears the request only on a committed replay or a closed-set engine
+result proving no commit (`REVISION_CONFLICT` or `OPERATION_ROLLED_BACK`). Other
+errors retain it for investigation. Re-arm only after cancellation or recovery
+succeeds; a committed recovery is not permission to repeat the mutation.
 
 `IN_PROGRESS` after interruption requires reconciliation, not automatic completion.
 `REVIEW` requires fresh evidence. Source changes stale proof; state/branding updates

package/plugins/ca-pi/includes/sprint-authority.md

@@ -0,0 +1,69 @@
+# Sprint approval and delegated method authority
+
+This private extension adds no registered command, skill or agent. Check that the verified installed
+native capability lists `sprint-approval-context`, `sprint-approve` and `smarts-apply`; a schema name
+or model-written event is not an implementation. Qualified exact-prompt host observation remains
+Claude Code or Codex only. Pi must not arm it without a real pre-model prompt seam. Other existing
+host-specific verification/review restrictions are unchanged.
+
+Prepare the complete ready same-slug spec and plan as unapproved drafts. The private planner
+preflight accepts `draft_for_pair: true` only for a full-lane initial sprint, never `/feature`, an
+existing approved pair, or an execution shortcut. Keep its `draft_preview` binding until the paired
+transaction. Run scope/criterion coverage, recorded-intent and adversarial review on both drafts.
+Present the optional plan-method delegation in the review packet before arming:
+
+```sh
+python "<plugin-root>/hooks/_approvallib.py" arm-sprint --root "<project-root>" --spec-id <spec-id> --plan-id <plan-id> --delegate-methods
+```
+
+Omit `--delegate-methods` for approval without delegated plan-method changes. Show the returned
+`reply` verbatim. It explicitly names both IDs, `delegate-methods` or `approve-only`, and the nonce.
+An ordinary yes, wrong nonce/mode or changed member does not approve either. `sprint-approve`
+recomputes both model/revision identities and the projected binding, verifies both observations
+from the same actual reply, and commits the two approvals through the existing native journal.
+It produces separate bound receipts and an optional `grant_receipt`. No partial approval is visible
+while recovery is required. Generic `capture-observation` and single-artifact `approve` cannot reuse
+these pair events to approve one half. Confirm both current `approved` gates before dispatch.
+
+An interrupted observed submission retains its exact source events, operation ID and both CAS
+identities. Resume it without asking the user to repeat the same decision:
+
+```sh
+python "<plugin-root>/hooks/_approvallib.py" resume-sprint --root "<project-root>" --plan-id <plan-id>
+```
+
+Arming without an observed reply cannot be resumed as authority. Recovery completes only this
+exact observed transaction, not an unrelated pending operation. A committed replay is success;
+a closed-set `REVISION_CONFLICT` or `OPERATION_ROLLED_BACK` proves this mutation did not commit and
+retires only its stale pending request while preserving source history. Changed content needs a
+new genuine approval, not an invented receipt. Other failures retain the request for diagnosis.
+Before observation, the existing `cancel --artifact-id <plan-id>` clears an unapproved arm. After
+submission, resume/recover first; cancellation cannot erase an uncertain transaction.
+
+With an explicit paired user grant, evaluate an existing task-method choice using SMARTS Step 0,
+all six lens verdicts and the actual supporting reasons. Query only the `smarts-apply` request schema.
+Provide the exact current plan `artifact_id`, `expected` revision/model hash, unique `operation_id`,
+original `grant_receipt`, and `decision` with task ID, options, selected index, strength and rationale.
+Each option contains label, steps and the six qualitative verdict/reason cells. There is no new
+numeric threshold, mandatory invented alternative or tie-triggered user interview. Persist the
+bounded JSON request as inert input and invoke the installation-owned bridge:
+
+```sh
+python "<plugin-root>/hooks/_approvallib.py" smarts --root "<project-root>" --request-file <decision-request.json>
+```
+
+The native producer validates the original user grant and current bound spec/plan. Only the selected
+existing task's method `steps` may change. Every path, criterion, test/verification definition,
+prerequisite, dependency, checkpoint, rollback and input policy stays protected. Changes that widen
+this scope or need a different authority use their real owner. The producer does not turn step text
+into shell permission and never grants commit, network/provider, spending, disclosure, publication,
+prerequisite or security authority. Normal execution gates still apply to the chosen method.
+
+An affected `IN_PROGRESS` writer must quiesce before mutation. A successful method change emits an
+actual `smarts_workflow` event/receipt and current plan approval together, invalidates affected
+checkpoint/dependency proof to `PENDING` while preserving `BLOCKED` members and their reasons,
+retains evidence refs as history and requires fresh context,
+verification and reviews. It never accepts work. An identical method needs no new approval; retain
+current evidence rather than manufacturing another attempt. Log material reasoning and record
+citations in the existing sprint audit. Recorded judgments remain model judgments: integrity and
+scope checks do not independently prove their truth or create a malicious-same-user sandbox.

package/plugins/ca-pi/package.json

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

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

@@ -2,7 +2,10 @@
 
 Skill bodies load on routing only. This index is the surface scan; never bulk-read
 `skills/*/SKILL.md`. Each skill is an orchestrator routine with gated phases, routed to, never
-"triggered." This index lists what each skill OWNS; to decide WHERE a trigger routes, load
+"triggered." Command-backed owners `commit-gate` and `skill-author` supply their
+complete public entries at build time. Claude keeps the owner discoverable and the
+command explicit-only; Codex/Pi expose the entry and keep the routine private. Read a needed owner directly or use the complete public body,
+not both merely to repeat the same procedure. This index lists what each skill OWNS; to decide WHERE a trigger routes, load
 `<plugin-root>/includes/routing-table.md` (the authoritative trigger→route surface).
 
 | Skill | Routed to by | Owns |
@@ -14,9 +17,9 @@ Skill bodies load on routing only. This index is the surface scan; never bulk-re
 | [refactor](refactor/SKILL.md) | `/refactor` | Behavior-preserving change behind a parity-coverage proof gate; routes to `tdd` Phase 1 only when new test seams are needed. |
 | [context-creation](context-creation/SKILL.md) | `/create-context` (brownfield) | Back-fills `.codearbiter/` from existing source via parallel scouts; writes `CONTEXT.md` (`arbiter: enabled` + `stage:`) and locks it `<!--INITIALIZED-->`. |
 | [decompose](decompose/SKILL.md) | greenfield startup, `/decompose` | Six-layer senior-architect interview, compaction-resilient via per-layer disk drafts + DRAFT ADRs; populates `.codearbiter/` and locks it initialized. |
-| [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. |
+| [brainstorming](brainstorming/SKILL.md) | `/feature` (front), `/sprint` planning | Caller-scoped feature or coherent sprint specification. Initial approval is user-owned; delegated choices require existing authority. Uses the selected artifact format, preserves recorded intent, and returns or forwards to the caller's required planning step before execution. |
+| [writing-plans](writing-plans/SKILL.md) | `/feature`, `/sprint` (after the spec) | Decomposes the exact approved spec, or a ready draft through the initial sprint-only pair preflight. Retains same-format criterion/task coverage, paths and verification; combined drafts return for one real spec-and-plan reply before execution. Ordinary sequential binding remains unchanged. |
+| [executing-plans](executing-plans/SKILL.md) | `/feature` | Attended coordinator: uses authored HTML checkpoint membership or bounded legacy batches, delegates to `subagent-driven-development`, and retains the user checkpoint. A display batch never changes an HTML acceptance scope; sprint does not inherit these pauses. |
 | [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. |

package/plugins/ca-pi/routines/brainstorming/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: brainstorming
-description: The Socratic spec-refinement front of /feature, and the planning front of /sprint. Routed to BEFORE any code — it takes a one-line idea and drives it to an approved, concrete spec with testable acceptance criteria. Five gated phases — frame, shape, refine, write, review-and-approve. No implementation and no handoff to tdd until the spec is on disk and approved; each acceptance criterion becomes one tdd Phase 1 obligation.
+description: The Socratic spec-refinement front of /feature, and the planning front of /sprint. Routed to BEFORE any code — it turns a one-line idea into a concrete spec with testable criteria, ready for initial combined sprint review or explicit sequential approval. Five gated phases — frame, shape, refine, write, review-and-approve. No implementation before an approved spec; the caller retains required planning, execution and delivery ordering. Each acceptance criterion becomes one tdd Phase 1 obligation.
 disable-model-invocation: true
 ---
 
@@ -23,7 +23,21 @@ structured-artifact engine and default to canonical `.html`. HTML `--farm`
 dispatch remains blocked.
 
 
-Refine the idea before it touches code. Routed to by `/feature` (before `tdd`) and by `/sprint` (the planning front).
+Refine the idea before it touches code. Routed to by `/feature` and `/sprint` as their specification step.
+
+## Caller scope and authority
+
+Read the active caller's workflow, selected lane, scope and existing delegation before refining.
+Initial sprint planning is not an approved sprint: this skill does not grant its own delegation.
+A full-lane feature requires `writing-plans` after spec approval. Initial HTML sprint planning instead
+returns a ready draft identity for the combined spec/plan review before either is approved; a
+subordinate specification step returns its result to the existing caller. Preserve direct handoffs when they
+satisfy that caller's ordering, not an unconditional terminal route to implementation.
+
+A sprint may contain several related features under one coherent goal. Keep their boundaries and
+criteria explicit without converting the sprint into repeated feature interviews. Parameter and
+method choices follow safety-core; material product decisions and missing authority are not inferred.
+No new registered surface, runtime state or copied procedure is needed for this call contract.
 
 ## Pre-flight
 
@@ -41,7 +55,9 @@ when the feature touches component boundaries or integrations). Index-first, nev
 A missing file or directory here is NOT a gap to surface and never a STOP: record
 `intent: silent — no decomposition record` in the running notes and proceed.
 
-Per-feature and light. NOT decompose's whole-project six-layer interview — one feature, five phases. Depth scales with the feature, not the ceremony: a small feature earns a short pass through every phase, never a skipped one. A spec can be five sentences; it cannot be zero — smallness changes the spec's length, not its existence.
+Scope-sized and light. NOT decompose's whole-project six-layer interview — five phases for the
+caller's feature or coherent sprint. Depth scales with that scope, not the ceremony. The deliberately
+inline small-feature lane remains owned by `/feature`; do not manufacture an HTML pair for it.
 
 ## Phase 1 — Frame the problem · gate: BLOCK
 
@@ -52,52 +68,74 @@ Take the one-line idea and pin its boundaries before designing or asking anythin
 - Name what this feature explicitly does NOT do — the boundary that keeps scope honest.
 - Check the framing against `CONTEXT.md`: it never contradicts the NOT-building list or redefines domain vocabulary. A contradiction is a conflict — surface it, do not reconcile it silently.
 - Check the framing against the recorded intent (pre-flight, when present): an idea that resurrects a capability `plans/02` records as deferred, or that duplicates a backlog item, is a fork to ask — lead with the recorded deferral rationale and your recommendation; never proceed on it silently (ADR-0025).
-- **Split before you spend.** If the idea bundles more than one independently shippable concern — distinct callers, acceptance criteria that would partition into disjoint sets, separable data or surfaces — say so NOW and negotiate the split with the user before any refinement effort is spent on one piece. Each surviving piece is its own spec and its own run of this skill. A bundle discovered in Phase 4 has already wasted every question asked about the piece that gets cut.
+- **Respect the caller's unit of work.** For a feature, split unrelated independently shippable
+  concerns before refining them; record the selected piece and its exclusions. For a sprint, retain
+  related features within the stated sprint goal and identify their separable criteria and dependencies
+  for planning. Do not force one new user interview per feature or silently absorb unrelated work.
+  Ask only when the intended scope or necessary product decision remains unresolved.
 
-Gate: problem, caller, and out-of-scope boundary stated and consistent with `CONTEXT.md`, and the idea is confirmed to be ONE feature — or the split is agreed and this run proceeds on exactly one piece.
+Gate: problem, caller, and out-of-scope boundary stated and consistent with `CONTEXT.md`; the unit is
+the caller's selected feature or coherent sprint, with unrelated scope explicitly excluded.
 
 ## Phase 2 — Shape the approach · gate: BLOCK
 
 Before drilling into details, establish WHICH design the details belong to:
 
-- Propose the genuine candidate approaches — usually two or three — each with its real trade-off stated (`X gives you A but costs B`). Recommend exactly one, with the reasoning that picks it. The user chooses under `/feature`; under `/sprint`, SMARTS chooses and the choice is logged with its scoring.
+- Propose the genuine candidate approaches — usually two or three — each with its real trade-off stated (`X gives you A but costs B`). Recommend exactly one, with the reasoning that picks it. The user rules on material product decisions during initial feature or sprint planning; within an already-approved sprint, its existing delegated decision rules apply and the choice is logged. A recommendation made before approval does not authorize execution.
 - **Never manufacture alternatives.** When only one sane approach exists, say so and say why — a padded list of straw options is noise wearing the costume of rigor, and it trains the reader to skim the one section that matters.
 - **Check each candidate against accepted ADRs** (the pre-flight index; ADR-0025). A contradicting candidate is surfaced WITH the ADR citation, never silently dropped — and it may not be recommended except paired with a supersession fork via `/adr`. When the contradicting candidate is the only sane approach, that IS the fork: present it (the user rules under `/feature`; under `/sprint` this surfaces at the interactive Phase 1 gate, where the user is present to rule).
 - Apply the isolation lens to the recommended shape while it is still soft: can each part be understood without reading its internals, and can its internals change without breaking its consumers? A design that fails this here fails it again in review, after the code exists.
 - Apply the YAGNI lens: strike anything the Phase 1 problem statement does not demand. A capability the caller never asked for is scope creep with a head start.
 
-Gate: one approach chosen (user-chosen, or SMARTS-chosen and logged), its trade-off stated, and nothing in it the problem does not require.
+Gate: one approach selected under the caller's existing authority and recorded with its trade-off;
+nothing in it exceeds the stated problem. Selection during initial planning is not execution authority.
 
 ## Phase 3 — Socratic refinement loop · gate: BLOCK
 
 Turn the chosen approach concrete. The discipline is decide-or-ask, never drift:
 
-- **Decide the parameters; ask the forks.** A parameter-level choice — a naming, a default, a threshold, an ordering with one sensible answer — is yours to make: decide it and record it in this phase's running notes; every recorded decision lands in the spec's **Decided parameters** section when Phase 4 writes the file, which is where the user reads them at approval. A genuine fork — a real trade-off, a scope boundary, anything irreversible or user-visible — is the user's: ask it IN FULL the first time, leading with your recommendation and its reasoning. Never merely mention that an open decision exists; a named-but-unasked question is an omission wearing a disclaimer.
+- **Choose methods; ask missing decisions.** Select reversible parameters and implementation methods
+  within safety-core's decision-authority limits; multiple reasonable methods alone do not require a
+  user choice. Record material decisions in the running notes and the spec's **Decided parameters**.
+  Use the existing delegated decision rules only where the approved sprint covers the choice. A
+  missing product decision, unresolved `[CONFIRM-NN]`, scope expansion or irreversible operation is
+  not a method choice: ask the actual question with its recommendation and counter-consideration.
 - **Batch what is independent.** Forks whose answers do not depend on each other are asked together, not serialized into rounds. One round of three real questions beats three rounds of one.
 - Run every answer through three lenses:
-  - **Vague language** — force concrete nouns, numbers, and verbs. "Manage", "handle", "support" are not verbs. "Fast", "secure", "scalable" are not specifications. "We'll figure it out later" is not an answer — every "later" becomes a `[CONFIRM-NN]`.
+  - **Vague language** — make the required outcome observable: "fast", "secure" and "scalable"
+    need acceptance boundaries. Only unresolved product requirements or missing user-owned decisions
+    become `[CONFIRM-NN]`; a reversible implementation detail deliberately left to planning within
+    the agreed constraints is not an unanswered user question. Do not invent unknowns to fill a template.
   - **Hidden complexity** — name what the user assumes is easy but is hard: state, concurrency, edge cases, failure modes, validation, idempotency, migration of existing data. Surface it now or it surfaces in `tdd`.
-  - **Trade-off forcing** — when a real decision exists, frame it with a recommendation and let the user rule. Do not pick for the user; do not hide that a pick exists.
-- **The loop has a breaker.** When refinement stops converging — an answer contradicts an earlier one, or the same fork resurfaces after being answered — STOP the loop: restate the contradiction plainly, force one adjudication (a user ruling, or a recorded `[CONFIRM-NN]`), and only then continue. A loop that circles is not being thorough; it is failing to close.
+  - **Trade-off forcing** — identify the actual choice and its counter-consideration. Apply the caller's existing authority: ask material user-owned decisions, or choose and log an authorized delegated method. Never hide a choice or widen delegation.
+- **The loop has a breaker.** When refinement stops converging, stop repeating the same question or
+  hypothesis. Reuse an applicable recorded ruling; within delegation, diagnose and choose a different
+  evidence-supported method. A genuine unresolved user decision or rule conflict is surfaced once
+  through its owner, never guessed or treated as permission. Do not manufacture `[CONFIRM-NN]` for
+  the agent's internal choice of method.
 - **Closure is a checklist, not a feeling.** The reasons to stop asking that do not count, each with why:
   - *"The feature is simple enough."* — Simplicity shortens the spec; it does not waive it. The five-sentence spec still names its criteria.
   - *"I've asked enough questions."* — Question fatigue is not an exit condition. The exit is the Phase 5 review passing.
   - *"The user seems eager to move on."* — Eagerness is a signal to compress the asking (decide more parameters, batch harder), never to skip an unresolved fork.
-  - *"We can settle it during implementation."* — Every deferral is a `[CONFIRM-NN]` on record, or it is a guess that `tdd` will faithfully implement.
+  - *"We can settle it during implementation."* — Missing acceptance requirements cannot be deferred
+    as implementation freedom. Record genuine user-owned unknowns; retain method selection within
+    the existing planning and delegated-execution contract.
 
-Record every genuinely-unresolved unknown as `[CONFIRM-NN]` in `<project-root>/.codearbiter/open-questions.md`, numbered sequentially. A finding that belongs to a different feature or a future scope gets an inline `[NEEDS-TRIAGE]` marker in the notes — never route it to a ticket.
+Record every genuinely-unresolved user-owned requirement or decision as `[CONFIRM-NN]` in `<project-root>/.codearbiter/open-questions.md`, numbered sequentially. A finding that belongs to a different feature or a future scope gets an inline `[NEEDS-TRIAGE]` marker in the notes — never route it to a ticket.
 
 **Before closing this loop, check the criteria decided so far against their own stated intent, not merely against each other** (#566: `writing-plans` Phase 4 proves BIJECTION between a plan's tasks and the `AC-NN` ledger — every criterion has a task, every task has a criterion — and that proves the two AGREE, never that the ledger itself is COMPLETE. A criterion missed by both sides passes that check cleanly; catching the miss belongs here, at the source, before Phase 4 writes anything to freeze it in place.) Assemble a scratch file outside the working tree (`mktemp`) shaped like the spec sections Phase 4 is about to write — a `## Scope` heading over the Phase 1 framing, and an `## Acceptance criteria` heading over every criterion decided in this phase's running notes so far — and, when this feature traces to a GitHub issue, its body into a second scratch file (`gh issue view <N> --json body -q .body > <scratch-file>`; omitted when there is no linked issue). Run `"$PY" "<plugin-root>/hooks/_intentlib.py" uncovered-intent <scope-and-criteria-file> [--issue-body <scratch-file>]`. A non-empty result names an in-scope bullet or an issue acceptance checkbox no criterion's text cites — add the missing criterion now, or record it as a `[CONFIRM-NN]` if it is genuinely undecided, never carry it forward uncited. This mechanical pass is the CHEAP half; it catches only an uncited bullet or checkbox.
 
 Then ask the half it cannot mechanize, explicitly, as its own step: **if every criterion decided so far passed and nothing else changed, what would still be broken?** A real answer names a criterion the ledger is still missing even though every scope bullet and checkbox is technically cited — a bullet reading "fix all three contaminated skills" against criteria for two of the three passes the citation check above cleanly, and only this question catches it. Finding nothing broken is a reportable result, stated in one line, never a silent skip.
 
-Gate: every vague term made concrete; every fork resolved by the user or recorded as `[CONFIRM-NN]`; every parameter decision recorded in the running notes that seed Phase 4's **Decided parameters** section; no unresolved "later" outside a `[CONFIRM-NN]`; the `uncovered_intent` backstop returns empty or every finding is resolved; and the negative question above has been asked and answered, not merely named. A blocking `[CONFIRM-NN]` that gates the spec's core stops the loop — surface it and STOP.
+Gate: every vague term made concrete; every material choice resolved under the caller's authority or recorded as a genuine `[CONFIRM-NN]`; every parameter decision recorded in the running notes that seed Phase 4's **Decided parameters** section; no unresolved user-owned acceptance requirement outside a `[CONFIRM-NN]`; the `uncovered_intent` backstop returns empty or every finding is resolved; and the negative question above has been asked and answered, not merely named. A blocking `[CONFIRM-NN]` that gates the spec's core stops the loop — surface it and STOP.
 
 ## Phase 4 — Write the spec · gate: BLOCK
 
-Create the agreed spec through the installed structured-artifact engine at
-`<project-root>/.codearbiter/specs/<slug>.html`; do not write the HTML or its
-embedded model directly. The slug is derived from the feature. The spec holds:
+Create or revise the agreed spec at the route-selected spec path, in its selected format.
+New full-lane work uses `<project-root>/.codearbiter/specs/<slug>.html` through the installed
+structured-artifact engine; do not write HTML or its embedded model directly. An existing `.md`
+spec stays on its exact legacy path; never create a counterpart or implicitly convert it.
+The spec holds:
 
 - **Problem** — the Phase 1 framing in final form.
 - **Approach** — the Phase 2 choice and the trade-off that picked it, in two or three sentences.
@@ -113,29 +151,59 @@ Gate: the spec file exists on disk under `specs/`, with at least one acceptance
 
 The spec earns its approval; it is not waved through. Two passes over the FILE as written, then the stop:
 
-1. **Mechanical self-review** — one pass, fix inline, no re-review: no placeholder text (`TBD`, `???`, an unfilled section); no criterion that contradicts the scope; nothing that crosses the `CONTEXT.md` NOT-building boundary; no criterion that contradicts an accepted ADR or `plans/01`'s recorded component boundaries (ADR-0025); every criterion still testable by one or more focused tests after the edits; the vague-language lens applied to the spec's own prose.
+1. **Mechanical self-review** — one pass, correct through the selected format's owning writer, no re-review: no placeholder text (`TBD`, `???`, an unfilled section); no criterion that contradicts the scope; nothing that crosses the `CONTEXT.md` NOT-building boundary; no criterion that contradicts an accepted ADR or `plans/01`'s recorded component boundaries (ADR-0025); every criterion still testable by one or more focused tests after the edits; the vague-language lens applied to the spec's own prose.
 2. **Adversarial pass** — build the strongest case AGAINST the design before the user reads it: the failure mode most likely to be real, the criterion most likely to be wrong, the assumption that would invalidate the approach if false. Present what survives WITH the spec at approval — the user rules on a challenged design, not a defended one. Finding nothing is a reportable result, stated in one line, not a silent skip.
 3. **Approval:**
    - **Under `/feature`** — present the spec and the adversarial findings, and request explicit user approval. Iterate on the file in place until the user approves. A blocking `[CONFIRM-NN]` must be resolved by the user before approval — never auto-resolve it.
-   - **Under `/sprint`** — approval may be granted automatically by SMARTS scoring, logged to the `.codearbiter/` audit trail. A blocking `[CONFIRM-NN]` is never auto-approvable; it escalates to the user and STOPs the sprint flow.
-
-On approval, hand off to the `tdd` skill (`<plugin-root>/routines/tdd/SKILL.md`), which enters Phase 1 against the approved spec — one obligation per acceptance criterion.
-
-Gate: both review passes run against the file on disk, adversarial findings presented, and the spec approved (by the user under `/feature`, or by logged SMARTS auto-approval under `/sprint`) with no unresolved blocking `[CONFIRM-NN]`. Only then does control pass to `tdd`.
+   - **Initial `/sprint` planning** — prepare the ready draft spec and adversarial findings for
+     explicit user approval with its complete draft plan at the caller's one initial review gate.
+     For HTML, return the current draft identity to `writing-plans` in `draft_for_pair` mode;
+     the combined `arm-sprint` / `sprint-approve` path in `<plugin-root>/includes/artifacts.md`
+     observes the exact returned reply and binds/approves both documents atomically. Do not separately approve
+     the spec, synthesize a SMARTS receipt, or execute draft tasks. Do not reinterpret one generic reply
+     as approval of either artifact or delegation. Autonomy begins only after the
+     caller's spec AND plan approval requirement is met. A legacy Markdown caller retains its
+     recorded approval mechanism; there is no implicit conversion.
+
+   - **Within an already-approved sprint** — use its existing delegation only for an in-scope choice.
+     For HTML, a supported policy-owned adapter must supply the actual event and engine receipt;
+     follow `<plugin-root>/includes/artifacts.md`. A SMARTS score or log entry is not an approval receipt.
+     The private `smarts-apply` producer covers only existing plan-method steps under an explicit
+     paired user grant; it cannot approve a specification amendment or widen its protected scope.
+     Use only a qualified production producer for the requested authority and host; do not invent a capture event
+     or reuse inspection-only evidence. A missing producer is not delegation: retain the pending state and use
+     only the existing supported authority path. The native engine's presence does not qualify a host adapter.
+     Blocking `[CONFIRM-NN]` decisions are never auto-approved in either phase.
+
+**Continuation follows the caller.** For a full-lane feature or sprint with approved spec authority,
+return the approved spec identity and review outcome to its planning step; for initial HTML sprint
+review, return the ready draft identity without execution authority. Either may forward directly to
+`writing-plans` (`<plugin-root>/routines/writing-plans/SKILL.md`) when that is the caller's declared
+next step. Do not skip required plan creation, binding or approval by jumping to `tdd`. A subordinate
+invocation returns to the named checkpoint in its caller instead of launching another full workflow.
+The inline small feature route belongs to `/feature` and can reach `tdd` without invoking this full-lane
+specification procedure. Neither path grants commit, PR, merge or publication authority.
+
+Gate: both review passes completed against the authoritative file, adversarial findings presented,
+and no unresolved blocking `[CONFIRM-NN]`. Require actual approval verified before execution.
+Only initial combined HTML review may return a ready unapproved draft to its constrained planner.
+The next operation obeys the active caller's sequence and authority.
 
 ## Hard rules
 
 - MUST NOT write implementation code or route to `tdd` before the spec is on disk under `specs/` AND approved.
-- MUST NOT refine a bundle — an idea holding more than one independently shippable concern splits in Phase 1, before any question budget is spent.
+- MUST preserve the caller's feature or coherent sprint boundary; unrelated scope is split or excluded, not silently absorbed.
 - MUST NOT manufacture alternatives in Phase 2 — when one sane approach exists, say so and why.
 - MUST NOT write an acceptance criterion that cannot be verified by one or more focused tests.
-- MUST decide parameter-level choices and record them in the spec; MUST ask genuine forks in full, with a recommendation, the first time — never name an open decision without asking it.
-- MUST stop a non-converging refinement loop and force one adjudication — a contradiction or a resurfacing fork is a breaker, not a prompt to circle.
+- MUST record material parameter choices; ask genuine missing user decisions in full, not internal method-selection questions already covered by delegation.
+- MUST stop a non-converging refinement strategy; reuse recorded rulings or authorized diagnosis rather than repeat an answered question. Genuine conflicts still route to their owner.
 - MUST run the `uncovered_intent` mechanical backstop and ask the negative-judgment question ("if every criterion passed and nothing else changed, what would still be broken?") before closing Phase 3 — bijective coverage in `writing-plans` proves the plan and the ledger agree with each other, never that the ledger is complete (#566).
 - MUST run the Phase 5 mechanical self-review and adversarial pass against the file as written, and present the adversarial findings at approval.
 - MUST NOT resolve a `[CONFIRM-NN]` by guessing — surface it and record it in `open-questions.md`.
 - MUST NOT auto-approve a spec carrying a blocking `[CONFIRM-NN]`, even under `/sprint` — it escalates to the user.
 - MUST NOT contradict the NOT-building list or redefine domain vocabulary in `CONTEXT.md` — a contradiction is a conflict to surface, not reconcile.
-- MUST NOT run decompose's six-layer whole-project interview — this is one feature, five phases.
-- MUST log a `/sprint` auto-approval to the `.codearbiter/` audit trail.
-- MUST, at exit, run the follow-up harvest (`<plugin-root>/includes/harvest.md`) over any `[NEEDS-TRIAGE]` notes raised this run — batch-confirm promoting them to `open-tasks.md` (work) or `open-questions.md` (decisions) so out-of-scope ideas don't vanish.
+- MUST NOT run decompose's six-layer whole-project interview or force a coherent sprint through repeated one-feature interviews.
+- MUST NOT use SMARTS to approve the initial sprint; record delegated decisions in the existing audit trail and verify actual authority for the selected artifact format.
+- MUST, at exit, run the follow-up harvest (`<plugin-root>/includes/harvest.md`) in the active caller's mode:
+  batch-confirm interactive work; use autonomous promotion only under existing delegation. A blocking
+  decision is never promoted into authority or silently demoted to a follow-up.

package/plugins/ca-pi/routines/commit-gate/SKILL.md

@@ -1,12 +1,18 @@
 ---
 name: commit-gate
-description: The only path to a commit. Routed to when the user invokes /commit or otherwise instructs codeArbiter to persist staged changes. Nine gated phases — permission, branch, classification, verification (test/lint/secrets), behavioral proof, diff review, selective stage, message, commit. Nothing reaches version control without clearing every gate; "it looks good" is not authorization.
+description: Create a verified local Git commit when committing changes is requested. Not for explaining commit history, drafting a message only, or postponing a commit. Applies every commit gate and never implies a push or PR.
+argument-hint: (none)
 ---
 
 # commit-gate
 
 The only permitted path to a commit. Bypassing it is a hard-rule violation. Routed to when the user invokes `/commit` or any equivalent instruction to persist staged changes.
 
+No command arguments are required; inspect current Git state. Test-only requests use the
+recorded invocation in `tech-stack.md` without entering this committing procedure. PR
+readiness belongs to the existing PR workflow; an informational or message-only request
+must not reach staging, commit, or this procedure's writing close.
+
 ## Pre-flight
 
 Read these, or STOP and surface the gap — never guess a command:

package/plugins/ca-pi/routines/executing-plans/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: executing-plans
-description: The checkpoint coordinator for /feature. Routed to by /feature once a writing-plans plan exists. Groups tasks into batches, delegates each batch to subagent-driven-development (fresh author agent per task, full review chain, fresh verification), then stops for a human checkpoint before the next batch. The checkpointed counterpart to /sprint's autonomous run.
+description: The checkpoint coordinator for /feature. Routed to by /feature once a writing-plans plan exists. Uses authored HTML checkpoints or bounded legacy batches, delegates each scope to subagent-driven-development (fresh author agent per task, full review chain, fresh verification), then stops for a human checkpoint before the next batch. The checkpointed counterpart to /sprint's autonomous run.
 disable-model-invocation: true
 ---
 
@@ -23,6 +23,8 @@ Coordinate the plan in small, user-acknowledged batches. Routed to by `/feature`
 `writing-plans` has produced a plan. Each batch is executed by `subagent-driven-development` — fresh
 author agent per task, spec-compliance review, quality review, fresh verification — and the user
 checkpoints between batches. The orchestrator never implements; it schedules and checkpoints.
+An HTML checkpoint is an acceptance scope, not a new user checkpoint in `/sprint`. Sprint routes
+directly to `subagent-driven-development` and does not inherit this attended coordinator's pauses.
 
 ## Pre-flight
 
@@ -42,22 +44,34 @@ Read these, or STOP and surface the gap — never guess a path, a command, or a
 
 ## Phase 1 — Batch plan · gate: BLOCK
 
-Group the plan's tasks into small batches. Keep batches tight — three to five tasks is a ceiling, not
-a target. Respect the plan's ordering and dependencies: a task never lands before the task it depends on.
+For Markdown, group remaining tasks into small batches; the three-to-five task ceiling is legacy
+presentation guidance, not a reason to rewrite typed scope. For HTML, read the authored checkpoint partition
+through the installed engine. Build the sequence from the plan's exact checkpoint membership and ordering,
+retaining each checkpoint's full task-ID set as its acceptance scope. Skip a checkpoint only when current
+engine evidence establishes its accepted state. Do not remove `REVIEW` tasks from an unfinished checkpoint:
+they still need the combined review and whole-scope acceptance. Likewise, do not drop `BLOCKED` members:
+excluding one does not make the checkpoint complete. Resume it only through the supported reconciliation path
+and refreshed eligibility. Respect explicit dependencies in either format.
+
+A smaller display grouping must not split an HTML acceptance scope, combine checkpoints, or change their
+membership to fit a task-count ceiling. Execute and accept one authored scope at a time. If the partition
+itself is unsuitable, return the actual problem to `writing-plans` for the existing amendment/approval path;
+do not mutate scope identity in the coordinator or add a new batching registry.
 
 **Resume is the normal re-entry.** For Markdown, a task already `ACCEPTED` in
 the plan's status column was verified before an earlier interruption. For HTML,
-derive the same decision from the current `eligible` result and its exact task
-identities. Exclude accepted tasks from batching and say so ("resuming: T-01–T-03
-already ACCEPTED"). Batch only the remaining tasks, starting at the first. Never
-re-execute an accepted task, and never restart the pipeline at brainstorming
-because the session died mid-plan.
+derive resume from current `eligible` evidence and the authored checkpoint partition above.
+For Markdown, exclude accepted tasks from new batches. For HTML, retain checkpoint membership while
+selecting only eligible work, and say which current accepted checkpoints are already complete.
+Stale proof requires its existing reconciliation and revalidation, not automatic reimplementation.
+Never restart the pipeline at brainstorming merely because the session died mid-plan.
 
 After process recreation on an HTML pair, rediscover the same authoritative pair
 and query `identity` and `eligible` again. An `IN_PROGRESS` task is not proof of
-completion: capture the existing reconciliation authority and apply
-`task-reconcile` before redispatch through `task-start` with a fresh complete
-context ticket. A task in `REVIEW` still requires fresh evidence and the current
+completion. Use the installed reconciliation adapter in `<plugin-root>/includes/artifacts.md` for the exact task,
+including its genuine host-observed decision and exact stored retry identity; do not construct
+an authority event in this coordinator. A supported `task-reconcile` transition must precede
+redispatch through `task-start` with a fresh complete context ticket. A task in `REVIEW` still requires fresh evidence and the current
 scope review before `accept-scope`; conversation memory cannot advance it.
 
 For each task, confirm the plan names its exact target paths and its verification command. A task
@@ -69,8 +83,10 @@ and what follows. Do NOT stop for a separate acknowledgment — the user approve
 surfaces there (or the user interrupts). Each unresolved unknown is a `[CONFIRM-NN]` in
 `open-questions.md` — surface it, do not guess past it.
 
-Gate: a batch sequence exists and every task has a target path and a verification command. A
-`[CONFIRM-NN]` that blocks batch 1 is the only reason to stop here.
+Gate: a batch sequence exists and every task has a target path and a verification command.
+Missing current authority or capability, a stale prerequisite, or a `[CONFIRM-NN]` blocking the
+first scope is a gate failure. Follow the existing diagnostic or reconciliation owner; do not
+invent a plan, drop blocked members, or restart the interview to clear it.
 
 ## Phase 2 — Execute batch · gate: BLOCK
 
@@ -78,8 +94,9 @@ Invoke `subagent-driven-development` (`<plugin-root>/routines/subagent-driven-de
 spec slug so it can read its own pre-flight files. Do not implement anything here — the author agents,
 review chain, and verification all run inside that skill.
 
-For HTML, pass the selected spec/plan identities and task IDs, not copied task
-labels or prose. The nested workflow records dispatch with `task-start`, records
+For HTML, pass the selected spec/plan identities and the complete task-ID set for one authored checkpoint;
+do not pass a partial or cross-checkpoint task set. Labels and presentation batches do not confer acceptance.
+The nested workflow uses engine eligibility to select work inside that scope, records dispatch with `task-start`, records
 the separate verification and spec-review receipts with `task-review`, and
 records whole-scope acceptance once with `accept-scope`. Preserve every returned
 identity and receipt for the checkpoint and later commit proof.