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

I1202

One typed provider model reads the objects, and no code names a provider

Where it stands

devtask.issue
Readiness
blocked 1 of its dependencies is not DONE
Status
BLOCKED
Can start
not now
Milestone
web-sign-in
Milestone status
PLANNED
Wave
1
Waiting on
I1201
Holds back
I1203I1208
Behind it in all
6
Evidence
0 of 3
In the waySubjectDetail
issueI1201I1201 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 I1202

majordomus plan verify I1202

majordomus plan done I1202

What it is

Objective
Add apps/majordomus-cli/src/identity with the typed model of a provider object: discovery of every object under .ai/repo/identity/providers/, validation against the schema, resolution of the credential environment variables at use rather than at load, and a deterministic ordering of the sign-in offer. Expose the read as a capability so the provider list reaches the CLI, the API, OpenAPI, MCP and the Cockpit through the registry rather than through five readers.
Why
The objects are only canonical if exactly one thing parses them. A second reader in the Cockpit or in the HTTP layer would be a second definition of what a provider is, and would drift the first time the schema gains a field.
Now
I1201 has the objects; nothing reads them.
Wanted
identity::providers() returns the validated, ordered set; a provider whose credentials are absent is reported as unavailable with a reason rather than omitted silently; and grep for the strings google and facebook in apps/ returns nothing outside tests and fixtures.
Done when
unknown: the record declares no `completion`
Risk
Resolving credentials at load makes the model unusable in any context that serialises it. They are resolved at the moment of the flow and never held.

Acceptance

  • The provider set is discovered from the directory, validated, and ordered deterministically
  • A provider with absent credentials is unavailable with a stated reason, and the reason reaches the surfaces
  • No provider identifier appears in the executable's source outside test fixtures
  • The read is declared once as a capability and appears in CLI, HTTP, OpenAPI, MCP and docs with no second registration
Validation
cargo test --workspace --all-featurescargo clippy --workspace --all-targets --all-features -- -D warningsmajordomus generate --check
Evidence required
typed_modelcapability_projectedno_provider_names_in_code
Evidence present
unknown: the record carries no `evidence` entries

Scope

Touches
apps/majordomus-cli/src/identityapps/majordomus-cli/src/capability/builtinapps/majordomus-cli/src/lib.rsapps/majordomus-cli/tests
Not
The HTTP flow, which is I1203Reading a credential value into any type that is serialised, cached, logged or rendered
Depends on
I1201
Priority
p0
Profile
implementation
Parallel safe
false
Owner
unknown: the record declares no `owner`

The work so far

Branches
none
Merged
none
Commits
0
Trunk
master
Sessions
none
Created
2026-09-08
Updated
2026-09-08
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.