Some checks failed
ci / build (push) Has been cancelled
Completes FLUID-WP-0007. The seven minimal-conformance requirements and the mechanically checkable architectural invariants are asserted as tests rather than claimed in a README, because a conformance claim nobody re-checks is one that quietly stops being true. Only the checkable subset of the invariants is asserted; pretending a test can settle the rest would be worse than leaving them to review. TestFirstVerticalSlice runs all eleven steps of Blueprint 50 with no human steps: two revisions, explicit routing, telemetry, a cohort dimension, detected pressure, a hypothesis, a candidate, a 90/10 experiment, fitness comparison, promotion, and a complete audit trail. Requests per completed task fall from 5.65 to 1.00 against a 1.20 target. A companion test runs the loop twice and requires the same verdict, since a loop whose conclusion depended on run order would be measuring the harness rather than the interface. The failure-containment matrix covers Blueprint 34 directly: the data plane keeps serving with the evidence store closed, with telemetry wedged against a sink that never returns, after a failed build, after an experiment rollback, and with the adaptive concurrency limit saturated. Fixes a real bug the suite exposed. Drain closed the emitter outright, so every request after the first flush emitted into a dead emitter and was silently lost -- the kind of fault that makes a later measurement quietly wrong rather than loudly broken. Emitter.Flush now waits for delivery without stopping it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014KmVxhJ35tCo7rE7UnLwWu Assistant: claude-code Assistant-Model: opus Assistant-Process: 1116572@bnt-lap001 Assistant-Session: 8ba9bb93-a72a-4883-b189-2499cce5c400
21 lines
978 B
Markdown
21 lines
978 B
Markdown
# echo-interface
|
||
|
||
The smallest honest reproduction of the `ArchitectureBlueprint.md` §33 worked
|
||
example, used as the conformance fixture.
|
||
|
||
Two revisions of one interface over the same backend data:
|
||
|
||
| Revision | Shape | Requests per completed task |
|
||
|---|---|---|
|
||
| **R-1** | `GET /v1/entries` only — consumers list everything and filter locally | ~3 |
|
||
| **R-2** | adds `GET /v1/entries/latest` — the concept consumers actually wanted | 1 |
|
||
|
||
R-1 is not a strawman. It is the interface a careful designer produces before
|
||
they have seen how it is used: a clean collection resource with no special
|
||
cases. The pressure it generates is the point — consumers repeatedly fetching
|
||
a collection to discard all but one item is the evidence that "latest" is a
|
||
first-class concept the contract failed to name.
|
||
|
||
The fixture has no external dependencies and runs in CI. It exists so the
|
||
revision–experiment–fitness loop is proven mechanically before a real workload
|
||
depends on it.
|