lychee-redirect-triagelisted

# Lychee Redirect / Link-Rot Triage Playbook Actionable consolidation of ClaudeSec's link-hygiene knowledge (PRs #290–#296). Use it to turn a redirect / dead-link finding into the *right* fix — not a reflexive exclude that hides real rot. Source of truth is always the live `lychee.toml` + `.github/workflows/lint.yml`; re-read them before quoting a flag. ## The one thing to internalize first **CI cannot catch link rot for you.** The PR-time `link-check` job runs lychee with `--accept '100..=599'`, so every 3xx/4xx/5xx response *passes* CI by design (this stops flaky external sites from blocking docs merges). So a green `link-check` does **not** mean links are healthy. Two backstops exist instead: - The **monthly redirect-sweep** (`lychee-redirect-sweep.yml`) re-runs lychee with `--max-redirects 0 --accept '200..=299'` and files a self-healing issue. - **This manual playbook**, when you hit a WARN locally or triage a sweep issue. Corollary: when you inspect a link, **capture its FINAL status code, not just the effective URL.** A URL that "resolves" in a browser can still be a 404 or an unwanted redirect that CI silently accepted. ## Triage decision tree For each flagged URL, curl it and read the *first* status (don't let curl follow redirects — you want to see the 3xx itself): ```bash curl -sS -o /dev/null -w '%{http_code} -> %{redirect_url}\n' --max-redirs 0 "<URL>" ``` Then classify: 1. **200 (clean)** — not a finding; it slipped in via the broad PR accept range