I1003 — Skills, rules, decisions, documents, use cases and benchmarks enter the graph as themselves
Bring the layer's own kinds into the graph through the registries that already index them, so that a rule, a skill, a decision, a document, a use case, a benchmark and a deployment are navigable next to the capabilities they govern.
DONE wave 1 · p0 · implementation profile · parallel safe
Objective
Bring the layer's own kinds into the graph through the registries that already index them, so that a rule, a skill, a decision, a document, a use case, a benchmark and a deployment are navigable next to the capabilities they govern.
Why
Doctrine that only exists as prose floating in a directory is unenforceable in practice and invisible in the interface. These kinds are already indexed; what is missing is their relation to the capabilities they concern.
Current state
Each kind is indexed and readable as an object. The site renders some of them as lists. None is related to a capability by anything a machine reads.
Desired state
Each kind is a node with the metadata its own registry holds, related to what it governs, documents, enforces, tests or measures.
Scope
- apps/majordomus-cli/src/capability/builtin/graph.rs
Out of scope
- A second registry for any of these kinds
- Frontmatter conventions that conflict with the schemas those directories already define
Dependencies
Acceptance criteria
- Each kind is projected from its own registry with the metadata that registry holds, and no field is invented here
- A rule shows what it governs, how it is enforced and what tests it; a skill shows its purpose, scope and relations; a decision shows what it puts in force
- Adding a valid object under a canonical directory makes it appear in the graph with no further registration
- Where a relation needs declaring, the field is added to the kind's existing schema rather than to a new one
Validation
- cargo test --workspace --all-features
- bin/majordomus doctor
Evidence required
- kinds_in_graph
- relations_from_registries
Evidence
| covers | type | command | result | at commit |
|---|---|---|---|---|
| kinds_in_graph | test | cargo test --lib graph (apps/majordomus-cli) and graph::derive(\"composed\") over this repository | every indexed kind is a node carrying what its own kind declares: a rule its class and statement, a skill its inputs and outputs, a use case its category and actors, read from the front matter the schema validated and never named in the derivation; 901 nodes across 25 node kinds over 778 objects | 434d18d |
| relations_from_registries | test | graph::unresolved_relations over this repository, and cargo test --lib graph | the relation table grew from nine declared fields to nineteen and every one is a field a kind schema already declares: the claim chain (126 defined_in, 118 implemented_by, 118 tested_by), the plan DAG (278 depends_on, 152 belongs_to), the application triangle (62 serves, 15 governed_by) and 109 exercises; 2100 edges in total and no unresolved reference across 778 objects | 434d18d |
Risk
Every kind has its own vocabulary, and flattening them into one node type loses what makes each useful. The node carries the kind's own metadata rather than a lowest common denominator.
Timeline
- started
- 2026-09-06T16:22:39Z
- verified
- —
- completed
- 2026-09-06T17:11:14Z
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/I1003.yaml. Read it back with majordomus plan show I1003.