@azure-id/orc 1.9.0 → 1.9.2

package/templates/skills/_shared/opus5-only.md

@@ -22,11 +22,11 @@ mixed-model table:
 | `[90,100]` | `orc-executor-opus-5-med`  |
 
 Two bands, sharing the 90 edge with the default table's top two rows. Since
-v1.0.0 the default table's high end is ALREADY Opus 5 with effort as the dial,
+v1.0.0 the default table's high end is ALREADY Opus 5.5 with effort as the dial,
 so this mode differs from it only below 65 — a third band here would be a
 distinction the default table stopped making.
 
-**Fixed roles** — dispatch the Opus 5 variant **instead of** the default role
+**Fixed roles** — dispatch the Opus 5.5 variant **instead of** the default role
 agent: same task slice, same return contract, same phase.
 
 | Role | Default agent | Opus-5-only variant |
@@ -41,14 +41,14 @@ agent: same task slice, same return contract, same phase.
 | claude write | `orc-claude-writer-opus-4-8-high` | `orc-claude-writer-opus-5-med` |
 | retro mine | `orc-retro-sonnet-5-high` | `orc-retro-opus-5-med` |
 
-The nine roles already pinned to `claude-opus-5` — analyst, planner, reviewer,
+The nine roles already pinned to `claude-opus-5-5` — analyst, planner, reviewer,
 verifier, test-author, combiner, learn-writer, advisor, judge — are already
 compliant and dispatch unchanged (their efforts are NOT rewritten by this mode).
 
 **The wiki scan tier ladder (v0.46.0) adds NO row here, and needs no new pair.**
 Off, the ladder picks deep or light per delta. ON, this mode already forces the
 wiki scanner to `orc-wiki-scanner-opus-5-med` — so **both tiers collapse onto that
-one shipped agent** and the ladder simply stops applying. A cheaper Opus 5 scanner
+one shipped agent** and the ladder simply stops applying. A cheaper Opus 5.5 scanner
 variant for the light tier does not exist and must never be added: a pair for a
 tier that cannot occur while the flag is on is exactly the phantom this table
 exists to prevent. Ladder: `../orc-wiki/references/partial-refresh.md`.
@@ -58,7 +58,7 @@ exists to prevent. Ladder: `../orc-wiki/references/partial-refresh.md`.
 - **`orc-trace-writer-haiku-4-5` stays Haiku 4.5.** It transcribes a packet the
   orchestrator hands it — no reasoning, no source reads. It is never in the
   roster.
-- **`orc-graph-noter-sonnet-4-6-med` is not dispatched at all.** It has no Opus 5
+- **`orc-graph-noter-sonnet-4-6-med` is not dispatched at all.** It has no Opus 5.5
   variant: under the mode a code lane skips graph notes and prints
   `graph notes: skipped (opus5_only)` (`code-graph.md` §6). The graph's structure
   layer costs no model, so nothing else about the graph changes.
@@ -73,7 +73,7 @@ exists to prevent. Ladder: `../orc-wiki/references/partial-refresh.md`.
   the lane SAYS so at the gate (`orc-quick ignores opus5_only — both options are
   live`), because a shadowed setting must never be silent in either direction.
 - **`/orc-challenge` — UNAFFECTED, not exempt.** All three of its agents are
-  already `claude-opus-5` (judge high, advisor medium, reader low), so the mode
+  already `claude-opus-5-5` (judge high, advisor medium, reader low), so the mode
   has nothing to force: zero new pairs, no rename churn, no roster row. The
   reader's `low` effort is a MEASUREMENT choice, not a cost one — a
   harder-thinking cold reader reasons around exactly the gaps D4 exists to find
@@ -102,7 +102,7 @@ mode is neither shadowed nor shadowing — it is simply **NOT CONSULTED** for th
 work extra took:
 
 - **a scored task** — an extra route row covering that score outranks the mode;
-  every score no row covers still resolves on the Opus 5 ladder.
+  every score no row covers still resolves on the Opus 5.5 ladder.
 - **a POSITION** (v0.55.0 — `quick-executor`, `fast-executor`, `doc-writer`,
   `doc-checker`, `wiki-scanner-deep`, `wiki-scanner-light`) — an extra slot row
   holding that position outranks the mode's variant of that slot's agent; **a
@@ -121,7 +121,7 @@ POSITION, not the model.
 ## Tier honesty
 
 A subagent can never outrank the main session. With the mode ON, EVERY dispatch
-needs an Opus 5 main session — not just the top executor band. On a lower
+needs an Opus 5.5 main session — not just the top executor band. On a lower
 session every role silently falls back to the session model and the tier-honesty
 rule (`return-validation.md`) reports a downgrade on **every** return. That is
 correct behavior, not a bug: hooks cannot block on model, only on effort, so the

