@arbiterforge/ca-pi 0.18.4 → 0.20.0

package/plugins/ca-pi/includes/author-tdd-workflow.md

@@ -1,27 +1,38 @@
-# Author TDD workflow — non-negotiable, fixed order
+# Author verification workflow
 
-Canonical for the author agents (`backend-author`, `frontend-author`, `infra-author`). Loaded via each agent's
-Required Reading; the agent bodies do not restate it. This is the worker's execution order for
-one task — the tdd skill's phase gates govern the lane above it.
-Apply `<plugin-root>/includes/verification-boundary.md` throughout.
+Use the caller's scoped obligations and selected verification approach from
+`<plugin-root>/routines/tdd/SKILL.md`. Keep each obligation tied to its source and
+proving check. Apply `<plugin-root>/includes/verification-boundary.md` for local
+checks and exact-head hosted CI.
 
-Use the Phase 1 checklist for the owning route. For a bug-origin `/fix`, carry the
-current expectation, cited evidence, supported cause, and regression oracle into
-the existing obligation ledger; confirm the original caller's repair authority and
-source freshness through the fix owner. Do not fabricate a feature artifact. For
-`/feature`, keep the approved spec and its criteria; for `/refactor`, keep its
-approved surface and parity contract. An ADR remains a user-attributed decision
-through `/adr`, never an author shortcut.
+| Route | Required evidence |
+|---|---|
+| /fix | Observe genuine target RED before repair, then fresh GREEN for the same named regression with unchanged assertions. Reuse an adequate current bug-origin RED. |
+| /feature | Keep the agreed spec and criteria. Prefer test-first work; existing implementation may use current criterion-focused checks and meaningful negative controls. Report the observed sequence accurately. |
+| /refactor | Keep the approved surface and parity contract. Establish passing characterization before restructuring and preserve baseline assertions throughout implementation. |
 
-Fixed order. Do not skip or reorder.
+For a bug-origin fix, carry the current expectation, cited evidence, supported
+cause and regression oracle into the existing obligation ledger. Check the
+original caller's repair authority and source freshness through the fix owner.
+Do not fabricate a feature artifact. An ADR remains a user-attributed decision
+through `/adr`.
 
-1. **Map failing tests** — bind each Phase 1 obligation to a test ID. For `/fix`, assess an existing failing test against target red using the current regression oracle and evidence. Name the existing test ID in the ledger and reuse that named existing target-red test when its oracle is adequate and the assertion matches the defect. Do not duplicate a test because of its age or because it predates repair. Add tests only for uncovered obligations.
-2. **Confirm tests are red for the right reason** — run the test command from `tech-stack.md`; the target failure must match the obligation. Record unrelated existing failures in the baseline; an unrelated failure is not target red. An import or setup error is not target red. Preserve and report their identities and outputs. Required commit gates remain blocked while required checks fail. Do not skip tests, suppress failures, or waive gates to proceed.
-3. **Write minimum implementation** — only enough code to make the failing tests pass; no extra scope
-4. **Run impact-bounded local suite** — rerun the same named target test for fresh green on the repaired source, with its assertions unchanged between red and green. Rerun fresh affected-contract tests on that source and record their results; exhaustive and cross-platform proof runs in exact-head hosted CI before merge
-5. **Run lint and type-check** — both clean
-6. **Stage for commit** — only after steps 1–5 complete
+Name the existing target test and reuse it when its assertion matches the defect;
+add tests for uncovered obligations. An import, setup or unrelated failure is not
+target RED. Retain unrelated baseline failures and their outputs. A material
+fixture or setup change requires renewed target RED on the broken source before
+claiming RED-to-GREEN. Preserve the regression's assertions between those runs.
 
-For a repair, observe target red on the broken source before minimum implementation. If a material fixture or setup change occurs after that observation, the earlier red no longer qualifies: repeat target red on the broken implementation with the changed fixture or setup before continuing the repair. Keep the test's assertions unchanged between red and green.
+For intermittent or timing defects, prefer a faithful deterministic seam.
+Otherwise declare a finite repeated-trial bound and failure oracle before running
+it. Report the sample limits; do not claim deterministic proof from a passing
+sample or retry until GREEN.
 
