Approve Plan

---
name: approve-plan
description: |-
  Atomically lock IMPLEMENTATION_PLAN.md as the approved execution baseline and stamp TASK_STATE.md with the approval signal. Symmetric counterpart to approve-proposed but for the plan itself, not for arbitrary PROPOSED artifacts. Use on every plan implementation-plan produces or self-critique-and-revise revises; it self-runs a blinded review, and only an ESCALATED exit reaches the user. Do not use when the plan is still draft, when implementation-plan returned NO_OP, when the plan contains [NEEDS CLARIFICATION:] markers, or when revisions are still pending review.
metadata:
  category: "planning-and-validation"
  primary-cursor-mode: "Agent"
  multi-repo-aware: "false"
  context-layers-consumed: "memory"
  context-layers-produced: "memory"
  tools: "Read, Write, Edit, Bash, Glob, Grep"
  x-wos-profiles: "minimal, core, full"
  provenance: "first-party"
  suggested-model: "claude-haiku-4-5"
---
> **Output contract, in brief.** This body is over the per-skill re-injection cap, so
> after a compaction the sections below are truncated away while this summary survives.
> They remain authoritative in full; re-read this file before emitting if you need them.
>
> - `Standard output layout (required)`: Produce the command output using this structure (English only):
> - `Artifact changes`: Follow `## Global output contract` in `WORKFLOW_OPERATING_SYSTEM.md` for `APPLIED` / `PROPOSED` / `SKIP` rules. Every listed file...
> - `Command transcript`: Brief audit trail (max 4 lines; max 3 in no-op runs with `NO_OP_TRACE`).
> - `Handoff`: Use the adaptive ending format of `WORKFLOW_OPERATING_SYSTEM.md` `## Global output contract`. Every Handoff is one fenced `text` b...
> - `Definition of done (command output)`: IMPLEMENTATION_PLAN.md `## Approval log` entry appended with date + slice count + first slice id.


Act as a senior/staff engineer atomically locking the current `IMPLEMENTATION_PLAN.md` as the approved execution baseline for the active task.

Goal:
Verify the plan is ready to be locked, append an explicit `## Approval log` entry to `IMPLEMENTATION_PLAN.md`, update `TASK_STATE.md` to reflect the approval, and emit a Handoff to the correct execution command for the first wave (waves-aware per ADR-0042). Closes the gap that previously left plan approval implicit (the user signaled approval by invoking `implement-approved-slice` directly, which left no audit trail of when the plan crossed from "draft" to "locked").

**Waves-aware routing rule (ADR-0042, ADR-0243, stated verbatim wherever execution is routed):** when the approved plan's `## Execution waves` section shows a remaining wave of size 2 or more whose slices declare `Scope` and `Depends-on`, route to `implement-fleet` on a harness with per-agent worktree isolation; otherwise, or on a harness without it, route to `implement-approved-slice`. The fleet is that wave's default path, not an offer.

**Test-strategy gate (before the waves-aware rule):** WHEN no `TEST_STRATEGY.md` exists for the task AND the plan's changes affect important behavior, contracts, data flow, or regression risk (the `test-strategy` command's own use-when test), route to `test-strategy` first and name the execution command that follows it per the waves-aware rule. Approval and a test-strategy pass are not in tension: locking the plan and deciding the protecting tests are consecutive steps, and skipping straight to execution on a regression-risky change was a confirmed routing gap (4 of 10 dogfood paths, 2026-07-11 wave).

Mandatory context bootstrap (before any output):
- Read these sections in `WORKFLOW_OPERATING_SYSTEM.md` first:
  - `## LLM execution contract`
  - `## Editor mode policy` (mode definitions only; the tool mapping table is lazy-loaded in `wos/editor-mode-mappings.md` and needed only for non-Claude-Code tools)
  - `## Global output contract` (including **Adaptive handoff** and **Mode selection rule**)
  - `## Cross-cutting workflow guardrails`
