jschoubben
c2a37ab7f8
Jochen's call, and the right one: a module cannot choose a port well, because it is written once and assigned anywhere. Any number it picks is a guess about a machine it has never seen, and two modules guessing the same number is not a mistake either of them made. Writing it up turned up something the issue had missed. The same number appears three times in every module — the rule set, what a consumer is told, and what the runtime publishes — and nothing checks that they agree. They agree today because one person wrote all three. A module whose `serves` said one thing and whose container published another would resolve, compose, apply, and hand every consumer a port that answers nothing. So the decision is one source with the other two derived, and an assignment made once and kept, as a credential is. The part that needed thought is ports that cannot move — mail on 25, submission on 587. Those become claims, which is what the mesh already has for what is singular on a machine. Two modules wanting 25 is the same shape as two wanting the seat, and gets refused by name at assignment rather than by a container runtime at apply. That makes this mostly a matter of pointing an existing mechanism at ports. Left open: whether a module should publish to the machine at all. Assignment makes publishing safe without making it necessary.
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.