@arbiterforge/ca-pi 0.18.4 → 0.20.0

package/plugins/ca-pi/skills/ca-init/SKILL.md

@@ -27,51 +27,29 @@ An initialized refresh is routed through `/ca-status drift` and the existing
 `context-check` owner after an explicit scoped or full selection; `--brownfield`
 keeps its initial-population lock.
 
-### Brownfield host prerequisites
-
-For repositories with existing source, every scaffold and populator step in
-the Procedure below is conditional on observing these prerequisites first.
-This applies to both `--brownfield` and the default auto-detection route.
-When qualification is unavailable or unknown, stop here and issue the handoff
-described below. Do not execute the later Procedure steps or enter brownfield
-population through the When NOT to use section.
-
-Scaffolding enables governance and may install Git hooks before population.
-It does not qualify the host for context extraction. Before selecting
-`--brownfield` or automatically routing existing source to brownfield
-population, inspect the installed
-context-creation containment profile in
-`<plugin-root>/routines/context-creation/SKILL.md`, under that exact heading.
-The active host needs an observed context-specific child profile with enforced
-read-only containment and report delivery, plus the existing native context
-writer and approval support. Ordinary unrestricted collaboration agents on
-Codex desktop/Windows do not satisfy that requirement. The repository-only
-Claude preparation fixture is neither a shipped consumer route nor proof of
-a qualified host.
-
-When these prerequisites are unavailable or unknown, report the missing
-capability before invoking the scaffolder. Keep a fresh repository unactivated
-and retain every byte of any existing partial state. Name the loaded package,
-observed host limitation or explicitly unknown qualification, selected
-population route and next missing prerequisite in the handoff; leave
-unobserved qualification and prior operation identities
-unknown. Resume on a host only after fresh containment and writer qualification,
-using the existing interrupted-population recovery procedure. No supported
-destination is implied by this guidance.
-
-This is a workflow preflight. The low-level scaffolder has no native scout
-capability attestation input and does not enforce or prove this assessment.
-Its successful exit, `--check` inventory or enabled stub never establishes
-population readiness. Do not fabricate a profile, receipt, context document
-or initialization sentinel to pass the later gates.
+### Brownfield preparation
+
+Confirm the intended repository, existing state, selected outcome and actual
+host permissions before activation. Scaffolding enables governance and may
+install Git hooks; it does not prove context correctness or host enforcement.
+For existing source, use bounded inspection and the safe installed context
+writer in `<plugin-root>/routines/context-creation/SKILL.md`. Scoped agents are
+optional. Ordinary native Windows work does not require a special scout sandbox,
+profile attestation or per-document artifact approval.
+
+If a real host permission or the installed safe writer is unavailable, report
+the exact operation and retain current state. Continue independent authorized
+inspection; do not fabricate a profile, receipt, context document or initialized
+marker. Successful scaffold or `--check` output is inventory, not evidence that
+population or a live host probe completed.
 
 The two flags are mutually exclusive and neither may combine with `--check`. `--stage N` may
-accompany one only while `.codearbiter/CONTEXT.md` is absent: after any required brownfield preflight,
+accompany one only while `.codearbiter/CONTEXT.md` is absent: after checking the repository and host permissions,
 scaffold at that stage, then enter the
 selected workflow. When an uninitialized stub already exists, skip the refusing scaffolder and enter
 the selected workflow directly. An initialized marker or source-shape mismatch retains the selected
 legacy workflow's BLOCK. Without an explicit strategy, continue with the unchanged auto-detection
-procedure below only after any required brownfield preflight.
+procedure below under the same repository and host permissions.
 <!-- catalog-command-modes:end -->
 
 ## Procedure
@@ -106,7 +84,7 @@ below remain in force for repositories that already opted in.
    `open-tasks.md`, `open-questions.md`, `overrides.log` (audit header), and `last-checkpoint` (`0`).
 
 3. **Then route to the populator** — the stub is not yet usable:
