@azure-id/orc 1.9.1 → 2.0.2

package/templates/skills/_shared/phases/scoring.md

@@ -1,65 +1,55 @@
-# Phase — Effort & scoring   (id: `scoring`)
-
-> **Shared phase file.** Moved out of `orc/SKILL.md` at v1.0.0 W12, and into
-> this library at W13 when `orc-diy` became its second reader. A spine is loaded
-> IN FULL when its skill activates; this is loaded when the phase fires, and most
-> runs skip most phases.
->
-> **Two layers, and a lane reads exactly one.** `full` is `/orc`'s procedure.
-> `composed` is what `orc diy compile` stitches — the same phase expressed as
-> `<!-- diy:when -->` variants over a composed flow, NOT a second copy of the
-> procedure. Reading the wrong one is the failure `README.md` names: a lane
-> doing a phase its product promise says it does differently.
-> `orc lane phases <lane> --json` names the layer for each lane.
-
-<!-- orc:layer full -->
-
-## Effort, dispatch style, scoring (load ../../orc/references/effort-and-mode.md)
-
-Emit `PHASE scoring start`. Refine effort; recommend **sequential** vs
-**parallel** dispatch (worktrees for high-effort independent features) — user
-confirms. Dispatch style is **intra-wave concurrency only**: waves are computed
-regardless of style (sequential runs have waves too, see wave-grouping.md), so
-the batch pause always binds to wave numbers. **Batch-pause schedule (deterministic, not a cadence hint):** the plan
-has K waves — ask "pause after every wave / every 2nd / run straight through?"
-and SHOW the resulting stop list ("will pause after waves [list]"); a 2-wave
-plan plainly offers "pause after wave 1". Store it as `pause_schedule`, recompute
-each wave's `is_batch_pause` (last wave never pauses). **Facet-validation gate
-(deterministic):** recompute `breadth` + `fan_in`/`fan_out` from the plan; a
-mismatch or an uncited `risk` entry bounces the plan (grounding mechanics).
-**Score every task** from its `facets` via the fixed formula, map to the model
-ladder, show the facet vector + arithmetic table, and emit `SCORE task=<id>
-score=<n> band=<band> model=<m> facets=<vector> :: <reason>` per task; a score
-override needs a written reason (logged). **With `extra_enabled`** the table gains
-a `via` column and its head can name TWO tables (effort-and-mode.md); a foreign
-task's `SCORE` appends `via=extra:<profile>` and `model=` is the FOREIGN model id.
-**Cited-risk hold-back (deterministic, beside the facet gate):** a foreign-routed
-task with a non-empty `risk[]` is HELD BACK to its Claude band (`extra_risk_tasks`
-defaults to `off`) and every one is LISTED with its cited risk — a silently
-held-back task is indistinguishable from a forgotten one. Use the wiki's "Notes for planning" to sharpen
-core/isolated + risk factors. **Tag each task's pattern domain+language**
-(+ secondary `db: postgres`) per `../../orc/references/pattern-gate.md`. Ask: "Any
-anticipated escalations, or run straight through?" Emit `PHASE scoring end`.
-
-<!-- /orc:layer -->
-
-<!-- orc:layer composed -->
-
-## Phase: Task scoring → executor selection
-
-<!-- diy:when scoring=on -->
-Score each task 0–100 with the full lane's rubric (see the scoring section of
-`.claude/skills/orc/SKILL.md`), then dispatch the executor agent from THIS
-compiled table — it is already clipped to this flow's session tier; never
-substitute a preset from `config.md`:
-
-{{score_table}}
-<!-- /diy:when -->
-<!-- diy:when scoring=off -->
-Scoring is DISABLED in this flow. Skip the rubric entirely: EVERY execution
-task dispatches to **{{fixed_executor}}**. Wave grouping, declared-files
-conflict rules, and slice construction are unchanged — scoring off changes
-model selection only, never scheduling.
-<!-- /diy:when -->
-
-<!-- /orc:layer -->
+# Phase — Effort & scoring   (id: `scoring`)
+
+> **Shared phase file** — read when the phase fires. A lane reads ONE layer: `full` (`/orc`) or `composed` (the `<!-- diy:when -->` variants `orc diy compile` stitches). `orc lane phases <lane> --json` names it.
+
+<!-- orc:layer full -->
+
+## Effort, dispatch style, scoring (load ../../orc/references/effort-and-mode.md)
+
+Emit `PHASE scoring start`. Refine effort; recommend **sequential** vs
+**parallel** dispatch (worktrees for high-effort independent features) — user
+confirms (H `orc.phase-2.execution`). Dispatch style is **intra-wave concurrency only**: waves are computed
+regardless of style (sequential runs have waves too, see wave-grouping.md), so
+the batch pause always binds to wave numbers. **Batch-pause schedule (deterministic, not a cadence hint):** the plan
+has K waves — ask (H `orc.phase-2.pause`) "pause after every wave / every 2nd / run straight through?"
+and SHOW the resulting stop list ("will pause after waves [list]"); a 2-wave
+plan plainly offers "pause after wave 1". Store it as `pause_schedule`, recompute
+each wave's `is_batch_pause` (last wave never pauses). **Facet-validation gate
+(deterministic):** recompute `breadth` + `fan_in`/`fan_out` from the plan; a
+mismatch or an uncited `risk` entry bounces the plan (grounding mechanics).
+**Score every task** from its `facets` via the fixed formula, map to the model
+ladder, show the facet vector + arithmetic table, and emit `SCORE task=<id>
+score=<n> band=<band> model=<m> facets=<vector> :: <reason>` per task; a score
+override needs a written reason (logged). **With `extra_enabled`** the table gains
+a `via` column and its head can name TWO tables (effort-and-mode.md); a foreign
+task's `SCORE` appends `via=extra:<profile>` and `model=` is the FOREIGN model id.
+**Cited-risk hold-back (deterministic, beside the facet gate):** a foreign-routed
+task with a non-empty `risk[]` is HELD BACK to its Claude band (`extra_risk_tasks`
+defaults to `off`) and every one is LISTED with its cited risk — a silently
+held-back task is indistinguishable from a forgotten one. Use the wiki's "Notes for planning" to sharpen
+core/isolated + risk factors. **Tag each task's pattern domain+language**
+(+ secondary `db: postgres`) per `../../orc/references/pattern-gate.md`. Ask: "Any
+anticipated escalations, or run straight through?" Emit `PHASE scoring end`.
+
+<!-- /orc:layer -->
+
+<!-- orc:layer composed -->
+
+## Phase: Task scoring → executor selection
+
+<!-- diy:when scoring=on -->
+Score each task 0–100 with the full lane's rubric (see the scoring section of
+`.claude/skills/orc/SKILL.md`), then dispatch the executor agent from THIS
+compiled table — it is already clipped to this flow's session tier; never
+substitute a preset from `config.md`:
+
+{{score_table}}
+<!-- /diy:when -->
+<!-- diy:when scoring=off -->
+Scoring is DISABLED in this flow. Skip the rubric entirely: EVERY execution
+task dispatches to **{{fixed_executor}}**. Wave grouping, declared-files
+conflict rules, and slice construction are unchanged — scoring off changes
+model selection only, never scheduling.
+<!-- /diy:when -->
+
+<!-- /orc:layer -->

