This folder specifies how an owner says what each of their repositories is, in rows tools can read, and how one hub reads the others. It is the repository inventory of the Medicine Wheel Developer Suite, beside the infrastructure inventory of @medicine-wheel/infra.
| File | What it is for |
|---|---|
repository-mapping.spec.md |
What to build: the owner hub folder, its rows, the lifecycle, the comparison with git, the meta mapping, the CLI and the page. |
capabilities.spec.md |
The platform-features and capabilities layer the mapping consumes, and the attribution every row carries. |
repository-mapping.kin.md |
Why it is shaped this way: what relational means here, why every row starts pending, what no function in it can judge. Read before changing a rule. |
STATUS.md |
What is implemented, in which release, and phase two. |
repository-mapping.sysdf.json |
The system drawing. Lists the three drawings below and the actors. Checked with stateloom’s check_system. |
repository-mapping.erdf.json |
The rows, drawn as an entity-relationship drawing. |
repository-lifecycle.smdf.json |
The lifecycle state machine. Each state’s prompt tells a mapping agent what to do while a repository is in it. |
meta-mapping.sqdf.json |
The usage scenario: an agent maps one owner, the meta hub reads that hub, a person affirms what holds. |
repository-mapping.sys.md |
The three drawings rendered as Mermaid, for reading on GitHub. Regenerated by stateloom’s render_diagram; not edited by hand. |
To build the system from these specs: implement capabilities.spec.md first, then repository-mapping.spec.md, using the drawings as the data and behaviour contract. To change a rule, change the spec and the drawing together, then run check_system.
Asked for in the prompt kept at .pde/2610182156--872139f0-b71c-4e94-9781-a5546182e3c1/input-prompt.md of this repository, decomposed beside it. The kinds and edges it rides are in rispecs/ontology-core.spec.md (Developer).