check-issue-refs: catch full forge issue URLs too, drop internal links from docs entirely

docs/README.md

@@ -92,8 +92,7 @@ declarations.
 
 - **What does a specific Rust crate do, on its own terms?** →
   [`crates/`](crates/README.md) — every workspace crate's own
-  `README.md`, one level up from source
-  (`$HIVE_FORGE_URL/hyperhive/hyperhive/issues/3051`); the crate
+  `README.md`, one level up from source; the crate
   itself is still the source of truth, this is just a walkable mirror.
 
 ## Process & conventions

docs/agent-lifecycle/agent-hierarchy.md

@@ -4,8 +4,7 @@ Every agent has a place in an operator-editable parent/child tree, used
 to scope which agents can manage which others. This doc covers how
 hive-c0re stores and edits the tree today, the rules that are meant to run on top
 of it once enforcement is finished, and where the manager still gets
-special-cased in the meantime. Tracking issue:
-`$HIVE_FORGE_URL/hyperhive/hyperhive/issues/361`.
+special-cased in the meantime, as a tracked cleanup.
 
 ## Where the tree lives
 
@@ -235,10 +234,7 @@ uid 0 and have the setuid bit set."
 
 ## Cross-references
 
-- Milestone: "Agent privileges and sub-agents"
-  (`$HIVE_FORGE_URL/hyperhive/hyperhive/issues/361`)
-- Dashboard render: "show agent topology in container list"
-  (`$HIVE_FORGE_URL/hyperhive/hyperhive/issues/363`)
-- Audit table source: milestone comment
-  (`$HIVE_FORGE_URL/hyperhive/hyperhive/issues/361#issuecomment-3335`)
+- Milestone: "Agent privileges and sub-agents" (tracked internally)
+- Dashboard render: "show agent topology in container list" (tracked internally)
+- Audit table source: milestone comment (tracked internally)
 - Operator/agent trust boundary (orthogonal axis): [`boundary.md`](../trust-boundary/boundary.md)

docs/agent-lifecycle/approvals.md

@@ -69,8 +69,7 @@ request.
    and no approval. (it's currently mounted read-write, which is a
    defect tracked separately, not an authoring path.)
    Branch protection (push/merge allowlist = `core`, approvals allowlist
-   = operator team; see "Forge mirror" and
-   `$HIVE_FORGE_URL/hyperhive/hyperhive/issues/1787`) makes the agent a
+   = operator team; see "Forge mirror" below) makes the agent a
    write collaborator that **can't merge its own config PR**.
 2. hive-c0re's `/webhook/config-pr` endpoint receives the Forgejo
    `pull_request` event (opened / synchronized / reopened) and queues a
@@ -477,8 +476,7 @@ repo — so it can push a branch and open a config PR — but not a member
 of any other agent's, so it can't reach another agent's config through
 the forge. Branch protection keeps `main` push/merge `core`-only with
 operator-team approval, so an agent can't fast-forward its own config or
-self-merge its PR (see the End-to-end flow +
-`$HIVE_FORGE_URL/hyperhive/hyperhive/issues/1787`). hive-c0re passes the tokenised push
+self-merge its PR (see the End-to-end flow above). hive-c0re passes the tokenised push
 URL inline to `git push`, never writing it into
 `applied/<n>/.git/config`; that repo is RO-bind-mounted into the root
 agent, and a stored token would leak core's admin credential to an

docs/agent-lifecycle/persistence.md

@@ -437,7 +437,7 @@ would only be transient.
 
 On a btrfs host, `lifecycle::ensure_agent_state_subvolume` creates a brand-new agent's state root as a
 **btrfs subvolume** instead of a plain directory (progressive
-enhancement — see `$HIVE_FORGE_URL/hyperhive/hyperhive/issues/1762`). This is a no-op fallback on
+enhancement). This is a no-op fallback on
 non-btrfs hosts and for any agent whose root already exists, so
 nothing is automigrated: existing agents keep their plain dirs
 until an explicit opt-in upgrade.

docs/crates/README.md

