docs: three dangling links, and a gate so they cannot accumulate

The vault is the project's source of truth, so a link to a page that does not
exist is a promise the repo cannot keep. Three were dangling:

- Dankclaw/Gitea.md pointed twice at dankclaw/compose.yaml — **which this
  session retired**. The clean cutover obligation from my own change: the page
  now describes the unit that publishes 3000 and the canonical Caddy unit, and
  records why the compose file is gone.
- Dankclaw/Hermes-Dashboard.md linked [[LAN DNS]]; the page is [[LAN-DNS]].
- LLM/frank-medium-radiance-mxfp4.md linked [[Observability on Dankclaw]]; the
  page is [[Observability]].

scripts/check-vault-links.py + a seam keep it that way. The checker models
Obsidian's rules, which took three corrections to get right — and each was a
false positive that would have sent me editing healthy docs:

  1. Wikilinks are case-insensitive. A case-sensitive matcher reported 45
     breaks; 39 were `[[qBittorrent]]` vs qbittorrent.md.
  2. `[[folder/Note]]` resolves by path suffix, not by stem.
  3. `%20` in a markdown link is URL-encoding, not a filename.

Validating the linter against the resolver it models is the prerequisite for
trusting any of its output — the same discipline that caught a bad assertion of
my own earlier tonight.
This commit is contained in:
Frank committed 2026-09-16 07:43:33 -07:00
1 parent 80a070d71b
commit 2e33ec36c1
5 files changed
+91 -5

No files matched your search

@@ -54,7 +54,7 @@ login — there is no unauthenticated bind:
reverse-proxies `192.168.0.143:9119` directly, with **no** Anubis/Outpost guard
chain in front of it (exempt-by-construction: the app carries its own complete
auth). The name deliberately has no public DNS record, so the vhost resolves on
the LAN only; WAN clients get NXDOMAIN. See [[LAN DNS]].
the LAN only; WAN clients get NXDOMAIN. See [[LAN-DNS]].
2. **`http://192.168.0.143:9119`** — the raw published port. Still reachable from
any LAN host (the container binds `0.0.0.0` inside its namespace and publishes
`9119:9119`), so treat the LAN as a trusted boundary here, not as a gate.