Function site_links_page_relative 

pub fn site_links_page_relative(
    generator: &'static str,
    page: &str,
    text: &str,
) -> Result<String, Error>

Rewrites this site’s absolute page URLs into page-relative Markdown links.

A doc comment cites the guide with SITE_PAGE_PREFIX because the same text is rendered by docs.rs, where a relative path is meaningless. When a generator inlines that prose into a page of this same site, republishing the absolute URL costs two real things:

• a reader of /0.1/reference/catalog/ who follows it is thrown to /latest/, silently, and lands on documentation for a version they are not reading;
• mkdocs build --strict cannot check it. validation.links.not_found and validation.links.anchors see a relative Markdown link and never an external URL, so an absolute link to a page that has been renamed is correct-looking and dead. This is D38 sub-decision (3)’s reasoning — Python and CLI links are emitted page-relative specifically so every one of them is validated on every build — applied to the other direction of the same problem.

page is the generated page’s own repository-relative path, so docs/reference/catalog.md yields ../howto/x.md and docs/index.md yields howto/x.md from one rule rather than from a per-generator constant.

Only this site’s URLs are touched. A docs.rs URL — atune_derive’s citation of Space::schema reaches docs/reference/space-dsl.md through resolve_reference_links — names a page on another host and must stay absolute.

Errors

Error::Unclassifiable when a site URL is not the target of an inline link, and when page is not a Markdown page under docs/. Both are fail-closed for the same reason: the rewrite has no valid output. A page-relative target is not a legal autolink — an autolink’s contents must be an absolute URI — and is not a link at all in bare prose, so emitting one would publish broken Markdown rather than an unverified link, which is strictly worse than the state being fixed.