Plumbdev07-6-2-1 · send what a run produced
What a developer does to get what their run produced somewhere they chose — a history to a holder their team runs, a record to a service they chose. The holder this reaches is dev07-6-2-2 · hold a series; what is sent to it is appended in dev07-6 · append the run to the series. This flow is the part between having something and it being held elsewhere, and it is the same part whichever capability is doing the sending.
dev07-6-2-1-1 name a destination for one capability Proven
As a developer I want to say where one kind of thing goes and who I am there, so that sending one kind somewhere decides nothing about where the others go.
The tests that cite it (8)
tests/test_transport.py::test_two_capabilities_reach_two_different_hosts— passed, ungroundedtests/test_transport.py::test_the_machine_wide_pair_still_serves_every_capability— passed, ungroundedtests/test_transport.py::test_a_capabilitys_own_pair_is_preferred_over_the_machines— passed, ungroundedtests/test_transport.py::test_an_enrolment_file_still_names_a_destination_for_everything— passed, ungroundedtests/test_transport.py::test_a_destination_says_nothing_about_a_relationship— passed, ungroundedtests/test_transport.py::test_a_capability_name_becomes_the_variable_a_runner_sets— passed, ungroundedtests/test_transport.py::test_a_series_is_pushed_to_the_address_its_own_capability_names— passed, groundedtests/test_transport.py::test_an_address_in_the_project_file_is_refused_by_name— passed, grounded
Requirements (9)
What the user needs
- dev07-6-2-1-1-ur1a destination is named for one capability; a run that sends several kinds of thing has one for each
- dev07-6-2-1-1-ur2naming one is the whole of enabling it, and there is no second setting that turns sending on
- dev07-6-2-1-1-ur3every field of a destination can be given in the environment, so a run can name a destination without writing a file
What the system does
- dev07-6-2-1-1-sr1a destination carries where to send, the credential to send with, and which store that credential owns
- dev07-6-2-1-1-sr2a destination says nothing about a relationship with whoever runs it; who the sender is to a service is the service's to decide from the credential it authenticated
- dev07-6-2-1-1-sr3two capabilities naming the same address are two destinations that happen to agree, and neither reads the other's
- dev07-6-2-1-1-sr4an address written in a project's configuration is never read and never silently ignored: the run names it and carries on, and a destination is named in the environment of the run
How well
- dev07-6-2-1-1-nfr1a credential in a file in a working tree is collectable by an artifact upload or a cache step written for something else, so the environment is how a run is given one
Still open
- dev07-6-2-1-1-u1whether a project's own configuration should be able to name a destination is undecided; a repository that pushes to its team's holder and one that pushes nowhere can share one machine and one environment
dev07-6-2-1-2 is a destination named for this one? Unproven
As a developer I want nothing to leave this machine unless I said where it goes, so that installing the tool is not a decision about my data.
the citations that passed reached nothing wired — what ran was the implementation on its own, which is not evidence the story holds where it is used
The tests that cite it (1)
tests/test_transport.py::test_no_destination_is_the_ordinary_state_and_never_an_error— passed, ungrounded
Requirements (6)
What the user needs
- dev07-6-2-1-2-ur1with no destination named for a capability, what that capability produced stays on this machine and the run says so
- dev07-6-2-1-2-ur2a destination named for one capability never addresses another's
What the system does
- dev07-6-2-1-2-sr1the absence of a destination is the ordinary state and is never an error
- dev07-6-2-1-2-sr2what is addressed is what has not been acknowledged, and never what a run happened to produce most recently
How well
- dev07-6-2-1-2-nfr1nothing leaves without being told where is a guarantee only while absence is the default; a default address would make it a promise about somebody's configuration instead
- dev07-6-2-1-2-nfr2a run that transmits silently and a run that transmits nothing look identical from the outside, so the one that transmitted nothing is the one that has to say so
dev07-6-2-1-3 hand it over Proven
As a developer I want what I send to go with the credential its destination names, so that where something goes and what it is sent under are decided in one place.
The tests that cite it (1)
tests/test_series.py::test_a_push_goes_with_the_credential_its_destination_names— passed, grounded
Requirements (1)
What the user needs
- dev07-6-2-1-3-ur1what is handed over is presented with the credential of the destination it is addressed to
dev07-6-2-1-4 record what was acknowledged Proven
As a developer I want a retry to send what did not arrive and nothing else, so that a service that was down for an hour does not become a service holding six copies of everything.
The tests that cite it (4)
tests/test_capture.py::test_an_unreachable_holder_is_named_as_the_destination_it_is— passed, groundedtests/test_transport.py::test_an_unreachable_push_names_the_address_and_the_variables_that_named_it— passed, groundedtests/test_transport.py::test_an_unreachable_push_names_the_enrolment_file_it_read— passed, groundedtests/test_transport.py::test_an_unreachable_pull_names_the_address_and_the_machine_wide_pair— passed, grounded
Requirements (9)
What the user needs
- dev07-6-2-1-4-ur1what the receiver acknowledged is recorded against what was sent, so a retry carries only what is outstanding
- dev07-6-2-1-4-ur2a receiver that has stopped answering is distinguishable from having nothing to send
- dev07-6-2-1-4-ur3a destination that cannot be reached, or refuses, leaves what is outstanding where it is and never fails the run that produced it — a board is complete without the network
- dev07-6-2-1-4-ur4a destination that cannot be reached is named in what the run says: the address it was sending to and where that address was named, so a wrong address reads differently from a down one
What the system does
- dev07-6-2-1-4-sr1an acknowledgement is keyed on something the receiver honours; where a receiver assigns its own name for what it took, that name is what is recorded
- dev07-6-2-1-4-sr2a second arrival of one thing is the same thing sent twice and is not an error
How well
- dev07-6-2-1-4-nfr1an acknowledgement keyed on something the receiver does not honour leaves an outbox that never clears and a sender that re-sends what already arrived, and the duplicates land on whoever runs the destination
- dev07-6-2-1-4-nfr2an outbox that never empties reads as a service that has stopped answering, so the reader draws the wrong conclusion about somebody else's system
Still open
- dev07-6-2-1-4-u1whether an outstanding item should expire is undecided; something unacknowledged for a month is either a receiver that moved or a sender nobody will read again