docs: record consumes/emits emptiness is expected ECCA-nascency (decision 65, closes #305)

docs/decision-log.md

@@ -384,4 +384,11 @@ Also updated `CONTRIBUTING.md`'s existing entry-62 guidance to state the new saf
 
 **Verified, not assumed**: every new/changed check has a corresponding unit test in `scripts/ci/tests/test_capability_validation.py` (mocked `cargo llvm-cov` output for the threshold logic) plus a real, unmocked end-to-end smoke test against an actual crate (`validate-luhn`, copied to a scratch directory) confirming the full plumbing -- both the missing-crate-directory failure path and the passing path -- works against real `cargo llvm-cov` output, not just mocks. `python3 -m unittest scripts/ci/tests/test_capability_validation.py` (65 tests) and a whole-tree `capability_validation.py` run both pass clean on this branch.
 
+65. **consumes/emits contract fields' near-total emptiness is expected ECCA-nascency, not a data-quality gap; no backfill, no CI enforcement change (2026-08-22, closes registry#305)**: external report (registry#305) found 114/116 published `contract.json` versions have `"emits": []` and all 116 have `"consumes": []`, with the sole exception being `core.transition-action-status`'s two newest versions declaring `emits: [{event_id: "core.action-item.status-transitioned", ...}]`. The report asked, correctly, whether this is intended, legacy, or a gap worth backfilling/enforcing.
+
+- **Traced, not guessed**: `crates/traverse-registry`'s `CapabilityContract.emits`/`consumes` (`graph.rs`) are typed `Vec<EventReference>` -- real, load-bearing infrastructure the crate's own composition/dependency graph reads, not a vestigial or decorative field. But decision 56 (`#168`, ECCA event-product publish path) already answered exactly this question when it shipped: "does not rewrite published capability `emits` arrays in place (immutable); inventory marks `core.transition-action-status` as `governed-event-declared` pointing at the new event." The real, current mechanism for declaring producer/consumer relationships is the separate `events/<namespace>/<id>/<version>/product.json` ECCA descriptor tree (spec 016) plus the FR-020 capability inventory -- not the contract-level `emits`/`consumes` arrays, which decision 56 deliberately chose not to backfill for already-published contracts.
+- **Why the numbers are exactly what they should be, not evidence of neglect**: the whole registry has published exactly one governed event product to date (`core.action-item.status-transitioned@1.0.0`, decision 56) and zero capabilities that declare consuming it. Two capability versions emitting it and zero consuming it is the *correct* current state of a one-event catalog, not 114 forgotten fields -- there was never a second event or a consumer to declare.
+- **Decided (resolves from existing decision-log + spec evidence alone, no new owner sign-off needed per this repo's working-style guidance on resolvable ambiguity)**: no backfill of `emits`/`consumes` on existing contracts (would misrepresent capabilities as declaring events that don't exist), no new CI enforcement requiring these fields at publish time (would conflate "declares no governed event" -- true for nearly every capability today -- with "author forgot"). Going forward, publishers with a real governed event to declare should use the ECCA `events/` pipeline (spec 016), which already has CI validation and index/catalog wiring; the bare contract-level fields stay available for `traverse-contracts`' own schema compatibility but are not this repo's enforcement surface.
+- **Execution boundary**: this entry only. No code, schema, or CI change -- the fields, their emptiness, and the lack of enforcement are all already correct as-is.
+
 **Execution boundary**: the spec, the CI check + its tests, the CI workflow tooling change, the `CONTRIBUTING.md` section, this entry, and the two tracking issues (#301, #302) are the full scope of this entry. Separately in this same session but tracked under their own PRs: the corruption fix (`#299`) and the two-crate backfill (`#300`) the audit above surfaced. Not attempted: backfilling any of the 15 or 18 tracked capabilities (registry#301/#302's own call, paced as ordinary backlog / a cross-team ask respectively).