Plumbdev07 · run plumb — the proving pipeline
A sub-flow of A developer's workflow. Entered from dev06 · do the work, carrying the configuration, the annotations and the working tree, and entered again from dev08 · update the plumb configuration once the configuration is corrected. Exits to the developer's judgement — is the proof what the story needs? — carrying a board, the manifest and, where a series is kept, the run in its history.
dev07-1 run the suite under observation Nothing holds it
As a developer whose test proves a behaviour I want the run to record what each test drove, so that a passing test is evidence of doneness.
Requirements (3)
- dev07-1-sr1observing is the adapter's, in the language's own tooling
- dev07-1-sr2the adapter is the one the project declares, and the core never learns which; an adapter that is not known fails the launch, never a verdict
- dev07-1-sr3the project's declarations are resolved once, and whichever adapter runs is handed the same resolved answers — answers, never questions, because an adapter may run apart from the core
dev07-2 check the tests bite Nothing holds it
As a developer whose suite is green I want to know which of my tests run the code without checking it, so that passing and checking stop being the same word.
Requirements (1)
- dev07-2-sr1a fixed, closed set of mutations is applied to the language's own parse tree, and nothing outside it
dev07-3 collect what the run did Nothing holds it
As a developer I want the record of the run to carry facts and never verdicts, so that the claims can be re-derived and checked rather than taken on trust.
Requirements (1)
- dev07-3-ur1one record per citing test
dev07-4 decide whether it is proven Nothing holds it
As a developer I want done derived from the recorded facts — the test ran, passed, and matched the kind of claim the story makes — so that I can rely on it.
Requirements (1)
- dev07-4-sr1the core reads the manifest schema versions it knows and refuses a newer one by name rather than guessing
dev07-5 report it Nothing holds it
As a developer about to act on the result I want one board naming, for each story, whether it is proven, the rungs its tests reached and what its checks could not settle, so that what I do next comes from what was proven.
Requirements (1)
- dev07-5-sr1the board has one documented, versioned machine-readable format, and every other rendering of it is a view of that format
dev07-6 append the run to the series Nothing holds it
As a developer asking when this broke I want every run to leave its mark in a history kept in my own tree, so that the history shows test status over the time dimension.
Requirements (2)
- dev07-6-nfr1appending locally and transmitting to its holder stay separate
- dev07-6-nfr2a project that declares no series skips this step, and nothing downstream may come to depend on it