ElaboratedModuleGraph's field is fully public, unlike NormalizedModuleGraph's

LIMIT-ELABORATION-001

ElaboratedModuleGraph's field is public, so code outside the frontend can build one without running elaboration, unlike NormalizedModuleGraph.

Lifecycle

known

Owner

metel-frontend

Scope

architecture/spec/elaboration.md#elaboration

Origin

this session's architecture-spec inventory (direct source reading), 2026-09-17

Affects · linked records

arch.elaboration.requirement-1architecture requirement

arch.path-normalization.requirement-1architecture requirement

ElaboratedModuleGraph metel-frontend/src/pipeline/elaboration/mod.rscode

limitationKnown limitations ↗

Limitation

ElaboratedModuleGraph(pub TypedModuleGraph)'s inner field is fully pub, so code outside metel-frontend can construct one directly without having run elaborate — unlike NormalizedModuleGraph (arch.path-normalization.requirement-1), whose pub(crate) field blocks exactly that from outside the crate. The two "proof this pass has run" wrapper types are not actually symmetric in what they enforce, despite both existing for the same stated purpose.

Impact

Nothing in the current codebase exploits this, but nothing prevents a future caller — inside metel-interpreter, or any external crate depending on metel-frontend — from synthesizing an ElaboratedModuleGraph whose MethodDispatch fields were never actually resolved, defeating the "proof" the type's own doc comment claims it carries.

Affects

• arch.elaboration.requirement-1
• arch.path-normalization.requirement-1

• metel-frontend/src/pipeline/elaboration/mod.rs::ElaboratedModuleGraph

Resolution

None yet. The straightforward fix (narrow the field to pub(crate), matching NormalizedModuleGraph) has not been evaluated for what it would break in existing callers.