package/templates/skills/_shared/phases/analyst-gates.md

@@ -1,136 +1,136 @@
-# Phase — Analyst & plan gates   (id: `analyst-gates`)
-
-> **Library file.** Canonical since v1.0.0 W12; it was under the `orc` skill's
-> private `references/`, and other lanes already reached across into it. Read
-> by `orc`, `orc-analyze`, `orc-mini`. Layers declared: `core` only — single-
-> layer because these are the orchestrator-side gates on a returned analysis
-> or plan, and a trimmed lane runs fewer of them rather than different ones.
-> `orc lane phases <lane> --json` names the file and the layers to read.
-
-<!-- orc:layer core -->
-## Reference — Analyst, Combiner & Plan Gates (orchestrator side)
-
-The orchestrator's deterministic gates around the analyst, the
-context-combiner, and the planner. The roles themselves are defined in
-`../../orc-analyze/SKILL.md`, `../../context-combiner/SKILL.md`, and
-`../../orc/subskills/orc-planner/SKILL.md` — this file is what YOU do around their
-dispatches and returns. Load at Phase 0 (analyst dispatch) and Phase 1
-(planner return). Emit a `GATE` trace line (pass|bounce) per check when
-logging.
-
-## Deep-mode scout dispatch (yours)
-
-When the analyst runs in deep mode it returns a `scout_plan` (pass 1). You then
-dispatch ≤ `config.max_scouts` (default 3) parallel
-`orc-scout-sonnet-4-6-high` agents (`orc-scout-opus-5-low` when `opus5_only`
-— `../../_shared/opus5-only.md`; scouts fan out in PARALLEL, so this is the
-mode's largest single cost multiplier) — one coverage area each, read-only — and
-re-dispatch the analyst WITH their evidence bundles for pass 2. Same "return a
-request → you re-slice → re-dispatch" shape as `needs_context`. You never
-analyze; you only dispatch and relay.
-
-## Analyst-return gates (deterministic, before any build option)
-
-1. **Evidence spot-check:** Glob every `files[]` path in the spec +
-   Grep-verify the quoted snippet on **EVERY quote-anchored ref, whatever its
-   `status`** (v0.34.6). It used to check only `exists|conflict` — but the two
-   statuses a GOOD audit most often produces are `resolved` (a challenged row
-   the user decided) and `buildable` (the actual work), so a correctly-triaged
-   analysis was the one the gate barely checked: a real spec had zero
-   `exists|conflict` rows, so the mandated verification covered 0 of 5 refs and
-   a `file:5` citing a quote that lives at `file:4` went through. It is one
-   Grep per ref, and it is the ONLY mechanical defence against a wrong line
-   number reaching the planner. Note the causal shape: that ref started as a
-   line RANGE with no quote (auto-UNVERIFIED per hard rule 2); narrowing it to
-   one line + quote was the CORRECT fix and is what introduced the off-by-one —
-   tightening evidence granularity is itself an error surface, so the gate has
-   to be what catches it.
-2. **Derivation lint:** R# ids, statuses, and context-anchor set must match
-   between report.md and requirement-spec.md.
-
-Any miss → bounce to the analyst with the miss list (one retry, then escalate
-to the user). Refuse take-into-build when the spec has open `UNVERIFIED` or
-lacks `scope_closed: true` (a one-Grep check).
-
-## Combiner tracking (yours; full lane only)
-
-`context-combiner` (`orc-context-combiner-opus-5-high` — Opus 5 high, v0.34.0)
-merges 2+ RELATED, already-confirmed
-analyses from the same run into ONE combined requirement-spec before build.
-
-- **Track the analysis set:** hold the confirmed spec paths of every analysis
-  this run in run state (survives checkpoint/resume).
-- When the user picks "pass to context-combiner" at orc-analyze's Phase F
-  branch menu (offered only once 2+ analyses exist), dispatch
-  `orc-context-combiner-opus-5-high` with that list.
-- The return carries `combined_spec_path` + `coverage_pct` (conservation
-  proof — every source requirement accounted for; must be 100) + `dropped[]` +
-  `stale_evidence[]` + `handoff_ready` — or `combined: false` if the user chose
-  keep-separate at the combiner's relatedness challenge (then fall back to
-  per-analysis stop/build).
-- Offer the build option ONLY when `handoff_ready` is true (the combiner sets
-  it false when `coverage_pct` < 100 OR a conflict is open). On build, continue
-  at Phase 1 with the combined spec exactly like a single requirement-spec.
-
-You never combine; you only track, dispatch, and relay.
-
-## Spec staleness valve (Phase 1, before dispatching the planner)
-
-If the requirement-spec's `git_head` ≠ current HEAD (analysis and build in
-different sessions), re-run the analyst evidence spot-check (paths + quotes)
-BEFORE dispatching the planner; on misses offer re-analyze vs
-proceed-with-flagged.
-
-## Phase 1 exit gate (deterministic, before scoring)
-
-1. **Grounding spot-check:** Glob every path the plan marks
-   `disposition: exists`. A task whose declared paths lack `grounding[]`
-   entries counts as a miss.
-2. **Coverage check:** recompute the planner's coverage echo — every in-scope
-   spec R# / intent-spec DoD line must appear in ≥ 1 task's `requirements[]`;
-   an `orphan` requirement is a miss (the user may explicitly descope instead).
-3. **Graph checks:** cycle detection over `depends_on` + same-file collision
-   over `declared_files` (two tasks sharing a file need a serializing dep or a
-   merge). Both trivial at ≤ 20 tasks — never trust the planner's self-check
-   alone.
-4. **TDD/test-task collision (v0.34.4):** a `tdd_spec` entry whose target file
-   is in the `declared_files` of a task whose `facets.test_surface` is
-   `new-tests` is a miss. The paired TDD task materializes `tdd_spec` BEFORE the
-   task it guards, so that task's planned work is already on disk and
-   green by the time its wave opens — leaving only bad options (dispatch a
-   no-op, silently drop promised coverage, or re-slice mid-run). The planner
-   authored both mechanisms and folds them together itself: extend the
-   materialized file, never re-author it.
-5. **TDD disposition gate (v0.41.0)** — this gate is what lets TDD be skipped
-   safely. Skipping a test is cheap to claim and expensive to get wrong, so
-   every skip must be checkable, and it is checked in BOTH directions: a rule
-   that only ever prevents tests is a rule that deletes coverage.
-   - `disposition` outside the closed set
-     `new-surface | behavior-change | covered-by-existing | no-behavior | no-runner`
-     → miss. (Absent on a pre-v0.41.0 plan → derive from `kind`; never bounce an
-     old plan — see the legacy exception below.)
-   - `covered-by-existing` **without a resolvable `covered_by`** → miss. Glob the
-     cited `path` exactly as check 1 does for `disposition: exists`. "A test
-     already covers this" is the one claim that, if false, silently removes
-     coverage the run promised.
-   - `no-behavior` whose task has `facets.test_surface != none` → miss
-     (self-contradiction: the planner said the surface is testable and that it
-     isn't).
-   - **Safety floor:** any entry that is `covered-by-existing` or `no-behavior`
-     on a task with non-empty `facets.risk[]` → miss, no exceptions. Auth,
-     money, migration, security, concurrency and data-integrity requirements do
-     not ride on another test's coincidence.
-   - `new-surface` / `behavior-change` missing `skeleton` or `given_when_then`
-     → miss.
-   - A disposition that DEVIATES from the derivation table in
-     `../../orc/schemas/planning-output.md` without a `reason` → miss. The derivation
-     is the default; departing from it is the thing that needs justifying.
-
-Any miss → the plan is malformed: bounce it back to the planner WITH the miss
-list (one retry), then escalate to the user. **Legacy exception:** a
-pre-v0.7.0 plan resumed from an old checkpoint has no `grounding[]`
-(pre-v0.9.0: no `requirements[]`/`spec_invariants[]`; pre-v0.41.0: no
-`disposition`) — resume it without the
-missing checks; never bounce an old plan.
-
-<!-- /orc:layer -->
+# Phase — Analyst & plan gates   (id: `analyst-gates`)
+
+> **Library file.** Canonical since v1.0.0 W12; it was under the `orc` skill's
+> private `references/`, and other lanes already reached across into it. Read
+> by `orc`, `orc-analyze`, `orc-mini`. Layers declared: `core` only — single-
+> layer because these are the orchestrator-side gates on a returned analysis
+> or plan, and a trimmed lane runs fewer of them rather than different ones.
+> `orc lane phases <lane> --json` names the file and the layers to read.
+
+<!-- orc:layer core -->
+## Reference — Analyst, Combiner & Plan Gates (orchestrator side)
+
+The orchestrator's deterministic gates around the analyst, the
+context-combiner, and the planner. The roles themselves are defined in
+`../../orc-analyze/SKILL.md`, `../../context-combiner/SKILL.md`, and
+`../../orc/subskills/orc-planner/SKILL.md` — this file is what YOU do around their
+dispatches and returns. Load at Phase 0 (analyst dispatch) and Phase 1
+(planner return). Emit a `GATE` trace line (pass|bounce) per check when
+logging.
+
+## Deep-mode scout dispatch (yours)
+
+When the analyst runs in deep mode it returns a `scout_plan` (pass 1). You then
+dispatch ≤ `config.max_scouts` (default 3) parallel
+`orc-scout-sonnet-4-6-high` agents (`orc-scout-opus-5-low` when `opus5_only`
+— `../../_shared/opus5-only.md`; scouts fan out in PARALLEL, so this is the
+mode's largest single cost multiplier) — one coverage area each, read-only — and
+re-dispatch the analyst WITH their evidence bundles for pass 2. Same "return a
+request → you re-slice → re-dispatch" shape as `needs_context`. You never
+analyze; you only dispatch and relay.
+
+## Analyst-return gates (deterministic, before any build option)
+
+1. **Evidence spot-check:** Glob every `files[]` path in the spec +
+   Grep-verify the quoted snippet on **EVERY quote-anchored ref, whatever its
+   `status`** (v0.34.6). It used to check only `exists|conflict` — but the two
+   statuses a GOOD audit most often produces are `resolved` (a challenged row
+   the user decided) and `buildable` (the actual work), so a correctly-triaged
+   analysis was the one the gate barely checked: a real spec had zero
+   `exists|conflict` rows, so the mandated verification covered 0 of 5 refs and
+   a `file:5` citing a quote that lives at `file:4` went through. It is one
+   Grep per ref, and it is the ONLY mechanical defence against a wrong line
+   number reaching the planner. Note the causal shape: that ref started as a
+   line RANGE with no quote (auto-UNVERIFIED per hard rule 2); narrowing it to
+   one line + quote was the CORRECT fix and is what introduced the off-by-one —
+   tightening evidence granularity is itself an error surface, so the gate has
+   to be what catches it.
+2. **Derivation lint:** R# ids, statuses, and context-anchor set must match
+   between report.md and requirement-spec.md.
+
+Any miss → bounce to the analyst with the miss list (one retry, then escalate
+to the user). Refuse take-into-build when the spec has open `UNVERIFIED` or
+lacks `scope_closed: true` (a one-Grep check).
+
+## Combiner tracking (yours; full lane only)
+
+`context-combiner` (`orc-context-combiner-opus-5-high` — Opus 5.5 high, v0.34.0)
+merges 2+ RELATED, already-confirmed
+analyses from the same run into ONE combined requirement-spec before build.
+
+- **Track the analysis set:** hold the confirmed spec paths of every analysis
+  this run in run state (survives checkpoint/resume).
+- When the user picks "pass to context-combiner" at orc-analyze's Phase F
+  branch menu (offered only once 2+ analyses exist), dispatch
+  `orc-context-combiner-opus-5-high` with that list.
+- The return carries `combined_spec_path` + `coverage_pct` (conservation
+  proof — every source requirement accounted for; must be 100) + `dropped[]` +
+  `stale_evidence[]` + `handoff_ready` — or `combined: false` if the user chose
+  keep-separate at the combiner's relatedness challenge (then fall back to
+  per-analysis stop/build).
+- Offer the build option ONLY when `handoff_ready` is true (the combiner sets
+  it false when `coverage_pct` < 100 OR a conflict is open). On build, continue
+  at Phase 1 with the combined spec exactly like a single requirement-spec.
+
+You never combine; you only track, dispatch, and relay.
+
+## Spec staleness valve (Phase 1, before dispatching the planner)
+
+If the requirement-spec's `git_head` ≠ current HEAD (analysis and build in
+different sessions), re-run the analyst evidence spot-check (paths + quotes)
+BEFORE dispatching the planner; on misses offer re-analyze vs
+proceed-with-flagged.
+
+## Phase 1 exit gate (deterministic, before scoring)
+
+1. **Grounding spot-check:** Glob every path the plan marks
+   `disposition: exists`. A task whose declared paths lack `grounding[]`
+   entries counts as a miss.
+2. **Coverage check:** recompute the planner's coverage echo — every in-scope
+   spec R# / intent-spec DoD line must appear in ≥ 1 task's `requirements[]`;
+   an `orphan` requirement is a miss (the user may explicitly descope instead).
+3. **Graph checks:** cycle detection over `depends_on` + same-file collision
+   over `declared_files` (two tasks sharing a file need a serializing dep or a
+   merge). Both trivial at ≤ 20 tasks — never trust the planner's self-check
+   alone.
+4. **TDD/test-task collision (v0.34.4):** a `tdd_spec` entry whose target file
+   is in the `declared_files` of a task whose `facets.test_surface` is
+   `new-tests` is a miss. The paired TDD task materializes `tdd_spec` BEFORE the
+   task it guards, so that task's planned work is already on disk and
+   green by the time its wave opens — leaving only bad options (dispatch a
+   no-op, silently drop promised coverage, or re-slice mid-run). The planner
+   authored both mechanisms and folds them together itself: extend the
+   materialized file, never re-author it.
+5. **TDD disposition gate (v0.41.0)** — this gate is what lets TDD be skipped
+   safely. Skipping a test is cheap to claim and expensive to get wrong, so
+   every skip must be checkable, and it is checked in BOTH directions: a rule
+   that only ever prevents tests is a rule that deletes coverage.
+   - `disposition` outside the closed set
+     `new-surface | behavior-change | covered-by-existing | no-behavior | no-runner`
+     → miss. (Absent on a pre-v0.41.0 plan → derive from `kind`; never bounce an
+     old plan — see the legacy exception below.)
+   - `covered-by-existing` **without a resolvable `covered_by`** → miss. Glob the
+     cited `path` exactly as check 1 does for `disposition: exists`. "A test
+     already covers this" is the one claim that, if false, silently removes
+     coverage the run promised.
+   - `no-behavior` whose task has `facets.test_surface != none` → miss
+     (self-contradiction: the planner said the surface is testable and that it
+     isn't).
+   - **Safety floor:** any entry that is `covered-by-existing` or `no-behavior`
+     on a task with non-empty `facets.risk[]` → miss, no exceptions. Auth,
+     money, migration, security, concurrency and data-integrity requirements do
+     not ride on another test's coincidence.
+   - `new-surface` / `behavior-change` missing `skeleton` or `given_when_then`
+     → miss.
+   - A disposition that DEVIATES from the derivation table in
+     `../../orc/schemas/planning-output.md` without a `reason` → miss. The derivation
+     is the default; departing from it is the thing that needs justifying.
+
+Any miss → the plan is malformed: bounce it back to the planner WITH the miss
+list (one retry), then escalate to the user. **Legacy exception:** a
+pre-v0.7.0 plan resumed from an old checkpoint has no `grounding[]`
+(pre-v0.9.0: no `requirements[]`/`spec_invariants[]`; pre-v0.41.0: no
+`disposition`) — resume it without the
+missing checks; never bounce an old plan.
+
+<!-- /orc:layer -->

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

@@ -37,7 +37,7 @@ the codifier); hold resolved patterns in run state.
 1. Dispatch EVERY task as a spawned subagent (emit `DISPATCH <agent> :: <task>
    expect=<model>/<effort>` BEFORE the Task call; subagent wrapper framing + the
    task's INPUT SLICE per orc-execution/core.md + its scored model). Every
-   slice carries ONE `orc graph ctx --for-slice <the task's declared_files> --if-enabled --json`
+   slice carries ONE `orc graph ctx --for-slice <the task's declared_files> --if-enabled --json --brief`
    `card` as its `graph` block (`../code-graph.md` §7; exit 3 = off → no block) —
    the OUTSIDE view only, because the executor reads each declared file in full
    itself,
@@ -78,7 +78,7 @@ the codifier); hold resolved patterns in run state.
 4. **Post-wave worktree audit (GATE, `_shared/return-validation.md` §6):** diff `git status --short` before/after the wave — a changed path in NO task's `declared_files`, INCLUDING one that became less modified (the revert signature), blocks the close until named and decided.
    Overlap → `failure_reason: "file-collision:<file> with <agent>"`, requeue later wave.
 4a. **Code graph (`../code-graph.md` §5–§6):** after the audit, ONE call —
