@azure-id/orc 1.9.1 → 2.0.2

package/templates/skills/orc/subskills/orc-testgen/SKILL.md

@@ -1,45 +1,34 @@
----
-name: orc-testgen
-description: >
-  Worker subskill for ORC's opt-in Phase 6.5 (Test Authoring). Fires when the user
-  opts into writing tests ("write test cases", "generate tests", "author test
-  cases for these changes"). Writes test cases as a deliverable — automated test
-  files, a manual TEST-PLAN.md, and (for HTTP/API backends) a Postman-importable
-  curl bundle. It NEVER runs tests and NEVER gates the ship; the user tests
-  manually. ALWAYS invoked as a spawned subagent by the orchestrator. Not for
-  direct user invocation.
----
-
-# orc-testgen
-
-One entry point: spawned via the Task tool with `subagent.md` framing + the
-slice, which points to `core.md` — the AUTHORITATIVE procedure + return contract;
-the summary below orients.
-
-## What the worker does (summary)
-
-1. Take the slice: changed surface (`actual_files`), the intent-spec's
-   definition-of-done (acceptance criteria), touched flows, constraints, detected stack.
-2. Write **automated test files** in the project's framework, covering the changed surface.
-3. Write a manual **TEST-PLAN.md** with two separated sections — "run the automated
-   suite" (exact CLI command) and "exercise the real running service" (manual/curl steps).
-4. For an HTTP/API backend, write a Postman-importable **test-cases.http** curl bundle
-   (env-var placeholders — never real secrets).
-5. Run NOTHING. Advisory `notes[]` may flag a case the code likely won't satisfy.
-
-The manual deliverables (TEST-PLAN.md + test-cases.http) are pinned to
-**`test-generator/<change-slug>/` at the project root** — a visible user
-deliverable, never inside `.claude/` or the run folder (see `core.md`).
-
-**Validation checkpoint before returning:** confirm each promised deliverable
-actually exists on disk **at the pinned path** (test files in the project's
-conventions; TEST-PLAN.md and — when the stack exposes HTTP — test-cases.http
-under `test-generator/<change-slug>/`) before emitting the return contract in `core.md`.
-
-Fixed model: `orc-test-author-opus-5-med` (Opus 5 medium — authoring good
-integration tests is a judgment task). Opt-in: the orchestrator dispatches this
-only when the user accepts the offer, defaulted from `config.generate_tests`. The
-full lane runs it as Phase 6.5 (after Verify, confirmed at intake); **orc-mini
-also offers it** as an end-of-run ask (only on a GREEN smoke gate). Either lane,
-it never runs tests and never gates the ship. orc-mini still skips full
-review/verify.
+---
+name: orc-testgen
+description: >
+  Worker subskill for ORC's opt-in Phase 6.5 (Test Authoring). Fires when the user
+  opts into writing tests ("write test cases", "generate tests", "author test
+  cases for these changes"). Writes test cases as a deliverable — automated test
+  files, a manual TEST-PLAN.md, and (for HTTP/API backends) a Postman-importable
+  curl bundle. It NEVER runs tests and NEVER gates the ship; the user tests
+  manually. ALWAYS invoked as a spawned subagent by the orchestrator. Not for
+  direct user invocation.
+---
+
+# orc-testgen
+
+A pointer. The orchestrator spawns `orc-test-author-opus-5-med` via the Task
+tool, prepending `subagent.md` framing + the input slice. It WRITES test cases;
+it never runs them and never gates the ship.
+
+- **Input slice** (the orchestrator builds it): `core.md`.
+- **Procedure + return contract** (the ONE source): the agent file,
+  `.claude/agents/orc-test-author-opus-5-med.md`. The manual deliverables
+  (TEST-PLAN.md + test-cases.http) are pinned to
+  **`test-generator/<change-slug>/` at the project root** — a visible user
+  deliverable, never inside `.claude/` or the run folder.
+- **Validator** (the caller checks every return against it):
+  `../../../_shared/return-validation.md`.
+
+Fixed model: `orc-test-author-opus-5-med` (Opus 5.5 medium — authoring good
+integration tests is a judgment task). Opt-in: the orchestrator dispatches this
+only when the user accepts the offer, defaulted from `config.generate_tests`. The
+full lane runs it as Phase 6.5 (after Verify, confirmed at intake); **orc-mini
+also offers it** as an end-of-run ask (only on a GREEN smoke gate). Either lane,
+it never runs tests and never gates the ship. orc-mini still skips full
+review/verify.

package/templates/skills/orc/subskills/orc-testgen/core.md

@@ -1,59 +1,20 @@
-# orc-testgen — Core (mode-neutral)
-
-A procedure specification: inputs, steps, outputs. Executed by a spawned
-`orc-test-author-opus-5-med` subagent; the orchestrator never runs this
-itself. **Authoring only — RUN NOTHING, GATE NOTHING.** The user tests manually.
-
-## Input slice (you receive exactly this)
-
-- changed_files[]        — the surface the change touched (from the run's actual_files)
-- acceptance_criteria[]  — the intent-spec's definition-of-done (the "new behaviour")
-- touched_flows[]        — user journeys through the changed code (may be empty)
-- constraints[]          — intent-spec hard rules
-- stack                  — {language, test_framework, is_http_api}; detect if absent
-- test_types[]           — subset of {new_behaviour, flow, change, regression}; default all
-- output_conventions     — where tests live in this repo
-
-## Procedure
-
-1. Detect stack: test framework + conventions, and whether the project exposes
-   HTTP endpoints (→ `is_http_api`).
-2. Derive a **test matrix** from changed_files + acceptance_criteria + flows —
-   one row per case {id, type, target, asserts, external_deps}. Bound regression
-   to the diff's blast radius; never test the whole app.
-3. Author **automated test files** in the project's framework/conventions where
-   feasible. Match existing test style. These stay in the project's own test
-   conventions (`output_conventions`) — do NOT move them.
-4. **Pin the manual-QA output folder.** The two manual deliverables below are
-   USER deliverables, not run state — write BOTH to
-   **`test-generator/<change-slug>/` at the PROJECT ROOT** (create the folder if
-   absent). `<change-slug>` = the run's existing kebab-case run-folder slug (e.g.
-   `post-users`). NEVER write them inside `.claude/`, and NEVER inside the run
-   folder — a hidden path is invisible for self-QA.
-5. Write **`test-generator/<change-slug>/TEST-PLAN.md`** (manual cases: scenario,
-   setup, steps, expected) with two CLEARLY SEPARATED sections:
-   - "Run the automated test suite" — the exact CLI command(s), pasted.
-   - "Exercise the real running service" — manual steps / curl.
-6. If `is_http_api`: write **`test-generator/<change-slug>/test-cases.http`** —
-   one Postman-importable `curl` per endpoint/flow (env-var placeholders for base
-   URL + auth; NEVER real secrets). Reference it from TEST-PLAN.md.
-7. Advisory only: note (do not gate) any case the code likely won't satisfy.
-
-## Return contract (emit EXACTLY this; the caller validates)
-
-- test_matrix[]         — the rows above (or counts by type)
-- files_authored[]      — automated test files created/updated
-- test_plan_path        — path to TEST-PLAN.md; MUST be inside
-                          `test-generator/<change-slug>/` (any other location is
-                          a malformed return)
-- curl_bundle_path      — path to test-cases.http (also inside
-                          `test-generator/<change-slug>/`), or null (non-API projects)
-- run_command           — exact CLI command(s) to run the authored tests
-- notes[]               — advisory gaps noticed while authoring (non-blocking); else []
-- actual_model          — model id quoted VERBATIM from your system prompt ("The
-                          exact model ID is …"); NEVER inferred; `unknown` if absent
-- actual_effort         — the value of $CLAUDE_EFFORT (read via Bash)
-- failure_reason        — required if you could not author; else null
-
-Malformed returns are treated as failure by the caller. Never run tests; never
-spawn subagents.
+# orc-testgen — Core (the input slice)
+
+The INPUT SLICE the orchestrator builds for ONE `orc-test-author-opus-5-med`
+dispatch. The procedure and the return contract live in ONE place: the agent
+file, `.claude/agents/orc-test-author-opus-5-med.md`. The orchestrator never
+runs this itself. **Authoring only — RUN NOTHING, GATE NOTHING.** The user tests manually.
+
+## Input slice (you receive exactly this)
+
+- changed_files[]        — the surface the change touched (from the run's actual_files)
+- acceptance_criteria[]  — the intent-spec's definition-of-done (the "new behaviour")
+- touched_flows[]        — user journeys through the changed code (may be empty)
+- constraints[]          — intent-spec hard rules
+- stack                  — {language, test_framework, is_http_api}; detect if absent
+- test_types[]           — subset of {new_behaviour, flow, change, regression}; default all
+- output_conventions     — where tests live in this repo
+
+The manual deliverables go to `test-generator/<change-slug>/` at the PROJECT
+ROOT (`<change-slug>` = the run's kebab-case run-folder slug). Malformed returns
+are treated as failure by the caller.

package/templates/skills/orc/subskills/orc-testgen/subagent.md

@@ -1,7 +1,7 @@
-# orc-testgen — Subagent wrapper (orchestrator prepends at spawn)
-
-You are an isolated test-authoring worker. You WRITE test cases from the slice
-below; you never run them, never fix code, never gate the ship. Make manual
-testing easy for the user. Emit the return structure from core.md and STOP.
-
-[Orchestrator: append the input slice here at spawn time.]
+# orc-testgen — Subagent wrapper (orchestrator prepends at spawn)
+
+You are an isolated test-authoring worker. You WRITE test cases from the slice
+below; you never run them, never fix code, never gate the ship. Make manual
+testing easy for the user. Emit the return structure your agent file defines and STOP.
+
+[Orchestrator: append the input slice here at spawn time.]

package/templates/skills/orc-advisor/SKILL.md

@@ -1,60 +1,56 @@
----
-name: orc-advisor
-description: >
-  Pre-analysis Advisor for the ORC ultra lane. Runs ONCE at ultra Phase U0
-  (after intake, before the analyst) to produce a code-grounded advisory
-  brief: domain risks, alternatives, a mandatory security-risk section, a
-  request-specific rubric the ultra judges score against, open questions
-  (relayed to the user in one batch), and the seed of the run's assumption
-  ledger. Dispatched only from /orc-ultra — no slash command of its own, never
-  in orc or orc-mini. The orchestrator dispatches the advisor subagent — it
-  never advises itself.
----
-
-# ORC-ADVISOR (ultra-lane advisory brief)
-
-Ultra-complex tasks fail on wrong interpretation, silent assumptions, and
-generic quality bars. The Advisor front-loads the fix: one max-effort pass
-that frames the request against the REAL codebase and hands every downstream
-role — analyst, planner, judges, executors — the same request-specific brief.
-
-Ultra lane ONLY. There is no `/orc-advisor` command; the orchestrator
-dispatches `orc-advisor-opus-5-xhigh` at Phase U0 of an `/orc-ultra` run.
-Cost is accepted by definition of the lane — no consent prompt.
-
-## Hard rules
-
-1. **The orchestrator never advises — it spawns.** Dispatch
-   `orc-advisor-opus-5-xhigh` with the slice below; the advisor writes the
-   brief; the orchestrator relays and injects.
-2. **The advisor is read-only on the project** (Read/Glob/Grep + Bash for
-   git introspection). It never edits code, never spawns subagents.
-3. **One dispatch per run.** The advisor is never re-dispatched for
-   revisions — post-brief quality is the judges' job.
-4. **The brief is injected LITERALLY** (never a file pointer) into the
-   analyst slice, the planner slice, all three judge slices, and — as
-   advisory notes — the executor slices.
-5. **The security section may not be skipped.** "No security surface" is a
-   legitimate conclusion but must be stated with reasoning.
-
-## Dispatch slice (orchestrator → advisor)
-
-- The user's request verbatim (plus the doc path when one exists).
-- The run-folder path for `advisory-brief.md`.
-- Detected stack summary (from intake — never re-detected).
-
-## Brief contents (see the agent file for the full section spec)
-
-Risks & pitfalls (anchored) · alternatives + trade-offs · security risks
-(mandatory) · the three-part RUBRIC (correct analysis / correct plan /
-faithful implementation) · open questions with proposed defaults · seed
-assumption-ledger entries.
-
-## Return contract
-
-`brief_path`, `open_questions[]`, `assumptions[]`, `actual_model` (verbatim
-from the agent's system-prompt model-id line), `actual_effort`
-($CLAUDE_EFFORT). The orchestrator validates the return, emits the `ADVISE`
-trace line when logging, relays the open questions to the user in ONE batched
-round, folds the answers into the intent-spec, and records unanswered
-defaults as UNCONFIRMED in the assumption ledger.
+---
+name: orc-advisor
+description: >
+  Internal to /orc-ultra: the pre-analysis Advisor. Runs ONCE at Phase U0 and
+  writes the advisory brief, the security-risk section and the rubric the ultra
+  judges score against. No slash command of its own.
+disable-model-invocation: true
+---
+
+# ORC-ADVISOR (ultra-lane advisory brief)
+
+Ultra-complex tasks fail on wrong interpretation, silent assumptions, and
+generic quality bars. The Advisor front-loads the fix: one max-effort pass
+that frames the request against the REAL codebase and hands every downstream
+role — analyst, planner, judges, executors — the same request-specific brief.
+
+Ultra lane ONLY. There is no `/orc-advisor` command; the orchestrator
+dispatches `orc-advisor-opus-5-xhigh` at Phase U0 of an `/orc-ultra` run.
+Cost is accepted by definition of the lane — no consent prompt.
+
+## Hard rules
+
+1. **The orchestrator never advises — it spawns.** Dispatch
+   `orc-advisor-opus-5-xhigh` with the slice below; the advisor writes the
+   brief; the orchestrator relays and injects.
+2. **The advisor is read-only on the project** (Read/Glob/Grep + Bash for
+   git introspection). It never edits code, never spawns subagents.
+3. **One dispatch per run.** The advisor is never re-dispatched for
+   revisions — post-brief quality is the judges' job.
+4. **The brief is injected LITERALLY** (never a file pointer) into the
+   analyst slice, the planner slice, all three judge slices, and — as
+   advisory notes — the executor slices.
+5. **The security section may not be skipped.** "No security surface" is a
+   legitimate conclusion but must be stated with reasoning.
+
+## Dispatch slice (orchestrator → advisor)
+
+- The user's request verbatim (plus the doc path when one exists).
+- The run-folder path for `advisory-brief.md`.
+- Detected stack summary (from intake — never re-detected).
+
+## Brief contents (see the agent file for the full section spec)
+
+Risks & pitfalls (anchored) · alternatives + trade-offs · security risks
+(mandatory) · the three-part RUBRIC (correct analysis / correct plan /
+faithful implementation) · open questions with proposed defaults · seed
+assumption-ledger entries.
+
+## Return contract
+
+`brief_path`, `open_questions[]`, `assumptions[]`, `actual_model` (verbatim
+from the agent's system-prompt model-id line), `actual_effort`
+($CLAUDE_EFFORT). The orchestrator validates the return, emits the `ADVISE`
+trace line when logging, relays the open questions to the user in ONE batched
+round, folds the answers into the intent-spec, and records unanswered
+defaults as UNCONFIRMED in the assumption ledger.

package/templates/skills/orc-analyze/SKILL.md

@@ -2,22 +2,17 @@
 name: orc-analyze
 description: >
   System Analyst for ORC. Use for "/orc-analyze", "analyze this doc for scope
-  X", or "analyze this requirement against the code" — turning a requirement (a
-  document, PDF by path or pasted, OR a plain-language request) into a precise,
-  code-grounded requirement set BEFORE any planning. Bounds the deliverable to
-  exactly the asked scope, pulls related adjacent scopes in only as anchored
-  "do not build" context, maps each requirement to real files with
-  quote-anchored file:line evidence, and challenges the user with recommended
-  options. Opt-in DEEP mode adds a scout-driven code sweep, verify-every-claim,
-  and alternatives + risks. Also auto-triggers inside /orc on a doc or
-  ambiguous requirement. The orchestrator dispatches this to a subagent — it
-  never analyzes itself.
+  X", or "analyze this requirement against the code". Turns a document (PDF by
+  path or pasted) or a plain-language request into a scope-bounded,
+  code-grounded requirement set with quote-anchored file:line evidence BEFORE
+  any planning, and challenges the user with recommended options. Opt-in DEEP
+  mode adds a scout-driven code sweep. Also auto-triggers inside /orc on a doc.
 ---
 
 # ORC-ANALYZE (System Analyst)
 
 The orchestrator stays on top and **dispatches a System Analyst subagent
-(Opus 5, high)** to do this work — it never analyzes itself, keeping its own
+(Opus 5.5, high)** to do this work — it never analyzes itself, keeping its own
 context lean. This skill defines what that subagent does, how the orchestrator
 runs the standard/deep gate + scout dispatch, and how it relays challenges and
 branches on the result.
@@ -33,7 +28,7 @@ the user meant.
 ## Hard rules
 
 1. **Dispatched, not self-run.** The orchestrator coordinates; the Analyst
-   subagent (Opus 5 high) reads the source, reads the code, and reconciles.
+   subagent (Opus 5.5 high) reads the source, reads the code, and reconciles.
 2. **Evidence-or-mark (never hallucinate) — quote-anchored.** Every
    requirement interpretation and code claim carries `file:line — "verbatim
    snippet"` evidence (≤1 line, quoted not paraphrased; no quote →
@@ -79,24 +74,20 @@ the user meant.
 
 ## Behavior trace (always on)
 
-`../_shared/phases/trace.md` (`core`, at run start; `orc lane phases` names
-the file and the layers). Lane token `analyze`, tier **Single-dispatch** —
-exactly ONE end-of-run packet, dispatched solo before `.current` is deleted.
-At run start write `log_dir/.current` = `run-analyze-<slug>-<DDMMYY>-<HHMMSS>.txt` AND
-`touch the trace file` of that name in the SAME step.
-Nothing else about the protocol is restated here; a phase that ends with
-`zero new trace lines is a protocol violation`.
+`../_shared/phases/trace.md` (`core`, at run start; `orc lane phases orc-analyze --json` →
+`trace_grammar` gives the verbs). Lane token `analyze`, tier
+**Single-dispatch**. At run start write `log_dir/.current` =
+`run-analyze-<slug>-<DDMMYY>-<HHMMSS>.txt` AND `touch the trace file` of that name
+in the SAME step. A phase that ends with `zero new trace lines is a protocol violation`.
 
 `context-combiner` is a PHASE of this run, not a lane: its `DISPATCH`/`RETURN`,
 its Phase D verdicts and its conservation-gate result fold into THIS packet.
 
 ## Phases
 
-`orc lane phases orc-analyze --json` is this lane's pipeline: the ordered list, where
-each phase lives, and how much of it to read. **The CLI owns the order** — never
-derive it from the headings below, and never renumber or rename one without the
-manifest, because a `read: section` pointer names a HEADING and a renamed heading
-is a pointer into nothing.
+`orc lane phases orc-analyze --json` is this lane's pipeline. **The CLI owns the order**:
+never derive it from the headings below, and never rename or renumber one
+without the manifest (`../_shared/lane-contract.md` §Phases).
 
 ## Phase A — Ingest & detect source mode
 
@@ -133,12 +124,11 @@ offer wording, the auto-consume back here: `references/thin-input.md`.
 
 ## Phase A′ — Standard vs Deep gate (default STANDARD)
 
-Before reconciliation, offer the depth choice (config `default_analysis_depth`
-presets the default; the run still confirms): deep = wider sweep, verify every
-claim, more questions, alternatives with trade-offs, noticeably more tokens;
-standard = faster, verifies the stated floor (hard rule 4). Mention the
-zero-token default switch `orc config set default_analysis_depth deep`. Deep
-requires explicit consent — never auto-escalates — and is **two-pass with
+Before reconciliation, offer the depth choice (H `any.analysis.depth`). Config
+`default_analysis_depth` presets it; mention the free switch `orc config set
+default_analysis_depth deep`. Deep = wider sweep, verify every claim, more
+questions, alternatives, more tokens; standard = faster, the hard rule 4 floor.
+Deep needs explicit consent EVERY run (never auto) and is **two-pass with
 scouts**: load `references/deep-mode.md`. Standard is single-pass.
 
 ## Phase B — Bound scope
@@ -216,44 +206,18 @@ another RELATED doc (multi-analyze loop → combiner once 2+ related analyses
 exist). Menu rules, relatedness gate, combiner handling:
 `references/branching.md`.
 
-## Mini variant
-
-For the fast lane, `orc-analyze-mini` (Sonnet 5 high) does a shallower version
-of the same flow: doc-optional intake, the same evidence-or-mark + floor (a)+(b)
-+ triage rules — but **no deep mode and no scouts** (always single-pass), and
-concrete escalation thresholds to the full analyst. Used by orc-mini. Same
-artifacts, same output contract; trimmed depth. See that skill.
-
-## Config
-
-**ONE resolver, and it is not you:** `orc lane config orc-analyze --json`. Obey
-`effective`, print every line in `announce[]` VERBATIM at preflight, and honour
-`stops[]` before wave 1. Never re-derive a value, a precedence or an inertness
-from `.claude/orc.config.yaml` — a key this lane does not read is not in the
-answer, and a key another key shadows comes back already marked. Exit ≠ 0 → say
-the CLI is unavailable and fall back to `../_shared/config-precedence.md`'s
-documented defaults, out loud. Priorities and families:
-`../_shared/config-precedence.md`.
-
-## Calls
-
-**ONE catalogue, and it is not you:** `orc lane calls orc-analyze --json` names every
-CLI call this lane makes, each with its exit-code contract, its cost, when to run
-it, and what an EMPTY answer means. Never invent a spelling, never re-word an
-exit code, and never re-derive a state word — the CLI's state words are the only
-state words, and **an exit code is an ANSWER wherever that contract says so, not
-a failure**. A call the answer does not name is a call this lane does not make.
-Exit ≠ 0 from the catalogue itself → say the CLI is unavailable and name the
-command you are about to run, out loud, before running it.
-
-## Rules — the anti-slop card (`../_shared/phases/rules.md`)
-
-`orc rules slice --lane orc-analyze --json` is the ONLY assembler; never build
-the card here. It rides under the house rules and above the task —
-**house rules > your project's rules > ORC's own packs** — and its `line` prints
-VERBATIM at preflight. Returns gain `rules_applied[]`, `rules_conflicts[]` (a gap,
-never a silent choice) and `rules_overridden[]`.
+## Lane contract (`../_shared/lane-contract.md` — read it ONLY when a call exits ≠ 0)
+
+- **Calls:** `orc lane calls orc-analyze --json` names every call and its exit codes.
+  **An exit code is an ANSWER where it says so, not a failure.** Make no other call.
+- **Config:** `orc lane config orc-analyze --json`. Obey `effective`, print every line
+  in `announce[]` VERBATIM at preflight, and honour `stops[]` before wave 1.
+  Never merge `.claude/orc.config.yaml` yourself (`../_shared/config-precedence.md`).
+- **Habits:** `habits{}` in that answer → `../_shared/habits.md`; else ignore `(H …)`.
+- **Rules:** `orc rules slice --lane orc-analyze --json` is the ONLY assembler
+  (`../_shared/phases/rules.md`). Its `line` prints VERBATIM at preflight.
+
 ## Waiting mid-run (`/orc-wait`)
 
 Canonical: `../_shared/wait.md`. **`a lane that waits without a hand-back` has broken this contract.**
-Checkpoint **full** · safe point **after the analyst returns**. `soft` FORCES that checkpoint and does NOT stop if the write fails; `hard` skips it and can lose an in-flight return. Never begin a wait between a dispatch and its validated return, or before the smoke gate has reported.
+Checkpoint **full** · safe point **after the analyst returns**.

package/templates/skills/orc-analyze/examples/analyze-mock.md

@@ -1,42 +1,42 @@
-# Example — Annotated System Analysis (dry run)
-
-A: = analyst (Opus 5 high) · U: = user. Nothing real. Bounds the DELIVERABLE to
-the asked scope; every claim is grounded with file:line evidence OR marked an
-assumption and turned into a question. The orchestrator dispatches this — it never
-analyzes itself.
-
-U: /orc-analyze  security-audit.pdf — implement the AUTH findings only
-
-## Mode + scope
-A: [reads the PDF] Mode: AUDIT (structured findings sheet). Scope X = auth.
-   Payments and logging findings exist in the doc — recognized only to EXCLUDE them
-   (they never become tasks). Depth gate: standard or deep? (default standard)
-U: standard
-
-## Ground against real code (evidence-or-mark)
-A: Finding A1 "login lacks rate-limit" → CONFIRMED, auth/login.py:33 has no limiter.
-   Finding A2 "JWT uses HS256, should be RS256" → auth/token.py:12 uses HS256 ✓ real.
-   Finding A3 "missing UUID check on /reset" → ⚠ STALE: reset.py:20 renamed that field
-     to `token_id` and DOES validate it. Marking A3 UNVERIFIED → question.
-
-## Challenge (recommended options, one at a time)
-A: A3 looks stale against the code. Options:
-   (a) Drop A3 — code already validates (RECOMMENDED: evidence at reset.py:20).
-   (b) Keep A3 — you know of a gap the diff doesn't show.
-U: (a) drop it
-
-## Adjacent context (anchored, do-not-build)
-A: A2's RS256 switch depends on the key-loading in config/keys.py — captured as
-   "Additional context (do not build)", anchored to A2, so the build respects it
-   without treating it as a task.
-
-## Artifacts + branch
-A: Writes orc/analyzer/auth-audit/report.md (Evidence column + Assumptions & Open
-   Questions) + derived requirement-spec.md. handoff_ready: true.
-   Keep as report, or take into build?
-U: take into build   → hands both files to /orc, which plans from the spec (no
-   re-questioning of scope — it's already settled).
-
-## (Phase F) Another related doc?
-A: You could analyze a related doc in this same scope; once 2+ related analyses
-   exist I'll offer context-combiner to merge them into one spec. [not needed here]
+# Example — Annotated System Analysis (dry run)
+
+A: = analyst (Opus 5.5 high) · U: = user. Nothing real. Bounds the DELIVERABLE to
+the asked scope; every claim is grounded with file:line evidence OR marked an
+assumption and turned into a question. The orchestrator dispatches this — it never
+analyzes itself.
+
+U: /orc-analyze  security-audit.pdf — implement the AUTH findings only
+
+## Mode + scope
+A: [reads the PDF] Mode: AUDIT (structured findings sheet). Scope X = auth.
+   Payments and logging findings exist in the doc — recognized only to EXCLUDE them
+   (they never become tasks). Depth gate: standard or deep? (default standard)
+U: standard
+
+## Ground against real code (evidence-or-mark)
+A: Finding A1 "login lacks rate-limit" → CONFIRMED, auth/login.py:33 has no limiter.
+   Finding A2 "JWT uses HS256, should be RS256" → auth/token.py:12 uses HS256 ✓ real.
+   Finding A3 "missing UUID check on /reset" → ⚠ STALE: reset.py:20 renamed that field
+     to `token_id` and DOES validate it. Marking A3 UNVERIFIED → question.
+
+## Challenge (recommended options, one at a time)
+A: A3 looks stale against the code. Options:
+   (a) Drop A3 — code already validates (RECOMMENDED: evidence at reset.py:20).
+   (b) Keep A3 — you know of a gap the diff doesn't show.
+U: (a) drop it
+
+## Adjacent context (anchored, do-not-build)
+A: A2's RS256 switch depends on the key-loading in config/keys.py — captured as
+   "Additional context (do not build)", anchored to A2, so the build respects it
+   without treating it as a task.
+
+## Artifacts + branch
+A: Writes orc/analyzer/auth-audit/report.md (Evidence column + Assumptions & Open
+   Questions) + derived requirement-spec.md. handoff_ready: true.
+   Keep as report, or take into build?
+U: take into build   → hands both files to /orc, which plans from the spec (no
+   re-questioning of scope — it's already settled).
+
+## (Phase F) Another related doc?
+A: You could analyze a related doc in this same scope; once 2+ related analyses
+   exist I'll offer context-combiner to merge them into one spec. [not needed here]