hq/04-ISSUES/174-the-meshs-own-files-for-a-module-are-placed-by-the-definition/00-report.md

status, opened, located-in, fixed-by, amended-design

status	opened	located-in	fixed-by	amended-design
located	2026-09-30	mesh-controller internal/catalogue/dir_into.go mesh-controller internal/catalogue/declaration.go mesh-catalog modules

174 — The mesh's own files for a module are placed by the definition, not by the mesh

What was observed

After every module's own data directory was placed by the mesh (issue 119), the catalogue still carries 232 host paths in 50 definitions, all of one kind: where the mesh writes what it makes for the module — its sealed bus credential (own-secrets.broker), its merged config file, its bindings — under /var/lib/mesh/<module>/…, and the directory resource that creates that subtree. Not one of those files is the module's. The mesh mints the credential, composes the binding, merges the config; the definition only says where to put them, and says it the same way seventy times.

Why this is here

Design 27's answer to what sits beneath a node's root (2026-09-26) is that the mesh's writes need no module-visible reservation: what the mesh writes for a module is the mesh's plumbing, placed where the mesh chooses and mounted in, never part of the module's contract. The definition today names that place, so a definition is not yet free of host paths — and a node whose root is elsewhere would place the module's data there and the mesh's files still under /var/lib/mesh.

The path-preserving test that let issue 119 close does not cover this: it proves a placed directory resolves to what was named, and these are not placed.

What it would take

A word for "the mesh's file for this module", or none: own-secrets values, a merged config file and a binding could be named by key alone, with the mesh choosing <root>/mesh/<module>/<key> and mounting it where the container says. The container side of the mount already exists in every definition (/run/secrets/broker, /run/config/config.json); only the host side would go. The change is in the controller, once, and then a mechanical edit of fifty definitions, which the same test that proved 119 can prove again with the rule extended.

Open questions

• Does own-secrets keep its map shape with the value becoming the container path rather than the host path, or does the mount stay where it is and the host side become a placeholder the mesh fills, ${mesh:<key>}?
• A binding file today lands wherever binds says; a module's code reads it from an environment variable naming the container path. If the host side is the mesh's, is the container side still the definition's to choose? It should be: it is the software's contract.