docir — design documents Graph

Documents / Issues / issue-7bc6f13c4d8c

Prose cross-references resolve to nothing, render as markup, and no check sees them

162 prose links in a maintained store were parsed by nothing: build published brackets, a retitle broke inbound links in silence, and finding the one that was broken took four hand-written passes.

issue-7bc6f13c4d8cissueresolved#cli#integrity#retrieval
View as Markdown◉ View in graph

Class: missing · Severity: material Flow: the read path (prose cross-references) · Step: rendering a body, and docir check Frequency: every [[...]] ever written — 162 occurrences across 94 targets in the reporting store

Finding

Documents cross-reference each other two ways and docir read only one. related: frontmatter is resolved, validated, checked and drawn. [[...]] written in prose was touched by nothing: not parsed, not resolved, not rendered, not checked. grep -rn '\[\[' over the source returned zero hits.

What happens today

REPORTED as GitHub issue #9 against 0.25.0, REPRODUCED on the same build. Three failures, and the first is worse than reported:

text
[[adr-fea4a96ca90c]]                      -> [[<a href=…><code>adr-fea…</code></a>]]
[[adr-fea4a96ca90c-hub-api-reads-…]]      -> [[<a …>adr-fea…</a>-hub-api-reads-…]]
[[token-issuer-epoch-drift]]              -> literal text

The bracketed id matched the bare-id linkifier, so build published a link wearing two stray brackets, and the filename-stem form published as a link with the slug hanging outside it. docir check and docir lint --deep reported nothing about any of them.

Impact

A retitle silently breaks every inbound link: update --set-title keeps the filename, so the old slug still names a file while no longer naming a title, and nothing reports it.

The reporter found one broken link in 162 occurrences, by writing a throwaway script, in four passes — two of which were wrong because query excludes inactive documents by default and a link to a resolved document is not broken. That is the measure of how legible this is: four attempts by the person who wrote the links, in the corpus he maintains. The yield is small and the failure is silent, permanent, and reads as fact to anyone who does not go and check.

Actors affected

  • AI coding agent writing cross-references into bodies
  • repository maintainer reading the published site
  • anyone validating links outside docir, who must reimplement a rule docir had not defined

Evidence

  • src/docir/modules/publishing/infra/rendering.py (_linkify_doc_ids, as it was)
  • src/docir/modules/documents/domain/services/graph_checks.py
  • https://github.com/l0kifs/docir/issues/9

Resolution

FIXED. platform.naming.links owns one resolution rule — id, filename stem, title slug, title — read by both sides: publishing renders the resolved ones as links carrying the target's current title, and docir check reports the rest as unresolved-link, a Tier 1 warning. Resolution reads inactive and archived documents, which is the half the hand-written scripts got wrong. Links inside code spans and fences are skipped, so a body explaining the syntax is not a finding.

Prose links still feed no graph: orphan reads related: alone. The reasoning, including why this is Tier 1 where unresolved-mention is Tier 2, is adr-ae631a356639.

Verified by injecting the bug: with resolution restricted to the default query, the check reports the link to the resolved issue as broken — the reporter's own second pass — and with code skipping removed it reports this repository's two syntax examples.

To amend: Re-verify: