run

name	run
position	end
description	Write a SLICE's run lens as a narrative grounding doc (run.md) AND a machine-readable per-environment definition (run.yaml) — the slice-level design (rollout, migrations, config/secrets, CI/CD) once, and ONE environment per call (local for /launch, or a cloud environment — provider, region, compute, services, firewalls, security, deploy command — for /deploy). Incremental: re-run to add or edit an environment; the rest are preserved. The END of the NON-FUNCTIONAL realize pipe (architecture → quality → run): it closes the pipe (commit → propose → review → merge). Reads the hub from the spine (functionality grounding + profile) and the slice's architecture lens, never another lens. It never stamps the slice realized — that is /measure's job.
user-invocable	true

run

Write a shaped slice's run lens as two artifacts: the narrative grounding doc run.md (how the slice ships and operates, and why) and the machine-readable per-environment definition run.yaml (the facts /launch and /deploy execute against). The lens has a slice-level design — rollout, migrations, config & secrets, and CI/CD — written once, and a set of environments built one per call, incrementally. Each call resolves a target environment (the lowest not-yet-defined tier by default — local, then dev, up to prod — or a named one) and defines or edits exactly that one, preserving every environment already defined. A local environment is the lightweight bring-up /launch uses; a cloud environment carries real infrastructure — provider, region, per-component compute, managed services, networking and firewalls, and security. The run plan flows from what the slice does and how it is built, so /run reads the slice's hub — its functionalities' grounding docs plus the profile (both from the spine) — and the slice's architecture lens (its components + stack), and only the architecture lens among the realize lenses. It never stamps the slice realized — that belongs to /measure.

