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.
73 lines
4.4 KiB
Markdown
73 lines
4.4 KiB
Markdown
---
|
|
status: active
|
|
initiated: 2026-08-23
|
|
touches:
|
|
- 03-DESIGN/00-as-is/04-delivery.md
|
|
- 02-DECISIONS/0014-build-publish-and-deploy-are-three-silos.md
|
|
- 02-DECISIONS/0013-an-artifact-is-build-output.md
|
|
- 01-RESEARCH/006-mesh-from-scratch/code-skeleton.md
|
|
became: []
|
|
---
|
|
|
|
# 008 — The coordinator: a change checked in becomes a deployed state
|
|
|
|
## What is being investigated
|
|
|
|
The mesh's own continuous delivery: a change is committed, and the mesh ends up in the state
|
|
that change describes — across every node the change touches, with a verdict that says whether
|
|
it worked.
|
|
|
|
The coordinator is what orchestrates that, and it is the mesh's most consequential machinery:
|
|
everything reaches every node through it.
|
|
|
|
## Why now
|
|
|
|
The as-is record ([`03-DESIGN/00-as-is/04-delivery.md`](../../03-DESIGN/00-as-is/04-delivery.md))
|
|
names problems that are structural rather than incidental:
|
|
|
|
- **A green pipeline proves transport, not effect.** The stages report that a message was
|
|
dispatched and accepted, which is not the same as the thing running, correct, or present.
|
|
This is the mesh's single most consistent failure shape.
|
|
- **Detection is the most fragile input.** A merge that creates no pipeline, with nothing saying
|
|
so, is the characteristic bad outcome — and it has happened for reasons unrelated to the
|
|
change.
|
|
- **The fan-out point is asymmetric.** The build node has already passed two silos when work
|
|
fans out, and code that knew only about the first parked it forever while every other node
|
|
deployed cleanly.
|
|
- **There is no end-to-end coverage.** The harness has not built since 2026-06-04
|
|
([`04-ISSUES/005`](../../04-ISSUES/005-pipeline-test-harness-unbuildable/00-report.md)).
|
|
|
|
Research 006 adds a requirement the current design does not have: the coordinator must work
|
|
**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 |
|
|
|---|---|
|
|
| What is a **deployed state**, and how does the mesh know it is in one? | Everything follows from this. If a stage reports transport, "deployed" is a claim nobody checked. A desired-state model with reconciliation gives a different answer from a job-completion model. |
|
|
| Does the coordinator dispatch **stages**, or converge nodes on a **declaration**? | The current model is a state machine over stages. The alternative is that a node is told what should be true and reports what is. The second makes drift visible; the first cannot see it. |
|
|
| How does a change **become** a pipeline, reliably? | Detection has failed for reasons unrelated to the change, silently. |
|
|
| What produces a **verdict**, and what is it a verdict about? | Ties to the lab ([ADR 0016](../../02-DECISIONS/0016-a-lab-node-is-a-virtual-machine.md)) and to a module carrying its own assertions. |
|
|
| How does delivery work **before self-hosting**, and across the transition? | From research 006: source and artifacts start external and are re-bound to internal providers. The coordinator has to be indifferent to which. |
|
|
| Does the **three-silo** split survive the artifact/part split? | [ADR 0014](../../02-DECISIONS/0014-build-publish-and-deploy-are-three-silos.md) is cardinality-driven, and research 006 renames the thing the cardinality is about. |
|