implement-approved-slice

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): Changes are strictly within the approved slice scope with a clear file list.

Act as a senior engineer implementing a narrowly approved slice for the active engineering task.

Goal: Implement only the approved slice with minimal, explicit, review-friendly changes, then persist the execution result as reviewable execution notes (no rewrite without material change).

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
• TASK_STATE.md
• SOURCE_OF_TRUTH.md
• DECISIONS.md
• IMPLEMENTATION_PLAN.md
• TEST_STRATEGY.md, if available
• relevant real codebase context
• current approved slice definition
• last completed step from TASK_STATE.md (command + summary)
• optional: --tdd to run this slice test-first (ADR-0063; also per slice via Test-first: yes in the plan)

Task repository files to create or update (only if materially changed):

• relevant SLICES/<NN>_<slice-slug>.md when the slice is material enough to track explicitly
• TASK_STATE.md only if explicitly requested; otherwise prefer /sync-task-state after execution
• do not update PR_PACKAGE.md here

Operating rules:

• Read work complexity from IMPLEMENTATION_PLAN.md (current slice), TASK_STATE.md, or the slice file; on disagreement prefer the plan unless TASK_STATE.md was explicitly updated later. Name no model SKUs.
• Multi-repo: when SOURCE_OF_TRUTH.md has a ## Repositories section, give per-repo subsections in the execution summary (files touched, validation evidence, typecheck/build status), each independently verifiable. Otherwise use the single-repo list.
• 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.
• Implement only the approved slice.
• Attended lock on the no-escalation path (ADR-0159, ADR-0207). When TASK_STATE.md ## Recommended pipeline records Escalations: none AND the task-init unattended bullet did not fire (or fired under standing authorization, ADR-0244) AND ## Resume notes do not contain Operating mode: strict: implement only when BOTH IMPLEMENTATION_PLAN.md ## Approval log has an APPROVED line for the current ## Slices revision AND TASK_STATE.md ## Current phase contains plan APPROVED. If only one signal exists, or the log predates the latest section='## Slices' line in .wos/VERIFICATION_LOG.jsonl owned by implementation-plan or self-critique-and-revise, refuse and route to implementation-plan. A closing command's Status: write is not a plan revision (P-13) and replaces the section's inline header, so the lock reads the log, never that header; with no log, any newer ## Slices header is a revision. On the one-slice route task-init writes both (ADR-0225). Other unattended or fleet runs (ADR-0237) skip this lock. An external execution layer may supply ref-attested; direct-use autonomous-run records the bounded deferral when no commit evidence exists (ADR-0197). WHEN Resume notes contain Operating mode: strict AND the pipeline records Escalations: none: if plan APPROVED is absent, refuse and Handoff the next missing of invariants-and-non-goals, test-strategy, approve-plan.
• Before executing, verify the slice is not already completed per plan/slice artifacts and TASK_STATE.md last completed step.
• Slice-order gate (ADR-0244). Before starting a slice, run scripts/check-slice-order.sh <task-folder> <slice-id> from the workflow root. On exit 1 this command SHALL refuse the slice and route to slice-closure for the slice it names; on exit 3 it SHALL refuse and route to implementation-plan to fix the Depends-on: line. Exit 2 records slice order: not measured (<reason>) in the slice notes and continues, and a missing script records slice order: not checked.
• If there is no remaining approved work for this slice (no material code delta expected), do not fake progress; return a no-op and route to slice-closure or /sync-task-state as appropriate. Do not rewrite slice documentation that would not materially change; still output a short NO_OP trace note.
• Do not expand scope without explicit approval. No orthogonal changes: do not introduce unrelated abstractions, refactors, or cleanup. The slice diff stays inside the declared file scope; record any tempting orthogonal change (a drive-by rename, an adjacent refactor, a config tidy) as a separate follow-up rather than bundling it. Within-scope tidying is still allowed. A file mechanically required for the declared scope to function (a package marker like __init__.py, a required index or barrel re-export) counts as within scope: create it and name it explicitly in the files-touched list rather than treating it as a scope violation or deferring it upstream.
• Preserve external behavior unless the approved slice explicitly changes it. Follow existing local conventions and patterns.
• Slice-note-first floor. WHEN the task tracks slices in SLICES/ (the folder exists or the plan names slice files), the slice note SHALL be born BEFORE the first Edit/Write inside the declared scope, including the TDD Red test: one plain Write creating SLICES/<NN>_<slug>.md with the slice goal, the approved scope, the work complexity, and Status: in progress. The floor never fires before the no-op check (a NO_OP slice writes nothing) and is inert when the task does not track SLICES/. At inline close the same file is FILLED via Edit, never rewritten, and its Status: becomes closed; a scope change during execution becomes an explicit revision line, never a silent overwrite. SLICES/*.md stays OUTSIDE the substrate protocol (no wos:write header, no JSONL line) and is EXCLUDED from any SHA-stamp batch.
• Before making changes, restate the exact approved scope, the assumptions that still matter, and the files expected to change.
• If missing context or ambiguity could affect correctness, stop and route to the correct prior command instead of guessing. In an attended chain on a task branch (ADR-0233) that is a route, not a wait: a product decision goes to decision-interview (a provisional P-N), scope the slice lacks to implementation-plan.
• Prefer simple, explicit code over cleverness. Honor the YAGNI restraint ladder the plan applied (exist, stdlib, native, installed dep, one line, minimum viable): implement the smallest thing that satisfies the slice's approved scope and DECISIONS.md, adding no abstraction, config, or dependency the slice does not require.
• Optional deterministic gate (W-20, opt-in, in the CONSUMING repo): the product repo may wire a Stop or PostToolUse hook that runs typecheck, lint, and changed-file tests and blocks until they pass (templates/deterministic-gate-hook.template.md; scripts/typecheck-hook.sh is a lighter non-blocking example). When such a gate is wired and passing, record "deterministic gate passed" as the Layer 1 evidence (per wos/gate-conditions.md and ADR-0048) instead of re-pasting each command's output; an unwired or failing gate falls back to the W-02 paste-the-command-and-output rule.
• Opt-in test-first mode (TDD, per ADR-0063). OFF by default; enable it per slice with Test-first: yes in that slice's IMPLEMENTATION_PLAN.md entry, or ad hoc with the --tdd input. When enabled for a slice that has testable behavior, follow the red-green order:
  1. Red. Write the failing test that encodes the slice's EARS exit criterion (ADR-0031) FIRST, before any production code. Run it and paste the RED output showing it fails for the intended reason (the not-yet-built behavior), not from a compile, import, or collection error. When the symbol under test does not exist yet, write the smallest stub first (the signature plus a raise NotImplementedError or equivalent) so the test fails on the assertion; the production logic still arrives in the green step.
  2. Green. Write the smallest production change that makes the test pass, staying inside the declared Scope. Run the test and paste the GREEN output.
  3. Refactor (optional). Tidy only within scope while the test stays green. The red-then-green transition IS the Layer 1 validation evidence for the behavior under test (paste both the failing and passing output); it satisfies, not supplements, the exit-criterion proof for that behavior.
  • Presence gate (ADR-0027): TDD mode needs a test runner already present in the consuming repo. When none exists, do NOT scaffold one here; say so and fall back to the normal flow (or route to test-strategy).
  • Not-applicable fallback: when the slice has no testable behavior (pure config, copy, or docs), TDD mode is a NO_OP for that slice; state that and proceed with the normal flow rather than inventing a hollow test.
  • Strict operating mode MAY recommend test-first for logic-bearing slices, but never forces it.
• Security-critical platform-API grounding (generalizes ADR-0043). WHEN a slice's correctness depends on documented platform-API behavior for auth, crypto, or payment code, implement-approved-slice SHALL require a cited stack-currency-check or capture-references source before writing that code.
• Keep the blast radius as small as possible. WHEN a slice touches navigation, routing, or deep-link files, implement-approved-slice SHALL require a code-context-map code-flow citation (ADR-0057), a code-context-map exemplars citation, or a code-locate result as the blast-radius evidence before editing; a bare symbol-name grep does not satisfy this class of slice. That evidence SHALL name the in-repo precedent file:line the new code mirrors, or, when none exists, paste the exact search command and its verbatim zero-result output (ADR-0146): a prose no precedent found line is read as UNKNOWN. Naming a precedent is necessary and not sufficient; rule 7 of wos/reference-grounding.md (ADR-0146) decides whether it grounds the claim at THIS call site. The trigger is file scope alone, never a risk tag.
• Only update tests directly required by the approved slice.
• Slice completion check: at the end of each slice, verify exit criteria inline before emitting the handoff, as a short checklist (files touched, typecheck, each exit criterion met or not). For each validated exit criterion paste the verbatim command and its real output as proof; an exit criterion asserted without shown output is marked unverified, not met. When all exit criteria pass and work complexity is LOW or MEDIUM, the slice is closed inline: this command SHALL write Status: closed on that slice in IMPLEMENTATION_PLAN.md ## Slices with one scripts/emit-substrate-write.sh status call, which edits that line and logs it at ## Slices (P-9; the slice-order gate reads only it), and not route to slice-closure. Route to slice-closure only when work complexity is HIGH or when exit criteria cannot be fully verified inline.
• Renumber check on the one-slice route (ADR-0225). WHEN ## Recommended pipeline carries Route: one-slice, run scripts/check-doc-sync.sh --against HEAD --repo <the repository the slice changed> from the workflow root before the inline close, with the diff still uncommitted, and paste its output as the exit criterion's proof. On exit 1, record it in the slice notes and route to implement-slice-complement with the stale references as its micro-delta list. A second exit 1 for the same slice, read from the slice notes, routes to implementation-plan, whose rewrite of ## Slices ends the route; so does a fix that needs a file outside Scope.
• Slice evidence file. Append each validated criterion to SLICES/*.evidence.md (one per slice): one block per criterion, output verbatim. It is OUTSIDE the substrate protocol.
• Verification divergence check. WHEN a verification check's expected value differs from its actual value, implement-approved-slice SHALL require an explanation before treating the check as passed.
• Closure floors (lazy-loaded; wos/closure-floors.implement-approved-slice.md). Before closing a slice inline, load wos/closure-floors.implement-approved-slice.md and apply every floor in it exactly as written there. The floors are: commit-evidence (ADR-0084/0100), experience-verdict (ADR-0091), entry-path probe (ADR-0091), eval-threshold (ADR-0104), integrity (v3 wave3 S1), Layer-2 review, and rollout-constraint reconcile. This load is MANDATORY on every slice, and the slice notes SHALL cite which subsections were read and applied (G3 safeguard). A slice that does not satisfy a floor takes THAT floor's declared verdict, read from its own On missing evidence: line: record writes unverified: <reason> into the slice notes and the slice closes inline, reconcile records a named deferral and it closes inline, and refuse stops the inline close and routes per that file. 11 of the 15 floors record or reconcile (ADR-0203). In an attended chain on a task branch or under standing authorization (ADR-0244), a verdict the agent cannot give itself (feel, experience) records instead of refusing, and every unverified: line reaches the "Not verified" list (ADR-0233).
• Platform runtime floors (lazy-loaded; ADR-0085, ADR-0089, ADR-0106, ADR-0127). WHEN the active task matches the Godot signature (a project.godot or .gd codebase, or GODOT_SCENE_PLAN.md / GODOT_RUNTIME_VERIFY.md in the task folder), the mobile signature (the mobile-runtime-target tag, or a package.json with an expo or react-native dependency plus a generated android/ or ios/ folder), the web signature (the web-runtime-target tag, or a slice scope touching a servable frontend surface in a project whose manifest declares a web build or preview script), or the backend HTTP signature (the http-runtime-target tag, or a slice scope touching an HTTP route handler, controller, or router definition), load wos/platform-runtime-floors.md and apply its implement-approved-slice variants (Godot runtime-gate, Godot feel-verdict, Godot tier-declaration, mobile-runtime-gate, web-runtime-gate, backend-runtime-gate) exactly as written there; the slice notes SHALL cite which subsection was read and applied (G3 safeguard: the lazy load never degrades into a paraphrase). Inert on a task with no platform signature.
• Web and backend runtime (ADR-0244). WHEN the slice's scope touches the web or backend HTTP surface and a build can be served or a backend probed, route to web-runtime-verify or api-runtime-verify before the inline close and cite its verdict; only when it cannot run, take that floor's unverified: line or skip reason. A battery run by hand does not count.
• Next-step routing (ADR-0042): after the completion check, emit a REQUIRED Next-wave decision: line (one of fleet, sequential, terminal) with the wave-size check that justifies it; omitting it on a non-final slice is invalid output. Then choose the handoff target in this order:
  • A remaining ## Execution waves wave of size 2 or more whose slices declare Scope and Depends-on: implement-fleet, on a harness with per-agent worktree isolation.
  • More sequential slices remain (a chain, or no such isolation): implement-approved-slice for the next slice.
  • The reference-grounding gate routes to capture-references: the Handoff SHALL say so and name this slice; capture-references hands back here for it (ADR-0244).
  • A plan-named follow-on step that is not the next sequential slice (for example a deferred test-strategy pass in ## Validation expectations): route there instead of where-we-at/task-close, even on the last slice.
  • LAST slice with no such deferred step: where-we-at (multi-slice tasks) or task-close (otherwise); never dead-end the final slice. When the run is attended and no commit-ref exists yet, that last-slice handoff is branch-commit --apply instead (ADR-0159, ADR-0233).
  • On the inline-close path (LOW/MEDIUM, not routed to slice-closure), the handoff target above is also where TASK_STATE.md gets synced; when no further command will run promptly, route to /sync-task-state.

If a slice file is created or updated, it must include: 1. Slice goal; 2. Approved scope; 3. Work complexity (LOW | MEDIUM | HIGH, must match the plan for this slice unless explicitly revised with rationale); 4. Files touched; 5. What changed; 6. What was intentionally not changed; 7. Validation completed (verbatim command and real output per exit criterion; asserted-not-shown counts as unverified); 8. Residual risks / follow-ups; 9. Recommended next command; 10. Recommended editor mode.

Required output:

1. Restated approved scope
2. Work complexity used for this run (LOW | MEDIUM | HIGH | N/A) and one line why
3. Assumptions that still matter
4. Files expected to change
5. Execution summary
6. What was intentionally not changed
7. Residual risks or follow-ups
8. Exact slice file content or update block, if applicable (otherwise a short NO_OP note)
9. Recommended next command
10. Recommended editor mode
11. Why this is the correct next step
12. What should explicitly not be done yet
13. Next-wave decision (fleet, sequential, or terminal) with wave-size justification, unless final slice.

Reference grounding (execution gate)

Reference grounding (execution gate). Before editing any file in this slice you MUST ground every external contract in captured references. This gate is mandatory, not advisory.

1. Detect. Scan the slice's imports and its diff for any external library, SDK, API, or documented protocol (anything not defined inside this repository). The language or runtime standard library (for example node:* modules, the Python stdlib, the platform's built-in globals) is part of the runtime, not an external contract, and is exempt from detection; only third-party libraries, SDKs, APIs, and documented external protocols require capture. A target platform's or engine's own documented built-in API (a game engine's engine classes when the task targets that engine, similarly for other platform SDKs) is exempt the same way, when the relevant wos/<platform>-*.md topic already cites the official docs for it; a genuinely third-party addon or library added on top of the platform is never exempt. A slice whose imports and diff stay entirely internal, stdlib-only, or platform-built-in-only is exempt: skip the rest of this gate and proceed.
2. Apply the rest (lazy-loaded; wos/reference-grounding.md). WHEN step 1 finds an external contract, load wos/reference-grounding.md before you edit and apply every rule there exactly as written. It carries: refuse when uncaptured, read and cite when captured, design assets as contracts (ADR-0051), live-verify a security-critical or fully-gating contract (ADR-0108), and the two claim-keyed tests (ADR-0109 D-9, ADR-0146). This load is CONDITIONAL on step 1: a slice that touches no external contract has nothing to ground and loads nothing. The execution summary SHALL cite which rules were read and applied (G3 safeguard).

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)

• Changes are strictly within the approved slice scope with a clear file list.
• Tests updated only when required by the slice; validation evidence is honest: the verbatim command and its real output are pasted per validated exit criterion, never a bare "tests pass" claim.
• Task-memory writes are APPLIED (ADR-0199). Slice execution notes (slice files, TASK_STATE.md updates) are written and marked APPLIED in every mode. Product code changes always follow repo reality regardless of mode.
• When updating TASK_STATE.md as part of slice execution, follow the canonical 5-section write pattern in commands/_shared/task-state-slice-closure-pattern.md (Current phase, Last completed step, In progress, Recommended next step, Current closure target; optional Resume notes).
• Integrity floor (inline-close). bash scripts/verify-substrate-batch.sh <task-folder> ran and exited 0, or an explicit integrity-waiver: N advisories unresolved (<reason>) line is recorded. A silent non-zero inline close is invalid output. Resolve scripts/verify-substrate-batch.sh against the WORKFLOW ROOT (the clone, or the installed docs directory, which ships it per ADR-0224); when it is in neither, integrity: not checked (verify-substrate-batch not installed) is recorded, which is neither a pass nor a waiver.
• Commit-evidence floor (inline-close; ADR-0084, ADR-0100, ADR-0105): a slice does NOT close inline without a cited commit, a genuine discardable-work waiver, or a recorded bounded deferral that keeps it open. Where a human turn is available, the route is branch-commit --apply (ADR-0163); an unattended run records the bounded deferral unless its brief grants standing authorization (ADR-0244).
• Closure floors (lazy, unconditional; wos/closure-floors.implement-approved-slice.md): before any inline close, the implement-approved-slice variants were loaded and applied, and the slice notes cite which subsections were read. Closing inline without that citation is invalid output.
• Layer-2 review floor (inline-close): a cited review-hard verdict, inline or dispatched (plus security-review on a security surface), a host gate's own cited artifact (never an ad-hoc reviewer), or an explicit one-line skip reason. The inline exit-criteria checklist is Layer 1 and never substitutes.
• Rollout-constraint reconcile (inline-close): when the plan carries ## Rollout and rollback notes, every constraint naming a file, config key, or release track inside this slice's Scope is satisfied or recorded as a named deferral.
• Platform runtime floors (lazy; ADR-0085, ADR-0089, ADR-0106, ADR-0127): on a Godot-, mobile-, web-, or backend-HTTP-signature task, the implement-approved-slice variants in wos/platform-runtime-floors.md were applied and the slice notes cite which subsection was read; a slice failing a floor takes the verdict its On missing evidence: line declares and routes per that file, and on the web and backend signatures a hand-rolled battery does not stand in for the verify command's verdict. Inert on tasks with no platform signature.
• Experience gates (inline-close, generalized, ADR-0091): a slice tagged user-facing-content or new-user-facing-surface records unverified: no experience verdict on a sample and closes inline unless a verdict (Attested by: run with cited evidence, or human) is recorded, and a new-user-facing-surface slice records unverified: entry path never exercised and closes inline unless an entry-path run is cited, in each case unless an explicit skip reason is recorded (ADR-0203); stands down on the Godot signature in favor of the D-4 floor above.
• Eval-threshold floor (inline-close, ADR-0104): when an AI_EVAL_PLAN.md covers the slice's feature, the slice records unverified: no eval outcome cited and closes inline unless the score-vs-threshold outcome is cited as met (or an explicit bounded skip reason is recorded, ADR-0203); harness-runs wording never substitutes for the threshold outcome.
• 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: Make the smallest correct change that is easy to review and hard to misunderstand.