Problem
Source-aware native Markdown includes can carry inline-link origins using per-render parser boundaries, but reference definitions may bind uses in a different file. The final anchor's location does not identify where its destination was authored. This is a separate limitation from ordinary standalone reference-style links.
The source-link correction for #86 deliberately refuses reference definitions combined with includes, using bounded native-parser binding probes so code groups, fenced code, HTML code and literal examples remain intact. It does not silently select the host directory.
Acceptance
- Retain the source origin of each effective reference definition through include expansion and native parsing, including first-definition precedence and normalized labels.
- Resolve uses in the host from included definitions and uses in an include from host definitions using the definition's actual directory and the rendered locale.
- Cover recursive includes, same-named targets in different directories, escaped brackets, multiline labels, HTML-bearing labels, query strings and fragments.
- Preserve literal examples in fenced blocks, code groups and HTML code; do not introduce a partial regular-expression destination rewriter or global current-source state.
- Demonstrate public native build and dev behavior, retained good output on unsupported/read failures, and bounded validation. Remove the documented reference/include refusal only after that proof.
- Qualify package release and downstream Stacks/Buddy adoption separately from retained application evidence.
Related integration: https://github.com/stacksjs/drone/issues/39
Native correction: PR #87, source commit fc7bb3ce58ac052aa5eb1e3e76bd5d4f2cea78a1. This issue tracks full cross-file reference support; the correction deliberately refuses that unsupported combination.