@orkestrel/scaffold 0.0.6 → 0.0.7

package/dist/host/CLAUDE.md

@@ -212,7 +212,7 @@ verifies its CLI is present before running and stops with a deviation report nam
 fallback when it is not. Benches are cross-provider reach only: a model native to the running
 harness never crosses a bridge.
 
-Three bench laws apply to every external engine:
+Four bench laws apply to every external engine:
 
 - **Transport by work class.** A short interactive exchange (one bounded question or a
   follow-up on a live thread, expected to finish in about two minutes) may use an MCP
@@ -221,19 +221,27 @@ Three bench laws apply to every external engine:
   session invisibly, while a journal survives any client-side failure.
 - **Journal first.** Every bench invocation leaves a tailable on-disk record under
   `tmp/<bench>/` (`tmp/codex/`, `tmp/cursor/`): the brief as a file, the event stream or
-  output log, and the final answer. The user tails the journal for live progress; the
-  journal's mtime is the liveness signal; the session id in the journal head is the recovery
-  handle. Briefs never travel as fragile shell arguments.
+  output log, and the final answer. Every long exec also carries exactly one Monitor on its
+  journal — a filtered tail that emits milestones (commands run, files changed, agent
+  messages, terminal states) and never the raw event firehose — so progress arrives in the
+  conversation while the journal stays tailable for depth. The filter exits on the exec's
+  terminal event, so the monitor's lifecycle matches the exec's and no watcher outlives its
+  subject. The journal's mtime is the liveness signal; the session id in the journal head is
+  the recovery handle. Briefs never travel as fragile shell arguments.
+- **Tracked, never loose.** Every bench unit is registered in the session task registry at
+  launch — subject, journal path, session id — and completed there at acceptance, so "what is
+  running" always has a first-class answer instead of a recollection of a command.
 - **Ephemeral journals.** Everything under `tmp/` is unit evidence, never committed. Bridges
   never delete journals; the Orchestrator sweeps `tmp/codex/` and `tmp/cursor/` once at
   campaign acceptance, after the final gate evidence is recorded. A journal surviving past
   its campaign is residue.
 
-For a long-running bridge exec the Orchestrator arms a stall watcher on the journal
-(file-exists on the final answer, mtime-stall threshold of a few minutes) instead of trusting
-the bridge to report failure — a wedged bridge is silent, and silence must never read as
-progress. A stalled journal follows the deviation ladder, with the session id from the
-journal head as the recovery handle.
+Every long bench exec is launched by the Orchestrator as a harness-tracked background command
+under a hard time cap, never detached from inside a bridge agent: the harness owns the
+lifecycle, completion re-invokes the session, and the cap kills a wedged bench loudly instead
+of trusting the bridge to report its own failure. A wedged bridge is silent, and silence must
+never read as progress. A stalled journal or a cap-killed exec follows the deviation ladder,
+with the session id from the journal head as the recovery handle.
 
 ### Cursor Grok
 
@@ -244,6 +252,10 @@ journal head as the recovery handle.
   `"$LOCALAPPDATA/cursor-agent/agent.cmd"` — verified with `--version` before first use. Long
   briefs are written to `tmp/cursor/<unit>-brief.md` and the prompt points at the file. The
   tee'd log is the bench's journal.
+- A long ask-mode run obeys the same launch, stream, and ledger discipline as a Codex exec:
+  the Orchestrator starts it as a harness-tracked background command under a time cap,
+  registers the unit in the task registry, and arms one Monitor on the tee'd log for
+  milestones. The `grok` bridge drafts the brief; it never detaches a run and ends its turn.
 - Read-only. `--force` never appears. Nothing it returns is applied.
 - Read the exact model id from `agent models` and store it in `CURSOR_GROK_MODEL`. Never guess
   or substitute.
@@ -260,11 +272,12 @@ journal head as the recovery handle.
 - Reached from Claude Code only through the `codex` role, on journaled, resumable
   `codex exec`; in a Codex session these are native agents.
 - **Every run is journaled and resumable.** `--json` streams the event log to