-   `orc graph update --notes-pending --files <the wave's changed paths> --at wave --if-enabled --json`
+   `orc graph update --notes-pending --files <the wave's changed paths> --at wave --if-enabled --json --brief`
    (emit `GRAPH-UPDATE`; the answer's `notes_pending` is the notes half):
    `notes_pending.exit` 0 → dispatch `orc-graph-noter-sonnet-4-6-med` (slice = paths only) in the
    SAME tool block as the next wave's first dispatch; 3 or 5 → nothing, the
@@ -146,9 +146,9 @@ outside `declared_files` (a revert included) gates the wave close.
 
 <!-- diy:when code_graph=on -->
 Code graph cache (never skipped): each slice gets ONE `orc graph ctx --for-slice <the task's
-declared_files> --if-enabled --json` `card` as its `graph` block, and the return
+declared_files> --if-enabled --json --brief` `card` as its `graph` block, and the return
 carries `graph_used`. After each wave's worktree audit run ONE call —
-`orc graph update --notes-pending --files <the wave's changed paths> --at wave --if-enabled --json`
+`orc graph update --notes-pending --files <the wave's changed paths> --at wave --if-enabled --json --brief`
 (copy its `trace` verbatim); `notes_pending.exit` 0 → dispatch `orc-graph-noter-sonnet-4-6-med` paired
 with the next wave's first dispatch, exit 3 or 5 → nothing. Canonical:
 `.claude/skills/_shared/code-graph.md`.

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

@@ -31,16 +31,16 @@ only pre-built needs/cache, never peer source live). **Gotchas (repair memory,
 config `gotchas`):** probe ONCE with `orc gotcha status` (exit 0 = entries exist,
 1 = none — never a `find`); canonical `_shared/gotchas.md`.
 **Code graph (`../code-graph.md` §3b and §7):** with the graph on, run
