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

I1114

A provider is an adapter over the model, and adding one is an implementation

Where it stands

devtask.issue
Readiness
blocked 1 of its dependencies is not DONE
Status
BLOCKED
Can start
not now
Milestone
two-folder-integration
Milestone status
ACTIVE
Wave
6
Waiting on
I1112
Holds back
I1115
Behind it in all
2
Evidence
0 of 2
In the waySubjectDetail
issueI1112I1112 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 I1114

majordomus plan verify I1114

majordomus plan done I1114

What it is

Objective
Make every provider-specific representation a derived adapter over the repository model, so that supporting another provider is one implementation rather than a copy of the instructions in another file.
Why
Provider files are the fastest-growing part of any repository that works with several assistants, and each copy drifts from the layer it was copied from. The layer is provider-neutral by design; the adapters are where a provider's requirements are allowed to exist.
Now
Provider bootstraps are generated from the registry, which is the right shape, but they land at the root and their ownership is not recorded.
Wanted
Adapters are generated into the control-plane namespace, bridged at the root only where a tool truly requires a root file, and a new provider is a trait implementation.
Done when
unknown: the record declares no `completion`
Risk
An adapter layer can grow provider-shaped holes in the model beneath it. The check is whether the model would still be complete if every adapter were deleted.

Acceptance

  • Every provider representation is derived from the model and declares its provenance
  • Adding a provider is one implementation of the adapter contract, with no edit to the layer and no new list
  • A provider that can be configured programmatically produces no repository file at all
  • Where a root file is unavoidable it is a managed bridge with recorded ownership, and its content is derived
Validation
majordomus generate --checkcargo test --workspace --all-features
Evidence required
adapters_derivednew_provider_is_one_impl
Evidence present
unknown: the record carries no `evidence` entries

Scope

Touches
apps/majordomus-cli/src/providers.rs.majordomus/generated
Not
Provider semantics in the canonical layerA provider list maintained by hand
Depends on
I1112
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-06
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.