@@ -3,8 +3,7 @@
 One page per Rust workspace crate — its own `README.md`, unchanged, served
 here for browsing alongside the rest of the docs site. **The crate's own
 `README.md` is the source of truth; nothing here is hand-maintained.**
-`nix/packages/reference-docs.nix`
-(`$HIVE_FORGE_URL/hyperhive/hyperhive/issues/3051`) generates every page at
+`nix/packages/reference-docs.nix` generates every page at
 build time straight from the crate's real `README.md`, so it can never
 drift out of sync the way a hand-copied mirror would — edit the crate's
 own README to change what shows up here.

docs/getting-started/setup.md

@@ -95,8 +95,7 @@ store's container reads it, writes the `swarm-controller` policy, enables the
 cert auth method, and creates the `swarm-controller` role that attaches the two.
 
 ⚠️ **This has only run once, and it didn't go all the way through.** The
-first real provision against a live store returned 403
-(`$HIVE_FORGE_URL/hyperhive/hyperhive/issues/4124`), so
+first real provision against a live store returned 403, so
 treat the block above as derived-then-partly-tested rather than proven: the
 grants still come from `-output-policy`, not from a swarm that came up on them.
 What that 403 does _not_ tell you is whether the login or the write was
@@ -129,8 +128,7 @@ can't hand you, being what opens it. ⚠️ Not the gateway's HTTPS certificates
 store that took its identity from an authority it will itself distribute could
 never come up before that authority.
 
-Making even the `init` unnecessary is tracked in
-`$HIVE_FORGE_URL/hyperhive/hyperhive/issues/3768`.
+Making even the `init` unnecessary is tracked as a follow-up.
 
 ### 4 · Swarm SSO (only when `deploy.authelia`)
 

docs/process/gotchas.md

@@ -412,7 +412,7 @@ connects to the compositor at `127.0.0.1:<vnc_port>`.
   Wayland clients couldn't find the compositor — libwayland falls
   back to a headless display or errors out, the app "works" on a
   second invisible display, and the VNC session shows a blank weston
-  desktop (`$HIVE_FORGE_URL/hyperhive/hyperhive/issues/540`, double-screen).
+  desktop (known double-screen issue).
 - **VNC bind address**: Weston's `vnc-backend` has no CLI
   bind-address flag (unlike the `rdp-backend`'s `--address`), so the
   listener binds `0.0.0.0`. The harness relay only connects via

docs/tools/bash.md

@@ -112,7 +112,7 @@ summary change signals the harness turn loop directly (in-process, no broker
 round-trip), so the harness drives a turn for the agent to handle it via
 `get_loose_ends`, then clears the todo with `cancel_loose_end(kind: "todo", id: N)` (dials the
 in-container socket directly — no bash task involved, so clearing doesn't
-spawn another todo; see `$HIVE_FORGE_URL/hyperhive/hyperhive/issues/2639`). Same mechanism the matrix daemon uses for
+spawn another todo). Same mechanism the matrix daemon uses for
 unread rooms. An inline `wait_seconds` / `status` observation that already
 delivered the result instead clears the keyed todo, so no redundant
 loose-end follows.

docs/trust-boundary/security.md

@@ -63,7 +63,7 @@ What still holds: the grant is **read-only** (a hive can't write an agent's
 credential, so it can't hand itself an agent's identity), and it's scoped to
 the agent-credential prefix — nothing else in the store is reachable with it.
 
-**`$HIVE_FORGE_URL/hyperhive/hyperhive/issues/4137`** tracks narrowing it, with the two candidate directions: scope
+**A tracked follow-up** narrows this, with the two candidate directions: scope
 the grant per hive (and pay for the re-emission), or give each agent container
 its own store identity so credentials never pass through a hive at all.
 

docs/turn-loop/claude-invocation.md

@@ -133,9 +133,7 @@ the reactive path only fires once claude-code has already refused a whole
 turn as too long. Neither can see context growth happening _inside_ a
 single long turn's own tool-calling before it returns — a turn whose tool
 calls alone blow past the window hits the reactive path with no preceding
