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:
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.
|
||||
|
||||
Reference in new issue
Block a user