-`orc graph map --focus <every file or symbol the request NAMES> --if-enabled --json`
+`orc graph map --focus <every file or symbol the request NAMES> --if-enabled --json --brief`
 **FIRST, once** — before any Glob and before `impact`. It ranks the repository
 around the request and names the files worth reading, which is the question
 `impact` cannot answer because `impact` needs the files already chosen. Print its
 `line` and emit `GRAPH-MAP`. Rank is a HINT about where to look first, never
 proof a file matters — and never a reason to skip reading a range you will edit.
 Exit 1 or 3 → orient exactly as before. Then run
-`orc graph impact <candidate declared_files> --if-enabled --json` and hand its
+`orc graph impact <candidate declared_files> --if-enabled --json --brief` and hand its
 callers to the planner — they sharpen `declared_files` and the `fan` and risk
-facets. Also run `orc graph cochange <each candidate file> --if-enabled --json`:
+facets. Also run `orc graph cochange <each candidate file> --if-enabled --json --brief`:
 it answers "what else will I have to touch" from HISTORY, which a static edge
 cannot see. Co-change is a HINT about people, never a dependency — exit 4 means
 this file changes alone, which is an answer. Exit 3 or 4 → plan exactly as before.

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

@@ -100,7 +100,7 @@ that the line is printed and when.
 ## The graph line (v1.8.0) — code-changing lanes only
 
 `/orc`, `/orc-ultra`, `/orc-diy`, `/orc-mini`, `/orc-fast` and `/orc-quick` run
