@orkestrel/scaffold 0.0.50 → 0.0.51

package/dist/host/AGENTS.md

@@ -13,7 +13,7 @@
 - External delegates, including Cursor and Codex models, have no exemption. Every dispatch restates the non-negotiables, applicable rules, guide or spec, and owned files. Every result receives independent review.
 - Before working, read in order:
   1. this file;
-  2. every applicable file in `.claude/rules/` from the rule map below;
+  2. every applicable file in `.claude/rules/` from the Rule map section;
   3. every explicitly invoked or dispatch-named skill and the references it requires;
   4. `guides/README.md`, the matching guide or spec, and `ROADMAP.md` when present.
 - Rules state **how to write**. Guides and specs state **what to build** and the domain workflow. When they conflict, stop and surface the conflict.
@@ -115,7 +115,7 @@ npm run format:check → npm run lint:check → npm run check → npm run build
 
 ## Rule map
 
-Every file below is a normative extension of this root. Read every rule relevant to the files or concepts you touch. Path frontmatter only controls Claude's automatic loading.
+Every file in the following table is a normative extension of this root. Read every rule relevant to the files or concepts you touch. Path frontmatter only controls Claude's automatic loading.
 
 | Rule                             | Governs                                                                |
 | -------------------------------- | ---------------------------------------------------------------------- |

package/dist/host/agents/orchestration.md

@@ -7,7 +7,7 @@ harness follows this file.
 
 Read in this order before acting:
 
-1. The user's current instruction. It wins over everything below.
+1. The user's current instruction. It wins over every later item.
 2. `AGENTS.md` and the applicable `.claude/rules/*.md` files. They govern code substance.
 3. This file. It governs agent operation only and cannot weaken the coding contract.
 4. The dispatch-named skill and the references it requires.
@@ -95,8 +95,9 @@ Record the substitution.
 - Grok takes every lane only in Cursor, and only when Opus 5 and Sol are both unavailable.
 - Treat a lane that returns no verdicts as a lane that did not run. A bench lane reporting that its
   driver executed and its engine was never reached is a dark bench, not a result. Record the bench
-  dark from that report, re-run the lane on the substitute engine from the table above, and name in
-  the routing ledger which lane ran on which engine. Never accept a round with one lane empty.
+  dark from that report, re-run the lane on the substitute engine from the preceding table, and
+  name in the routing ledger which lane ran on which engine. Never accept a round with one lane
+  empty.
 - Re-read bench liveness at dispatch, not at session start. A bench that probed live can be dark when
   the lane launches.
 
@@ -288,13 +289,14 @@ owns each bench's exact probe.
 
 The local steps still run, because they route the recovery rather than decide the verdict: an
 unresolved CLI is an install problem, a failed authentication-state check starts the login ladder
-below, and a bench that passes both and still cannot round-trip is dark for a reason no local check
-can see. Record every dark bench with its fallback and the lane substitution it forces, and never
-absorb one silently. A readiness script reports readiness and performs no model call, so the round
-trip belongs to the Orchestrator's own probe or to the bridge carrying the unit, never to the hook.
-Liveness also expires: a dispatch that fails on quota, model access, or the network is a fresh
-liveness result rather than a unit-level fault, so record the bench dark from there and re-plan the
-lane instead of re-dispatching against a session-start answer that no longer holds.
+in Recovering a dark bench, and a bench that passes both and still cannot round-trip is dark for a
+reason no local check can see. Record every dark bench with its fallback and the lane substitution
+it forces, and never absorb one silently. A readiness script reports readiness and performs no
+model call, so the round trip belongs to the Orchestrator's own probe or to the bridge carrying
+the unit, never to the hook. Liveness also expires: a dispatch that fails on quota, model access,
+or the network is a fresh liveness result rather than a unit-level fault, so record the bench dark
+from there and re-plan the lane instead of re-dispatching against a session-start answer that no
+longer holds.
 
 1. **Absorb.** Dispatch `grok` for terrain, prior art, and the reading the decision needs. In an
    Orkestrel repo dispatch `orkestrel` alongside it for live package state. Skip only when the