-   - **Source code already exists** in the repo → route to `/ca-create-context` (brownfield: scouts
+   - **Source code already exists** in the repo → route to `/ca-create-context` (brownfield: bounded inspection and optional agents
      read the codebase and synthesize the full context, writing the initialization sentinel).
    - **Greenfield** (no meaningful source) → route to `/ca-decompose` (layered interview).
 

package/plugins/ca-pi/skills/ca-pr/SKILL.md

@@ -45,14 +45,14 @@ branch-finish request, assemble state and ask for the terminal choice, not a com
 An already-recorded explicit choice remains effective for its unchanged scope;
 revalidate evidence, not the wording of the user's request.
 
-All PR creation and terminal actions below require the current-head commit gate.
+PR creation and terminal actions below require applicable current-head verification.
 Watch and cleanup return from their own paths before reaching that requirement.
 
 ## Pre-flight
 
 Read these, or STOP and surface the gap — never guess the branch name or the default branch:
 
-- `<project-root>/.codearbiter/CONTEXT.md` — the default-branch name and project context.
+- `<project-root>/.codearbiter/CONTEXT.md` — project context. Resolve the working branch and default target from Git or repository metadata.
 - The discovered authoritative spec/plan pair for the pipeline, when `/feature`
   or `/sprint` produced one. Use the exact selected `.md` or `.html` plan as the
   yardstick for "is the work complete." Re-run the private bridge resolver
@@ -61,23 +61,21 @@ Read these, or STOP and surface the gap — never guess the branch name or the d
   for HTML and obtain HTML plan state only through the installed engine
   `identity`, `index`, and symbol-scoped `read` operations. The finishing step
   must not create, convert, or consult a counterpart.
-- `<project-root>/.codearbiter/last-checkpoint` — the most recent gate results; confirms `commit-gate` cleared on this branch.
+- The observed commit/check results for this branch: checked source identity, commands and cwd, outcomes, and applicable review findings.
 - `<plugin-root>/includes/verification-boundary.md` — the exact-head hosted-CI evidence required before merge.
 
-For an HTML pair, query the engine `identity` and `eligible` again after process
-recreation. Require `all_accepted_and_current: true` for the exact spec and plan
-identities, with their acceptance receipts still bound in engine state and the
-commit-gate proof. Finalization must not parse rendered HTML and must not consult
-a shadow Markdown ledger; displayed labels, status words, checkboxes, or digests
-cannot establish completion.
+For an HTML pair, query `identity` and `eligible` after process
+recreation and read the actual work and check results. `eligible` is advisory
+scheduling; `DONE` means implementation progress, not a verified release.
+Report unfinished work, missing or failing tests, and any outstanding
+decisions, rather than requiring an artifact acceptance receipt simply to
+prepare or open an authorized PR. Do not scrape HTML or invent receipts.
+`_preflight_current_acceptance` remains an **explicit historical proof query**,
+not the mandatory permission gate for opening a PR or preparing a branch.
+Real Git/host authorization, current applicable check results, independent security
+controls and exact-head hosted CI before merge still apply.
 
-Enforce that requirement by invoking the installed bridge's
-`_preflight_current_acceptance` with the exact `_resolve_workflow_pair` result,
-repository-bound client, and engine-returned spec/plan IDs. Carry its returned
-identity/receipt proof into state assembly. Any refusal blocks terminal options;
-do not recreate the proof from the PR description, checkpoint prose, or labels.
-
-`commit-gate` MUST have cleared on the current HEAD. If it has not, this skill does not run — return to it.
+Establish applicable verification for the current HEAD. Reuse observed results whose checked source and inputs still match. For a committed branch, derive paths and obligations from the explicit base-to-HEAD diff and run missing or affected checks under `verification-boundary.md`, followed by the review matrix below. Bind secrets scanning and specialized security/migration checks to that same base-to-HEAD subject. An empty staged set does not establish branch coverage. Report these read-only readiness results without creating commit markers. This verification does not invoke commit-only phases or create a commit. Authorized uncommitted work uses `commit-gate` before delivery.
 
 ## Phase 1 — State assembly · gate: BLOCK
 
@@ -85,7 +83,7 @@ Assemble the facts the decision needs. Nothing is presented until all are in han
 
 - **Branch** — the current branch name and its base. Confirm it is NOT the default branch; if HEAD is the default branch, STOP — there is nothing to finish and merge-to-default is forbidden.
 - **Diff summary** — files changed, insertions/deletions, and the commit list since the base. Read it, do not paraphrase from memory.
-- **Gate results** — `commit-gate` outcome and the `last-checkpoint` record. Surface any open `[NEEDS-TRIAGE]` markers left in the diff as out-of-scope findings.
+- **Check results** — observed commands, source identity, outcomes and relevant review conclusions for the current HEAD. Mark missing or inapplicable evidence as pending. Surface any open `[NEEDS-TRIAGE]` findings.
 - **Plan delta** — when a plan exists, state which plan items the branch satisfied and which remain open. Open items are surfaced, not hidden.
 - **ADR source ancestry** — when `.codearbiter/decisions/adr-lifecycle.jsonl` exists, select
   the merge method from the exact fetched target commit and PR head commit. Run the installed verifier:
@@ -199,18 +197,27 @@ contributor-source, native-qualification and no-bypass requirements above apply.
 ### Open-PR procedure
 
 Run this procedure only for the selected open-PR or merge-via-PR action, after the
-current-head commit and acceptance preflight. It is shared by direct PR requests
+current-head verification and authorized commit handling. It is shared by direct PR requests
 and caller handoffs; it is not a second host-command invocation.
 
-1. **Confirm the commit gate cleared** this session (`commit-gate` green, or `/ca-commit` completed).
-2. **Path matrix** — inspect the diff and dispatch the reviewer agents the change demands:
+1. **Confirm current-head readiness** from the applicable observed checks and review assembled in Phase 1. If a commit is needed, use `commit-gate` under the existing authorization.
+2. **Review coverage** — inspect the base-to-HEAD diff and identify the required review subjects:
    - auth / crypto / middleware paths → `auth-crypto-reviewer` + `security-reviewer`
+   - CI / deployment / infrastructure paths → `security-reviewer`
    - migration files → `migration-reviewer`
    - dependency manifests → `dependency-reviewer`
-   - all paths → `coverage-auditor`
-3. **Run reviewers** in parallel where there are no dependencies.
+   - executable source or verification-contract changes → `coverage-auditor`
+   - prose-only changes → applicable documentation/reference checks
+   Reuse inspected review conclusions when their source, requirements, findings and
+   verification inputs still cover this subject. A commit, PR handoff or new receipt
+   identity alone does not require redispatch. A newly failing check or relevant edit
+   requires reassessing the affected conclusions. Honor an explicit request for a
+   fresh independent review.
+3. **Run missing or affected reviews** in parallel where there are no dependencies.
+   If existing reviews cover every required subject, proceed with those results.
 4. **BLOCK check** — any CRITICAL or HIGH finding STOPs the flow; present it and do not draft the PR.
-   Correct within existing scope and authority, then re-run the commit and review gates.
+   Correct within existing scope and authority, then rerun affected checks and reviews.
+   Reuse unaffected evidence and invoke commit handling only for changes needing a commit.
    Do not require the user to repeat command spellings; no unresolved blocker is waived.
 5. **Stage the PR** once all BLOCK findings clear: concise title; summary of what changed and why; a
    bulleted test plan; a conflict-hierarchy tradeoff citation for any non-obvious tradeoff; a link to
@@ -231,39 +238,22 @@ and caller handoffs; it is not a second host-command invocation.
    `/ca-watch <new-PR>`. When `enabled` is false, do nothing here — the user can still run `/ca-watch`
    ad-hoc. Never enable the flag on the user's behalf.
 
-## Phase 4 — Receipt · gate: BLOCK
-
-The loop has been a chain of gates the user watched clear. End it on its most rewarding beat, not in
-silence. Emit a tight **Receipt** — a win summary that reflects the prevention back, drawn ONLY from
-the state Phase 1 already assembled plus `<project-root>/.codearbiter/last-checkpoint`. This is
-**not a fresh audit-trail crawl** — no new log scan, no `git` archaeology. If a field has no data in
-hand, omit the line rather than go digging.
-
-Report only what the assembled state supports:
-
-- **Obligations covered** — the count of `tdd` obligations that reached `COVERED` on this branch.
-- **Gates that fired and what each caught** — the gates that BLOCKed and then cleared, named with the
-  specific thing caught (an untested seam, a scope-creep file set aside), not a bare gate name.
-- **SMARTS decisions the user made** — the architectural forks the user resolved, one line each.
-- **Secrets / regressions prevented** — credential findings and behavioral-proof mismatches the gates
-  stopped before they shipped.
-- **Suite time** — the wall-clock of the verifying run, from the gate results in hand.
-
-Close with **exactly one** warm, synthesizing sentence (per the orchestrator register) that reflects
-the run back — synthesized for this branch, not the register's canned example. One sentence, earned,
-never on a no-op close.
+## Phase 4 — Delivery report
 
-Gate: the Receipt is emitted from in-hand state (no fresh crawl), and the close carries at most one
-warm sentence.
+Use the Phase 1 state and the observed action result. Report the commit/PR identity,
+implemented scope, applicable checks and review outcomes, and remaining work.
+Include suite time when observed. Keep implementation, verification, merge and
+publication distinct. Do not perform a fresh audit-trail crawl to embellish the
+report or infer verification from a checkpoint counter.
 
 ## Hard rules
 
-- MUST NOT merge directly to the default branch or force-push — every change lands through a PR.
-- MUST NOT auto-merge under `/sprint`; auto-select "open PR" and surface the merge decision to the user.
-- MUST NOT discard a branch without explicit user confirmation that names the branch.
-- MUST NOT delete un-pushed commits silently — STOP and report the loss before any discard.
-- MUST NOT run before `commit-gate` has cleared on the current HEAD.
-- MUST NOT merge without the repository merge-readiness aggregate passing for the PR's current exact head; missing, stale, cancelled, mismatched, pending, or red hosted evidence blocks.
-- MUST NOT guess the branch or default-branch name — read `CONTEXT.md` or STOP.
-- MUST draw the Receipt only from Phase 1 state + `last-checkpoint` — never a fresh audit-trail crawl — and never build a rolling cross-branch "saves" tally.
-- MUST keep the close to at most one warm sentence; never on a no-op close.
+- Preserve the selected branch and exact reviewed head; every merge goes through a PR.
+- Merge requires explicit authorization. Never force-push.
+- MUST NOT auto-merge under `/sprint`; its terminal action is an open PR.
+- MUST NOT discard a branch without explicit user confirmation naming it.
+- MUST NOT delete un-pushed commits silently.
+- Required current-head checks and review must pass before claiming readiness. Missing evidence stays pending.
+- Merge requires the repository's passing merge-readiness aggregate for the PR's current exact head.
+- Read branch and target identities from Git; do not guess them.
+- Report only observed actions and applicable evidence.

package/plugins/ca-pi/skills/ca-refactor/SKILL.md

@@ -8,13 +8,13 @@ argument-hint: "<surface and motivation>"
 
 Select this owning procedure for a behavior-preserving restructure, whether requested
 in plain language or through `/refactor`. Entry syntax is not an additional gate;
-the approved-surface, parity, and verification requirements below still apply.
+the authorized scope, parity, and verification requirements below still apply.
 Externally observable behavior before equals after, proven rather than assumed.
 
 ## Entry boundaries
 
 - Identify both the surface and the motivation. Phase 1 owns the precise surface
-  table and its approval; knowing a command name does not establish either.
+  table under existing authorization. Ask only about a missing consequential scope decision.
 - New behavior, including a new error path, side effect, or public method beyond
   a Phase 3 seam, belongs to `/feature`. Incorrect existing behavior belongs to `/fix`.
 - An explanation-only question stays in the non-mutating question-answer path,
@@ -36,7 +36,9 @@ The working tree MUST be clean over the named surface before Phase 1. A dirty su
 
 ## Phase 1 — Surface identification · gate: BLOCK
 
-Enumerate the exact blast radius before any other work. Restate the planned refactor in one sentence and confirm it back to the user, then record a surface table:
+Inspect the requested refactor and record its precise surface before restructuring.
+Present the table and continue when the existing request covers it; no second
+signoff is required. Ask only about a genuinely unresolved scope or outcome:
 
 - Files (repo-relative paths).
 - Top-level symbols touched — function, class, and exported member names.
@@ -45,7 +47,10 @@ Enumerate the exact blast radius before any other work. Restate the planned refa
 
 Reject vague surfaces. "the auth module", "the user service", "some helpers in utils" are categories, not surfaces. A surface is acceptable only when a reader could grep the repo for the listed symbols and arrive at the same file set. The table is the parity contract for Phases 2–6.
 
-Gate: a precise, complete surface table, user-signed-off. A vague or category-level surface does not pass — "the functions `signToken`, `verifyToken`, and `rotateKey` in `src/auth/tokens.ts`" passes; "the auth module" does not.
+Gate: a precise, complete surface table covered by existing user authorization.
+Resolve category-level requests through source inspection where their outcome is
+clear. Ask only when inspection exposes a consequential missing choice. Include
+necessary consumer updates within the requested restructure and record their scope.
 
 ## Phase 2 — Behavioral parity coverage proof · gate: BLOCK
 
@@ -65,7 +70,7 @@ Where the surface has no coverage tooling, take the no-tooling exemption in
 section that omits a command for this surface — and the per-symbol direct-test proof stands alone.
 Without that citation the phase STOPs rather than passing on an unverifiable claim.
 
-If surface coverage is below the maturity threshold on any required metric, OR any public method has zero direct tests, halt and route to the `tdd` skill (`<plugin-root>/routines/tdd/SKILL.md`) Phase 1 to backfill obligations and red tests for the uncovered surface. Resume Phase 2 only after the backfill is green.
+If surface coverage is below the maturity threshold on any required metric, or a public method has no direct test, use the characterization/backfill approach in `<plugin-root>/routines/tdd/SKILL.md`. Add tests for the existing behavior and run them before restructuring; initially passing tests establish the baseline. Use a meaningful isolated negative control where needed to check the oracle. Record the passing post-backfill baseline, including test identities and assertions. Resume with that measured coverage and preserve the baseline assertions through implementation.
 
 Gate: surface coverage at or above the maturity threshold on every required metric in the declared coverage profile, the shared critical-path evidence present, AND every public method backed by a direct test. Otherwise backfill via `tdd` Phase 1 before retrying.
 
@@ -79,33 +84,49 @@ Gate: either "No new seams", or failing seam tests with all pre-existing tests s
 
 ## Phase 4 — Implementation · gate: BLOCK
 
+**Strategy choice (conditional).** Only when materially distinct restructuring strategies exist (for
+example, extract-and-delegate versus move-and-rename), and only after the Phase 1 surface table and
+the Phase 2 parity proof are settled, run a SMARTS comparison per
+`<plugin-root>/includes/smarts/core.md` inline to choose between them. The choice never widens the
+surface table or relaxes a parity or coverage gate. One evident strategy gets no SMARTS table.
+
 Apply the restructure with zero behavior change, to the conventions in `coding-standards.md`. Confine every edit to the surface table. Acceptable edits: rename symbols (with consumer updates); extract or inline functions and methods; move symbols between files; replace an internal implementation with an equivalent one; collapse or split modules where the public interface is preserved.
 
 Unacceptable inside a refactor: adding a behavior, branch, error path, or side effect; changing the value any public method returns for any pre-existing input; adding a public method beyond a Phase 3 seam; changing observable order of operations (event emission, logging, IO). Classify the resulting staged diff against `commit-gate` classification criteria — a diff that classifies as `feat` is not a refactor; halt and route to `tdd`.
 
-Gate: the refactor confined to the surface table, with any Phase 3 seam tests now green. BLOCK if the diff classifies as `feat`, or if any edit falls outside the Phase 1 surface table without an explicit user-approved amendment.
+Gate: the refactor remains within the authorized outcome, with any Phase 3 seam
+tests now green. Maintain the surface table for discovered consumer updates within
+that scope. BLOCK if the diff classifies as `feat` or requires a scope expansion
+without the actual owner's authorization.
 
 ## Phase 5 — Parity verification · gate: BLOCK
 
-Run every impact-bounded local parity test identified in Phase 2, following `verification-boundary.md`. Each MUST pass with NO modification to its source — inspect the diff and confirm zero edits to any pre-existing test file. A modified pre-existing test is, by definition, evidence the surface's observable behavior changed: revert it. If it cannot pass after revert, the refactor introduced a behavior change and is routed to `tdd` as a feature or fix. Phase 3 seam tests (if any) MUST pass. Record the pass/fail tally and any modified-test detection. The exhaustive pre-existing suite remains a required exact-head hosted-CI merge gate.
+Run the impact-bounded parity tests recorded in the post-backfill Phase 2 baseline,
+following `verification-boundary.md`. Compare test changes made during implementation
+against that baseline, including characterization cases added to existing test files.
+Preserve their assertions. Necessary import or symbol-reference updates must retain
+the same behavioral oracle. If implementation requires changing an expected result,
+resolve the behavior change through the feature or fix owner. Phase 3 seam tests
+must also pass. Record current results and any permitted mechanical test changes.
 
-Gate: scoped parity tests green with zero pre-existing tests modified. BLOCK if any pre-existing test was modified to pass, or if any applicable test fails; the branch still MUST NOT merge until exhaustive exact-head hosted CI passes.
+Gate: baseline parity and new seam checks pass with preserved behavioral assertions.
+The exhaustive pre-existing suite remains an exact-head hosted-CI merge requirement.
 
 ## Phase 6 — Lint and coverage · gate: BLOCK
 
 Run lint, the type-check if the project is statically typed, and coverage, all from `tech-stack.md`. Resolve every lint and type error. Confirm surface coverage remains at or above the maturity threshold on every required metric in the same declared coverage profile. A refactor MUST NOT reduce coverage of the surface it touched on any required metric or drop its critical-path evidence.
 
-Where the surface has no coverage tooling, the same clause as Phase 2 applies — the no-tooling exemption in `<plugin-root>/includes/maturity-coverage.md`, citation included — and parity is verified through Phase 5's unmodified pre-existing tests alone. Phase 2 and Phase 6 MUST NOT give different answers about the same surface, which is why both defer to the one shared clause rather than restating its conditions.
+Where the surface has no coverage tooling, the same clause as Phase 2 applies — the no-tooling exemption in `<plugin-root>/includes/maturity-coverage.md`, citation included — and parity is verified through Phase 5's post-backfill baseline and preserved behavioral assertions. Phase 2 and Phase 6 MUST NOT give different answers about the same surface, which is why both defer to the one shared clause rather than restating its conditions.
 
 Gate: clean lint and type-check, zero errors, and no coverage regression on the named surface. "Mostly passes" is not passing — this is what clears the path to `commit-gate`.
 
 ## Hard rules
 
-- MUST NOT begin Phase 2 without a precise, user-signed-off surface table.
+- MUST identify the precise surface and existing authorization before Phase 2; do not request duplicate signoff.
 - MUST NOT proceed past Phase 2 if surface coverage is below the maturity threshold or any public method has zero direct tests — route to `tdd` Phase 1 to backfill.
 - MUST NOT introduce new behavior in Phase 4. A diff that classifies as `feat` under `commit-gate` is not a refactor.
-- MUST NOT modify any pre-existing test to make it pass. A modified test is a behavior change.
+- MUST NOT weaken a baseline assertion to make the refactor pass. Mechanical test-reference changes must preserve the behavioral oracle.
 - MUST NOT reduce coverage of the named surface during the refactor.
-- MUST NOT extend the surface mid-flight without an explicit user-approved amendment to the Phase 1 table.
+- MUST keep the surface table current and obtain authorization for a material scope expansion or changed outcome.
 - MUST NOT inline-suppress a lint rule to clear Phase 6, and never to bypass a security-relevant rule.
 - MUST NOT guess the test, coverage, lint, or type-check command — read `tech-stack.md` or STOP.

package/plugins/ca-pi/skills/ca-release/SKILL.md

@@ -342,7 +342,7 @@ Derive the bump mechanically from the commit log; do not guess it.
    **For the footer-completeness rule below, an accepted `[RECONCILED]` row counts as footer-complete.** That is not an auto-fill or a relaxation for ordinary missing footers: it is an explicit repository declaration bound to one exact commit already on the freshly fetched default branch, and every unlisted or unprovable commit remains `[NEEDS-TRIAGE]`. An unpublished commit must be amended or rebased instead and MUST NOT be added to the ledger. A reconciliation for a published commit lands through a normal reviewed commit, after which this lane restarts so its clean-tree and fresh-origin gates cover the policy change. When step 5 composes the changelog, it uses the exact helper-printed reconciliation text in the group selected by the commit's unchanged type; it does not reword or re-derive the note.
 3. **Verify footer completeness for the already-established `$EFFECTIVE_WINDOW` before touching anything else — never after.** On a first release, step 0 has already proposed and confirmed the adoption floor before classification; do not classify the raw full-history `$WINDOW` first and then try to narrow it here. The sole sanctioned exception is Back-fill's own canonical first-release shape (step 0's note, step 1's check): there, `$EFFECTIVE_WINDOW` may still be substituted to `HEAD` at step 1, but only through that step's OWN presented confirm-or-replace gate, before this step ever runs — a confirmed widen at the documented point of use, not an unconfirmed narrowing performed HERE. `adoption-commit` takes the oldest line of its newest-first input, so considering both candidate files identifies whichever adoption happened first. The confirmed boundary commit itself remains included, including when it is the root commit. Over that effective window, every `feat`/`fix`/`perf`/`refactor` commit (the full harvested set step 5 rolls into the changelog, not just `feat`/`fix`) MUST carry a `CHANGELOG:` footer. **This obligation is wider than those four types, regardless of type: any commit `classify_commit` marks `breaking` — an unfootered `chore!:`, `docs!:`, `test!:`, or `ci!:` included — is caught here too**, because `classify_window`'s `missing_footer` set keys on each row's own `bump != "none"`, not a fixed type list, so a footer-incomplete breaking commit of any type is already BLOCKed at this step, before step 5 ever composes a changelog. **A missing footer on any one of them is a BLOCK**, not a soft finding: surface EVERY offending commit as its own `[NEEDS-TRIAGE]` line in the release report presented to the user (one line per commit missing the footer, `<short-sha> <subject>` — never a single collapsed `[NEEDS-TRIAGE]` when more than one commit is at fault, and never written to any file: the report is its only destination) and STOP here — never auto-fill it, and never tag a changelog that silently drops a user-visible change. **The remedy is the operator's to choose:** first check whether the commit is already published with `git -C "$PROJECT_ROOT" merge-base --is-ancestor <sha> "origin/$DEFAULT_BRANCH"`. An unpublished commit may be amended or rebased; a published one must not be rewritten or force-pushed. If a listed commit genuinely has nothing user-facing to say, reclassify its type instead of leaving it half-classified. Never invent footer text on the author's behalf. Checking before step 4 bumps any file means a blocked release leaves no partial manifest bump. A `CHANGELOG:` footer on a `test`/`docs`/`chore`/`ci` commit is harvested by step 5 rather than silently discarded, but does not by itself create a bump.
 4. **Apply the step-2 classification to `$BASE_VERSION` through the policy-aware helper, never by eye.** Capture step 2's first line verbatim as `$BUMP`. For `LAST_TAG=<none>` with the numeric-sequence manifest exactly at `$INITIAL_VERSION`, run `DERIVATION_BASE="<none>"; COMPARISON_BASE="<none>"`; otherwise run `DERIVATION_BASE=$BASE_VERSION; COMPARISON_BASE=$BASE_VERSION`. Then run `VERSION=$("$PY" "<plugin-root>/hooks/_releaselib.py" derive-version "$DERIVATION_BASE" "$BUMP" "$VERSION_POLICY" "$INITIAL_VERSION")` and set `RELEASE_TAG=${TAG_PREFIX}${VERSION}` once for every later tag, notes, asset, and publication command. This preserves SemVer's patch/minor/major arithmetic while `numeric-sequence` advances its final component exactly once for any bumping classification; `none`, an unknown policy, or an invalid base STOPs. Confirm the result mechanically with `"$PY" "<plugin-root>/hooks/_releaselib.py" version-greater "$VERSION" "$COMPARISON_BASE" "$VERSION_POLICY" "$INITIAL_VERSION"`. The helper treats `<none>` as the empty numeric sequence only for this first-release comparison. Exit 1 means equal or lower; exit 2 means policy-invalid input. For compatibility, this is the policy-general replacement for the legacy `semver-greater <derived> $BASE_VERSION` check and keeps its remedy: re-derive from `$BASE_VERSION` rather than raising the bump. `$BASE_VERSION` already accounts for the tag and every manifest, including the first-release sentinel case. Bringing every manifest to the derived version still happens once in step 6; describing that write here too would be one action described two ways. Present the version and per-commit classification to the user for confirmation.
-5. Derive the release date **once** — `RELEASE_DATE=$(date +%F)` — and reuse that single value for the changelog header, the Phase-2 `Released-at:` footer, and the Phase-3 Release; never hand-type the date a second time (`release_dates_consistent` verifies the changelog-header date equals the `Released-at:` date). Roll the `CHANGELOG:` footers from each `feat` / `fix` / `perf` / `refactor` commit into a new `## [${VERSION}] — $RELEASE_DATE` section in `$CHANGELOG` (the Keep-a-Changelog bracket heading this guard matches, not the bare `v`-prefixed form), grouped Added (`feat`) / Fixed (`fix`) / Performance (`perf`) / Changed (`refactor`, matching this repository's own changelog convention for non-user-facing-but-notable work). **A commit whose classification marks `breaking` true — the `!` bang after the type/scope or a `BREAKING CHANGE:`/`BREAKING-CHANGE:` footer, exactly the flag `classify-window` already computes and never re-derived here — rolls into its own `### Breaking` group instead of its type group, placed first among the section's groups.** A `feat!` no longer lands under `### Added` indistinguishable from an ordinary feature, and a breaking `chore!:` (which has no type group of its own) still gets one; an ordinary nonbreaking commit is never placed in `### Breaking`, and a commit already in `### Breaking` is never also duplicated into its type group. This is the same composed section text Phase 2's `<message-file>` and Phase 3's `<Phase-1 section file>` both read back (below), so `### Breaking` is visible in the changelog, the tag message, and the Release notes without a second composition pass. **Also harvest a `CHANGELOG:` footer from any `test`/`docs`/`chore`/`ci` commit that carries one**, into the same section's Changed group: its type says "not user-visible" but its footer is the more specific, deliberately-authored signal, and dropping it because of the type would be exactly the silent discard this guard exists to prevent (measured against this repository's own history, where such footers are a recurring, intentional pattern, not a mistake to reject). This harvesting rule does not by itself force a release — if the whole window is non-bumping, step 2's STOP still applies even when a non-bumping commit in it carries a footer; widening what a bare footer alone can trigger is out of scope here. Prior sections stay intact. Create the file with a `# Changelog` heading if absent. The changelog is a user-facing deliverable: apply `<plugin-root>/includes/anti-slop-design/core.md` §3.A (no prose-separator em-dashes in the entry prose) and §3.B (copy self-audit), and `<plugin-root>/includes/anti-slop-design/medium-documents.md` §7.A.1 changelog guidance, to each rolled entry. **Home for the composed section (MEDIUM, adversarial review 2026-07-31, previously unspecified):** besides landing in `$CHANGELOG` itself, this same section text is what Phase 2's `<message-file>` and Phase 3's `<Phase-1 section file>` both read back — write it to a scratch file created OUTSIDE the working tree (e.g. `mktemp`), never anywhere under the repo. A copy left inside the tree would either dirty the clean-tree state Pre-flight already required (this skill never re-runs Pre-flight mid-phase to notice) or, under a `payload: .` row, be swept straight into the very release window it is composing. Discard the scratch file once Phase 3 no longer needs it; it is working state, not a deliverable. **This scratch file is not required to survive across a session boundary** (HIGH, blind exercise run 19): `resume_publish` below explicitly permits Phase 3 to run in a LATER invocation than the one that composed this section — by design, since a fresh publish and a resumed one share the same Phase-3 authorization gate — and by then a `mktemp` file from a prior session is normally already gone. Phase 3 step 2 does not assume it survived; it reconstructs the same text mechanically from `$CHANGELOG` instead.
+5. Derive the release date **once** — `RELEASE_DATE=$(date +%F)` — and reuse that single value for the changelog header, the Phase-2 `Released-at:` footer, and the Phase-3 Release; never hand-type the date a second time (`release_dates_consistent` verifies the changelog-header date equals the `Released-at:` date). Roll the `CHANGELOG:` footers from each `feat` / `fix` / `perf` / `refactor` commit into a new `## [${VERSION}] — $RELEASE_DATE` section in `$CHANGELOG` (the Keep-a-Changelog bracket heading this guard matches, not the bare `v`-prefixed form), grouped Added (`feat`) / Fixed (`fix`) / Performance (`perf`) / Changed (`refactor`, matching this repository's own changelog convention for non-user-facing-but-notable work). **A commit whose classification marks `breaking` true — the `!` bang after the type/scope or a `BREAKING CHANGE:`/`BREAKING-CHANGE:` footer, exactly the flag `classify-window` already computes and never re-derived here — rolls into its own `### Breaking` group instead of its type group, placed first among the section's groups.** A `feat!` no longer lands under `### Added` indistinguishable from an ordinary feature, and a breaking `chore!:` (which has no type group of its own) still gets one; an ordinary nonbreaking commit is never placed in `### Breaking`, and a commit already in `### Breaking` is never also duplicated into its type group. This is the same composed section text Phase 2's `<message-file>` and Phase 3's `<Phase-1 section file>` both read back (below), so `### Breaking` is visible in the changelog, the tag message, and the Release notes without a second composition pass. **Also harvest a `CHANGELOG:` footer from any `test`/`docs`/`chore`/`ci` commit that carries one**, into the same section's Changed group: its type says "not user-visible" but its footer is the more specific, deliberately-authored signal, and dropping it because of the type would be exactly the silent discard this guard exists to prevent (measured against this repository's own history, where such footers are a recurring, intentional pattern, not a mistake to reject). This harvesting rule does not by itself force a release — if the whole window is non-bumping, step 2's STOP still applies even when a non-bumping commit in it carries a footer; widening what a bare footer alone can trigger is out of scope here. Keep an existing `## [Unreleased]` section at the top of the release sections. Insert the new version section below its complete body and above prior released versions; never place a released version above the Unreleased marker. Prior sections stay intact. Create the file with a `# Changelog` heading if absent. The changelog is a user-facing deliverable: apply `<plugin-root>/includes/anti-slop-design/core.md` §3.A (no prose-separator em-dashes in the entry prose) and §3.B (copy self-audit), and `<plugin-root>/includes/anti-slop-design/medium-documents.md` §7.A.1 changelog guidance, to each rolled entry. **Home for the composed section (MEDIUM, adversarial review 2026-07-31, previously unspecified):** besides landing in `$CHANGELOG` itself, this same section text is what Phase 2's `<message-file>` and Phase 3's `<Phase-1 section file>` both read back — write it to a scratch file created OUTSIDE the working tree (e.g. `mktemp`), never anywhere under the repo. A copy left inside the tree would either dirty the clean-tree state Pre-flight already required (this skill never re-runs Pre-flight mid-phase to notice) or, under a `payload: .` row, be swept straight into the very release window it is composing. Discard the scratch file once Phase 3 no longer needs it; it is working state, not a deliverable. **This scratch file is not required to survive across a session boundary** (HIGH, blind exercise run 19): `resume_publish` below explicitly permits Phase 3 to run in a LATER invocation than the one that composed this section — by design, since a fresh publish and a resumed one share the same Phase-3 authorization gate — and by then a `mktemp` file from a prior session is normally already gone. Phase 3 step 2 does not assume it survived; it reconstructs the same text mechanically from `$CHANGELOG` instead.
 6. **Sync `$TARGET`'s release surfaces to the repo — mechanically derived, never typed.** In this order; each sub-step depends on the one before it.
 
    **6a. Update the manifests.** Set every path in `$MANIFEST` to the derived version, **except a path also listed in `$GENERATED_MANIFEST`** — that one is never hand-edited; run the row's declared `generate` command (when declared) to regenerate it instead.

package/plugins/ca-pi/skills/ca-review/SKILL.md

@@ -8,9 +8,7 @@ argument-hint: "[path | #<pr> | <pr-url>] (defaults to the current diff)"
 
 Read-only review of a change. Routes to `dispatching-parallel-agents` (`<plugin-root>/routines/dispatching-parallel-agents/SKILL.md`): dispatches the reviewer fleet by path matrix, dedupes, then funnels through `finding-triage` → `verdict-aggregator` to a single in-memory verdict. No code is modified.
 
-**The change under review does not have to be yours.** `/ca-review #123` reviews an inbound pull request through the same fleet, the same matrix, and the same triage. That is the point of issue #80: a tool that only reviews the diff you just wrote is a linter for authors, not a gate for a team, and reviewing code you did NOT write is where a governance gate earns its keep.
-
-It is an ARGUMENT, not a second command. The scope resolver already took one, the fleet is scope-agnostic, and every phase downstream operates on a diff regardless of where it came from — so a `/ca-review-pr` would be a whole public surface (catalog, three host projections, README counts, sidebar) whose only distinguishing feature is where the diff was fetched from.
+`/ca-review #123` reviews an inbound pull request through the same fleet and triage as a local diff.
 
 ## Flow
 
@@ -33,14 +31,13 @@ It is an ARGUMENT, not a second command. The scope resolver already took one, th
    task-critical source refs from the review obligation. Pass the packet and
    those refs to `_contextselectlib.prepare_review_input` for each reviewer,
    then include its `reviewer_input` in that reviewer's actual input. The
-   returned `ready` state is a local preflight, not evidence that the host
-   delivered the input; check that boundary before using the review result.
+   returned `ready` state checks required inputs; it does not attest host delivery.
    For each actual reviewer, call `_contextselectlib.prepare_actor_delivery`
    with that selected packet, reviewer/task, absolute worktree and current
    source/host epochs. Send its bounded `delivery_text` with the review input
-   on `deliver`, retain the counted attempt, and stop the substantive verdict
-   on `blocked`. Re-select after resume, compaction, scope or worktree change;
-   a parent session marker or author receipt cannot stand for reviewer delivery.
+   on `deliver` and retain the counted attempt. On `advisory`, record the unknown
+   delivery observation and continue the review without further delivery retries.
+   Re-select after resume, compaction, scope or worktree change.
    Preserve applicable native instruction precedence. Source-scoped records,
    imported instruction text, map prose, and accepted ADR labels do not gain
    local normative authority by being copied into the packet.

package/plugins/ca-pi/skills/ca-sprint/SKILL.md

@@ -1,44 +1,30 @@
 ---
 name: ca-sprint
-description: Autonomous sprint — one interactive spec gate, then plan-to-PR execution with every auto-decision SMARTS-scored and logged. Hard gates remain true stops.
+description: "Run an autonomous sprint from maintained specs and plans, with truthful verification and no duplicate artifact approval ceremonies."
 argument-hint: "[goal] [--farm]"
 ---
 
 # /ca-sprint — autonomous sprint
 
-The autonomy mode. Brainstorm a sprint spec with the user — the one interactive gate — then execute
-the approved plan end-to-end without per-batch checkpoints, deciding "as the user" via SMARTS on
-every non-hard-gate point. Every auto-decision lands in `.codearbiter/sprint-log.md` (append-only)
-with a confidence flag; the `low`-confidence entries are exactly what the user reviews afterward.
-Nothing is hidden behind autonomy.
+The user's requested sprint establishes its working scope. Use `brainstorming` to clarify genuinely missing outcomes, `writing-plans` to maintain a practical plan, and `subagent-driven-development` to execute through real task dependencies without per-batch permission questions. Record meaningful choices and honest evidence; do not invent approvals, clear user stops, or infer tests passed from progress labels.
 
 ## Flow
 
-Load and follow `<plugin-root>/SPRINT.md` — it is the procedure. In brief:
+Load and follow `<plugin-root>/SPRINT.md`:
 
-1. **Sprint spec (STOP)** — `brainstorming` scoped to a sprint, then `writing-plans`. Explicit user
-   approval of spec AND plan before autonomy begins.
-2. **Autonomous execution (BLOCK)** — `subagent-driven-development` runs the plan; test-first via
-   `tdd`, two-pass reviewed, fresh-run verified. SMARTS decides non-hard-gate points; everything logs.
-3. **Land & summarize (BLOCK)** — `commit-gate`, then `finishing-a-development-branch`, which
-   auto-selects open-PR. `/ca-sprint` never merges and never discards; the merge decision is the user's.
+1. **Specify and plan:** build or resume the exact spec/plan representation. Ask about consequential missing choices, not about arbitrary approval hashes.
+2. **Execute:** work through task-scoped prerequisites and coherent batches, implement or delegate where useful, and check changed behavior. Retry affected failures without restarting a reviewer fleet.
+3. **Report and deliver:** show actual results, pending checks, and open choices. Use the existing authorized `commit-gate` and PR handoff; opening a PR does not authorize merging or publishing.
 
-Hard gates — `security-controls`, crypto/secrets/auth, irreversible ops, `/override`, an
-unresolvable `[CONFIRM-NN]`, merge-to-default — are NEVER auto-decided. They halt and surface.
+Real host/tool permissions, explicit security policy, irreversible operation limits and user stops remain intact. Artifact `DONE` means implementation reported complete, not independently verified acceptance.
 
 ## Arguments
 
-- **`"goal"`** — seed for the sprint-spec brainstorm.
-- **`--farm`** — cost-arbitrage backend: cheap workers implement under the same gates; Claude still
-  authors spec, failing tests, plan, and reviews everything. Pre-flights `FARM_API_KEY`.
+- **Goal:** intended sprint outcome and scope.
+- **`--farm`:** separately requested legacy Markdown preview backend; obey its provider, budget and circuit-breaker boundaries. HTML farm is disabled, and failure does not authorize a silent backend switch.
 
 ## Routes to
 
-`<plugin-root>/SPRINT.md` (mode body), which routes through `brainstorming`,
-`writing-plans`, `subagent-driven-development`, `commit-gate`, `finishing-a-development-branch`.
+`<plugin-root>/SPRINT.md` routes through `brainstorming`, `writing-plans`, `subagent-driven-development`, `commit-gate`, and `finishing-a-development-branch`.
 
-## When NOT to use
-
-- A single feature with human checkpoints → `/ca-feature`.
-- Work whose spec cannot be made concrete up front — the one interactive gate is load-bearing;
-  a thin spec makes hard-gate stops frequent instead of rare.
+For a single bounded feature, use `/ca-feature`. No repetitive initial spec approval interview is implied by either entry.

package/plugins/ca-pi/skills/ca-status/SKILL.md

@@ -30,10 +30,19 @@ reset.
 The orchestrator reads and presents:
 
 1. **Stage** — the `stage:` maturity value from `<project-root>/.codearbiter/CONTEXT.md` frontmatter.
-2. **Pipelines** — every slug in `<project-root>/.codearbiter/specs/` and `plans/`, with how
-   far each got: spec awaiting approval, spec approved / no plan, plan in progress (`ACCEPTED` count
-   vs. total from the plan's status column), or complete. An interrupted pipeline is resumable via
-   `/ca-feature` — say so on its line.
+2. **Pipelines** — every slug in `<project-root>/.codearbiter/specs/` and `plans/`, preserving
+   its existing representation. For HTML, use the installed engine's bounded structured reads
+   (`identity`, `index`, symbol-scoped `read`, or `task-context`) through
+   `<plugin-root>/includes/artifacts.md`; do not read rendered markup or execute verification
+   to obtain status. For Markdown, read its actual status ledger without creating a counterpart.
+   Report a spec with no plan, implementation in progress, or implementation complete. Count
+   `DONE` and historical `ACCEPTED` toward implementation completion while retaining their
+   distinct labels. Show verification separately: pending, failed, unknown, or the recorded result
+   and its applicability when available. Completion alone does not establish a passing check,
+   current acceptance, review, or release. Report missing/unreadable state as unknown, not complete.
+   A draft spec or plan is not awaiting permission. Show a genuine unresolved product decision,
+   explicit user checkpoint, or `BLOCKED` stop with its actual reason; status never clears it.
+   An interrupted pipeline is resumable via `/ca-feature` — say so on its line.
 3. **Open tasks** — the in-flight count from `<project-root>/.codearbiter/open-tasks.md`
    (top-level `- ` bullets excluding done `- [x]`; the same `_taskboardlib` count the
    SessionStart hook uses).
@@ -51,8 +60,8 @@ The orchestrator reads and presents:
 Stage:            N
 Branch:           <current branch>
 Pipelines:
-  <slug>          plan 3/7 ACCEPTED — resume with /ca-feature "<slug>"
-  <slug>          spec approved, no plan
+  <slug>          implementation 3/7 complete (2 DONE, 1 historical ACCEPTED); verification unknown — resume with /ca-feature "<slug>"
+  <slug>          spec present, no plan
 Open tasks:       N
 Open questions:   N ([CONFIRM-NN] unresolved)
 Overrides since last checkpoint: N