@orkestrel/scaffold 0.0.30 → 0.0.32

package/dist/host/guides/scaffold.md

@@ -71,8 +71,8 @@ Exported from `@orkestrel/scaffold`, and reachable from
 | `HostArtifact`      | interface | A file byte-copied from the vendored data root, planned before its bytes are read.      |
 | `HydratedArtifact`  | interface | A vendored file whose exact bytes have been read, so its content can be compared.       |
 | `Override`          | interface | One artifact override.                                                                  |
-| `PlanSummary`       | interface | The tally of one plan by artifact origin.                                               |
 | `Plan`              | interface | The compiled, ordered artifact list and the selection it covers.                        |
+| `PlanSummary`       | interface | The tally of one plan by artifact origin.                                               |
 | `Question`          | interface | One validation issue raised against a blueprint or a plan.                              |
 | `Scaffolding`       | interface | The replayable outcome of one compile.                                                  |
 | `SrcDefinition`     | interface | The build and export settings one published `src` environment contributes.              |
@@ -94,20 +94,22 @@ Exported from `@orkestrel/scaffold`, and reachable from
 | `CONFIG_TEMPLATES`                | const | Formatter-stable template text for every configuration artifact.                                 |
 | `CONFORMANCE_TEST_PATH`           | const | The official-tooling drift proof whose presence makes a workspace `conformance`.                 |
 | `CONTROL_CHARACTER_PATTERN`       | const | Unicode controls, formatting controls, and line and paragraph separators rejected in text.       |
+| `DECLARATION_DEV_DEPENDENCIES`    | const | The development dependencies that emit declarations for published source or an executable.       |
 | `DEFAULT_ENGINES`                 | const | The `engines.node` range a workspace starts with.                                                |
 | `DEFAULT_VERSION`                 | const | The version a workspace starts at.                                                               |
 | `DEPENDENCY_NAME_PATTERN`         | const | The runtime dependency name syntax: the `@orkestrel` scope and a bare name.                      |
+| `DISTRIBUTION_TEST_PATH`          | const | The packed-package proof whose presence makes a workspace `distribution`.                        |
 | `ENGINES_PATTERN`                 | const | The minimum-Node engine syntax a blueprint declares.                                             |
 | `ENVIRONMENTS`                    | const | The three `Environment` values, frozen.                                                          |
+| `EXECUTABLE_PATHS`                | const | The vendored paths a target receives with its executable bit set, frozen.                        |
 | `EXTRA_NAME_PATTERN`              | const | The development extra name syntax: any valid npm package name.                                   |
 | `EXTRA_RANGE_PATTERN`             | const | The registry-only semver subset accepted for a development extra's range.                        |
 | `GLOBAL_SETUP_PATH`               | const | The shared Vitest global-setup module whose presence makes a workspace `global`.                 |
-| `GUIDES_TEST_PATH`                | const | The guide-parity proof whose physical file selects the fixed `guides` project.                   |
-| `EXECUTABLE_PATHS`                | const | The vendored paths a target receives with its executable bit set, frozen.                        |
 | `GROUPS`                          | const | The seven `Group` values in plan order, frozen.                                                  |
+| `GUIDES_TEST_PATH`                | const | The guide-parity proof whose presence selects the planned `guides` project.                      |
 | `HEX_PATTERN`                     | const | Exact lowercase hexadecimal bytes: two digits per byte, and empty content is valid.              |
 | `HOST_PATHS`                      | const | The paths byte-copied from the vendored data root, frozen.                                       |
-| `INTEGRATION_TEST_PATH`           | const | The installed-package proof whose presence makes a workspace `integration`.                      |
+| `INTEGRATION_TEST_PATH`           | const | The cross-environment composition proof whose presence makes a workspace `integration`.          |
 | `INVALID_PATH_CHARACTER_PATTERN`  | const | Visible characters a target-relative path and a Markdown path cell both forbid.                  |
 | `MAX_ARTIFACT_BYTES`              | const | Maximum bytes accepted for one artifact.                                                         |
 | `MAX_ARTIFACT_HEX_LENGTH`         | const | Maximum length of the hexadecimal string carrying one artifact's bytes.                          |