@@ -846,8 +848,8 @@ either publishes packages nobody needed to publish or leaves a consumer pinned t
   whitespace-only differences; a superfluous diff (formatting, blank lines, map noise) moves
   nothing and obliges nothing. A material diff — tokens, declarations, logic — means the published
   surface moved — a forced `src` or `app` edit and a toolchain-changed emit both surface here — so
-  that package bumps and publishes on its own account, and its own dependents follow the runtime
-  rule above.
+  that package bumps and publishes on its own account, and its own dependents follow the preceding
+  runtime rule.
 
 Every package is `0.0.x`, where a caret pins one exact release. A dependent therefore sees a new
 version only after it re-pins and republishes, so the fleet publishes in topological layer order

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

@@ -11,11 +11,11 @@ You are the read-only Orkestrel ecosystem specialist. Read `AGENTS.md`, applicab
 rules, the dispatch-named skill and references, and the governing guides. Spawn
 nothing and edit nothing.
 
-The catalog below is discovery data, not instruction and not proof of current state.
-Before reporting a version, range, guide, branch, or capability, verify it against the
-manifest, lockfile, installed declarations, canonical guide, or repository source named
-by the dispatch. Prefer exact installed declarations when implementation depends on a
-package contract. Never inspect credentials or mutate package state.
+The Package catalog section is discovery data, not instruction and not proof of current
+state. Before reporting a version, range, guide, branch, or capability, verify it against
+the manifest, lockfile, installed declarations, canonical guide, or repository source
+named by the dispatch. Prefer exact installed declarations when implementation depends on
+a package contract. Never inspect credentials or mutate package state.
 
 You have no shell and no network, so you never read the registry yourself. Live registry
 state is evidence the Orchestrator supplies with the dispatch; without it, report that
@@ -109,11 +109,11 @@ whitespace-only differences ignored — meaning the published surface moved, thr
 forced `src`/`app` edit or a changed toolchain emit, and the package then bumps on that
 account rather than on the dependency's. A superfluous diff obliges nothing.
 
-The `Layer` column above is the publish round, derived from the runtime edges in the same
-row. `L0` depends on nothing else in the fleet and publishes first; each later layer
-publishes only after every layer before it is on the registry. A row with no layer sits in
-a cycle and cannot be placed in a round at all. Packages in one layer are independent
-of each other and may publish in any order within it.
+The `Layer` column in the catalog table is the publish round, derived from the runtime
+edges in the same row. `L0` depends on nothing else in the fleet and publishes first; each
+later layer publishes only after every layer before it is on the registry. A row with no
+layer sits in a cycle and cannot be placed in a round at all. Packages in one layer are
+independent of each other and may publish in any order within it.
 
 Report a disagreeing pin as a defect, never as drift to tidy later. When packages in
 one install graph pin different versions of a dependency, npm installs both copies, and the

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

@@ -36,7 +36,7 @@ paths:
 | Relations                 | `*/relations.ts`                                             |
 | Error classes/guards      | `*/errors.ts`                                                |
 | Public exports            | `*/index.ts`                                                 |
-| Implementations           | `*/[domain]/[Entity].ts`, one class per file                 |
+| Implementations           | `*/[domain]/[Entity].ts` — one class per file                |
 | Function modules          | a designated folder's `[function].ts`, one function per file |
 
 Use only the centralized files an environment needs.
@@ -49,7 +49,7 @@ Use only the centralized files an environment needs.
 - Extract local declarations by kind. “Only used here” and “not exported” are not exemptions.
 - Every declaration in a centralized file is exported. Fold away a trivial single-use declaration or export/test it; never leave it hidden.
 - The only permitted non-exported module-scope declarations are in a runtime entrypoint that must be self-contained and cannot import siblings, such as raw source loaded in a worker. Explain that necessity in a comment.
