I1006 — The runtime reads the graph through the registry, like every other read
Expose the graph to the running Cockpit as a declared capability, so that its route, its schema, its documentation and its benchmark coverage all follow from the declaration.
DONE wave 3 · p1 · implementation profile · parallel safe
Objective
Expose the graph to the running Cockpit as a declared capability, so that its route, its schema, its documentation and its benchmark coverage all follow from the declaration.
Why
A route added by hand for the Cockpit would be the one endpoint missing from OpenAPI, from the reference and from the smoke suite. The registry exists precisely so that does not happen.
Current state
The Cockpit renders in-process. No capability serves the aggregate graph.
Desired state
One declared capability serves the graph, documented and benchmarked like the rest, with the runtime state layered over the definitions rather than mixed into them.
Scope
- apps/majordomus-cli/src/capability/builtin/graph.rs
Out of scope
- A route registered outside the capability registry
- Runtime state stored in the same structure as the definitions
Dependencies
What waits on this
- I1008BLOCKED The two projections are proved to be the same model
- I1017READY Live state is an overlay that degrades to nothing
Acceptance criteria
- The operation is one capability declaration and appears in the API, the OpenAPI document, the reference and the benchmark coverage without a second registration
- The response is typed and carries safe fields only
- Runtime state is an overlay over the definitions, distinguishable in the response
- A test exercises the operation against a running server rather than a mock
Validation
- cargo test --workspace --all-features
- majordomus generate --check
Evidence required
- capability_declared
- runtime_overlay
Evidence
| covers | type | command | result | at commit |
|---|---|---|---|---|
| capability_declared | test | cargo test --lib -- graph:: && cargo test --test cockpit a_graph_page_lists_every_node_and_edge | 86 passed (graph:: incl. the_declaration_yields_the_projections_it_claims); cockpit test 1 passed: GET /api/v1/graph?id=registry on a running server answers 200 with the typed graph. graph.list and graph.get are one declaration each in capability/builtin/graph.rs and appear in /openapi.json (operationId graph.get, graph.list), docs/generated/capabilities.md, docs/generated/modules/graph.md and docs/generated/benchmarks.* | f075170 |
| runtime_overlay | test | cargo test --lib -- graph::tests::the_runtime_projection_is_the_static_one_with_an_overlay_beside_it graph::tests::the_graph_holds_definitions_and_the_overlay_holds_what_a_process_saw | ObservedGraph keeps graph (byte-for-byte the derived definitions) and runtime (the overlay) as separate fields; stripping runtime yields the static projection. graph.get answers the definitions only; the Cockpit graph page (cockpit/pages.rs observed_now) applies the overlay beside them, so runtime state is distinguishable in the response the Cockpit serves and absent from the static one | f075170 |
Risk
Serving the whole graph on every Cockpit load is a cost on the hot path. It is measured, and paged or filtered if the measurement says so.
Timeline
- started
- 2026-10-04T10:11:17Z
- verified
- 2026-10-04T10:11:35Z
- completed
- 2026-10-04T10:11:46Z
Those three fields, the evidence above and the state of the dependencies are all the status is made of. There is no status field to disagree with them.
Canonical record: .ai/repo/project/issues/I1006.yaml. Read it back with majordomus plan show I1006.