Merge pull request 'The pointers back from what yesterday's records changed, which I missed twice' (#197) from decision/the-pointers-back-from-what-these-narrow into main

2026-09-29 22:47:45 +00:00
parent 83791f0921 53b94c51bb
commit ba30286896
8 changed files with 76 additions and 3 deletions
@@ -13,6 +13,14 @@ decisions taken over three days; the reasoning is kept, the fragmentation is not
 The environment a change is run against before it reaches real machines.
 > **Still the lab, no longer the test bed — 2026-09-30, by [ADR 0149](0149-the-live-mesh-is-the-test-bed.md).**
 > Everything here stands. What changed is what the lab is *for*: a change is verified against the mesh
 > that is running, because the faults that cost the most are faults of a mesh that already exists —
 > bound consumers, containers made against an older roster, an adopted machine — and a bed is by
 > construction a mesh that does not. Raising a mesh from bare is now the lab's whole job, which is the
 > one thing the live mesh cannot be asked to do. 0149 also supersedes
 > [ADR 0068](0068-the-lab-takes-requests.md), which extended this one and was never built.
 ## A node in the lab is a virtual machine
 It boots a stock Linux image, runs the real install, and becomes a node. **It is not a model of
@@ -80,6 +80,15 @@ reaching the routed name, which the clause above has just made resolvable inside
 three are one decision: **compose the name, propagate it, certify it** — each is meaningless without
 the one before it.
 > **The mechanism changed — 2026-09-30, by [ADR 0148](0148-the-meshs-names-are-resolved-not-copied-into-containers.md).**
 > A routed name still reaches every asker in the mesh, which is what this record decided and it stands.
 > It no longer reaches them by being written into each declared container: copying the roster in made the
 > roster part of every container's identity, so one name moving replaced every container in the mesh
 > ([issue 151](../04-ISSUES/151-a-new-name-recreates-every-container-in-the-mesh/00-report.md)). A
 > container resolves through its machine's resolver instead. The consequence below — that an internal
 > issuer's challenge needs the routed name resolvable inside the mesh — holds unchanged, by the means the
 > machine itself already uses.
 ## Consequences
 - **Lab-versus-production is one node-level `public-domain` setting**, not an override on every
@@ -48,6 +48,31 @@ form above and dated no earlier than the record's own `date:` — an unmarked ed
 violation the reviewer looks for in the diff, and a marked one is legible in the record itself.
 The git history is the backstop, not the record of intent; the note is the record of intent.
 ## A pointer back from what a record changes
 A new record naming an old one is not enough. **Where a record changes a mechanism an older record
 states — without reversing the decision, so no supersession — the older record gets a dated note
 saying where its mechanism now lives.** A reader arrives at the old record by following a citation,
 and finds text that is still the decision and no longer the method; nothing in it says a later record
 moved the method, and the new record is not in their hands.
 > **The mechanism changed — YYYY-MM-DD, by ADR NNNN.** What still stands, what moved,
 > and why.
 Three examples of the shape, all found by being missed: ADR 0066 still described a routed name being
 written into every container after 0148 replaced that with resolution; ADR 0047 still said a module's
 code runs in a container after 0150 made it a supervised process; and ADR 0016 still read as though the
 lab were the test bed after 0149 said the live mesh is. Each was a citation leading to the wrong
 answer, in a record that was not wrong about anything it decided.
 **This is not machine-checked, and it cannot be from `extends:` alone.** 102 records extend another and
 87 name a parent that does not mention them, which is correct: extending usually means building on a
 context, and a one-directional pointer is the right shape for that. What needs a note is the narrower
 case where the parent's own text has gone stale, and which case that is, is a judgement — so it is a
 rule for the author and the reviewer, and the diff is where it is caught. Making it mechanical would
 mean a record declaring the relationship in its frontmatter, which is a change to the record schema and
 has not been decided.
 The records run in the order the decisions were taken, oldest first.
 **Every decision is a record.** There is no ledger and no index file — if a decision is worth