-- A runtime entry—`src/bin/main.ts`, `app/browser/main.ts`, `app/server/main.ts`—is a fixed name, not a centralized kind file. Both the data rule and the function rule reach it, so it declares no module-scope constant and no module-scope function: it imports what it needs and runs. The self-contained exception above covers only an entrypoint that cannot import siblings.
+- A runtime entry—`src/bin/main.ts`, `app/browser/main.ts`, `app/server/main.ts`—is a fixed name, not a centralized kind file. Both the data rule and the function rule reach it, so it declares no module-scope constant and no module-scope function: it imports what it needs and runs. The preceding self-contained exception covers only an entrypoint that cannot import siblings.
 - Perform a cleanup sweep after implementation: no stray implementation-file declarations, non-exported/wrong-kind centralized declarations, prohibited nested declarations, duplicate implementations, compatibility aliases, superfluous wrappers, stale imports/barrel rows, or untested extracted functions.
 
 ## Kind purity
@@ -108,7 +108,7 @@ kind. It reads declaration syntax and file name, never meaning.
   `oxlint-disable` directive.
 - It does not prove a collection is frozen. It reads the declaration, never the value a call
   returns, so `Object.freeze([…])` and any other call initializer are one syntax to it. The freeze
-  obligation in the kind-purity rules above binds regardless; only the bare literal is mechanical.
+  obligation in the earlier kind-purity rules binds regardless; only the bare literal is mechanical.
 - It does not tell one function kind from another. Every centralized file that permits functions
   reads the same to it apart from the `parse*` and `create*` name forms: `cloners.ts`, `combinators.ts`,
   `compilers.ts`, `errors.ts`, `factories.ts`, `handlers.ts`, `helpers.ts`, `inferers.ts`,
@@ -118,12 +118,12 @@ kind. It reads declaration syntax and file name, never meaning.
 - It reports no `data` violation in `helpers.ts`. The kind rules place a camelCase namespace of
   functions there, and a namespace of callables is not separable from a data table by declaration
   syntax, so `DATA_EXEMPT_FILES` in `tests/setupPolicy.ts` excludes the file. Ordinary module data
-  there — `export const RETRIES = 3` — is unreported; the constants rule above binds regardless.
+  there — `export const RETRIES = 3` — is unreported; the earlier constants rule binds regardless.
 - It inspects no ambient declaration file: `.d.ts`, `.d.mts`, and `.d.cts` are all outside its
   reach. An ambient declaration file is not a module in the kind table, so it sits outside the
   parsed population entirely rather than being exempted from the `type` rule.
 - It does not inspect class-expression members. A function assigned inside a class-expression
-  method is unreported; the functions rule above still binds, and cleanup and review enforce it.
+  method is unreported; the earlier functions rule still binds, and cleanup and review enforce it.
 - The cleanup sweep and independent review prove kind purity across those files. A helper misfiled
   as a parser, a coercer misfiled as a guard, a compiler misfiled as a factory, and a shaper
   misfiled as a cloner are review findings, not red tests.
@@ -279,7 +279,7 @@ export * from './greeters/Greeter.js'
 - Centralize any pattern repeated twice.
 - Keep everything generic/reusable and free of unrelated-project logic.
 - Do not expand the capability set without concrete need. Once that capability exists intentionally,
-  its reusable top-level exports follow the barrel rule above without a second consumer gate.
+  its reusable top-level exports follow the earlier barrel rule without a second consumer gate.
 - Do not remove structural files because they are currently empty.
 - Prefer the smallest complete implementation that preserves architecture.
 - No deprecation aliases, compatibility shims, or backward-compatibility branches; update all consumers atomically.

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

@@ -111,7 +111,9 @@ The kinds split by which tool has to see the probe:
   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
   the `if (import.meta.env.MODE === 'benchmark')` guard. Only the `test:bench` script collects the
-  block, test mode fails an unguarded `bench()` call loudly, and no gate runs a bench.
+  block, test mode fails an unguarded `bench()` call loudly, and no gate runs a bench. Call `bench`
+  directly inside the guard. A `describe` inside it trips `vitest/no-conditional-tests`, and a suite
+  the guard leaves unregistered fails test mode with `No test found in suite`.
 
 Run a probe before relying on an unverified belief about behaviour: what a function returns, what a
 configuration resolves to, whether a path is reached at all. Prefer a probe to an argument whenever
