jochen
907051c21d
The review found questions no record decides: 012's minimum-viable-node half and 027's packaging, secrets, sizing and leftovers questions, so both stay active. Where the record lives (006) is issue 414, and 037's two other leftovers are issues 415 and 416; to-be 06 now points at issue 414.
4.8 KiB
4.8 KiB
status, initiated, touches, became
| status | initiated | touches | became | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| graduated | 2026-08-22 |
|
|
001 — Module domain decomposition
- Initiated by: jochen, 2026-08-22
- Areas touched: every
hal/*andnoxflow/*module; the pipeline's dependency graph; the knowledge base; agent identity and credentials.
Summary
HAL has 124 modules. That number is not a maintenance problem in itself — it is the symptom of missing bounded contexts. Modules are split not because they model different domains, but because splitting is the only lever the platform offers:
- no way to run one daemon on one node without making it a module
(
hal/claude-licences— one daemon, single-node) - no way to expose two of a kind from one module
- no namespace separating the mesh from the software it runs
This effort establishes the current state, the ideal state, and the sequence between them.
Trigger
A night of debugging that produced four fixes and one conclusion. Every fault was a boundary fault:
- Per-agent Claude credentials had to be written by the noxflow runtime, because
agents.claude_accountis in noxflow's database — even though agent identity is a mesh concept and node identity already lives in the mesh registry. - Whether
hal/brainmay depend on noxflow took three attempts to answer, twice wrongly, because the ownership boundary was never stated. - Authoritative documentation existed in
mesh_docsand was not found, while a proposal in repo markdown was invisible to search entirely.
Decisions taken (2026-08-22)
| Question | Decision |
|---|---|
| What should noxflow become? | Decompose into hal/* modules; noxflow returns to tasks/workflows |
| Who owns agent identity? | hal/agents — a mesh concept, alongside nodes |
| Where do third-party apps live? | Out of this repo. They run on the mesh; they are not of it |
| Knowledge structure | Modelled on papa-hq; implementation choice left open |
Open questions
Tracked in analysis.md under "Open questions".
Deliberately not decided
Recorded so they are not mistaken for oversights. Each was open, and each came out of ADR 0001; how each was answered is under What it became below.
| Question | Status |
|---|---|
hal/scheduler — infrastructure, or part of the work context. |
Open. |
| Which context owns the executor. | Open. |
| Catalogue destination — one repository or many. | Open. Phase 4. |
| What the shared library keeps after extraction. | Open. Phase 3. |
| Where human agent modality is recorded — which user, on which node, a human agent acts as. | Open. Required by the model; not yet stored. |
| Which domains the modules outside the platform core group into. | Open, from ADR 0009, which settles the principle and deliberately not the list. |
What it became
Closed 2026-10-10. Every question left open was answered by a later record, or stopped applying.
- The scheduler and the executor were questions about two of the predecessor's modules. The predecessor is retired and the operator's machines are the mesh's (ADR 0173), so neither module exists to place.
- One catalogue repository or many: ADR 0037 — the mesh's own parts live in the repositories that build them, software the world made is described in one catalogue, and an application carries its description at its own root.
- What the shared library keeps: ADR 0039 — the stable spine, and never a module's own client or tools.
- Which user, on which node, a person acts as: ADR 0181 — the operator account is a fact of the node.
- Which domains the modules group into: ADR 0009 settled the principle and ADR 0244 the domains.