The provider sandbox never ran. bubblewrap 0.9.0 stops parsing an `--args` file at the first non-option and never hands the remainder back, so the command written into that file was silently dropped: bwrap printed its usage text, exited 1, and the provider produced no evidence at all. The options still travel in the args file — that is what keeps host paths and credentials out of `/proc/<pid>/cmdline` — but the command now rides on real argv, and `encodeProviderBwrapInput` refuses a `--` so the drop cannot come back. The scope wrapper then could not exit. It read the supervisor's liveness pipe through `fs`, which runs a blocking `read(2)` on a threadpool thread; the supervisor holds that pipe open for the scope's whole life, so the read never returned and closing the descriptor did not interrupt it. Once bubblewrap finished the wrapper deadlocked in `process.exit`, the scope outlived the provider, and a completed run was reported as a timeout kill. The channel is now read through the event loop, so teardown is observable and terminal. Creation modes were left to the ambient umask. `mkdir(mode)` and `open(mode)` are requests the kernel subtracts the umask from, so a runner exporting a restrictive umask produced directories it could not enter and handed `tar` a file it could not re-open. Private modes are pinned instead of inherited. Promotion cleanup deleted before it checked. Removals run through a pinned descriptor, so a leaf substituted after validation had this promotion's exact five destroyed first and the substitution reported afterwards, leaving a half-emptied directory a retry could not tell from a completed one. The name is re-bound to the inode before anything is removed, so the failure is total. Separately, release coherence proved the artifacts agreed with each other but never that they belonged where they were going: a build whose runtime document said `APP_ENV: local`, `AUTH_MODE: demo` and a loopback API is coherent with itself and passed every gate. `public/` is copied verbatim into `dist/`, so that local document shipped with every build regardless of what the build was for. Runtime configuration now comes from a declared profile, and FE-GATE-027 refuses to admit an artifact to an environment it does not match — including refusing an undeclared destination, so nothing is admitted by omission. `REQUEST_TIMEOUT_MS` and `VITE_ROUTER_BASE_PATH` were validated and then dropped: the V3 executor ran every operation on its contract's own deadline, and Vite emitted root-absolute assets for a sub-path deployment. The timeout is now a ceiling that may tighten a contract but never loosen one, and one base path feeds the router, the Service Worker scope and the asset base together. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
71 lines
2.4 KiB
TypeScript
71 lines
2.4 KiB
TypeScript
import { spawnSync } from "node:child_process";
|
|
import { rm } from "node:fs/promises";
|
|
import process from "node:process";
|
|
|
|
import { INSTALLED_RUNTIME_CAPABILITIES } from "../src/features/installed-runtime-capabilities.ts";
|
|
|
|
/**
|
|
* §17.2.2. Deterministic two-pass build.
|
|
*
|
|
* The Service Worker needs the exact hashed asset list at compile time, so the
|
|
* order is fixed:
|
|
*
|
|
* 1. clean dist and .generated/frontend-runtime
|
|
* 2. generate contractSet and build-info source
|
|
* 3. Vite app build (emptyOutDir = true)
|
|
* 4. materialize dist/config.json from the declared APP_PROFILE
|
|
* 5. scan app dist and generate the static asset source
|
|
* 6. ACTIVE only: Vite Service Worker build (emptyOutDir = false)
|
|
* 7. generate Release Manifest V2 and the build manifest
|
|
*
|
|
* Steps 5 and 6 are skipped for `REMOVE_REGISTRATION`, `PURGE_OWNED_RESOURCES`
|
|
* and `null`: those modes never run an active worker build.
|
|
*
|
|
* Step 4 has to follow the Vite build and precede the asset scan. Vite copies
|
|
* `public/` verbatim, so without it every build — including a production one —
|
|
* ships the local runtime document; and the Service Worker hashes the emitted
|
|
* `config.json`, so the profile must be in place before that inventory is
|
|
* taken.
|
|
*/
|
|
|
|
const selection = INSTALLED_RUNTIME_CAPABILITIES.serviceWorker;
|
|
const buildsActiveWorker = selection?.mode === "ACTIVE";
|
|
|
|
function run(command: string, args: readonly string[]): void {
|
|
const result = spawnSync(command, [...args], {
|
|
stdio: "inherit",
|
|
env: process.env,
|
|
});
|
|
if (result.status !== 0) {
|
|
process.stderr.write(`build step failed: ${command} ${args.join(" ")}\n`);
|
|
process.exit(result.status ?? 1);
|
|
}
|
|
}
|
|
|
|
// 1. clean
|
|
await rm("dist", { recursive: true, force: true });
|
|
await rm(".generated/frontend-runtime", { recursive: true, force: true });
|
|
|
|
// 2. contract set + build info
|
|
run("node", ["scripts/generate-contract-set.ts"]);
|
|
|
|
// 3. app build
|
|
run("npx", ["vite", "build"]);
|
|
|
|
// 4. runtime config for the declared profile
|
|
run("node", ["scripts/generate-runtime-config.ts"]);
|
|
|
|
if (buildsActiveWorker) {
|
|
// 5. hashed asset inventory
|
|
run("node", ["scripts/generate-service-worker-assets.ts", "dist"]);
|
|
// 6. service worker build
|
|
run("npx", ["vite", "build", "--config", "vite.service-worker.config.ts"]);
|
|
} else {
|
|
process.stdout.write(
|
|
`service worker mode ${selection?.mode ?? "null"}: skipping worker build\n`,
|
|
);
|
|
}
|
|
|
|
// 6. release + build manifest
|
|
run("node", ["scripts/generate-build-manifest.ts"]);
|