-checkpoint, losing whatever wasn't already persisted
-(`$HIVE_FORGE_URL/hyperhive/hyperhive/issues/2707`, root-caused in
-`$HIVE_FORGE_URL/hyperhive/hyperhive/issues/3727`).
+checkpoint, losing whatever wasn't already persisted (a known, root-caused gap).
 
 **Safety net for that gap: claude-code's own native autocompact is on**,
 via the managed settings (`"autoCompactEnabled": true`,

docs/turn-loop/mcp.md

@@ -222,7 +222,7 @@ operator-driven `hivectl choom` session — which passes neither `--tools`
 nor `--allowedTools` — gets claude's built-in synchronous `Bash` tool
 (inline, human-approved). That sidesteps the async `mcp__bash__run`
 completion wake landing in the wrong session (the harness inbox) for a
-choom-started task (`$HIVE_FORGE_URL/hyperhive/hyperhive/issues/2356`); `choom` is an operator (root) action, so
+choom-started task; `choom` is an operator (root) action, so
 built-in shell there stays within the existing trust boundary. The bash MCP server
 (`run` / `status` / `kill`) uses `allowedTools = ["*"]` so all
 `mcp__bash__*` tools are always available regardless of tool groups.

docs/web-ui/agent.md

@@ -85,7 +85,7 @@ structurally rather than for one specific trigger. Two columns:
     `agent_links()` in hive-agent is the single source of truth for
     both. No separate overflow (`⋯`) menu exists any more — it used
     to hold exactly this dashboard link plus a rebuild-container action
-    (mara, `$HIVE_FORGE_URL/hyperhive/hyperhive/issues/3704`: "remove rebuild button, move link to
+    (mara: "remove rebuild button, move link to
     dashboards into links menu") — rebuild had no real discoverability
     need of its own (the dashboard's own R3BU1LD button already covers
     it) so it's gone outright, and the dashboard link moved here,

docs/web-ui/dashboard.md

@@ -146,7 +146,7 @@ part-way through a spawn is byte-identical on disk to a tombstone, and
 the pane lists both. The pane carries a standing warning to that effect, and
 the row badge says `offline` rather than `destroyed` — the absence of a
 container is all hive-c0re can actually prove. Fixing it properly
-needs a recorded destroy: **`$HIVE_FORGE_URL/hyperhive/hyperhive/issues/3020`**, deferred to the swarm-controller /
+needs a recorded destroy — **deferred** to the swarm-controller /
 snapshot-storage rework where the problem changes shape.
 
 *Stale permission entries*: agents with explicit capability or
@@ -236,7 +236,7 @@ than reconstructing chrome hive-c0re no longer sends. Settled entries
 render their **full step tree**, not just a bare summary — the wire
 doesn't filter `Done` nodes out.
 
-**State filter (`$HIVE_FORGE_URL/hyperhive/hyperhive/issues/2606`).** A row of per-state checkboxes above
+**State filter.** A row of per-state checkboxes above
 the tree — one per lifecycle state, matching the row glyphs — lets the
 operator narrow which root groups render; unchecking a state re-fetches
 `GET /api/jobq/graph?states=<checked, comma-joined>` rather than
@@ -811,7 +811,7 @@ below).
 
 ### Status badges
 
-**Which single badge (`$HIVE_FORGE_URL/hyperhive/hyperhive/issues/3139`):** `ContainerView.failed`
+**Which single badge:** `ContainerView.failed`
 (systemd `ActiveState=failed` — the unit exhausted its bounded
 restarts and gave up on its own) draws a red `✖ gave up` badge;
 otherwise a plain muted `■ not running` — a container an operator

docs/web-ui/shape.md

@@ -245,7 +245,6 @@ drill-ins (file previews, diffs, journald logs) now open in the
 **side panel** (see below) rather than expanding inline. The
 dashboard's own answered-questions history list was the only
 `<details data-restore-key>` consumer and is gone
-(`$HIVE_FORGE_URL/hyperhive/hyperhive/issues/3721`)
 — `snapshotOpenDetails()` / `restoreOpenDetails()` currently have
 nothing to restore, kept in place for the next collapsible section
 that needs it rather than ripped out along with their one caller.