Skip to content
Cockpit0.29.0
A snapshot: read at commit 707a04c7ce8 on 2026-10-18T00:06:01Z by majordomus 0.29.0. Nothing on this page is read again. See it live

I0925

Every deployment rule is a check that runs

Where it stands

devtask.issue
Readiness
blocked 1 of its dependencies is not DONE
Status
BLOCKED
Can start
not now
Milestone
Milestone status
ACTIVE
Wave
6
Waiting on
Holds back
Behind it in all
1
Evidence
0 of 3
In the waySubjectDetail
issueI0915I0915 is not DONE
A move writes the repository: it stamps one field of this issue's record and appends one event to the ledger, and a commit will carry both.
The same moves from a terminal

majordomus plan start I0925

majordomus plan verify I0925

majordomus plan done I0925

What it is

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.
Now
Project rules exist for benchmarkable commands, derived files, hot paths, scope declaration, shared-server resilience and more, each with a check. None concerns deployment.
Wanted
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.
Done when
unknown: the record declares no `completion`
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.

Acceptance

  • 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 doctorbash test/run.sh
Evidence required
rules_authoredchecks_executeci_runs_them
Evidence present
unknown: the record carries no `evidence` entries

Scope

Touches
.ai/repo/rules/project
Not
A rule with no executable checkRestating an existing rule that already covers the constraint
Depends on
Priority
p0
Profile
deep-work
Parallel safe
true
Owner
unknown: the record declares no `owner`

The work so far

Branches
none
Merged
none
Commits
0
Trunk
master
Sessions
none
Created
2026-09-06
Updated
2026-09-06
Started
unknown: the record declares no `started_at`
Verified
unknown: the record declares no `verified_at`
Completed
unknown: the record declares no `completed_at`

Synchronisation

Adapter
scripts/github-sync
Repository
unknown: the derived plan's header carries no repository
External issue
unknown: a live GitHub state; this executable makes no network call, so only `scripts/github-sync --check` can answer it
State there
unknown: a live GitHub state; this executable makes no network call, so only `scripts/github-sync --check` can answer it

Findings

Nothing is wrong with these records.