@azure-id/orc 1.9.2 → 2.0.2

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

@@ -1,70 +1,62 @@
-# Phase — Verify — TDD gate + adversarial review   (id: `verify`)
-
-> **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 -->
-
-## Verify: TDD gate + adversarial review (same subskill, phase=verify)
-
-Emit `PHASE verify start`. TWO halves in the SAME dispatched verifier slot
-(../../orc/subskills/orc-review-verify/ — Phase 5's reviewer stays separate):
-**1) TDD gate (deterministic):** run the plan's TDD suite — green IS the
-definition-of-done for non-exempt requirements; red → repair loop (implement→
-test→repair, cap `tdd_loop_max`; cap hit → STOP SEQUENCE + honest red report).
-**2) Adversarial review:** attack the green implementation — edge cases the
-spec missed, error paths, contract violations, race/ordering, workflow breaks
-(dead wiring, broken commands) — findings on the existing P0–P3 ladder. The
-verifier also checks the intent-spec's
-definition-of-done PLUS the pattern's `validation_gate[]` lines (each a
-criterion; unmet = P0). The return carries `criteria[]` {criterion, pass|fail,
-evidence} — every criterion needs evidence. Quote spot-check P0/P1 first, then:
-P0 → auto-fix once → re-verify once → second failure STOPS; P1 → ask before the
-one fix attempt, then re-verify (same single-retry cap).
-**Pact recheck (`pact_recheck_on_verify`, default true; emit `PACT recheck`):**
-after GREEN, run `orc pact check` scoped to the promises whose anchors intersect
-this run's CHANGED files. A promise that flips to BROKEN is a **P1 finding with its
-check output** — reported, never an automatic abort: the ledger may simply have
-outgrown the code, and that is the user's call. Emit
-`VERDICT pass|fail :: <detail>`, then `PHASE verify end`.
-
-<!-- /orc:layer -->
-
-<!-- orc:layer composed -->
-
-## Phase: Verify
-
-<!-- diy:when verify=off -->
-Verification is DISABLED in this flow. The build+test evidence in each
-executor return is the only green signal; say "verify skipped by flow
-config" in the summary. Never claim criteria were verified.
-<!-- /diy:when -->
-<!-- diy:when verify=smoke -->
-Run a SMOKE verify only: dispatch the verifier
-(`orc-verifier-opus-5-med`) with an explicitly narrowed scope — build +
-full test suite, red/green verdict, NO per-criterion definition-of-done
-sweep. Red blocks ship exactly as a full verify would.
-<!-- /diy:when -->
-<!-- diy:when verify=full -->
-Dispatch verification exactly as the full lane does — follow the verify half
-of `.claude/skills/orc/subskills/orc-review-verify/SKILL.md` (build + tests +
-every acceptance criterion checked against the definition of done).
-<!-- /diy:when -->
-<!-- diy:when tdd=on -->
-TDD gate (rides the verify slot): the verifier slice carries the plan's
-`tdd_suite[]`; green is the definition-of-done for non-exempt requirements,
-red → the repair loop capped at `tdd_loop_max` (cap hit → STOP + honest red
-report). The adversarial half of the verify pass applies as the full lane
-defines it.
-<!-- /diy:when -->
-
-<!-- /orc:layer -->
+# Phase — Verify — TDD gate + adversarial review   (id: `verify`)
+
+> **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 -->
+
+## Verify: TDD gate + adversarial review (same subskill, phase=verify)
+
+Emit `PHASE verify start`. TWO halves in the SAME dispatched verifier slot
+(../../orc/subskills/orc-review-verify/ — Phase 5's reviewer stays separate):
+**1) TDD gate (deterministic):** run the plan's TDD suite — green IS the
+definition-of-done for non-exempt requirements; red → the flaky check
+(`../smoke-gate.md` §Flaky: exit 0 = not red, no round), then the repair loop (implement→
+test→repair, cap `tdd_loop_max`; cap hit → STOP SEQUENCE + honest red report).
+**2) Adversarial review:** attack the green implementation — edge cases the
+spec missed, error paths, contract violations, race/ordering, workflow breaks
+(dead wiring, broken commands) — findings on the existing P0–P3 ladder. The
+verifier also checks the intent-spec's
+definition-of-done PLUS the pattern's `validation_gate[]` lines (each a
+criterion; unmet = P0). The return carries `criteria[]` {criterion, pass|fail,
+evidence} — every criterion needs evidence. Quote spot-check P0/P1 first, then:
+P0 → auto-fix once → re-verify once → second failure STOPS; P1 → ask before the
+one fix attempt, then re-verify (same single-retry cap).
+**Pact recheck (`pact_recheck_on_verify`, default true; emit `PACT recheck`):**
+after GREEN, run `orc pact check` scoped to the promises whose anchors intersect
+this run's CHANGED files. A promise that flips to BROKEN is a **P1 finding with its
+check output** — reported, never an automatic abort: the ledger may simply have
+outgrown the code, and that is the user's call. Emit
+`VERDICT pass|fail :: <detail>`, then `PHASE verify end`.
+
+<!-- /orc:layer -->
+
+<!-- orc:layer composed -->
+
+## Phase: Verify
+
+<!-- diy:when verify=off -->
+Verification is DISABLED in this flow. The build+test evidence in each
+executor return is the only green signal; say "verify skipped by flow
+config" in the summary. Never claim criteria were verified.
+<!-- /diy:when -->
+<!-- diy:when verify=smoke -->
+Run a SMOKE verify only: dispatch the verifier
+(`orc-verifier-opus-5-med`) with an explicitly narrowed scope — build +
+full test suite, red/green verdict, NO per-criterion definition-of-done
+sweep. Red blocks ship exactly as a full verify would.
+<!-- /diy:when -->
+<!-- diy:when verify=full -->
+Dispatch verification exactly as the full lane does — follow the verify half
+of `.claude/skills/orc/subskills/orc-review-verify/SKILL.md` (build + tests +
+every acceptance criterion checked against the definition of done).
+<!-- /diy:when -->
+<!-- diy:when tdd=on -->
+TDD gate (rides the verify slot): the verifier slice carries the plan's
+`tdd_suite[]`; green is the definition-of-done for non-exempt requirements,
+red → the flaky check
+(`.claude/skills/_shared/smoke-gate.md` §Flaky), then the repair loop capped at `tdd_loop_max` (cap hit → STOP + honest red
+report). The adversarial half of the verify pass applies as the full lane
+defines it.
+<!-- /diy:when -->
+
+<!-- /orc:layer -->

