026 reopened — the rule is right about data, wrong about facilities

Enforcing "declare what you mount" refuses the builder, which mounts the
container runtime's socket. That socket is not the builder's data: it
exists already, the machine owns it, and declaring it as one of the
module's directories would be a lie the host would act on.

Two kinds of mount are spelled identically today — the directory my data
lives in, and a machine facility I was granted. Until a manifest can say
which, the fourteen declared mounts are right by coincidence, which is
what this issue was opened about.

Recorded rather than decided: separating them is new vocabulary, and
inventing it to turn a check green is how a mechanism nobody chose ends
up load-bearing.

04-ISSUES/026-the-data-directories-are-not-declared/00-report.md

@@ -1,8 +1,8 @@
 ---
-status: fixed
+status: located
 opened: 2026-09-01
 located-in: [mesh-control]
-fixed-by: mesh-control 53eb000
+fixed-by: partly — mesh-control 53eb000, withdrawn in 83c6a2f
 amended-design:
 ---
 
@@ -69,17 +69,28 @@ arrangement being replaced, which put everything under one directory per service
 right here is a separate question, and a bigger one — it decides what a person backs up, and what
 survives a module being removed.
 
-## Fixed
+## Half fixed
 
 **All fourteen are declared**, across the forge, the mail system, the store and the object store —
 each mount now resolves to a `directory` or to a file the module already names.
 
-**And a manifest that does not declare one is refused**, where it is written. The manifests being
+**Enforcing it was tried and withdrawn**, and the withdrawal is the interesting half. A refusal
-right today was a coincidence: nothing said they had to be, so the next volume somebody added
+for any mount no resource declares refuses the **builder**, which mounts the container runtime's
-would have been undeclared again and nothing would have said so. A path under a declared directory
+socket. That socket is not the builder's data. It does not belong to the module, it already exists,
-counts as declared, as do a module's own secrets, its grants, and what it receives.
+and declaring it as one of the module's own directories would be a lie that the host would act on.
 
-Refused in the control plane rather than on the machine, which cannot tell the difference: by the
+So the rule is right about data and wrong about everything else, because the manifest cannot
-time the host sees the mount it is being asked to create a directory, which it is perfectly able to
+currently say which a path is. Two kinds of mount are spelled identically:
-do. The fault is in the manifest, so it is named at the manifest — the same argument as the action
+
-refusal it now sits beside.
+- **the directory my data lives in** — created if absent, owned by the module, protected by
+  [ADR 0030](../../02-DECISIONS/0030-data-outlives-the-mesh-that-declared-it.md)
+- **a machine facility I was granted** — a socket, a device; it exists, the machine owns it, and
+  the module is being given access to it
+
+`capabilities` is the closest existing thing to the second and names no paths. Inventing a field
+to separate them is a design decision, so it is recorded here rather than made to get a check
+green.
+
+**Until then the manifests are right by coincidence**, which is the state this issue was opened
+about. What is kept is a check that every real manifest still parses — worth nothing against this
+fault, and the reason the next attempt finds out in a second rather than in a fifteen-minute run.