- **Bootstrap tiers:** the light-weight commands (`branch-commit`, `what-next`, `where-we-at`, `slice-closure`, `compact-task-memory`) plus the high-frequency `implement-approved-slice` and `sync-task-state` (v3 wave1 item D) read the four sections above with two subsections of `## Cross-cutting workflow guardrails` skipped: `### External web access (centralized)` and `### Sequencing heuristics (by phase)`. Everything else is read at every tier, including `### Proposal vs approved persistence` and `### Substrate peer ownership (per ADR-0034)`, since all seven write substrate sections and reason about PROPOSED (`state-reconcile` stays on the full tier for cross-artifact judgment). The full tier is measured at 12109 tokens, the four always-read sections combined; the two skipped subsections are 1,034 of those (measured 2026-09-28), so the reduced tier is about 11,074. The leaf-reviewer tier (`verify-against-rubric`, ADR-0226) reads only `## Global output contract`, measured at 5215 tokens, plus its rubric.
- **Session bootstrap reuse (skip-if-unchanged; v3 wave1 item D):** WHEN this conversation already read the bootstrap sections in an earlier turn still VISIBLE in the context window AND `WORKFLOW_OPERATING_SYSTEM.md` has not changed since, the command MAY skip the re-read and cite the earlier one, emitting one Command transcript line: `Bootstrap: reusing turn <N> read, WOS unchanged`. Scoped exception to the context-budget re-fetch rule (`wos/context-budget.md`, "The re-fetch rule"), because these sections are one large, static, byte-identical read repeated every turn; every other tool result still re-fetches. VISIBLE means the section text itself is still present and quotable now, not merely that a record of the earlier read exists: a harness that clears a tool result while the record survives (ADR-0114) has not satisfied VISIBLE, and self-declared memory after a compaction never qualifies. A stateless-per-turn harness is excluded. The transcript line is mandatory; a silent skip is invalid output.
- **Resolving the spec and `wos/<topic>.md`:** canonical repository FIRST. Otherwise use active-adapter docs: `~/.claude/workflow-docs` (`CLAUDE_WORKFLOW_DOCS_DIR`), `~/.cursor/workflow-docs` (`WORKFLOW_DOCS_DIR`; project `.cursor/workflow-docs` on project installs), `~/.codex/workflow-docs` (`CODEX_WORKFLOW_DOCS_DIR`), or `<kimi-home>/workflow-docs` (`KIMI_WORKFLOW_DOCS_DIR`). Nonempty overrides win. Kimi home: `KIMI_CODE_HOME`, else existing `~/.kimi-code`, else existing `~/.kimi`, default `~/.kimi-code`. Use one root for both paths; try other adapters if absent or unknown. Report resolved root, fallback to other adapters, or missing mandatory context in `### Command transcript`. Installed snapshots refresh and prune retired topics only on sync.
- Read additional sections only when relevant to this command's role.
- Align all routing recommendations and next-command suggestions with the current command set.
- **Official next-command names only:** recommendations, including `Run now`, use registered names from `commands/<name>.md` or `commands/<name>/SKILL.md`; installed mode uses the available Fhorja command or skill inventory. No invented aliases. `Run now: none` with `Mode: N/A` ends only if no honest next step exists, defined under `### Official command names (routing integrity)` (ADR-0126).
Required inputs:
- active task folder path
- IMPLEMENTATION_PLAN.md (must exist and have been last touched by `implementation-plan` or `self-critique-and-revise`)
- TASK_STATE.md

Task repository files to update:
- IMPLEMENTATION_PLAN.md (append `## Approval log` entry)
- TASK_STATE.md (set status to `plan APPROVED`; set `## Recommended next step` waves-aware per ADR-0042, see Operating rules)

