@azure-id/orc 1.9.0 → 1.9.2

package/templates/skills/context-combiner/schemas/combined-report.md

@@ -1,78 +1,78 @@
-# Template — Combined Analysis Report
-
-Human-readable source of truth for a MERGE of 2+ related analyses. Written to
-orc/analyzer/combined-{name}/combined-report.md. Copied OUT to
-{report_out_dir}/combined-{name}/ on "stop here".
-
-```markdown
-# Combined Analysis Report — {combined-name}
-kind: combined
-combined_from: [analysis-A, analysis-B, ...]   # source analysis names
-scope: <the shared scope X these analyses live in>
-combined_at: DDMMYY HH:MM:SS
-combined_against: <git HEAD short sha the evidence spot-check ran against>
-model: opus-5-high        # the RESOLVED model of the combiner that produced
-                          #   this — never copied from here
-
-## Relatedness check
-How the source analyses overlap — shared files, overlapping requirements,
-shared scope. If overlap was weak, the user was challenged and their decision
-is recorded here.
-- Shared files: web/reports/x (analysis-A R1, analysis-B R2)
-- Overlapping requirement: both add export to the reports module
-- Verdict: related (confirmed) | combined-anyway (user override) | ...
-
-## Merged requirements (deduped, ordered)
-Every row carries file:line evidence inherited from the source spec (the
-combiner trusts confirmed specs; it does not re-derive the code) — spot-checked
-against `combined_against`; anchors that no longer match are marked STALE and
-were challenged, never silently carried. SEMANTIC-DUPLICATE merges quote both
-original statements. PARTIAL-OVERLAP rows are split (shared + residue), never
-collapsed. `Depth` is shown when sources differ in depth.
-
-| # | Requirement (merged) | From | Depth | Code reality | Evidence (file:line) | Files/modules | Status |
-|---|----------------------|------|-------|--------------|----------------------|---------------|--------|
-| 1 | "add CSV export"     | A.R1 | deep | HTML only    | web/reports/view.x:30 | web/reports/x | buildable |
-| 2 | "reuse report auth"  | A.R2, B.R3 (dedup) | standard | guard present | web/reports/routes.x:12 (STALE — user chose proceed) | web/reports/x | exists |
-
-## Source coverage matrix (conservation proof)
-EVERY source requirement ID appears exactly once with exactly one Outcome.
-`dropped` requires a recorded user decision in combine-decisions.md. The gate
-below must show coverage_pct: 100 before this report can hand off to build.
-
-| Source ID | Outcome | Merged as | Decision ref |
-|-----------|---------|-----------|--------------|
-| A.R1 | merged | #1 | — |
-| A.R2 | deduped-into | #2 | — |
-| B.R2 | conflict-resolved | #3 | combine-decisions.md #2 |
-| B.R3 | deduped-into | #2 | — |
-| B.R4 | dropped | — | combine-decisions.md #4 (user: superseded by A.R1) |
-
-- source requirements total: {N} · accounted: {N} · coverage_pct: 100
-
-## Additional context (do not build)
-Anchored, non-actionable context merged from the sources — each item re-pointed at
-the merged requirement it serves. Dedupe ONLY when the evidence anchor is the same
-file:line AND the notes convey the same constraint — near-identical notes are kept,
-both, with their own From tags. Read for understanding; never a task. Omit this
-whole section if no source carried context.
-| Anchor (merged #) | From | From scope | Dependency | Touchpoint to respect | Evidence (file:line) |
-|-------------------|------|-----------|------------|-----------------------|----------------------|
-| 1 (CSV export) | A.ctx | reporting (Y) | consumes-output | report query already paginates; export must page too | web/reports/query.x:44 |
-
-## Cross-scope conflicts & decisions
-Every conflict/duplicate/partial-overlap/ordering issue found across sources
-(including contradictory resolved assumptions), each raised as a
-recommended-option challenge and resolved. Decisions are also checkpointed
-eagerly in combine-decisions.md.
-- CONFLICT (resolved): A.R4 wants offset paging, B.R2 wants cursor — user chose cursor.
-- DUPLICATE (merged): A.R2 and B.R3 both reuse auth — merged into #2.
-- PARTIAL-OVERLAP (split): A.R5 subsumes B.R1 — shared row #4, A-only residue row #5.
-- ORDERING (structured): before: #1 (A export) → after: #6 (B schedule).
-
-## Open questions (block handoff until resolved)
-- (none) | UNRESOLVED: ... — combiner refuses build handoff while any remain.
-
-## Handoff readiness
-- complete: yes/no   (coverage_pct == 100, all conflicts resolved, no open UNRESOLVED)
-```
+# Template — Combined Analysis Report
+
+Human-readable source of truth for a MERGE of 2+ related analyses. Written to
+orc/analyzer/combined-{name}/combined-report.md. Copied OUT to
+{report_out_dir}/combined-{name}/ on "stop here".
+
+```markdown
+# Combined Analysis Report — {combined-name}
+kind: combined
+combined_from: [analysis-A, analysis-B, ...]   # source analysis names
+scope: <the shared scope X these analyses live in>
+combined_at: DDMMYY HH:MM:SS
+combined_against: <git HEAD short sha the evidence spot-check ran against>
+model: opus-5-5-high      # the RESOLVED model of the combiner that produced
+                          #   this — never copied from here
+
+## Relatedness check
+How the source analyses overlap — shared files, overlapping requirements,
+shared scope. If overlap was weak, the user was challenged and their decision
+is recorded here.
+- Shared files: web/reports/x (analysis-A R1, analysis-B R2)
+- Overlapping requirement: both add export to the reports module
+- Verdict: related (confirmed) | combined-anyway (user override) | ...
+
+## Merged requirements (deduped, ordered)
+Every row carries file:line evidence inherited from the source spec (the
+combiner trusts confirmed specs; it does not re-derive the code) — spot-checked
+against `combined_against`; anchors that no longer match are marked STALE and
+were challenged, never silently carried. SEMANTIC-DUPLICATE merges quote both
+original statements. PARTIAL-OVERLAP rows are split (shared + residue), never
+collapsed. `Depth` is shown when sources differ in depth.
+
+| # | Requirement (merged) | From | Depth | Code reality | Evidence (file:line) | Files/modules | Status |
+|---|----------------------|------|-------|--------------|----------------------|---------------|--------|
+| 1 | "add CSV export"     | A.R1 | deep | HTML only    | web/reports/view.x:30 | web/reports/x | buildable |
+| 2 | "reuse report auth"  | A.R2, B.R3 (dedup) | standard | guard present | web/reports/routes.x:12 (STALE — user chose proceed) | web/reports/x | exists |
+
+## Source coverage matrix (conservation proof)
+EVERY source requirement ID appears exactly once with exactly one Outcome.
+`dropped` requires a recorded user decision in combine-decisions.md. The gate
+below must show coverage_pct: 100 before this report can hand off to build.
+
+| Source ID | Outcome | Merged as | Decision ref |
+|-----------|---------|-----------|--------------|
+| A.R1 | merged | #1 | — |
+| A.R2 | deduped-into | #2 | — |
+| B.R2 | conflict-resolved | #3 | combine-decisions.md #2 |
+| B.R3 | deduped-into | #2 | — |
+| B.R4 | dropped | — | combine-decisions.md #4 (user: superseded by A.R1) |
+
+- source requirements total: {N} · accounted: {N} · coverage_pct: 100
+
+## Additional context (do not build)
+Anchored, non-actionable context merged from the sources — each item re-pointed at
+the merged requirement it serves. Dedupe ONLY when the evidence anchor is the same
+file:line AND the notes convey the same constraint — near-identical notes are kept,
+both, with their own From tags. Read for understanding; never a task. Omit this
+whole section if no source carried context.
+| Anchor (merged #) | From | From scope | Dependency | Touchpoint to respect | Evidence (file:line) |
+|-------------------|------|-----------|------------|-----------------------|----------------------|
+| 1 (CSV export) | A.ctx | reporting (Y) | consumes-output | report query already paginates; export must page too | web/reports/query.x:44 |
+
+## Cross-scope conflicts & decisions
+Every conflict/duplicate/partial-overlap/ordering issue found across sources
+(including contradictory resolved assumptions), each raised as a
+recommended-option challenge and resolved. Decisions are also checkpointed
+eagerly in combine-decisions.md.
+- CONFLICT (resolved): A.R4 wants offset paging, B.R2 wants cursor — user chose cursor.
+- DUPLICATE (merged): A.R2 and B.R3 both reuse auth — merged into #2.
+- PARTIAL-OVERLAP (split): A.R5 subsumes B.R1 — shared row #4, A-only residue row #5.
+- ORDERING (structured): before: #1 (A export) → after: #6 (B schedule).
+
+## Open questions (block handoff until resolved)
+- (none) | UNRESOLVED: ... — combiner refuses build handoff while any remain.
+
+## Handoff readiness
+- complete: yes/no   (coverage_pct == 100, all conflicts resolved, no open UNRESOLVED)
+```

