Issue 112 diagnosis: correct located-in attribution

The carried-peer record (CarriedPeer/TunnelPeer) lives in mesh-controller
internal/inventory, not internal/catalogue. internal/catalogue is the
right package for the zone-generation side of the fix (facts.go's
nodeZones), but a different concern from where the name field itself
would go. Split the two so a decision record doesn't get pointed at the
wrong package.
This commit is contained in:
2026-09-24 13:54:20 +02:00
parent 6a56738d7b
commit 75c104c355
2 changed files with 12 additions and 7 deletions
@@ -1,7 +1,7 @@
---
status: diagnosing
opened: 2026-09-24
located-in: [mesh-controller internal/catalogue, mesh-controller cmd/mesh-controller, mesh-catalog modules/dnsmasq]
located-in: [mesh-controller internal/inventory, mesh-controller internal/catalogue, mesh-controller cmd/mesh-controller, mesh-catalog modules/dnsmasq]
fixed-by:
amended-design:
---
@@ -54,12 +54,17 @@ inventing a fact under time pressure — it is the predecessor's own record, cur
correctly serving these three names for six days without correction. Recording it is transcription,
not assertion.
**located-in, tentatively:** `mesh-controller internal/catalogue` (where a carried peer's fact would
need a name field) and `cmd/mesh-controller` (a command to set it — nothing today lets an operator
attach a name to a carried-tunnel-peer record; `node add` is for enrolling nodes, not naming
peers). `mesh-catalog modules/dnsmasq` would then need to emit an `address=` wildcard for a *named
carried peer* the same way it does for a node, which the module's own generation code does not
distinguish today.
**located-in, tentatively:** `mesh-controller internal/inventory` (where a carried peer's record
lives today — `CarriedPeer`/`TunnelPeer` in `tunnel.go` carry a public key and an address but no
name field) and `cmd/mesh-controller` (a command to set it — nothing today lets an operator attach
a name to a carried-tunnel-peer record; `node add` is for enrolling nodes, not naming peers, and
`node public-domain <name> <d>` is the closest existing shape to model a new verb on). Separately,
`mesh-controller internal/catalogue` (`facts.go`'s `nodeZones`) would then need to emit an
`address=` wildcard for a *named carried peer* the same way it does for a node — it renders only
from the mesh's `addresses` map today, keyed by node name, and does not distinguish a named carried
peer from an unnamed one. `mesh-catalog modules/dnsmasq` itself needs no change: it already
restarts on the `node-zones` fact and would pick up the new wildcard the moment `internal/catalogue`
emits it.
## What is still open