[antoinetoussaint-byte]

What

The three findings from the review of #42, which is merged. Two are fixes; the third is an accepted limit written down.

1. One statement, stated once — inside a fragment too

The one-source rule was enforced per source, so one fragment could state the same (organization, role, kind) twice and silently union {id: seeded} with {all: true}: the exact widening the rule exists to stop, inside one file, where whoever reads the first statement has no reason to look further down. Decode now refuses a duplicate grant, installation or stand-in module within one document, naming it — which also holds the merged document to the rule, not just its inputs. ErrConflict now reads "one statement, stated twice" and covers both directions.

The grants of a kind are a union, which is why one file stating a kind twice widens it exactly as two files would. A role stating two different kinds, and two roles stating one kind, stay valid.

2. ApplyComposition applied what can fail last

It wrote the role grants, then loaded the installations and stand-in modules — so a document that failed while being applied had already widened the fixture's roles, against that same function's "nothing is applied unless the whole document is valid". The two applying steps are now ordered: LoadFixture (the one that can fail) first, the role writes (which cannot) after. LoadFixture's own internal steps are not individually reversible; the comment says so rather than implying otherwise.

The illustration matters, and my first one was wrong. A refused installation is precisely the case that was already safe: an owner the fixture does not define is caught by checkComposedSetup, pure validation that runs before either applying step in both orderings. My first test used that scenario, so it could not fail — reverting only the ordering left it green, and the whole pkg/business/state suite with it. A guard about a name.

The reachable bug needs a document that gets past validation and fails inside LoadFixture: a stand-in module named after a fixture person. checkComposedSetup only checks its kinds and logs a line for it; the core refuses it when the manifest is applied (principal %q names a person; a module's principal is its own). TestADocumentRefusedWhileApplyingLeavesTheRolesAlone uses that, and I diagnosed it by putting the bug back: against the pre-fix ordering it fails with the editor holding ledger.entry approve from a refused document; with the fix the role is untouched.

3. Ownership is not enforced — an accepted limit, now written down

A statement is keyed by organisation, role and kind alone, never by which module ships the fragment, so a module's fragment can grant at another module's kinds — and a composition's fragment does, by design: the robin playground grants its viewer documents.collection on the collection its own seed writes, a kind the document store owns. "One definition per module" is therefore a convention about where a grant is written, enforced only in that two fragments cannot state the same grant; it is not a check that a module grants on its own kinds.

Both READMEs now say this plainly, with why nothing is lost: these fragments reach the development fixture alone, never a host, and a grant at a kind no composed module serves resolves to nothing (the authority intersects every capability with the delivered manifests), so the failure mode is a refusal, not a widening. Enforcing ownership would need each kind's owning module named in the document, which v1 does not carry — a v2 question, not a silent gap.

Evidence

• libraries/fixture-composition/go: go vet + go test -race green. New test covers the widening pair, two role entries of one kind, a duplicate installation, a duplicate stand-in — each refused as ErrConflict by Decode and named against its fragment by Merge — and the three shapes that are not duplicates.
• modules/authority/services/local/code: go vet ./... + go test -race ./... green, with a new regression that fails against the pre-fix ordering (verified by reverting the production change) and passes with it.
• tools/noproxygate and tools/packagegate green. gofmt clean (it also fixes an import ordering fixture-composition: one fragment per module, merged by the run #42 left in state.go).

A test changed deliberately

TestCompositionRefusesByName prepends a valid entry to every roles case so a refused later entry cannot leave it applied. That entry used the cases' own kind, so under the new rule every case became a duplicate and stopped testing what it names. Its kind moves to ledger.audit, keeping the test's intent; the comment says why. No case was removed and no refusal was weakened.

Fix or hack

Both changes are fixes at the owner. The third is neither — it is a limit named in the docs instead of a check that would need a schema version.

🤖 Generated with Claude Code