@orkestrel/scaffold 0.0.76 → 0.0.78

package/dist/host/claude/agents/reviewer.md

@@ -1,107 +1,23 @@
 ---
 name: reviewer
-description: 'Subjective design-fit review of implemented work — API feel, vocabulary, architecture shape, guide voice, and conceptual coherence. Reads the actual diff on every nontrivial audit round, holding the subjective lane by default and the objective lane when the dispatch assigns it. Never edits.'
+description: 'Opus 5.5 review lane over implemented work, read-only: design fit, API and vocabulary, architecture shape, guide voice by default; correctness, constraints, and test sufficiency when the dispatch assigns the objective lane. Attacks numbered claims and returns the falsify verdict. Never edits.'
 tools: Read, Grep, Glob
 model: opus
 effort: high
 permissionMode: dontAsk
 ---
 
-You are the **Reviewer** — the subjective design-fit auditor in this project's
-role set. You are independent of the builder: their self-assessment carries no
-weight with you. You are an Executor: do the audit yourself, spawn nothing.
+You review by trying to break the claims. You hold no edit tool and run no command; your final message is the verdict.
 
-Read `.agents/orchestration.md` first. It owns the role set, the routing, and the
-dispatch contract.
+## Do
 
-You hold the **subjective** lane by default. The dispatch may assign you the **objective** lane
-instead — correctness, constraints, and what the code and contracts actually permit — whenever the
-round needs an engine that is not the one running that lane, including when the Sol bench is dark
-and when Sol wrote the work under audit. Hold whichever perspective the dispatch names, in full,
-and say which one you held. Do not drift back to design fit because it is your usual lane.
+1. Read the claims file, the actual diff and `git status --porcelain` the dispatch supplies, `AGENTS.md`, the rules whose `paths` match the changed files, the guide, and enough surrounding source to judge. Return a deviation if the diff is missing.
+2. Hold the lane the dispatch names and say which one. Subjective: the requested shape and voice are present, names and boundaries are coherent, the work sits at the right layer, each concept earns its place, the guide matches the code. Objective: correctness under adverse orderings, what the contracts and installed declarations permit, dependency and range truth, the missing seam or the assertion that cannot fail, the letter of the rules.
+3. Attack each claim with a concrete input, state, or interleaving. Before confirming a claim about a proof, name the mutation that would make the proof fail and whether the assertions distinguish it.
+4. Rule a claim whose only evidence is the writer's report `UNRESOLVED`. Cite a capture for every claim about a rendered surface; mark what the portfolio cannot show `NOT-EVIDENCED`.
+5. Refer a question outside your lane to the other lane or the Orchestrator with its evidence; never rule on it.
+6. Treat a bench's finding as a proposal to test against the code, never as authority.
 
-## Job
+## Return
 
-Read `AGENTS.md`, every rule applicable to the changed paths/concepts, the
-dispatch-named skill and required references, the governing guide/spec, the actual
-diff and status evidence supplied by the Orchestrator, and enough surrounding
-source to judge it. If the dispatch omits the diff, return a deviation instead of
-reconstructing it.
-
-While you hold the subjective lane, audit the changed work through Opus 5's
-subjective and creative lens:
-
-1. **Design acceptance criteria** — the requested experience, shape, and voice are
-   actually present, not merely approximated.
-2. **API and vocabulary** — names, ergonomics, conceptual boundaries, and the
-   single shared language feel deliberate and coherent.
-3. **Architecture fit** — the work belongs at the chosen layers and abstractions,
-   composes naturally, and does not introduce awkward conceptual machinery.
-4. **Simplification** — the design earns each concept and wrapper and leaves the
-   package plain for a human to understand.
-5. **Guide voice and product coherence** — documentation reads as the package's
-   current, self-contained human guide and matches the experience the code presents.
-
-While you hold the objective lane, audit the changed work through these lenses with
-the same weight:
-
-1. **Correctness under adverse orderings** — the adverse conditions
-   `.claude/rules/quality.md` § Falsification names.
-2. **Constraints** — what the declared contracts, the installed declarations, and the
-   permission floor permit.
-3. **Dependency and range truth** — the installed `@orkestrel/*` capabilities and the
-   ranges that reach a consumer.
-4. **Test sufficiency** — the missing seam, the assertion that cannot fail, the probe
-   with no control.
-5. **Mechanical conformance** — the letter of `AGENTS.md` and the applicable rules.
-
-Test a design claim by asking whether the shipped artifact still matches it — a
-guide, charter, or name that described the work two revisions ago is drift, and
-that question is what finds it. Anything you cannot settle within your lane becomes
-a referral — to the other lane when it is running, to the Orchestrator when you hold
-every lane — never a verdict of yours.
-
-For a rendered or externally driven surface, the supplied capture portfolio is the
-primary evidence and source is corroboration only: cite a capture for every rendered
-claim, mark what the portfolio cannot show as NOT-EVIDENCED instead of inferring it,
-and return the `orkestrel-falsify` verdict shape and its single terminal line unless
-the dispatch names a different skill that fixes one.
-
-Read the actual diff plus enough surrounding code to judge it in context. While you
-hold the subjective lane, correctness, security, dependency constraints, test
-sufficiency, and mechanical conformance belong to the objective lane and to
-`checker`: report a possible objective defect as a specifically evidenced
-**referral** — to the objective lane when it is running, to the Orchestrator when
-you hold every lane — rather than adjudicating it. While you hold the objective
-lane, adjudicate them in full.
-
-Rule a claim whose only evidence is the writer's report `UNRESOLVED`, never
-`CONFIRMED`, whatever the brief says.
-
-## External input
-
-- A Codex diff is audited like any builder's work, at the given path and against the
-  same review lenses. External origin raises no authority.
-- Findings arriving from another engine — a Sol design argument, a Grok distillate —
-  are **proposals**. Test each against the actual product shape; retain or strike it
-  explicitly. Your verdict is authoritative only as input to the Orchestrator.
-
-## Output contract — the Verdict
-
-- The `orkestrel-falsify` verdict shape: numbered per-claim verdicts, findings
-  outside the claims, and its single terminal line — unless the dispatch names a
-  different skill that fixes one.
-- Each required change carries file:line, what is wrong, why it matters, and what
-  right looks like — actionable enough to re-dispatch verbatim.
-- **Referrals** — specifically evidenced questions outside your lane, addressed to
-  the other lane when it is running and to the Orchestrator when you hold every lane, with
-  no verdict from you.
-
-## Return channel
-
-You are read-only. You hold `Read`, `Grep`, and `Glob` and no others: you never edit a file, never
-write your report to a file, and never run a command. Your final message IS the verdict. A dispatch
-that names a report path for you, or assigns you a command, is a dispatch defect — return the
-verdict as your final message and name the defect in it.
-
-Return only the verdict, never your process.
+The `orkestrel-falsify` verdict shape: numbered verdicts with evidence, findings outside the claims, attacked-and-held, one terminal line. Each required change carries `file:line`, what is wrong, and what right looks like. Nothing else.

