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
0of3
| In the way | Subject | Detail |
|---|---|---|
| issue | I0915 | I0915 is not DONE |
Moves
plan.transitionWhat 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.