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
I0903
Deployment reads are declared once and projected everywhere
Where it stands
devtask.issue- Readiness
- complete completion is recorded and every required evidence token is present
- Status
- DONE
- Can start
- not now
- Milestone
- Milestone status
- ACTIVE
- Wave
2- Waiting on
- none
- Holds back
- Behind it in all
11- Evidence
4of4
Moves
plan.transitionWhat it is
- Objective
- Declare the read-only deployment operations as canonical capabilities so that the CLI, the HTTP API, MCP, OpenAPI and the generated documentation all derive from one declaration.
- Why
- The repository's rule is that an operation is declared once and projected; adding deployment to a transport registry, an OpenAPI file or a documentation table by hand is the defect ADR 0004 names.
- Now
- The capability registry holds a deploy module (apps/majordomus-cli/src/capability/builtin/deploy.rs) beside the others. The statement this field used to carry -- that no deployment module exists -- was falsified before 2026-09-10 and never corrected. Measured on master 6042f4286, 2026-09-10.
- Wanted
- A deploy capability module declares the deployment reads, and every projection picks them up from generate with no second registration anywhere.
- Done when
- unknown: the record declares no `completion`
- Risk
- A deployment status read wants to call flyctl, which turns a cheap capability into a network call on a hot path. Live provider state belongs behind an explicit operation with its own cost, not behind an ordinary read.
Acceptance
- Each operation is one capability! declaration with its input, output, stability, exposure and tags
- The operations appear in the CLI, the HTTP API, the MCP surface, openapi.json and the generated reference without any file listing them a second time
- No capability performs a mutating deployment action
- generate --check is green after regeneration and fails when a projection is edited by hand
- The benchmark coverage projection accounts for the new capabilities, as the coverage rule requires
- Validation
cargo test --workspace --all-featuresmajordomus generate --check- Evidence required
capability_declaredprojections_derivedgenerate_checkbenchmark_coverage- Evidence present
capability_declaredprojections_derivedgenerate_checkbenchmark_coverage
Scope
- Touches
apps/majordomus-cli/src/capability/builtin/deploy.rsapps/majordomus-cli/src/capability/builtin/mod.rs- Not
Mutating operations over HTTP or MCP; deployment mutation belongs to the trusted CLI and CIHand-edited OpenAPI, route tables or documentation lists- Depends on
- Priority
- p0
- Profile
- implementation
- 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-10-14T09:04:42Z
- Started
- 2026-10-14T09:04:28Z
- Verified
- unknown: the record declares no `verified_at`
- Completed
- 2026-10-14T09:04:42Z
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.