Observed evidence
In the 2026-05-18 deploy window, two consecutive PRs were needed to get the worker image building correctly:
PR #4901 fixed wiki-server route imports leaking into the worker. PR #4903 then had to fix:
- 10 npm packages that weren't in
docker/worker/package.json (first one prod hit: proper-lockfile)
data/schema.ts which wasn't COPY'd into the image
Found at runtime in prod after enqueueing a real backfill-sources job.
The gap
The existing validator crux/validate/validate-workspace-dep-coverage.ts checks that every @longterm-wiki/* workspace dep used in crux/ is declared in docker/worker/package.json and that every file: workspace dep has a matching COPY line. It does not check:
- Regular npm packages imported transitively from
crux.mjs — when a new crux command imports e.g. proper-lockfile, nothing flags that the worker package.json is now missing that dep.
- Non-workspace files copied from outside
crux/ (like data/schema.ts) — the worker crux.mjs static-import graph can pull in arbitrary repo files, and there's no check that every imported file is present in the image.
Proposed extension
Extend the validator to:
- Scan the worker's static import graph rooted at
crux/run.mjs (or whatever the worker's entry is).
- Collect every imported npm package and assert it's declared in
docker/worker/package.json.
- Collect every relative file import that leaves
crux/ (e.g. ../data/..., ../apps/.../...) and assert there's a matching COPY line in Dockerfile.worker before pnpm install --prod.
The principle is the same as the existing validator (find the gap mechanically, fail-closed in CI), just applied to the broader dependency graph that the worker actually uses at runtime.
Why this matters
The "fix the system, not the instance" principle in CLAUDE.md: each missing dep is one PR away from causing a prod backfill-job failure. After two of these in one week, the validator should subsume the manual reasoning.
Related: see also docs/agent-rules/dockerfile-postinstall-trap.md (sub-app Dockerfiles, different but related class).
Discovery context
Filed during weekly maintenance sweep 2026-05-24 — auto-generated PR for context.
Observed evidence
In the 2026-05-18 deploy window, two consecutive PRs were needed to get the worker image building correctly:
PR #4901 fixed wiki-server route imports leaking into the worker. PR #4903 then had to fix:
docker/worker/package.json(first one prod hit:proper-lockfile)data/schema.tswhich wasn't COPY'd into the imageFound at runtime in prod after enqueueing a real backfill-sources job.
The gap
The existing validator
crux/validate/validate-workspace-dep-coverage.tschecks that every@longterm-wiki/*workspace dep used incrux/is declared indocker/worker/package.jsonand that everyfile:workspace dep has a matchingCOPYline. It does not check:crux.mjs— when a new crux command imports e.g.proper-lockfile, nothing flags that the workerpackage.jsonis now missing that dep.crux/(likedata/schema.ts) — the workercrux.mjsstatic-import graph can pull in arbitrary repo files, and there's no check that every imported file is present in the image.Proposed extension
Extend the validator to:
crux/run.mjs(or whatever the worker's entry is).docker/worker/package.json.crux/(e.g.../data/...,../apps/.../...) and assert there's a matchingCOPYline inDockerfile.workerbeforepnpm install --prod.The principle is the same as the existing validator (find the gap mechanically, fail-closed in CI), just applied to the broader dependency graph that the worker actually uses at runtime.
Why this matters
The "fix the system, not the instance" principle in CLAUDE.md: each missing dep is one PR away from causing a prod backfill-job failure. After two of these in one week, the validator should subsume the manual reasoning.
Related: see also
docs/agent-rules/dockerfile-postinstall-trap.md(sub-app Dockerfiles, different but related class).Discovery context
Filed during weekly maintenance sweep 2026-05-24 — auto-generated PR for context.