I0912 — The image serves the site the canonical pipeline produced
Build the served documentation and site assets in the container with the same pipeline local development and the Pages deployment already use, and carry exactly those outputs into the runtime stage.
BLOCKED wave 4 · p0 · implementation profile · parallel safe
Blocked. This issue cannot start until I0909 is done. The status is derived from that, not declared.
Objective
Build the served documentation and site assets in the container with the same pipeline local development and the Pages deployment already use, and carry exactly those outputs into the runtime stage.
Why
A second site build inside a Dockerfile is a second source of truth for the documentation, and the two will disagree the day one of them is fixed. The pipeline already exists and already has a check.
Current state
One pipeline builds the site and scripts/site-deploy publishes it to Pages. Nothing builds it for a container.
Desired state
The container build calls the canonical generation and site build, copies their outputs, and the runtime serves those assets through the existing server architecture with no duplicated content.
Scope
- deploy/fly
- scripts
Out of scope
- A second site generator, a second Zola invocation path or a shell reimplementation of the build
- Changing how Pages is deployed
Dependencies
What waits on this
Acceptance criteria
- The container build invokes the repository's canonical generation and site build, not a copy of their steps
- The runtime stage carries exactly the produced assets and no source of the site
- The served assets are byte-identical to what the canonical pipeline produces locally
- The contribution of the assets to the image size is measured and reported
Validation
- bash test/run.sh
- majordomus generate --check
Evidence required
- single_site_pipeline
- assets_in_image
- asset_size
Evidence
None recorded. Every token above needs a command or an artifact behind it before this issue can be completed; narrative is refused.
Risk
The derived site content is gitignored, so a clean checkout has to generate it before it can be built. A container build that skips generation produces an image with no documentation and no error.
Timeline
- started
- —
- verified
- —
- completed
- —
Those three fields, the evidence above and the state of the dependencies are all the status is made of. There is no status field to disagree with them.
Canonical record: .ai/repo/project/issues/I0912.yaml. Read it back with majordomus plan show I0912.