Files
hq/04-ISSUES
jschoubben 333356cff3 Order the records the way the system is learned
Jochen asked whether the order made sense. It did not -- it followed when
things happened to be decided, which after consolidation is fictional anyway
since record 5 alone folds decisions taken across a week.

Concretely wrong before: the domain statement sat at 8, after five engineering
rules; the constitution was scattered across 5, 12 and 17; the tiers landed at
15, 16, 21 and 22 with process records in between.

Now it walks: what the mesh is (1-3), its tiers from the bottom up (4-8), what
runs on them and how it gets there (9-10), how it is built (11-16), how it is
checked (17-18), how we work (19-23).

Two things made this safe rather than free. It is a permutation, not a
compaction, so the renames go through temporary names -- otherwise two files
want one slot and one is lost. And the reference rewrite is a single
simultaneous pass, because almost every number moved into a slot another number
was vacating; replacing one at a time would have cascaded and pointed things at
the wrong record while still resolving.

Verified: 284 [ADR NNNN](path) links across the repository, all with matching
text and target.

The ordering principle is now stated in 19 rather than left implicit -- the
repository already said "the numbering is the flow" about its folders, and
there was no reason for the records to be the exception.
2026-08-28 23:30:42 +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.