Files
hq/04-ISSUES
jschoubben 77f3a4cea7 Consolidate: 65 decision records to 23
Every remaining cluster merged. Each was one design that had been split across
several records because it was worked out over days rather than at once.

  the node host          8 -> 1    applies not decides, depends on nothing,
                                   per operating system, root service, the
                                   launcher, episodic, what a declaration is,
                                   actions from the bundle only
  a node and how it joins 4 -> 1   what a node is, joining, the link as
                                   security boundary, the enrolment token
  modules and the graph   7 -> 1   everything is a module, no domain modules,
                                   three edges, provisioning, the core library
  substrate and control   6 -> 1   the test, seven contexts, one control plane,
    plane                          the authority is not a database, the named
                                   products, the pinned bundle
  connectivity            3 -> 1   a route is a grant, reachability declared,
                                   filter rules
  delivery                5 -> 1   reconciliation not a pipeline, artifacts,
                                   the three silos, a failed step, the verdict
  the lab                 5 -> 1   (earlier)
  how this repository     10 -> 1  (earlier)
    works

Nothing was dropped. Each consolidated record carries the reasoning of the ones
it absorbs -- the measurements, the incidents, the alternatives rejected --
because that reasoning is the only reason to keep a record at all. What is gone
is the fragmentation: eight files to read to understand tier 0, when tier 0 is
one component.

The four superseded records went too. They existed to point at their
successors, and the successors now contain what they said.

The checker made this safe. Each merge left dangling links -- 38 files after
the host merge alone -- and it named every one. Nothing was found by reading,
and a manual pass would certainly have missed some, including references inside
AGENTS.md which every session loads.
2026-08-28 20:03:24 +02:00
..

04-ISSUES

The front door for "something is wrong" at the level of the mesh's design or governance. Diagnosis happens here, where the whole mesh is in view; the fix lands in the owning code repository.

What belongs here

Belongs here Belongs in the knowledge base
The design permits a failure to be silent How to fix one occurrence of it
A documented rule is enforced by nothing A command that works around it
A stated invariant is false in practice A node-specific quirk
The owner is unknown and finding it needs the whole mesh in view Symptom → fix, once the answer is known

The knowledge base already holds the operational record and is indexed on symptoms. This folder is not a second copy of it. An issue here is a question HQ must answer; an entry there is an incident someone must clear. An issue whose answer is a general lesson belongs in both.

Structure

NNN-short-name/
  00-report.md      the symptom as observed, with the evidence; status in frontmatter
  01-diagnosis.md   the investigation trail, dated, including what was ruled out

Frontmatter, on 00-report.md

---
status: open | diagnosing | located | resolved | wontfix
opened: YYYY-MM-DD
located-in: []       # owning repo(s) or module(s), filled by diagnosis
fixed-by:            # pull request or commit reference, filled at resolution
amended-design:      # design doc path, when the root cause was a design gap
---

Rules

  • Anyone may open an issue. No localisation is required to report one.
  • The full flow is playbook 00-META/process/03-issues.md.
  • Closed issues are never deleted — they are the mesh's symptom-to-component memory.
  • wontfix is legitimate and requires a sentence saying why.