jschoubben
9dc57b4712
Continuing the sweep. Both were answered by records that did not cite them, which is the same pattern 003 showed -- an effort stays active because the decision that resolved it was reached from another direction. 005 graduates. Three of its four questions are answered: provider modules do not group (0044), the ~50 modules that co-change with nothing stay as they are, and 'group or leave' was never the right pair -- 0054 reframes it as authority versus package. Worth noting the debt runs the other way too: this effort's measurement, that reachability is the ONLY place modules genuinely co-change, is what 0054 rests on and why connectivity is a context while nothing else needed one. Its fourth question moves rather than closes. Whether applications leave the monorepo before or after they group is a sequencing question, so it belongs to 009-migration. 008 stays active, with its central question marked answered: the coordinator converges nodes on a declaration rather than dispatching stages (0058). The three-silo split survives with the third redefined. What 0058 explicitly does NOT answer is how a change becomes a pipeline reliably -- detection is upstream of everything it changed and remains the fragile input.
88 lines
4.8 KiB
Markdown
88 lines
4.8 KiB
Markdown
---
|
|
status: graduated
|
|
initiated: 2026-08-23
|
|
touches:
|
|
- 02-DECISIONS/0017-modules-outside-the-core-are-grouped-by-domain.md
|
|
- 03-DESIGN/00-as-is/10-module-catalogue.md
|
|
- 03-DESIGN/00-as-is/02-modules-and-manifests.md
|
|
became:
|
|
- 02-DECISIONS/0044-a-module-declares-presence-instantiation-and-exclusion.md
|
|
- 02-DECISIONS/0054-things-that-change-together-share-an-authority.md
|
|
---
|
|
|
|
# 005 — Which domains the catalogue groups into
|
|
|
|
[ADR 0017](../../02-DECISIONS/0017-modules-outside-the-core-are-grouped-by-domain.md) settles
|
|
that modules outside the platform core are grouped by domain rather than by single function,
|
|
and deliberately does not settle the list. This effort settles the list — and, first, tests
|
|
whether the premise survives measurement.
|
|
|
|
## What is being investigated
|
|
|
|
Eighty-nine modules sit outside the platform core. The question is which of them belong
|
|
together, and the method is evidence rather than intuition: **which modules actually change
|
|
together**, measured across the full history of the code repository.
|
|
|
|
## Why
|
|
|
|
The argument in ADR 0017 is that the catalogue's shape records what was installed rather than
|
|
what anything is for — that four modules constituting "how a node is reachable" have no
|
|
relationship the mesh can see, so a change to connectivity is made four times.
|
|
|
|
That argument is testable. If those modules genuinely change together, the grouping is
|
|
justified by more than tidiness. If they do not, the premise needs revising before a list is
|
|
drawn from it.
|
|
|
|
## What it touches
|
|
|
|
The catalogue's shape, the manifest, and — for one candidate grouping — the provisioning
|
|
reference itself, since a requirement names a provider **module**. Grouping providers would
|
|
change what a consumer names.
|
|
|
|
## Status
|
|
|
|
Measurement is done and is in [`analysis.md`](analysis.md). It **partly contradicts the
|
|
premise**, in a way that narrows the effort usefully:
|
|
|
|
- Non-platform modules overwhelmingly change **alone** — 10% of commits touch more than one,
|
|
and 50 of 89 never co-change with anything.
|
|
- Two clusters do exist. One of them, reachability, holds up as a domain.
|
|
- The other, the provisioned infrastructure providers, co-changes for a reason that argues
|
|
**against** grouping rather than for it.
|
|
|
|
The remaining work is the list itself, for the modules where grouping is justified, plus the
|
|
open questions below.
|
|
|
|
## What it became
|
|
|
|
*Closed 2026-08-28.* Three of the four questions are answered, and by records that did not cite
|
|
this effort — which is why it stayed open after being resolved.
|
|
|
|
**Whether provider modules group at all** — *no.*
|
|
[ADR 0044](../../02-DECISIONS/0044-a-module-declares-presence-instantiation-and-exclusion.md):
|
|
there is no `networking` thing to install, there are concrete modules named individually. Folders
|
|
assert relationships; edges record them. *Provider* stops being a category at the same time.
|
|
|
|
**Whether "group or leave" is even the right pair of options** — *it was not*, and that is the
|
|
useful finding. [ADR 0054](../../02-DECISIONS/0054-things-that-change-together-share-an-authority.md)
|
|
reframes it: things that change together share an **authority**, not a package. This effort's own
|
|
measurement is what that record rests on — reachability being the *only* place modules genuinely
|
|
co-change is why connectivity is a context and why nothing else needed one.
|
|
|
|
**What to do with the ~50 modules that co-change with nothing** — *nothing.* They are modules.
|
|
Grouping is a tag and a query over the graph, neither of which anybody keeps true by hand.
|
|
|
|
**What remains is a sequencing question, not a grouping one**, and it moves rather than closes:
|
|
*whether applications leave the monorepo before or after they group* is
|
|
[research 009](../009-migration/00-overview.md)'s, because it is about how to get from here to
|
|
there rather than about what the shape is.
|
|
|
|
## Open (superseded by the above) questions
|
|
|
|
| Question | Why it is open |
|
|
|---|---|
|
|
| Whether provider modules group at all, and if so what a consumer's requirement names instead of a module. | The provisioning reference is load-bearing; getting it wrong is expensive. Opinion and evidence in the analysis; not yet decided. |
|
|
| Whether applications group into domains now and leave the monorepo later as a unit, or leave first. | Decided in principle — group first, then split — but the migration order has real cost either way. |
|
|
| What to do with the ~50 modules that co-change with nothing. | The evidence gives no grouping signal for them at all. That may mean they are correctly sized already. |
|
|
| Whether "group or leave" is even the right pair of options. | [Research 006](../006-mesh-from-scratch/code-skeleton.md) finds a third fate — **absorbed into the node host**, ceasing to be a module at all — and argues it is the correct answer for the reachability cluster this effort measured. If so, the cluster this effort found is evidence for absorption rather than for grouping. |
|