package/templates/skills/orc/README.md

@@ -94,11 +94,11 @@ codifier: 9 language playbooks + a11y/perf rule packs), `context-combiner`
 ## Key behaviors to know
 
 - **The orchestrator NEVER implements — it always spawns scored subagents,
-  even for tiny tasks.** Orchestrator (Opus 4.8 high, or Opus 5 / Fable 5 at
+  even for tiny tasks.** Orchestrator (Opus 4.8 high, or Opus 5.5 / Fable 5 at
   medium+) only coordinates; each task's 0–100 score (computed arithmetically
   from the planner's per-task `facets`) maps to a named executor agent via the
   single 6-band table in `config.md` (`rubric_bands` = report granularity only),
-  Haiku 4.5 [0,30) → Opus 5 low [65,90) → Opus 5 medium [90,100].
+  Haiku 4.5 [0,30) → Opus 5.5 low [65,90) → Opus 5.5 medium [90,100].
 - **Every executor slice carries** the intent-spec constraints, the task's
   sliced acceptance criteria, the standing
   house-rules card, and — when a code-pattern is resolved — your project's

package/templates/skills/orc/SKILL.md

@@ -13,7 +13,7 @@ description: >
 
 # ORC (orchestrator spine)
 
-You are the **orchestrator**: **Opus 4.8 high — or Opus 5 / Fable 5 at medium+**
+You are the **orchestrator**: **Opus 4.8 high — or Opus 5.5 / Fable 5 at medium+**
 (never downgrade yourself). You own the schemas, the dependency/conflict graph, wave
 scheduling, per-task model scoring, all checkpoint writes, user Q&A relay, and
 every decision below. Workers stay dumb and isolated.
@@ -24,8 +24,8 @@ version of a reference you haven't loaded this run. Detect the stack from the re
 
 ## Preflight gate (before Phase 0 — do this FIRST)
 
-Confirm you are **Opus 4.8 high**, or **Opus 5 / Fable 5 at medium+** (both clear
-the guard from medium up; Opus 5 also unlocks the [90,100] executor band). Effort
+Confirm you are **Opus 4.8 high**, or **Opus 5.5 / Fable 5 at medium+** (both clear
+the guard from medium up; Opus 5.5 also unlocks the [90,100] executor band). Effort
 is hard-blocked by the `orc-effort-guard.js` PreToolUse hook; the model cannot be
 (hooks can't see it) — the statusline warns. On a weaker tier **STOP immediately**
 and tell the user to switch the main session and re-run — never intake below it
@@ -69,11 +69,11 @@ themselves are this lane's own and stay here.
 
 ## Dispatched roles (you never do this work yourself)
 
-**Analyst** `orc-analyze` (Opus 5 high): doc OR bare request →
+**Analyst** `orc-analyze` (Opus 5.5 high): doc OR bare request →
 scope-bounded, code-grounded report + spec; standard or opt-in DEEP (scouts).
-**Context-combiner** (Opus 5 high): merges 2+ related confirmed analyses
+**Context-combiner** (Opus 5.5 high): merges 2+ related confirmed analyses
 into ONE combined spec; build only on `handoff_ready` with `coverage_pct` =
-100; full lane only. **Planner** `subskills/orc-planner` (Opus 5 medium):
+100; full lane only. **Planner** `subskills/orc-planner` (Opus 5.5 medium):
 request or spec → planning-output. Scout dispatch, analyst-return gates,
 combiner tracking, the `git_head` staleness valve, and the Phase 1 exit gate
 are YOURS and deterministic — load `../_shared/phases/analyst-gates.md` at their
@@ -96,7 +96,7 @@ requeue) run the same formula, inherit the original task's risk floor, and never
 dispatch below the finding-task's band. Fixed roles dispatch BY NAME (analyst /
 combiner / planner / reviewer / verifier — see `config.md`'s fixed-role table +
 `.claude/agents/MODEL-MAPPING.md`). If `opus5_only`, EVERY role (scored and fixed)