@@ -124,6 +126,7 @@ Exported from `@orkestrel/scaffold`, and reachable from
 | `ORCHESTRATION_PATH_NAMES`        | const | The exact root filenames that wire an agent bench rather than the toolchain, frozen.             |
 | `ORCHESTRATION_PATH_PREFIXES`     | const | The path prefixes whose contents instruct or wire an agent, frozen.                              |
 | `ORKESTREL_RANGE_PATTERN`         | const | The exact caret-pinned pre-1.0 range accepted for an `@orkestrel/*` runtime dependency.          |
+| `PRINT_WIDTH`                     | const | Columns one emitted line may occupy, matching `printWidth` in `.oxfmtrc.json`.                   |
 | `SERVICE_SCRIPT_PATH`             | const | The provisioner skeleton a workspace with declared service vendors is given once.                |
 | `SERVICE_SETUP_PATH`              | const | The live-service readiness module whose presence makes a workspace `service`.                    |
 | `SERVICE_TEST_INCLUDE`            | const | The include the live-service project covers, which is a directory rather than one proof.         |
@@ -131,7 +134,9 @@ Exported from `@orkestrel/scaffold`, and reachable from
 | `SHOWCASE_DEV_DEPENDENCIES`       | const | The development dependency used only by the optional single-file showcase build.                 |
 | `SOURCE_BROWSER_DEV_DEPENDENCIES` | const | The development dependencies a published browser `src` environment adds.                         |
 | `SRC_MATRIX`                      | const | The build and export settings each published `src` environment contributes, frozen.              |
+| `TAB_WIDTH`                       | const | Columns one tab occupies when the formatter measures a line, matching `tabWidth`.                |
 | `VERSION_PATTERN`                 | const | The exact three-component version syntax a blueprint declares.                                   |
+| `WORKSPACE_OWNED_PATHS`           | const | The vendored paths whose present bytes belong to each workspace, frozen.                         |
 
 #### Guards
 
@@ -145,8 +150,8 @@ Exported from `@orkestrel/scaffold`, and reachable from
 | `isCompilerHooks`   | const    | Narrow a value to the compiler's initial listener record.                        |
 | `isCompilerOptions` | const    | Narrow a value to `CompilerOptions`.                                             |
 | `isContent`         | const    | Narrow a value to text this package will accept as one artifact's content.       |
-| `isDependencyName`  | const    | Narrow a value to the scoped package name a runtime dependency carries.          |
 | `isDependency`      | const    | Narrow a value to a `Dependency`.                                                |
+| `isDependencyName`  | const    | Narrow a value to the scoped package name a runtime dependency carries.          |
 | `isEnvironment`     | const    | Narrow a value to one `Environment` a workspace may select.                      |
 | `isFinding`         | const    | Narrow a value to a `Finding`.                                                   |
 | `isGroup`           | const    | Narrow a value to one `Group` a plan selects over.                               |
@@ -189,9 +194,10 @@ Exported from `@orkestrel/scaffold`, and reachable from
 | `matchesDriftReachability`  | function | Test whether `inferDrift` could have produced a finding for an ownership.     |
 | `matchesEngines`            | function | Test whether a declared engines floor is at or above the supported minimum.   |
 | `matchesOrchestrationPath`  | function | Test whether a path instructs or wires an agent rather than the toolchain.    |
+| `matchesPrintWidth`         | function | Test whether one emitted line fits the vendored formatter width.              |
 | `matchesRange`              | function | Test whether a declared range already admits a published version.             |
 | `nameToGuide`               | function | Derive the guide mirror path a package name answers for.                      |
-| `nameToRewrite`             | function | Derive the declaration rewrite a published face roll-up applies.              |
+| `nameToRewrite`             | function | Derive the declaration rewrite a published face's `beforeWriteFile` applies.  |
 | `planToSummary`             | function | Project a plan into its tally by artifact origin.                             |
 | `selectGroups`              | function | Select the groups a compile covers, in plan order.                            |
 | `selectHostPaths`           | function | Select the host paths a named workspace vendors.                              |
