Plumbdev08-1 · contribute a module
What whoever builds a module does, from a capability plumb lacks to a verb an adopter can install. Exits to dev00-1 · bring plumb to a project, whose later entry mounts it. The surfaces a module builds against are the core's documented, derived artifacts — the board, the series interface — and never the manifest, which stays the adapters' hub and the core's own to restructure.
dev08-1-1 build against the documented surfaces Proven
As whoever builds a module I want one documented contract to build against, so that adding my capability never means reading plumb's source or touching its core.
The tests that cite it (3)
tests/test_modules.py::test_a_surface_version_the_core_cannot_give_is_refused— passed, ungroundedtests/test_modules.py::test_the_core_publishes_a_version_for_every_surface_it_names— passed, ungroundedtests/test_modules.py::test_the_one_cli_grows_the_verb— passed, grounded
Requirements (5)
What the user needs
- dev08-1-1-ur1a module consumes the documented derived surfaces — the board, the series interface — each versioned, each refusing newer by name
- dev08-1-1-ur2a module declares the surfaces it speaks as a map, a version per surface, so one surface can be refused while another is accepted
- dev08-1-1-ur3a module that cannot reach what it needs is inert: its verbs report their own standing, and the tool stays whole
What the system does
- dev08-1-1-sr1the manifest stays the adapters' hub and the core's own to restructure; the module contract never names it
How well
- dev08-1-1-nfr1a module reads what was proven and never moves a status; only a run moves one
dev08-1-2 declare what it adds and what it writes Proven
As an adopter deciding what to install I want the module to say what verbs it adds and what it will write, so that trusting it is a decision about a list rather than a hope.
The tests that cite it (10)
tests/test_modules.py::test_a_module_may_not_mount_a_verb_the_core_owns— passed, ungroundedtests/test_modules.py::test_render_says_what_a_module_adds_and_what_it_reaches— passed, ungroundedtests/test_modules.py::test_a_write_that_is_not_a_footprint_entry_refuses_the_module— passed, ungroundedtests/test_modules.py::test_a_refused_module_contributes_nothing_to_the_footprint— passed, ungroundedtests/test_modules.py::test_a_modules_declared_writes_reach_the_footprint— passed, ungroundedtests/test_modules.py::test_the_command_prints_what_modules_declared— passed, groundedtests/test_modules.py::test_a_name_two_modules_claim_mounts_for_neither— passed, ungroundedtests/test_modules.py::test_an_uncontested_verb_is_untouched_by_somebody_elses_collision— passed, ungroundedtests/test_modules.py::test_the_listing_is_what_the_tool_mounted— passed, groundedtests/test_modules.py::test_one_distribution_found_twice_is_not_two_modules— passed, ungrounded
Requirements (10)
What the user needs
- dev08-1-2-ur1the verbs it mounts are named in the declaration, and none is a verb the core keeps; a name the core is giving up is taken over only as dev08-1-5 describes
- dev08-1-2-ur2every place the module writes is a declared footprint entry with a disposition, so migration, removal, and whatever backup the adopter runs stay honest about what modules added; a secret the module keeps is its own footprint entry, with the disposition carries a credential, and never sits in the project's declaration
- dev08-1-2-ur3the module names itself and its version, out of its own artifact
- dev08-1-2-ur4the declaration says whether the module reaches the network, beside the verbs and writes it names — together, what dev00-1-5-nfr1's trust decision is made on
- dev08-1-2-ur5a verb name claimed by more than one module mounts for none of them, and every claimant is named
What the system does
- dev08-1-2-sr1a module that needs configuration reads its own named table and never another's; the core's keys are read-only to it
- dev08-1-2-sr2every declaration is held against the others before any of them is bound, so a contested name is a refusal the adopter reads; the tool answers for every verb that is not contested
- dev08-1-2-sr3what the tool lists as mounted is exactly what it mounted
How well
- dev08-1-2-nfr1which module answers a verb is never decided by an order the adopter did not choose and cannot see
Still open
- dev08-1-2-u1how an adopter resolves a contested name is undecided; nothing here lets them choose one, so the remedy is to uninstall the other
dev08-1-3 cite it under its own namespace Nothing holds it
As a module author who keeps a spec I want my subjects on the same board as everything else, so that my module's claims are proven the way the core's are.
Requirements (2)
What the user needs
- dev08-1-3-ur1the module's spec lives in its own namespace, and its citations coexist on one board with every other spec in the repository
- dev08-1-3-ur2keeping a spec is the author's choice; nothing refuses a module that keeps none
dev08-1-4 ship it as an installable artifact Proven
As an adopter I want a module installed by the same gesture as any package, so that adding a capability never means reading a contributor's repository.
The tests that cite it (3)
tests/test_modules.py::test_a_mounted_group_reaches_its_callable_through_the_parser— passed, ungroundedtests/test_modules.py::test_the_one_cli_grows_the_verb— passed, groundedtests/test_modules.py::test_a_module_from_outside_this_tree_is_discovered— passed, ungrounded
Requirements (2)
What the user needs
- dev08-1-4-ur1the artifact declares its mount under the name its package registers, which is what an install reads to mount it (dev00-1-5-sr1)
- dev08-1-4-ur2the artifact carries what its verbs need; an adopter obtains nothing separately
dev08-1-5 take over a name the core is giving up Proven
As an adopter I want a verb I already use to keep working across the release that moves it out of the core, so that where the capability is built is not a thing I have to notice.
The tests that cite it (3)
tests/test_modules.py::test_the_core_has_given_the_name_up— passed, ungroundedtests/test_modules.py::test_a_module_may_now_take_the_name— passed, groundedtests/test_modules.py::test_what_the_module_builds_on_did_not_leave_with_the_capability— passed, ungrounded
Requirements (9)
What the user needs
- dev08-1-5-ur1the core dropping the name and the module mounting it are one release, so no adopter meets a version with two of that verb or none
- dev08-1-5-ur2an artifact that carries the module before the name is free does not declare its mount until the release that frees it
- dev08-1-5-ur3what the verb does is the module's from the moment it mounts, and the core keeps no copy against which the module could be said to be wrong
- dev08-1-5-ur4what the core wrote under that name stays exactly where it is and the module reads it there; the release that gives the name up moves nothing, because a conversion run by the half that is leaving is one nobody can run a second time
What the system does
- dev08-1-5-sr1the two sides are cut together and neither is released on the strength of the other being ready
- dev08-1-5-sr2what leaves is what implemented the capability, never what the module builds on: a published surface stays published, because a module cannot speak a version of something the core stopped having, and a holder somebody runs themselves must not come to depend on the software of whoever answers a different capability
How well
- dev08-1-5-nfr1a verb is never served by the core and a module at once; a core that ships a verb claims the capability
- dev08-1-5-nfr2the moment a capability leaves is the cheapest it will ever be to leave, because the population using it only grows
Still open
- dev08-1-5-u1what an adopter who upgrades the core and not the module meets is undecided, and so is whether anybody is told the two have drifted