67%

Consumer-SSOT Registry — per-consumer pool subset

Goal

  • Complete the registry so each entry records WHICH shared pools it reads, not a uniform assumption.
  • Record the one nuance: ori_eval reads CanExpr + DecisionTreePool but NOT the resolved type pool (no ori_types dependency).

Implementation Sketch

  • Extend ConsumerEntry with a per-pool subset flag set {CanExpr, DecisionTreePool, resolved_type_pool}; populate accurately per consumer.
  • Record ori_eval’s runtime method-dispatch as a SCOPED, ALLOWED surface (dispatch-among-already-typechecked-candidates), NOT a re-derivation violation.
  • Add a module doc + Design-Invariants note mirroring ori_registry’s structural-enforcement comment.
  • Corrected topology: ori_repr and ori_fmt are NOT canon consumers (verified via their Cargo.toml); do not register them.

Spec References

missions.md §ori_registry (pure-data model); missions.md §ori_eval (parity + no type-pool dep); canon.md §3.

Work Items

  • Add per-pool subset flags to ConsumerEntry; populate {CanExpr, DecisionTreePool, type-pool} accurately for each of the 5 consumers.
  • Record ori_eval runtime-dispatch as an allowed scoped surface (annotation on the entry), not a violation.
  • Add module doc + Design-Invariants comment mirroring ori_registry’s structural-enforcement note.
  • Unit test asserting each entry’s pool flags match the consumer’s real type references.

Items

  • Add per-pool subset flags to ConsumerEntry, modeled as a closed classification (an enum/small named-set over {MeaningConsumer{CanExpr, DecisionTreePool, resolved_type_pool}, OrchestrationIdOnly, IdOnlyImporter} — never 3 independent raw bools, since only 3 meaningful shapes exist) rather than boolean flags. Populate it accurately for the 5 already-registered CANON_CONSUMERS entries. ALSO resolve, in this same registry pass, the classification gap the walking-skeleton’s own fresh-intel already found on the live tree: register ori_types (ID-only via MonoInstanceId) and ori_patterns (ID-only via CanId + SharedCanonResult) with an explicit ID-only pool-subset entry, OR record each’s exemption with a stated why per COVER-35 — never leave either silently unregistered for the s-e26ee405 lint to discover later.
  • Add a module doc + Design-Invariants note mirroring ori_registry::burden’s structural-enforcement comment, documenting: (a) the closed pool-subset classification (meaning-consumer / orchestration-ID-only / ID-only-importer) and why ori_types/ori_patterns are registered as ID-only rather than silently exempted; (b) that crate_name stays the real Cargo package identity while any module-qualified detail lives in description only. State only the invariant content (WHY the shape is closed, WHY the classification exists) — never restate what the code visibly does (COMMENT-01/COMMENT-09).

Fresh intel (regenerated)

The section’s own goal statement is already stale against the terrain. It says “populate accurately for each of the 5 consumers” — but its own sibling section (walking-skeleton--s-598f5119, completed) already ran a fresh-intel pass and found the 5-crate list undercounts the real dependency surface: ori_types (via MonoInstanceId) and ori_patterns (via CanId + SharedCanonResult) both import ori_ir::canon today and carry NO CANON_CONSUMERS entry. This dossier’s own terrain query (§2) independently confirms both import sites verbatim against live source. This is not new information this section can ignore — it is a decision the section’s Implementation Sketch has not yet made, and the sibling lint section (s-e26ee405) will trip over the gap the moment its negative-fixture lint runs against the real tree.

Three decisions this package forces before any code is written:

  1. The “5 consumers” premise is wrong — widen the classification, don’t just populate it. ori_types::MonoInstanceId and ori_patterns::CanId/SharedCanonResult are ID-only handle-passers (index/key passage for monomorphization dispatch + closure-body storage), not tree-walking meaning-consumers — exactly the “ID-only importer” category the goal’s own second work item (w-0051af00, scoping ori_eval runtime-dispatch as allowed) already gestures at for a THIRD crate. Extend the per-pool-subset classification to explicitly register (or explicitly exempt with a stated reason) ori_types and ori_patterns, not just the 5 named crates.
  2. The mechanical enforcement (crate-dag-lint.py) validates ONLY crate_name + the ori_ir dependency edge — never the pool-subset field. _read_canon_consumers is a bare regex (crate_name:\s*"([^"]+)") over the Rust source text; it has no knowledge of description, let alone a not-yet-existing pool-subset field. The section’s own w-e318d6df (a Rust unit test asserting pool-flag accuracy) is therefore the ONLY mechanical backstop for this section’s actual deliverable — there is no cross-check today between what the registry CLAIMS about a consumer’s pool usage and what cargo metadata/the lint verifies.
  3. entry_for — the query API the module doc calls “the one query” — has zero production callers. The graph flags it is_dead_code_candidate: true; its only caller is its own unit test, and it sits in a 2-node community with nothing else in the ~223K-symbol graph coupled to it. This is not this section’s bug to fix (pre-existing, shipped by the walking-skeleton), but populating the registry with richer data (pool-subset flags) is the natural moment to ask whether anything should actually query through entry_for — or whether the registry stays a compile-time-only, Python-regex-consumed artifact forever.

DIG DEEPER

scripts/intel-query.sh plan-status canonical-consumer-boundary
scripts/intel-query.sh dag-ascii canonical-consumer-boundary
sed -n '1,50p' compiler_repo/compiler/ori_ir/src/canon/consumers.rs

(full dossier: consumer-ssot-registry—s-e731d59b.intel.md)