Skip to content

I0925 — Every deployment rule is a check that runs

State the durable deployment constraints as project rules in the repository's rule system, and give each one an executable check that CI runs.

BLOCKED wave 6 · p0 · deep-work profile · parallel safe

Part of fly-deployment — A deployment is a projection of the repository model, and a reachable URL is its evidence.

Blocked. This issue cannot start until I0915 is done. The status is derived from that, not declared.

Objective

State the durable deployment constraints as project rules in the repository's rule system, and give each one an executable check that CI runs.

Why

The repository's own rule says a rule is a doctrine with enforcement. Deployment constraints written only as prose would be advice, and advice does not survive the first hurried change to a resource envelope.

Current state

Project rules exist for benchmarkable commands, derived files, hot paths, scope declaration, shared-server resilience and more, each with a check. None concerns deployment.

Desired state

Each deployment rule exists as a rule object with a check that executes, and a violation is refused rather than reported in a document nobody reads.

Scope

  • .ai/repo/rules/project

Out of scope

  • A rule with no executable check
  • Restating an existing rule that already covers the constraint

Dependencies

What waits on this

Acceptance criteria

  • Deployment configuration originates from the canonical object, and editing a generated provider artifact by hand is refused by a check
  • Generated deployment artifacts must match the canonical object, and CI fails on drift
  • Secrets must not enter generated artifacts, source control, build arguments, layers, documentation or the UI, and a check enforces it
  • The production runtime image must contain only runtime dependencies and must run non-root, and a check enforces both
  • Deployment documentation and UI must derive from the authoritative data, and a check enforces it
  • A deployment must expose and test the canonical health and readiness behaviour, and a check enforces it
  • The declared cost profile must stay resource-bounded, and a change to the envelope is visible in review because a check names it
  • Each rule reuses an existing rule where one already covers the constraint rather than adding a near-duplicate

Validation

  • bin/majordomus doctor
  • bash test/run.sh

Evidence required

  • rules_authored
  • checks_execute
  • ci_runs_them

Evidence

None recorded. Every token above needs a command or an artifact behind it before this issue can be completed; narrative is refused.

Risk

Seven new rules is a lot of doctrine for one subsystem. Any constraint an existing rule already covers should be referenced rather than restated.

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/I0925.yaml. Read it back with majordomus plan show I0925.