-For an intermittent or timing defect, use a faithful deterministic seam when one exists. Otherwise define a finite repeated-trial oracle with its trial bound and pass/fail rule before running it. Record the stochastic sample limit; do not claim deterministic proof from a passing sample or retry until green. A failing trial must still match the target mechanism, and fresh green remains bounded by the stated oracle.
+Implement only the assigned scope. Run its proving checks and affected existing
+contracts on the resulting source, then applicable coverage, lint and type checks.
+Preserve failures and actual user stops; never skip tests, suppress failures or
+waive required checks to obtain a pass.
+
+Return changed paths, obligation evidence, actual commands/cwd/results and pending
+checks to the caller. Stage only when that action is assigned and authorized;
+committing and publication retain their own owners and permissions.

package/plugins/ca-pi/includes/fresh-verification.md

@@ -1,14 +1,16 @@
-# Fresh-run verification
+# Current verification evidence
 
-The shared proof-by-fresh-evidence discipline. Used by `subagent-driven-development` Phase 5 (per
-accepted task, against the task's verification command) and `commit-gate` Phase 5 (the whole change,
-against the spec's acceptance criterion). Each caller supplies its own target; this is the common rule.
+Verify the caller's actual task or acceptance criterion before claiming completion.
+Read the command, cwd, relevant source and input identities, output and exit code.
+A result is reusable across execution, commit and PR preparation when those inputs
+still match and the observed behavior proves the required claim.
 
-A green suite proves the tests pass — not that the change does what was asked. Before accepting or
-committing:
-
-- **Run the proving command FRESH**, in a clean invocation, in this phase. Do not accept a logged
-  result from an earlier phase, and never trust a subagent's self-report.
-- **Read the actual output AND the exit code.** A non-zero exit, or output that does not demonstrate
-  the obligation/acceptance criterion, fails the gate and returns the work for correction.
-- A self-reported "it works" is never evidence — proof is.
+- Reuse inspected current results, including an earlier phase's result. A phase
+  transition, bookkeeping edit or new receipt ID alone requires no rerun.
+- Run the missing or affected check when evidence is absent, its inputs changed,
+  its scope is insufficient, or its outcome is unresolved. A passing general suite
+  cannot replace a missing criterion-specific check.
+- Inspect delegated command output and its source binding before relying on it.
+  A self-report without accessible evidence is insufficient.
+- Keep a relevant failure or contradictory later result visible until resolved.
+  Correct the affected work and rerun its check; preserve unrelated valid results.

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

@@ -43,14 +43,14 @@ as a **GitHub issue**, not the board.
      the board BUT record one audit line (`harvest declined: N candidates from <origin>`)
      to `triage.log` (append-only — use Edit/`>>`, never Write) so the decline is
      recoverable, not invisible.
-   - **Autonomous (`/sprint`):** SMARTS-score the batch, auto-promote, and append each
+   - **Autonomous (`/sprint`):** promote in-scope follow-ups and append each
      promotion (id + `(from origin)`) to `sprint-log.md` — append-only, so use Edit/`>>`,
      never Write (H-05 blocks a Write to it). A blocking decision is never auto-promoted
      — it escalates and STOPs.
 4. **Apply.** On confirm, route each:
    - **work → `open-tasks.md`** — a queued, ID-less `- [ ] <desc>  (from <origin>)` via
-     `/ca-task add -- "<desc>" --from <origin>` (the `--` lets a desc start with `-`;
-     add `--boundaries a,b` when the extractor supplied them).
+     `/ca-task add --from <origin> -- "<desc>"`. Put optional
+     `--boundaries a,b` before `--`; the terminator lets a description start with `-`.
    - **non-blocking decision → `open-questions.md`** "Deferred decisions" (a
      non-`CONFIRM-NN` bullet with the back-ref).
    - **blocking decision → ESCALATE**, never the Deferred-decisions section: `promote`

package/plugins/ca-pi/includes/reference-map.md

@@ -19,4 +19,4 @@ then route to the owning skill or agent. This map answers *what to read before t
 | Out-of-scope finding | — | inline `[NEEDS-TRIAGE]` marker (never an ADR); promoted to `open-tasks.md` by the harvest at the workflow's terminal step |
 | Following up on workflow residue / a backlog task | `open-tasks.md` (schema), `<plugin-root>/includes/harvest.md` | `/ca-task` writer; harvest (`extract_*` → `promote`) at a terminal step |
 | Generating a user-facing deliverable (UI, report, PR/CHANGELOG prose, slide, chart) | `<plugin-root>/includes/anti-slop-design/INDEX.md` (then `core` + the medium leaf) | `design-quality-reviewer` agent |
-| Provenance drift surfaced outside a commit (merge, external edit, SessionStart drift line) | `.codearbiter/.provenance/` + `.codearbiter/code-map.md` | `context-check` skill (`/ca-context-check`) |
+| Provenance drift or requested refresh of initialized context | Selected documents + `.codearbiter/.provenance/` + `.codearbiter/code-map.md` | `context-check` skill (`/ca-context-check`); reuse the selected scope and existing authorization |

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

@@ -21,8 +21,8 @@ reached the same way.
 
 | Invocation cue | Primary route | Also dispatch | Hard gate |
 |---|---|---|---|
-| New feature | `/feature` Step 0 triage → full lane `brainstorming` → `writing-plans` → `executing-plans` → `tdd`, or logged small lane straight to `tdd` | `backend-`/`frontend-`/`infra-author` | No spec, no code; no code before `tdd` Phase 1; small lane only on all triage criteria, logged to `triage.log` |
-| Autonomous sprint | `/sprint` → `SPRINT.md` (brainstorm → plan → `subagent-driven-development`) | per-task impl authors + reviewers | One interactive spec gate; hard gates never auto-decided; every auto-decision logged |
+| New feature | `/feature` Step 0 triage → full lane `brainstorming` → `writing-plans` → `executing-plans` → `tdd`, or logged small lane straight to `tdd` | `backend-`/`frontend-`/`infra-author` | Maintain useful full-lane spec/plan and applicable tests; small lane requires its listed criteria and triage log, not another permission question |
+| Autonomous sprint | `/sprint` → `SPRINT.md` (brainstorm → plan → `subagent-driven-development`) | implementation or useful delegated authors; reviews by actual risk | No duplicate artifact approval; real host/security and unresolved material decisions remain stops; meaningful auto-decisions logged |
 | Bug fix | `/fix` → `tdd` (bug variant) | impl author | Failing regression test before any fix code |
 | Docs edit / dep bump / revert | `/chore` (type-scaled gates) | `dependency-reviewer` for deps | No behavioral code; suite green for deps/revert; exits via `commit-gate` |
 | Exploratory throwaway spike | `/spike` (self-contained command) → `spike/<slug>` branch | — | Never merges or PRs; `commit-gate`-exempt (nothing on the branch can land); exits to a findings note or `/feature` |
@@ -53,5 +53,5 @@ reached the same way.
 | Local runtime work (run, watch, exercise this repo's own app) | `mode --ops` → narrows the persona per `includes/ops-mode.md`, no skill/agent dispatch | — | Advisory only, no hook becomes mode-aware; permitted only when the operation starts, observes, or exercises and leaves no change in tracked files or git history — anything that mutates tracked files, the index, git history, or published state still routes normally |
 | Promote a workflow's un-actioned follow-ups | `includes/harvest.md` (run at a terminal step) → `/ca-task` (work) / `open-questions.md` (decision) | — | Batch-confirm interactive; SMARTS-logged auto under `/sprint`; dedup by `(from <origin>)`; a blocking decision escalates, never demoted |
 | Zero-onboarding dry-run of the reviewer fleet | `/ca-preview` (no skill; reuses `includes/review-matrix.md` to predict reviewers) | — | Read-only; writes nothing, stages nothing, `git status` unchanged; no `/ca-init` or `.codearbiter/` required; empty diff exits clean |
-| Manual drift audit of provenance-tracked docs (bypass / merge / external edit case) | `context-check` at `<plugin-root>/routines/context-check/SKILL.md` (explicit `/ca-status drift` or `/ca-context-check`) | — | Read-only unless user selects re-scout or re-baseline; MUST NOT commit on its own; not the daily loop — commit-gate auto-heal is the routine path |
+| Context drift audit or requested scoped/full refresh of initialized context | `context-check` at `<plugin-root>/routines/context-check/SKILL.md` (explicit `/ca-status drift` or `/ca-context-check`) | — | Audits are read-only; a direct refresh request selects its scope without another per-document approval. Preserve unselected content and initialized state; MUST NOT commit on its own. Commit-gate auto-heal owns routine maintenance. |
 | Deep on-demand codebase audit | `tribunal` at `<plugin-root>/routines/tribunal/SKILL.md` (explicit `/ca-tribunal` retained) | `tribunal-lens-reviewer` per active lens (+ optional `map-structure`/`map-deps` on large repos) | Read-only until the filing gate; runs only after the user acknowledges the token estimate; never blocks a merge/commit; nothing filed or sent without explicit authorization |

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

@@ -1,10 +1,23 @@
-# SMARTS — lenses, cell rules, strength
+# SMARTS — design-quality rubric
 
-The standardized evaluation for architectural variances. Apply the six lenses evenhandedly to every
-option. This is the project's framework; do not substitute another. This `core` file is everything the
-scoring path needs (decision-variance, the grader, the decision-challenger, and `/sprint` autonomous
-scoring). The append-only **decision-log entry format** lives separately in
-[`decision-log-format.md`](decision-log-format.md) — load it only when writing a log line.
+SMARTS is codeArbiter's six-lens design-quality rubric for material engineering solution choices.
+Workflow owners decide when a choice needs a scan, a full comparison, or delegated autonomous
+handling; SMARTS itself does not grant authority. Architectural variance (decision-variance, the
+grader, the decision-challenger) is one consumer of the rubric, not the definition of the framework.
+Apply the six lenses evenhandedly to every option; this is the project's framework, do not substitute
+another. This `core` file is everything a routine evaluation needs; the per-lens detail in [`lenses.md`](lenses.md)
+is loaded only when a case named under the lenses below arises. The append-only **decision-log entry
+format** lives separately in [`decision-log-format.md`](decision-log-format.md) — load it only when
+writing a log line.
+
+## Evaluation depths
+
+1. **Scan** — a lightweight six-lens fitness pass when a choice is material but does not need the full table: name the material strengths, weaknesses, unknowns and decisive lenses; no full table is required in user-visible output.
+2. **Comparison** — the full option-by-option table, when two or more materially plausible approaches exist, when the user explicitly asks for a full SMARTS read, or when reconciliation or arbitration requires it.
+3. **Delegated decision** — a requested `/sprint` choosing a reversible in-scope method on the user's behalf and logging its reason in `.codearbiter/sprint-log.md`; no separate method grant is required.
+
+All three depths use the semantics in this file; they differ in presentation, persistence and
+decision authority, not in what the acronym means.
 
 ## Step 0 — recorded-intent check (before any lens is scored; ADR-0025)
 
@@ -37,8 +50,27 @@ Three outcomes:
 Fail-soft: an absent `plans/` or `decisions/` directory is not a gap to surface and never a STOP —
 record `intent: silent — no decomposition record` and proceed.
 
+## Context envelope
+
+Before judging a material choice, establish only the context that makes the lenses meaningful:
+
+- **decision** — the actual choice being made, stated when the request leaves it implicit.
+- **scope/horizon** — the bounded system and planning horizon, when they change a verdict.
+- **scale expectation** — only when scale could differentiate the options.
+- **failure/availability expectation** — only when failure behavior could differentiate the options.
+- **security/trust boundary** — only when it bears on Securable.
+- **non-SMARTS constraints** — cost, schedule, team skill, vendor or stakeholder constraints, only when they materially affect the recommendation.
+
+The envelope is scope-sized and fail-soft. No dimension is required for every choice, and it creates
+no new project or configuration file: existing project context, the active spec, explicit user
+steering and relevant recorded decisions supply the evidence when available.
+
 ## The six lenses
 
+The summaries below settle most verdicts. Load the per-lens reference
+[`lenses.md`](lenses.md) only when a verdict turns on a consideration these summaries do not
+settle, or when the user asks for a full SMARTS read — never for a routine scan.
+
 - **Scalable** — supports growth in users, data, throughput, geography without an architectural rewrite. Trap: over-engineering for scale that never arrives, or under-engineering for scale that's on the roadmap.
 - **Maintainable** — can be understood, modified, and extended later (including by agents) without prohibitive effort. Standard patterns over bespoke abstractions; mind the refactoring blast radius and eventual hand-off.
 - **Available** — reachable and functional when needed, including under partial failure. Watch single points of failure, bundled-dependency failure, recovery time. Do not conflate availability with high availability.
@@ -46,33 +78,77 @@ record `intent: silent — no decomposition record` and proceed.
 - **Testable** — validated by deterministic, fast tests that cover real failure modes. Unit + integration + contract; mind mockability and test-data isolation. "Tests later" is a Weak verdict.
 - **Securable** — enables the project's security posture (per `<project-root>/.codearbiter/security-controls.md`) without retrofit. Authentication, authorization, audit, secret management, attack surface, default-deny stance, supply-chain integrity.
 
+## Verdicts
+
+Every evaluated lens takes exactly one verdict:
+
+- **Strong** — performs well for the stated context.
+- **Adequate** — acceptable for the stated context.
+- **Weak** — materially poor for the stated context.
+- **Indifferent** — evidence shows the lens does not materially differentiate the options at the stated context and horizon. If any option marks a lens `Indifferent`, every option marks it `Indifferent`. In a single-option scan there is nothing to differentiate, so Indifferent means the lens is not material to this choice at the stated context; a lens that matters but lacks evidence is `Unknown`, never `Indifferent`.
+- **Unknown** — the evidence needed to judge the lens is missing, contradictory or not yet established. Every Unknown names its missing observation (`missing_observation`) and states whether it is decision-critical (`decision_critical`: true when that observation could change the selected option); no other verdict carries those fields.
+
+`Unknown` is not neutral: never treat it as `Indifferent`, `Adequate` or a pass, and never map it to
+one. A recommendation may stand with a non-critical Unknown only when the output names the missing
+observation and why it does not control the decision. A decision-critical Unknown blocks a `strong`
+recommendation, blocks selecting the option that carries it, and is surfaced before any irreversible
+or authority-bearing choice. A non-critical Unknown never shields a dominated option: on the selected
+option it is no better than the other option's verdict on that lens, and strictly worse than a compared
+`Strong`.
+
 ## Cell rules (hard)
 
 Each SMARTS cell is a constraint, not a guideline. A non-conformant cell is rejected.
 
 1. **Length cap** — at most 25 words per cell.
-2. **Verdict-first** — every cell opens with one verdict word: `Strong` (performs well), `Adequate` (acceptable), `Weak` (poor), `Indifferent` (this lens does not differentiate the options at the current scale).
-3. **Justification follows** — at most 20 words after the verdict.
-4. **No hedging adverbs** — forbidden: potentially, might, arguably, perhaps, generally, tends to, could be, may. If genuinely uncertain, the verdict is `Indifferent`.
+2. **Verdict-first** — every cell opens with one verdict word: `Strong`, `Adequate`, `Weak`, `Indifferent` or `Unknown`.
+3. **Justification follows** — at most 20 words after the verdict; an `Unknown` justification names the missing observation and whether it is decision-critical.
+4. **No hedging adverbs** — forbidden: potentially, might, arguably, perhaps, generally, tends to, could be, may. If genuinely uncertain, the verdict is `Unknown` with its missing observation.
 5. **Evidence specificity** — "industry standard," "best practice," "widely adopted" are not evidence. Cite a specific property of the option, a specific project constraint, or a specific failure mode.
 
+## Conflicting lenses and priority
+
+SMARTS stays qualitative: never count `Strong` cells, assign weights, sum or compute percentages to pick a winner.
+Per-lens dominance — one option no worse on every lens and better on at least one — is an ordinal
+comparison, not a score. When lenses conflict, apply preference evidence in this order:
+
+1. explicit current user or approved-spec priority;
+2. explicit project priority already recorded in project context or an accepted decision;
+3. relevant prior-decision precedent, labelled as precedent, not authority;
+4. no assumed priority.
+
+Absent explicit priority evidence, a tied comparison stays tied.
+
 ## Strength of recommendation
 
 Every recommendation carries exactly one strength label:
 
-- **strong** — multiple dominant lenses align cleanly on one option; non-SMARTS factors confirm.
+- **strong** — dominant lenses align cleanly on one option, non-SMARTS factors confirm, and no option carries a decision-critical Unknown.
 - **moderate** — dominant lenses align with caveats, or a single lens dominates.
 - **tied** — no preferred option emerges. A legitimate output: "This is a coin flip under SMARTS — your call."
 
-There is no `weak` level — a slight edge is `moderate`. When lenses conflict with no winner, state it
-plainly, surface which lens the user has emphasized in prior decisions as input, and mark `tied`.
-The `Precedent:` line under each table (decision-variance Phase 3) is how that emphasis is surfaced
-systematically: 1–3 most-similar prior decisions by ID plus the observed lens pattern, or
-`Precedent: none on record` when history is thin — never an invented pattern.
+There is no `weak` level — a slight edge is `moderate`. The `Precedent:` line under each table
+(decision-variance Phase 3) surfaces step 3 of the priority order: 1–3 most-similar prior decisions by
+ID plus the observed lens pattern, or `Precedent: none on record` when history is thin — never an
+invented pattern, and never authority on its own.
 
 SMARTS does not cover cost, time-to-market, team-skill fit, vendor lock-in, or political
-acceptability. When these matter, surface them as **non-SMARTS considerations** alongside the table;
-they supplement, never replace, the analysis.
+acceptability. When these matter, surface them as **non-SMARTS considerations** alongside the
+analysis; they supplement, never replace it, and never become a seventh lens.
+
+## Design rationale record
+
+An approved full-lane spec keeps a concise SMARTS design rationale; it is design evidence, not a
+source of execution authority. For a typed HTML spec, write it through the existing mutation
+operations with this convention, with no spec-schema change:
+
+- the chosen approach and its trade-off live in the existing `approach` record (`choice`, `tradeoff`);
+- a `decisions` record carries each material decision the SMARTS pass settled, and `approach.binding_decision_refs` cites it;
+- one `sections` record with the fixed id `SEC-SMARTS` (title "SMARTS design rationale") holds one block each for: alternatives considered or the single-option statement; decisive lenses; material Weak and Unknown observations, each Unknown with its missing observation and whether it is decision-critical; load-bearing assumptions; non-SMARTS considerations; and priority evidence when one influenced the recommendation.
+
+Read the rationale back with the existing read operations; never hand-edit or parse rendered HTML.
+A legacy Markdown spec keeps the rationale in one stable `## SMARTS design rationale` section that
+carries the same parts in the same order.
 
 ## Worked example
 

package/plugins/ca-pi/includes/smarts/lenses.md

@@ -0,0 +1,115 @@
+# SMARTS — lens reference (lazy)
+
+Per-lens detail behind the one-line summaries in [`core.md`](core.md). `core.md` owns the role,
+verdicts, cell rules and strength; this file only deepens what each lens asks. Load it only under
+the condition `core.md` states — never for a routine scan the summaries already settle.
+
+Each lens lists the question it answers, the considerations that usually decide it, the traps
+that produce a wrong verdict, and the observation that settles an `Unknown` on it (the
+`missing_observation` an Unknown cell names).
+
+## Scalable
+
+**Question:** does the option support growth in users, data, throughput or geography without an
+architectural rewrite?
+
+**Considerations:**
+- User scale across the stated horizon — prototype, pilot, production.
+- Data volume and its growth rate, including retained history and logs.
+- Throughput shape: bursty versus steady, and the peak the design must absorb.
+- Geographic spread: single region now, multi-region on the roadmap or not.
+
+**Traps:** over-engineering for scale that never arrives; under-engineering for scale that is on
+the roadmap; confusing performance (one request is fast) with scalability (many requests stay fast).
+
+**Settles an Unknown:** the expected load or data volume at the stated horizon, or a measurement
+of the option at that load.
+
+## Maintainable
+
+**Question:** can the system be understood, modified and extended later — including by agents —
+without prohibitive effort?
+
+**Considerations:**
+- Comprehensibility for the next contributor, human or agent, without reading internals.
+- Standard patterns versus bespoke abstractions.
+- Documentation the option obliges someone to keep current.
+- Refactoring blast radius when the option changes.
+- Onboarding and hand-off cost to whoever owns the code next.
+
+**Traps:** treating maintainability as one engineer's concern; underestimating the cost of a
+bespoke pattern when agents write most of the code; ignoring the eventual hand-off.
+
+**Settles an Unknown:** who maintains the code at the stated horizon, and whether the pattern
+already exists in the codebase.
+
+## Available
+
+**Question:** is the system reachable and functional when needed, including under partial failure?
+
+**Considerations:**
+- Single points of failure the option introduces or removes.
+- Failure of a bundled or external dependency, and what keeps working.
+- Disconnected or degraded operation requirements.
+- Time to recover from the common failure modes.
+- The downtime the caller can actually accept.
+
+**Traps:** conflating availability with high availability; designing for high availability the
+project does not require; ignoring partial-availability states.
+
+**Settles an Unknown:** the stated downtime tolerance, or how the option behaves when its
+dependency is unreachable.
+
+## Reliable
+
+**Question:** does the option produce correct, predictable, durable outcomes?
+
+**Considerations:**
+- Atomicity and durability where they matter — the decision log, audit events, receipts.
+- Idempotency of retried operations.
+- State consistency across components.
+- Recovery from failure without corruption.
+- Reproducibility of builds, deployments and recorded evidence.
+
+**Traps:** assuming the database or framework handles it without checking; underestimating the
+reliability cost of distribution; ignoring long-tail durability.
+
+**Settles an Unknown:** the failure the option must survive, and evidence of its behavior under it.
+
+## Testable
+
+**Question:** can the option be validated by deterministic, fast tests that cover meaningful
+failure modes?
+
+**Considerations:**
+- Unit testability of the parts the option introduces.
+- Integration and contract testing between components.
+- Test data generation and isolation.
+- Whether the real failure modes can be reproduced in a test, not just the happy path.
+- The boundary between a throwaway spike and a test that must hold.
+
+**Traps:** patterns that resist mocking or isolation; ignoring the cost of test infrastructure;
+"tests later" for foundational components.
+
+**Settles an Unknown:** whether a deterministic test can reproduce the failure mode the option
+must handle.
+
+## Securable
+
+**Question:** does the option enable the project's security posture — as defined in
+`<project-root>/.codearbiter/security-controls.md` — without retrofit?
+
+**Considerations:**
+- Authentication boundary: who the actor is.
+- Authorization boundary: what the actor may do.
+- Audit boundary: what is recorded, and whether it can be trusted.
+- Secret handling.
+- Attack surface: every bundled component and exposed input.
+- Default-deny versus default-allow stance.
+- Supply-chain integrity: provenance, licenses, signatures.
+
+**Traps:** bolting security on after the architecture is set; confusing compliance with security;
+underestimating the hardening burden of bundled components.
+
+**Settles an Unknown:** the trust boundary the option crosses, and the control
+`security-controls.md` requires there.

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

@@ -1,4 +1,9 @@
-# Sprint approval and delegated method authority
+# Historical sprint approval and delegated method authority
+
+This is an explicit historical attestation and recovery reference, not the normal sprint
+workflow. Load it only for a requested attestation claim or an already-observed transaction
+that needs recovery. Ordinary planning, method changes and execution use `SPRINT.md` under
+the existing authorization; do not arm this protocol to obtain permission for them.
 
 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

package/plugins/ca-pi/includes/verification-boundary.md

@@ -1,10 +1,12 @@
 # Local and hosted verification boundary
 
 Use **impact-bounded local verification** for the contributor loop. Before a
-commit or pull request, run the smallest fresh set that directly proves the
+commit or pull request, establish the smallest applicable set that directly proves the
 changed obligations and affected contracts, plus applicable lint/type-check,
 coverage, generated-artifact parity, staged secret scanning, and specialized
-security, dependency, migration, release, ADR, or deployment gates. A failing
+security, dependency, migration, release, ADR, or deployment gates. Reuse inspected
+results while their relevant source, inputs, command and obligations still match;
+run missing or affected checks. A phase transition alone does not require a rerun. A failing
 local check blocks. Do not require a repository-wide or cross-platform suite on
 the contributor's machine merely to create a commit or open a pull request.
 
@@ -25,3 +27,10 @@ gates. It never waives focused regression proof, coverage thresholds, lint or
 type-check failures, security and secret controls, dependency review, migration
 review, release invariants, ADR lifecycle proof, deployment review, or exact-head
 merge protection.
+
+Use the host relevant to the change for a needed live check. Do not require users
+to install, configure, or switch hosts to complete ordinary work. Cross-adapter
+compatibility belongs to maintainer CI; additional live-host trials require an
+explicit acceptance requirement. If the available host denies a needed action,
+report that limitation once and continue independent authorized work. Do not retry
+an unchanged denial or seek another host merely to obtain a passing result.

package/plugins/ca-pi/package.json

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

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

@@ -12,25 +12,25 @@ not both merely to repeat the same procedure. This index lists what each skill O
 
 | Skill | Routed to by | Owns |
 |---|---|---|
-| [tdd](tdd/SKILL.md) | `/feature` (after spec approval), `/fix`, `/refactor` | The test-first gate: six phases — obligation scan → red → green → obligation verify → coverage → lint. No implementation before Phase 1; no path to `commit-gate` until all six gates are green. |
+| [tdd](tdd/SKILL.md) | `/feature` (with its selected spec), `/fix`, `/refactor` | Scoped verification: regression-first fixes, behavioral feature checks, characterization baselines, coverage and lint; return observed evidence to the commit owner. |
 | [commit-gate](commit-gate/SKILL.md) | `/commit` | The commit gate: nine phases — permission, branch, classification, impact-bounded local verification under the shared [verification boundary](../includes/verification-boundary.md), behavioral proof, diff review, selective stage, message, commit. No commit while an applicable check is red, the behavior unproven, or secrets/cruft present; exhaustive exact-head proof remains a hosted-CI merge gate. |
 | [decision-variance](decision-variance/SKILL.md) | Architectural reconciliation or variance report; explicit `/reconcile` retained | One SMARTS arbitration owner; report-only is non-mutating. Analysis card loads on demand; only explicit user choices enter the append-only log. |
 | [debug](debug/SKILL.md) | Diagnosis intent or `/debug` | Investigate-then-decide root-cause analysis: five phases. Investigation only, no code change here; returns one evidence-backed result: confirmed_code_defect, confirmed_noncode_cause, design_question, no_action, or unresolved. Follow-up action retains caller authority; no default task or ADR write. |
 | [refactor](refactor/SKILL.md) | Behavior-preserving restructure intent or `/refactor` | Behavior-preserving change behind a parity-coverage proof gate; routes to `tdd` Phase 1 for coverage backfill or new test seams. |
-| [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-->`. |
+| [context-creation](context-creation/SKILL.md) | `/create-context` (brownfield) | Back-fills `.codearbiter/` from bounded source inspection and optional agents; 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 | 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. |
+| [brainstorming](brainstorming/SKILL.md) | `/feature` (front), `/sprint` planning | Caller-scoped feature or coherent sprint specification. Keeps material user decisions explicit without duplicate artifact approval. Preserves the selected format, recorded intent and handoff to a maintained plan. |
+| [writing-plans](writing-plans/SKILL.md) | `/feature`, `/sprint` (after the spec) | Maintains the selected spec's criterion/task coverage, dependencies and relevant checks in the same format. Typed draft binding requires no special sprint approval or future reviewer adapter. |
+| [executing-plans](executing-plans/SKILL.md) | `/feature` | Assistive feature coordinator: uses authored HTML checkpoint membership or meaningful legacy batches, delegates useful work, and reports results. Pauses for explicit user-requested checkpoints or actual decisions, not routine status reporting. |
+| [subagent-driven-development](subagent-driven-development/SKILL.md) | `/sprint` (engine), `executing-plans` (batch scope) | Work from real task dependencies; implement or delegate coherently, run relevant checks, record DONE separately from verified evidence, and retry affected failures. Real user stops, security controls and unresolved material decisions still apply. |
 | [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) | PR intent or `/feature` / `/sprint` terminal handoff |Select watch/cleanup before creation preflight. Own PR opening after the current-head gates; sprint opens only. Merge/discard require explicit authority and their own proof. |
-| [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. |
+| [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 completed units onto the caller's working branch for independent commit-gate checks. Never the default path. |
 | [secret-handling](secret-handling/SKILL.md) | changed code reads/writes/passes a secret | The secret-source gate: identify → source → sinks/persistence. Secrets only from the approved store in `security-controls.md`; never in source, log, error, telemetry, image, or LLM prompt. Dispatches `auth-crypto-reviewer`. |
 | [crypto-compliance](crypto-compliance/SKILL.md) | changed code uses crypto/hashing/signing/TLS/random | The banned-primitive gate: one scan. Rejects broken primitives, disabled TLS verification, home-rolled crypto; approved list lives in `security-controls.md`. Dispatches `auth-crypto-reviewer`. |
 | [decision-lifecycle](decision-lifecycle/SKILL.md) | Record a decided ADR / inspect ADR health (`/adr`, `/adr-status`) | One owner; select read-only status before authoring prerequisites. User-attributed writing loads its reference on demand. Full-stem identity; Accepted/Planned is not delivery proof. |
 | [release](release/SKILL.md) | `/release` | Lean declared-policy release, three phases: derive the next identity from Conventional Commits under `version-policy` + roll the changelog; cut the annotated tag and qualify declared assets through either a protected hosted `release-build` or a provenance-bound retained exact-head CI cohort; publish that tag and only those assets on explicit authorization, then verify the remote inventory. SemVer remains the default. No tag on a red suite; no direct-to-main/force-push; nothing published unbidden; a release commit routes through `commit-gate`. |
 | [security-architecture](security-architecture/SKILL.md) | Requested threat model or `/threat-model` |Read-only STRIDE analysis of a sensitive design. Lesser gaps remain constraints; critical unmitigated threats stop the pass. No ordinary-change auto-entry. |
-| [context-check](context-check/SKILL.md) | Drift-audit intent, `/status drift`, or `/context-check` |Report provenance drift; re-scout or re-baseline selected documents only. No staging or commits; routine auto-heal remains with commit-gate. |
+| [context-check](context-check/SKILL.md) | Context refresh, drift-audit intent, `/status drift`, or `/context-check` | Report drift or refresh selected documents under existing authorization. No staging or commits; routine auto-heal remains with commit-gate. |
 | [post-merge-cleanup](post-merge-cleanup/SKILL.md) | Merged-branch cleanup intent, `/ca-pr --cleanup`, or `/ca-cleanup` |Prove fetched containment, classify residue, confirm each discard, and transition fast-forward-only. Preserve unique work, stashes and remote branches. |
 | [tribunal](tribunal/SKILL.md) | Deliberate deep-audit intent or `/ca-tribunal` |Cost-approved deep audit with persisted findings and resumable triage. Separate approval for issue filing and telemetry; never a required gate. |