Operating rules:
- **Handoff:** end with the adaptive `### Handoff` block per `WORKFLOW_OPERATING_SYSTEM.md` `## Global output contract` (Mode A compact or Mode B full).
- **Operating mode (ADR-0008, ADR-0162).** WHEN `TASK_STATE.md ## Resume notes` contains `Operating mode: minimal`, `strict`, `teaching`, or `assisted`, load `wos/operating-modes.md` and apply that mode. WHEN the line is absent, use this command's native rules. Auto-suggestion is not a declaration.
- **Attended chain on a task branch (ADR-0233; defined in the spec `### Adaptive handoff`):** a person is present, `TASK_STATE.md ## Resume notes` carry a `Task branch:` line, and no `Operating mode: assisted` is declared. There a missing product decision becomes a provisional `### P-N` under `DECISIONS.md ## Provisional decisions` and the chain continues, and so under standing authorization (ADR-0244). Other unattended and fleet-dispatched runs (ADR-0237) keep every rule below as written.
- **The one-slice route does not reach this command (ADR-0225).** `task-init` writes that plan's single slice and its approval line itself, and `check-doc-sync.sh --against HEAD` at `implement-approved-slice`'s inline close stands in for the blinded review. A route plan that `implementation-plan` rewrites is an ordinary plan and comes here as usual.
- **Refusal conditions (each independently triggers `NO_OP_TRACE`):**
  - IMPLEMENTATION_PLAN.md does not exist.
  - `bash scripts/check-live-markers.sh <task-folder>` exits non-zero (B2, 2026-09-17). It reports an UNRESOLVED clarification marker per `wos/cross-cutting-workflow-guardrails.md` -> `### NEEDS CLARIFICATION inline marker`; route to `decision-interview` (in an attended chain it records a provisional `### P-N`, ADR-0233). Run the script; do not eyeball the file. The script strips fenced blocks and backticked code spans before looking, which is the mechanical difference between a live marker and prose about one. Exit 1 is a live marker. Exit 2 means it read nothing (no such folder, or none of `IMPLEMENTATION_PLAN.md`, `TASK_STATE.md`, `DECISIONS.md`), which the first condition above already refuses; it is never a clean verdict. Resolve `scripts/check-live-markers.sh` against the WORKFLOW ROOT (the clone, or the installed docs directory, which ships it per ADR-0224), never against the task repository. When it is in neither, or otherwise unreachable, this condition does NOT fire on the absence: write `live-markers: not installed, plan not checked` in `### Command transcript` and fall back to reading the file for an unbackticked marker opening a bullet, naming the fallback there too.
  - The most recent run that touched IMPLEMENTATION_PLAN.md was not `implementation-plan` or `self-critique-and-revise` (heuristic: check the file's last write annotation or the TASK_STATE.md `Last completed step` field).
  - TASK_STATE.md already shows `plan APPROVED` for the same plan revision (idempotency; do not re-approve).
  - The cross-artifact consistency check fails (distinct from the NEEDS_CLARIFICATION check, which only catches unresolved markers): a slice does not trace to a LOCKED `### D-N` entry in `DECISIONS.md ## Locked decisions` (read the slice's `Decision-ref:` field when present, fall back to content-level tracing otherwise; a `Decision-ref:` resolving only to a `<!-- PROPOSED by ... -->` block is a blocking mismatch routed to `decision-interview` to lock the decision first, per ADR-0105 amending the ADR-0103 gate semantics; a `Decision-ref:` reading `rests on provisional P-N` traces labeled, never as authorization (ADR-0233); a task whose `DECISIONS.md` holds no locked decisions AND whose slices cite no PROPOSED-only refs PASSES this sub-check, there being nothing to trace), a slice violates an `INVARIANTS_AND_NON_GOALS.md` invariant, the plan's exit criteria do not cover the locked decisions, a `## Requested deliverables` ledger row tagged `user-facing-content` or `new-user-facing-surface` has no covering slice carrying the matching `Deliverable-tag:` (deliverable-tag propagation per ADR-0103; a ledger-carried tag silently dropped by the plan is a blocking mismatch), or (when the plan carries a `## Spec coverage` table from spec-ingest mode, ADR-0061) a spec item in that table maps to no slice and has no recorded de-scope or `[NEEDS CLARIFICATION:]` marker. This is a read-only assertion at the approval boundary, not a re-plan; name the specific mismatch and route to `decision-interview` (decision gap) or `implementation-plan` (plan fix) before approval.
- **Run the deterministic coverage check FIRST (B0b, 2026-09-17).** Before the blinded review, run `bash scripts/check-plan-coverage.sh <task-folder>` and read the exit code. `implementation-plan` runs it at creation time, and the plan may have changed since. Resolve `scripts/check-plan-coverage.sh` against the WORKFLOW ROOT (the clone, or the installed docs directory, which ships it per ADR-0224), never against the task repository.
  - Exit 0: say so in `### Command transcript` and continue to the review.
  - Exit 2 (it printed `Plan-coverage: not measured`), exit 127, or the script in neither root: coverage NOT checked. Write `plan-coverage: not checked (<reason>)` in `### Command transcript`, never that it passed, check the deliverable-tag rule by reading `TASK_STATE.md ## Requested deliverables` against the slices' `Deliverable-tag:` lines, and continue to the review.
  - Non-zero on a `deliverable-coverage` row: this is the half the blinded review never checks, because its rubric asks what the plan commits to, never what it leaves out. Report every unmatched deliverable by name, do NOT refuse, and route to `implementation-plan` to either cover it or de-scope it with a reason. A checkpoint reports and routes; the hard refusal on an uncovered deliverable belongs to `task-close`, which is a finalization.
  - Non-zero on a `domain-terms` row (rule 6, ADR-0245): report each uncovered term by name, do NOT refuse, and route to `implementation-plan` to tag a test condition with it, as for a deliverable row. The blinded reviewer never receives `DECISIONS.md`, so this check is the only one.
  - Non-zero on a `decision-coverage` or `slice-fields` row only: report it and continue to the review, which asks the harder version of the same question.
  - A deliverable row marked de-scoped or done is already skipped by the checker; do not re-report it.
- **Blinded authorization review (ADR-0208, and the evidence this command's approval rests on).** WHEN no refusal condition fired, dispatch exactly ONE `verify-against-rubric` run BEFORE appending the approval log. Its reviewer is a `judgment` dispatch (ADR-0236): the session applies the judgment row of `wos/model-routing.md ## Dispatch roles`, and never a weaker one, whatever model runs this command.
  - Artifact: the task's `IMPLEMENTATION_PLAN.md` path.
  - Locked rubric, one falsifiable question rather than a quality opinion: does this plan commit the product to anything `DECISIONS.md ## Locked decisions` does not authorize? Per slice: does it trace to a locked decision through `Decision-ref:` or an exit criterion, or record an explicit reason for tracing to none? The identifier-matching half of that question is already asserted deterministically by `scripts/check-plan-coverage.sh` and is NOT this review's job. What IS its job is the half no grep can reach: a slice that CITES a locked decision but exceeds what that decision authorizes.
  - **Cited authorization inputs:** paste each cited `### D-N` entry verbatim from `## Locked decisions` into the rubric, never the full decisions file. Run `bash scripts/build-plan-review-input.sh <task-folder>` from the workflow root; its JSON carries the artifact identity, rubric, source hashes and brief source. Recheck hashes before dispatch. It selects live references, excludes unrelated history and refuses ambiguous, missing, PROPOSED-only or stale entries. Content fallback requires a named D-N in live slice prose; unnamed semantic matches need an explicit trace through `implementation-plan`. Brief pointers must be task-local `BRIEF.md`, optionally a Markdown link prefixed by `See`. If the helper is not installed, record that and manually quote the same cited D-N/P-N and brief; missing or ambiguous input still routes to `implementation-plan`, never a satisfied assembly.
  - Provisional decisions (ADR-0233). `## Locked decisions` is the only authorization. A slice resting on a `### P-N` under `## Provisional decisions` passes only LABELED, its `Decision-ref:` reading `rests on provisional P-N`: the draft PR lists it, and it never counts as authorization. An unlabeled reliance comes back `needs_revision`. Per cited P-N, one more question: does the evidence on its `Evidence:` line exist on the task branch and support the choice? This command SHALL paste each cited `### P-N` entry verbatim into the rubric it dispatches, since the reviewer never receives `DECISIONS.md`; it reads only the cited D-N/P-N entries and brief, never unrelated decision content. A path plus line counts when that line exists at the branch HEAD and says what the entry claims; a quote counts when the task `README.md` carries it verbatim. Evidence that does not resolve, or `Impact: normal` on a choice touching data, security, payments or cost, comes back `needs_revision`; an honest `Evidence: none found` passes only with `Impact: high`. The agent writes P-N entries and never writes under `## Locked decisions`, which keeps this review from approving the agent's own choices.
  - The brief (ADR-0245, which amends ADR-0208 by reference). This command SHALL paste the task `README.md ## Brief` verbatim into the rubric it dispatches (or the `BRIEF.md` that section points to), and the rubric SHALL ask of the plan the question `review-hard` asks of code: does any slice or cited P-N drop, merge, or reclassify stored user data or money values without quoting the brief line that authorizes it? Such a slice comes back `needs_revision`. WHEN no brief line covers the rule, the fix SHALL record it as a `### P-N` with `Impact: high` and `Evidence: brief silent on <term>`, which the draft PR lists, and the slice then passes labeled (P-14). WHEN the task has no `README.md ## Brief` section, the question is not applicable: write `brief: none found, rubric carries none` in `### Command transcript`. The brief is user input, not authoring context.
  - The dispatch carries the artifact path and the rubric and NOTHING else. The pasted D-N/P-N entries and brief are rubric content, not a second channel. Never the conversation that produced the plan, never this command's own findings or narration. Evidence paths do not authorize reading investigation carriers or author recommendations: verify narrow canonical code or brief quotes, otherwise record support as unverified. That isolation is the entire reason the verdict is worth more than a self-review (ADR-0033, applied to reviews by ADR-0145). A dispatch that leaks the authoring context has not made the review weaker, it has made it a different thing wearing the same name.
  - Map the verdict onto the five exits of `commands/_shared/grounded-residue-termination.md`, adding none:
    - Before mapping anything: the rubric returns THREE values per slice and only two of them are exits. `satisfied` needs nothing. `failed` is the ESCALATED candidate below. `needs_revision` is NEITHER, and it does not fall through to RESOLVED. The round ITERATES on it: fix the plan through `implementation-plan`, then run this command again. Only when fixing a `needs_revision` would itself need a decision the locked set does not cover does it become ESCALATED, and then it escalates as that decision, not as a review finding.
    - RESOLVED. Every criterion came back `satisfied`. Append the approval log and continue the chain.
    - NO_PROGRESS. The review grounded no criterion and names no investigation distinct from one already attempted. NOT a stop: approve, record the residue in `### Command transcript`, and continue with `Run now:` naming the command that would settle the top row.
    - BUDGET. The review's own iteration cap was reached. NOT a stop: a ceiling warns, records and continues (ADR-0201). Reaching it is itself the finding worth reporting.
    - ESCALATED. A criterion came back failed AND the failure is a product commitment the locked decisions do not authorize. This is the ONLY exit that hands back to the maintainer. Name the slice, the commitment, and the decision that does not cover it. Asking for approval in general is invalid output here; the ask names what could not be grounded or it is not this exit. In an attended chain on a task branch a product decision does not stop the chain (ADR-0233): record the exit, then `Run now: decision-interview`, which records a provisional P-N the plan then cites; the hand-back stays for stop reason 1. Unattended and fleet-dispatched runs (ADR-0237) keep the hand-back, save under standing authorization (ADR-0244).
    - ENVIRONMENT. No sub-agent capability is reachable. Emit the terminal form (`Run now: none`, `Mode: N/A`) naming what would unblock it, per ADR-0126. In an attended chain on a task branch or under standing authorization (ADR-0244), approve instead and end the approval log entry with `unverified: blinded plan review not run (<reason>)`, which the draft PR lists under "Not verified" (ADR-0233).
  - Do NOT gate on how certain the review sounded. There is no confidence field, no numeric threshold and no self-assessment prompt in this mapping, and adding one would be the exact shape ADR-0109 D-2 forbids and `scripts/check-claim-grounding.sh` refuses.

- **Deeper round on the Strict surface (ADR-0208; the list is copied from ADR-0184, not restated from memory).** WHEN the surface is auth, payments, compliance, PII, or multi-tenant isolation, run a SECOND blinded pass after the first, against a DIFFERENT locked rubric: the task's `INVARIANTS_AND_NON_GOALS.md`. It is a `judgment` dispatch too.
  - A different question, not the same one twice. The first pass asks whether the plan commits the product to anything the locked decisions do not authorize. The second asks whether the plan holds the invariants the task declared and whether any slice reaches a stated non-goal. Running one rubric twice would cost a dispatch and buy nothing, while looking like depth.
  - The artifact is already there. ADR-0184's Strict disqualifier already escalates `invariants-and-non-goals` into the pipeline on exactly this surface, so depth costs one more dispatch and no new machinery.
  - WHEN `INVARIANTS_AND_NON_GOALS.md` is absent on a Strict-surface task, do NOT quietly proceed on one pass. In an attended chain on a task branch or under standing authorization (ADR-0244) whose profile carries it, `Run now: invariants-and-non-goals` and come back (ADR-0233). Otherwise take the ESCALATED exit naming its absence, and name `invariants-and-non-goals` as what would produce it where the installed profile carries that command. ESCALATED hands back to the maintainer rather than continuing the chain, so this is information for them, not a handoff: the command sits in the `core` and `full` profiles and a `minimal` install does not have it. A surface that trips a categorical escalation and then gets the shallow round is the failure this rule exists to prevent.
  - The surface wording above is byte-identical to `commands/task-init.md` and to ADR-0184. One list with three carriers is two more than attention can maintain, which is why the test asserts they match rather than trusting that they do.
  - Depth is the control, not a stop. A strict surface does not get a human gate back; it gets a second reviewer (ADR-0208). The chain hands back here only through ESCALATED, like everywhere else.

- **Record the verdict (ADR-0208).** Every approval appends exactly ONE `plan_review` line per pass to the project's `OUTCOMES.jsonl`: `python3 scripts/compute-task-outcome.py --plan-review <task-slug> --project <client__project> --exit <EXIT> --rubric <rubric> [--escalated-on <what could not be grounded>] >> projects/<client__project>/OUTCOMES.jsonl`. A Strict-surface task writes two lines, one per pass, each naming its own rubric.
  - The helper only PRINTS the line; the `>>` is the append. Its exit 0 proves the line was computed, not written. Report the append as `APPLIED` only after the file's last line is that `plan_review` line; otherwise name the failure. Measured 2026-09-22: a run reported this append APPLIED on the helper's exit 0 alone, and the ledger did not exist (ADR-0217). Resolve `scripts/compute-task-outcome.py` against the WORKFLOW ROOT (the clone, or the installed docs directory, which ships it per ADR-0217), never against the task repository; when it is in neither, name that in `### Command transcript` instead of reporting the append.
  - Why this is part of the decision and not bookkeeping: ADR-0208 ACCEPTED the measured 39-percent plan-rejection rate and replaced the control instead of disputing the number, which moves the burden of proof onto the replacement, which only sampling these lines across tasks can discharge; a replacement leaving no trail could not be judged at all.
  - The helper refuses an exit outside the five rather than recording it: a value outside that set means the mapping drifted, and a recorded drift is worse than a refused write.
  - Like every other line in that ledger it is a record, never a gate. A failed append is reported in `### Command transcript` and does NOT block the approval (`templates/OUTCOMES.schema.md ## Writer rules`).

- When proceeding:
  - Append a new entry to IMPLEMENTATION_PLAN.md `## Approval log` (create the section if absent): `<YYYY-MM-DD>: APPROVED -- baseline locked for execution. Slices in scope: <N>. First slice: <slice id>. Rests on provisional: <P-N ids, or none>.`
  - Update TASK_STATE.md per the canonical 5-section write pattern in `commands/_shared/task-state-slice-closure-pattern.md`. Set `## Recommended next step` as a three-way branch. WHEN the test-strategy gate fires (no `TEST_STRATEGY.md` exists and the change carries regression risk), persist `Command: test-strategy / Mode: Plan / Why: plan locked; no TEST_STRATEGY.md and the change carries regression risk; then <implement-fleet or implement-approved-slice per the waves-aware rule>`. That `Plan` is the step's intent: the same turn continues into it in the current harness mode and model (ADR-0241). Otherwise apply the waves-aware routing rule: when it names the fleet, `Command: implement-fleet / Mode: Agent / Why: plan locked, Wave 1 [<slice ids>] is parallelizable`; otherwise `Command: implement-approved-slice / Mode: Agent / Why: plan locked, begin first slice <id>`.
  - Set TASK_STATE.md `## Current phase` to include `plan APPROVED` if it was not already.
- **Overnight-run routing (D-3 of the 2026-07-27 readiness task).** WHEN the maintainer has said this plan will be executed unattended (overnight, detached, or hands-off) rather than supervised wave by wave, save a session under standing authorization (ADR-0244), which runs the plan itself, the recommended next step is `autonomous-readiness`, not `autonomous-run`: persist `Command: autonomous-readiness / Mode: Ask / Why: plan locked; an unattended run needs a BOOT verdict before <autonomous-run>`. This precedes the waves-aware branch above and replaces nothing in it: approval has just been recorded here, and a readiness verdict never stands in for it. A supervised run keeps the existing three-way branch untouched.
- Do not modify slice content, decision content, or any other artifact. This command is for locking the existing plan, not editing it.

Required output:
1. Slice count and complexity tier distribution from the plan (e.g., "8 slices: 3 LOW, 4 MEDIUM, 1 HIGH")
2. First slice identifier and one-line scope
3. Confirmation that no `[NEEDS CLARIFICATION:]` markers remain AND that the cross-artifact consistency check passed (every slice traces to a LOCKED `### D-N` entry in `DECISIONS.md ## Locked decisions` via `Decision-ref:` or content, a PROPOSED-only `Decision-ref:` being a blocking mismatch per ADR-0105, a `rests on provisional P-N` ref tracing labeled per ADR-0233, or the task has no locked decisions and no PROPOSED-cited refs; no slice violates an invariant; exit criteria cover the locked decisions; every tagged ledger deliverable has a covering slice tag per ADR-0103), or NO_OP_TRACE naming the unresolved markers or the consistency mismatch
3a. The blinded review's exit label (one of RESOLVED, NO_PROGRESS, BUDGET, ESCALATED, ENVIRONMENT), the rubric it ran against, and, on ESCALATED, the slice and the unauthorized commitment it names. An approval reported without its review verdict is invalid output (ADR-0208).
3b. Each provisional P-N the plan rests on and whether its evidence resolved, or `none` (ADR-0233).
4. The exact `## Approval log` entry appended (date + slice count + first slice id)
5. The TASK_STATE.md sections updated
6. Recommended next command: `autonomous-readiness` when the maintainer declared the run unattended, save under standing authorization; otherwise the existing three-way branch (`test-strategy` when the test-strategy gate fires, naming the execution command that follows it per the waves-aware rule; otherwise `implement-fleet` or `implement-approved-slice` for the first slice, per the waves-aware routing rule)

### Claim grounding (active epistemic humility)
**Claim grounding (active epistemic humility).** This block governs what you may assert and how you record it. It is keyed to the substrate section you are writing, not to which command is running, and it is INERT on any output that writes none of the claim-bearing sections below. Full contract and rationale: `wos/active-epistemic-humility.md`.

1. When this applies. This block fires ONLY while you are writing a claim-bearing substrate section: `TASK_STATE.md ## Current known facts`, `## Risks to watch`, `## Observations`, `## Active files in scope`, `## Canonical decisions`; `DECISIONS.md ## Locked decisions`; `IMPLEMENTATION_PLAN.md ## Current gaps`, `## Risks and mitigations`; `IMPACT_ANALYSIS.md`; `EXTERNAL_RESEARCH.md`; `REFERENCES.md`; or any section whose content is a statement a later command or a human decision will act on. WHEN your output writes none of these, this block imposes nothing: skip it and proceed. This is the D-13 inert clause; a fully-grounded or claim-free output pays nothing.

2. The unit is the load-bearing claim. A load-bearing claim is one a downstream command or a human decision consumes. A passing aside is not load-bearing; a statement someone will act on is. Apply the rest of this block per load-bearing claim, not per sentence.

3. Ground it or abstain. Before you assert a load-bearing claim, trace it to the enumerable grounded set: a captured `REFERENCES.md` entry, a file read in this session, command output actually seen, or a passing deterministic gate. A claim supported only by model memory is OUTSIDE the grounded set, including when you are right, because that support is not observable. WHEN a load-bearing claim falls outside the set, do NOT assert it: either investigate until it is grounded, or abstain per rule 6.

4. Status records provenance, never confidence. WHERE you attach an epistemic status to a claim, the status names WHERE THE CLAIM CAME FROM: a `REFERENCES.md` entry title, a file path plus line, or the gate output it came from. It SHALL NOT express a degree of certainty. Do NOT add a confidence field, a numeric threshold, or a self-assessment prompt anywhere; a self-reported confidence signal is not a usable control signal (`wos/active-epistemic-humility.md` Part 1.3). A status whose referent slot is empty is read as UNKNOWN, not as a weak yes.

5. Persisted claims carry the status; chat-only claims carry it when they route. Every load-bearing claim you write into a task-memory artifact carries its provenance referent, and that referent travels with the claim so a later command reads it too; do not drop it at the write boundary. A load-bearing claim that appears only in a chat-turn output carries a status only when it crosses the grounding boundary and triggers a route (an abstention, an escalation).

6. Abstain as a routed continuation, never a bare refusal. WHEN you abstain, name the specific investigation that would settle the question AND route to the command that runs it (`capture-references`, `code-locate`, `incident-triage`, or the fitting one). A withholding that stalls the work is invalid output. Abstention is distinct from `NO_OP`: `NO_OP` means there is no work to do; abstention means there is work and the grounding to do it is missing.

7. An unfired gate is not evidence. The absence of a fired check does not mean grounding existed. Do not read silence here as a pass.
### Standard output layout (required)
Produce the command output using this structure (English only):

### Artifact changes
Follow `## Global output contract` in `WORKFLOW_OPERATING_SYSTEM.md` for `APPLIED` / `PROPOSED` / `SKIP` rules. Every listed file carries one of those three tokens, in Lean output too; a prose verb like "written" is not a label.

### Command transcript
Brief audit trail (max 4 lines; max 3 in no-op runs with `NO_OP_TRACE`).

### Handoff
Use the adaptive ending format of `WORKFLOW_OPERATING_SYSTEM.md` `## Global output contract`. Every Handoff is one fenced `text` block with all four lines, `Run now:`, `Mode:`, `Work complexity:` and `Reason:`, on a stop and on a refusal too; the terminal form is `Run now: none` with `Mode: N/A`. A new `Mode:`, a model or a fresh session is never a stop, an offered choice is one, and `Reason:` names a role, never a model.
### Definition of done (command output)
- IMPLEMENTATION_PLAN.md `## Approval log` entry appended with date + slice count + first slice id.
- TASK_STATE.md reflects `plan APPROVED` and the recommended next step matches the waves-aware routing rule (`implement-fleet` for a parallelizable wave, else `implement-approved-slice`).
- No `[NEEDS CLARIFICATION:]` markers present in the locked plan (verified before approval).
- The cross-artifact consistency check passed (slices trace to LOCKED `### D-N` entries in `DECISIONS.md ## Locked decisions` via `Decision-ref:` or content, a PROPOSED-only `Decision-ref:` being a blocking mismatch per ADR-0105, a `rests on provisional P-N` ref tracing labeled per ADR-0233, with the no-locked-decisions-and-no-PROPOSED-cited-refs case passing; no `INVARIANTS_AND_NON_GOALS.md` invariant violated; exit criteria cover the locked decisions; every tagged `## Requested deliverables` ledger row has a covering slice `Deliverable-tag:` per ADR-0103; and any `## Spec coverage` table from spec-ingest mode has every spec item mapped to a slice or carrying a recorded de-scope or marker), or the run is NO_OP_TRACE naming the mismatch.
- `## Locked decisions` stayed the only authorization; slices resting on a P-N carry the `rests on provisional P-N` label and each cited P-N's evidence was checked (ADR-0233).
- The dispatched rubric carried `README.md ## Brief` verbatim and asked the data and money question of the plan, or the transcript says no brief was found (ADR-0245).
- Handoff points to `implement-fleet` or `implement-approved-slice` per the waves-aware routing rule; or to `test-strategy` first per the test-strategy gate when no `TEST_STRATEGY.md` exists and the change carries regression risk; or to `autonomous-readiness` when the maintainer declared the run unattended, save under standing authorization.
- Before declaring this output done, confirm it satisfies the shared **Definition of done (command outputs)** and **Gate conditions** in WORKFLOW_OPERATING_SYSTEM.md.

Quality bar:
Approval is atomic. Either the plan is locked, the Approval log records it, and TASK_STATE.md reflects it -- or none of those happened (NO_OP_TRACE). Half-applied approvals are not allowed.