Issue 153 resolved: an assignment places a module's directories and its accesses

mesh-controller PR 176 and mesh-catalog PR 198. Designs 27 and 18 carry the words: places, accesses, ${access:<id>}, the default a definition still holds while the catalogue converts.
2026-10-01 00:04:10 +02:00
parent 36454d7e4a
commit 52e9df0f02
3 changed files with 32 additions and 4 deletions
@@ -237,7 +237,7 @@ counts as a copy and what as a base.
 | `directory` | a directory with a mode and an owner, **placed by the mesh** under the node's root: `place: "."` is the assignment's own root, `place: "mesh"` the mesh's directory for the module, a pathless one sits beneath the root by its id; a stated path is the placement for data that must stay where it is, and may itself sit beneath a placed one (`${dir:<id>}/…`). Everything else names it as `${dir:<id>}` ([issue 119](../../04-ISSUES/119-a-module-definition-decides-where-its-files-live/00-report.md), [174](../../04-ISSUES/174-the-meshs-own-files-for-a-module-are-placed-by-the-definition/00-report.md)) | ✅ |
 | `file` | literal content, with `${bound:…}`, `${secret:…}`, `${dir:…}`, `${port:…}`, `${machine:…}` and `${setting:…}` filled in — the last an operator's value from the assignment's settings, refused by name when unset ([ADR 0155](../../02-DECISIONS/0155-a-definition-names-no-installation-and-how-that-is-checked.md)) | ✅ |
 | `user` | a login | ✅ |
-| `access` | a pre-existing path it may use and must not own | ✅ |
+| `access` | a pre-existing path it may use and must not own, **named by id** and placed by the assignment (`accesses: {<id>: <path>}` on its settings); mounts say `${access:<id>}`; a path in the definition is the default an assignment replaces, tolerated while the catalogue converts ([issue 153](../../04-ISSUES/153-an-adopted-machines-data-cannot-be-placed-where-it-is/00-report.md)) | ✅ |
 | `archive` | files fetched by digest and unpacked | ✅ |
 | `package` | a package that must be present | ✅ |
 | `network` | a named container network | ✅ |
@@ -137,6 +137,12 @@ lost is a named volume, not a directory ([ADR 0030](../../02-DECISIONS/0030-data
  the assignment says nothing;
 - **a placement**, where the assignment puts one directory elsewhere: on a second disk, or where an
  adopted machine's data already is ([ADR 0100](../../02-DECISIONS/0100-a-node-in-use-is-adopted-before-it-is-converged.md)).
+  *Built 2026-10-01 ([issue 153](../../04-ISSUES/153-an-adopted-machines-data-cannot-be-placed-where-it-is/00-report.md)):*
+  `places` on the assignment's settings, by directory id, with an owner where the data already has
+  one; and `accesses`, by access id, for the operator's data — an access has an id and its mounts
+  name it as `${access:<id>}`. Both validated as `endpoints` is: an id the definition does not
+  declare is refused. *How it is checked:* the controller's placement tests, and the
+  path-preservation proof extended to accesses.

 **An operator's shared data** is an access, as before ([ADR 0051](../../02-DECISIONS/0051-shared-data-is-the-operators.md)):
 never created, owned or removed by the mesh. The module requires read or read-write access. Where
@@ -1,11 +1,11 @@
 ---
-status: open
+status: resolved
 opened: 2026-09-29
 located-in:
  - mesh-controller internal/catalogue/dir_into.go (dirsFor: a stated path or <data root>/<module>/<id>, nothing else)
  - mesh-controller (accesses: the path is the manifest's literal)
-fixed-by:
-amended-design:
+fixed-by: mesh-controller PR 176 (`places` and `accesses` on an assignment, `${access:<id>}`, an owner the data already has); mesh-catalog PR 198 (ten definitions name their accesses by id)
+amended-design: [03-DESIGN/01-to-be/27-a-module-requires-the-mesh-resolves.md, 03-DESIGN/01-to-be/18-building-a-module.md]
 ---

 # 153 — An adopted machine's data cannot be placed where it is
@@ -55,3 +55,25 @@ The two assignment halves 0112 decided: a setting that places a declared directo
 path on this node, and a setting that says where an access's data is — both validated like
 `endpoints` (unknown ids refused), and an access placed by the assignment still never created,
 chowned or removed.
+
+## Resolved, 2026-10-01
+
+The two assignment halves ADR 0112 decided exist. On an assignment's settings, `places` puts a
+declared directory (by id) at a path on this node, with an owner where the data already has one —
+`{"config": "/where/it/is", "data": {"path": "…", "owner": "1001:2000"}}` — and `accesses` says where
+the operator's data is, by the access's id. Both are validated the way `endpoints` is: an id the
+definition does not declare is refused, naming what it does declare; a relative path and a
+non-numeric owner are refused; an access nothing places and whose definition carries no path is
+refused with the setting to write, rather than mounted as nothing. A placed directory is still the
+mesh's — created, owned as said, removed when empty and undeclared. A placed access is still the
+operator's — mounted, never created, owned or removed.
+
+An access now has an **id**, and the definition's mounts name it as `${access:<id>}`, so a placement
+moves the mount with it. Ten catalogue definitions were given ids; each keeps its path as the default
+an assignment may replace, so the machine that said nothing received exactly the paths it had before
+(the path-preservation proof, extended to accesses). That default is still a host path in a
+definition, tolerated as the transition: the media modules on the control node hold it until their
+assignments say where the data is, and then the defaults go.
+
+What the home server's assignments say next is the operator's: per media module, `places` for the
+configuration on the second disk and `accesses` for the pool, with the owner the predecessor ran as.