-  `tmp/codex/<unit>.jsonl` (gitignored; the user tails it live for progress — nobody polls),
-  `--output-last-message` captures the final answer as a file, and the session id from the
-  journal head goes in every bridge report so follow-ups continue the same session via
-  `codex exec resume <session-id>` with context intact. `--output-schema` is available when
-  the Orchestrator wants a machine-checkable return shape.
+  `tmp/codex/<unit>.jsonl` (gitignored; the Monitor emits its milestones and the user tails it
+  for depth — nobody polls), `--output-last-message` captures the final answer as a file, and
+  the session id from the journal head goes in the unit's task registry entry and every bridge
+  report so follow-ups continue the same session via `codex exec resume <session-id>` with
+  context intact. `--output-schema` is available when the Orchestrator wants a
+  machine-checkable return shape.
 - **Transport is chosen by work class.** The MCP wiring (`.mcp.json` registers
   `codex mcp-server`; verified tools `codex` to start a session, `codex-reply` to continue
   one; settings enable project MCP servers without prompting, so the wiring works headless —
@@ -272,19 +285,27 @@ journal head as the recovery handle.
   short interactive exchanges only, and the bridge persists the thread id to
   `tmp/codex/<unit>.session` the moment a response carries it — an interrupted MCP call with
   no persisted id is unrecoverable and treated as failed. Long-running work (audits,
-  implementation units) always uses the journaled CLI: the brief at
-  `tmp/codex/<unit>-brief.md`, one `codex exec --json` streaming to `tmp/codex/<unit>.jsonl`
-  with `--output-last-message`, foreground when it fits the shell cap, backgrounded with the
-  turn ended when it may not — the harness re-invocation is the wait; placeholder loops and
-  wait-promise reports are deviations. Every exec names its working directory with `-C`, and an
-  exec rooted outside a trusted git repository dies at launch unless `--skip-git-repo-check` is
-  passed, so cross-repo and fleet-container work rooted outside a checkout always passes it. A
-  launch is not a launch until the journal grows past its header: the bridge confirms the event
-  stream advanced beyond the session-configured head
-  before it reports the exec started, and treats an instantly-dead journal as a failed launch
-  whose tail is the evidence. Recovery ladder on interruption: persisted-id
-  `codex-reply` re-emission → fresh CLI session with the same brief file → for an interrupted
-  CLI exec, the journal survives and the Orchestrator chooses resume or fresh.
+  implementation units) always uses the journaled CLI, and the Orchestrator — never a bridge
+  agent — launches it as a harness-tracked background command: the brief at
+  `tmp/codex/<unit>-brief.md`, then one
+  `timeout <cap> codex exec --json … < /dev/null > tmp/codex/<unit>.jsonl` with
+  `--output-last-message`, started through the shell's background-task mechanism so the exec
+  appears in the session's task list, its completion re-invokes the session, and the cap kills
+  a wedged bench loudly. Stdin is always closed with `< /dev/null`: a background-launched exec
+  can inherit an open stdin pipe and wedge forever at "Reading additional input from stdin..."
+  before its first event, and a cap kill is the only thing that would ever surface it.
+  The journal remains the durable, resumable record and the session id the recovery handle. A
+  bridge that backgrounds an exec and ends its turn orphans it — no owner, no completion
+  signal, no death notice — so bridges keep two jobs only: drafting briefs and short MCP
+  exchanges. Placeholder wait loops and wait-promise reports are deviations. Every exec names
+  its working directory with `-C`, and an exec rooted outside a trusted git repository dies at
+  launch unless `--skip-git-repo-check` is passed, so cross-repo and fleet-container work
+  rooted outside a checkout always passes it. A launch is not a launch until the journal grows
+  past its header: the Orchestrator confirms the event stream advanced beyond the
+  session-configured head before recording the exec started, and treats an instantly-dead
+  journal as a failed launch whose tail is the evidence. Recovery ladder on interruption:
+  persisted-id `codex-reply` re-emission → fresh CLI session with the same brief file → for an
+  interrupted CLI exec, the journal survives and the Orchestrator chooses resume or fresh.
 - **The inverse bridge exists too:** Claude Code exposes `claude mcp serve`, registered in
   Codex's global config (`codex mcp add claude -- claude mcp serve`) so Codex-primary
   sessions reach Claude/Opus as first-class MCP tools instead of shelling to the CLI.
@@ -294,6 +315,11 @@ journal head as the recovery handle.
 - `implementer` runs `gpt-5.6-sol` at high effort with `--sandbox workspace-write` in the
   main checkout as the sole writer from a clean committed baseline, for bounded
   implementation.
+- **The exec sandbox denies network** (`--unshare-net`). Any unit that needs the registry or
+  any other remote endpoint — lockfile generation, real installs, live fetches — belongs to
+  the Orchestrator's own tracked commands or a network-capable native agent, never to a Codex
+  exec. A Sol exec observed hanging on `npm` until its cap fires is the signature of this
+  misroute, not of a slow bench.
 - Raise the analyst to `xhigh` only for a stated hard reasoning need. `gpt-5.6-terra` serves
   only explicitly mechanical, taste-free roles. `gpt-5.6-luna` requires a proven repeatable,
   high-volume workload.

package/dist/host/guides/src/scaffold.md

@@ -127,49 +127,50 @@ plan.artifacts.some((artifact) => artifact.path === 'app/server/main.ts') // tru
 
 From [`types.ts`](../../src/core/types.ts).
 
-| Name                   | Kind      |
-| ---------------------- | --------- |
-| `Environment`          | type      |
-| `BuildFormat`          | type      |
-| `SrcDefinition`        | interface |
-| `AppDefinition`        | interface |
-| `ViteMachinery`        | interface |
-| `Origin`               | type      |
-| `Group`                | type      |
-| `Category`             | type      |
-| `CatalogEntry`         | interface |
-| `Drift`                | type      |
-| `Freshness`            | type      |
-| `CompileStage`         | type      |
-| `ScaffoldErrorCode`    | type      |
-| `Dependency`           | interface |
-| `Override`             | interface |
-| `Blueprint`            | interface |
-| `Member`               | interface |
-| `ArtifactBase`         | interface |
-| `HostArtifact`         | interface |
-| `ContentArtifact`      | interface |
-| `Artifact`             | type      |
-| `Snapshot`             | type      |
-| `Plan`                 | interface |
-| `Finding`              | interface |
-| `Audit`                | interface |
-| `Question`             | interface |
-| `Validation`           | interface |
-| `GuideSync`            | interface |
-| `VersionSync`          | interface |
-| `SyncReport`           | interface |
-| `PlanSummary`          | interface |
-| `CompileRecord`        | interface |
-| `CompileFailure`       | interface |
-| `Scaffolding`          | interface |
-| `PlanRecord`           | interface |
-| `CompilerEventMap`     | type      |
-| `CompilerOptions`      | interface |
-| `CompilerInterface`    | interface |
-| `PlanManagerEventMap`  | type      |
-| `PlanManagerOptions`   | interface |
-| `PlanManagerInterface` | interface |
+| Name                      | Kind      |
+| ------------------------- | --------- |
+| `Environment`             | type      |
+| `BuildFormat`             | type      |
+| `SrcDefinition`           | interface |
+| `AppDefinition`           | interface |
+| `ViteMachinery`           | interface |
+| `ViteProjectRegistration` | interface |
+| `Origin`                  | type      |
+| `Group`                   | type      |
+| `Category`                | type      |
+| `CatalogEntry`            | interface |
+| `Drift`                   | type      |
+| `Freshness`               | type      |
+| `CompileStage`            | type      |
+| `ScaffoldErrorCode`       | type      |
+| `Dependency`              | interface |
+| `Override`                | interface |
+| `Blueprint`               | interface |
+| `Member`                  | interface |
+| `ArtifactBase`            | interface |
+| `HostArtifact`            | interface |
+| `ContentArtifact`         | interface |
+| `Artifact`                | type      |
+| `Snapshot`                | type      |
+| `Plan`                    | interface |
+| `Finding`                 | interface |
+| `Audit`                   | interface |
+| `Question`                | interface |
+| `Validation`              | interface |
+| `GuideSync`               | interface |
+| `VersionSync`             | interface |
+| `SyncReport`              | interface |
+| `PlanSummary`             | interface |
+| `CompileRecord`           | interface |
+| `CompileFailure`          | interface |
+| `Scaffolding`             | interface |
+| `PlanRecord`              | interface |
+| `CompilerEventMap`        | type      |
+| `CompilerOptions`         | interface |
+| `CompilerInterface`       | interface |
+| `PlanManagerEventMap`     | type      |
+| `PlanManagerOptions`      | interface |
+| `PlanManagerInterface`    | interface |
 
 The closed vocabularies are small and total. `Environment` is `'core' | 'browser' | 'server'`.
 `BuildFormat` is `'es' | 'cjs'`. `Origin` is `'host' | 'template' | 'computed'`. `Group` is
@@ -190,6 +191,10 @@ single-file-component, HTML, and development-server machinery an application bro
 needs, and `output` for build-output containment. It never selects a boundary guarantee — those ship
 in every shape, as the compilers section sets out.
 
