measure

name	measure
position	both
description	Write a SLICE's measure lens as a grounding doc (measure.md) — the delivery-measurement focus, the metrics that prove it (baseline / target / proof, triangle-primary speed/tokens/cognition), and what is out of scope — then, when all seven lens docs line up, stamp the slice realized on the spine. The DELIVER pipe of realize (runs last): it opens its own branch (start-change) and closes it (commit → propose → review → merge). Reads the hub from the spine; the single play that flips a slice to realized — the marker /grill checks.
user-invocable	true

measure

Write a shaped slice's measure lens as the grounding doc measure.md — what delivery the slice is proving, the metrics that prove it (each a baseline, a target, and a proof; triangle-primary on speed/tokens/cognition), and what is out of scope — and, when the slice lines up (all seven lens docs present), stamp it realized. /measure reads the slice's hub — its functionalities' grounding docs plus the profile, both from the spine. It is the deliver lens, the last of the three realize pipes, and the one play that flips a slice's status to realized on the spine — the single marker /grill checks before it cuts delivery work.

Pipeline position: both. /measure is the DELIVER pipe — a single-play pipe that runs last (after the functional pipe ux → agentic → marketing and the non-functional pipe architecture → quality → run have merged to main). The D2 rule prepends start-change (opens the deliver issue, cuts a fresh branch off main, inits STM) and, after the lens is persisted, the realized stamp is made, and both are verified, appends the close sequence commit-change → propose-change → review-change → merge-change, merging the realized slice to main. (#437; 3-pipe realize 2026-06-26)

Compiled From

This play was compiled from the measure 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–F14); the expectation defines success scenarios (S1–S6), a Done means (D1–D4, baked to stop-condition.yaml — D4 counts BOTH stamp outcomes as done), 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 measure lens grounding doc — to the product-os-keeper agent via a JSON contract over files on disk, and you run the mechanical checks (readiness/hub resolution, the shape linter, the content-quality eval, grounding + coverage, KB grounding, the allowlisted apply, the lines-up gate, the realized stamp, the verify) through bundled scripts and an isolated judge. You never write the lens yourself, you never stamp a slice that has not lined up, and you never persist before the single checkpoint's gate resolves (C11) — 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 measure.md, a decision, and (on lines-up) the one realized status field (C2); stamping the slice realized when a lens doc is missing (C8); reading or grounding on another realize lens (C7); persisting or stamping by any route other than scripts/apply_measure.py + scripts/stamp_slice.py; persisting before the checkpoint; closing COMPLETED without the stop-condition verdict reading held (C13/F13).

Agent boundaries:

Agent	Domain	Skill it invokes	Phases
product-os-keeper	Author the slice's measure lens (focus / metrics / out-of-scope) from the hub + KB measurement-frame grounding	kb-search, author-measure-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 (check_ready_slice.py)	C1	Hard halt (REC1)

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

python3 scripts/preflight.py --play measure --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. If the slice is absent, a functionality does not resolve, or the profile is not firmed, hard halt (C1/REC1).

The run's working root (<working> below) is {stm_base}_realize/measure/ — the draft dir, the manifests, the captured verify output (measure-checks.json), the lines-up capture, the stamp record (stamp-record.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/measure/status/session-stamp-measure.json" \
    --cwd "$(pwd)" --branch "$(git branch --show-current)"

Resume check: if {stm_base}_realize/measure/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.

[T0] start-change (injected — start head)   blockedBy: []
[T1] Draft the lens          blockedBy: [T0]
[T2] Validate the draft      blockedBy: [T1]
[T3] Checkpoint (approval)   blockedBy: [T2]
[T4] Persist + stamp         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: Start (injected — D2 position: start)

Step 0 — start-change · Owner: start-change (sub-play) · Depends on: pre-flight Run the start-of-pipeline member as a sub-play, dispatched with parent_run_id so it emits only its own C1 evidence and this play's close absorbs it. It resolves or creates the deliver-pipe issue, cuts a fresh branch off main, sets up a worktree iff config calls for it, and initializes the STM workspace.