-`orc graph status --if-enabled --heal --json` in step 3, BEFORE the first
+`orc graph status --if-enabled --heal --json --brief` in step 3, BEFORE the first
 dispatch — never skipped. `--heal` builds a missing graph and updates a drifted
 one in the same call (it is free), so there is no second call to forget. Print
 its `line` (`off` included) and put its `trace` (`GRAPH-CONSULT …`) in the next

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

@@ -17,13 +17,15 @@
 ## Review (load ../../orc/subskills/orc-review-verify/, spawned)
 
 Emit `PHASE review start`. Superpowers path: its review skill incl. tests
-(Sonnet 4.6 medium). OpenSpec/self path: review worker (Opus 5 medium). Pass the resolved
+(Sonnet 4.6 medium). OpenSpec/self path: review worker (Opus 5.5 medium). Pass the resolved
 `code_pattern` + its invariants + gate lines for the re-check
 (pattern-gate.md); no resolved pattern → FIRST ask for one (paste/md/none).
 FE tasks in run → pass `fe_rules[]` from `../../orc-pattern/references/` fe-a11y
 + fe-perf. **Code graph (`../code-graph.md` §7):** with the graph on, also pass
 `orc graph changes --if-enabled --json` — the symbols THIS diff's hunks overlap,
-each with its callers, its tests and a risk word that carries its own reason. It
+each with its callers, its tests and a risk word that carries its own reason.
+**This one read keeps its rows: no `--brief` here**, because the reviewer is
+handed `symbols[].caller_files` and reads them. It
 replaces a whole-file `orc graph impact` here: a file card reports every symbol in
 a touched file, and a symbol nobody edited is not a finding. An unchanged caller of
 a changed signature is a finding candidate, anchored like any other. Findings arrive on the **P0–P3 ladder** (invariant violation or

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

@@ -54,7 +54,7 @@ subagent). The user must always know what the run cost. **Code graph
 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
 dispatch, exit 3 or 5 → nothing. Then ONE line, once, copied VERBATIM from