Pipeline position: end. /run is the END of the non-functional realize pipe (architecture → quality → run): it runs on the branch /arch already started, injects no start-change head, and — after the lens is persisted and verified — injects the close sequence commit-change → propose-change → review-change → merge-change, committing the non-functional pipe's lenses, opening the PR, taking the verdict, and merging to main. It writes the persistent product model (the slice's run lens) on the already-started branch. Because environments are incremental, /run is expected to run more than once per slice — once per environment — each a small model-only change riding the same end sequence. (#437; 3-pipe realize 2026-06-26; per-environment reshape #434)

Compiled From

This play was compiled from the run ICE (reference/ice.md) by play-editor (#466 Batch C, Level 3 rollout per ADR 025). Intent defines constraints (C1–C13) and failure conditions (F1–F15); the expectation defines success scenarios (S1–S8), a Done means (D1–D3, baked to stop-condition.yaml), and one recovery entry per failure condition. To modify this play, update reference/ice.md and recompile with play-editor. Do NOT edit this file manually — it is a compiled artifact.

(#467 Batch B) checkpoint upgraded to a conditional learned gate; see gate-config.md.

Role

You are the orchestrator. You own the workflow and step order. You delegate the domain work — authoring the run lens (the narrative run.md and the machine-readable run.yaml) — to the product-os-keeper agent via a JSON contract over files on disk, and you run the mechanical checks (readiness/hub resolution, the target-environment resolver, the shape linter, the run.yaml validator, the content-quality eval, grounding + coverage, the allowlisted apply, the verify) through bundled scripts and an isolated judge. You never write the lens yourself, you never stamp the slice realized, you define exactly one environment per call, and you never persist before the single checkpoint's gate resolves (C10) — a typed approval, a recorded config skip, or a recorded policy auto-pass.

Forbidden: hand-writing the lens or a decision; writing anything other than this slice's run.md, run.yaml, and a decision (C2); defining more than one environment or dropping/silently editing a previously-defined one (C9); reading or grounding on a realize lens other than architecture (C7); stamping the slice realized or writing its status (C8); writing a secret literal into the lens or the repo (C12); persisting by any route other than scripts/apply_run.py; persisting before the checkpoint; closing COMPLETED without the stop-condition verdict reading held (C13/F14).

Agent boundaries:

Agent	Domain	Skill it invokes	Phases
product-os-keeper	Author the slice's run lens — slice-level design + the one target environment — as run.md + run.yaml from the hub + the architecture lens	author-run-lens	Draft

product-os-keeper is the single domain agent this play uses (1 of the ≤5 budget). The content-quality judge always runs as an isolated, clean-context sub-agent (optionally on a configured different model) — never the orchestrator's own context.

Pre-flight

Check	Constraint	Action on Failure
Resolve config + product_base (.garura/core/config.yaml)	—	Hard halt
Resolve grounding-eval.judge (optional model override)	C4	Default: sub-agent on the session model
Slice ready + hub resolves + architecture lens present (check_ready_slice.py)	C1	Hard halt (REC1)
Resolve the target environment for this call (resolve_target_env.py)	C9	Hard halt — all envs defined, ask for --env

Resolve the pre-flight facts mechanically with the bundled resolver:

python3 scripts/preflight.py --play run --config .garura/core/config.yaml

Then resolve the slice and its hub from the spine — the readiness gate every realize lens shares:

python3 scripts/check_ready_slice.py --product-base <product_base> --slice <slice-id>

It asserts the profile is set (from the spine), resolves the slice record, and resolves every functionality_ref through the spine to its functionality.md grounding doc — the hub, and emits the slice's lens_dir. /run also needs the slice's lens/architecture.md to exist (it reads it). If the slice is absent, a functionality does not resolve, the profile is not firmed, or the architecture lens is missing, hard halt (C1/REC1).

Then resolve which one environment this call builds — the lowest not-yet-defined tier by default, or the --env <name> the invoker named — reading the slice's current run.yaml (if any) from the resolved lens_dir:

python3 scripts/resolve_target_env.py --run-yaml <lens_dir>/run.yaml [--env <name>]

It returns the target_env ({name, type, tier}) and the existing_run_yaml path (empty on the first call). If every known environment is already defined and no --env is given, hard halt and ask which to edit (C9). Both facts are passed to the Draft step.

The run's working root (<working> below) is {stm_base}_realize/run/ — the draft dir, the manifests, the captured verify output (run-checks.json), and the status/ markers all live under it; the stop condition evaluates against it.

Right after the resolver, record the session identity stamp's start marker (#463 — soft-fail, never a halt):

python3 scripts/session_stamp.py --phase start \
    --marker "{stm_base}_realize/run/status/session-stamp-run.json" \
    --cwd "$(pwd)" --branch "$(git branch --show-current)"

Resume check: if {stm_base}_realize/run/status/<slice-id>.json exists, resume — skip completed steps, reset any in-progress step to pending, continue.

Task DAG

Create ALL tasks immediately after resolving config — before any domain work.

[T1] Draft the lens          blockedBy: []
[T2] Validate the draft      blockedBy: [T1]
[T3] Checkpoint (approval)   blockedBy: [T2]
[T4] Persist                 blockedBy: [T3]
[T5] Verify persisted        blockedBy: [T4]
[TE1] commit-change   (injected — end #1)  blockedBy: [T5]
[TE2] propose-change  (injected — end #2)  blockedBy: [TE1]
[TE3] review-change   (injected — end #3)  blockedBy: [TE2]
[TE4] merge-change    (injected — end #4)  blockedBy: [TE3]
[T6] Scenario Validation     blockedBy: [TE4]
[T7] Close                   blockedBy: [T6]

Mark each task in-progress before its step and completed right after its eval passes.

Workflow

Phase: Draft

Step 1 — Draft the lens · Owner: product-os-keeper · Depends on: pre-flight The agent invokes author-run-lens to draft the slice's run.md (per the Run lens template) AND run.yaml (per the run lens schema) — the slice-level design (carried forward if it exists) plus the one resolved target environment — from the hub (the functionality grounding docs + the profile) and the slice's architecture.md, plus a run-manifest.yaml (the grounding map) and any material run decision:

{
  "task":    "author the slice's run lens — slice-level design (rollout/migrations/config-secrets/ci-cd) once + define the one target environment (local: bring-up; cloud: provider/region/compute/services/firewalls/security/deploy) — as run.md + run.yaml; ground every operational choice in the functionalities, profile, or architecture; a cloud env's compute/services map to architecture components; secrets via a manager, never a literal",
  "inputs":  { "slice_ref": "<domain>/<slice>",
               "slice_file": "<slice record>",
               "target_env": "<{name,type,tier} from resolve_target_env>",
               "existing_run_yaml": "<lens_dir>/run.yaml or empty (from resolve_target_env)",
               "functionality_groundings": "<from check_ready_slice>",
               "architecture_lens": "<slice>/lens/architecture.md",
               "profile": "<spine profile>", "product_base": "<product_base>",
               "lens_rel": "product-os/<domain>/slices/<slice>/lens/run.md" },
  "outputs": { "draft_dir": "<working>/draft/", "run_yaml": "<working>/draft/.../lens/run.yaml",
               "manifest": "<working>/draft/run-manifest.yaml" }
}

The skill reads the hub + the architecture lens + any existing run.yaml read-only and writes only the draft (the run.md, the run.yaml, the manifest, any decision). It defines exactly the target environment, preserves the rest, and never stamps the slice realized.

Step 2 — Validate the draft · Owner: play · Depends on: Step 1 Run the guards over the draft before the checkpoint — run.md shape, then run.yaml facts, then content, then grounding/coverage/preservation.

python3 scripts/lint_grounding.py --doc <working>/draft/product-os/<domain>/slices/<slice>/lens/run.md
python3 scripts/validate_run.py --draft <working>/draft --manifest <working>/draft/run-manifest.yaml \
        --slice-file <product_base>/<slice_file> \
        --arch-lens <product_base>/product-os/<domain>/slices/<slice>/lens/architecture.md \
        --existing-run-yaml <existing_run_yaml or omit> --target-env <target_env.name>

Then run the content-quality eval over run.md: spawn an isolated, clean-context sub-agent handed the judge prompt (standards/rules/grounding-eval.md), the doc, and the Run lens per-section guidance, on the model from grounding-eval.judge.model. Gate the verdict:

python3 scripts/grounding_gate.py --verdict <verdict.json>

SE-1 (F1/C1): check_ready_slice.py passed at pre-flight — the slice is ready, its hub resolves, and the architecture lens exists; an unready slice halted (REC1). SE-2 (F3/C3): lint_grounding.py exits 0 — run.md conforms to the Run lens template (Environments / Rollout / Migrations / Config & secrets / CI/CD), no missing/extra/empty section. SE-3 (F3/C3): validate_run.py — run.yaml conforms to the run lens schema: slice-level rollout / migrations / CI/CD present, and an environments list whose each entry has name/tier/type and the type-appropriate local or cloud block. SE-4 (F4/C4): the content-quality eval gate (grounding_gate.py) passes — run.md is self-explaining and clears the stranger test. SE-5 (F5/C5): validate_run.py — every operational choice grounds in the hub, the profile, or the architecture lens; every cloud env compute/service maps to a real architecture-lens component; any material run choice names a decision that resolves. SE-6 (F6/C6): validate_run.py — the run plan considers every functionality the slice bundles (coverage). SE-7 (F7/C7): validate_run.py — the run plan grounds on no realize lens other than architecture. SE-8 (F9/C9): validate_run.py — exactly the target environment is defined or edited this call; no environment beyond the target was added, none dropped, and every previously-defined environment is value-identical to the existing run.yaml. SE-9 (F10/C11): validate_run.py — run.yaml and run.md name the same environment set (every environment run.yaml defines is narrated in run.md). SE-10 (F13/C12): validate_run.py — no secret literal in run.yaml or run.md; secrets are manager bindings, not raw values. On any GAP, apply the matching recovery (REC3–REC10, REC13) and re-run before the checkpoint.

Phase: Checkpoint (conditional gate, class: standard, C10)

Step 3 — Human review (conditional gate, class: standard) · Owner: play · Depends on: Step 2 This is the single checkpoint (C10) — the agent never skips it on its own judgment. It is a conditional gate per standards/rules/gate-config.md (#467 — /run is one of the eleven conditional document plays). Resolve, first match wins: pinned (n/a here) → gates.plays.run → the learned policy → gates.classes.standard → gates.default (absent ⇒ on). When config resolves it off, record gate skipped by config (<resolution path>) as a Checkpoint Decisions row in the evidence and proceed on the validated draft.

For the policy leg, classify the draft-vs-live change shape mechanically:

python3 scripts/classify_change.py --play run --draft <working>/draft --live <product_base> --out <working>/shape.json

Look the shape key up in the config-resolved learned policy (gates.conditional.policy → gate-policy.yaml). Shape in auto: AND not in never_auto: AND no blocking finding (a Step 2 lint gap or content-eval fail) → auto-pass: record gate auto-passed by learned policy (shape: <shape-key>, policy v<version>) as a Checkpoint Decisions row plus the draft's diff summary (the axis counts from shape.json), append the ledger line, and proceed — no wait:

python3 scripts/gate_eval.py append --ledger <gates.conditional.ledger> --play run \
    --issue <issue> --shape <shape-key> --predicted auto --human auto_pass \
    --ts <run ts> --policy-version <policy version>

Anything else → gate: render the approval prompt — the target environment's definition (local bring-up, or the cloud provider/region/compute/services/firewalls/security/deploy) plus the slice-level design (rollout, migrations, config & secrets, CI/CD) and any decision inline — and wait for the typed response. Approve → persist; cancel → halt, nothing written. Then append the ledger line with the human's real action:

python3 scripts/gate_eval.py append --ledger <gates.conditional.ledger> --play run \
    --issue <issue> --shape <shape-key> --predicted gate \
    --human approved_clean|approved_edited|rejected --ts <run ts>

<run ts> is the run's own timestamp, derived the same way the close derives ts (date -u) and passed by the orchestrator — the script never reads the wall clock. EVERY crossing appends exactly one live-eval ledger line, gated or auto. SE-11 (F12/C10): the lens is persisted only after this gate resolves — a typed approval, a recorded config skip, or a recorded policy auto-pass; Step 4 is the sole writer and depends on this step. SE-15 (F15/C10): every conditional-gate crossing appended exactly one live-eval ledger line (gate_eval.py append), and an auto-pass fired only for a shape the policy lists in auto: (and not in never_auto:) with no blocking finding.

Phase: Apply

Step 4 — Persist · Owner: play · Depends on: Step 3 First snapshot the live spine and the slice folder so Step 5 can verify (cp the spine to <working>/spine-before.yaml; cp -R the slice folder to <working>/slice-before). Then persist on the fixed allowlist — only this slice's run.md and run.yaml (re-derive) and decisions (skip-if-exists):

python3 scripts/apply_run.py --draft <working>/draft --product-base <product_base> --out-manifest <working>/apply-manifest.json

Step 5 — Verify persisted · Owner: play · Depends on: Step 4 Verify the persist was surgical and that the slice's status was untouched (no realized stamp) — capture the checker's JSON output; its ok field is the stop condition's D3 input:

python3 scripts/check_run.py --cap-before <working>/slice-before --cap-dir <product_base>/product-os/<domain>/slices/<slice> --spine-before <working>/spine-before.yaml --spine-after <product_base>/product-os/_spine.yaml > <working>/run-checks.json

SE-12 (F8/C8): the spine and the slice record are byte-identical before and after — so the slice's status is unchanged; /run never stamped the slice realized. SE-13 (F2/F11/C2): the only files changed in the slice folder are lens/run.md and lens/run.yaml (decisions may be added, never edited in place); the spine — and with it the profile, the slice record, and the other lenses — is byte-identical. Nothing outside the allowlist was written.

Phase: End sequence (injected — D2 position: end)

After the lens is persisted and verified, the D2 rule injects the close sequence — each a sub-play dispatched with parent_run_id, resolving its own context from the branch + config — to commit the non-functional pipe's lenses, raise the PR, take the verdict, and merge to main.

Step E1 — commit-change · blockedBy: Step 5

{ "play": "commit-change", "parent_run_id": "<this run id>", "inputs": {}, "outputs": { "result": "{stm_base}_realize/run/end/commit-change.json" } }

Step E2 — propose-change · blockedBy: E1

{ "play": "propose-change", "parent_run_id": "<this run id>", "inputs": {}, "outputs": { "result": "{stm_base}_realize/run/end/propose-change.json" } }

Step E3 — review-change · blockedBy: E2

{ "play": "review-change", "parent_run_id": "<this run id>", "inputs": {}, "outputs": { "result": "{stm_base}_realize/run/end/review-change.json" } }

Step E4 — merge-change · blockedBy: E3

{ "play": "merge-change", "parent_run_id": "<this run id>", "inputs": {}, "outputs": { "result": "{stm_base}_realize/run/end/merge-change.json" } }

Each end member owns its own evals (commit grouped by concern, PR opened, verdict posted, branch merged

• cleaned); they are not re-checked here. A review-change reject stops the chain before merge.

Phase: Scenario Validation

Step 6 — Scenario evals · Owner: play · Depends on: the end sequence

• SCE-1 (S1 — devops engineer, first environment): the first run resolves the target to local, writes run.yaml (slice-level design + local at tier 0) and run.md, both clearing their validators; the spine/slice/profile/other lenses are byte-identical.
• SCE-2 (S2 — devops engineer, next environment): a later run for dev adds the dev cloud environment (provider/region/compute/services/firewalls/security/deploy), preserves the local environment unchanged, and run.yaml holds both in tier order; run.md and run.yaml agree.
• SCE-3 (S3 — architect, grounded run): every operational choice grounds in the hub, the profile, or the architecture lens; every cloud compute/service maps to an architecture-lens component; material choices name a decision that resolves.
• SCE-4 (S4 — reviewer, architecture-driven): the run plan read the architecture lens and no other realize lens, and flows from its stack and components.
• SCE-5 (S5 — release manager, no premature realize): the slice's status is unchanged — /run never stamped realized.
• SCE-6 (S6 — product owner, re-run same environment): a re-run of the same environment re-derives only that environment; other environments, the spine, slice record, other lenses, and profile are byte-identical; no accepted decision edited in place.
• SCE-7 (S7 — security reviewer, no secrets in repo): a cloud env's secrets are manager bindings; no secret literal appears in run.yaml, run.md, or the repo.
• SCE-8 (S8 — reviewer, the checkpoint): the checkpoint showed the target environment plus the slice-level design inline, and no product-model file was written before approval — or, on the auto-pass path, the shape was policy-listed and the recorded auto-pass, the ledger line, and the diff summary stood in for the wait (nothing written before the gate resolved).

Phase: Evidence & Close

Step 7 — Close · Owner: play · Depends on: Step 6 Run the Standard Play Close. /run is a slice-realize play — record evidence per the D1 rule. SE-14 (F14/C13): the stop-condition verdict is held before the run closes COMPLETED; a close over an unmet or unevaluable verdict reads HALTED, never COMPLETED (REC14).

# --- Standard Play Close (canonical; see standards/rules/play-close.md) ---
# Path tokens resolved at pre-flight (resolve here if not already):
#   ltm_project_target  = yq '.ltm.project-target' .garura/core/config.yaml
#   evidence_base, slug:
#     project-scoped play : evidence_base="${stm_base}${issue}/evidence/run/"   ; slug="#${issue}"
#     product-scoped play : evidence_base="${product_base}_evidence/run/"        ; slug="${slice_slug}"
evidence_template=$(cat "${ltm_project_target}standards/templates/evidence-file.md")
delivery_template=$(cat "${ltm_project_target}standards/templates/delivery-report.md")
ts=$(date -u +%Y%m%d-%H%M%S)
evidence_dest="${evidence_base}${ts}.md"
mkdir -p "$(dirname "$evidence_dest")"
# Session identity stamp (#463) — close phase; start phase ran at pre-flight
session_stamp=$(python3 scripts/session_stamp.py --phase close \
    --marker "${stm_base}_realize/run/status/session-stamp-run.json")
# Stop-condition gate (#464) — Step C0: this play carries a baked manifest, so the
# gate is LIVE. Evaluate the Done means as the close's authoritative input.
python3 scripts/check_stop_condition.py \
    --manifest "<play-dir>/stop-condition.yaml" \
    --base "${stm_base}_realize/run/" \
    --out "${stm_base}_realize/run/status/stop-condition-run.yaml"
sc_exit=$?   # 0 held · 1 unmet · 2 error
# Conditional-gate policy refresh (#467) — soft: a distill failure never blocks the close.
#   gates_ledger / gates_policy / gates_streak = yq '.gates.conditional.ledger|.policy|.streak'
#   project_name = yq '.project.name' .garura/core/config.yaml
python3 scripts/distill_gate_policy.py --ledger "${gates_ledger}" --policy "${gates_policy}" \
    --streak "${gates_streak}" --project "${project_name}" || true

/run runs on the slice-realize issue /arch opened, so it is project-scoped: evidence_base="${stm_base}${issue}/evidence/run/" and slug="#${issue}".

Step C0 — bind the verdict. sc_exit == 0 (held) permits status: COMPLETED. Anything else closes HALTED with exit_reason: stop_condition_unmet and the evidence's Stop Condition section names every unmet clause — a run that never applied (checkpoint cancelled, validation failed) is a HALTED run, not a done one; fix the state per REC14 (re-run the verify capture, or complete the missing step) and re-evaluate; the close stays HALTED until the verdict reads held. An unevaluable verdict is never a pass.

Step C1 — Write evidence file. Gated by the resolved evidence.record flag. When false, skip and record evidence skipped (record=false). Otherwise fill the evidence-file.md slots (play run, run_id run-${ts}, slice slug, the target environment defined this call, started/completed, status per C0, exit_reason; artifacts: the slice's run.md, run.yaml, the manifest, any decision, the stop-condition verdict; the content-eval verdict; step + scenario evals SE-1…SE-15 / SCE-1…SCE-8; checkpoint decision (incl. any gate skipped by config or gate auto-passed by learned policy row, with the diff summary and the ledger line); the end-sequence results; the session identity stamp fields from $session_stamp (#463): session_id, ledger_file, ledger_start_offset, ledger_end_offset (null when unresolved — never blocks the close); and stop_condition per C0 with the Stop Condition section filled) and write to $evidence_dest. Do NOT hand-author the body.

Step C2 — Render delivery report. Also render the Next line: resolve this play in standards/rules/pipeline-next.md and emit **Next:** /<command> — <why>. Or run /next to see all recommended actions. (only /next pointer, or omit, when the mapped command is null), per play-close.md. Fill the delivery-report.md slots: ## run Delivered — ${slug}, the Run Summary table (name the target environment built), the Pipeline Steps table, the Artifacts Produced table (the run lens run.md + run.yaml + any decision), Next Steps (add the next environment by re-running /run, or close the non-functional pipe and run the deliver pipe: /measure, which stamps the slice realized), and a pointer to $evidence_dest. Always emitted.

# --- end Standard Play Close ---

Scenario Validation

Scenario	Persona	Eval
S1 — first environment	devops engineer	SCE-1
S2 — next environment	devops engineer	SCE-2
S3 — grounded run	architect	SCE-3
S4 — architecture-driven	reviewer	SCE-4
S5 — no premature realize	release manager	SCE-5
S6 — re-run same environment	product owner	SCE-6
S7 — no secrets in repo	security reviewer	SCE-7
S8 — the checkpoint	reviewer	SCE-8

Recovery

For	Trigger	Direction	Handoff
F1	the slice is absent, a functionality does not resolve, the profile is not firmed, or the architecture lens is missing	halt and route to /shape, /understand, or /arch before /run runs	human
F2	a write touched something beyond this slice's run.md, run.yaml, or a decision	revert the out-of-scope write; /run writes only the slice's run.md, run.yaml, and any decision	autonomous
F3	run.md fails the template/shape or carries out-of-scope content, or run.yaml fails the schema	re-emit the failing artifact to its contract — the five run sections for run.md, the run lens schema for run.yaml	autonomous
F4	run.md fails the content-quality eval	rewrite the failing section to the judge's cited fixes and re-judge until the gate passes	autonomous
F5	an invented choice, a cloud compute/service referencing a non-arch component, or a material choice with no decision	re-tie each choice to the hub, the profile, or the architecture (a cloud compute/service to a real component), and record the material decision	autonomous
F6	a functionality was left unaccounted for	extend the run plan to account for the missing functionality	autonomous
F7	/run read or depended on a lens other than architecture	remove the dependency; /run reads only the hub + the architecture lens	autonomous
F8	/run stamped the slice realized or wrote its status	revert the status write; the realized stamp belongs to /measure	autonomous
F9	a previously-defined environment was dropped or silently edited, or more than one was defined in a call	restore the untouched environments from the prior run.yaml and re-derive only the single target environment	autonomous
F10	run.yaml and run.md disagree	re-emit both from one source of truth so the environments and facts match	autonomous
F11	a non-lens/non-decision file changed, or an accepted decision was edited in place	restore it and re-apply only run.md / run.yaml and the new decision, after a human confirms the restore	human
F12	the lens was persisted before the checkpoint gate resolved	revert the premature write and re-present the checkpoint; persist only after the gate resolves (a typed approval, a recorded config skip, or a recorded policy auto-pass)	human
F13	a secret value was written into the lens or the repo	strip the secret, replace it with a secrets-manager binding, and re-verify no secret literal remains	autonomous
F14	the run is about to close COMPLETED with the Done means unmet	close HALTED (stop_condition_unmet) with the unmet clauses named; fix the state — re-run the verify capture, or complete the missing draft/apply step — and re-evaluate; the close stays HALTED until the verdict reads held	autonomous
F15	a conditional-gate crossing left no live-eval ledger line, or an auto-pass fired for a shape the policy does not list as auto (or that carried a blocking finding)	re-append the missing ledger line from the recorded crossing; when the auto-pass was unearned, re-run the gate as a live wait (render the prompt, take the typed verdict) and append the corrected line	autonomous

Pause and Resume

Steps run top to bottom. On entry, resolve config, resolve the target slice, resolve the target environment, check the status marker, skip completed steps, reset any in-progress step to pending, and continue.

Compilation Metadata

Field	Value
fingerprint	sha256:f88a93f2a07971b8417a69af1587e6dae080773a417100763b35b5223be0aa40 (of reference/ice.md)
compiled_by	play-editor (#466 Batch C; #467 Batch B — conditional learned gate)
pipeline_position	end (closes the non-functional realize pipe; injects commit → propose → review → merge)
model_writes	yes
workflow_structure	A (single checkpoint — conditional learned gate, class: standard, per gate-config.md #467; stop-condition gated close)
stop_condition	stop-condition.yaml (D1–D3), gate live at Step C0
domain_agents	1 (product-os-keeper)
utility_agents	0
skills_used	author-run-lens
scripts	13 (preflight, check_ready_slice, resolve_target_env, lint_grounding, grounding_gate, validate_run, apply_run, check_run, check_stop_condition, session_stamp, classify_change + gate_eval + distill_gate_policy — #467 conditional gate)
constraints	13 (C1–C13)
failure_conditions	15 (F1–F15)
success_scenarios	8 (S1–S8)
step_evals	15 (SE-1…SE-15)
scenario_evals	8 (SCE-1…SCE-8)
recovery_entries	15 (one per failure condition; 12 autonomous / 3 human)