Enforce correct SourceryKit usage with dev-time hooks

[aural-psynapse]

Skills teach an agent how to integrate SourceryKit; nothing checks the agent actually did. An agent can skip wrapping a call, forget the structured output, or never verify — and the guardrail silently does nothing. We should ship hooks: deterministic checks that fire on coding-agent events (post-edit, pre-commit) and flag or block an integration that's missing its guardrails, while the code is being written.

Where skills are advisory, hooks are enforcement. Together they cover both halves: teach the right way, then catch when it wasn't followed.

What to ship

Checks that fire during development and fail loudly when the integration is incomplete — for example:

• an outbound HTTP call inside an agent tool that isn't wrapped in async_intercept_context
• an agent whose output type isn't SourceryKitAgentResponse (or a subclass), so claimed_values will always be empty
• a tool hitting a URL never registered via insert_trusted_endpoint
• a terminal path that returns a result without ever calling evaluate_handoff

The goal is to turn "the guardrail quietly did nothing" into an error the agent sees and fixes on the spot.

Why

• The whole value of SourceryKit is catching hallucinations. A silently-skipped integration is worse than none — it looks protected and isn't.
• Catching it at author time (not runtime, in prod) is cheap and immediate.
• Complements the skills work: skills reduce mistakes, hooks catch the ones that slip through.

Notes / out of scope

• Hooks are per-tool (Claude Code settings.json, Codex, Gemini each differ) — no shared format like SKILL.md, so expect per-ecosystem adapters. Scope which tools to support during the work.
• The exact check implementation (static analysis vs runtime assertions) — decided by whoever picks this up.

[benrrr56-wq]

The real risk here isn't a malicious agent — it's a well-meaning one that reads the skill, does a half-integration, and then every later result carries the SourceryKit stamp without any of the wrap/verify actually having run. Today that absence is invisible: a skipped wrap and a properly verified call emit the same verdict, so the guardrail silently endorses calls it never checked. Treat non-usage as a distinct, fail-closed state rather than a silent pass — if the wrap or structured-output step didn't execute for a call, mark it unverified instead of green. And consider recording a per-interception attestation (call → checks-that-ran → verdict) so coverage can be recomputed later; tamper-evident / recomputably verifiable evidence beats a boolean "verified" flag. I build an opt-in checkpoint layer (allow/deny/require-human-approval) with recomputable evidence — happy to compare notes on the hook design.