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:
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user