@@ -458,9 +464,10 @@ An option a verb does not list is refused by name rather than parsed and ignored
 the registry, so `new` fails when the registry names no release for a package it was given: the
 workspace would otherwise declare a dependency that does not resolve.
 
-`new --bin` creates the executable entry, its test, and its scoped Vite and TypeScript wrappers.
-The other structural facts do not need creation flags. Add `tests/integration.test.ts` for
-`integration`, `tests/conformance.test.ts` for `conformance`, `tests/setupService.ts` for `service`,
+`new --bin` creates the executable entry, its test, and its scoped Vite and TypeScript wrappers. The
+other structural facts do not need creation flags. Add `tests/guides.test.ts` for `guides`,
+`tests/distribution.test.ts` for `distribution`, `tests/integration.test.ts` for `integration`,
+`tests/conformance.test.ts` for `conformance`, `tests/setupService.ts` for `service`,
 `tests/setupGlobal.ts` for `global`, and `configs/app/vite.showcase.config.ts` for `showcase`;
 reading verbs detect each exact-case file and register its fixed machinery. Add `scripts/service.sh`
 for `vendors`. Reading verbs preserve and protect that birth-owned script, but do not infer its
@@ -471,8 +478,9 @@ vendor list from edited text.
 `audit`, `repair`, `catalog`, and `overwrite` derive the blueprint from the target itself. The name
 and the declared `@orkestrel/*` packages come from `package.json`. The two environment axes come
 from the directories the target actually ships, because a directory is the fact and a declaration
-beside it could disagree. Six more facts come from exact-case files: `src/bin/main.ts` selects
-`bin`, `tests/integration.test.ts` selects `integration`, `tests/conformance.test.ts` selects
+beside it could disagree. Eight more facts come from exact-case files: `src/bin/main.ts` selects
+`bin`, `tests/guides.test.ts` selects `guides`, `tests/distribution.test.ts` selects `distribution`,
+`tests/integration.test.ts` selects `integration`, `tests/conformance.test.ts` selects
 `conformance`, `tests/setupService.ts` selects `service`, `tests/setupGlobal.ts` selects `global`,
 and `configs/app/vite.showcase.config.ts` selects `showcase`. A containing directory does not select
 the fact by itself.
@@ -488,27 +496,43 @@ cannot recover would leave every such workspace unplannable. `tests/setupService
 is the module the root configuration names by path, and is what a live proof needs anyway, so it
 carries the fact and the vendor list keeps its own separate job.
 
-The root Vite configuration always defines the fixed `guides` project and selects it at
-configuration load 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. A workspace that later adds the proof keeps the project through `repair`. The
-birth-owned manifest still gains no `test:guides` script automatically; the developer who adds the
-proof adds that script too.
-
-The three plan-reading verbs compare every Vitest project named by the target manifest's scripts
-with the project set the planned root configuration will load. One shell-token pass reads quoted and
-unquoted `--project value` and `--project=value` forms. A shell expansion or malformed quote that
-prevents a project value from being resolved statically produces a question instead of licensing a
-write. The classifier is deliberately bounded to manifest script text that names `vitest`; an
-external wrapper whose name does not identify its runner supplies no static Vitest fact to infer.
+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.
+
+The three 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
+reachable from the manifest's `test` chain. A target whose manifest does not set `private: true` may
+also reach it from `prepublishOnly`. A private target cannot use that chain, because npm refuses the
+package before a publish lifecycle script runs, so crediting it would report a dead gate as a live
+one. Generated integration runs from `test`. One shell-token pass reads quoted and unquoted
+`--project value` and `--project=value` forms and follows literal `npm run` calls. A shell expansion
+or malformed quote that prevents a project or script name from being resolved statically produces a
+question instead of licensing a write. The classifier is deliberately bounded to manifest script
+text that names `vitest`; an external wrapper whose name does not identify its runner supplies no
+static Vitest fact to infer.
 
 `audit` still completes the comparison and reports one non-blocking `projects` question. For a
 literal absent project, its advisory tells the developer to register the project or remove the
-script. `repair` and `overwrite` refuse instead. Their refusal tells the developer to remove the
+script. For a planned project absent from both gate chains, the advisory gives the exact direct
+script line to add to `package.json`. `repair` and `overwrite` refuse either mismatch and do not
+write the manifest or configuration. Their absent-project refusal tells the developer to remove the
 script or not use scaffold writing verbs for a workspace that needs custom Vitest projects. It does
 not recommend editing the content-owned configuration that the refusing verb would restore. An
 advisory alone does not make an aligned target drift.
 
+The same three plan-reading verbs compare the tooling set the derived blueprint plans against
+`dependencies` and `devDependencies` together. A missing planned package produces one non-blocking
+`dependencies` question naming every missing package and the exact manifest lines to add, in stable
+order. The comparison measures membership only: range differences and workspace-owned extras are
+outside it, and a planned tool may live in either section. A present section that is not an object
+produces a question instead of a crash. `audit` reports the question without changing its exit
+semantics. `repair` and `overwrite` refuse before writing configuration, and no verb edits the
+birth-owned `package.json`.
+
 ### Exit codes
 
 `0` means the target matched its plan and every step completed. `1` means the target drifted or a
@@ -572,22 +596,50 @@ because the shape is chosen once and read afterwards: `new` refuses the advisory
 `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.
 