{ "play": "start-change", "parent_run_id": "<this run id>", "inputs": { "title": "realize (deliver): <slice>" }, "outputs": { "result": "{stm_base}_realize/measure/start/start-change.json" } }

start-change owns its own evals (issue anchored, branch off latest main, worktree per config, STM initialized); they are not re-checked here.

Phase: Draft

Step 1 — Draft the lens · Owner: product-os-keeper · Depends on: Step 0 The agent invokes author-measure-lens to draft the slice's measure.md (focus / metrics / out of scope, per the Measure lens template) from the hub (the functionality grounding docs + the profile) and KB measurement-frame grounding, plus a measure-manifest.yaml (the grounding map) and any material decision:

{
  "task":    "author the slice's measure lens (focus / metrics baseline-target-proof / out-of-scope) from its hub; ground each metric in the functionalities + profile and the frames in the KB",
  "inputs":  { "slice_ref": "<domain>/<slice>",
               "slice_file": "<slice record>",
               "functionality_groundings": "<from check_ready_slice>",
               "profile": "<spine profile>", "product_base": "<product_base>",
               "lens_rel": "product-os/<domain>/slices/<slice>/lens/measure.md" },
  "outputs": { "draft_dir": "<working>/draft/", "manifest": "<working>/draft/measure-manifest.yaml" }
}

The skill reads the hub read-only and writes only the draft (the measure.md, the manifest, any decision, any KB proposals).

Phase: Validate

Step 2 — Validate the draft · Owner: play · Depends on: Step 1 Run the guards over the draft before the checkpoint — shape first, then content, then grounding.

python3 scripts/lint_grounding.py --doc <working>/draft/product-os/<domain>/slices/<slice>/lens/measure.md
python3 scripts/validate_measure.py --draft <working>/draft --manifest <working>/draft/measure-manifest.yaml --slice-file <product_base>/<slice_file>
python3 scripts/check_kb_grounding.py --manifest <working>/draft/measure-manifest.yaml --kb-root <kb_root> --proposals-dir <working>/draft/proposals

Then run the content-quality eval over measure.md: spawn an isolated, clean-context sub-agent handed the judge prompt (standards/rules/grounding-eval.md), the doc, and the Measure 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 and its hub resolves; an unready slice halted (REC1). SE-2 (F3/C3): lint_grounding.py exits 0 — measure.md conforms to the Measure lens template (Focus / Metrics / Out of scope), no missing/extra/empty section. SE-3 (F4/C4): the content-quality eval gate (grounding_gate.py) passes — measure.md is self-explaining and clears the stranger test. SE-4 (F5/C5): validate_measure.py — every metric grounds in a functionality's acceptance or a profile outcome (the manifest grounds), and a material choice names a decision that resolves. SE-5 (F6/C6): validate_measure.py — every functionality the slice bundles is considered. SE-6 (F7/C7): validate_measure.py — the metrics ground on no other realize lens. SE-7 (F12/C12): check_kb_grounding.py exits 0 — the measurement-frame choices trace to a KB learning or a recorded proposal. On any GAP, apply the matching recovery (REC3–REC7, REC12) and re-run before the checkpoint.

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

Step 3 — Human review (conditional gate, class: standard) · Owner: play · Depends on: Step 2 This is the single checkpoint (C11) — the agent never skips it on its own judgment. It is a conditional gate per standards/rules/gate-config.md (#467 — /measure is one of the eleven conditional document plays). Resolve, first match wins: pinned (n/a here) → gates.plays.measure → 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 measure --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 measure \
    --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 proposed focus, metrics, and out-of-scope inline, plus any decision, AND the realized stamp this run will make — or, if a lens doc is missing, the lenses still outstanding (the slice will not be stamped) — 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 measure \
    --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 (F11/C11): the lens and the stamp are 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-13 (F14/C11): 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 + stamp · 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). Persist the lens on the fixed allowlist — only this slice's measure.md (re-derive) and decisions (skip-if-exists):

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

