@azure-id/orc 1.9.1 → 2.0.2

package/templates/skills/_shared/phases/plan-handoff.md

@@ -1,97 +1,91 @@
-# Phase — Plan handoff   (id: `plan-handoff`)
-
-> **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-route`. Layers declared: `core` only — single-layer because
-> executing a plan another session wrote is the same procedure wherever it is
-> done, and /orc-route reads it to DEFINE what a plan is (v0.42.0 — a second
-> definition is drift the lint cannot see). `orc lane phases <lane> --json`
-> names the file and the layers to read.
-
-<!-- orc:layer core -->
-## Reference — Plan Handoff (executing a plan from another session)
-
-The entry contract for the case ORC had no defined path for: **the run input
-IS a plan**, not a request. A plan was produced in one session (or saved to a
-file) and handed to a fresh session to build. Load `plan-handoff.md`
-at Phase 0 the moment you recognise a plan input; it turns a pasted plan into a
-real ORC run instead of an ad-hoc task-by-task improvisation.
-
-## Trigger — the input IS a plan
-
-Recognise a plan input when the run starts from any of:
-
-- **pasted planning-output** — a YAML/markdown block matching
-  `schemas/planning-output.md` (has a `tasks:` list with `declared_files`,
-  `depends_on`, `grounding[]`);
-- **a `plan-{name}.md` path** the user points at;
-- **an `orc/planner/{name}/` checkpoint** (the planner's "Save & stop" artifact).
-
-A plain-language feature request is NOT a plan input — that is ordinary Phase 0
-intake. When in doubt (a prose paragraph with no task structure), treat it as a
-request and run intake normally.
-
-## Why this exists (the failure it prevents)
-
-A plan built in session A and executed in session B used to improvise: no spine
-load, no trace protocol (the hook bootstrapped a generic `run-*.txt`), no Phase
-1 exit gate re-run, no Phase 2 scoring or pause schedule, no Phase 3 wave
-grouping. The result was a bare SPAWN/RETURN trace, per-task ad-hoc pauses, and
-**phantom-file drift** — the plan declared a file that never (or no longer)
-existed, invisible because the plan's grounding Glob ran at *planning* time in
-the other session and nothing re-ran it here.
-
-## Mandatory sequence (never execute a plan task-by-task ad hoc)
-
-Do these IN ORDER before any dispatch. Skipping any step is a protocol
-violation.
-
-1. **This IS a run — bootstrap it.** Load the spine (`orc/SKILL.md`) and
-   `../../_shared/phases/trace.md`; create `log_dir`, write `log_dir/.current` =
-   `run-orc-<slug>-<DDMMYY>-<HHMMSS>.txt` AND `touch the trace file` of that name
-   in the SAME step (both, or neither — a pointer naming a file that does not
-   exist is what splits a run across two files), store `trace_path` in the
-   checkpoint. Record `PHASE intake start` into this phase's packet.
-2. **Schema-validate against `schemas/planning-output.md`.** Every task needs
-   `declared_files`, `grounding[]`, `depends_on`, `requirements[]`,
-   `acceptance[]`, `owns_area`, `spec_ref`, and the `facets` block (Part D). A
-   malformed plan → show exactly what field is missing and offer a re-plan via
-   `orc-planner` (dispatch it with the miss list). **Never improvise a missing
-   field** — a guessed `declared_files` or an invented `facets` vector defeats
-   the point of consuming a plan.
-3. **Staleness valve (`plan_head`).** The plan carries `plan_head` — HEAD at
-   plan time (the mirror of a requirement-spec's `git_head`). If `plan_head` ≠
-   current HEAD, OR the field is absent (a pre-v0.31.0 plan), the grounding
-   spot-check in step 4 is **compulsory** and its misses are surfaced, not
-   waved through. Matching heads still run the gate — they only lower the
-   suspicion.
-4. **Re-run the FULL Phase 1 exit gate in THIS session** (deterministic — the
-   checks live in `analyst-gates.md`; emit `GATE` lines): Glob every
-   `disposition: exists` path, recompute coverage (no `orphan` requirements),
-   cycle detection over `depends_on`, same-file collision over `declared_files`.
-   This is the deterministic catch for phantom-file drift — a declared path that
-   no longer (or never) existed bounces **before** any dispatch. On a miss,
-   offer a targeted re-ground (one `orc-planner` re-dispatch with the miss list)
-   or a user correction; never dispatch past an unresolved miss.
-5. **Relay unresolved `open_questions[]`** (Part E) in ONE batch before
-   proceeding: blocking questions must be answered; non-blocking show their
-   `proposed_default` for tacit approval. A `plan_confidence: low` plan →
-   recommend stepping back to `orc-analyze` (the user may override).
-6. **Then the NORMAL pipeline.** Emit `PHASE planning end`, then run Phase 2
-   (facet scoring + dispatch-style recommendation + the batch-pause schedule
-   question) → Phase 3 (wave grouping — waves are computed regardless of
-   dispatch style, see `wave-grouping.md`) → review → verify → ship. **A plan
-   input never skips Phase 2/3.** The plan supplied the tasks; the orchestrator
-   still owns scoring, waves, and pauses.
-
-## Not this
-
-- **Not** a re-plan. If the plan validates and grounds clean, DO NOT re-run the
-  planner — the plan is authoritative; you are scoring and scheduling it.
-- **Not** a scope re-litigation. Scope was settled where the plan (or its
-  upstream spec) was produced. The gate checks structural integrity, not intent.
-- **Not** a poly-spec path. A poly-spec (`orc-poly:spec`) is split-and-STOP at
-  Phase 1 (see SKILL.md) — that is a different input than a per-repo
-  planning-output handed here to build.
-
-<!-- /orc:layer -->
+# Phase — Plan handoff   (id: `plan-handoff`)
+
+> **Library file** (`orc`, `orc-route`), `core` only: executing another session's plan is one procedure, and /orc-route reads this file to DEFINE a plan — a second definition is drift.
+
+<!-- orc:layer core -->
+## Reference — Plan Handoff (executing a plan from another session)
+
+The entry contract for the case ORC had no defined path for: **the run input
+IS a plan**, not a request. A plan was produced in one session (or saved to a
+file) and handed to a fresh session to build. Load `plan-handoff.md`
+at Phase 0 the moment you recognise a plan input; it turns a pasted plan into a
+real ORC run instead of an ad-hoc task-by-task improvisation.
+
+## Trigger — the input IS a plan
+
+Recognise a plan input when the run starts from any of:
+
+- **pasted planning-output** — a YAML/markdown block matching
+  `schemas/planning-output.md` (has a `tasks:` list with `declared_files`,
+  `depends_on`, `grounding[]`);
+- **a `plan-{name}.md` path** the user points at;
+- **an `orc/planner/{name}/` checkpoint** (the planner's "Save & stop" artifact).
+
+A plain-language feature request is NOT a plan input — that is ordinary Phase 0
+intake. When in doubt (a prose paragraph with no task structure), treat it as a
+request and run intake normally.
+
+## Why this exists (the failure it prevents)
+
+A plan built in session A and executed in session B used to improvise: no spine
+load, no trace protocol (the hook bootstrapped a generic `run-*.txt`), no Phase
+1 exit gate re-run, no Phase 2 scoring or pause schedule, no Phase 3 wave
+grouping. The result was a bare SPAWN/RETURN trace, per-task ad-hoc pauses, and
+**phantom-file drift** — the plan declared a file that never (or no longer)
+existed, invisible because the plan's grounding Glob ran at *planning* time in
+the other session and nothing re-ran it here.
+
+## Mandatory sequence (never execute a plan task-by-task ad hoc)
+
+Do these IN ORDER before any dispatch. Skipping any step is a protocol
+violation.
+
+1. **This IS a run — bootstrap it.** Load the spine (`orc/SKILL.md`) and
+   `../../_shared/phases/trace.md`; create `log_dir`, write `log_dir/.current` =
+   `run-orc-<slug>-<DDMMYY>-<HHMMSS>.txt` AND `touch the trace file` of that name
+   in the SAME step (both, or neither — a pointer naming a file that does not
+   exist is what splits a run across two files), store `trace_path` in the
+   checkpoint. Record `PHASE intake start` into this phase's packet.
+2. **Schema-validate against `schemas/planning-output.md`.** Every task needs
+   `declared_files`, `grounding[]`, `depends_on`, `requirements[]`,
+   `acceptance[]`, `owns_area`, `spec_ref`, and the `facets` block (Part D). A
+   malformed plan → show exactly what field is missing and offer a re-plan via
+   `orc-planner` (dispatch it with the miss list). **Never improvise a missing
+   field** — a guessed `declared_files` or an invented `facets` vector defeats
+   the point of consuming a plan.
+3. **Staleness valve (`plan_head`).** The plan carries `plan_head` — HEAD at
+   plan time (the mirror of a requirement-spec's `git_head`). If `plan_head` ≠
+   current HEAD, OR the field is absent (a pre-v0.31.0 plan), the grounding
+   spot-check in step 4 is **compulsory** and its misses are surfaced, not
+   waved through. Matching heads still run the gate — they only lower the
+   suspicion.
+4. **Re-run the FULL Phase 1 exit gate in THIS session** (deterministic — the
+   checks live in `analyst-gates.md`; emit `GATE` lines): Glob every
+   `disposition: exists` path, recompute coverage (no `orphan` requirements),
+   cycle detection over `depends_on`, same-file collision over `declared_files`.
+   This is the deterministic catch for phantom-file drift — a declared path that
+   no longer (or never) existed bounces **before** any dispatch. On a miss,
+   offer a targeted re-ground (one `orc-planner` re-dispatch with the miss list)
+   or a user correction; never dispatch past an unresolved miss.
+5. **Relay unresolved `open_questions[]`** (Part E) in ONE batch before
+   proceeding: blocking questions must be answered; non-blocking show their
+   `proposed_default` for tacit approval. A `plan_confidence: low` plan →
+   recommend stepping back to `orc-analyze` (the user may override).
+6. **Then the NORMAL pipeline.** Emit `PHASE planning end`, then run Phase 2
+   (facet scoring + dispatch-style recommendation + the batch-pause schedule
+   question) → Phase 3 (wave grouping — waves are computed regardless of
+   dispatch style, see `wave-grouping.md`) → review → verify → ship. **A plan
+   input never skips Phase 2/3.** The plan supplied the tasks; the orchestrator
+   still owns scoring, waves, and pauses.
+
+## Not this
+
+- **Not** a re-plan. If the plan validates and grounds clean, DO NOT re-run the
+  planner — the plan is authoritative; you are scoring and scheduling it.
+- **Not** a scope re-litigation. Scope was settled where the plan (or its
+  upstream spec) was produced. The gate checks structural integrity, not intent.
+- **Not** a poly-spec path. A poly-spec (`orc-poly:spec`) is split-and-STOP at
+  Phase 1 (see SKILL.md) — that is a different input than a per-repo
+  planning-output handed here to build.
+
+<!-- /orc:layer -->

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

@@ -1,16 +1,6 @@
 # Phase — Planning   (id: `planning`)
 
-> **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 -->
 
@@ -21,7 +11,7 @@ resolved values of every config key this run will consume (ALWAYS `opus5_only`
 proof `/orc-retro` audits that the run honored the config.
 **Wiki consult (load `wiki-consult.md`;
 always report — no tier is silent):** read the FRESH/AGING/STALE tier from
-**`orc wiki status`** (v0.41.0 — deterministic; never hand-compute it from `wiki-meta.json`), pull the relevant pages (incl. cross-cutting maps like `orc-reference-api-surface`), apply
+**`orc wiki status`** (deterministic; never hand-compute it from `wiki-meta.json`), pull the relevant pages (incl. cross-cutting maps like `orc-reference-api-surface`), apply
 `code > fresh wiki > stale wiki (hints) > model priors`, emit
 `WIKI-CONSULT <tier> :: docs=<pages>`, print the one-line tier report (every tier, `absent` included), and attribute per-dispatch too — `wiki:` on the `DISPATCH` line + a `wiki_used` return (wiki-consult.md Step 5). **Crosslink:** per wiki-consult.md, inject
 the cached `.claude/orc/crosslink/needs.json` contract into any boundary-touching
@@ -44,17 +34,17 @@ facets. Also run `orc graph cochange <each candidate file> --if-enabled --json -
 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.