-`bin`, `integration`, `conformance`, `service`, `vendors`, `global`, and `showcase` are structural
-facts. Each is set only when the workspace physically ships the directory or exact-case file that
-defines it, never because of the workspace's name and never because a sibling fact is set.
+`bin`, `guides`, `distribution`, `integration`, `conformance`, `service`, `vendors`, `global`, and
+`showcase` are structural facts. Each is set only when the workspace physically ships the directory
+or exact-case file that defines it, never because of the workspace's name and never because a
+sibling fact is set.
+
+A structural fact is read when a verb runs, not when the file appears. Writing
+`tests/integration.test.ts` into a workspace sets the fact, but the root configuration on disk was
+generated before that file existed and still registers no `integration` project, so `test:config`
+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.
+
+Adding a structural proof is therefore three 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.
+
+`distribution` projects only when the workspace also publishes at least one `src` environment. It
+packs and installs the published artifact, so without that axis there is nothing to pack, and the
+declared flag alone adds no project, no `test:distribution` script, and no gate entry.
 
 `service` says the workspace runs a live-service Vitest project over `tests/service`, and it alone
 registers that project, its `test:service` script, and the `tests/setupService.ts` readiness module
-the project names. `vendors` names each external service the workspace drives and emits
-`scripts/service.sh`, the provisioner that starts them. Neither is derivable from the other: a
-workspace may declare vendors before it writes a suite, and a suite may drive a service the skeleton
-does not start.
-
-An axis-dependent structural fact projects only when its required axis exists. `integration`
-projects a published `src`, and `showcase` projects the browser `app` environment. When that axis is
-absent the flag adds no artifact, configuration, script, or dependency, and the gate reports a
-non-blocking question on that field so the caller who set it learns it emitted nothing. The same
-rule applies to both facts.
+the project names. A publishing workspace invokes it from `prepublishOnly`; a `private: true`
+workspace invokes it from `test`, which is the only gate it has. Its longer timeouts and disabled
+file parallelism are the same in both. `vendors` names each external service the workspace drives
+and emits `scripts/service.sh`, the provisioner that starts them. Neither is derivable from the
+other: a workspace may declare vendors before it writes a suite, and a suite may drive a service the
+skeleton does not start.
+
+`integration` projects a cross-environment composition proof for any workspace, independently of
+whether it has a published `src`. Its generated seed imports every selected `src` and `app`
+environment through its public barrel. It starts no process and does not pack or install the
+workspace. The proof composes across environments, so when `src` and `app` together declare fewer
+than two the gate reports a non-blocking `integration` question: the project, the script, and the
+`test` entry are all still registered, and the advisory reports that the seed composes nothing
+rather than withholding it.
+
+`showcase` projects only when the browser `app` environment exists. Without that axis the flag adds
+no artifact, configuration, script, or dependency, and the gate reports a non-blocking question on
+that field so the caller who set it learns it emitted nothing.
 
 `createBlueprint` enforces shape only. Whether the name is a name, the version a version, and the
 axis combination one this package can generate are the gate's laws, and the gate answers them with