Then run the lines-up gate over the live slice and resolve the stamp — stamp_slice.py reads the lines-up capture, stamps realized ONLY on a pass, and EITHER WAY writes the stamp record (stamp-record.json, the stop condition's D4 input):

python3 scripts/lines_up.py --product-base <product_base> --slice <slice-id> > <working>/lines-up.json
python3 scripts/stamp_slice.py --product-base <product_base> --slice <slice-id> \
        --lines-up <working>/lines-up.json --record <working>/stamp-record.json

When the gate passes (all seven lens docs present) the slice is stamped and the record reads {stamp_resolved: true, stamped: true}; when a lens is missing the stamp is explicitly skipped, the record reads {stamp_resolved: true, stamped: false, missing: [...]}, and the missing-lens list is carried into the report — the slice stays un-realized. Both outcomes are resolved outcomes; an unwritten record is an unresolved stamp and blocks the close (C13). SE-8 (F8/C8): the slice is stamped realized only when lines_up.py reports every one of the seven lens docs present; a missing lens leaves the status unchanged and is reported — and either outcome is recorded in stamp-record.json (stamp_resolved: true, stamped true/false with the missing lenses).

Phase: Verify

Step 5 — Verify persisted · Owner: play · Depends on: Step 4 Verify the persist and the stamp were surgical (pass --expect-realized iff the stamp record reads stamped: true) — capture the checker's JSON output; its ok field is the stop condition's D3 input:

python3 scripts/check_measure.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 --slice <slice-id> --expect-realized > <working>/measure-checks.json

SE-9 (F2/F9/C2/C9): the only file changed in the slice folder is lens/measure.md (decisions may be added, never edited in place); on the spine, the ONLY change is this slice's status → realized (or none, when not stamped) — every other slice, field, and collection byte-identical. SE-10 (F10/C10): the run is non-destructive — no accepted decision edited in place, no file removed.

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

After the lens is persisted, the stamp is made (or skipped), and both are verified, the D2 rule injects the close sequence — each a sub-play dispatched with parent_run_id, resolving its own context — to commit the deliver pipe, raise the PR, take the verdict, and merge the realized slice to main.

Step E1 — commit-change · blockedBy: Step 5

{ "play": "commit-change", "parent_run_id": "<this run id>", "inputs": {}, "outputs": { "result": "{stm_base}_realize/measure/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/measure/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/measure/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/measure/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 — delivery analyst, first run): measure.md is a valid Measure Lens doc clearing the linter + the content eval, grounded in the hub.
• SCE-2 (S2 — delivery owner, the realized stamp): with all six other lens docs present, the slice is stamped realized on the spine and that is the only spine change.
• SCE-3 (S3 — reviewer, not-yet-lined-up): with a lens missing, measure.md is written but the slice is NOT stamped; the missing lens is named and the status unchanged.
• SCE-4 (S4 — architect, hub-only): every metric grounds in a functionality or the profile, never another lens.
• SCE-5 (S5 — delivery owner, re-run): a re-run re-derives only measure.md and re-affirms the stamp; everything else byte-identical; no accepted decision edited in place.
• SCE-6 (S6 — reviewer, the checkpoint): the checkpoint showed the lens and the stamp 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. /measure is a slice-realize play — record evidence per the D1 rule. SE-12 (F13/C13): the stop-condition verdict is held before the run closes COMPLETED — including D4, the resolved stamp record (either outcome); a close over an unmet or unevaluable verdict reads HALTED, never COMPLETED (REC13).

# --- 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/measure/"   ; slug="#${issue}"
#     product-scoped play : evidence_base="${product_base}_evidence/measure/"        ; 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/measure/status/session-stamp-measure.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/measure/" \
    --out "${stm_base}_realize/measure/status/stop-condition-measure.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

/measure opens its own deliver-pipe issue (position start), so it is project-scoped: evidence_base="${stm_base}${issue}/evidence/measure/" 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 not-stamped run whose record names the missing lenses is a DONE run (D4 held); an UNRESOLVED stamp — no record — is not; fix the state per REC13 (re-run the verify capture, or re-run the stamp step so the record names one of the two outcomes) 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 measure, run_id measure-${ts}, slice slug, started/completed, status per C0, exit_reason; artifacts: the slice's measure.md, the manifest, any decision, the lines-up result, the stamp record (stamped or explicitly not-stamped with the missing lenses), the stop-condition verdict; the content-eval verdict; step + scenario evals SE-1…SE-13 / SCE-1…SCE-6; 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: ## measure Delivered — ${slug}, the Run Summary table, the Pipeline Steps table, the Artifacts Produced table (the measure lens + any decision + whether the slice was stamped realized), Next Steps (if realized: run /grill to cut this slice into epics; else: run the missing lens pipe), and a pointer to $evidence_dest. Always emitted.

# --- end Standard Play Close ---

Scenario Validation

Scenario	Persona	Eval
S1 — first run	delivery analyst	SCE-1
S2 — the realized stamp	delivery owner	SCE-2
S3 — not-yet-lined-up	reviewer	SCE-3
S4 — hub-only	architect	SCE-4
S5 — re-run	delivery owner	SCE-5
S6 — the checkpoint	reviewer	SCE-6

Recovery

For	Trigger	Direction	Handoff
F1	the slice is absent, a functionality does not resolve, or the profile is not firmed	halt and route to /shape or /understand before /measure runs	human
F2	a write touched something beyond this slice's measure.md, a decision, or the one realized status field	revert the out-of-scope write; /measure writes only those	autonomous
F3	measure.md fails the template/shape	re-emit to the Measure lens template (Focus / Metrics / Out of scope only)	autonomous
F4	measure.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	a metric lacks a baseline/target/proof or grounds in nothing the slice delivers	re-draft the metric as a concrete baseline + target + proof tied to the hub	autonomous
F6	a functionality is neither measured nor named out of scope	add a metric for it or name it in out-of-scope with the reason	autonomous
F7	the assessment read or grounded on another lens	remove the dependency; derive only from the slice's hub	autonomous
F8	the slice was stamped realized when a lens doc was missing	revert the stamp, report the missing lens, route to the pipe that owns it	human
F9	the stamp changed more than this slice's status on the spine	restore the spine and re-apply only the single status flip	human
F10	a non-lens/non-decision file changed, or an accepted decision was edited in place	restore it and re-apply only measure.md and the new decision, after a human confirms the restore	human
F11	the lens or stamp 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
F12	a measurement frame with no KB learning and no recorded proposal	search the KB via kb-search and ground the frame, or raise a KB-learning-gap proposal	autonomous
F13	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 re-run the stamp step so the record names one of the two outcomes — and re-evaluate; the close stays HALTED until the verdict reads held	autonomous
F14	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, check the status marker, skip completed steps, reset any in-progress step to pending, and continue.

Compilation Metadata

Field	Value
fingerprint	sha256:0bac8299871a0d9b072941b301ed1d922ff90fee34503d24567dc11e2ec907fc (of reference/ice.md)
compiled_by	play-editor (#466 Batch C; #467 Batch B — conditional learned gate)
pipeline_position	both (deliver pipe — injects start-change head and commit → propose → review → merge close)
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–D4; D4 counts both stamp outcomes), gate live at Step C0
domain_agents	1 (product-os-keeper)
utility_agents	0
skills_used	kb-search, author-measure-lens
scripts	15 (preflight, check_ready_slice, lint_grounding, grounding_gate, validate_measure, check_kb_grounding, apply_measure, lines_up, stamp_slice, check_measure, check_stop_condition, session_stamp, classify_change + gate_eval + distill_gate_policy — #467 conditional gate)
step_evals	13 (SE-1…SE-13)
scenario_evals	6 (SCE-1…SCE-6)
recovery_entries	14 (one per failure condition; 8 autonomous / 6 human)