-resolves to its Opus 5 agent, FORCING over everything below — `_shared/opus5-only.md`.
+resolves to its Opus 5.5 agent, FORCING over everything below — `_shared/opus5-only.md`.
 Caveat: a subagent's model can't exceed the MAIN session's tier — run the main
 session on Opus or the Opus pins silently fall back (the original "wrong model" bug).
 
@@ -205,7 +205,7 @@ them; they are never dispatched as subagents).
 - Phase 5.5 → `../_shared/phases/security-checklist.md`; 6.5 → `subskills/orc-testgen/`
 - Phase 8 → `subskills/orc-pr/SKILL.md` (template `subskills/orc-pr/pr.md`);
   stack gate → `subskills/orc-pr/stack-gate.md` + `_shared/pr-templates.md`
-- Code graph cache, NEVER skipped (§0 of the contract) — `orc graph status --if-enabled --heal --json` at preflight BEFORE the first dispatch (builds or updates it) · ONE `orc graph ctx <declared files>` call per slice · `orc graph map` FIRST at planning (orientation — before any Glob, before `impact`) then `orc graph impact` + `orc graph cochange`, `orc graph changes` at review · `orc graph coverage` before you trust a card's silence · `orc graph update` + `orc graph notes` at every wave close and ship · print each JSON `line`, copy each `trace` VERBATIM (CLI-resolved) → `../_shared/code-graph.md`
+- Code graph cache, NEVER skipped (§0 of the contract) — `orc graph status --if-enabled --heal --json` at preflight BEFORE the first dispatch (builds or updates it) · ONE `orc graph ctx <declared files>` call per slice · `orc graph map` FIRST at planning (orientation — before any Glob, before `impact`) then `orc graph impact` + `orc graph cochange`, `orc graph changes` at review · `orc graph coverage` before you trust a card's silence · `orc graph update` + `orc graph notes` at every wave close and ship · every `--json` read carries `--brief` · print each JSON `line`, copy each `trace` VERBATIM (CLI-resolved) → `../_shared/code-graph.md`
 - Schemas (you own; pass slices only): `schemas/intent-spec.md`,
   `schemas/planning-output.md`, `schemas/checkpoint.md`
 - Worked example (orient only — never execute from it) → `examples/full-run-mock.md`