@@ -688,15 +740,21 @@ content is produced. `Ownership` says what scaffold claims at the path.
 | `presence`  | Existence only | Restore an absent file, never touch present bytes |
 | `birth`     | Nothing        | Create the file only while it is absent           |
 
+Presence ownership has two separate mechanisms, and a reader needs to know which applies:
+
+| Mechanism       | Paths                                             | Bytes belong to       | Cost                                                    |
+| --------------- | ------------------------------------------------- | --------------------- | ------------------------------------------------------- |
+| Verb-owned      | `CATALOG_AGENT_PATH` and dependency guide mirrors | `catalog` or `mirror` | The owning verb is the only route for a later update.   |
+| Workspace-owned | `WORKSPACE_OWNED_PATHS`, currently `.gitignore`   | The target workspace  | Present bytes receive no later canonical ignore update. |
+
 Birth ownership is what makes a generated workspace the consumer's. `package.json`, the source
 barrels, the tests, `README.md`, and `guides/README.md` are written once and are never rewritten by
 a later verb.
 
 Content ownership does not preserve an arbitrary custom Vitest project. Fixed optional proofs are
-selected by their defining paths, as `guides`, `conformance`, and `service` are. A workspace that
-needs other local configuration
-must keep those edits outside a content-owned file; `repair` restores that file to the canonical
-project set.
+selected by their defining paths, as `guides`, `distribution`, `integration`, `conformance`, and
+`service` are. A workspace that needs other local configuration must keep those edits outside a
+content-owned file; `repair` restores that file to the canonical project set.
 
 An audit reports one `Finding` per planned path, followed by any foreign path beneath the groups
 the plan covers. Every planned finding carries its artifact's `ownership`. A foreign finding has
@@ -840,7 +898,10 @@ except the manifest.
   selection declares the `playwright` this module imports.
 - One template artifact per source and test file the selection needs: an `index.ts` barrel per
   selected environment, `main.ts` and `index.html` for an application browser, `tests/setup.ts`
-  plus the host setup modules the selection reaches, and one entry test per axis project.
+  plus the host setup modules the selection reaches, and one entry test per axis project. An
+  integration selection also emits a birth-owned `tests/integration.test.ts` seed that imports each
+  selected public barrel and records its initial empty exports for the consumer to replace with an
+  observable cross-environment flow.
 - One template artifact each for `README.md` and `guides/README.md`.
 - One host artifact per vendored path the workspace selects. A vendored directory is one planned
   path that expands into the files the data root stores beneath it.
@@ -998,7 +1059,7 @@ proves that every fence imports only real exports of the two barrels, and that e
 in this file resolves to one. It neither runs a fence nor typechecks one, so a trailing `// value`
 comment inside a fence states what this guide claims rather than what the build answered. The
 verdicts that are measured are the ones a consumer hovers:
-[`tests/integration.test.ts`](../tests/integration.test.ts) drives every `@example` the built
+[`tests/distribution.test.ts`](../tests/distribution.test.ts) drives every `@example` the built
 declarations print against the installed package, scores each verdict it can read as a value, and
 names exactly the ones it cannot. Fences are not added to that instrument, because most of them
 cannot be run: several declare an ambient value that has no runtime, and several write to a
@@ -1043,29 +1104,43 @@ nothing. This is deliberate: a generated sample entity is repeatedly mistaken fo
 implementation. What a consumer does first is write the module's `types.ts`, then the
 implementation that conforms to it, then export both from the barrel — the order `AGENTS.md` fixes.
 
