Issues 046, 049 and 069 located, each with the decision its fix needs named

2026-09-21 17:50:42 +02:00
parent 16442ecd23
commit 62ff9a5bd3
6 changed files with 62 additions and 6 deletions
@@ -1,7 +1,7 @@
 ---
-status: open
+status: located
 opened: 2026-09-14
-located-in: []
+located-in: [mesh-controller internal/builder (upstream artifacts)]
 fixed-by:
 amended-design:
 ---
@@ -0,0 +1,17 @@
+# Diagnosis — 2026-09-21
+
+1. What was established stands: the failure is in going through a machine's image store, whose
+   newer store keeps an index and refuses to push a single platform out of it. Every variant of
+   pull-then-push was tried and failed the same way.
+2. The first open question answers the other two. A copy between registries never needs a
+   platform, because it moves what is there — the index and every manifest it names, or one
+   manifest if the module says so. The registry API is enough for it: read the index, read each
+   manifest, mount or upload each blob by digest, put the manifests and then the index under the
+   module's repository. No image store is involved and the runtime's behaviour stops mattering.
+3. Whether the mesh mirrors an index or a platform is then a choice the copy can offer rather
+   than a limitation; today every machine on one mesh is the same architecture, and that
+   assumption is now written down here rather than nowhere.
+
+**Located in:** the builder's upstream-artifact step. Not fixed here: a registry-to-registry copy
+is a few hundred lines against the registry API and is proven only against a real registry
+serving a real index, which is a lab run of its own.
@@ -1,7 +1,7 @@
 ---
-status: open
+status: located
 opened: 2026-09-14
-located-in: []
+located-in: [mesh-controller cmd/mesh-controller, mesh-tools (the request contract)]
 fixed-by:
 amended-design:
 ---
@@ -0,0 +1,18 @@
+# Diagnosis — 2026-09-21
+
+1. The refusal is the scope working as designed: a module's broker account covers what it emits
+   and consumes and nothing else. A tool call needs a reply queue the caller creates and a publish
+   to the serving module's request queue, and no declared scope grants either.
+2. Of the three callers the report names, two already have an account with the right shape. The
+   controller holds an admin connection to the broker, and an agent acting for an operator runs
+   through the controller. Another module is the only caller that would need something minted.
+3. The honest first step is therefore the third option in the report: the controller is the way
+   in. A `mesh-controller ask <module> <tool>` needs no new account, routes every question
+   through one process — which is where an audit of who asked what belongs anyway — and settles
+   what a module declares about being asked by declaring nothing: serving a tool is being
+   askable through the controller. A module-to-module call, if one is ever wanted, is a grant
+   like any other, and a later decision.
+
+**Located in:** the controller (a command speaking the tool request/reply over its own connection)
+and the tool runtime's request contract. Not fixed here: it is a new command against a protocol
+the runtime owns, and needs a lab run against a tools-only bed to be proven.
@@ -1,7 +1,7 @@
 ---
-status: open
+status: located
 opened: 2026-09-20
-located-in: []
+located-in: [mesh-controller internal/catalogue (requires/secrets), mesh-controller internal/inventory (secret key)]
 fixed-by:
 amended-design:
 ---
@@ -0,0 +1,21 @@
+# Diagnosis — 2026-09-21
+
+1. The constraint is real and where the report put it: a module requires a provision name once,
+   a pair credential is keyed on (name, consumer node, consumer module, provider), and the login
+   the vault derives is keyed on the (node, module) pair. Two secrets for one module and one vault
+   collide on every key.
+2. The third question was answered by reading the ten modules. Six of the "two" cases hold two
+   names for one value or a value derived from another (an admin password and a token only ever
+   set from it, a relay user that is a fixed string beside the relay password). Those are one
+   secret each, and the module's own business to derive from. The "three or more" cases are
+   genuinely independent: a root certificate, its key and that key's password are three values
+   with three lifetimes.
+3. So the answer is neither option as the report framed them. A module keeps one `secret`
+   provision per independent value, and needs a way to require the same provision name more than
+   once under distinct local names — the way `secrets:` already maps a provision to a path. That
+   is a manifest-vocabulary decision, and it moves the pair key: the credential must be keyed on
+   the local name, not the provision name, or the second pair overwrites the first.
+
+**Located in:** the manifest's `requires`/`secrets` vocabulary (the catalogue parser) and the pair
+credential's key (the controller's secret store). Not fixed here: the key change touches every
+existing pair and belongs in a feature of its own, with a lab run against the vault bed.