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
I1025
The federated model and its two projections are an architecture decision
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
1- Waiting on
- none
- Holds back
- Behind it in all
2- Evidence
1of1
Moves
plan.transitionWhat it is
- Objective
- Record the decision to compose the authoritative registries into one typed graph and to render it as two projections, with the alternatives that were real and the consequences that follow.
- Why
- The choices here — composing rather than centralising, generating rather than fetching, progressive enhancement rather than a client application, availability as metadata rather than a condition in a page — will each look arbitrary to somebody later. ADR 12 decided the Cockpit is a projection; this decides what it is a projection of.
- Now
- ADR 12 establishes the Cockpit as a projection of the registry. ADR 13 establishes that web surfaces are discovered from their producers. Neither covers the composed graph or the static projection.
- Wanted
- One record states the decision, extends rather than restates the two it follows, and says what would have to change to revisit it.
- Done when
- unknown: the record declares no `completion`
- Risk
- Written last, it becomes a summary of the code. It is written when the choice between composing and centralising is still open.
Acceptance
- The record follows the repository's ADR format and frontmatter exactly and relates to the decisions it extends
- It states the federated composition, the dual projection, progressive enhancement, availability as metadata and the conditional exposure of runtime surfaces
- The alternatives — one central manifest, a client-side application fetching the API, a separate site generator — are recorded with why they were not taken
- The consequences state what a new subsystem must do to appear, and what it costs when it does not
- Validation
bin/majordomus doctorbash test/run.sh- Evidence required
adr_recorded- Evidence present
adr_recorded
Scope
- Touches
.ai/repo/adrs- Not
Restating ADR 12 or ADR 13An ADR that documents the implementation instead of the decision- 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-09-06T16:54:55Z
- Started
- 2026-09-06T16:23:01Z
- Verified
- unknown: the record declares no `verified_at`
- Completed
- 2026-09-06T16:54:54Z
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.