Issues 173 and 174 resolved; the installation check refuses at registration (ADR 0155)

A setting overrides a key a contribution or served fact declares and adds none; a provider that must
tell its consumers an operator's value declares it as ${setting:…} (173). The mesh's own files for a
module are a placed directory, `place: "mesh"`, and forty-eight definitions name no host path for
them (174). Registration refuses a definition naming an installation, the day the list emptied
rather than a release later (0155, progressive insight; 134). Designs 27 and 18 carry the rules.

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

@@ -153,7 +153,7 @@ 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).
+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). *Placed since later the same day: `place: "mesh"` — issue 174 is resolved.*
 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)).

04-ISSUES/134-a-definition-may-still-name-the-mesh/00-report.md

@@ -77,4 +77,4 @@ composes for its route**, read through the route's binding, and an operator's ow
 another mesh's forge stays a URL, which the check reports and `names-on-purpose` would declare. The
 seven values that remain are declared with their reason — four applications built outside the mesh —
 and are the list that shrinks ([ADR 0155](../../02-DECISIONS/0155-a-definition-names-no-installation-and-how-that-is-checked.md)).
-Registration does not refuse yet; it will when the list has been empty for a release.
+Registration does not refuse yet; it will when the list has been empty for a release. *2026-09-30, later the same day:* it refuses — the list was empty the day the check landed, and the operator asked for it (mesh-controller PR 175); `module add` and a build's result are refused in the check's words, with the way out, and the build stays recorded.

04-ISSUES/173-a-modules-settings-reach-every-fact-it-contributes/00-report.md

@@ -1,9 +1,9 @@
 ---
-status: located
+status: resolved
 opened: 2026-09-30
 located-in: [mesh-controller internal/catalogue/settings.go (settle), mesh-controller internal/catalogue/declaration.go (composed, ownNames)]
-fixed-by:
-amended-design:
+fixed-by: mesh-controller PR 175 (a setting overrides a declared key and adds none; `${setting:…}` in a served or contributed value); mesh-catalog PR 196 (mail declares its domain, the identity provider its issuer)
+amended-design: 03-DESIGN/01-to-be/27-a-module-requires-the-mesh-resolves.md
 ---
 
 # 173 — A module's settings reach every fact it contributes, not only the file that asked
@@ -45,3 +45,28 @@ asked for it. Until that form exists, this is the cost of the placeholder being
 - What does a consumer do with a served key it did not expect? Today: nothing, silently. A served
   map is not checked against what the provision's contract says it carries, because there is no such
   contract yet.
+
+## Resolved, 2026-09-30
+
+**A setting overrides a key a contribution or a served fact declares, and adds none.** A file keeps
+taking any key, because a configuration file is where an operator adds things; a contribution and a
+served fact are a contract the other side reads, and a setting made for one of the module's files is
+no part of it. A key that lands nowhere — no mergeable file, no `${setting:…}` asking for it, no
+contribution or served fact declaring it — is named as stray when the node is planned, rather than
+dropped.
+
+The first open question is answered the smaller way, and it turned out to be the right one: the two
+keys consumers actually read through the leak — the mail provider's `domain`, the identity provider's
+`issuer` — are now **declared** by the provider in what it serves, as the operator's value
+(`${setting:domain}`, `${setting:issuer}`), filled from the same setting that used to leak and refused
+by name when nothing sets it. So the contract says what travels, which is the shape design 27 draws,
+without a second key for overrides. The second question stands: a consumer still checks nothing
+against a contract, because there is none yet; what it is told is now only what the provider
+declared.
+
+*How it was checked:* the plans of all four nodes, under the running controller and the one with the
+rule, compared resource by resource — every key that disappears from a contribution is a leaked file
+setting or one of the mesh's own words (`expose`, `endpoints`), and nothing a provider reads goes
+away; the two served keys were declared before the controller rolled. Unit tests: a setting a route
+never declared does not reach the proxy; a served value nothing sets is refused by name; the setting
+a served fact asks for is not stray.

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

@@ -1,9 +1,9 @@
 ---
-status: located
+status: resolved
 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:
+fixed-by: mesh-controller PR 175 (`place: "mesh"`, a directory beneath a placed one, the proof test resolving both sides); mesh-catalog PR 197 (48 definitions converted)
+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]
 ---
 
 # 174 — The mesh's own files for a module are placed by the definition, not by the mesh
@@ -46,3 +46,21 @@ test that proved 119 can prove again with the rule extended.
 - 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.
+
+## Resolved, 2026-09-30
+
+The word is the one issue 119 introduced, with a second place: a directory saying `place: "mesh"` is
+the mesh's directory for the module, `<root>/mesh/<module>`, beside the assignment's own root and
+under the same node setting. The mesh's files keep their map shape and the container side of every
+mount stays the definition's — only the host side changed, to `${dir:mesh-state}/…`. A directory that
+sat beneath the mesh's (a forge's runtime state, a manager's output) states its path as
+`${dir:mesh-state}/<rest>` and moves with it; one that sits elsewhere by adoption (the registry's data)
+keeps its literal path as the exception it is.
+
+Forty-eight catalogue definitions and the controller's own manifest were converted mechanically. The
+proof is the same test that let issue 119 close, now resolving *both* checkouts before comparing,
+because the earlier manifest already placed its own directories: resolved on the default root, every
+converted definition names exactly the paths it named before. Nothing moved.
+
+Both open questions are answered by keeping what exists: the map stays, the host side is placed; the
+container side is the software's contract and stays where the definition says.