jschoubben
4eb16f1028
0037 (where a module lives), 0113 (the vault makes every secret) and 0115 (one assignment of a module per node) described arrangements the mesh has — a catalogue of other people's software plus a table filled by module add, a vault answering a secret requirement six modules make, and a rule the assignment table's primary key already enforces. Each is accepted against what was built, and says so in its own words. 0037's other half is not built: a manifest outside this catalogue has no check, which is issue 148. 0068 (the lab takes requests) and 0114 (a shared credential rotates over two credentials) stay proposed. Neither is built, and both are decisions rather than records of something that happened.
1.8 KiB
status, opened, located-in
| status | opened | located-in | |
|---|---|---|---|
| open | 2026-09-29 |
|
148 — a manifest outside this catalogue has no check
What was observed
A module's manifest is validated by a test — internal/catalogue's suite parses every manifest
in the catalogue checkout beside it and fails on one it cannot resolve. That works, and it is how
several real faults were caught before a machine saw them.
It is available to exactly one repository: this one. Somebody describing their own application in their own repository — the case ADR 0037 calls the case that matters most — has no check at all. They write a manifest, register it with a running mesh, and find out whether it is valid when the mesh refuses it, or later, when a machine applies something that resolved and should not have.
The same record asks for the answer: a module check command on the control plane's binary, so
a manifest is checked by the tool rather than by a test that imports the tool's internals.
What would have prevented it
Nothing prevents this; it was noticed and left. ADR 0037 named it on 2026-09-01 and the record sat
proposed until 2026-09-29, so the missing half was never anybody's task.
Evidence to carry into diagnosis
mesh-controller/internal/catalogue—ParseManifestandCatalogueProblemsare the check, and both are internal.- The catalogue-wide test is
TestEveryCatalogueManifestDeclaresWhatItMountsand its siblings; they take a path fromMESH_CATALOG, so the mechanism is already path-driven and not repository-bound. mesh-controller module addrefuses a bad manifest at registration, which is the same check far too late: by then it is in a running mesh's records.