package/dist/host/claude/agents/scout.md

@@ -1,35 +1,21 @@
 ---
 name: scout
-description: 'Read-only repository reconnaissance: locate files, symbols, seams, and structures; map terrain before a dispatch is written. Returns file:line pointers and a shape summary; never reads at absorption depth, never edits, never judges quality.'
+description: 'Read-only repository reconnaissance: locate files, symbols, seams, and structures before a brief is written. Returns file:line pointers and a shape summary. Never reads at depth, edits, or judges quality.'
 tools: Read, Grep, Glob
 model: sonnet
 effort: low
 permissionMode: dontAsk
+omitClaudeMd: true
 ---
 
-You are the **Scout** — the cheap native reconnaissance lane in this project's
-role set. You answer "where does X live, what shape is it, what touches it" so the
-Orchestrator can write a precise dispatch. You are an Executor: spawn nothing.
+You locate. You do not read at depth, edit, or judge.
 
-Read `.agents/orchestration.md` first. It owns the role set, the routing, and the
-dispatch contract.
+## Do
 
-## Law
+1. Take one bounded question: what to find and where to stop.
+2. Read the map the dispatch supplies (the Orchestrator runs the `orkestrel-scout` skill's `map.ts` and names its path); then search by name, symbol, export, and call site for what the map leaves open. Open a file only far enough to confirm a match. Refuse a dispatch that names no map and asks for one.
+3. Return every hit as `file:line` with a one-line shape note, grouped by the question's parts, and name the search patterns and roots you used so the coverage is checkable.
 
-- Read **AGENTS.md** next; the repository model and rule map orient every
-  answer. This charter restates nothing they own.
-- Locate, do not absorb: read excerpts sufficient to identify a seam, an owner,
-  or a shape. Deep reading and synthesis belong to the `grok` bench, and quality
-  judgment belongs to the review roles. If the question needs either, say so
-  instead of drifting into it.
-- Return pointers, not prose: `file:line` for every claim, the minimal shape
-  summary the question needs, and an explicit list of places searched that came
-  up empty — an absence claim is only as good as its named search.
-- Never speculate past the evidence.
+## Return
 
-## Return channel
-
-You are read-only. You hold `Read`, `Grep`, and `Glob` and no others: you never edit a file, never
-write your report to a file, and never run a command. Your final message IS the answer. A dispatch
-that names a report path for you, or assigns you a command, is a dispatch defect — return the
-answer as your final message and name the defect in it.
+`Question`, `Hits` (cited), `Shape` (under ten lines), `Not found` (patterns that returned nothing). Nothing else.

package/dist/host/claude/agents/verifier.md

@@ -1,47 +1,29 @@
 ---
 name: verifier
-description: 'Runs the exact authoritative quality gates or evidence commands named by the dispatch and reports exit-code truth with exact failure excerpts. Defaults to source-nonmutating check variants before build/test. Independent of every executor; never fixes.'
+description: 'Runs the exact gates or evidence commands the dispatch names, scoped first, and reports exit-code truth with exact failure excerpts. Independent of every writer; never fixes.'
 tools: Read, Grep, Glob, Bash
 model: sonnet
 effort: low
 permissionMode: default
+omitClaudeMd: true
 ---
 
-You are the **Verifier** — the independent gate runner in this project's role set.
-No builder's self-report counts as gate evidence. You are an Executor: run the
-gates yourself, spawn nothing.
+You run gates and report their true result. You never edit a file and never fix a failure.
 
-Read `.agents/orchestration.md` first. It owns the role set, the routing, and the
-dispatch contract.
+## Do
 
-## Job
+1. Run exactly the commands the dispatch names, in order. Default scoped sweep: the `check:` script and `test:` script of each project the dispatch names. Default tree-wide sweep, only when the dispatch says tree-wide: `npm run format:check`, `npm run lint:check`, `npm run check`, `npm run build`, `npm test`.
+2. Read each gate bare. Never pipe it through `tail` or `grep`.
+3. Record each gate's outcome by exit code. A gate that "mostly passes" failed.
+4. On failure, capture the exact failing excerpt and the `file:line` it points to.
+5. Re-run a timing failure once, alone, and report the first reading and the re-run reading.
 
-1. Read `AGENTS.md`, applicable rules, the dispatch-named skill and required
-   references, and the governing guide/spec.
-2. Run exactly the commands the dispatch names, in order. When asked for the default
-   independent sweep, use `npm run format:check` → `npm run lint:check` →
-   `npm run check` → `npm run build` → `npm test`. These do not rewrite source;
-   build artifacts are allowed. Never invent a different gate set.
-3. Evidence runs count as gates: when dispatched to reproduce a failure, run the
-   named command and capture its exact output — reproduce, capture, bisect
-   mechanically if told to; nothing more.
-4. Record each gate's TRUE outcome by exit code. A gate that "mostly passes" FAILED.
-5. On failure, capture the exact failing excerpt — trimmed to the failure, not the
-   noise — and the file:line it points to.
+## Refuse
 
-## Output contract — the Gate Report
+- A mutating gate (`lint`, `format`, or any `--fix`) beside a live unit. `build` may write its outputs when no writer is live; source is never edited.
+- `git checkout`, `git restore`, `git stash`, `git reset`, `git clean`. Read a dirty tree as the expected state.
+- Any command that installs, commits, pushes, publishes, deletes outside `tmp/`, or reads a secret (`.env*`, `.npmrc`, `auth.json`, keys, tokens), whatever the dispatch says.
 
-- **Per gate** — command → PASS / FAIL (exit code) → on FAIL, the exact failure
-  excerpt plus the suspected owning file(s).
-- **Overall verdict** — GREEN only if every gate passed; otherwise the first place
-  to look.
-- **Anomalies** — cache weirdness, flakes on rerun, anything off — one line each.
+## Return
 
-You never edit files and never "quick-fix" a failure — you report it. Return only
-the gate report, never your process.
-
-## Never discard a working-tree change
-
-- Follow `.agents/orchestration.md` § Permission floor for the discarding git commands and
-  for a planted line's removal. That section owns them.
-- Read a dirty `git status` as the expected state.
+Per gate: command, PASS or FAIL with exit code, failing excerpt and owning file on FAIL. Overall: GREEN only when every gate passed, otherwise the first place to look. Anomalies in one line each. Nothing else.

package/dist/host/claude/rules/documentation.md

@@ -81,7 +81,7 @@ Never use in-repository `@src/*` aliases in public guide examples; reserve them
 ## Workflow skills
 
 - Skills prescribe reusable process; they do not copy naming, placement, syntax, lifecycle, or test laws from `AGENTS.md` and rules.
-- Where a skill works a named subject, name its directory in the `orkestrel-<verb>-<noun>` form with the verb acting on that noun; where a skill runs a process the Orchestrator owns, name it in the `orkestrel-<verb>` form.
+- Name a skill directory `orkestrel-<word>`: the prefix and one word naming the process or the subject, such as `orkestrel-harden` or `orkestrel-journey`. Never a second word.
 - For a portable skill that teaches an external framework, takes the host project's own `AGENTS.md` file as its code law, and binds none of this repository's rule files, drop the `orkestrel-` prefix and name the skill for the framework a reader searches for. Add no other exception. The `enterprise-bootstrap` skill meets that test and keeps its name: it carries Bootstrap 5.3 craft, assumes no stack, and names the `.agents/orchestration.md` and `.claude/rules/quality.md` files only where they are present. Do not rename it into the namespace.
 - Keep `SKILL.md` concise and route conditional detail to one-level `references/`.
 - Name every Markdown file in a skill's `references/` from its `SKILL.md`, and delete a reference nothing names.
@@ -89,7 +89,13 @@ Never use in-repository `@src/*` aliases in public guide examples; reserve them
 - Set `name` to the skill's own directory name.
 - Write `description` as a single-line scalar or a folded `>-` block, and no other shape. Include in it a sentence beginning `Use ` that names when to invoke the skill.
 - Do not put model routing or package version catalogs in a skill.
-- Validate every referenced resource, leave no template TODOs, and limit each skill directory to `SKILL.md`, `agents/openai.yaml`, and the `references/*.md` files its `SKILL.md` names; add no other file or directory.
+- Validate every referenced resource, leave no template TODOs, and limit each skill directory to `SKILL.md`, `agents/openai.yaml`, the `references/*.md` files its `SKILL.md` names, and the `scripts/*.ts` files its `SKILL.md` names; add no other file or directory.
+- Put a repeatable or idempotent step of a skill in `scripts/<name>.ts`, run with `node .agents/skills/<skill>/scripts/<name>.ts` from the checkout root under Node's type stripping, and name the script, its arguments, and its exit codes from `SKILL.md` so an executor runs it instead of re-deriving the step. Name another skill's script by its full path under `.agents/skills/<skill>/scripts/`; the policy sweep attributes a bare `scripts/<name>.ts` token to the skill whose `SKILL.md` carries it and requires a qualified path to exist.
+- A skill script obeys `AGENTS.md`, `.claude/rules/typescript.md`, `.claude/rules/names.md`, and `.claude/rules/portability.md` as written, plus the no-nested-function and wrapper laws in `.claude/rules/architecture.md`, with these adaptations: an executable script exports nothing, runs `main` at the bottom, and carries the usage line and the exit codes in its opening comment; the types, constants, and helpers it alone needs live in the file, because the kind-file placement law stops at a self-contained script; what two scripts share lives in `.agents/skills/orkestrel-dispatch/scripts/helpers.ts`, the one shared module, which exports declarations with TSDoc, runs no entry point, and carries no usage line; a script imports `node:` modules and that module and nothing else, so the `@orkestrel/process` spawn rule yields to `child_process` there (a target may not declare that package), and imports it with the `.ts` extension, because the checkout runs a script unbuilt; and it spawns `process.execPath` or an executable by name with an argument array and never a shell, except the npm shim where no `npm-cli.js` sits beside the binary. Every script has a mirrored proof at `tests/agents/skills/<skill>/scripts/<name>.test.ts`: an executable script's proof drives it as a child process against a scratch fixture, and the shared module's proof imports it and tests each export. The policy sweep refuses a script without a proof, and a proof grows a case for every defect found.
+- Run a script in a target through its built twin, `node node_modules/@orkestrel/scaffold/dist/agents/skills/<skill>/scripts/<name>.js`, because Node refuses to strip types for a file under `node_modules`; `.claude/rules/workspace.md` names the `build:skills` script that emits the twins. When a script spawns a sibling script, take the extension from the running file (`extname(fileURLToPath(import.meta.url))`), so the twin spawns `.js` and the checkout spawns `.ts`. When a script resolves a file under `.agents/templates/`, add that file to the copy in `build:skills`.
+- Resolve a sibling canon file (a template, another script) from the script's own location with `import.meta.url`, and the manifest, `tmp/`, and the test tree from the working directory, because a target runs the script from `node_modules/@orkestrel/scaffold/dist/agents/` against its own checkout.
+- Read arguments as `--flag value` pairs through the shared helpers: the first occurrence of a flag wins, a value that opens with `--` is a missing value, and `--flag=value` is not read. Where flags select different work (`--visit` or `--plan`), the script names one operation mode per run and refuses two; where each flag adds a section to one report (`--tree` with `--headings`), the script combines them and its usage line says so. Read a flag that repeats (`--range`) through `readOptions` and say in the usage line that it repeats. Exit 64 on every usage refusal and say on stderr what was refused: the usage line when no mode or two modes were given, and the flag with the value it takes when a flag was malformed or given with no value.
+- Print to the terminal by default. Offer `--json` for a reader that parses, and `--out FILE` (`.txt` for a list, `.json` for a structure) where a lane reads the result later or the output would crowd a context; a written file saves the tokens a terminal dump spends. Choose per script; state each form in its usage line.
 - Verify each API a skill instructs an executor to call against the installed package's public entry before landing the instruction, and name the entry you read. A skill that names a symbol its package does not export teaches an executor to write a dangling import.
 - Put every symbol a skill teaches in a named import inside a Markdown fence in `SKILL.md` or a named reference. The policy sweep reads fenced value and type imports from `@orkestrel/*` declaration entries; it does not read identifiers in prose or table cells, or validate call signatures and runtime behavior.
 - Import only packages in `BASE_DEV_DEPENDENCIES` in those fences. The sweep refuses a package outside that set because a generated workspace need not install it.

package/dist/host/claude/rules/portability.md

@@ -5,6 +5,7 @@ paths:
   - 'configs/**/*'
   - 'tests/**/*'
   - 'scripts/**/*'
+  - '.agents/skills/*/scripts/*.ts'
   - 'guides/**/*'
   - 'package.json'
   - '.gitattributes'
@@ -60,6 +61,10 @@ and the form of a conditional skip.
 - Resolve, spawn, and terminate a child through `@orkestrel/process` where the package declares it.
 - Where it is not declared, spawn `process.execPath` with a JavaScript entry. Never spawn a `.bin`
   shim, and never add `shell: true` to reach one.
+- Merge a child environment by case-folded name: before spawning, drop every inherited variable
+  whose lower-cased name an added variable claims. A Windows environment block folds names by case,
+  so an inherited `NPM_CONFIG_CACHE` outranks an added `npm_config_cache`, and npm reads its
+  `npm_config_` variables case-insensitively on every host.
 - Take a resolver's first match only after splitting its output into lines and trimming each one.
   `where` prints a match per line and can name a file that is not an executable.
 - Treat `fs.constants.X_OK` as an existence check on Windows, where `accessSync` passes on a plain
@@ -89,7 +94,8 @@ and the form of a conditional skip.
 - Write every `package.json` script as a portable command: a Node invocation or an installed binary.
   Never name a `.sh` file there.
 - Keep `#!/usr/bin/env node` on an npm bin. npm writes the Windows shim from it.
-- Keep an agent hook under `scripts/` in bash, and keep `.gitattributes` `eol=lf`.
+- Keep `scripts/` for the Claude Code Cloud session hooks alone, in bash, with `.gitattributes` `eol=lf`. Every other script is TypeScript run by Node per `AGENTS.md`; a skill's scripts live in its `scripts/` directory.
+- Spawn a command from a script with an argument array and no shell, so quoting is the same on every host; resolve a `.cmd` shim to the JavaScript entry it wraps rather than spawning the shim.
 
 ## Claims
 

package/dist/host/claude/rules/quality.md

@@ -4,117 +4,57 @@ paths:
   - 'app/**/*'
   - 'tests/**/*'
   - 'guides/**/*'
-  - 'package.json'
-  - 'vite.config.ts'
-  - 'tsconfig.json'
-  - '.agents/skills/**/*'
-  - '.claude/skills/**/*'
 ---
 
-# Research, hardening, and completion rules
+# Evidence, probes, and completion rules
 
 ## Evidence before change
 
-- Research when the user asks for it, when comparing an upstream, protocol, or legacy implementation, or when current external behavior materially affects design.
-- Use current primary sources for external capabilities, and the exact installed declarations and guides for dependencies. Separate verified fact from inference.
-- Read authoritative types and named decision-bearing implementation files first-hand. Delegate bulk supporting context, never the owning design decision.
+- Read the authoritative `types.ts` and the decision-bearing implementation first-hand. Delegate bulk reading, never the owning decision.
 - Treat existing code, tests, `old/`, branches, and copied projects as evidence, not authority.
-- Build a capability/defect matrix before a broad API or production-readiness change. Every row ends as implement, repair, retain, or intentionally exclude with evidence.
-- Fix that matrix when the change starts. It is the definition of done, and the change closes when every row closes.
-- Never end a row as "hardened further." Replace any evaluative phrase with the concrete condition that closes the row.
-- Record a finding outside the matrix against the row that owns it, for the next matrix. Do not reopen this one.
+- Research when the user asks, when comparing an upstream or legacy implementation, or when current external behavior changes the design. Use primary sources for external capabilities and the installed declarations for dependencies. Separate verified fact from inference.
+- For a broad API or production-readiness change, build a capability/defect matrix before editing. Every row ends as implement, repair, retain, or exclude with evidence. The matrix is the definition of done; fix it when the change starts. Record a finding outside it for the next matrix.
 
 ## Probes before arguments
 
-A question a probe can settle is settled by the probe, whether or not anyone has disputed it. Reasoning decides what to run and what the result means. It does not replace the run.
-
-- Test your own assumptions before you rely on them. You do not need a disagreement to justify a probe. If you are about to depend on what a function returns, what a config resolves to, what a flag does, or whether a path is even reached, run it and find out.
-- Treat a long deliberation about behaviour as the signal to stop and run something. Deliberation that a ten-line probe would have ended is the most expensive habit in this process, and it is invisible because it feels like rigour.
-- Verify a belief before stating it, or label it as unverified. An unverified assertion put into context becomes a fact for everything downstream, including other agents, and correcting it later costs more than the check would have.
-- Hold a claim you issue to the standard you hold a claim you receive. Nothing downstream re-checks an instruction, so an unverified fact inside one becomes the premise of every task built on it. Auditing every report you receive while exempting every brief you write is the common form of this failure.
-- Prefer the check over the chain of reasoning whenever the check is cheap. Reading the installed declaration, running one line, or counting the call sites beats three paragraphs inferring the same thing, and it produces evidence you can hand to someone else.
-- Write the probe before the argument gets long. The moment a claim about behaviour is disputed — between engines, between a report and a rule, or in your own head — stop and run it. Get the smallest real input through the real code and read the real output.
-- Bound the search before starting it, and put the bound in the brief. Name the benchmark, the population, or the row that ends it. An investigation with no stated stopping condition runs until attention runs out. This includes the case where the honest answer is that the limit is inherent and belongs in documentation rather than in code.
-- Treat a negative probe as evidence about the probe until its input is shown to reach the code under test. A pass proves nothing if the vector never arrived. Instrument the path, assert an observable side effect, or drive it through a door you can see.
-- When a report names a defect and your reproduction comes back clean, assume first that your vector was weaker than theirs, and go get their exact vector. Treating a failed reproduction as a disproof is the most common way a true finding is lost.
-- A reported vector the compiler rejects refutes the VECTOR, never the finding. Where a claim asserts reachability through a typed API, compile the exact vector under the project's own settings; re-derive one the types admit before dropping the finding, and record which vector was actually tested.
-- Reproduce a reported defect's cause before instructing a fix from it. A real symptom can carry a wrong diagnosis, and a fix aimed at the stated cause edits the wrong file while the defect survives.
-- Do not read a result into a tool's failure to find your probe. "No tests found", an empty match, a skipped file, a runner that resolved nothing — these report on the harness, not the subject. Confirm the probe was collected and executed first.
-- Prefer an observation over a derivation, including your own. When a measurement and an argument disagree, the argument is wrong until the measurement is shown to be broken.
-- Diagnose from the artifact the work produces — the file, the count, the exit code, the timestamp on what changed — never from a wrapper or a proxy signal that merely correlates with progress. Read a gate bare: a pipeline stage after it (`| tail`, `| grep`) reports the stage's exit status and hides the gate's failing lines.
-- Verify a comment or an agent's report against the call sites before relying on it. A code comment is not evidence. When lanes disagree about whether a path is live, count the callers rather than weighing the prose.
-- What a round proves is what it ran. A conclusion carried from one door to another is a hypothesis at the second door. Re-run it there.
-
-## Falsification
-
-A review that reads a diff finds what the diff shows. A review that tries to break named claims finds what the diff hides. Code that has passed diff review several times can still carry a defect nobody has tried to trigger.
-
-### Writing the claims
-
-- State the subject as a numbered list of the claims the work makes, never as "review this diff." Each claim is falsifiable: a property some concrete input, state, or interleaving could show false.
-- Instruct the auditor to attempt refutation, not confirmation. A claim it cannot break is CONFIRMED with the evidence that convinced it. A claim it breaks is BROKEN with the exact failing input, state, or interleaving, plus the smallest correct fix.
-- Derive claims from what the change asserts under adverse conditions: cancellation, restart, concurrency, partial failure, hostile input, resource exhaustion, and the orderings a happy path never reaches.
-- Read the installed declaration or implementation of every substrate a claim depends on. A claim about `stop()` is unfalsifiable until you know what `stop()` does when the status is not the one the caller assumed.
-
-### Instruments
-
-- An instrument is not evidence until it has failed. Pair every probe, comparison, or matrix with a negative control that must report failure, run under the same conditions. An identity check whose control reports "same" has measured nothing.
-- When a question about a TypeScript edit can supply a workspace project, a case of workspace files with a test, and a negative control naming its files, its test, the stage it must fail at, and why, call the `prove` tool the `probe` MCP server registers before relying on the answer. When the question supplies no project, no case, or no control, follow `.claude/rules/tests.md` § Probes and report the fallback instrument's own control and coverage.
-- When no `probe` server is registered in the session, register one outside the repository, in the harness's own local or user MCP scope — in Claude Code, `claude mcp add` outside project scope — naming the installed `node_modules/@orkestrel/probe/dist/bin/main.js` entry, and start it in the repository whose projects the question names, because the server fixes its workspace from its own working directory. The registration cannot live in the tree: a scaffold target holds no `.mcp.json` file, that path is instruction canon, and a copy at it reports as foreign drift on every `scaffold audit` run. Where the harness registers no server at all, treat the question as supplying no project and take the preceding rule's fallback.
-- Quote the closing line of the `prove` answer verbatim in every report, brief, and audit verdict that rests on the claim: the `receipt probe:<digest>:…` line when the case ran clean and the control broke exactly where the claim declared it would, and the `no receipt` line otherwise. A `no receipt` line leaves the claim unproved — report it with the stage that refused.
-- Read a receipt as evidence about its claim, never as a gate result. The gate chain still runs, and `verifier` still owns its result.
-- Draw the negative control from outside the population the instrument covers. Name the instrument's membership rule first, then pick a control that rule excludes. A control sampled from constructs the instrument already handles proves only that it discriminates among those constructs, and says nothing about the class it silently cannot reach.
-- State an instrument's coverage beside its result. A conclusion inherits the instrument's scope, not the question's. An unstated coverage claim is read as complete, and it never is. A search proves something about the paths it walked, so name them.
-- Match the instrument to the question. A text search reports on text, so a claim about declarations, call sites, or structure needs the compiler or a parser instead. A pattern written for one spelling of a construct reports on that spelling alone. A path check answers relative to the directory it runs from, so resolve the inputs against their own base before reading a miss as a finding.
-- Name the rival reading the instrument must exclude, and show it reports differently under that reading. Give independent measurements independent state: one counter shared across members reports read order and per-member read count identically, so a result consistent with both measured neither.
-- Report a question unanswered rather than answering it with a weaker instrument. A fallback that measures something adjacent returns a confident wrong answer, and nothing downstream can tell that answer from the real one — searching commit messages for a release when the question is where a version changed will match some release, but not the one asked about. Name the substitute and what it actually measures, or say the question is open.
-- State what the controls established and what they did not. An instrument certified only from the inside is trusted exactly where it has never been tested.
-- Treat a gap between what an instrument says it checks and what it actually matches as a defect in the instrument, not as a documented limit. A recorded blind spot buys trust only when everything outside it is genuinely covered.
-- Measure the product, not the harness. A recorded baseline that counts something about its own fixture is not evidence about the shipped surface, however often a guide quotes it.
-- Baseline a published-artifact claim against the published artifact. "Did my change move the surface" and "does this release differ from the last one" are different questions, and a diff against your own starting point answers only the first. A toolchain that re-emits declarations moves the artifact without any source edit, so every writer can correctly report an unmoved surface while the package's published contract has changed. Fetch what consumers actually have — the tarball, the deployed asset — and compare against that.
-- Prove a module cycle by loading the built artifact, not by a green suite. Tests import through the source graph and a bundler resolves it differently, so a cycle that is fatal at module-init in the shipped form can stay invisible under every test. Import each published entry point and read an export from it.
-- Adopt an instrument that settled a claim as a test before accepting the work it settled. The probe that proved a fix, carrying the control that proved the probe, is that fix's regression guard. A verification that runs once is a rehearsal, not a gate.
-
-### Rounds and verdicts
-
-- Treat an all-confirmed round as a legitimate result, and put the brief on trial rather than the subject. Re-read the claims and ask whether any could have been falsified by evidence the round actually had. If none could, the claims were descriptive and the round proved nothing — sharpen them and re-run. If they could have been and were not, the pass stands.
-- Name the claims you could not break either way, so the next round knows what has already been attacked.
-- Never tell an auditor that a clean round means it did not try. That instructs it to manufacture a finding, and a manufactured finding costs a fix unit, an argument, and the credibility of the true findings beside it.
-- Treat a repaired claim as a new claim, not a settled one. Re-ask it at every entry point that reaches the same rule, not only the door the defect arrived through. The engine that wrote the fix is least able to see this, because re-verifying where the fix is feels like verifying the fix.
-- A fix that adopts the auditor's prescription verbatim may close with a mutation probe in place of a fresh audit round: disable the load-bearing line, watch the adopted pin fail, restore it, and commit the pin as the regression guard. A fix that departs from the prescription gets the cross-engine round.
-- Let reachability bound the fix. A defect reachable through the package's own shipped code or a documented extension seam falsifies its claim and is repaired now.
-- Document the obligation instead when a defect is reachable only through a hypothetical foreign implementation of a contract this package publishes. State it on the interface that owns it and prove the documentation. Do not build coordination machinery against a requirement nobody wrote down. Attacks are unlimited; reachable ones are not, and only the reachable set is a work list.
-- **Three rounds at one seam is the budget, and reaching it switches the search strategy rather than stopping the work.** Repeated rounds against one seam are evidence about the design, not evidence of diligence. At the third round, name what the audit is trying to accomplish, then pick the successor strategy from what the recurrence shows.
-- Recurrence with a direction — each fix relocates the class along one stream, or the evidence points up a dependency chain — ends the depth search. Run one breadth round that probes the stream's stations in parallel to locate the source, in the shape `.agents/orchestration.md` § Context and decomposition prescribes, then plan the downstream work from the source and size it by the sweep's map.
-- Recurrence with no direction makes the seam itself the question. The next unit is a ruling — on the threat model, the mechanism, or the boundary — taken with the same adversarial pass a design gets, not a fourth repair.
-- A subject that reprices itself on every edit — a count, a census, a total over prose — has no closing condition and is not a seam. Drop the claim, or recast it as the property the tally stood in for.
-- Write the round count down in the capability/defect matrix row that owns the seam, when the seam opens, so it is a fact rather than a feeling. A seam that has consumed more rounds than the rest of the matrix combined has already answered the question.
-- State the ruling that ends a seam as the invariant the code will obey, the constraint bounding it against over-correction, and the interface where a consumer meets the obligation. A ruling that names only the defect it replaces produces the opposite defect next round.
-- Give every behavioural audit the means to run its attacks. An auditor that cannot execute cannot falsify a behavioural claim: it returns derivations, and a derivation reads exactly like a verdict while being a different thing — it will confirm a claim one probe would break. Treat a report with no executed evidence as a review of the source, and label it as such.
+- Settle a question about behavior by running it: what a function returns, what a config resolves to, whether a path is reached. Run before stating the belief.
+- When the argument about a behavior grows past a few sentences, stop and run it.
+- Label an unverified assertion as unverified. An unverified claim in a brief becomes the premise of every downstream unit.
+- Bound a search before starting it: the benchmark, the population, or the row that ends it.
+- A passing negative probe proves nothing until its input is shown to reach the code under test.
+- A clean reproduction of a reported defect means your vector was weaker than the reporter's; get theirs before ruling. A vector the compiler rejects refutes the vector, not the finding.
+- "No tests found", an empty match, or a runner that resolved nothing reports on the harness. Confirm the probe was collected before reading a result.
+- Prefer an observation to a derivation. When a measurement and an argument disagree, the argument is wrong until the measurement is shown broken.
+- Read a gate bare. A `| tail` or `| grep` behind it hides the failing lines and reports the pipe's exit code.
+
+## Instruments
+
+- An instrument counts as evidence only after it has failed: pair every probe, comparison, or matrix with a negative control that must fail under the same conditions, drawn from outside the population the instrument covers.
+- When a TypeScript question can name a workspace project, a case (files plus a test), and a control (files, test, the stage it must fail at, and why), call the `prove` tool the `probe` MCP server registers. Quote its closing line (`receipt probe:<digest>:…` or `no receipt`) where the claim is reported. A `no receipt` line leaves the claim unproved; report the stage that refused.
+- When the question supplies no project, no case, or no control, write a probe per `.claude/rules/tests.md` § Probes and report the probe's control and coverage.
+- When no `probe` server is registered, register one outside the repository in the harness's user or local MCP scope, pointing at `node_modules/@orkestrel/probe/dist/bin/main.js`, and start it in the repository whose projects the question names. A scaffold target holds no `.mcp.json`.
+- Read a receipt as evidence about its claim, never as a gate result.
+- State the instrument's coverage beside its result. Match the instrument to the question: a text search reports on text; a claim about declarations or call sites needs the compiler or a parser.
+- Report a question unanswered rather than answering it with a weaker instrument.
+- Baseline a published-artifact claim against the published artifact (the tarball, the deployed asset). Prove a module cycle by loading the built entry points.
+- Promote an instrument that settled a claim into a test, with its control, before accepting the work it settled.
 
 ## Ecosystem reuse
 
-The root laws on inspecting declared `@orkestrel/*` capabilities, reusing a matching primitive, and updating every consumer without shims bind here without restatement. This file adds the judgment calls:
-
-- Prove the semantic difference before keeping a local variant. Similar names are not evidence of different behavior.
-- Treat downstream friction as valid evidence of a reusable upstream defect, not as automatic proof. Fix the lowest package that owns the general mechanism and keep product policy downstream.
-- Never re-export a dependency's symbol to soften a consumer's import.
+- Prove a semantic difference before keeping a local variant of an installed primitive.
+- Fix a reusable defect in the lowest package that owns the mechanism; keep product policy downstream.
+- Never re-export a dependency's symbol.
 
 ## Production hardening
 
-- Translate "enterprise-grade" or "production-ready" into an explicit risk and seam matrix covering applicable inputs, states, failures, cleanup, cancellation, concurrency, resource ownership, hostile boundaries, environment isolation, serialization and restore, and package consumption.
-- Grade that matrix on coverage, not optimization: whether every applicable seam exists, works, and stays proven. Do not grade on how many further interleavings can be invented against the one seam already proven. A surface polished past its row buys less than the next uncovered seam would have.
-- Test observable invariants at each applicable seam with real implementations.
-- Use dedicated real-service projects for external model or service behavior. Require readiness and tune each request to the smallest proof that still exercises the claim.
-- Audit test discovery, counts, skipped and todo tests, cleanup, and assertion adequacy. Passing discovered tests alone is insufficient.
-- Inspect public exports, declarations, supported runtime targets, and generated outputs.
-- Treat a claim that a surface works with an external client as unproven until one representative real client of that class has driven it end to end. Protocol tests prove the protocol, not the integration.
-- Add an independent adversarial review for security, destructive paths, concurrency, protocols, or untrusted external input.
+- Translate "enterprise-grade" or "production-ready" into a risk and seam matrix: inputs, states, failures, cleanup, cancellation, concurrency, resource ownership, hostile boundaries, environment isolation, serialization, package consumption.
+- Grade the matrix on coverage of applicable seams, not on further interleavings against a seam already proven.
+- Test observable invariants at each seam with real implementations; use a dedicated real-service project for external behavior.
+- Treat "works with an external client" as unproven until one representative real client has driven it end to end.
+- Audit test discovery, counts, skipped and todo tests, cleanup, and assertion adequacy before acceptance. Coverage is not adequacy.
+- Add an independent review for security, destructive paths, concurrency, protocols, or untrusted input, per the size gate in `.agents/orchestration.md`.
 
 ## Completion
 
-The root completion law — finish every in-scope capability now, leave no TODO, deferral, or hidden follow-up, and run the applicable repository skill for comprehensive work — binds here without restatement. This file adds these obligations:
-
-- Perform a final centralization, wrapper, test-helper, and text-integrity sweep after implementation and before gates.
-- Produce local quality gates and relevant output inspection as required evidence.
-- Stop once the enumerated scope is closed and those gates are green. Stopping there is correct, and the next scope is the deliverable. A further pass over the same surface requires a new instruction from the user, not an auditor's remaining appetite. Depth is owed to what the scope names, not to what an engine can still imagine about it.
+- Sweep centralization, wrappers, test helpers, and text integrity after implementation and before gates.
+- Stop when the enumerated scope is closed and the gates the size gate names are green. The next scope is the deliverable; a further pass needs a further instruction from the user.

package/dist/host/claude/rules/styles.md

@@ -43,6 +43,9 @@ SCSS mirrors TypeScript centralization. Concrete token prefixes are project-spec
   literal color may appear in is `_tokens.scss`, where the token itself is declared.
 - Never repeat per-color/per-variant blocks; drive shared structure with one `@each` over a shared list.
 - If a pattern appears in at least two partials, move it to `_mixins.scss`.
+- Treat a declaration block two partials share because each records an external value as a
+  coincidence, never a pattern: keep both copies inline, and move a block only where its callers
+  share one decision whose divergence is a defect.
 - A one-partial pattern stays inline; do not create a mixin for one caller.
 - Never `@extend` across partials; share through tokens/mixins.
 - Never declare a `transition:` without `prefers-reduced-motion: reduce`. Use the project transition mixin, which emits both.

package/dist/host/claude/rules/tests.md

@@ -12,7 +12,7 @@ paths:
 
 - Mirror module/application structure:
   `tests/{src,app}/[environment]/[domain]/[module].test.ts`.
-- The mirrored population is `src` and `app` alone. `configs/` is a source directory and is
+- The mirrored population is `src` and `app`, plus the skill scripts: `.agents/skills/<skill>/scripts/<name>.ts` is proved by `tests/agents/skills/<skill>/scripts/<name>.test.ts`, one proof per script, and the policy sweep refuses a script with no proof. `configs/` is a source directory and is
   deliberately not a mirrored root: its leaves produce the workspace's configuration rather than ship
   in it, and they are proved from `tests/config.test.ts` beside the configuration they produce. Do
   not add `tests/configs/`.
@@ -54,6 +54,7 @@ its own:
 | `tests/config.test.ts`       | Root configuration resolves its aliases, projects, and outputs, and the `configs/` leaves behind them                                                                                        |
 | `tests/guides.test.ts`       | Every documented API exists, every public API is documented, every compared summary, example, and pitch equals its source, and every executable fence returns what the guide says it returns |
 | `tests/conformance.test.ts`  | Where this package drifts from the official tooling it tracks                                                                                                                                |
+| `tests/agents/**/*.test.ts`  | Each skill script does what its `SKILL.md` states, driven as a child process against a scratch fixture from its mirrored proof; the scaffold checkout alone carries them                     |
 | `tests/distribution.test.ts` | The packed package installs and resolves through its public exports                                                                                                                          |
 | `tests/integration.test.ts`  | The package's features work together end to end across environments                                                                                                                          |
 | `tests/setup*.test.ts`       | Reusable behavior exported from sibling `tests/setup*.ts` modules works as the workspace's suites require                                                                                    |
@@ -109,7 +110,7 @@ The kinds split by which tool has to see the probe:
   lives in the source tree beside what it measures. Delete it before the unit returns; a leaked one
   fails the `policy` plugin's placement rules, because a probe filename is not a centralized kind
   file.
-- A **runtime probe** is collected by a Vitest project, so it lives in `tmp/probe/` and runs through
+- A **runtime probe** is collected by a Vitest project, so it lives in `tmp/probes/` and runs through
   the `probe` project. `tmp/` is ignored by git, so no probe enters a commit by accident, and every
   test script names its project, so no gate runs the `probe` project.
 - A **bench** is read by Vitest's benchmark mode, so it lives inside a test file as a block behind
@@ -321,7 +322,9 @@ Coverage rules:
 
 ## Discovery and adequacy audit
 
-Before acceptance:
+For a change the size gate in `AGENTS.md` § Work loop names medium or large, run
+`node .agents/skills/orkestrel-harden/scripts/discovery.ts` before acceptance for the census of
+projects, gates, collected files, and skip markers, then:
 
 - prove every intended test file is discovered by the correct project;
 - prove every declared project is reachable from a gate. A project registered in the root