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

I0915

Deployment joins the diagnostics that already exist

Where it stands

devtask.issue
Readiness
cancelled withdrawn
Status
CANCELLED
Can start
not now
Milestone
fly-deployment
Milestone status
ACTIVE
Wave
5
Waiting on
I0914
Holds back
I0925
Behind it in all
2
Evidence
0 of 3
In the waySubjectDetail
issueI0914I0914 is not DONE

Moves

plan.transition
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 I0915

majordomus plan verify I0915

majordomus plan done I0915

What it is

Objective
Add the deployment checks to the health and doctor architecture the repository already has, so that the answer to whether a deployment can succeed comes from the same diagnostic surface as every other verdict.
Why
A second doctor framework is the defect this repository names explicitly. The existing health module already delegates each check to the engine that decides it; deployment checks belong there for the same reason.
Now
system.health aggregates index diagnostics, benchmark coverage and projection staleness. No check knows anything about a deployment.
Wanted
The deployment checks are readable as machine-readable output and as human output, they mutate nothing, and each one delegates to the engine that already decides it.
Done when
Cancelled 2026-10-14 on master e28daccd9b: what it would add is credential validity and application resolution against Fly; the local checks are deploy.check. The owner disconnected Fly.io on 2026-10-12; this repository deploys release binaries, the GHCR image and GitHub Pages (commit 9af3fa65a4 removed fly.toml).
Risk
Checks that need the provider's network will make the local doctor slow and flaky. Local checks and remote checks have to be separable so that the fast ones stay usable in a hook.

Acceptance

  • The checks cover the canonical object's validity, projection freshness, toolchain and tool availability, credential validity, application resolution, configuration validity, container build and non-root execution, port and health and readiness responses, absence of secret material and of local paths, size and memory budgets, machine count and resource sizing against the declared profile, and the deployed revision against the expected one
  • Every check states what it observed, what it expected and the command that repairs it
  • The output is available in both machine-readable and human-readable form, following the existing conventions
  • Every check is read-only and safe to run against production
  • No check duplicates a verdict another engine already produces
Validation
majordomus deploy doctorcargo test --workspace --all-features
Evidence required
doctor_checksmachine_readableread_only
Evidence present
unknown: the record carries no `evidence` entries

Scope

Touches
apps/majordomus-cli/src/deploy/doctor.rs
Not
A new diagnostics frameworkAny check that mutates the provider, the repository or the working tree
Depends on
I0914
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-14
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.