The modules the mesh runs lived under examples/modules/, which framed the real catalogue as illustrations of a control-plane package. They're neither examples nor the control plane's — they're the mesh's own catalogue, now in novox/mesh-catalog (30 manifests, flat under modules/), consumed as a build source like any other.
The engine stays here (internal/catalogue): the control plane owns the manifest contract; the data doesn't belong beside it. No runtime code referenced examples/modules/ — only two tests did.
Removed with the manifests:examples/modules/modules_test.go and internal/catalogue/parseall_test.go, which validated the example manifests against the parser. That validation logically follows the catalogue to mesh-catalog, but it imports internal/catalogue, so re-homing it needs the parser exported from internal/ first — a deliberate follow-up, not done here (it's a public-API decision for the control plane). Until then the pipeline is the gate, and internal/catalogue's own inline tests still cover the parser. go build ./... and go test ./... are green.
Answers novox/hq ADR 0030's open tier-4 question — where the catalogue lives — in favour of one flat mesh-catalog repository (the drop of domain grouping in favour of seats/claims/tags is what makes flat the right shape).
The modules the mesh runs lived under `examples/modules/`, which framed the real catalogue as illustrations of a control-plane package. They're neither examples nor the control plane's — they're the mesh's own catalogue, now in [`novox/mesh-catalog`](https://git.novox.be/novox/mesh-catalog) (30 manifests, flat under `modules/`), consumed as a build source like any other.
The engine stays here (`internal/catalogue`): the control plane owns the manifest contract; the data doesn't belong beside it. No runtime code referenced `examples/modules/` — only two tests did.
**Removed with the manifests:** `examples/modules/modules_test.go` and `internal/catalogue/parseall_test.go`, which validated the example manifests against the parser. That validation logically follows the catalogue to mesh-catalog, but it imports `internal/catalogue`, so re-homing it needs the parser **exported from `internal/`** first — a deliberate follow-up, not done here (it's a public-API decision for the control plane). Until then the pipeline is the gate, and `internal/catalogue`'s own inline tests still cover the parser. `go build ./...` and `go test ./...` are green.
Answers `novox/hq` ADR 0030's open tier-4 question — where the catalogue lives — in favour of one flat `mesh-catalog` repository (the drop of domain grouping in favour of seats/claims/tags is what makes flat the right shape).
https://claude.ai/code/session_01LrgweAeERJYBg88c5cKDzF
The modules the mesh runs were under examples/modules/, which framed
the real catalogue as illustrations of a control-plane package. They
are neither examples nor the control plane's — they are the mesh's own
catalogue, and they now live in their own repository (novox/mesh-catalog),
consumed as a build source like any other.
The engine that reads them stays here (internal/catalogue): the control
plane owns the manifest contract; the data does not belong beside it.
Removed with them: modules_test.go and parseall_test.go, which validated
the example manifests against the parser. That validation logically
follows the catalogue to mesh-catalog, but it imports internal/catalogue,
so re-homing it needs the parser exported from internal/ first — a
deliberate follow-up, not done here. Until then the pipeline is the gate,
and internal/catalogue's own inline tests still cover the parser.
Answers novox/hq ADR 0030's open tier-4 question — where the catalogue
lives — in favour of one flat mesh-catalog repository.
Claude-Session: https://claude.ai/code/session_01LrgweAeERJYBg88c5cKDzF
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The modules the mesh runs lived under
examples/modules/, which framed the real catalogue as illustrations of a control-plane package. They're neither examples nor the control plane's — they're the mesh's own catalogue, now innovox/mesh-catalog(30 manifests, flat undermodules/), consumed as a build source like any other.The engine stays here (
internal/catalogue): the control plane owns the manifest contract; the data doesn't belong beside it. No runtime code referencedexamples/modules/— only two tests did.Removed with the manifests:
examples/modules/modules_test.goandinternal/catalogue/parseall_test.go, which validated the example manifests against the parser. That validation logically follows the catalogue to mesh-catalog, but it importsinternal/catalogue, so re-homing it needs the parser exported frominternal/first — a deliberate follow-up, not done here (it's a public-API decision for the control plane). Until then the pipeline is the gate, andinternal/catalogue's own inline tests still cover the parser.go build ./...andgo test ./...are green.Answers
novox/hqADR 0030's open tier-4 question — where the catalogue lives — in favour of one flatmesh-catalogrepository (the drop of domain grouping in favour of seats/claims/tags is what makes flat the right shape).https://claude.ai/code/session_01LrgweAeERJYBg88c5cKDzF
Pull request closed