package/templates/skills/_shared/phases/wave-grouping.md

@@ -1,133 +1,128 @@
-# Phase — Wave grouping   (id: `wave-grouping`)
-
-> **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 the
-> conflict graph is arithmetic, and a lane that groups waves at all groups
-> them this way. `orc lane phases <lane> --json` names the file and the layers
-> to read.
-
-<!-- orc:layer core -->
-## Reference — Wave Grouping & Conflict Graph
-
-Turn the tagged task list into conflict-free waves. Load during Phase 3.
-
-## Waves are computed for EVERY run — dispatch style is intra-wave only
-
-Wave computation is NOT a parallel-mode concern. It runs for **every run with ≥2
-tasks, sequential included** (dependency layers + conflict graph +
-`max_wave_tasks` cap). **Dispatch style controls only INTRA-WAVE concurrency:**
-
-- **parallel** → a wave's non-conflicting tasks dispatch at once (up to
-  `max_wave_tasks`);
-- **sequential** → the SAME waves, but a wave's tasks dispatch one at a time, in
-  order; the wave still closes only when all its tasks close.
-
-Either way the **wave-boundary gate fires identically** (the deterministic batch
-pause below binds to wave numbers, not to a dispatch style). A sequential run
-therefore never degenerates to "no waves / per-task pauses" — a 5-task plan
-becomes e.g. `[T1] [T2 T3 T4] [T5]`, not five ad-hoc stops. **Show the wave plan
-(wave → tasks → pause marks) to the user BEFORE wave 1 in BOTH styles.**
-
-## The principle
-
-Two tasks may share a wave ONLY if their `declared_files` don't overlap AND
-neither depends on the other. Conflicts are designed out by scheduling — never
-negotiated at runtime.
-
-## Algorithm
-
-1. **Dependency edges:** a task's earliest wave = max(wave of its deps) + 1.
-2. **Conflict edges:** for every pair, mark conflict if `declared_files` globs
-   intersect (expand against the repo tree; unresolvable globs conflict on
-   their literal prefix).
-3. **Assign greedily in topological order:** place each task in the earliest
-   wave where (a) all deps are earlier and (b) nothing in that wave conflicts.
-   Otherwise open a new wave.
-4. **Cap concurrency at `config.max_wave_tasks`** (default 3): a wave NEVER
-   exceeds this many tasks, even if more are conflict-free. Overflow moves to the
-   next wave. This is the efficiency cap — 3 parallel subagents by default.
-5. **Mark batch pauses:** compute the pause schedule from the user's Phase 2
-   answer — mark `is_batch_pause: true` on wave W when `W % N == 0` AND a later
-   wave exists (`W < total_waves`); the last wave is NEVER a pause (nothing
-   remains to gate). The resulting wave indices are the `pause_schedule` stored
-   in the checkpoint. A pause so marked is a HARD gate (stop-resume.md), not
-   an orchestrator judgment call.
-
-## Same-feature collision
-
-If two tasks own the same feature/files with no dependency between them, the
-graph auto-serializes them — but that's a planning smell. Surface it: suggest
-merging them into one task rather than silently serializing duplicate work.
-
-## TDD tasks are ORDINARY tasks (v0.41.0)
-
-TDD red proofs are **planner-emitted tasks**, not an orchestrator-synthesized
-Wave 0. Each one materializes the `tdd_spec` entries of the implementation task
-it guards, and that task lists it in `depends_on`. Nothing here special-cases
-them:
-
-- they enter the same conflict graph via their `declared_files` (their test
-  files), so **independent TDD tasks share a wave and run in parallel** — the
-  red proofs for two unrelated features are one wave, not two;
-- `depends_on` guarantees **a red proof is always in an earlier wave than the
-  code it proves** — a proof can never land beside its implementation;
-- they are scored from **their own planner-emitted `facets`**, like any task, so
-  no derived-vector rule is needed;
-- `max_wave_tasks`, `is_batch_pause` and `pause_schedule` bind to them unchanged.
-
-**A TDD task does NOT inherit the risk floor** of the task it guards: it
-transcribes planner-authored skeletons, writes no production code, and its output
-is asserted RED before anything is believed. The planner reflects that in the
-task's own facets (`novelty: mechanical`, `logic: none`, `risk: []`). Stated here
-so it is not re-litigated per run — the alternative is a Haiku-sized
-transcription job dispatched at floor 70 because the requirement it proves is
-auth-flavoured.
-
-**If no task carries `new-surface` or `behavior-change` entries, no TDD task
-exists and no extra wave is created.**
-
-## Orchestrator-synthesized tasks (the mock example, any future one)
-
-Some dispatched tasks appear in no `tasks[]` because the ORCHESTRATOR synthesized
-them — the mock example (`_shared/drift-recovery.md`). They still obey hard rule
-1: **dispatched like any other task, never done by you.** But they have no
-planner-emitted `facets`, and the orchestrator is by definition the party that
-did NOT read the code — inventing a vector for them is judgment wearing
-arithmetic's clothes, the exact thing the facet redesign removed.
-
-So their vector is **DERIVED, never judged**:
-
-| Facet | Value |
-|---|---|
-| `breadth` | `len(files the synthesized task will touch)` |
-| `novelty` | `mechanical` — it transcribes planner-authored material |
-| `logic` | `none` |
-| `test_surface` | per the task |
-| `risk` | `[]` — unless the synthesized task itself inherits a CITED risk |
-
-## Post-wave worktree audit (a GATE, not a report)
-
-Declarations can be wrong, and a return can be honest and still miss what
-happened. Capture `git status --short` BEFORE the wave dispatches and again
-after every task returns, then diff the two:
-- **Any path whose state changed and is in NO task's `declared_files`** → name
-  the path and the likely task, and get an explicit user decision BEFORE the
-  wave closes. A wave never closes over an unexplained worktree delta.
-- **A file that became LESS modified is as much a violation as one that became
-  more modified.** That is the revert signature — an executor made an
-  unsatisfiable assertion true by `git checkout`-ing another task's completed
-  work, returned a literally-true report, and left a CLEAN tree. Nothing that
-  reads returns can see it.
-- **Stray files count** — a path that appears at the repo root (a stdout dump, a
-  mangled-path artifact) is undeclared output, not noise to ignore.
-- Two agents in one wave touched the same undeclared file → record
-  `failure_reason: "file-collision:<file> with <agent>"`, set the
-  later-finishing task to `requeued`, re-dispatch in a later wave so it sees
-  the other's committed changes.
-- Declarations are the plan, `actual_files` is the ATTESTATION, and
-  `git status` is the AUDIT — same instruction → contract → attestation →
-  spot-check pattern the plan applies to `grounding[]`.
-- Canonical cross-lane wording: `_shared/return-validation.md` §6.
-
-<!-- /orc:layer -->
+# Phase — Wave grouping   (id: `wave-grouping`)
+
+> **Library file** (`orc`, `orc-diy`), `core` only: the conflict graph is arithmetic, and every lane that groups waves groups them this way.
+
+<!-- orc:layer core -->
+## Reference — Wave Grouping & Conflict Graph
+
+Turn the tagged task list into conflict-free waves. Load during Phase 3.
+
+## Waves are computed for EVERY run — dispatch style is intra-wave only
+
+Wave computation is NOT a parallel-mode concern. It runs for **every run with ≥2
+tasks, sequential included** (dependency layers + conflict graph +
+`max_wave_tasks` cap). **Dispatch style controls only INTRA-WAVE concurrency:**
+
+- **parallel** → a wave's non-conflicting tasks dispatch at once (up to
+  `max_wave_tasks`);
+- **sequential** → the SAME waves, but a wave's tasks dispatch one at a time, in
+  order; the wave still closes only when all its tasks close.
+
+Either way the **wave-boundary gate fires identically** (the deterministic batch
+pause below binds to wave numbers, not to a dispatch style). A sequential run
+therefore never degenerates to "no waves / per-task pauses" — a 5-task plan
+becomes e.g. `[T1] [T2 T3 T4] [T5]`, not five ad-hoc stops. **Show the wave plan
+(wave → tasks → pause marks) to the user BEFORE wave 1 in BOTH styles.**
+
+## The principle
+
+Two tasks may share a wave ONLY if their `declared_files` don't overlap AND
+neither depends on the other. Conflicts are designed out by scheduling — never
+negotiated at runtime.
+
+## Algorithm
+
+1. **Dependency edges:** a task's earliest wave = max(wave of its deps) + 1.
+2. **Conflict edges:** for every pair, mark conflict if `declared_files` globs
+   intersect (expand against the repo tree; unresolvable globs conflict on
+   their literal prefix).
+3. **Assign greedily in topological order:** place each task in the earliest
+   wave where (a) all deps are earlier and (b) nothing in that wave conflicts.
+   Otherwise open a new wave.
+4. **Cap concurrency at `config.max_wave_tasks`** (default 3): a wave NEVER
+   exceeds this many tasks, even if more are conflict-free. Overflow moves to the
+   next wave. This is the efficiency cap — 3 parallel subagents by default.
+5. **Mark batch pauses:** compute the pause schedule from the user's Phase 2
+   answer — mark `is_batch_pause: true` on wave W when `W % N == 0` AND a later
+   wave exists (`W < total_waves`); the last wave is NEVER a pause (nothing
+   remains to gate). The resulting wave indices are the `pause_schedule` stored
+   in the checkpoint. A pause so marked is a HARD gate (stop-resume.md), not
+   an orchestrator judgment call.
+
+## Same-feature collision
+
+If two tasks own the same feature/files with no dependency between them, the
+graph auto-serializes them — but that's a planning smell. Surface it: suggest
+merging them into one task rather than silently serializing duplicate work.
+
+## TDD tasks are ORDINARY tasks (v0.41.0)
+
+TDD red proofs are **planner-emitted tasks**, not an orchestrator-synthesized
+Wave 0. Each one materializes the `tdd_spec` entries of the implementation task
+it guards, and that task lists it in `depends_on`. Nothing here special-cases
+them:
+
+- they enter the same conflict graph via their `declared_files` (their test
+  files), so **independent TDD tasks share a wave and run in parallel** — the
+  red proofs for two unrelated features are one wave, not two;
+- `depends_on` guarantees **a red proof is always in an earlier wave than the
+  code it proves** — a proof can never land beside its implementation;
+- they are scored from **their own planner-emitted `facets`**, like any task, so
+  no derived-vector rule is needed;
+- `max_wave_tasks`, `is_batch_pause` and `pause_schedule` bind to them unchanged.
+
+**A TDD task does NOT inherit the risk floor** of the task it guards: it
+transcribes planner-authored skeletons, writes no production code, and its output
+is asserted RED before anything is believed. The planner reflects that in the
+task's own facets (`novelty: mechanical`, `logic: none`, `risk: []`). Stated here
+so it is not re-litigated per run — the alternative is a Haiku-sized
+transcription job dispatched at floor 70 because the requirement it proves is
+auth-flavoured.
+
+**If no task carries `new-surface` or `behavior-change` entries, no TDD task
+exists and no extra wave is created.**
+
+## Orchestrator-synthesized tasks (the mock example, any future one)
+
+Some dispatched tasks appear in no `tasks[]` because the ORCHESTRATOR synthesized
+them — the mock example (`_shared/drift-recovery.md`). They still obey hard rule
+1: **dispatched like any other task, never done by you.** But they have no
+planner-emitted `facets`, and the orchestrator is by definition the party that
+did NOT read the code — inventing a vector for them is judgment wearing
+arithmetic's clothes, the exact thing the facet redesign removed.
+
+So their vector is **DERIVED, never judged**:
+
+| Facet | Value |
+|---|---|
+| `breadth` | `len(files the synthesized task will touch)` |
+| `novelty` | `mechanical` — it transcribes planner-authored material |
+| `logic` | `none` |
+| `test_surface` | per the task |
+| `risk` | `[]` — unless the synthesized task itself inherits a CITED risk |
+
+## Post-wave worktree audit (a GATE, not a report)
+
+Declarations can be wrong, and a return can be honest and still miss what
+happened. Capture `git status --short` BEFORE the wave dispatches and again
+after every task returns, then diff the two:
+- **Any path whose state changed and is in NO task's `declared_files`** → name
+  the path and the likely task, and get an explicit user decision BEFORE the
+  wave closes. A wave never closes over an unexplained worktree delta.
+- **A file that became LESS modified is as much a violation as one that became
+  more modified.** That is the revert signature — an executor made an
+  unsatisfiable assertion true by `git checkout`-ing another task's completed
+  work, returned a literally-true report, and left a CLEAN tree. Nothing that
+  reads returns can see it.
+- **Stray files count** — a path that appears at the repo root (a stdout dump, a
+  mangled-path artifact) is undeclared output, not noise to ignore.
+- Two agents in one wave touched the same undeclared file → record
+  `failure_reason: "file-collision:<file> with <agent>"`, set the
+  later-finishing task to `requeued`, re-dispatch in a later wave so it sees
+  the other's committed changes.
+- Declarations are the plan, `actual_files` is the ATTESTATION, and
+  `git status` is the AUDIT — same instruction → contract → attestation →
+  spot-check pattern the plan applies to `grounding[]`.
+- Canonical cross-lane wording: `_shared/return-validation.md` §6.
+
+<!-- /orc:layer -->