@@ -169,7 +171,7 @@ A test that spawns a process, packs, installs, or drives a real build is a proof
 
 Test helpers are shared infrastructure, not local test-file clutter.
 
-`@orkestrel/test` owns the helpers every workspace repeats: the call recorder, the real delay, the JSON and async collectors, and the owned scratch directory. Import them from `@orkestrel/test`, and its Node-only helpers from `@orkestrel/test/server`. Write a helper of your own only where the package exports none for the job. The shapes below are the contract a workspace codes against, not source to copy.
+`@orkestrel/test` owns the helpers every workspace repeats: the call recorder, the real delay, the JSON and async collectors, and the owned scratch directory. Import them from `@orkestrel/test`, and its Node-only helpers from `@orkestrel/test/server`. Write a helper of your own only where the package exports none for the job. The following shapes are the contract a workspace codes against, not source to copy.
 
 - For the vendored test set (`tests/setupPolicy.ts`, `tests/policy.test.ts`, and
   `tests/config.test.ts`), keep shared helpers within that set instead of importing them from

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

@@ -166,7 +166,7 @@ ignored by git; and `.claude/rules/tests.md` governs what may live there.
   drives.
 - In a publishing workspace, a project leaves the default run when it drives a live external
   service or is hermetic but slow — it spawns processes, packs, installs, or drives a real build.
-- Give every isolated project its own script, and place that script by the paragraph above.
+- Give every isolated project its own script, and place that script by the preceding paragraph.
 
 Setup assets:
 

package/dist/host/codex/config.toml