+`ViteProjectRegistration` carries one generated project factory identifier and its optional browser
+label. Root configuration renderers preserve that browser ownership as data through registration
+instead of inferring it from a project identifier.
+
 `Blueprint` is the closed input spec:
 
 ```ts
@@ -969,6 +974,7 @@ From [`compilers.ts`](../../src/core/compilers.ts).
 | `packageManifest`       | function |
 | `rootTsconfig`          | function |
 | `viteMachinery`         | function |
+| `renderViteTest`        | function |
 | `viteHeader`            | function |
 | `policyViteProject`     | function |
 | `singleSrcViteConfig`   | function |
@@ -1027,7 +1033,8 @@ emits `environmentBoundary`, its `resolveId` / `load` / `buildEnd` walks, the mo
 plus its `environmentPathError` / `environmentSourceError` clauses). Those enforce owner-independent
 laws: core stays host-independent whatever else the workspace declares, a server module never
 imports a stylesheet, and a `@vite-ignore` dynamic import — which `resolveId` never sees and the
-module graph never records — has no other enforcement point. Only host-specific pipelines vary,
+module graph never records — has no other enforcement point in workspace-owned source. Dependency
+and toolchain modules are outside that ownership boundary. Only host-specific pipelines vary,
 along the three `ViteMachinery` axes:
 
 | Machinery                                                         | Emitted when                         |
@@ -1040,6 +1047,10 @@ along the three `ViteMachinery` axes:
 An application of `app/core` alone is the sole shape that builds nothing, so it is the sole shape
 without output containment — and it still carries every boundary guarantee above.
 
+`renderViteTest` is the single root-project renderer. It consumes ordered
+`ViteProjectRegistration` data and emits either the plain project list or the browser gate, keeping
+source and application root configurations byte-consistent without reconstructing browser ownership.
+
 `coreViteConfig`, `srcViteConfig`, and `appViteConfig` emit the thin per-target wrappers;
 `rootViteConfig`, `singleSrcViteConfig`, and `applicationViteConfig` emit the root configuration for
 a library-only, single non-core `src` environment, and application-bearing workspace respectively;
@@ -1396,7 +1407,7 @@ a fixed, interleaved order so aggregates sit immediately before their per-enviro
   Vue typechecker, every other scope uses plain `tsc`
 - `test`, then `test:src` and its per-environment scopes, `test:app` and its per-environment scopes,
   `test:policy`, and `test:guides`; an engine also receives the deliberately non-default
-  `test:integration` live installed-consumer gate
+  `test:integration` live installed-consumer gate and `test:equivalence` driver-reference proof
 - `build`, then `build:src` and its per-environment targets, `build:app` and its runtime targets, and
   `build:host` for an engine workspace
 - `dev` when a browser application is selected; `serve` and `serve:build` when a server application
@@ -1404,6 +1415,10 @@ a fixed, interleaved order so aggregates sit immediately before their per-enviro
 - `prepublishOnly` chaining `format:check → lint:check → check → build → test`, followed by the
   live generated-consumer integration gate for the scaffold engine itself
 
+Run `npm run test:equivalence` after changing the persistent boundary build driver. It reruns the
+integration project in dual-path mode and proves each programmatic driver verdict against the
+spawned npm-script reference; ordinary integration runs keep the faster driver-only path.
+
 **Environment isolation.** Scoped TypeScript projects remove the wrong host's globals from each
 environment: core scopes carry the WHATWG web-interop surface and no host at all — no DOM, no Node,
 no `vite/client`; browser scopes carry DOM and no Node; server scopes carry Node and no DOM. The
@@ -1451,10 +1466,10 @@ application's module graph through `import.meta.env` instead.
 Asset URLs that force `?inline` are rejected before Vite can read them outside that auditable output
 graph. Dynamic imports must use a static quoted string or expression-free template string; even
 `/* @vite-ignore */` static values repeat the same environment and containment checks inside the
-transform boundary, including inline HTML proxy modules and trusted dependency modules. Trusted
-dependency modules also pass through a bounded, no-follow, identity-checked load inspection before
-Vite transforms or tree-shakes their raw source, so dependency-side asset references cannot escape
-the physical package root by disappearing from the later graph.
+transform boundary, including inline HTML proxy modules. The transform, load, resolution, emitted
+asset, and finished-module-graph passes apply that law only to workspace-owned `src/*` and `app/*`
+modules. Resolved ids under any `node_modules` segment, Vite/Vitest virtual ids, and tooling client
+injections remain owned by their toolchain and are exempt.
 
 Browser application scripts are modules. Vite's parsed HTML asset callback rejects a classic
 external `<script src>` before resolution and directs the author to `type="module"`. A module
@@ -1469,9 +1484,9 @@ path remains Vite-owned and passes through the environment resolver, which rejec
 ASCII control range and every non-Node URL scheme before loading or output. No second HTML parser or global
 reference rewrite is involved, so comments, text, non-script attributes, and entity-spelled asset
 filenames retain Vite's native parsing and resolution behavior.
-The resolver leaves NUL-prefixed Rolldown/Vite virtual module IDs to the tool that owns that
-namespace; author module and asset URLs are extracted and validated before they reach that resolver
-exception.
+The resolver leaves NUL-prefixed and `virtual:` Rolldown/Vite module IDs, tooling client injections,
+and every resolved `node_modules` module to the tool that owns that namespace; author module and
+asset URLs are extracted and validated before they reach those resolver exceptions.
 SVG script `href` and `xlink:href` attributes are parsed too and rejected as classic script loads.
 Inline module scripts enter Vite's HTML proxy graph and receive the same Oxc boundary analysis as
 module files. Classic inline scripts cannot enter that graph, so the required security prologue places
@@ -1511,11 +1526,7 @@ What it rejects is equally deliberate:
   browser or server package subpath;
 - a browser module reaching a Node builtin or a server subpath;
 - a server module reaching a stylesheet, Vue, or a browser subpath;
-- a workspace-relative import that resolves outside the workspace, or a dependency import that
-  escapes the exact physical package root established by the nearest bounded, unlinked
-  `package.json` whose own `name` exactly matches the resolved dependency;
-- a package `#imports` mapping that resolves outside both the declaring package and another exact
-  physical package root;
+- a workspace-relative import that resolves outside the workspace;
 - an HTML reference carrying `vite-ignore` that violates the same environment or containment law
   as an ordinary reference, a Vite `%ENV%` HTML substitution, a classic external script, or a
   computed dynamic import in the module graph that would bypass graph resolution;
@@ -1549,11 +1560,14 @@ host-origin file and run it as a dedicated Node-only `policy` test project over
 **Real browser capability.** Browser test projects are gated on the real executable: the generated
 configuration and the generated policy test both probe `existsSync(chromium.executablePath())`. A
 browser suite runs when a real Chromium is installed and is skipped honestly when it is not, rather
-than being faked. The gate is applied at registration, not only inside the project: without a
-Chromium the browser project is left out of the emitted `projects` list entirely, so the runner
-never has to reconcile a registered project whose include set resolves to nothing, and one printed
-warning names every omitted project label. A machine with a browser runs the browser suite; a
-machine without one runs the remaining projects and says so.
+than being faked. The gate is applied at registration, not inside the real browser project: without
+Chromium, each browser factory is replaced by a same-label Node/no-test placeholder, so generated
+`--project <label>` and `--project=<label>` filters still resolve while no browser code runs. The
+root permits an empty run only when every recognized exact project filter names one of those gated
+placeholders; an unreadable or mixed filter keeps the ordinary no-test failure semantics for its
+Node projects. One printed warning names every gated project label. A machine with a browser
+registers and runs the real browser suites unchanged; a machine without one runs the remaining
+projects and says so.
 
 **Continuous integration.** The generated workflow runs on push and pull request, on
 `ubuntu-latest`, with read-only contents permission, a 60-minute timeout, and a matrix that **tests
@@ -2009,6 +2023,7 @@ import {
 	coreTsconfig,
 	coreViteConfig,
 	policyViteProject,
+	renderViteTest,
 	rootTsconfig,
 	rootViteConfig,
 	singleSrcViteConfig,
@@ -2025,6 +2040,7 @@ appTsconfig('browser', true)
 
 viteMachinery(['core']) // { browser: false, vue: false, output: true }
 viteMachinery([], ['core', 'browser']) // { browser: true, vue: true, output: true }
+renderViteTest([{ project: 'srcCore' }], false).includes('projects: [srcCore]') // true
 viteHeader(viteMachinery([], ['core', 'browser'])) // the shared header, with browser and Vue support
 coreViteConfig()
 srcViteConfig('browser')

package/dist/host/tests/setupPolicy.ts

@@ -51,6 +51,7 @@ export const DATA_SOURCE_FILES: readonly string[] = Object.freeze([
 	'contracts.ts',
 	'relations.ts',
 	'schemas.ts',
+	'shapers.ts',
 	'templates.ts',
 	'validators.ts',
 ])