-`orc graph gain --run <this run's trace name> --if-enabled --json` (emit
+`orc graph gain --run <this run's trace name> --if-enabled --json --brief` (emit
 `GRAPH-GAIN`): what the graph put in, and an ESTIMATE of the retrieval it kept
 out. Exit 1 or 3 → no line. **Never restate it as one number** — the range and
 the word "estimate" are the claim. Finally emit

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

@@ -231,10 +231,11 @@ supplies the fact in a packet, the writer writes the line. `SPAWN`, `RETURN` and
 | `CONFIG <key=value …>` | orc → writer | Phase 1 — the resolved config values this run will consume (ALWAYS `opus5_only` — it selects the executor table AND every fixed role, so retro can segment outcomes by dispatch mode). Runtime proof that the run honored the config; `/orc-retro` audits it against behavior |
 | `WIKI-CONSULT <tier> :: docs=<list>` | orc → writer | project wiki consulted for grounding (full/mini at planning; fast at slice-build) — tier ∈ `fresh` \| `aging` \| `stale` \| `absent` \| `empty`; `docs=` the pages pulled/handed to the executor (comma list) or `none`. Records whether the run grounded in the wiki and whether it was stale (surfaces grounding + staleness for later audit) |
 | `CROSSLINK <state> :: boundaries=<n> peers=<names>` | orc → writer | cross-repo peer-knowledge state at the consult point — state ∈ `cached` (peer cache present) \| `configured-no-cache` (crosslink configured but the cache is not built) \| `none`. Per-task `CROSSLINK inject task=<id> :: <boundary>` when a slice receives a linked contract. Records whether peer contracts were injected this run (full orc consumes only the pre-built crosslink cache — it never reads peer source live; mechanism in `wiki-consult.md`) |
-| `GRAPH-CONSULT <state> :: files=<n> symbols=<n>` | orc → writer | the code graph's preflight state (`code-graph.md` §4) — state ∈ `fresh` \| `updated` \| `built` \| `drifted` \| `none` \| `off`. Copied VERBATIM from the `trace` field of `orc graph status --heal --json`; a `GATE` line that describes the graph in other words does not replace it. Plus `GRAPH-CONSULT card task=<id> :: targets=<…>` (the `trace` of `orc graph ctx --json`, with `task=` added) when a slice receives cards |
+| `GRAPH-CONSULT <state> :: files=<n> symbols=<n>[ density=<n>[ thin=1]]` | orc → writer | the code graph's preflight state (`code-graph.md` §4) — state ∈ `fresh` \| `updated` \| `built` \| `drifted` \| `none` \| `off`. Copied VERBATIM from the `trace` field of `orc graph status --heal --json --brief`; `density=` is the named symbols per file and `thin=1` means most files hold none, so most questions asked of the graph will not find one (v1.9.1); a `GATE` line that describes the graph in other words does not replace it. Plus `GRAPH-CONSULT card task=<id> :: targets=<…>` (the `trace` of `orc graph ctx --json`, with `task=` added) when a slice receives cards |
 | `GRAPH-UPDATE <state> :: parsed=<n> reused=<n> deleted=<n> gen=<n> route=<n> ms=<n>` | orc → writer | one graph update at a wave close, a green smoke gate, a code-writing `/orc-quick` request, or ship — the `trace` field of `orc graph update --json`, verbatim. The graph HOOK writes its own `GRAPH-UPDATE … :: by=hook …` lines directly; never copy one of those, it is already in the file |
 | `GRAPH-MAP <repo|focused> :: files=<shown>/<total> [focus=<a,b>] gen=<n>` | orc → writer | ONE line at the START of planning (and at a `/orc-quick` Q1 look that had no file to name) — the `trace` field of `orc graph map --json`, verbatim. `files=` is how many the budget SHOWED over how many the repository has, so a short map can be told from a small repository. `focused` means `--focus` re-ranked the repository around what the request named. RANK is a hint about where to look first and the trace never says more than that |
 | `GRAPH-CHANGES <found\|none> :: symbols=<n> high=<n> medium=<n> low=<n> gen=<n>` | orc → writer | one line at review — the `trace` field of `orc graph changes --json`, verbatim. `high` counts symbols that are exported, have three or more callers and NO test reaching them |
+| `GRAPH-COMPLEXITY <mini-ok\|recommend-orc> :: files=<n> callers=<n> caller_files=<n> maybe=<n> tests=<n> risk=<n> cochange=<n> gen=<n>` | orc → writer | one line per `/orc-mini` run — the `trace` field of `orc graph impact … --complexity --json`, verbatim. The CLI computes the verdict from the four thresholds in `bin/graph-signals.js`; `maybe` is reported and never trips one. Mini's own `GATE complexity :: <the line>` is separate: it records what the USER chose after the offer |
 | `GRAPH-COCHANGE <found\|none> :: rows=<n> commits=<n>` | orc → writer | one line per planning batch, not per file — the `trace` field of `orc graph cochange --json` for the file that produced the widest answer |
 | `GRAPH-HINT injected=<n> subagent_start=<n> read_notes=<n> updates=<n>` | orc → writer | ONE line per phase close, not one per hint — the counters `orc-graph-hook.js` keeps in `<log_dir>/<run>.graph-hook.json`. Omitted when the file does not exist (the hook is off, or it never had anything to say) |
 | `GRAPH-GAIN paid=<n> low=<n> high=<n> calls=<n>` | orc → writer | ONE line per run, at ship — the `trace` field of `orc graph gain --run <trace name> --json`, verbatim. `paid` is exact (the tokens the graph put in); `low`/`high` are an ESTIMATE of the retrieval it kept out, and they are never collapsed into one number. Omitted when the ledger is empty or the graph is off |
@@ -313,7 +314,7 @@ For each spawn the orchestrator:
 ## Announce-on-spawn
 
 When dispatching, announce the model to the user, derived from the agent NAME
-(e.g. "Spawning orc-executor-opus-5-low → claude-opus-5 / low"). Derive it
+(e.g. "Spawning orc-executor-opus-5-low → claude-opus-5-5 / low"). Derive it
 from the name — do NOT pass the coarse `sonnet|opus|haiku` dispatch arg, which
 cannot express 4-7 vs 4-8 and would override the frontmatter pin.
 

package/templates/skills/_shared/read-ladder.md

@@ -26,7 +26,7 @@ Escalate one step at a time. Stop at the step that answers the question.
 
 ## Step 0 — ask the graph (always first; the CLI decides if it is on)
 
-Before step 1, run `orc graph ctx <symbol|file[:line]> --if-enabled --json`
+Before step 1, run `orc graph ctx <symbol|file[:line]> --if-enabled --json --brief`
 yourself. You do not need to know whether the graph is on. Exit 0 → the card
 answers step 1 and step 2 together: where the symbol is, its line range, who
 calls or uses it, what it calls, and which effects it has. Then continue at
@@ -40,6 +40,19 @@ footer says how many lines it cut. Use it for the CALLER'S range, the callee's,
 the neighbour you will not touch. **It never replaces exception 1**: a file you
 will EDIT is read IN FULL with `Read` first, because an `old_string` rebuilt
 from a printed range is the same corruption bug as one rebuilt from an outline.
+**`--callers-source` adds six lines around each confident call site (≤ 5)**
+(v1.9.1), charged against the same `--budget` after everything else. A file you
+will EDIT is still read in full with `Read` first — this is for the callers you
+will not touch.
+
+**Ask a language server when the card cannot be exact** (v1.9.1). If the card
+answers `AMBIGUOUS (n)` for a callee, or `← maybe <n>` for callers, and an `LSP`
+tool is available in this session, run `LSP findReferences` (callers) or
+`goToDefinition` (a callee) at the card's `lsp_at` — file, line, character —
+before any Grep. A language server's answer is EXACT; the card's `AMBIGUOUS` is a
+list of candidates. Without an LSP tool, or with `lsp_at: null`, the ladder
+continues as before.
+
 Exit 3 (off) → skip step 0 for the rest of the task. Exit 1 (no index) or 4 (not
 in the graph) → step 1 as before. Name the card targets you used in
 `graph_used`. Both exceptions below apply unchanged.

package/templates/skills/_shared/return-validation.md

@@ -16,7 +16,7 @@ agent. It does not.
 
 What that costs, measured: one graded `/orc-quick` entry put THREE
 `orc-executor-opus-5-low` agents on the SAME task — 50m19s, 115m22s and
-100m53s, **266 minutes of Opus 5 for one authorised dispatch**, all editing the
+100m53s, **266 minutes of Opus 5.5 for one authorised dispatch**, all editing the
 same files, inside a 2h04m window. The second was dispatched 4m19s after the
 first, while the first was still working. The hook had recorded all three; no
 lane had ever read that record.

package/templates/skills/context-combiner/SKILL.md

@@ -31,7 +31,7 @@ it were a single analysis — with PROOF that no source requirement was lost.
 ## Hard rules
 
 1. **Dispatched, not self-run.** The orchestrator coordinates; the Combiner
-   subagent (Opus 5 high) reads the specs and reconciles them against each
+   subagent (Opus 5.5 high) reads the specs and reconciles them against each
    other. The combiner NEVER builds and NEVER spawns subagents.
 2. **Related only — verify + challenge.** The user asserted relatedness at the
    Phase F gate, but the combiner MUST verify real overlap (shared files,