Files
hq/04-ISSUES/005-pipeline-test-harness-unbuildable/00-report.md
T
jschoubben 333356cff3 Order the records the way the system is learned
Jochen asked whether the order made sense. It did not -- it followed when
things happened to be decided, which after consolidation is fictional anyway
since record 5 alone folds decisions taken across a week.

Concretely wrong before: the domain statement sat at 8, after five engineering
rules; the constitution was scattered across 5, 12 and 17; the tiers landed at
15, 16, 21 and 22 with process records in between.

Now it walks: what the mesh is (1-3), its tiers from the bottom up (4-8), what
runs on them and how it gets there (9-10), how it is built (11-16), how it is
checked (17-18), how we work (19-23).

Two things made this safe rather than free. It is a permutation, not a
compaction, so the renames go through temporary names -- otherwise two files
want one slot and one is lost. And the reference rewrite is a single
simultaneous pass, because almost every number moved into a slot another number
was vacating; replacing one at a time would have cascaded and pointed things at
the wrong record while still resolving.

Verified: 284 [ADR NNNN](path) links across the repository, all with matching
text and target.

The ordering principle is now stated in 19 rather than left implicit -- the
repository already said "the numbering is the flow" about its folders, and
there was no reason for the records to be the exception.
2026-08-28 23:30:42 +02:00

1.9 KiB

status, opened, located-in, fixed-by, amended-design
status opened located-in fixed-by amended-design
open 2026-08-22
hal

005 — The end-to-end pipeline harness has not built since the workspace was removed

Symptom

The repository's end-to-end pipeline test harness depends on a workspace that no longer exists. It has not been buildable since 2026-06-04. Nothing runs it, and nothing reports that nothing runs it.

Why this matters

The delivery pipeline is the mesh's most consequential machinery — every module reaches every node through it — and its only end-to-end coverage has been silently dead for over two and a half months.

That interval is not incidental. Several of the pipeline's most expensive defects landed inside it: packaging that was never actually split from build, migrations and provisioning scripts reading a source layout that no longer ships, selection files never packaged at all. Whether this harness would have caught any of them is unknown — which is itself the point. The coverage was assumed, not checked.

Evidence

  • The workspace was removed by pull request #240 on 2026-06-04 (ADR 0014).
  • The harness has not built since that date.
  • Recorded in the knowledge base as a standing entry, not as a fixed incident.

Relationship to the lab

03-DESIGN/01-to-be/01-end-to-end-testing.md designs end-to-end testing on a lab mesh, which would replace this harness rather than repair it. That is a reason to decide its fate deliberately, not a reason to leave it broken and unmentioned: until the lab exists, this is the coverage the pipeline is presumed to have.

Open questions

  • Repair, or retire in favour of the lab? Leaving it in the repository unbuilt is the one option that keeps the false impression of coverage.
  • Was anything relying on it, or had it already stopped running before the workspace removal?