-**A conformance or live-service proof is registered, but neither is written for you.** Scaffold
-registers the `conformance` and `service` projects, their scripts, and the gate each belongs to. It
-emits no proof into either, because both name something only the package knows: the official
-artifact a conformance check measures against, and the service a live proof drives. A generated
-placeholder would read as a proof while measuring nothing, so the file a consumer writes is the file
-that selects the project.
-
-The consequence is one empty-project case in each direction. A blueprint carrying `conformance` with
-no `tests/conformance.test.ts` registers a project whose include resolves to nothing, and Vitest
-exits non-zero on it. A blueprint carrying `service` gets `tests/setupService.ts` — the root
-configuration names that module by path, so an absent one fails the project's load rather than its
-run — and still no suite beneath `tests/service`, so `test:service` reports no test files until the
-consumer writes the first one. Both cases are visible the first time the script runs, which is why
-neither is silent.
-
-Neither project folds into `integration`, which means something narrower: the built package works
-when installed and driven from outside. Two fleet packages hold the distinction. `@orkestrel/ollama`
-drives a real Ollama daemon through a `service` project, so a real service answers it and it runs
-from `prepublishOnly`. `@orkestrel/mcp` measures its server against the specification's own runner,
-`@modelcontextprotocol/conformance`, through a `conformance` project. It pins that runner as a
-development dependency and resolves it out of `node_modules`, and the server the runner drives is
-one the fixture starts itself on a loopback port, so the run drives nothing external and stays in
-`test`.
+**A selected distribution, conformance, or live-service proof is registered, but none is written for
+you.** Scaffold registers `conformance` and `service` when their structural facts are set, and
+registers `distribution` only when the workspace also publishes `src`. In a publishing workspace,
+`distribution` and `service` run from `prepublishOnly` and `conformance` stays in `test`. In a
+`private: true` workspace, `distribution` is absent, `service` runs from `test`, and there is no
+`prepublishOnly` at all. Scaffold emits no proof into any registered project, because each names
+something only the package knows: the behavior its own packed artifact must hold once installed, the
+official artifact a conformance check measures against, and the service a live proof drives. A
+generated placeholder would read as a proof while measuring nothing, so the file a consumer writes
+is the file that selects the project.
+
+A distribution proof carries one contract scaffold does enforce from the outside. The generated
+`prepublishOnly` invokes it as `npm run test:distribution -- --mode release`, and a proof that reads
+`import.meta.env.MODE === 'release'` must **fail** on an unreachable registry rather than skip. An
+ordinary local run may skip that case, because a developer offline is not a defect; a release run
+may not, because skipping there passes the publish gate without ever proving the artifact installs.
+Scaffold writes no proof, so honouring the flag is the consumer's, and a proof that ignores it
+reports green on exactly the runs that matter.
+
+The consequence is one empty-project case per registered proof. A publishing blueprint carrying
+`distribution` with no `tests/distribution.test.ts`, or any blueprint carrying `conformance` with no
+`tests/conformance.test.ts`, registers a project whose include resolves to nothing, and Vitest exits
+non-zero on it. A blueprint carrying `service` gets `tests/setupService.ts` — the root configuration
+names that module by path, so an absent one fails the project's load rather than its run — and still
+no suite beneath `tests/service`, so `test:service` reports no test files until the consumer writes
+the first one. Every case is visible the first time the script runs, which is why none is silent.
+
+None of the three folds into `integration`, which measures a different axis rather than a smaller
+one: the workspace's selected environments compose through their public barrels. The generated seed
+proves only that those barrels load together and expose the initial empty surfaces; the consumer
+replaces it with an observable cross-environment flow. The seed starts no process and does not pack
+or install the workspace, so the project stays in `test`. Two fleet packages hold the distinction.
+`@orkestrel/ollama` drives a real Ollama daemon through a `service` project, so a real service
+answers it and it runs from `prepublishOnly`. `@orkestrel/mcp` measures its server against the
+specification's own runner, `@modelcontextprotocol/conformance`, through a `conformance` project. It pins that runner as a development dependency and resolves it out
+of `node_modules`, and the server the runner drives is one the fixture starts itself on a loopback
+port, so the run drives nothing external and stays in `test`.
 
 ## Tests
 

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

