Roadmap

The problem

Majordomus has no deployment at all: no container, no hosting provider, no way for anyone who is not standing in front of this checkout to see the layer it serves. The obvious repair is the wrong one. A Dockerfile and a fly.toml written by hand would be a second description of facts the repository already holds — the port the server binds, the routes it registers, the assets the site build produces, the binary the workspace names — and every one of those pairs would drift the first time one half changed. The repository already refuses that shape everywhere else: capabilities are declared once and projected into CLI, HTTP, MCP, OpenAPI, docs and the site, and generate --check fails when a projection is stale. A deployment must arrive the same way or not at all.

The outcome

One canonical deployment object under .ai/repo/deployments/ describes the image; a typed Rust model parses and validates it; the Dockerfile, its ignore file, the GHCR image that docker-image.yml and release.yml build, its smoke derived from the route registry, the doctor checks, the documentation and the cockpit view are projections of that object and of the capability registry, each checked for drift. The published image runs as a non-root user, carries no secret and no developer path, answers live and ready in its smoke, and has measured size, cold-start and memory baselines. Re-scoped 2026-10-14 from a Fly.io deployment, which the owner disconnected on 2026-10-12.

Where it stands

Measured 2026-10-14 on master e28daccd9b: .ai/repo/deployments/majordomus.yaml is the canonical object; deploy/Dockerfile and its ignore file are generated from it (Alpine, uid 10001, exec-form entrypoint); docker-image.yml builds and smoke-tests the image on pull requests and on master, and release.yml publishes it to GHCR; .github/actions/image-smoke checks the image runs as non-root and answers /api/v1/live and /api/v1/ready; deploy.list, deploy.get, deploy.check and deploy.observed are capabilities. Missing: a smoke derived from the route registry, a secret and developer-path scan of the image, an SBOM, size, cold-start and memory baselines, a documentation page. The object still carries region, machines and resources, which nothing reads since Fly.io was disconnected on 2026-10-12.

Where it should stand

The GHCR image is a projection of the canonical object like every other artifact: generated, checked for drift, smoke-tested from the route registry, scanned for secrets and developer paths, measured against recorded budgets, documented and shown in the cockpit. Whether region, machines and resources leave the deployment/v1 schema is decided and recorded.

In scope

• .ai/repo/deployments
• .ai/repo/adrs
• .ai/repo/rules/project
• .ai/repo/policy.yaml
• apps/majordomus-cli/src/deploy
• apps/majordomus-cli/src/capability/builtin
• apps/majordomus-cli/src/http
• deploy
• share/kinds.yaml
• share/allow
• share/schemas
• docs
• site
• test/cases
• .github/workflows

Out of scope

• Any dependency, in code, script, documentation, CI or default, on ~/dev/prismatic-platform
• A provider abstraction covering hosts other than the one this repository deploys to
• Kubernetes, Nomad, buildpacks, Nixpacks or a second container implementation
• A persistent volume, a database or any stateful service, unless a measured requirement forces one
• Mutating deployment operations exposed to unauthenticated HTTP or to the browser
• Profile-guided optimisation

Proven when

• One canonical deployment object is the only place the port, the region, the resources, the Machine count, the health routes, the build inputs and the budgets are stated
• Every image artifact — the Dockerfile and its ignore file — is generated, marked as generated with its source and its regeneration command, and fails generate --check when edited by hand
• The deployment reads are declared once in the capability registry and appear in the CLI, the HTTP API, MCP, OpenAPI and the generated documentation without a second registration
• The smoke suite is derived from the route registry; no second list of endpoints exists anywhere
• The production image runs as a non-root user, contains no build toolchain, no repository history, no secret and no absolute developer path
• The published image answers live and ready in its smoke, run from outside the container on a free host port
• Image size, binary size, build context size, cold start, resident memory and endpoint latency are measured, recorded as baselines and gated against unexplained regression
• No credential is written to the repository, to a Docker layer, to a generated file, to the site or to a log, and the image is published with the workflow's own token
• Every rule this milestone states is enforced by a check that CI executes