jschoubben
4bf4fe2d06
Asked whether the host is built for more than one architecture. It is not, and the reason is worse than a missing feature. A bundle in a compiled language must name a system, must name one of alpine, android or arch, and is refused with a careful message if it gets that wrong. The field is then read by nothing: it does not reach the compiler, no machine is matched against it, and nothing chooses between two artifacts by it. The compile runs with no target named and produces a binary for whatever the build machine happens to be. The host is x86-64 because the build machine is, not because the declaration said so. Correct for this mesh by coincidence — four machines, all x86-64 Arch. A module declaring two systems would get two identical binaries, both published and both pinned, and the one sent to the machine it was not built for would fail at exec. android is the sharp end: not an x86-64 platform, and an artifact declared for it today would be an x86-64 binary wearing the label. A field that is checked and ignored is worse than one that does not exist, because the check is what persuades you it works. Also noted: the processor is a second dimension the manifest has no word for, so even implementing the present field would not answer the question that found this. And since the Go toolchain builds statically, one binary would run on all three systems anyway — so the pin is a policy rather than a necessity, which is a decision and not a fix.
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.
wontfixis legitimate and requires a sentence saying why.