package/templates/skills/_shared/phases/wiki-consult.md

@@ -1,11 +1,6 @@
 # Phase — Wiki consult   (id: `wiki-consult`)
 
-> **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-mini`, `orc-fast`, `orc-wiki`. Layers declared: `core` only —
-> single-layer because the precedence ladder (`code > fresh wiki > stale wiki
-> > model priors`) does not bend for a faster lane. `orc lane phases <lane>
-> --json` names the file and the layers to read.
+> **Library file** (`orc`, `orc-mini`, `orc-fast`, `orc-wiki`), `core` only: the ladder `code > fresh wiki > stale wiki > model priors` does not bend for a faster lane.
 
 <!-- orc:layer core -->
 ## Reference — Wiki Consult (shared by orc / orc-mini / orc-fast)
@@ -148,6 +143,15 @@ actually read, or `none`. `none` on a slice that carried docs is a REAL signal
 It is the only thing that distinguishes a wiki that is working from one that is
 merely being shipped.
 
+**orc-mini only** (moved here from its spine at v2.0.0):
+
+**`none` is an answer — record it, never drop it.** `wiki_used: none` and
+`graph_used: none` from ANY return go into the checkpoint and the ship line
+(`knowledge: wiki 2 pages offered · used none · graph card 2 targets · used
+none`). Two runs in a row with `wiki_used: none` on FRESH pages → one line:
+`wiki: the selected pages were not used in 2 runs — check their TL;DRs
+(/orc-wiki)`. A signal, never a gate, never dropped for looking null.
+
 ## Scoring bonus (full lane, Phase 2)
 
 If a non-empty `wiki/` is present, use its overviews' "Notes for planning" to

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

@@ -5,14 +5,6 @@ about to edit: scouts, wiki scan-tasks, the analyst, the reviewer, and every
 executor reading a file for context rather than for change. Load this wherever
 a slice tells an agent to go read something.
 
-## Why this exists
-
-ORC's cost is dominated by parallel reading, not by thinking: up to `max_scouts`
-scouts at once, a wiki scan that is expensive by design, and every executor in a
-wave opening its declared files. A role that opens a 900-line file to learn one
-function's shape has spent the run's budget on bytes nobody needed. Reading more
-is not understanding more.
-
 ## The ladder
 
 Escalate one step at a time. Stop at the step that answers the question.
@@ -88,50 +80,6 @@ is a `needs_context` return, not permission to keep going.
    lint results — the smoke gate, the TDD gate, the verifier and orc-quick's
    build loop decide red vs green from those exact bytes. Read them whole.
 
-## Reading ORC's own payload — the partial-read discipline (v1.0.0 W10)
-
-Everything above is about reading the PROJECT. It applies unchanged to reading
-ORC's own files, and it has to: a lane manifest of pointers that every lane
-dutifully reads whole is MORE round-trips than the prose it replaced, for the
-same bytes. Centralizing prose and then reading all of it is a slower payload,
-not a smaller one.
-
-So every pointer a lane carries declares three things.
-
-| Declaration | Values | Means |
-|---|---|---|
-| `when` | `always` · `on-phase` · `on-state` · `on-demand` · `compile-time` | WHETHER to open it at all |
-| `read` | `layer` · `section` · `whole` | HOW MUCH to open |
-| `layers` | `core` · `full` · `trim` · `composed` | WHICH part, when `read: layer` |
-
-### The four rules that make it honest
-
-1. **`on-phase` is the default, and `always` must be justified.** A file every
-   lane always loads has saved nothing by moving. Each `always` pointer is
-   named in the wave that adds it.
-2. **`read: section` names a HEADING, never a line number.** A stored line
-   number is a wrong line number one edit later; a heading anchor survives an
-   edit above it. This is why a shared file's headings are part of its
-   contract — renaming one breaks every pointer into it.
-3. **A trimmed lane reads `core` plus its OWN layer, and never the `full`
-   layer.** Reading a neighbouring layer "for context" is the bleed this rule
-   exists to stop: the layer boundary is the product promise, not a suggestion.
-4. **The two exceptions above carry over unchanged.** A file you will EDIT is
-   read in full, first, always; and output a gate parses is read whole.
-5. **`compile-time` is not a run-time read at all.** `orc-diy` is a declared
-   reader of ten shared phases and opens none of them during a run: the `orc
-   diy compile` CLI reads their `composed` layer once and stitches it into
-   `FLOW-COMPILED.md`, which is the only spine that run then follows. Saying
-   `on-phase` there would describe a read that never happens, and a manifest
-   that describes a run nobody performs is the drift it exists to prevent
-   (v1.0.0 W13).
-
-### The honest limit
-
-A partial read saves round-trips and bytes for the lanes that SKIP a phase. It
-does **not** make a phase cheaper for the lane that runs it — that lane reads
-its layers whole. Any claim otherwise has to show the measurement.
-
 ## Handoff
 
 The ladder governs HOW MUCH to read. It never decides WHETHER knowledge exists —
@@ -140,6 +88,5 @@ that is `detecting-artifacts.md` — and it never overrides precedence:
 the same order gains two rungs and loses none:
 `code > graph structure (current blob) > fresh wiki > stale wiki (hints) > graph notes and doc notes > model priors`.
 
-What a lane INVOKES, and what each exit code means, is not here either: that is
-`orc lane calls <lane> --json`, whose catalogue is the one copy of every call
-two or more lanes share.
+An orchestrator reading ORC's OWN payload follows the partial-read rules in
+`phases/README.md` (§Pointer discipline).