@@ -5,7 +5,7 @@ code:
  - mesh-controller cmd/mesh-builder
  - mesh-controller internal/builder
  - mesh-catalog modules/builder
-updated: 2026-09-29
+updated: 2026-09-30
 decisions:
  - 02-DECISIONS/0150-a-modules-own-code-runs-as-supervised-processes-under-one-account.md
  - 02-DECISIONS/0142-the-mesh-delivers-its-own-components-as-binaries.md
@@ -5,7 +5,7 @@ code:
  - mesh-catalog modules/showcase
  - mesh-controller internal/builder
  - mesh-sdk src
-updated: 2026-09-21
+updated: 2026-09-30
 decisions:
  - 02-DECISIONS/0150-a-modules-own-code-runs-as-supervised-processes-under-one-account.md
  - 02-DECISIONS/0099-a-step-that-runs-once-names-what-it-reads.md
@@ -59,3 +59,17 @@ container is made with are the same kind of input, read once at creation, and ar
  and is the stronger statement; it is also what the mesh's own resolver exists for.
 - Either way: what tells an operator that a container is running with an address the node no longer
  has? Nothing did.
 ## Answered at the cause (2026-09-30)
 This was the first of three arrivals of one fact: a container is given the mesh's names when it is
 created and never looks again, so a name that moves afterwards is wrong inside it for as long as it
 runs. It arrived again as [issue 135](../135-a-containers-mesh-names-are-not-compared/00-report.md),
 whose fix made the names comparable — and that fix made the roster part of every container's identity,
 which arrived as [issue 151](../151-a-new-name-recreates-every-container-in-the-mesh/00-report.md).
 [ADR 0148](../../02-DECISIONS/0148-the-meshs-names-are-resolved-not-copied-into-containers.md) ends the
 copying: a container resolves through its machine's resolver at the moment it asks. The shape this
 record reports then has nowhere to occur. It is gated on
 [issue 110](../110-a-container-on-the-runtimes-own-network-cannot-reach-the-resolver/00-report.md), so
 until that lands the mesh still copies and still compares.
@@ -2,7 +2,7 @@
 status: resolved
 opened: 2026-09-25
 located-in: [hq, mesh-catalog modules/showcase, mesh-sdk src/tools/index.ts, mesh-tools]
-fixed-by: hq ADR 0150 — a module's own code runs as supervised processes under the module's one account; designs 18 and 20 now cite it, and ADR 0047 carries a dated note pointing at it
+fixed-by: hq 83791f0 (PR 196) — ADR 0150: a module's own code runs as supervised processes under the module's one account; designs 18 and 20 now cite it, and ADR 0047 carries a dated note pointing at it
 amended-design:
 ---
@@ -68,3 +68,20 @@ container runtime's shape, not a choice; the answer is to recreate, which is wha
 that would rather re-read a roster from a file can already ask for one as a fact
 ([ADR 0120](../../02-DECISIONS/0120-a-roster-fact-carries-its-format-as-a-template.md)) and restart on
 it.
 ## What replaced this fix (2026-09-30)
 The fix here — putting the mesh's names into the digest the host compares, so a container whose names
 moved is recreated like one whose image moved — worked, and cost more than it was worth. It made the
 roster part of every container's identity, so one name moving replaced every container in the mesh: a
 module assigned on one machine restarted the store, the registry, the edge and mail on another
 ([issue 151](../151-a-new-name-recreates-every-container-in-the-mesh/00-report.md)).
 [ADR 0148](../../02-DECISIONS/0148-the-meshs-names-are-resolved-not-copied-into-containers.md) goes at
 the cause this record only described: **a copy taken at creation is stale the moment the roster moves,
 and detecting that is not as good as not copying.** A container resolves the mesh's names through its
 machine's resolver, at the moment it asks, so the fault this record reports cannot occur rather than
 being noticed a restart later.
 Recorded here because this is where somebody arrives to find out why the digest carries names, and the
 answer is that it did, for two days short of a month, and stopped.