v0.4

Release Notes — Authoritative Resolved IDs for Merge (Breaking Change)

Highlights

• Merge-stage consumers can now use the authoritative dependency identity returned by the resolver, enabling non-path-like reference mapping (e.g., domain-prefixed shader include IDs).

Fixed

• Eliminates merge failures caused by re-deriving dependency IDs from raw directive references (path heuristics) when the resolver maps references to a different canonical ResourceId.

Changed

• The preprocessing pipeline now records, per directive occurrence, the resolved target ResourceId produced during resolution and provides it to merge via MergeContext.

Breaking

• MergeContext<TContent, TDirective> constructor signature changed: it now requires a ResolvedReferences mapping.
• Any downstream/custom merge strategy that constructs or expects the prior MergeContext signature must be updated.

How to use (for downstream merge strategies)

• When inlining/expanding directives in merge, look up the resolved dependency via MergeContext.ResolvedReferences (keyed by (requestingResourceId, directiveIndex)) and then fetch the content from MergeContext.ResolvedCache.
• Do not compute a ResourceId from the raw reference string.

Diagnostics & Docs

• Documentation now clarifies phase responsibilities: resolution errors come from resolver stage; merge diagnostics are for merge-time issues only.
• Docs describe ResolvedReferences as the source of truth for resolved dependency identity.