Files
hq/04-ISSUES/074-a-mesh-test-wears-a-catalogue-modules-name/01-diagnosis.md
T

23 lines
1.7 KiB
Markdown

# Diagnosis — 2026-09-21
1. The renames the report asked for were sized: each bed uses its borrowed name twenty to sixty
times, most of them container names and paths that could stay; the name itself appears in the
manifest, in the `assign` and `module issue` commands, and in the broker account the bed
asserts on, `<node>-<module>`.
2. Then the account was read. The mesh scopes a module's broker account to `serve.<module>.*`
from the manifest's name, and the tool runtime binds its queues under the module name baked
into its image. A fixture named `redis-fixture` running the real redis runtime would be
refused the queues it serves on. The name is not a label. **A fixture that runs a module's
runtime carries the module's name**, and therefore reads the catalogue
([ADR 0093](../../02-DECISIONS/0093-a-fixture-that-runs-a-modules-runtime-carries-its-name.md)).
3. Of the twelve, the two whose only cut was the vault's secret — the grant bed and the
backend-network bed, both redis — read the catalogue's redis now and install the vault beside
it, as the vault bed does. The rest are declared with this reason: four sidecar beds need the
module's server raised (and, for grafana and sonarr, the route module); the minio and postgres
grant beds raise a second store beside the foundation's; the route-forwarding bed needs the
certificate authority; the largest mesh test carries a declaration-only postgres, a builder
that builds itself and an umami of another shape.
**Located in:** mesh-lab, the ten declared beds, one conversion each with a lab run. Not renamed,
by decision; converted two at a time as the modules they need are raised beside them.