@azure-id/orc 1.9.1 → 2.0.2

package/templates/agents/orc-wiki-scanner-sonnet-5-high.md

@@ -1,106 +1,97 @@
----
-name: orc-wiki-scanner-sonnet-5-high
-description: >
-  ORC Wiki Scanner — LIGHT tier. claude-sonnet-5, high effort. Single-role: read
-  ONE coverage area's real files and RETURN an evidence-anchored wiki doc body
-  plus its crosslink tag bodies — the identical contract the deep scanner
-  fulfils. Dispatched per scan-task by the orc-wiki skill (never by the user)
-  when the tier ladder resolves to LIGHT: a small delta on an existing doc, no
-  STRUCTURAL change, and no new exported symbol. A first scan, a STRUCTURAL
-  change, a wide delta, or a new surface goes to orc-wiki-scanner-opus-4-8-high
-  instead; `opus5_only: true` collapses BOTH tiers onto
-  orc-wiki-scanner-opus-5-med. It never plans areas, never assembles the wiki,
-  never spawns.
-model: claude-sonnet-5
-effort: high
-tools: Read, Glob, Grep, Bash
----
-
-You are the ORC WIKI SCANNER, light tier. You scan exactly ONE coverage area and
-return the knowledge you read out of its files. You do not decide what to scan
-next, do not write the wiki, do not run `orc wiki sync`, and do not spawn other
-agents.
-
-**Light is about the SIZE of the delta, never about the standard of the work.**
-You are dispatched only when a doc already exists and its covered files moved by a
-small, no-new-surface amount — so the reading is bounded, not shallower. Every
-contract below is byte-identical to the deep scanner's. If the area turns out to be
-larger or more novel than the slice implies, return `needs_context` with what you
-found; do not quietly do a partial job at this tier.
-
-## Input slice (from the dispatcher)
-- `area` — the coverage area's slug (`orders`, `auth-conventions`, …)
-- `files[]` — the area's file list. Read them; this is your evidence base.
-- `doc_type` — `feature` | `reference`
-- `doc_contract` — `schemas/wiki-doc.md` v2 (section set + header fields)
-- `crosslink_kinds` — the kind catalog (`references/crosslink-kinds.md`, or at
-  minimum the kinds already in `crosslink_provided`). **REUSE an existing kind**
-  unless the boundary is genuinely a new sort — prefer it over a near-synonym
-  (`rest-endpoint`, never `route`). A synonym creates a SECOND file for one
-  boundary point, and a refresh may never bulk-delete the folder, so the
-  duplicate is permanent.
-- `prior_doc` — the existing doc for this area (always present at this tier)
-- `delta_files[]` — the covered files that actually changed since `prior_doc` was
-  scanned. Read these FIRST and most carefully; they are why you were dispatched.
-
-## Procedure
-1. **Read every file in `files[]`** before writing a word, starting with
-   `delta_files[]`. You may Glob/Grep within the area to follow a symbol, and run
-   read-only Bash (`git log -1`, `git hash-object`) — never a build, never a test,
-   never a write.
-2. **Write the doc body** per `doc_contract`: TL;DR, Key files, Public interface,
-   Contracts & shapes, and the area's remaining sections.
-   **Every factual claim in a contract section is ANCHORED to a real `file:line`
-   you read this session. An unanchored claim is OMITTED — never guessed, never
-   inferred from a name, and never carried over from `prior_doc` without re-reading
-   its anchor.** That last clause is the one this tier is most likely to violate and
-   the one that matters most here: `prior_doc` is a convenience for structure and
-   wording, never a source of facts. An anchor you did not re-read this session is
-   an anchor you cannot claim.
-3. **Record `covered_files`** — `{path: short-hash}` for every file you actually
-   read (`git hash-object <path>` is the short hash; quote what the command
-   returns, never invent one). A file you skimmed but did not read does not belong
-   here: this map is what later tells a refresh which docs went stale.
-4. **Emit `crosslink_tags`** — one tag body per OUTWARD boundary point in this
-   area's files, each per `schemas/crosslink-tag.md` §1, captured FROM SOURCE at the
-   moment you read it (the same knowledge as your `Contracts & shapes` rows — not
-   doc prose re-read later). Every tag is `<kind>:<name>`: a nameless tag has no
-   slug and therefore no file. If the area genuinely exposes nothing outward, return
-   the literal token `none` plus a one-line reason — an auditable claim, never
-   silence.
-5. **`keywords[]`** — 5–10 retrieval terms a future consumer would actually search
-   for. They feed `INDEX.md`; a doc nobody can match is a doc nobody reads.
-6. **Planning notes** — the core/isolated/risk hints the orchestrator uses for
-   scoring. Facts you observed, not adjectives.
-
-## Escalate rather than under-deliver
-
-Return `needs_context` with the reason when any of these is true, instead of
-producing a thinner doc:
-
-- a `delta_file` introduces an exported symbol the slice did not mention
-- a covered file named in `prior_doc` no longer exists (that is STRUCTURAL, and a
-  targeted refresh cannot re-anchor blind)
-- the area's real file count is far larger than `files[]` suggested
-
-The dispatcher will re-run the area at the deep tier. A `needs_context` here is
-cheap; a doc with invented anchors is permanent.
-
-## Return EXACTLY this (the orchestrator validates)
-- `area`
-- `status` — done | failed | partial | needs_context
-- `doc_body` — the filled sections (the orchestrator adds the header metadata)
-- `keywords[]` — 5–10 retrieval terms
-- `covered_files` — `{path: short-hash}` for every file you READ
-- `crosslink_tags` — REQUIRED: a list of tag bodies, or `none` + reason
-- `planning_notes` — core/isolated/risk hints
-- `failure_reason` — required when `failed`; else null
-- `progress` — `{percent, notes}` when `partial`; else null
-- `actual_model` — the model id quoted VERBATIM from your system prompt ("The
-  exact model ID is …"); NEVER infer from priors; `unknown` if no such line exists
-- `actual_effort` — the value of $CLAUDE_EFFORT (read via Bash at start)
-
-Malformed = failure (requeue): a missing `keywords[]` or `covered_files`, a missing
-`crosslink_tags` field (tags OR `none`+reason is mandatory — "found boundaries but
-wrote no tags" is structurally impossible), a contract section with an unanchored
-claim, or any write to the project. `needs_context` cap: 2 per area.
+---
+name: orc-wiki-scanner-sonnet-5-high
+description: >
+  ORC Wiki Scanner — claude-sonnet-5, high effort. Dispatched by orc-wiki per scan-task when the tier ladder resolves to LIGHT.
+model: claude-sonnet-5
+effort: high
+tools: Read, Glob, Grep, Bash
+---
+
+You are the ORC WIKI SCANNER, light tier. You scan exactly ONE coverage area and
+return the knowledge you read out of its files. You do not decide what to scan
+next, do not write the wiki, do not run `orc wiki sync`, and do not spawn other
+agents.
+
+**Light is about the SIZE of the delta, never about the standard of the work.**
+You are dispatched only when a doc already exists and its covered files moved by a
+small, no-new-surface amount — so the reading is bounded, not shallower. Every
+contract below is byte-identical to the deep scanner's. If the area turns out to be
+larger or more novel than the slice implies, return `needs_context` with what you
+found; do not quietly do a partial job at this tier.
+
+## Input slice (from the dispatcher)
+- `area` — the coverage area's slug (`orders`, `auth-conventions`, …)
+- `files[]` — the area's file list. Read them; this is your evidence base.
+- `doc_type` — `feature` | `reference`
+- `doc_contract` — `schemas/wiki-doc.md` v2 (section set + header fields)
+- `crosslink_kinds` — the kind catalog (`references/crosslink-kinds.md`, or at
+  minimum the kinds already in `crosslink_provided`). **REUSE an existing kind**
+  unless the boundary is genuinely a new sort — prefer it over a near-synonym
+  (`rest-endpoint`, never `route`). A synonym creates a SECOND file for one
+  boundary point, and a refresh may never bulk-delete the folder, so the
+  duplicate is permanent.
+- `prior_doc` — the existing doc for this area (always present at this tier)
+- `delta_files[]` — the covered files that actually changed since `prior_doc` was
+  scanned. Read these FIRST and most carefully; they are why you were dispatched.
+
+## Procedure
+1. **Read every file in `files[]`** before writing a word, starting with
+   `delta_files[]`. You may Glob/Grep within the area to follow a symbol, and run
+   read-only Bash (`git log -1`, `git hash-object`) — never a build, never a test,
+   never a write.
+2. **Write the doc body** per `doc_contract`: TL;DR, Key files, Public interface,
+   Contracts & shapes, and the area's remaining sections.
+   **Every factual claim in a contract section is ANCHORED to a real `file:line`
+   you read this session. An unanchored claim is OMITTED — never guessed, never
+   inferred from a name, and never carried over from `prior_doc` without re-reading
+   its anchor.** That last clause is the one this tier is most likely to violate and
+   the one that matters most here: `prior_doc` is a convenience for structure and
+   wording, never a source of facts. An anchor you did not re-read this session is
+   an anchor you cannot claim.
+3. **Record `covered_files`** — `{path: short-hash}` for every file you actually
+   read (`git hash-object <path>` is the short hash; quote what the command
+   returns, never invent one). A file you skimmed but did not read does not belong
+   here: this map is what later tells a refresh which docs went stale.
+4. **Emit `crosslink_tags`** — one tag body per OUTWARD boundary point in this
+   area's files, each per `schemas/crosslink-tag.md` §1, captured FROM SOURCE at the
+   moment you read it (the same knowledge as your `Contracts & shapes` rows — not
+   doc prose re-read later). Every tag is `<kind>:<name>`: a nameless tag has no
+   slug and therefore no file. If the area genuinely exposes nothing outward, return
+   the literal token `none` plus a one-line reason — an auditable claim, never
+   silence.
+5. **`keywords[]`** — 5–10 retrieval terms a future consumer would actually search
+   for. They feed `INDEX.md`; a doc nobody can match is a doc nobody reads.
+6. **Planning notes** — the core/isolated/risk hints the orchestrator uses for
+   scoring. Facts you observed, not adjectives.
+
+## Escalate rather than under-deliver
+
+Return `needs_context` with the reason when any of these is true, instead of
+producing a thinner doc:
+
+- a `delta_file` introduces an exported symbol the slice did not mention
+- a covered file named in `prior_doc` no longer exists (that is STRUCTURAL, and a
+  targeted refresh cannot re-anchor blind)
+- the area's real file count is far larger than `files[]` suggested
+
+The dispatcher will re-run the area at the deep tier. A `needs_context` here is
+cheap; a doc with invented anchors is permanent.
+
+## Return EXACTLY this (the orchestrator validates)
+- `area`
+- `status` — done | failed | partial | needs_context
+- `doc_body` — the filled sections (the orchestrator adds the header metadata)
+- `keywords[]` — 5–10 retrieval terms
+- `covered_files` — `{path: short-hash}` for every file you READ
+- `crosslink_tags` — REQUIRED: a list of tag bodies, or `none` + reason
+- `planning_notes` — core/isolated/risk hints
+- `failure_reason` — required when `failed`; else null
+- `progress` — `{percent, notes}` when `partial`; else null
+- `actual_model` — the model id quoted VERBATIM from your system prompt ("The
+  exact model ID is …"); NEVER infer from priors; `unknown` if no such line exists
+- `actual_effort` — the value of $CLAUDE_EFFORT (read via Bash at start)
+
+Malformed = failure (requeue): a missing `keywords[]` or `covered_files`, a missing
+`crosslink_tags` field (tags OR `none`+reason is mandatory — "found boundaries but
+wrote no tags" is structurally impossible), a contract section with an unanchored
+claim, or any write to the project. `needs_context` cap: 2 per area.

package/templates/commands/orc-analyze.md

@@ -1,21 +1,13 @@
----
-description: System Analyst — turn a doc (PDF/pasted) into a scope-bounded, code-grounded requirement report before planning
----
-
-Use the **orc-analyze** skill (System Analyst). Ingest the provided
-document, auto-detect and confirm its mode (prose vs audit), then **run the
-Standard-vs-Deep gate (Phase A′): offer the depth choice and wait for the
-answer** — default standard, deep = wider sweep + verify-every-claim + scouts,
-never auto-escalated. Tell the user they can preset the default with the
-zero-token CLI `orc config set default_analysis_depth deep` (the run still
-confirms). Then bound to the requested scope only (recognize other scopes only
-to exclude them), map each requirement/row to real files and verify against
-code with quote-anchored file:line evidence (absence claims carry the searches
-run), and challenge scope + accuracy issues — blocking ones one at a time,
-advisory ones in one batched round, all recorded. Write the human report +
-derived requirement spec into `analyst_report/{name}/`; the orchestrator
-spot-checks the evidence and lints the report↔spec derivation before offering
-to take it into a build or leave it as a report. The orchestrator dispatches
-the analysis to a subagent.
-
-Document / scope: $ARGUMENTS
+---
+description: System Analyst — turn a doc (PDF/pasted) into a scope-bounded, code-grounded requirement report before planning
+---
+
+Use the **orc-analyze** skill (System Analyst). It ingests the document, runs
+the Standard-vs-Deep gate and WAITS for your choice, bounds the work to the
+requested scope, and maps each requirement to real code with quote-anchored
+evidence. It writes the report and the derived spec into
+`orc/analyzer/{name}/` (a copy goes to `analyst_report/{name}/` only when you
+stop at the report). The orchestrator dispatches the analysis to a
+subagent.
+
+Document / scope: $ARGUMENTS

package/templates/commands/orc-fast.md

@@ -1,15 +1,10 @@
----
-description: Fastest lane — knowledge-gated single Sonnet 4.6 high executor; needs fresh wiki + pattern cache, else falls back to orc-mini
----
-
-Use the **orc-fast** skill. Start at Phase F0 preflight: verify the two
-prerequisites — a fresh project wiki (freshness computed from the orc-wiki
-manifest; STALE offers refresh-then-continue (recommended) / drop to orc-mini /
-continue anyway) AND a cached code-pattern for the request's language. Either
-missing → fall back to orc-mini with the request carried over (never stop the
-chat). Then: fit gate + micro-intake (one combined confirmation), one
-Sonnet 4.6 high executor with wiki page pointers + literal pattern injection,
-build+test smoke gate (one repair round, blocks ship on red), ship. No analyst,
-no planner, no review/verify. Orchestrator may run at Sonnet medium.
-
-Request: $ARGUMENTS
+---
+description: Fastest lane — knowledge-gated single Sonnet 4.6 high executor; needs fresh wiki + pattern cache, else falls back to orc-mini
+---
+
+Use the **orc-fast** skill. It needs a fresh project wiki AND a cached
+code-pattern for the request's language; either missing → it falls back to
+orc-mini with the request carried over. Then one Sonnet 4.6 high executor, a
+build+test smoke gate, and ship.
+
+Request: $ARGUMENTS

package/templates/commands/orc-poly.md

@@ -1,21 +1,12 @@
----
-description: Poly-repo planning — plan ONE change across 2+ repos, freeze the shared interface contract, split into one plan per repo (no drift)
----
-
-Run the **orc-poly** skill. You are in the HOST repo; paste the path of each
-PEER repo the change also touches (one or many — FE→BE, BE→another service's
-gRPC, …). orc-poly peeks at every repo's wiki + crosslink read-only (or, when a
-wiki is missing, asks you which folders/files to dig — never a blind scan),
-gathers the cross-repo context by asking questions until the shared boundary is
-pinned with no guesses, then writes a source-of-truth doc set
-(`poly-context.md`, `interface-contract.md`, `poly-spec.md`) into
-`poly-repo-implementation/<slug>/`. Each iteration it offers three choices: pass
-to orc-plan · stop & chat · add more context (another repo path or pasted
-knowledge). On "pass to orc-plan" the shared planner self-activates poly mode on
-the `orc-poly:spec` marker and splits ONE plan per repo — the HOST plan into
-this repo, each PEER plan written into that peer repo — every plan pinned to the
-frozen `interface-contract.md`. You then build each repo later, in its own
-session, with plain `/orc`, and no repo drifts. PEER source is READ-ONLY (the
-only peer write is its plan file); orc-poly never builds.
-
-Change / peer path(s): $ARGUMENTS
+---
+description: Poly-repo planning — plan ONE change across 2+ repos, freeze the shared interface contract, split into one plan per repo (no drift)
+---
+
+Run the **orc-poly** skill in the HOST repo; paste the path of each PEER repo.
+It asks until the shared boundary is pinned, then writes `poly-context.md`,
+`interface-contract.md` and `poly-spec.md` into
+`poly-repo-implementation/<slug>/`. The `orc-poly:spec` marker makes the planner
+split ONE plan per repo, each pinned to `interface-contract.md`. PEER source is
+read-only; it never builds.
+
+Change / peer path(s): $ARGUMENTS

package/templates/commands/orc-pr-driver.md

@@ -1,30 +1,11 @@
----
-description: Stacked-PR driver — execute a stack plan: one branch per layer, mandatory per-layer green gate, gh stack submit, then sync/rebase/bottom-up merge
----
-
-Run the **orc-pr-driver** skill. It takes an approved stack plan and makes the
-layers real: `gh stack init` → per layer `gh stack add`, only that layer's files,
-the **mandatory green-gate ladder** (build → tests → lint scoped to *that layer's
-own base* → the repo's own pre-commit hooks, never `--no-verify`) → commit →
-`gh stack submit`, PR bodies filled from the resolved template, then the ongoing
-`gh stack sync` / `rebase --upstack` / `modify` care and the bottom-up merge.
-
-**Three ways in — all read the same file** (`stacked-pr/<slug>/stack-plan.md`,
-probed with `orc pr stack status`):
-
-1. `/orc-pr-setup` planned it (the normal path),
-2. ORC's ship phase handed it over (`stacked-pr/<slug>/STACK-FROM.md`),
-3. **you wrote the plan yourself** — run `orc pr stack template` for the skeleton,
-   fill it in, and start here. No planner run required.
-
-It **refuses to run** — naming the exact missing field — on a plan with an
-unanswered uncertain seam, a missing ticket, a layer with no purpose or value
-class, a FOUNDATION layer that names no consumer, fewer than 2 layers, or a red
-build. It never fills a field in for you.
-
-When the change already exists in the worktree, your work is snapshotted to a
-scratch branch BEFORE any branch surgery, every layer is materialized from that
-snapshot file-by-file, and a completeness gate proves the union of the layers
-equals the snapshot exactly before anything is submitted.
-
-Slug / plan path / stack action: $ARGUMENTS
+---
+description: Stacked-PR driver — execute a stack plan: one branch per layer, mandatory per-layer green gate, gh stack submit, then sync/rebase/bottom-up merge
+---
+
+Run the **orc-pr-driver** skill. It executes `stacked-pr/<slug>/stack-plan.md`
+(probed with `orc pr stack status`; written by `/orc-pr-setup`, by you, or
+handed over as `STACK-FROM.md`): one branch per layer, a mandatory green gate
+per layer, then `gh stack submit` and the merge care. It refuses a plan with an
+open field or a red build, and never fills a field in for you.
+
+Slug / plan path / stack action: $ARGUMENTS

package/templates/commands/orc-pr-setup.md

@@ -1,31 +1,10 @@
----
-description: Stacked-PR planner — decide where the PR cut lines go, prove each layer stands alone, write stacked-pr/<slug>/stack-plan.md (plans only, never touches git)
----
-
-Run the **orc-pr-setup** skill. It plans a **stack of pull requests** for a
-change that is too big to review as one PR: ordered layers, each with a one-line
-purpose, a value class (`USER | OPERATOR | CONTRACT | FOUNDATION`), an explicit
-file list, measured LoC/file budgets and a dependency reason — written to
-`stacked-pr/<slug>/stack-plan.md`.
-
-It **plans only**: no branches, no commits, no pushes, no PRs. That is
-`/orc-pr-driver`.
-
-Two entry modes, auto-detected: **greenfield** (nothing written yet — a spec or
-ticket) and **orc-run** (the change already exists in the worktree, e.g. ORC just
-built it — the split is file-granular; hunk surgery is forbidden). A ticket
-number is required. The PR-description template is resolved from the ORC template,
-then the project (`.github/`, `docs/`), then a `CLAUDE.md` section — and if none
-exists you get three recommended options to pick from; declining them all means
-the stack is skipped and the change ships as one regular PR.
-
-**P0 hard gate:** every uncertain boundary STOPS the lane and asks you, one
-decision at a time, with the LoC/file/CI cost of each option and a recommendation
-— and records your answer under `## Decisions`. Same-tier files, shared helpers,
-refactor mixed with behavior change, ordering ambiguity and oversize atoms are all
-uncertain by definition. It never guesses a seam.
-
-When the plan is written it shows the layer table, states that nothing has been
-created yet, and hands off to `/orc-pr-driver`.
-
-Ticket / change / spec: $ARGUMENTS
+---
+description: Stacked-PR planner — decide where the PR cut lines go, prove each layer stands alone, write stacked-pr/<slug>/stack-plan.md (plans only, never touches git)
+---
+
+Run the **orc-pr-setup** skill. It plans a stack of pull requests for a change
+too big to review as one, and writes `stacked-pr/<slug>/stack-plan.md`. It plans
+only: no branches, commits, pushes or PRs — that is `/orc-pr-driver`. A ticket
+is required. Every uncertain boundary STOPS and asks you, one decision at a time.
+
+Ticket / change / spec: $ARGUMENTS

package/templates/commands/orc-route.md

@@ -1,41 +1,11 @@
----
-description: You have a plan — this says which lane should build it, with the numbers it decided from. Plan-only: it refuses a request in words rather than guess
----
-
-Use the **orc-route** skill. Zero agents, nothing is built.
-
-**It routes a PLAN, and only a plan** — pasted ORC planning-output, a
-`plan-<name>.md` path, or a saved `orc/planner/<name>/` checkpoint (the same
-definition `skills/_shared/phases/plan-handoff.md` already uses). A plan carries real
-numbers: tasks, files per task, dependencies, facets, scores. Routing from those
-is arithmetic; routing from a sentence is guessing, so a request in words gets a
-refusal and a pointer to `/orc-plan`, not a guess.
-
-It reads the plan plus ORC's deterministic probes (`orc wiki status`,
-`orc pattern status`, `orc gotcha status`, `orc diy status`) and answers:
-
-```
-Plan: merchant-notifications — 7 tasks, 3 waves, 14 files touched
-      top score 78, two tasks marked risky
-
-→ /orc          the plan has risky tasks and a task above 70;
-                review and verify are worth paying for here
-   runner-up    /orc-mini — about 3x faster, but it skips full review
-                and verification. Fine only if you will read the diff yourself.
-   not possible /orc-fast — needs a fresh wiki (yours is STALE) and this plan
-                is 7 tasks; that lane runs ONE task
-
-Start /orc now?  [yes / no]
-```
-
-Every runner-up says what choosing it costs you. Every impossible lane names the
-condition blocking it **and** how to fix it. Risk beats size: a small plan with a
-cited risk still earns the full lane.
-
-`/orc-plan` also offers this automatically after **Save & stop**, so you rarely
-need to type it.
-
-New to ORC and wondering which command to use at all? That is
-`orc onboarding first-run`, not this.
-
-Plan (paste it, or give a path): $ARGUMENTS
+---
+description: You have a plan — this says which lane should build it, with the numbers it decided from. Plan-only: it refuses a request in words rather than guess
+---
+
+Use the **orc-route** skill. Zero agents, nothing is built. It routes a PLAN
+only — the same definition `skills/_shared/phases/plan-handoff.md` uses. It reads
+the plan's tasks, files, deps, `facets` and scores plus ORC's probes, then names
+the lane, the runner-up and its cost, and each impossible lane with its fix. A
+request in words gets a pointer to `/orc-plan`, never a guess.
+
+Plan (paste it, or give a path): $ARGUMENTS

package/templates/commands/orc-test.md

@@ -2,65 +2,10 @@
 description: Run the tests against the real running system — happy path to security — and report only what was observed
 ---
 
-Use the **orc-test** skill. Standalone — no plan, no build, no code written into
-your project.
-
-Every other ORC lane reasons about your system. This one **runs it**:
-
-> **A test that ran is a FACT; a test that was written is an OPINION.**
-
-ORC already has a lane that WRITES tests and never runs them (Phase 6.5,
-`test-generator/`). This is the mirror image, and the two never mix: `/orc-test`
-writes nothing into your test tree and runs everything.
-
-**It never edits the system it is testing.** If the server will not come up, it
-prints exactly what it ran and the tail of the output, and hands back. You fix
-it, and re-run for free — the same shape as `/orc-challenge`, and for the same
-reason: a session that just fixed the code cannot be trusted to measure it.
-
-**It never reports a result it did not observe.** Three verdicts and no fourth:
-`pass` (observed, matched), `fail` (observed, did not match), and `unknown` —
-not observed. `unknown` keeps its slot in the report and never becomes a pass.
-A flake is recorded, never retried away: there is no retry count, because if the
-same case answers differently twice, *that instability is the finding*.
-
-One pass:
-
-1. **Target** — `orc test init <slug>` asks what it must not guess: back end or
-   front end, local or remote, the base URL. On a remote target it also requires
-   `--authorized "<who authorized this, and where it is recorded>"`, stored
-   verbatim and reprinted at the head of every report. ORC cannot verify
-   authorization and does not pretend to — it makes the assertion impossible to
-   skip. Frozen, and never asked again.
-2. **Surface** — free, deterministic: an OpenAPI or GraphQL spec on disk, the
-   same spec at the target, route extraction by framework fingerprint, FE router
-   config. Anything ambiguous comes back as `unresolved[]` and is never guessed.
-   The **code-vs-live diff** is a first-class output: routes that answer live and
-   exist in no source file are zombie APIs.
-3. **Flow** — it digs the repo for how a request reaches your endpoint: the
-   route registration, the middleware in order, the handler, what it writes, what
-   must be true first, which fields name an object, and the login flow itself.
-4. **Environment** (local only) — it brings the system up and waits for health.
-   Five states, one next action each.
-5. **Cases** — the CLI derives the bulk for free: equivalence partitions,
-   boundary values, method and content-type negatives, stateful create → read →
-   update → delete sequences. An agent fills only what a schema cannot know.
-6. **Run** — paced, capped, and fenced to the frozen origin. A 429 is a RESULT,
-   not an error: it means rate limiting works. Every case leaves its exact
-   request, its exact response and a reproducible `curl`, with every credential
-   redacted **before the bytes reach disk**.
-7. **Report** — `orc/orc-test/<slug>/REPORT.md`, written for someone who does
-   not read code.
-
-The security tier is a **closed set** mapped to the OWASP API Security Top 10
-(2023), and it demonstrates a CONDITION rather than an extraction — confirming
-an exploit is your decision on your authority. With one identity, BOLA and BFLA
-report `UNCHECKABLE`, which keeps its slot and never becomes a pass.
-
-**The run folder is never staged.** Evidence contains real response bodies from
-a real system. The lane offers you the one `.gitignore` line; it does not edit
-`.gitignore` itself.
-
-Read the state back any time without this lane: `orc test status <slug>`.
+Use the **orc-test** skill. Standalone: no plan, no build, no code written into
+your project. It RUNS the system; Phase 6.5 (`test-generator/`) writes tests and
+never runs them. It never edits the system under test, and it never reports a
+result it did not observe. The report is `orc/orc-test/<slug>/REPORT.md`; the
+run folder is never staged. Read the state back with `orc test status <slug>`.
 
 The slug to open or reopen (or nothing, and it will ask): $ARGUMENTS

package/templates/commands/orc-ultra.md

@@ -1,17 +1,17 @@
----
-description: Ultra lane — full orchestrator + Opus 5 xhigh advisor and three judgment gates, for ultra-complex work (maximum rigor, cost accepted)
----
-
-Use the **orc** skill with `ultra_mode: true` forced on for this run. Ultra is
-the maximum-rigor lane for complex/ultra-complex requests: everything the full
-pipeline does, PLUS an up-front Advisor brief with a batched clarification
-round (orc-advisor skill), three judgment gates — after analysis, after
-planning, and after verify (implementation fidelity + ultra-strict quality;
-orc-judge skill) — an assumption ledger, a deterministic traceability matrix,
-a blast-radius map, and an executor tier floor. Forced for the run (run-scoped,
-never written to the user's config): deep analyze (Phase A′ gate bypassed),
-pattern findings on, test authoring on, security review on. Ultra is costly by
-design — state it once, never prompt about cost mid-run. Follow the orc
-SKILL.md's ULTRA LANE section and references/ultra-mode.md exactly.
-
-Request: $ARGUMENTS
+---
+description: Ultra lane — full orchestrator + Opus 5.5 xhigh advisor and three judgment gates, for ultra-complex work (maximum rigor, cost accepted)
+---
+
+Use the **orc** skill with `ultra_mode: true` forced on for this run. Ultra is
+the maximum-rigor lane for complex/ultra-complex requests: everything the full
+pipeline does, PLUS an up-front Advisor brief with a batched clarification
+round (orc-advisor skill), three judgment gates — after analysis, after
+planning, and after verify (implementation fidelity + ultra-strict quality;
+orc-judge skill) — an assumption ledger, a deterministic traceability matrix,
+a blast-radius map, and an executor tier floor. Forced for the run (run-scoped,
+never written to the user's config): deep analyze (Phase A′ gate bypassed),
+pattern findings on, test authoring on, security review on. Ultra is costly by
+design — state it once, never prompt about cost mid-run. Follow the orc
+SKILL.md's ULTRA LANE section and references/ultra-mode.md exactly.
+
+Request: $ARGUMENTS

package/templates/commands/orc-verify.md

@@ -1,11 +1,11 @@
----
-description: Standalone verify — checks git-modified changes only, shows summary, Opus 5 medium
----
-
-Use the **orc-verify** skill independently (no orchestrator): verify
-only the git-modified changes in the working tree using Opus 5 medium effort,
-classify findings on the P0–P3 severity ladder (P0/P1 gate, P2/P3 advisory;
-every P0–P2 finding anchored with file:line + a verbatim quote, else it's
-auto-P3), and show the summary. Read-only — do not fix or commit.
-
-Optional focus: $ARGUMENTS
+---
+description: Standalone verify — checks git-modified changes only, shows summary, Opus 5.5 medium
+---
+
+Use the **orc-verify** skill independently (no orchestrator): verify
+only the git-modified changes in the working tree using Opus 5.5 medium effort,
+classify findings on the P0–P3 severity ladder (P0/P1 gate, P2/P3 advisory;
+every P0–P2 finding anchored with file:line + a verbatim quote, else it's
+auto-P3), and show the summary. Read-only — do not fix or commit.
+
+Optional focus: $ARGUMENTS