package/templates/skills/_shared/phases/security-checklist.md

@@ -1,50 +1,46 @@
-# Phase — Security pass   (id: `security-checklist`)
-
-> **Library file.** Canonical since v1.0.0 W12; it was under the `orc` skill's
-> private `references/`, and another lane already reached across into it. Read
-> by `orc`, `orc-diy`. Layers declared: `core` only — single-layer because an
-> opt-in pass either runs its checklist or does not run. `orc lane phases
-> <lane> --json` names the file and the layers to read.
-
-<!-- orc:layer core -->
-## Reference — Security-Pass Checklist (Phase 5.5, opt-in)
-
-Loaded ONLY when the Phase 5.5 security pass fires (config `security_review`
-`on`/`ask` + a task scored ≥ 70 in the run). Passed to the reviewer as
-`security_checklist[]` — the worker sweeps ONLY the run's changed files against
-these items, wrapping Semgrep if it is already installed (never installing it).
-
-Severity mapping (same P0–P3 ladder): an item the DIFF makes exploitable = P0 ·
-a hardening gap on a touched path = P1 · defense-in-depth suggestions = P2/P3.
-
-## Checklist (OWASP/STRIDE-derived, impact-ordered — the closed set; never extend ad hoc)
-
-1. **Injection** — SQL/NoSQL/command/LDAP built from user input without
-   parameterization or a safe builder anywhere in the diff.
-2. **Broken auth on new surface** — any new endpoint/route/handler reachable
-   without the auth check its siblings carry (spoofing).
-3. **Broken authorization** — object/record access without an ownership or role
-   check (IDOR); privilege boundaries crossed by the new code (elevation).
-4. **Secrets in code** — credentials, tokens, keys, or connection strings
-   hardcoded or logged; secrets reaching client bundles or responses
-   (information disclosure).
-5. **Unvalidated input** — request bodies/params/headers/files used before
-   schema validation; mass-assignment of writable model fields (tampering).
-6. **Injection into output** — XSS via unescaped user data in HTML/JS contexts;
-   unsafe redirects/headers from user input.
-7. **Insecure data handling** — sensitive data stored/transmitted unencrypted,
-   PII in logs, cache keys/values leaking secrets.
-8. **CSRF/replay on state changes** — new state-changing browser endpoints
-   without CSRF protection; missing idempotency where retries can double-apply
-   (repudiation/tampering).
-9. **Resource exhaustion** — new unbounded loops/queries/uploads/allocations an
-   attacker controls (denial of service): missing pagination, no timeout, no
-   size cap.
-10. **Dependency risk** — a newly added dependency that is unmaintained,
-    typosquat-suspicious, or pulled for something the stdlib/project already does.
-11. **Error-path leaks** — stack traces, internal paths, or raw driver errors
-    surfaced to callers by the new error handling.
-12. **Crypto misuse** — home-rolled hashing/encryption, weak algorithms (MD5,
-    SHA1 for passwords), missing salts, static IVs in the diff.
-
-<!-- /orc:layer -->
+# Phase — Security pass   (id: `security-checklist`)
+
+> **Library file** (`orc`, `orc-diy`), `core` only: an opt-in pass runs its checklist or does not run.
+
+<!-- orc:layer core -->
+## Reference — Security-Pass Checklist (Phase 5.5, opt-in)
+
+Loaded ONLY when the Phase 5.5 security pass fires (config `security_review`
+`on`/`ask` + a task scored ≥ 70 in the run). Passed to the reviewer as
+`security_checklist[]` — the worker sweeps ONLY the run's changed files against
+these items, wrapping Semgrep if it is already installed (never installing it).
+
+Severity mapping (same P0–P3 ladder): an item the DIFF makes exploitable = P0 ·
+a hardening gap on a touched path = P1 · defense-in-depth suggestions = P2/P3.
+
+## Checklist (OWASP/STRIDE-derived, impact-ordered — the closed set; never extend ad hoc)
+
+1. **Injection** — SQL/NoSQL/command/LDAP built from user input without
+   parameterization or a safe builder anywhere in the diff.
+2. **Broken auth on new surface** — any new endpoint/route/handler reachable
+   without the auth check its siblings carry (spoofing).
+3. **Broken authorization** — object/record access without an ownership or role
+   check (IDOR); privilege boundaries crossed by the new code (elevation).
+4. **Secrets in code** — credentials, tokens, keys, or connection strings
+   hardcoded or logged; secrets reaching client bundles or responses
+   (information disclosure).
+5. **Unvalidated input** — request bodies/params/headers/files used before
+   schema validation; mass-assignment of writable model fields (tampering).
+6. **Injection into output** — XSS via unescaped user data in HTML/JS contexts;
+   unsafe redirects/headers from user input.
+7. **Insecure data handling** — sensitive data stored/transmitted unencrypted,
+   PII in logs, cache keys/values leaking secrets.
+8. **CSRF/replay on state changes** — new state-changing browser endpoints
+   without CSRF protection; missing idempotency where retries can double-apply
+   (repudiation/tampering).
+9. **Resource exhaustion** — new unbounded loops/queries/uploads/allocations an
+   attacker controls (denial of service): missing pagination, no timeout, no
+   size cap.
+10. **Dependency risk** — a newly added dependency that is unmaintained,
+    typosquat-suspicious, or pulled for something the stdlib/project already does.
+11. **Error-path leaks** — stack traces, internal paths, or raw driver errors
+    surfaced to callers by the new error handling.
+12. **Crypto misuse** — home-rolled hashing/encryption, weak algorithms (MD5,
+    SHA1 for passwords), missing salts, static IVs in the diff.
+
+<!-- /orc:layer -->

