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

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
1 of 1
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 I1025

majordomus plan verify I1025

majordomus plan done I1025

What 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.