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
I0924
The decision is recorded where architecture decisions are recorded
Where it stands
devtask.issue- Readiness
- cancelled withdrawn
- Status
- CANCELLED
- Can start
- not now
- Milestone
- Milestone status
- ACTIVE
- Wave
1- Waiting on
- none
- Holds back
- Behind it in all
2- Evidence
0of1
Moves
plan.transitionWhat it is
- Objective
- Write the architecture decision record for deploying as a generated projection of canonical deployment metadata, with the alternatives that were genuinely considered and the consequences that follow.
- Why
- The repository decides architecture in ADRs, and the ones that matter here — a hand-written Dockerfile against a generated one, Alpine against a distroless or slim base, one machine against redundancy, an account token against a scoped one — will be revisited by somebody who was not in this session.
- Now
- Twelve ADRs cover the CLI, the registry, the shared server, performance, projections, CI, skills, use cases, prompt capture, knowledge, directory contracts, the cockpit and web surfaces. None covers deployment.
- Wanted
- One ADR states the decision, the alternatives, the tradeoffs and what would have to change to revisit them, in the repository's own ADR format.
- Done when
- Cancelled 2026-10-14 on master ce5959db59: the decision this issue would record is gone. The owner disconnected Fly.io on 2026-10-12 and the deployment is the release binaries, GitHub Pages and the GHCR image; commit 9af3fa65a4 removed the Dockerfile and fly.toml, so there is no Fly, Alpine or autostop choice left to decide.
- Risk
- An ADR written after everything is finished records the implementation rather than the decision. It has to be written when the choice is still visible.
Acceptance
- The record follows the repository's ADR format and its frontmatter exactly
- It states the decision, the container strategy against buildpacks and image-based alternatives, the runtime base, the single-machine cheap profile, the autostop behaviour, the token model and the generation architecture
- Alternatives that were genuinely available are recorded with why they were not taken
- The consequences include what scaling, rollback and migration would mean under this decision
- It is related to the ADRs it depends on rather than restating them
- Validation
bin/majordomus doctorbash test/run.sh- Evidence required
adr_recorded- Evidence present
- unknown: the record carries no `evidence` entries
Scope
- Touches
.ai/repo/adrs- Not
A second ADR format or an ADR that restates the documentation- Depends on
- Priority
- p1
- 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.