Rendered from docs/obligations/0040-composition-between-two-library-entries-has-no-add-only-form.md in the Headwater corpus. Every document on this half of the site is typed by the taxonomy the descriptor names: corpus.json.

Composition between two library entries has no add-only form

Context

The decision-record entry is the second entry in the library, and it met this three times in one bundle. Its obligation_record kind serves the obligation purpose, and the design-spec entry declares that purpose. The admission criteria refuse a second declaration at one address, and the resolver refuses it too, because both operations write the same leaves.

The wall is narrower than this record first stated, and a measurement narrowed it. The diataxis entry measured the relevance canon at line 130 of its doctrine. The resolver reads require and optional together when it decides the facets of a kind. An optional listing therefore satisfies the canon. A facet-only entry is admissible without any reach into another entry's kinds.<k>.facets.require. #6 stated that such an entry had to reach that address, and it does not. What stands is the operation itself: a required facet on a kind that another entry declared still has no add-only form. What falls is the claim that every facet-only entry needs the operation.

Obligation

The remedies are a rename, which puts two names on one reader intent, or a dependency. The entry declares requires: [design-spec] for one line, and a team that keeps only decision records inherits six kinds of a tradition it does not use.

The second instance refused the dependency rather than paid it. The brd-prd entry wants an edge from prd to functional_spec. The natural spelling adds prd to the relations.realizes endpoint list that the standards-spec entry declared, and that is not an add. The alternative is a new relation and requires: [standards-spec]. That dependency buys three kinds, a purpose, a facet and two relations. It also buys two shelves, three identifier schemes and three obligations, for one edge. The entry refused it, so the pipeline that both entries describe is declared by neither of them. The third finding at line 167 holds the argument.

The two other cases are lists rather than addresses. An endpoint list of concrete kinds closes a relation to a later kind, so no kind of the second entry cites evidence at all. A kind's list of required facets closes the same way.

Discharge

The root is one. Vocabulary that more than one tradition needs cannot live in an entry, because the first entry to claim an address owns it.

The owner ruled the form on 2026-09-22. HW-DR-0095 records the ruling. One entry may address keys of an entry that it names as a dependency in requires, with add_to and add. No general operation that extends or appends is added. Spec 2 states the narrowed confluence claim.

The resolver change landed with #1246, and this record is discharged. The resolver reads requires from each source that a selection chose as a bundle. Its confluence check admits an add or an add_to from the dependent entry into a key of an entry that it names directly. It still refuses the same write from an entry that names no dependency, or that reaches the other entry only through a third. A selection that lacks a named entry is refused before the merge where the dependent writes into it. The refusal names both entries and the address. A cycle in requires is refused, and the refusal names each entry in it. Six cases under engine/crates/resolve/fixtures/cases/ hold these behaviors. They are dependent-add-to, dependent-add-to-without-requires, missing-dependency-add-to, missing-dependency-add, requires-cycle and transitive-requires-grants-no-write.

The library entries that met this wall have not used the form yet. The diataxis and brd-prd findings that cite this record can now build against it, and a release of the package carries that work.