Issue 081 opened (a cache consumer does not use its login); 079 and 080 diagnoses carry the review's consequences

04-ISSUES/079-every-machine-is-named-twice-over/01-diagnosis.md

@@ -22,3 +22,10 @@ machine with an address, while the resolver's "on the private network" is a mach
 runs the module that puts it there. The names follow the resolver's rule now — one predicate,
 used by both — held by a controller test that unassigns one machine's networking and reads the
 names back.
+
+Two consequences of the one predicate, on review. The filter's "from the mesh" set is that same
+set now, so a rule admits exactly the machines the mesh names. And a machine whose assigned set
+fails to resolve is no longer on the network in the mesh's eyes: its name leaves every other
+machine's hosts file and every resolver's zones on the next push, and the mesh's report of that
+machine's failure is what says why — the stated preference for a name that fails at once over a
+connection that hangs, at the cost of one machine's failure being visible mesh-wide.

04-ISSUES/080-a-cache-grant-lets-the-consumer-flush-the-server/01-diagnosis.md

@@ -7,3 +7,8 @@
    what a consumer scoped to a prefix should use.
 
 **Located in:** the redis module's client. Not a decision. Proven by the grant end-to-end bed.
+
+*On review.* `INFO` is in the dangerous category and several client libraries ask it at connect;
+it reads nothing a consumer keeps, so it is allowed back. Whether the catalogue's two cache
+consumers need anything else the category removes is unverified — and moot until they present the
+login they were granted ([issue 081](../081-a-cache-consumer-does-not-use-the-login-it-was-granted/00-report.md)).

04-ISSUES/081-a-cache-consumer-does-not-use-the-login-it-was-granted/00-report.md

@@ -0,0 +1,31 @@
+---
+status: open
+opened: 2026-09-22
+located-in: [mesh-catalog modules/n8n, mesh-catalog modules/baserow]
+---
+
+# 081 — A cache consumer does not use the login it was granted
+
+## Symptom
+
+Two catalogue modules require the cache and are given a login and a password under a keyspace of
+their own ([issue 080](../080-a-cache-grant-lets-the-consumer-flush-the-server/00-report.md)),
+and neither tells its software the login: each hands it the host, the port and the password only,
+so the software authenticates as the server's default user and writes wherever it likes — or is
+refused, if the default user is closed. The grant is honoured by the provider and ignored by the
+consumer.
+
+Found on review of issue 080, by reading the two manifests. Not run: no bed installs either
+module against the catalogue's cache and reads what it wrote.
+
+## Why it matters beyond the instance
+
+A grant is two ends agreeing. The provider's end is checked by the grant bed; the consumer's end,
+that the software actually presents what it was given, is checked by nothing but the module
+working — and a module that works as the default user works.
+
+## What would close it
+
+Each module passes the login it was bound (`${bound:redis-cache:as}`) to its software's username
+setting, and a bed installs one of them against the catalogue's cache and reads back that its keys
+sit under its login.