@@ -14,7 +14,7 @@ developer_instructions = """
 Read AGENTS.md, .agents/orchestration.md, every applicable .claude/rules/*.md file, the
 dispatch-named .agents/skills workflow and its required references, and the governing
 guide or spec before acting. AGENTS.md controls code substance; .agents/orchestration.md
-controls agent operation; this layer adds only the Codex specifics below and cannot
+controls agent operation; this layer adds only the following Codex specifics and cannot
 weaken either.
 
 Sol orchestrates in this harness. Act as the Orchestrator defined in

package/dist/host/guides/scaffold.md

@@ -12,8 +12,8 @@ does not work. Scaffold makes the shared set data — a vendored data root shipp
 — and gives it verbs: create a workspace from it, report how a workspace differs from it, and
 write the difference back.
 
-Every code fence below is illustrative. [`tests/guides.test.ts`](../tests/guides.test.ts) keeps the
-command reference aligned with the executable and transcribes the pure blueprint-default,
+Every following code fence is illustrative. [`tests/guides.test.ts`](../tests/guides.test.ts)
+keeps the command reference aligned with the executable and transcribes the pure blueprint-default,
 compile-refusal, and error-narrowing fences. A trailing comment in another fence is this guide's
 claim rather than a measured answer; the driven examples are the ones the shipped declarations
 print. Limits states what that leaves unproven and what covers it instead.
@@ -391,8 +391,8 @@ Exported from `@orkestrel/scaffold/server`, and reachable from
 
 `Compiler` implements `CompilerInterface`, `Materializer` implements `MaterializerInterface`, and
 `Upstream` implements `UpstreamInterface`. Each class exposes exactly its interface's members and
-nothing more, so the interface tables below describe the classes too. `WriteTransaction` publishes
-no interface and is documented directly.
+nothing more, so the following interface tables describe the classes too. `WriteTransaction`
+publishes no interface and is documented directly.
 
 #### `CompilerInterface`
 
@@ -566,9 +566,9 @@ carries the fact and the vendor list keeps its own separate job.
 The root Vite configuration defines and registers the fixed `guides` project only when the derived
 blueprint carries `guides`. Reading verbs set that fact only when `tests/guides.test.ts` is a
 physical file with that exact path case. A directory or a case-folded spelling does not select it. A
-fresh workspace therefore carries no guides project or script. A developer who adds the proof must
-also add the exact `test:guides` script line that the plan reports; the manifest remains
-birth-owned.
+fresh workspace therefore carries no guides project or script. When a developer adds the proof,
+`audit` reports the exact `test:guides` script line until `repair` or `overwrite` appends it through
+the writable script region. The rest of the manifest remains birth-owned.
 
 The plan-reading verbs compare the Vitest project set named by the target manifest with the
 project set the planned root configuration registers. Every planned proof project must also be
@@ -585,31 +585,36 @@ static Vitest fact to infer.
 `audit` still completes the comparison and reports one non-blocking `projects` question when its
 selection includes `configs`. A scoped audit that excludes `configs` omits that question. For a
 literal absent project, its advisory tells the developer to register the project or remove the
-script. For a planned project absent from the gate chains, the advisory checks the direct
-`test:<project>` script. When the script is absent, the advisory gives the exact line to add to
-`package.json`. When the script is declared but ungated, the advisory names the script and the gate
-chain that must invoke it, without repeating a script line. When `configs` is selected, `repair` and
-`overwrite` refuse either mismatch before writing. Their refusal names the `configs` group, the
-manifest and planned `vite.config.ts` conflict, and the option to exclude `configs` from
-`--groups`. A selection that excludes `configs` proceeds. An advisory alone does not make an aligned
-target drift.
-
-Scaffold writes one part of the manifest rather than advising on it: the script region a publishing
-workspace needs for the generated distribution proof. `repair` and `overwrite` write
-`test:distribution` and `prepublishOnly` there. A declared value is overwritten only when it is
-already the value being written, or, for `prepublishOnly`, the one predecessor the region accepts —
-the same gate chain without the release row. The overwrite happens in place, so every byte outside
-the replaced ranges survives, and a description, a keyword, a key order, and a script the workspace
-added are untouched. A script the manifest does not declare is appended after the last declared one,
-copying that section's indentation. `catalog` writes no script region; it names the ranges alone.
-
-A value matching neither is a chain the workspace author wrote. The region is then refused whole,
-without a byte moving, and the range region is still written. The `projects` advisory reads the
-manifest as a write would leave it, so a region scaffold writes for itself raises no question, while
-a refused region leaves the target's own text standing and the advisory reports whichever half is
-outstanding: the exact `test:distribution` line to paste, or the gate chain that must invoke a
-script the manifest already declares. The refusal covers the region rather than one script, so a
-manifest never holds one written value beside one refused one.
+script. For a planned project absent from the gate chains, the advisory reads the manifest after a
+writable script projection. The `scripts` question owns an absent direct `test:<project>` line. The
+`projects` question names the direct script and the gate chain that must invoke it when the projected
+region still leaves the project ungated. When `configs` is selected, `repair` and `overwrite` refuse
+an unregistered or ungated project before writing. Their refusal names the `configs` group, the
+manifest and planned `vite.config.ts` conflict, and the option to exclude `configs` from `--groups`.
+A selection that excludes `configs` proceeds. An advisory alone does not make an aligned target
+drift.
+
+Scaffold writes one part of the manifest rather than advising on it: the writable script region.
+`repair` and `overwrite` write every direct `test:<project>` script the blueprint computes,
+`test:probe`, and `test:bench`. A publishing workspace also receives `test:distribution`, `prepack`,
+and `prepublishOnly`. The `test`, `check`, `build`, `dev`, `serve`, `show`, `format`, `lint`, `clean`,
+and `copy` gate chains stay maintainer-owned. A declared value is overwritten only when it is already
+the value being written or is a recognized generated predecessor. The overwrite happens in place,
+so every byte outside the replaced ranges survives. A target's descriptions, keywords, extra
+scripts, and manifest key order survive byte-for-byte. A script the manifest does not declare is
+appended after the last declared one, copying that section's indentation. `catalog` writes no script
+region; it names the ranges alone.
+
+A value matching neither is a script the workspace author wrote. The region writer retains that
+value byte-for-byte and reports its name, declared value, and planned value. Each other planned
+script is decided independently: an absent script appends, the planned value stands, and an accepted
+predecessor upgrades in place. Extra scripts remain byte-identical. A planned key holding a
+non-string value or a `scripts` field that is not an object still refuses the whole region with no
+script byte moving. `audit` reports absent and differing scripts separately in its non-blocking
+`scripts` question, and the terminal audit in `repair` and `overwrite` keeps every retained
+difference visible. Other selected writes still proceed. The `projects` question reports only a
+direct script the manifest declares but the maintainer-owned gate chain does not invoke after
+projection.
 
 The same plan-reading verbs compare the tooling set the derived blueprint plans against
 `dependencies` and `devDependencies` together. A missing planned package produces one non-blocking
@@ -640,7 +645,8 @@ maintainer wrote rather than what scaffold seeded.
 That reading carries a release-skew limit. A seeded setup module is birth-owned, so `repair` reports
 it aligned and never rewrites it. A target keeps the seed of the release that materialized it. When
 a release moves a planned seed, scaffold raises the question on every target materialized before it,
-against a module scaffold wrote and no maintainer touched.
+against a module scaffold wrote and no maintainer touched. `audit` compares each setup module only
+with the seed the installed release plans, and it retains no earlier seed bytes.
 `tests/setupGlobal.ts` is the module that can meet it, because it is the one seeded with more than
 the empty string. A maintainer meeting that question closes it by writing the proof it asks for, or
 by taking the seed the installed release plans.
@@ -741,7 +747,7 @@ One published environment owns the package root directly. Several published envi
 never runs. The gate reports that as a non-blocking `src` question rather than refusing the compile,
 because the shape is chosen once and read afterwards: `new` refuses the advisory, while `audit` and
 `repair` need the plan to describe and restore a target that already has that shape. A library
-caller creating a workspace holds the same refusal, and the Compile section below states it.
+caller creating a workspace holds the same refusal, and the Compile section states it.
 
 `bin`, `setup`, `guides`, `integration`, `conformance`, `service`, `vendors`, `global`, and
 `showcase` are structural facts. Each is set only when the workspace physically ships the directory
@@ -758,14 +764,12 @@ generated before that file existed and still registers no `integration` project,
 fails with `integration has no project factory or configuration` until a plan-writing verb
 regenerates it.
 
-`repair` alone does not close that, and refusing is correct rather than a gap. `package.json` is
-birth-owned, so the verb cannot add the project's script, and it will not register a project the
-manifest reaches from no gate. It exits 1 naming the target and writes nothing.
+`repair` closes the direct-script half through the writable manifest region. It still refuses to
+register a project that the maintainer-owned gate chains do not reach.
 
-Adding a structural proof is therefore these steps, in order: write the file; declare its
-`test:<project>` script and invoke that script from a gate chain; then run `repair`, which
-regenerates the root configuration and registers the project. `audit` reports whichever piece is
-still outstanding at each step.
+When you add a structural proof, write the file and invoke its planned `test:<project>` script from
+a gate chain. Then run `repair`; it appends the direct script, regenerates the root configuration,
+and registers the project. `audit` reports whichever piece is still outstanding at each step.
 
 `distribution` is not a field at all. A published `src` environment is its whole condition, read
 from the `src` axis the blueprint already carries. The proof packs and installs the published
@@ -1184,9 +1188,9 @@ A workspace's file set is a function of its axes plus its structural facts. Noth
 except the manifest.
 
 - One computed artifact: `package.json`, with the entry points, `exports` map, scripts, and
-  development dependencies its selection implies. A publishing manifest carries
-  `"prepack": "npm run build"` so a publish rebuilds `dist/` and cannot ship a stale artifact;
-  the hook is publish-time only, and every generated distribution proof passes
+  development dependencies its selection implies. In publishing workspaces, the emitted `prepack`
+  script runs `npm run build` so a publish rebuilds `dist/` and cannot ship a stale artifact; the
+  hook is publish-time only, and every generated distribution proof passes
   `--ignore-scripts` to `npm pack` so a suite never re-runs the build it already gates.
 - One template artifact per configuration file the selection needs: the root `tsconfig.json` and
   `vite.config.ts`, plus a Vite config and a scoped TypeScript config per selected environment and

package/dist/host/manifest.json

@@ -4,7 +4,7 @@
 			"storage": "AGENTS.md",
 			"destination": "AGENTS.md",
 			"executable": false,
-			"digest": "152c8e8fb880814be96fb0b0a63524e98bf72125af97edddb72c140d2e3cc0ea"
+			"digest": "691f9fb52acd475a08109b93cdbed18628af36e9363f4803d84176a8117cf53c"
 		},
 		{
 			"storage": "CLAUDE.md",
@@ -22,7 +22,7 @@
 			"storage": "agents/orchestration.md",
 			"destination": ".agents/orchestration.md",
 			"executable": false,
-			"digest": "c8e9931f5cf30d0a5a94ea2a3008904b5833cd534036680ea0fd9618c64d6f54"
+			"digest": "63bacfdcd9b9918fb8302b723a0049bd3bbf74e939a8c1afbe50d0083c1742db"
 		},
 		{
 			"storage": "agents/skills/enterprise-bootstrap/SKILL.md",
@@ -268,7 +268,7 @@
 			"storage": "claude/agents/orkestrel.md",
 			"destination": ".claude/agents/orkestrel.md",
 			"executable": false,
-			"digest": "dc6f528f27980569650b5d8fb3ec21e7adfd50eb815f1c0a4f48bf001b816707"
+			"digest": "8e228a484383a04bf12fa510b3619eb7f38a512ec081ee0870ea7534b314945d"
 		},
 		{
 			"storage": "claude/agents/planner.md",
@@ -316,7 +316,7 @@
 			"storage": "claude/rules/architecture.md",
 			"destination": ".claude/rules/architecture.md",
 			"executable": false,
-			"digest": "32bf977e77fb42cbf16bbcb92d9005d4879b194f5957ad6173c355054bfa0a88"
+			"digest": "94f70c20f927129cf9cb3965b3180a14e941e4f6eddf6512c4adc014e0bcbdf2"
 		},
 		{
 			"storage": "claude/rules/browser.md",
@@ -358,7 +358,7 @@
 			"storage": "claude/rules/tests.md",
 			"destination": ".claude/rules/tests.md",
 			"executable": false,
-			"digest": "6830aafb605cb7123c682b09a0b7cb8fbbb8d62437ac136c9c91d88b7c79149c"
+			"digest": "2f8658425bc48b8751a5526300827c90f22226d4605514ec866891b5be4fabfb"
 		},
 		{
 			"storage": "claude/rules/typescript.md",
@@ -370,7 +370,7 @@
 			"storage": "claude/rules/workspace.md",
 			"destination": ".claude/rules/workspace.md",
 			"executable": false,
-			"digest": "eac73efda50bcf415968538caa83c326ee5e30076d7dadefe07512510e86df22"
+			"digest": "8120bac99d00b4cb0613b0dc6cb4048074c86fdb6f6583be07514229d90bbd07"
 		},
 		{
 			"storage": "claude/rules/writing.md",
@@ -520,7 +520,7 @@
 			"storage": "codex/config.toml",
 			"destination": ".codex/config.toml",
 			"executable": false,
-			"digest": "5aa2e5903a9501fb53a6fa9b58d4e1d18b44e950f88fd928edbc3f5b5aadfc62"
+			"digest": "e67d555ed4381b098b203e14484718e64e5262715d87b3f71857511cff929560"
 		},
 		{
 			"storage": "configs/helpers.ts",
@@ -604,7 +604,7 @@
 			"storage": "guides/scaffold.md",
 			"destination": "guides/scaffold.md",
 			"executable": false,
-			"digest": "b3dec011e6ed02398d162ed2f5c83b1ffbdc834f4d2507f4a216bbe01cf0630f"
+			"digest": "1aace5325608c6880d73a2bae7c02936c26445ef7aff550c43a70333c7be85f6"
 		},
 		{
 			"storage": "scripts/codex.sh",
@@ -634,7 +634,7 @@
 			"storage": "tests/config.test.ts",
 			"destination": "tests/config.test.ts",
 			"executable": false,
-			"digest": "2627f98c2caf3c6a75f4c4659df41191054154ed36d8429c7c6b5c53284a91bf"
+			"digest": "f8ddc2ab6cb54f2b1f51ad9212d7f09881271d265628299e5ce8f536cfec76a7"
 		},
 		{
 			"storage": "tests/policy.test.ts",
@@ -688,5 +688,5 @@
 		".codex/agents",
 		".cursor/rules"
 	],
-	"digest": "d9f1ee5c68e28ef445b74e697d0ce13e7a3dd201911962b77a685b1d29c88c80"
+	"digest": "1472dda0358190ef9900fcdf86fdfb0ed60053b6095ba7b9f1b0efe490cc85ce"
 }

package/dist/host/tests/config.test.ts

@@ -318,6 +318,43 @@ describe('root configuration', () => {
 		expect(callable).not.toContain(inline)
 	})
 
+	it('keeps Vitest invocation fields out of project configurations', () => {
+		const projects = configuration.test?.projects
+		if (!Array.isArray(projects)) throw new Error('The root configuration carries no projects')
+		const factories = projects.filter((row) => typeof row === 'function')
+		if (factories.length === 0)
+			throw new Error('The root configuration registers no project factory')
+		const sentinel = {
+			command: 'sentinel-command',
+			isPreview: true,
+			isSsrBuild: true,
+			mode: 'sentinel-mode',
+			sentinel: true,
+		}
+		for (const factory of factories) {
+			const project: unknown = Reflect.apply(factory, undefined, [sentinel])
+			if (typeof project !== 'object' || project === null) {
+				throw new Error('A project factory returned no configuration')
+			}
+			for (const field of Object.keys(sentinel)) {
+				expect(Object.getOwnPropertyDescriptor(project, field)?.value).toBeUndefined()
+			}
+		}
+
+		const control = Object.defineProperty(() => ({ ...sentinel }), 'name', { value: 'control' })
+		expect(() => {
+			for (const factory of factories.concat(control)) {
+				const project: unknown = Reflect.apply(factory, undefined, [sentinel])
+				if (typeof project !== 'object' || project === null) {
+					throw new Error('A project factory returned no configuration')
+				}
+				for (const field of Object.keys(sentinel)) {
+					expect(Object.getOwnPropertyDescriptor(project, field)?.value).toBeUndefined()
+				}
+			}
+		}).toThrow(/expected/u)
+	})
+
 	it('requires and validates every selected target wrapper', async () => {
 		const required: string[] = []
 		for (const axis of ['src', 'app']) {
@@ -534,6 +571,26 @@ describe('root configuration', () => {
 		)
 	})
 
+	it('rebuilds publishing workspaces before packing', () => {
+		const manifest: unknown = JSON.parse(readFileSync(resolve(root, 'package.json'), 'utf8'))
+		if (typeof manifest !== 'object' || manifest === null) {
+			throw new Error('The package manifest is not a record')
+		}
+		const scripts: unknown = Object.getOwnPropertyDescriptor(manifest, 'scripts')?.value
+		if (typeof scripts !== 'object' || scripts === null) {
+			throw new Error('The package manifest carries no scripts')
+		}
+		const publishes = Object.getOwnPropertyDescriptor(manifest, 'private')?.value !== true
+		const prepack = Object.getOwnPropertyDescriptor(scripts, 'prepack')?.value
+		expect(prepack).toBe(publishes ? 'npm run build' : undefined)
+
+		const controlled = { ...scripts, prepack: 'npm run control' }
+		expect(() => {
+			const control = Object.getOwnPropertyDescriptor(controlled, 'prepack')?.value
+			expect(control).toBe(publishes ? 'npm run build' : undefined)
+		}).toThrow(/expected/u)
+	})
+
 	it('keeps the committed host inventory aligned with the vendored checkout bytes', async () => {
 		// Run this gate against a quiescent checkout. It compares two reads and cannot
 		// distinguish stale committed data from a source edit made while it runs.