package/templates/skills/_shared/phases/security.md

@@ -1,55 +1,45 @@
-# Phase — Security pass (opt-in)   (id: `security`)
-
-> **Shared phase file.** Moved out of `orc/SKILL.md` at v1.0.0 W12, and into
-> this library at W13 when `orc-diy` became its second reader. A spine is loaded
-> IN FULL when its skill activates; this is loaded when the phase fires, and most
-> runs skip most phases.
->
-> **Two layers, and a lane reads exactly one.** `full` is `/orc`'s procedure.
-> `composed` is what `orc diy compile` stitches — the same phase expressed as
-> `<!-- diy:when -->` variants over a composed flow, NOT a second copy of the
-> procedure. Reading the wrong one is the failure `README.md` names: a lane
-> doing a phase its product promise says it does differently.
-> `orc lane phases <lane> --json` names the layer for each lane.
-
-<!-- orc:layer full -->
-
-## Security pass (opt-in)
-
-Only when config `security_review` is `on`/`ask` (default `off`) AND a task
-scored **≥ 70** (reuses the risk floor). `ask` → one P0 prompt; `on` →
-silent. Dispatch the reviewer with `phase=security` + changed files +
-`security-checklist.md` (load only now). Same ladder, same
-hard-rule-5 handling; report-only.
-
-<!-- /orc:layer -->
-
-<!-- orc:layer composed -->
-
-## Phase: Security pass
-
-<!-- diy:when security=off -->
-The security pass is OFF in this flow — skip silently.
-<!-- /diy:when -->
-<!-- diy:when security=ask -->
-When at least one task scored at or above the risk floor (70), ask the user
-once after review whether to run the security pass; on yes, run it exactly as
-the full lane's Phase 5.5 (reviewer re-dispatched with the checklist from
-`.claude/skills/_shared/phases/security-checklist.md`, sweeping only the
-run's changed files).
-<!-- /diy:when -->
-<!-- diy:when security=on -->
-When at least one task scored at or above the risk floor (70), dispatch the
-security pass without asking — the full lane's Phase 5.5 with the checklist
-from `.claude/skills/_shared/phases/security-checklist.md`, sweeping only the
-run's changed files.
-<!-- /diy:when -->
-<!-- diy:when security=always -->
-Dispatch the security pass on EVERY run of this flow, regardless of task
-scores — the full lane's Phase 5.5 with the checklist from
-`.claude/skills/_shared/phases/security-checklist.md`, sweeping only the
-run's changed files. (This flow removes the risk-floor trigger, not the
-pass's mechanics.)
-<!-- /diy:when -->
-
-<!-- /orc:layer -->
+# Phase — Security pass (opt-in)   (id: `security`)
+
+> **Shared phase file** — read when the phase fires. A lane reads ONE layer: `full` (`/orc`) or `composed` (the `<!-- diy:when -->` variants `orc diy compile` stitches). `orc lane phases <lane> --json` names it.
+
+<!-- orc:layer full -->
+
+## Security pass (opt-in)
+
+Only when config `security_review` is `on`/`ask` (default `off`) AND a task
+scored **≥ 70** (reuses the risk floor). `ask` → one P0 prompt (H `orc.phase-5-5.security`); `on` →
+silent. Dispatch the reviewer with `phase=security` + changed files +
+`security-checklist.md` (load only now). Same ladder, same
+hard-rule-5 handling; report-only.
+
+<!-- /orc:layer -->
+
+<!-- orc:layer composed -->
+
+## Phase: Security pass
+
+<!-- diy:when security=off -->
+The security pass is OFF in this flow — skip silently.
+<!-- /diy:when -->
+<!-- diy:when security=ask -->
+When at least one task scored at or above the risk floor (70), ask the user
+once after review (H `orc.phase-5-5.security`) whether to run the security pass; on yes, run it exactly as
+the full lane's Phase 5.5 (reviewer re-dispatched with the checklist from
+`.claude/skills/_shared/phases/security-checklist.md`, sweeping only the
+run's changed files).
+<!-- /diy:when -->
+<!-- diy:when security=on -->
+When at least one task scored at or above the risk floor (70), dispatch the
+security pass without asking — the full lane's Phase 5.5 with the checklist
+from `.claude/skills/_shared/phases/security-checklist.md`, sweeping only the
+run's changed files.
+<!-- /diy:when -->
+<!-- diy:when security=always -->
+Dispatch the security pass on EVERY run of this flow, regardless of task
+scores — the full lane's Phase 5.5 with the checklist from
+`.claude/skills/_shared/phases/security-checklist.md`, sweeping only the
+run's changed files. (This flow removes the risk-floor trigger, not the
+pass's mechanics.)
+<!-- /diy:when -->
+
+<!-- /orc:layer -->

