From 9dc57b4712bc183c382ecc48e85d03e065ffbed2 Mon Sep 17 00:00:00 2001 From: jochen Date: Fri, 28 Aug 2026 01:40:02 +0200 Subject: [PATCH] Graduate 005; record what 0058 answered in 008 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. --- .../005-domain-grouping/00-overview.md | 32 +++++++++++++++++-- .../008-delivery-coordinator/00-overview.md | 19 +++++++++++ 2 files changed, 48 insertions(+), 3 deletions(-) diff --git a/01-RESEARCH/005-domain-grouping/00-overview.md b/01-RESEARCH/005-domain-grouping/00-overview.md index 7a12a48..665ca19 100644 --- a/01-RESEARCH/005-domain-grouping/00-overview.md +++ b/01-RESEARCH/005-domain-grouping/00-overview.md @@ -1,11 +1,13 @@ --- -status: active +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: [] +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 @@ -51,7 +53,31 @@ premise**, in a way that narrows the effort usefully: The remaining work is the list itself, for the modules where grouping is justified, plus the open questions below. -## Open questions +## 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 | |---|---| diff --git a/01-RESEARCH/008-delivery-coordinator/00-overview.md b/01-RESEARCH/008-delivery-coordinator/00-overview.md index 9bc14a0..d862506 100644 --- a/01-RESEARCH/008-delivery-coordinator/00-overview.md +++ b/01-RESEARCH/008-delivery-coordinator/00-overview.md @@ -41,6 +41,25 @@ Research 006 adds a requirement the current design does not have: the coordinato **before the mesh is self-hosting**, when source and artifacts come from outside, and keep working across the transition to self-hosted providers. +## Answered since + +**Does the coordinator dispatch stages, or converge nodes on a declaration?** — *Converge.* +[ADR 0058](../../02-DECISIONS/0058-delivery-ends-in-a-declaration.md): a pipeline ends when the +declaration is updated, and deploy stops being once-per-node. The host applies it and reads back, +so the reporter is the applier — which is what this effort was circling when it asked what a +*deployed state* is. + +**Does the three-silo split survive?** — *Yes, with the third redefined.* Build and publish are +unchanged; deploy becomes one write rather than a fan-out. + +**What is a deployed state?** — *Partly.* "The declaration is updated, and here is which nodes +have applied it" is the answer 0058 gives, and it makes *outstanding* a first-class result rather +than a stall. What it does not answer is what a node reports and how, which waits on the link. + +**Explicitly NOT answered, and 0058 says so:** *how a change becomes a pipeline, reliably.* +Detection remains the fragile input — *a merge that created no pipeline, and nothing said so* is +upstream of everything 0058 changed and is untouched by it. + ## The questions | Question | Why it matters |