package/templates/skills/orc/config.md

@@ -35,13 +35,13 @@ canonical 6-band table, and dispatches the matching **executor agent**.
 | [30,40)  | claude-sonnet-4-6 | medium | orc-executor-sonnet-4-6-med |
 | [40,55)  | claude-sonnet-4-6 | high   | orc-executor-sonnet-4-6-high |
 | [55,65)  | claude-sonnet-5   | high   | orc-executor-sonnet-5-high |
-| [65,90)  | claude-opus-5     | low    | orc-executor-opus-5-low |
-| [90,100] | claude-opus-5     | medium | orc-executor-opus-5-med |
+| [65,90)  | claude-opus-5-5     | low    | orc-executor-opus-5-low |
+| [90,100] | claude-opus-5-5     | medium | orc-executor-opus-5-med |
 
 (Haiku has no effort ladder — that agent carries no `effort:` field.) The risk
 floor (≥70) lands `orc-executor-opus-5-low` at minimum in THIS table. Above ~65
 the useful dial stopped being the model GENERATION and became the EFFORT, which
-is why the old four Opus rows are two. **Every band from 65 needs an Opus 5 MAIN
+is why the old four Opus rows are two. **Every band from 65 needs an Opus 5.5 MAIN
 session** or it silently falls back to the session model (the tier-honesty rule
 reports the downgrade) — two bands where it used to be one, and that is the cost
 of this table.