package/templates/skills/_shared/phases/ship.md

@@ -1,16 +1,6 @@
 # Phase — Ship   (id: `ship`)
 
-> **Shared phase file.** Moved out of `orc/SKILL.md` at v1.0.0 W12, and into
-> this library at W13 when `orc-diy` became its second reader. A spine is loaded
-> IN FULL when its skill activates; this is loaded when the phase fires, and most
-> runs skip most phases.
->
-> **Two layers, and a lane reads exactly one.** `full` is `/orc`'s procedure.
-> `composed` is what `orc diy compile` stitches — the same phase expressed as
-> `<!-- diy:when -->` variants over a composed flow, NOT a second copy of the
-> procedure. Reading the wrong one is the failure `README.md` names: a lane
-> doing a phase its product promise says it does differently.
-> `orc lane phases <lane> --json` names the layer for each lane.
+> **Shared phase file** — read when the phase fires. A lane reads ONE layer: `full` (`/orc`) or `composed` (the `<!-- diy:when -->` variants `orc diy compile` stitches). `orc lane phases <lane> --json` names it.
 
 <!-- orc:layer full -->
 
@@ -23,7 +13,7 @@ Emit `PHASE ship start`. Show current branch.
 (`git diff --numstat`, exclusions applied) vs config `stacked_pr_loc`/
 `stacked_pr_files`. Under threshold or `stacked_pr: off` → silent, ship normally
 (`GATE stack-gate pass :: under-threshold`). Tripped → surface report + ONE P0
