Merge pull request 'Issue 119 resolved for a module's own data; issue 174 for the mesh's files (group 4, step 2)' (#232) from feat/definitions-place-their-directories into main

Reviewed-on: #232

03-DESIGN/01-to-be/27-a-module-requires-the-mesh-resolves.md

@@ -181,6 +181,13 @@ first form is [`${dir:<id>}`](../../04-ISSUES/119-a-module-definition-decides-wh
 a placed directory under the node's root. Each is this design's provider in the shape the existing
 placeholders have, not yet the one requirement form below; they are phase 1's first cases.
 
+*Phase 3, in part (2026-09-30):* every definition's **own** data directory is placed; the conversion
+moved no data, proven by resolving both catalogues with the controller's rule and comparing
+([issue 119](../../04-ISSUES/119-a-module-definition-decides-where-its-files-live/00-report.md)).
+What the mesh writes *for* a module is still placed by the definition
+([issue 174](../../04-ISSUES/174-the-meshs-own-files-for-a-module-are-placed-by-the-definition/00-report.md)),
+which is the gap this design answered on 2026-09-26 and has not built.
+
 ## How a definition reads what was resolved
 
 **One form, naming a requirement and a field of its contract.** A definition that needs the database's

04-ISSUES/119-a-module-definition-decides-where-its-files-live/00-report.md

@@ -1,9 +1,9 @@
 ---
-status: located
+status: resolved
 opened: 2026-09-25
 located-in: [mesh-catalog modules, mesh-controller internal/catalogue]
-fixed-by:
-amended-design:
+fixed-by: mesh-catalog PR 193 (the conversion), mesh-controller PR 170 (TestPlacedDirectoriesKeepTheirPaths, which proves it moved nothing); the placed-directory mechanism itself predates this in mesh-controller internal/catalogue/dir_into.go
+amended-design: 03-DESIGN/01-to-be/27-a-module-requires-the-mesh-resolves.md
 ---
 
 # 119 — A module definition decides where its files live on the machine
@@ -133,3 +133,30 @@ not by any check.
 - What identifies an assignment, if a module may be assigned to one node more than once?
 - What would the contributions file carry instead of host paths, so a provider needs no
   identical-path mount?
+
+## Resolved, 2026-09-30 — the module's half; the mesh's half is issue 174
+
+**A definition no longer decides where its own data lives.** Twenty-eight definitions that named their
+data directories now place them: the module's root as `place: "."`, a sub-directory by its id, and every
+host-side reference — bindings, secrets, own secrets, grants, receives, file paths, mounts, env-files —
+as `${dir:<id>}`. Twenty-eight others had already been written that way. Five directories whose id is
+not their last segment keep their path as a placement, which is the exception the design allows and
+the reason nothing else has to move for them.
+
+**Nothing moved, and a test says so.** The controller's `TestPlacedDirectoriesKeepTheirPaths` takes the
+catalogue before and after, resolves every converted definition on the default root with the
+controller's own rule, and compares it whole with the definition before it: identical for all
+twenty-eight. So the retirement this record said was a data migration turned out not to be one, on
+one condition — a node's default root is where the data already is, and every node's is — and the
+machines see no change. A node that sets another root is the case this does not cover, and it does
+not exist.
+
+**What remains is not this record's.** The 232 host paths still in the catalogue are where the mesh
+writes what it makes for a module, under `/var/lib/mesh/<module>`; design 27 says the mesh places
+those itself, and it does not yet. That is [issue 174](../174-the-meshs-own-files-for-a-module-are-placed-by-the-definition/00-report.md).
+The defects this record listed under *where that has already gone wrong* are unchanged by this and
+stay in 174's scope where they concern the mesh's files; the operator's shared data stays an access
+([ADR 0051](../../02-DECISIONS/0051-shared-data-is-the-operators.md)).
+
+The manifest change lands with the catalogue's next merge; the rollout is a rebuild that changes no
+machine, checked by comparing each machine's plan before and after.

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

@@ -0,0 +1,48 @@
+---
+status: located
+opened: 2026-09-30
+located-in: [mesh-controller internal/catalogue/dir_into.go, mesh-controller internal/catalogue/declaration.go, mesh-catalog modules]
+fixed-by:
+amended-design:
+---
+
+# 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](../119-a-module-definition-decides-where-its-files-live/00-report.md)), 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.