@@ -59,15 +59,15 @@ One model, EFFORT as the cost dial. Off by default; nothing changes until set.
 
 | Score | Model | Effort | Executor agent |
 |-------|-------|--------|----------------|
-| [0,90)   | claude-opus-5 | low    | orc-executor-opus-5-low |
-| [90,100] | claude-opus-5 | medium | orc-executor-opus-5-med |
+| [0,90)   | claude-opus-5-5 | low    | orc-executor-opus-5-low |
+| [90,100] | claude-opus-5-5 | medium | orc-executor-opus-5-med |
 
 Two bands, sharing the 90 edge with the default table's top two rows. That
-symmetry is the point: once the default table's high end is already Opus 5 with
+symmetry is the point: once the default table's high end is already Opus 5.5 with
 effort as the dial, this mode differs from it only BELOW 65, so a third band
 would be a distinction the default table stopped making.
 
-**Tier cost:** today TWO bands in six need an Opus 5 main session; with this on,
+**Tier cost:** today TWO bands in six need an Opus 5.5 main session; with this on,
 EVERY dispatch does, so a lower session downgrades every task (warn-only — a
 hook can gate effort, never model). **Scope:** it is NOT executor-only — it also
 forces every fixed role below, across every lane. orc-diy's table
@@ -93,8 +93,8 @@ un-shown number.
 | Ultra advisor (/orc-ultra only) | orc-advisor-opus-5-xhigh |
 | Ultra judge (/orc-ultra only) | orc-judge-opus-5-xhigh |
 
-Under `opus5_only`, every role above that is not already `claude-opus-5`
-dispatches its Opus 5 variant instead — plus the roles owned by other lanes
+Under `opus5_only`, every role above that is not already `claude-opus-5-5`
+dispatches its Opus 5.5 variant instead — plus the roles owned by other lanes
 (scout, wiki scanner, CLAUDE.md writer, retro miner, fast executor).
 
 ## Where each subsystem's rule is written down

package/templates/skills/orc/examples/full-run-mock.md

