5 Commits

Include renames

Author	SHA1	Message	Date
mesh-tools	6be8f6eada	Feature 57 (config and provisioning): the record of its designs, playbooks and glossary words, synced with main	2026-10-16 07:22:11 +00:00
jochen	daa9f171ae	Issue reports carry only opened: the tracker holds every status, so no copy can drift ... The import of slice 3 (ADR 0275) was checked against every folder: no report changed since the commit it read, and the tracker holds each report's status, owner, fix, design amendment, replay and closing day. The keys are removed from all 361 reports, cycle.py refuses them in any report, and the playbooks, skills and READMEs that still pointed at them name the tracker instead.	2026-10-10 17:44:18 +02:00
jschoubben	36d9b38a0d	An issue is open, diagnosing, located, resolved or wontfix — nothing else ... The playbook, the README and the status skill knew five statuses; the cycle check knew a sixth, 'fixed', and not 'wontfix'. Eleven issues sat in the sixth for weeks with their fixes shipped, one step short of closed. They are resolved; the check refuses the word from now on and accepts the one the playbook allows.	2026-09-21 17:38:17 +02:00
jschoubben	80f18caf03	022 fixed; 023 filed — a password is not a connection ... 022 turned out to have a silent half worth recording: the provider refuses loudly and names the modules, which reads as a decision, while the consuming node does not refuse at all. Three modules wanting one database produce one need, so two of them get no credential file and each starts and fails to authenticate with nothing saying why. 023 is what remained after fixing it. A consumer now gets its own password, in whatever shape its configuration wants, and still cannot connect: the user name is invented by the provisioner and recorded nowhere in the mesh, and the host and port sit in a JSON binding that an application reading KEY=value cannot use. The asymmetry is backwards and the coverage document now says so. The secret is the hard case, because the mesh must not be able to read it, and the secret is the part that arrives. The host and port are ordinary facts the mesh holds in the clear, and they are the ones stuck. Keycloak, Gitea, Mailu and MinIO all parse and resolve and none of them can start. This is what stands between the module set and a running one.	2026-09-01 02:40:40 +02:00
jschoubben	c86adbe3cc	022 — a credential belongs to a node, so a second consumer refuses ... Found while checking whether the module vocabulary covers real use cases. A node running three modules that all want a database cannot be planned at all: anchor has 3 modules asking for "postgres-database" and they would share one credential: gitea, keycloak, umami The refusal is right about what it says and wrong about what it implies. They would share one credential, and sharing is worse than refusing — but the arrangement being refused is the ordinary one, and the node this mesh exists to take over runs eight modules against one database server. The cause is the key: a credential is keyed by provision, consumer node and provider node, so `consumer` is a machine. The provisioner inherits it and names the role `mesh_<node>`. The refusal is not a check that caught something; it is the only honest thing that function can do with a key that cannot tell two consumers apart. It is the same mistake as 021 with a different face. There the machine was treated as a trust boundary; here it is treated as an identity, as though "who is asking" is answered by naming a host. Two modules on one node are as separate as two on different nodes. Worth stating plainly: without the refusal, gitea's login would have opened keycloak's database, and nothing would have said so — from the provisioner's side it created exactly what it was asked to create. Not a local fix. It crosses the control plane, the grant file naming and every provisioner that names something after a consumer.	2026-09-01 02:28:39 +02:00