Issue 119 resolved for a module's own data; issue 174 for the mesh's files; design 27 phase 3 in part

This commit is contained in:
2026-09-30 21:11:42 +02:00
parent 5292f4176a
commit 1e1957a9c4
3 changed files with 85 additions and 3 deletions
@@ -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