What
Two gaps in the bregctl explain JSON Schema contract under products/breg/contracts/explain/, gated by crates/registry-bregctl/tests/explain_contract.rs.
1. ActionsExplanation does not tie backend fields to handler.kind
Only the common handler fields are required. There is no oneOf or conditional binding the backend-specific members to the discriminator, so the schema accepts:
kind: "rhai" without scriptSha256, rhaiVersion, or limitskind: "wasm" without moduleSha256 or compatibility
Those fields are pinned precisely because they are the ones a consumer verifies a handler against. Dropping one from explain_actions today still passes the gate, which is the one thing the gate exists to catch. Model the two handler variants separately and require each variant's own members.
2. Four branches are pinned from source and never instantiated
explain_contract.rs replays the real binary over 11 fixtures and 2 scenarios. None of them reaches:
- a WASM action handler (
handler.kind == "wasm") — already recorded under "Unexercised branches" in the contract README
- the
"clear" field-mutation kind in ActionsExplanation and ChangeRequestsExplanation — also already recorded there
- a project omitting
package or manifestProjection, so explain_model serializes them as null
- an authority inventory failure, so
explain_access carries a non-null claimContractError
The last two were widened to accept null and the snake_case error vocabulary in PR #1271 after the review connector caught that the schemas refused valid payloads. The schemas are now correct, but nothing replays either branch, so the same class of defect can recur unseen. A conflicting-claim scenario (ConflictingClaimExpectation is the reachable one) and a fixture without production metadata would close both.
Item 1 is the merge-relevant half: it is a gate that does not gate. Item 2 is coverage.
Provenance
Raised by the review connector on PR #1271. Item 1 is verbatim; item 2 extends the README's existing unexercised-branch note with the two branches found while fixing the schemas.
What
Two gaps in the
bregctl explainJSON Schema contract underproducts/breg/contracts/explain/, gated bycrates/registry-bregctl/tests/explain_contract.rs.1.
ActionsExplanationdoes not tie backend fields tohandler.kindOnly the common handler fields are required. There is no
oneOfor conditional binding the backend-specific members to the discriminator, so the schema accepts:kind: "rhai"withoutscriptSha256,rhaiVersion, orlimitskind: "wasm"withoutmoduleSha256orcompatibilityThose fields are pinned precisely because they are the ones a consumer verifies a handler against. Dropping one from
explain_actionstoday still passes the gate, which is the one thing the gate exists to catch. Model the two handler variants separately and require each variant's own members.2. Four branches are pinned from source and never instantiated
explain_contract.rsreplays the real binary over 11 fixtures and 2 scenarios. None of them reaches:handler.kind == "wasm") — already recorded under "Unexercised branches" in the contract README"clear"field-mutation kind inActionsExplanationandChangeRequestsExplanation— also already recorded therepackageormanifestProjection, soexplain_modelserializes them asnullexplain_accesscarries a non-nullclaimContractErrorThe last two were widened to accept
nulland the snake_case error vocabulary in PR #1271 after the review connector caught that the schemas refused valid payloads. The schemas are now correct, but nothing replays either branch, so the same class of defect can recur unseen. A conflicting-claim scenario (ConflictingClaimExpectationis the reachable one) and a fixture without production metadata would close both.Item 1 is the merge-relevant half: it is a gate that does not gate. Item 2 is coverage.
Provenance
Raised by the review connector on PR #1271. Item 1 is verbatim; item 2 extends the README's existing unexercised-branch note with the two branches found while fixing the schemas.