shipped work-check hook directs blocked agents to 'crosslink intervene' — a subcommand the CLI does not ship (dead-end remediation)

[magnificentlycursed]

Observed (0.9.0-beta / resources/claude/hooks/work-check.py): all three block messages instruct the agent to log via crosslink intervene <issue-id> ... --trigger ... — but the CLI has no intervene subcommand (error: unrecognized subcommand 'intervene'). An agent complying with the hook's own remediation hits a dead end (the same circular-dead-end class as a docs-vs-binary version gap).

Downstream impact: consumers deploying the hook inherit the dead-end; local edits to the deployed payload are clobbered on re-deploy, so the fix belongs in the shipped resource.

Fix directions (either closes it): repoint the three messages to an existing command (e.g. crosslink issue comment <id> "..." --kind result — the pattern that works today), or ship crosslink intervene (it appears in downstream methodology contracts as an anticipated surface, so shipping it has a consumer waiting).

(Found while aligning our hook config to the PR-boundary git posture your PR #65 / gh#58 reconciliation ratifies.)

[magnificentlycursed]

Correction from a deeper CLI sweep: the capability EXISTS — crosslink issue intervene <id> ... --trigger ... (nested under issue, --trigger required) — the shipped work-check.py messages just point at a nonexistent TOP-LEVEL crosslink intervene. So the fix narrows to one word in the three hook messages: crosslink intervene → crosslink issue intervene (or an alias). Smaller than either direction originally proposed.

[magnificentlycursed]

One more datum from a deeper audit: the dead-end instruction ships in the TEMPLATE — resources/claude/hooks/work-check.py carries three occurrences of top-level crosslink intervene, so every estate deploying the hook inherits the bug (our local repoint is re-deploy-fragile until the resource fixes). With issue intervene confirmed real, the fix is the one-word change in the shipped resource's three messages.