approve-plan

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.