-question (stack into layers? or one regular PR?) in the SAME round as its two
+question (H `orc.phase-8.stack`: stack into layers? or one regular PR?) in the SAME round as its two
 prerequisites — **a ticket** and a resolved PR template
 (`_shared/pr-templates.md`; none found → recommend three options). No ticket, no
 template, or "no" → **one regular PR, never re-asked**. "Yes" → commit on the
@@ -36,7 +26,7 @@ GREEN surface in `orc handoff surfaces --json`, say so —
 *"2 of these were changes a PM could have made alone — `/orc-handoff` next time."*
 That sentence is how anyone finds out that lane exists.
 
-Then ask together: **commit? push? create PR?** (PR: ticket +
+Then ask together (H `orc.phase-8.ship`): **commit? push? create PR?** (PR: ticket +
 title + target branch; generate from `../../orc/subskills/orc-pr/pr.md`). If Phase 6.5 ran,
 commit `test-generator/<change-slug>/` too (a user deliverable, never gitignored).
 **`mock-examples/` is NEVER staged** (drift-recovery.md; no `.gitignore` edit —
@@ -46,10 +36,11 @@ On success: delete the ephemeral decision log; KEEP checkpoint + dispatch log.
 run changed; point at `/orc-wiki`. **Post-ship refresh ask** (BIG runs, /orc +
 /orc-ultra — the `wiki_refresh_ask_tasks`/`_files` triggers and full rules in
 `../../orc-wiki/references/staleness.md`): upgrade the passive note to **"Refresh
-wiki now?"**; on "later" print the prominent stale warning and stamp
+wiki now?"** (H `orc.phase-8.wiki-refresh`); on "later" print the prominent stale warning and stamp
 `wiki_refresh_declined` in the checkpoint. Then ALWAYS show the completion
 usage report — /usage limits + the full dispatch log (model/effort/score per
-subagent). The user must always know what the run cost. **Code graph
+subagent). The user must always know what the run cost. A `proposal` in
+`habits{}` → its ONE line joins that report (`../habits.md` §3). **Code graph
 (`../code-graph.md` §5–§6):** run `orc graph update --if-enabled` once more —
 fix rounds move code — and emit `GRAPH-UPDATE`; then run `orc graph notes pending
 --files <every path the run changed> --at end --if-enabled` — exit 0 → one noter

package/templates/skills/_shared/phases/stop-resume.md

@@ -1,9 +1,6 @@
 # Phase — Stop, usage report, resume   (id: `stop-resume`)
 
-> **Library file.** Canonical since v1.0.0 W11; it was
-> the `orc` skill's own `stop-and-resume` reference. Layers declared: `core` only — the stop
-> sequence is identical in every lane that stops, and the lane-specific half
-> (which moments are MANDATORY stops) is already a per-lane rule in the spine.
+> **Library file**, `core` only: the stop sequence is identical in every lane that stops; which moments are MANDATORY stops is a per-lane rule in the spine.
 
 <!-- orc:layer core -->
 
@@ -41,7 +38,7 @@ boundary is not.
 4. **Usage report** (see below).
 5. **Generate the resume block** (see below) — regenerate FRESH at every stop,
    never reuse an old one. It is printed inline AND is the body of `RESUME.md`.
-6. Tell the user: what's done / remaining, then BOTH continue paths:
+6. Tell the user: what's done / remaining, then BOTH continue paths (H `any.stop.where`):
    "Reply **continue** here, or paste the block below in a **fresh session**
    (recommended if this conversation is long — cheaper and cleaner than
    dragging this context forward)."

package/templates/skills/_shared/phases/summary.md

@@ -1,48 +1,73 @@
-# Phase — Summary   (id: `summary`)
-
-> **Shared phase file.** Moved out of `orc/SKILL.md` at v1.0.0 W12, and into
-> this library at W13 when `orc-diy` became its second reader. A spine is loaded
-> IN FULL when its skill activates; this is loaded when the phase fires, and most
-> runs skip most phases.
->
-> **Two layers, and a lane reads exactly one.** `full` is `/orc`'s procedure.
-> `composed` is what `orc diy compile` stitches — the same phase expressed as
-> `<!-- diy:when -->` variants over a composed flow, NOT a second copy of the
-> procedure. Reading the wrong one is the failure `README.md` names: a lane
-> doing a phase its product promise says it does differently.
-> `orc lane phases <lane> --json` names the layer for each lane.
-
-<!-- orc:layer full -->
-
-## Summary
-
-Emit `PHASE summary start`. Report: tasks/waves/dispatches (scores + overrides), escalations,
-needs_context events, findings by severity (P0/P1 resolved; P2 itemized; P3
-counted), verify result, authored tests when 6.5 ran, repo state + branch,
-stale_review flags. Then ONE question: **"Apply the P2 fix-batch? The P3
-cosmetics too?"** — never fix unasked. Emit `PHASE summary end`.
-
-<!-- /orc:layer -->
-
-<!-- orc:layer composed -->
-
-## Phase: Summary
-
-<!-- diy:when summary=off -->
-No summary phase: end after ship with a single line (tasks done / gate color
-/ ship action taken) plus usage, and note which phases this flow skipped.
-<!-- /diy:when -->
-<!-- diy:when summary=short -->
-Short summary: one paragraph — what was built, gate results, ship action,
-skipped phases, and usage. No per-task breakdown.
-<!-- /diy:when -->
-<!-- diy:when summary=full -->
-Full summary exactly as the full lane's final phase: per-task outcomes with
-models used, findings outcomes, verify results, ship action, skipped
-phases, and usage.
-<!-- /diy:when -->
-
-Always name the phases this flow skipped by config — the user must never
-mistake a DIY run for a full-lane run.
-
-<!-- /orc:layer -->
+# Phase — Summary   (id: `summary`)
+
+> **Shared phase file** — read when the phase fires. A lane reads ONE layer: `full` (`/orc`) or `composed` (the `<!-- diy:when -->` variants `orc diy compile` stitches). `orc lane phases <lane> --json` names it.
+
+<!-- orc:layer full -->
+
+## Summary
+
+Emit `PHASE summary start`. Report: tasks/waves/dispatches (scores + overrides), escalations,
+needs_context events, findings by severity (P0/P1 resolved; P2 itemized by
+`group`; P3 counted; `pre_existing` in its own non-gating bucket; the
+after-filter's `removed[]`, each with the id that removed it), verify result,
+authored tests when 6.5 ran, repo state + branch,
+stale_review flags. Then ONE question: **"Apply the P2 fix-batch? The P3
+cosmetics too?"** (H `orc.phase-7.p2-batch` · `orc.phase-7.p3-batch`) — never fix unasked.
+A yes dispatches ONE fix per `group` (R7), never one per finding. Then record
+each Phase 5 finding's outcome and emit `FINDING-OUTCOME` (`../gotchas.md` §10
+"Review close"). Print the card (§End-of-run card), then emit `PHASE summary end`.
+
+<!-- /orc:layer -->
+
+<!-- orc:layer composed -->
+
+## Phase: Summary
+
+<!-- diy:when summary=off -->
+No summary phase: end after ship with a single line (tasks done / gate color
+/ ship action taken) plus usage, and note which phases this flow skipped.
+<!-- /diy:when -->
+<!-- diy:when summary=short -->
+Short summary: one paragraph — what was built, gate results, ship action,
+skipped phases, and usage. No per-task breakdown.
+<!-- /diy:when -->
+<!-- diy:when summary=full -->
+Full summary exactly as the full lane's final phase: per-task outcomes with
+models used, findings outcomes, verify results, ship action, skipped
+phases, and usage.
+<!-- /diy:when -->
+
+Always name the phases this flow skipped by config — the user must never
+mistake a DIY run for a full-lane run. The run ends with the card
+(`.claude/skills/_shared/phases/summary.md` §End-of-run card).
+
+<!-- /orc:layer -->
+
+## End-of-run card
+
+**ONE template, the same shape in every coding lane.** `/orc` and `/orc-diy`
+print it at the end of the summary; `/orc-mini`, `/orc-fast` and `/orc-quick`
+point here and print it at their end — a green ship, a red STOP, or a quick
+entry that wrote code. Every detail goes BELOW the card, never above it.
+
+```
+✅ Fixed the null charge on guest checkout — 3 files, tests 14 passed (2 affected first)
+   review   2 findings · 1 fixed · 1 disputed (recorded)      gotchas  1 recorded (G-044)
+   risk     low — callers 3 in 2 files, tests reach 2          habits   1 proposal below
+   flaky    1 test passed on the re-run (no repair round)      graph    <gain line>
+   undo     orc undo --run <run-slug>                          next     commit? (your usual: review → commit)
+```
+
+- **Line 1 is the outcome.** Start with ✅ (done), ⚠ (partial) or ⛔ (red). Then
+  say what happened, the files and the tests. The first sentence answers "what
+  happened?".
+- **A row shows only when it has something.** Never print an empty row.
+- **The `undo` row always shows on a run that wrote code:**
+  `orc undo --run <run-slug>` — never `git checkout -- .`, which also discards
+  the user's own edits. No `checkpoint.json` with `actual_files` → add
+  `--files <actual_files>`. No snapshot (not a git repository) → say
+  `undo  none — no snapshot`. The command only PRINTS the undo; `--apply` runs
+  it. The lane never runs it itself.
+- **Copy the CLI's words.** `risk` is the `blast_line` with its `why`;
+  `graph` is the `orc graph gain` `line`, VERBATIM — an estimate with a range,
+  never restated as a saving. `flaky` is the `GATE flaky` tests.