-**Pact / boundary / aftermath / wiki debt (v0.46.0 — all CONSUMED here, never
+**Pact / boundary / aftermath / wiki debt (all CONSUMED here, never
 written here):** probe `orc pact status --json` (`pact_gate`, default `warn`),
 `orc boundary status --json` (`boundary_gate`, default `warn`), `orc wiki debt
 --json`, and — only to decide whether the preflight's `after:` line fires at all —
 `orc aftermath status --json`. Print each probe's own `line` VERBATIM; never
 recount or re-word one. Gates: `../../orc-pact/references/gate.md` +
-`../../orc-boundary/references/gate.md`. **Challenge (v0.47.0, `challenge_gate`,
+`../../orc-boundary/references/gate.md`. **Challenge (`challenge_gate`,
 default `warn`):** when the run's INPUT DOCUMENT has a cycle, print
 `orc challenge status <slug> --json`'s `preflight_line` verbatim — building from
 a document that has not passed its own review is worth one line. There is no
-`block` mode (the `/orc-pact` precedent). **Extra (v0.50.0, `extra_enabled`) —
+`block` mode (the `/orc-pact` precedent). **Extra (`extra_enabled`) —
 resolved HERE, announced HERE, never silent:** load `../extra-dispatch.md`;
 per task run `orc extra resolve <score> --role executor --risk <n> --json`, and
 before wave 1 settle its two pre-dispatch states, both PRINTED — a `needs_reping`
@@ -63,7 +53,7 @@ profile (re-ping; a STALE profile still routes) and a vaulted credential, which
 Claude rather than stopping the run. **Preflight:** print the compact block per
 `../../orc/references/preflight-report.md` once wiki + crosslink (+ pattern/waves) resolve.
 
-Ask which planner: **Superpowers / OpenSpec / Requirement Planner / ORC
+Ask which planner (H `orc.phase-1.planner`): **Superpowers / OpenSpec / Requirement Planner / ORC
 (self)**. With an analyst requirement-spec present, the Requirement Planner
 is the natural choice (consumes the spec; does NOT re-question scope); apply
 the `git_head` staleness valve first (analyst-gates.md). Dispatch the planner
@@ -80,7 +70,7 @@ only input that does NOT proceed to Phase 2 (each repo builds later, in its own
 `../../orc/schemas/planning-output.md` (per-task `declared_files` incl. tests,
 `grounding[]`, `acceptance[]`, `requirements[]`, `spec_invariants[]`,
 `depends_on`, `owns_area`, `spec_ref`, + a `coverage` echo, + `tdd_spec` —
-TDD is ALWAYS ON in full orc/ultra but **SCOPED to what can actually fail (v0.41.0)**: a `disposition` per entry (`new-surface | behavior-change | covered-by-existing | no-behavior | no-runner`) DERIVED from the planner's facets — constants/translations/file-splits get NO test, a cited `risk[]` is never scoped out, and a PAIRED task materializes it, never a Wave 0 (schema notes 7-8; gate check 5);
+TDD is ALWAYS ON in full orc/ultra but **SCOPED to what can actually fail**: a `disposition` per entry (`new-surface | behavior-change | covered-by-existing | no-behavior | no-runner`) DERIVED from the planner's facets — constants/translations/file-splits get NO test, a cited `risk[]` is never scoped out, and a PAIRED task materializes it, never a Wave 0 (schema notes 7-8; gate check 5);
 missing declared files → extract and confirm before leaving this phase.
 
 **Phase 1 exit gate** (deterministic — full checks in analyst-gates.md; emit

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

@@ -1,14 +1,6 @@
 # Phase — Preflight   (id: `preflight`)
 
-> **Library file.** New at v1.0.0 W11, distilled from the eleven lane preflight
-> sections that had independently converged on the same four steps in the same
-> order. Layers: `core` (every lane with a silent preflight) and `full`
-> (`/orc` and `/orc-ultra`, whose preflight also PRINTS a report).
->
-> **What is NOT here:** the probes themselves. Which artifacts a lane probes, and
-> which config keys it reads, are the lane's own — they are in the lane's spine
-> and in `orc lane config <lane> --json`. This file is the SHAPE: the order, and
-> the four rules that make the shape worth having.
+> **Library file.** `core` = every lane with a silent preflight; `full` = `/orc` and `/orc-ultra`, which also PRINT a report. This file is the SHAPE; the probes and config keys are the lane's own (its spine and `orc lane config <lane> --json`).
 
 <!-- orc:layer core -->
 
@@ -22,17 +14,17 @@ never a fifth step before step 2.
    yourself. Print every line of `announce[]` VERBATIM — *a shadowed setting must
    never be silent*, and a lane that resolves silently cannot tell the user why
    the thing they configured did not happen. Precedence, gates, inertness and the
-   CLI-absent floor are all in `../config-precedence.md`.
+   CLI-absent floor are all in `../config-precedence.md`. **`habits{}` in the
+   answer → print `habits.line` and read `../habits.md` NOW**.
 
 2. **Trace.** Write `log_dir/.current` = `run-<lane>-<slug>-<DDMMYY>-<HHMMSS>.txt`
    AND `touch the trace file` of that name in the SAME step. **Both, or neither.**
-   A pointer naming a file that does not exist is indistinguishable from a
-   dangling one — that split fifteen graded runs across two files each. The rest
-   of the protocol is `trace.md`.
+   The rest of the protocol is `trace.md`.
 
-3. **Probes.** Use `../detecting-artifacts.md` — **never a raw `find`**, because
-   `.claude/` is hidden and a filesystem search false-negatives a real artifact
-   from the wrong CWD. Every probe is a documented exit-code contract, listed
+3. **Probes.** Read each probe's answer from `probes{}` in the step-1 answer.
+   Run a probe yourself only when `probes{}` does not have it or its entry has
+   `error` — by `../detecting-artifacts.md`, **never a raw `find`** (`.claude/`
+   is hidden). Every probe is a documented exit-code contract, listed
    once in `orc lane calls <lane>`. Treat a positive probe as the source of truth
    and never second-guess it.
 
@@ -55,27 +47,12 @@ never a fifth step before step 2.
   ledger yet, this is a first run"; `orc gotcha status` exit 1 is an empty
   ledger. Say what it means, not that it failed.
 
-## The rules line (v1.7.0) — printed by every lane that runs the `rules` phase
+## The rules line — printed by every lane that runs the `rules` phase
 
-`orc rules slice --lane <lane> --json` returns a `line`. Print it VERBATIM:
+Print `probes["rules-slice"].line` (`orc rules slice --lane <lane> --json`) VERBATIM — both spellings and the override names are `./rules.md` §One assembler and §Precedence.
+`/orc-doc` prints `house rules: …` from `orc doc rules` instead; the two surfaces never mix.
 
-```
-rules:    ORC 65 (W 23 · C 22 · D 10 · U 10) · yours 9 lines (P0 4 · P1 2 · P2 3) · 1 override
-rules:    ORC 65 (W 23 · C 22 · D 10 · U 10) · yours none
-```
-
-**Both spellings are mandatory in their state.** `yours none` says the project
-has not written its own rules — a different fact from the CLI failing to look,
-and the line is what keeps the two apart. Never compute the counts here.
-
-Where the lane's preflight prints a REPORT rather than a bare line, the report
-names each override under it. An override the user cannot see is an override
-they cannot audit. The rest of the mechanic is `./rules.md`.
-
-`/orc-doc` prints `house rules: …` instead, from `orc doc rules`. The two
-surfaces are different files and never mix.
-
-## The usage line (v1.1.0) — printed whenever `usage_gate` is armed
+## The usage line — printed whenever `usage_gate` is armed
 
 `usage_gate` resolves in step 1 like any other key. When it is anything but
 `off`, run `orc usage check --json` in step 3 and print ONE line:
@@ -97,14 +74,14 @@ and again at every gate it suppresses. The rest of the mechanic — the modes, t
 hops, what `stop` and `wait` actually do — is `../wait.md`; this file only says
 that the line is printed and when.
 
-## The graph line (v1.8.0) — code-changing lanes only
+## The graph line — code-changing lanes only
 
-`/orc`, `/orc-ultra`, `/orc-diy`, `/orc-mini`, `/orc-fast` and `/orc-quick` run
-`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
-packet as it is — never as a `GATE` line in your own words. While the graph is
+`/orc`, `/orc-ultra`, `/orc-diy`, `/orc-mini`, `/orc-fast` and `/orc-quick` print
+`probes["graph-status"].line` (`off` included) in step 3, BEFORE the first
+dispatch — never skipped. Run `orc graph status --if-enabled --heal --json --brief`
+only when `heal_needed` is true (it builds or updates the graph, free). Put the
+`trace` (`GRAPH-CONSULT …`) in the next packet as it is — never as a `GATE` line
+in your own words. While the graph is
 on, `orc lane config` prints the three graph steps in `announce[]` (`../code-graph.md`
 §0). **The lane reads no `code_graph` key:** `--if-enabled`
 makes the CLI decide, which is how `/orc-quick` takes part while its step 1 still

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

@@ -1,38 +1,32 @@
 # Phase — Review   (id: `review`)
 
-> **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 -->
 
 ## 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
+Emit `PHASE review start`. **Build the slice from `../review-slice.md`** — its
+§1 free check FIRST, then its §2 fields (with the graph on, `graph_changes` keeps
+its rows: no `--brief` here). Superpowers path: its review skill incl. tests
+(Sonnet 4.6 medium), then `../review-slice.md` §3 on its findings — no second
+dispatch. 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).
+(pattern-gate.md); no resolved pattern → FIRST ask for one (paste/md/none) (H `orc.phase-5.pattern-missing`).
 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.
-**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
++ fe-perf. Findings arrive on the **P0–P3 ladder** (invariant violation or
 unmet gate line = P0; every P0–P2 carries `file:line` + VERBATIM `quote`;
-unanchored → P3). Apply hard rule 5 INCLUDING the quote spot-check: P0 →
-auto-fix once · P1 → ask, then fix once · P2/P3 → record for Phase 7. Emit
-`FINDING p0=<n> p1=<n> p2=<n> p3=<n>` on the return, then `PHASE review end`.
+unanchored → P3). Run `../review-slice.md` §3 (the after-filter) on the return.
+**Disprove pass (R6, `/orc` and `/orc-ultra` ONLY):** a P0 or P1 left → dispatch
+the SAME reviewer with `mode: disprove`, only those findings + their files; a
+`keep: false` verdict → P3 with its `why`. Then apply hard rule 5 INCLUDING the
+quote spot-check, per `group`: P0 →
+auto-fix once · P1 → ask, then fix once · P2/P3 → record for Phase 7.
+**Re-review (R9):** after a P0/P1 fix, dispatch the reviewer once more with
+`previous_findings[]` (each with its outcome). It may raise a NEW finding only
+on a line the fix changed. Its `gotcha_recorded` body → `orc gotcha add -`. Emit
+`FINDING p0=<n> p1=<n> p2=<n> p3=<n> pre=<n> suppressed=<n> folded=<n>` on the
+return (the tail = the §3 buckets), then `PHASE review end`. Outcomes: Phase 7.
 
 <!-- /orc:layer -->
 
@@ -48,11 +42,13 @@ skipped by flow config") — never imply the work was reviewed.
 Dispatch the reviewer exactly as the full lane does — follow the review half
 of `.claude/skills/orc/subskills/orc-review-verify/SKILL.md` (reviewer agent
 `orc-reviewer-opus-5-med`; findings ride the severity ladder from the
-locked rules, blocking and advisory findings both surfaced).
+locked rules, blocking and advisory findings both surfaced). Build its slice
+from `.claude/skills/_shared/review-slice.md` (§1 free check, §3 after-filter).
 <!-- /diy:when -->
 <!-- diy:when review=blocking-only -->
 Dispatch the reviewer exactly as the full lane does — follow the review half
-of `.claude/skills/orc/subskills/orc-review-verify/SKILL.md` — but only
+of `.claude/skills/orc/subskills/orc-review-verify/SKILL.md`, with the slice
+of `.claude/skills/_shared/review-slice.md` — but only
 P0/P1 findings gate anything; P2/P3 findings are listed once in the summary
 and never re-offered as fix-up tasks.
 <!-- /diy:when -->

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

@@ -1,18 +1,6 @@
 # Phase — Rules   (id: `rules`)
 
-> **Library file.** New at v1.7.0 W5. Layers declared: `core` only — single-layer
-> for the same reason `house-rules.md` is: it is a standing card injected
-> VERBATIM into a slice, and a layered card would be a different card. What
-> varies between lanes is DATA (which packs, whether a task is front-end), not
-> prose. `orc lane phases <lane> --json` names the file and the layers to read.
->
-> **What is NOT here:** the rules. They are `../rules/` — four packs, read-only,
-> shipped. This file is the SHAPE: who assembles the card, where it sits in a
-> slice, what comes back, and what the phase must never do.
->
-> **`/orc-doc` does not run this phase.** That lane has its own ledger
-> (`orc doc rules`) and its own frozen-per-document mechanic. Excluded means
-> excluded, and `orc rules slice --lane orc-doc` refuses by name.
+> **Library file**, `core` only (a standing card, like `house-rules.md`). The rules are in `../rules/`; this file is the SHAPE. **`/orc-doc` does not run this phase** — it has `orc doc rules`, and `orc rules slice --lane orc-doc` refuses by name.
 
 <!-- orc:layer core -->
 
@@ -118,11 +106,8 @@ structural and safety rules.
 A rule that asks for one of those comes back as `unsupported_request` and is
 relayed as a gap. **Never a guessed compromise.**
 
-**Do not build a detector for this.** The CLI declares the boundary and does not
-pretend to enforce it, for the reason `orc doc rules` already settled: a
-validator that sometimes works is worse than none, because a clean pass then
-means nothing. The agent is the only reader that can tell a content rule from a
-structural one, so the agent is where the answer comes from.
+The CLI declares this boundary and does not enforce it. The agent is the only
+reader that can tell a content rule from a structural one.
 
 ## The free lint
 
@@ -144,29 +129,20 @@ An exemption is never silent either. The lint skips the rules packs themselves
 (a rule that bans a word has to print that word to define it) and any file
 marked `orc-rules-ignore-file`, and it reports the count of both.
 
-## Cost, and where to cut it
-
-Measured at v1.7.0: roughly **3 600 tokens** per build-lane slice, **4 300** with
-the UI pack, **2 200** for a prose-only lane. The card already carries HARD rules
-in full and PURPOSE/LOCK rules as one line plus the file to open when one
-applies.
-
-If it must come down, the lever is the worked examples inside the HARD bodies,
-and the only place to pull it is `rulesSlice()` in `bin/cli.js`. **Never by a
-lane deciding to trim its own card** — that is the drift this phase exists to
-prevent, arriving disguised as a saving.
-
-**v1.9.0 — the COMPACT form, and the CLI decides which lanes get it.** The
-lever above is now pulled for **`orc-quick`** and for no one else: every HARD
-rule keeps its id, its title and its first line — the instruction — and the
-worked examples come out, with the pack file named beside them. Measured
-**13 874 → 5 838 chars** (~3 470 → ~1 460 tokens) with every HARD id still
-present. The lane that gets it is the lane with the smallest tasks under the
-largest fixed card, and the card is re-sent on every executor turn.
-
-The answer says which form it is: `compact: true` in the JSON. A reader that
-cannot tell a short card from a stripped one cannot trust either. `line` is
-IDENTICAL in both forms — it counts the rules in force, and compacting changes
-how a rule is written, never whether it applies.
+## The COMPACT card
+
+`orc-quick` gets the COMPACT form: every HARD rule keeps its id, its title and
+its first line. `orc-mini` and `orc-fast` get it too, because `rules_card_compact`
+is `on` by default since v2.0.2 (eval E4 passed, DE-17); `off` gives them the full
+card. The CLI decides this, never the lane. The answer says `compact: true` in the JSON. `line` is IDENTICAL in
+both forms.
+
+## The LEARNED tier
+
+With `habits` on, the card can carry **learned preferences** (commit, branch
+and test-file naming, from `orc habit repo`). Each one rides only after your
+yes. They sit BELOW your rules and ABOVE the ORC rules. A preference that no
+longer matches 4 of the last 5 samples is `stale` and leaves the card. Under
+`habits: off` the slice has no `learned` field and no byte of this tier.
 
 <!-- /orc:layer -->