@@ -1,73 +1,73 @@
-# Example — Annotated Full Run (v2.2, dry run)
-
-O: = orchestrator (Opus 4.8 high, always) · U: = user. Nothing real. The
-orchestrator NEVER implements — it always spawns scored subagents.
-
-U: Orchestrate: merchant notification system — in-app, email digest, prefs page.
-
-## Phase 0 — Intake
-O: Creates run folder run/merchant-notifications/ FIRST.
-   [reads repo: TS/yarn/jest — asks nothing about stack] Rough size: medium+ → 4-question tier (one batched round):
-   1) What should exist when done? 2) Out of scope? 3) How do we know it's done? 4) Patterns/files to avoid?
-U: [answers] no push, no admin; bell count + both digest schedules + prefs persist; follow services/ pattern, don't touch auth_service.
-O: [drafts run/merchant-notifications/intent-spec.md] Sign-off: gate or soft? (default gate)
-U: gate → approved
-
-## Phase 1 — Planning
-O: Planner? U: OpenSpec
-O: [6 tasks with declared_files incl. tests + per-file grounding attestations + sliced acceptance[], depends_on, spec_ref] ⚠ T1/T2 share models/notification.ts → scheduling separates them.
-   Grounding spot-check (Phase 1 exit): globs all `exists` paths — 13/14 present, models/notifcation.ts MISSING (typo) → plan bounced to planner with the miss list → corrected to models/notification.ts ✓.
-
-## Phase 2 — Effort, dispatch style, scoring
-O: Refined: medium, partially dependent. Recommend PARALLEL waves. Confirm? U: yes. Batch pause? U: every 2 waves.
-O: Facet scoring (planner facets → formula → band; facet gate: breadth + fan recomputed, risk cites checked):
-   T1 3·new-surface·stateful·new-tests·fan0/3·low = 6+18+16+8+9 = 57 → sonnet-5-high (keystone — every later task imports its enum)
-   T2 3·imitate·branching·new-tests·fan1/0·low = 6+8+8+8+5 = 35 → sonnet-4-6-med
-   T3 3·imitate·branching·update-existing·fan1/0·low = 6+8+8+4+5 = 31 → sonnet-4-6-med
-   T4 2·imitate·branching·update-existing·fan1/0·low = 6+8+8+4+5 = 31 → sonnet-4-6-med
-   T5 1·mechanical·none·update-existing·fan0/0·low = 2+0+0+4 = 6 → haiku-4-5
-   T6 1·mechanical·none·none·fan0/0·low = 2+0+0+0 = 2 → haiku-4-5
-   Plan: 6 tasks, 3 waves W1{T1} W2{T2,T3,T4} W3{T5,T6}, all spawned. Anticipated escalations? U: none, go.
-
-## Phase 3 — Execution (ALL spawned; orchestrator coordinates only)
-O: [checkpoint + state-of-play written into run/merchant-notifications/ BEFORE dispatch]
-▶ W1: spawn Agent-A(T1, sonnet-5-high) — milestones 40%→100% — return validated ✓ (evidence: `yarn jest models/` exit 0, tail quoted; unmet[] empty) — log: DECISION type enum.
-▶ W2: spawn 3 agents (sonnet-4-6-med each).
-   Agent-C needs_context (1/2): "needs T1's enum interface" → O adjudicates in-scope → re-slices → resumes. (User never bothered.)
-   Agent-C user escalation: "digest send time?" → U: 07:00 fixed → ANSWER broadcast to log.
-   Returns validated ✓ · collision audit clean.
-⏸ BATCH PAUSE (stop sequence):
-   checkpoint ✓ → state-of-play ✓ → dispatch report shown (models/scores) → "Run /usage to see your remaining limits."
-   → resume block:
-   | Continue ORC run `merchant-notifications`.
-   | Read run/merchant-notifications/state-of-play.md, then run/merchant-notifications/checkpoint.json.
-   | Resume from checkpoint phase/wave. Intent-spec approved — do not re-plan. Do not redo done tasks.
-   "Reply continue here, or paste in a fresh session (recommended if long)."
-
-U: [next day, FRESH session, pastes block]
-O: [state-of-play → checkpoint → re-anchored] "Resuming: merchant notifications (in-app+digest+prefs). Still correct?" U: yes.
-▶ W3: spawn T5+T6 (haiku-4-5) → done. All 6 complete.
-
-## Phase 5 — Review (spawned worker, Opus 5 medium)
-O: Code pattern? U: none. Findings (P0–P3 ladder, each P0–P2 anchored file:line + verbatim quote):
-   P1 T2 no pagination — services/notification_list.ts:88 — O spot-checks: Reads line 88, quote matches ✓ → asks user, U: fix it
-   · P3 email_digest naming ×2 · 12 tests added. (An unanchored finding would be auto-P3 — never fixed unasked.)
-
-## Phase 6 — Verify (spawned worker, Opus 5 medium; criteria = definition-of-done)
-   criteria[] with per-line evidence: bell ✓ (test name) · both schedules ✗ (weekly cron missing = P0, unmet criterion, evidence: no cron entry in scheduler.ts) · prefs ✓ → FAILED → quote spot-check ✓ → P0 auto-fix (single attempt, no ask) → re-verify → PASSED. 14/14.
-
-## Phase 7 — Summary
-O: 6 tasks/3 waves/6 spawns/1 pause/1 fresh-session resume · 1 needs_context · 1 escalation · verify fixed_then_passed · branch green. P2 fix-batch: none · Apply the 2 P3 cosmetics? U: no.
-
-## Phase 8 — Ship (orc-pr, reads pr.md)
-O: Branch: feat/notifications. Commit? Push? PR? U: yes all.
-O: Ticket/title/target? U: DRP-482 / Add merchant notification system / develop
-O: ✓ committed → pushed → run/merchant-notifications/DRP-482-add-merchant-notification-system.md from pr.md (base develop).
-   Log deleted · checkpoint + dispatch log KEPT · completion dispatch report shown → "Run /usage to see your remaining limits."
-
-## What this exercises
-always-spawn (even cheap tasks get a subagent) · facet-scored arithmetic · 6-band ladder ·
-per-run folder run/merchant-notifications/ · usage reminder (no programmatic /usage) ·
-planner grounding spot-check catching a hallucinated path · executor evidence (verbatim
-build/test proof) · reviewer quote spot-check before any P0/P1 action ·
-definition-of-done catching the weekly-cron gap · needs_context resolved internally · fresh-session resume.
+# Example — Annotated Full Run (v2.2, dry run)
+
+O: = orchestrator (Opus 4.8 high, always) · U: = user. Nothing real. The
+orchestrator NEVER implements — it always spawns scored subagents.
+
+U: Orchestrate: merchant notification system — in-app, email digest, prefs page.
+
+## Phase 0 — Intake
+O: Creates run folder run/merchant-notifications/ FIRST.
+   [reads repo: TS/yarn/jest — asks nothing about stack] Rough size: medium+ → 4-question tier (one batched round):
+   1) What should exist when done? 2) Out of scope? 3) How do we know it's done? 4) Patterns/files to avoid?
+U: [answers] no push, no admin; bell count + both digest schedules + prefs persist; follow services/ pattern, don't touch auth_service.
+O: [drafts run/merchant-notifications/intent-spec.md] Sign-off: gate or soft? (default gate)
+U: gate → approved
+
+## Phase 1 — Planning
+O: Planner? U: OpenSpec
+O: [6 tasks with declared_files incl. tests + per-file grounding attestations + sliced acceptance[], depends_on, spec_ref] ⚠ T1/T2 share models/notification.ts → scheduling separates them.
+   Grounding spot-check (Phase 1 exit): globs all `exists` paths — 13/14 present, models/notifcation.ts MISSING (typo) → plan bounced to planner with the miss list → corrected to models/notification.ts ✓.
+
+## Phase 2 — Effort, dispatch style, scoring
+O: Refined: medium, partially dependent. Recommend PARALLEL waves. Confirm? U: yes. Batch pause? U: every 2 waves.
+O: Facet scoring (planner facets → formula → band; facet gate: breadth + fan recomputed, risk cites checked):
+   T1 3·new-surface·stateful·new-tests·fan0/3·low = 6+18+16+8+9 = 57 → sonnet-5-high (keystone — every later task imports its enum)
+   T2 3·imitate·branching·new-tests·fan1/0·low = 6+8+8+8+5 = 35 → sonnet-4-6-med
+   T3 3·imitate·branching·update-existing·fan1/0·low = 6+8+8+4+5 = 31 → sonnet-4-6-med
+   T4 2·imitate·branching·update-existing·fan1/0·low = 6+8+8+4+5 = 31 → sonnet-4-6-med
+   T5 1·mechanical·none·update-existing·fan0/0·low = 2+0+0+4 = 6 → haiku-4-5
+   T6 1·mechanical·none·none·fan0/0·low = 2+0+0+0 = 2 → haiku-4-5
+   Plan: 6 tasks, 3 waves W1{T1} W2{T2,T3,T4} W3{T5,T6}, all spawned. Anticipated escalations? U: none, go.
+
+## Phase 3 — Execution (ALL spawned; orchestrator coordinates only)
+O: [checkpoint + state-of-play written into run/merchant-notifications/ BEFORE dispatch]
+▶ W1: spawn Agent-A(T1, sonnet-5-high) — milestones 40%→100% — return validated ✓ (evidence: `yarn jest models/` exit 0, tail quoted; unmet[] empty) — log: DECISION type enum.
+▶ W2: spawn 3 agents (sonnet-4-6-med each).
+   Agent-C needs_context (1/2): "needs T1's enum interface" → O adjudicates in-scope → re-slices → resumes. (User never bothered.)
+   Agent-C user escalation: "digest send time?" → U: 07:00 fixed → ANSWER broadcast to log.
+   Returns validated ✓ · collision audit clean.
+⏸ BATCH PAUSE (stop sequence):
+   checkpoint ✓ → state-of-play ✓ → dispatch report shown (models/scores) → "Run /usage to see your remaining limits."
+   → resume block:
+   | Continue ORC run `merchant-notifications`.
+   | Read run/merchant-notifications/state-of-play.md, then run/merchant-notifications/checkpoint.json.
+   | Resume from checkpoint phase/wave. Intent-spec approved — do not re-plan. Do not redo done tasks.
+   "Reply continue here, or paste in a fresh session (recommended if long)."
+
+U: [next day, FRESH session, pastes block]
+O: [state-of-play → checkpoint → re-anchored] "Resuming: merchant notifications (in-app+digest+prefs). Still correct?" U: yes.
+▶ W3: spawn T5+T6 (haiku-4-5) → done. All 6 complete.
+
+## Phase 5 — Review (spawned worker, Opus 5.5 medium)
+O: Code pattern? U: none. Findings (P0–P3 ladder, each P0–P2 anchored file:line + verbatim quote):
+   P1 T2 no pagination — services/notification_list.ts:88 — O spot-checks: Reads line 88, quote matches ✓ → asks user, U: fix it
+   · P3 email_digest naming ×2 · 12 tests added. (An unanchored finding would be auto-P3 — never fixed unasked.)
+
+## Phase 6 — Verify (spawned worker, Opus 5.5 medium; criteria = definition-of-done)
+   criteria[] with per-line evidence: bell ✓ (test name) · both schedules ✗ (weekly cron missing = P0, unmet criterion, evidence: no cron entry in scheduler.ts) · prefs ✓ → FAILED → quote spot-check ✓ → P0 auto-fix (single attempt, no ask) → re-verify → PASSED. 14/14.
+
+## Phase 7 — Summary
+O: 6 tasks/3 waves/6 spawns/1 pause/1 fresh-session resume · 1 needs_context · 1 escalation · verify fixed_then_passed · branch green. P2 fix-batch: none · Apply the 2 P3 cosmetics? U: no.
+
+## Phase 8 — Ship (orc-pr, reads pr.md)
+O: Branch: feat/notifications. Commit? Push? PR? U: yes all.
+O: Ticket/title/target? U: DRP-482 / Add merchant notification system / develop
+O: ✓ committed → pushed → run/merchant-notifications/DRP-482-add-merchant-notification-system.md from pr.md (base develop).
+   Log deleted · checkpoint + dispatch log KEPT · completion dispatch report shown → "Run /usage to see your remaining limits."
+
+## What this exercises
+always-spawn (even cheap tasks get a subagent) · facet-scored arithmetic · 6-band ladder ·
+per-run folder run/merchant-notifications/ · usage reminder (no programmatic /usage) ·
+planner grounding spot-check catching a hallucinated path · executor evidence (verbatim
+build/test proof) · reviewer quote spot-check before any P0/P1 action ·
+definition-of-done catching the weekly-cron gap · needs_context resolved internally · fresh-session resume.