@@ -42,7 +42,7 @@ describe('root configuration', () => {
 			for (const key of required.keys()) {
 				if (!absent.has(key)) throw new Error('The alias population carries no required entry')
 			}
-		}).toThrowError('The alias population carries no required entry')
+		}).toThrow('The alias population carries no required entry')
 		for (const [key, expected] of required) {
 			const values = declared.get(key)
 			if (values === undefined) throw new Error(`${key} is not declared`)
@@ -102,7 +102,14 @@ describe('root configuration', () => {
 				setup: ['./tests/setup.ts', './tests/setupServer.ts'],
 			})
 		}
-		for (const label of ['policy', 'config', 'guides', 'conformance', 'integration']) {
+		for (const label of [
+			'policy',
+			'config',
+			'guides',
+			'conformance',
+			'distribution',
+			'integration',
+		]) {
 			if (!existsSync(resolve(root, `tests/${label}.test.ts`))) continue
 			expected.set(label, {
 				include: `tests/${label}.test.ts`,
@@ -218,7 +225,7 @@ describe('root configuration', () => {
 		expect(missing.delete('probe')).toBe(true)
 		expect(() => {
 			for (const [label, project] of expected) expect(missing.get(label)).toStrictEqual(project)
-		}).toThrowError(/strictly equal/u)
+		}).toThrow(/strictly equal/u)
 
 		const misconfigured = new Map(configured)
 		const probe = misconfigured.get('probe')
@@ -227,7 +234,7 @@ describe('root configuration', () => {
 		expect(() => {
 			for (const [label, project] of expected)
 				expect(misconfigured.get(label)).toStrictEqual(project)
-		}).toThrowError(/strictly equal/u)
+		}).toThrow(/strictly equal/u)
 	})
 
 	it('requires and validates every selected target wrapper', async () => {
@@ -344,10 +351,10 @@ describe('root configuration', () => {
 		const controlFound = ['configs/app/vite.server.config.ts']
 		expect(() => {
 			for (const wrapper of controlRequired) expect(controlFound).toContain(wrapper)
-		}).toThrowError(/vite\.browser/u)
-		expect(() =>
-			expect(resolve(root, 'dist/actual')).toBe(resolve(root, 'dist/control')),
-		).toThrowError(/expected/u)
+		}).toThrow(/vite\.browser/u)
+		expect(() => expect(resolve(root, 'dist/actual')).toBe(resolve(root, 'dist/control'))).toThrow(
+			/expected/u,
+		)
 	})
 
 	it('registers proof scripts in the correct gate', () => {
@@ -359,8 +366,10 @@ describe('root configuration', () => {
 		if (typeof scripts !== 'object' || scripts === null) {
 			throw new Error('The package manifest carries no scripts')
 		}
+		const publishes = Object.getOwnPropertyDescriptor(manifest, 'private')?.value !== true
 		const test = Object.getOwnPropertyDescriptor(scripts, 'test')?.value
 		const config = Object.getOwnPropertyDescriptor(scripts, 'test:config')?.value
+		const distribution = Object.getOwnPropertyDescriptor(scripts, 'test:distribution')?.value
 		const integration = Object.getOwnPropertyDescriptor(scripts, 'test:integration')?.value
 		const conformance = Object.getOwnPropertyDescriptor(scripts, 'test:conformance')?.value
 		const service = Object.getOwnPropertyDescriptor(scripts, 'test:service')?.value
@@ -390,24 +399,39 @@ describe('root configuration', () => {
 		expect(registered.has('config')).toBe(true)
 		expect(registered.has('control')).toBe(false)
 		const hasConformance = registered.has('conformance')
+		const hasDistribution = registered.has('distribution')
 		const hasService = registered.has('service')
 		expect(config).toBe(
 			'vitest run --config vite.config.ts --no-cache --reporter=dot --project config',
 		)
 		expect(typeof test === 'string' && test.includes('npm run test:config')).toBe(true)
+		expect(distribution).toBe(
+			hasDistribution
+				? 'vitest run --config vite.config.ts --no-cache --reporter=dot --project distribution'
+				: undefined,
+		)
+		expect(typeof test === 'string' && test.includes('test:distribution')).toBe(false)
+		expect(typeof publish === 'string' && publish.includes('npm run test:distribution')).toBe(
+			hasDistribution && publishes,
+		)
+		expect(typeof publish === 'string').toBe(publishes)
 		expect(integration).toBe(
 			hasIntegration
 				? 'vitest run --config vite.config.ts --no-cache --reporter=dot --project integration'
 				: undefined,
 		)
-		expect(typeof test === 'string' && test.includes('test:integration')).toBe(false)
-		expect(typeof publish === 'string' && publish.includes('npm run test:integration')).toBe(
+		// The integration seed composes barrels and starts no process, so it runs in
+		// `test` like any other hermetic proof. `prepublishOnly` reaches it through
+		// `npm test` rather than through a second direct invocation.
+		expect(typeof test === 'string' && test.includes('npm run test:integration')).toBe(
 			hasIntegration,
 		)
+		expect(typeof publish === 'string' && publish.includes('npm run test:integration')).toBe(false)
 		// A registered project no gate runs is a proof that never executes, and it
 		// never fails, so the suite reports green while carrying it. Conformance is
-		// hermetic and belongs to `test`; the live-service project drives a real
-		// service and belongs to `prepublishOnly` alone.
+		// hermetic and belongs to `test`. A publishing workspace isolates the
+		// live-service project in `prepublishOnly`; a private workspace reaches it
+		// from `test`, because npm never runs a private package's publish lifecycle.
 		expect(conformance).toBe(
 			hasConformance
 				? 'vitest run --config vite.config.ts --no-cache --reporter=dot --project conformance'
@@ -421,8 +445,12 @@ describe('root configuration', () => {
 				? 'vitest run --config vite.config.ts --no-cache --reporter=dot --project service'
 				: undefined,
 		)
-		expect(typeof test === 'string' && test.includes('test:service')).toBe(false)
-		expect(typeof publish === 'string' && publish.includes('npm run test:service')).toBe(hasService)
+		expect(typeof test === 'string' && test.includes('npm run test:service')).toBe(
+			hasService && !publishes,
+		)
+		expect(typeof publish === 'string' && publish.includes('npm run test:service')).toBe(
+			hasService && publishes,
+		)
 	})
 })
 
@@ -562,9 +590,9 @@ describe('configuration helpers', () => {
 		expect(() => configHelpers.enforceOutputPath(expected, expected)).not.toThrow()
 		expect(() =>
 			configHelpers.enforceOutputPath(resolve(root, 'dist/outside-control'), expected),
-		).toThrowError('Build output must use its exact configured workspace directory')
+		).toThrow('Build output must use its exact configured workspace directory')
 		const outside = resolve(dirname(root), 'outside-config-control')
-		expect(() => configHelpers.enforceOutputPath(outside, outside)).toThrowError(
+		expect(() => configHelpers.enforceOutputPath(outside, outside)).toThrow(
 			'Build output must remain inside the workspace',
 		)
 	})
@@ -611,7 +639,7 @@ describe('configuration helpers', () => {
 				error: expect.unreachable,
 				resolve: Promise.resolve.bind(Promise, { id: source }),
 			}
-			await expect(Reflect.apply(hook, context, ['@src/server', source])).rejects.toThrowError(
+			await expect(Reflect.apply(hook, context, ['@src/server', source])).rejects.toThrow(
 				'Browser modules cannot depend on Node or server-only modules',
 			)
 			await expect(Reflect.apply(hook, context, ['@src/core', source])).resolves.toBeNull()