jschoubben
2c8616b650
Numbers 008 and 009 were taken on main after this branch was opened (008-provider-runtime-has-no-seal-key, 009-runtime-config-change-does-not-restart, both merged). Renumber the seed-file-wipe and shared-directory issues to the next free numbers so merging records two more issues rather than duplicating two. Claude-Session: https://claude.ai/code/session_01LrgweAeERJYBg88c5cKDzF
2.6 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design |
|---|---|---|---|---|
| open | 2026-09-02 |
012 — Six modules own what they must share
The symptom, as observed
Found by review of the catalogue examples (2026-09-02). The media stack is several modules — a library server, the acquisition managers, a download client and their satellites — and each of them declares the same library and download directories as its own resources.
The resolver refuses two modules that declare one path on one node, with no exemption for identical content and no merge. That rule is right in general: two owners of one path is the class of fault this repository keeps recording. But sharing those directories on one machine is the entire point of this stack — the download client and the managers must see the same downloads, the library server must see the same libraries. So the set, as written, refuses its own only sensible assignment.
No test co-resolves any two of them, which is why the manifests pass today. The first machine to be assigned the stack together is where the refusal would have surfaced.
Why it matters beyond the instance
The manifests can express a directory I own and nothing else, so a directory that is the shared workspace of several modules was written six times as six private ones. The intention — several modules, one filesystem contract between them — has no vocabulary, and this is not a media-stack peculiarity: any pipeline of modules handing files to each other on one machine (an ingest directory, a spool, a drop folder) hits the same wall.
It is also a fork in the design the catalogue has otherwise avoided: the fix could be a new owning module the others depend on, a shared-resource concept in the manifest, or a statement that co-located file handoff is not a thing the mesh supports and these modules are one module. Each answer changes what a module is, which is why this is an issue and not a patch.
Open questions
- Is the unit wrong — is a stack that must share a filesystem one module with several containers, the way the mail module already is?
- If it stays several modules: does one of them own the directories and the rest require them, and is requiring a directory from a neighbour a provision, a claim, or a third thing?
- The duplicate-path rule protects against genuinely rivalrous owners. Whatever expresses sharing must not weaken it for the cases where refusal is the right answer — what distinguishes the two, machine-checkably?
- The mesh's own rule is that a rule states how it is checked: whichever shape is chosen, what test co-resolves the stack so this class of refusal is caught before a machine is?