Broaden the hook trigger surface: add WebFetch, decide on shell research, hook the research dispatch

[A1igator]

Corrected. This issue originally proposed adding a tenjin precheck verb on the premise that the check depended on model recall. That premise was wrong: the hook already exists, is enabled, and works. Verified by direct test, see the companion issue. What follows is the corrected ask.

The hook watches PreToolUse with matcher WebSearch. The research that missed it used curl, npm view, npm pack, gh api, git show, cast and WebFetch. The fix is trigger surface, not new machinery.

1. Add WebFetch to the matcher, today

Cheapest possible change and it covers a large share of real research. An agent fetching a spec page or a changelog is asking a research question just as much as one typing a query. Same hook, same payload shape, one more matcher entry in what tenjin install writes.

2. Decide what to do about shell-based research

This is the hard part and the one worth designing rather than patching.

A PreToolUse matcher on Bash would fire on every command, which is unacceptable noise: most shell calls are ls, git status, and test runs. But the subset that is unmistakably research is narrow and pattern-matchable in the hook itself, which already exits silently on anything it does not care about:

• curl or wget to a non-localhost host
• npm view, npm pack, pip download
• gh api against a repo that is not one of the operator's own
• cast or other chain reads against a public RPC

The hook is already built to be cheap and silent, so a Bash matcher that inspects the command string and exits 0 immediately on a non-match is consistent with its existing design. The risk is nag fatigue, which argues for a dedup window per question rather than per command.

3. Hook the research dispatch, which is the real decision point

The most valuable trigger is not any individual web call. It is the moment an agent decides to spend a lot on finding something out.

In a harness with subagents, that moment is the spawn of a research task, and it happens once, before the tokens are committed. A PreToolUse matcher on the task-dispatch tool would have fired exactly twice for those 2.07M tokens, with the full research question available in the prompt, which is a far better search input than any single query string. Two prompts against two dispatches, versus dozens of individual calls, is also the lowest-nag option available.

This is the one I would build if only one gets built.

4. Make the outcome visible

searches.json records what the hook saw. Nothing records what it never saw. Because the ledger only grows on a trigger, a day of heavy research that never touched WebSearch is indistinguishable from a quiet day. That is precisely why this went unnoticed until someone who knew the piece existed asked about it.

Anything that lets an operator ask "did we check today, and against what" would have surfaced this immediately.

The signal, restated correctly

The original filing said an installed, available, triggered skill still failed. That was wrong. The accurate version is sharper:

A well-built hook, enabled and working, watching the tool that agents used to use for research, was bypassed entirely by an agent that had a shell. The gap is not reliability, it is that the definition of "web search" moved. Any buyer whose agent has shell access has the same blind spot, and like this one, they will not know, because a miss and a never-triggered look identical from the outside.

[vraspar]

Triage with data, so this issue narrows to the one ask that survived.

A transcript analysis on the operator's machine (584 WebFetch calls across 719 session files, 21 days) settled ask 1: 45% of WebFetch calls are follow-ons to a same-session WebSearch the existing hook already recorded, 31% are doc/reference reads, ~3% junk, leaving ~21% genuine marketplace-shaped questions at 4-5 per active day. An unconditional WebFetch hook would record 4-5x more noise than signal and mostly double-count the WebSearch hook, and suppressing the noise needs a search-dedup gate plus a doc-host allowlist that goes stale permanently. WebFetch stays unhooked; revisit only if those gates exist for other reasons.

Ask 2 (shell research detection): skipped. A curl or gh invocation is not a question; reconstructing intent from command lines is guesswork, and the dispatch hook covers the same sessions at a point where an actual question exists.

Ask 4 (non-trigger visibility): parked as minor.

Ask 3, the dispatch-point hook, is now what this issue tracks: a PreToolUse hook on subagent spawn that appends one marked Tenjin line to research prompts, hitting the exact mechanism #173 and the original incident documented (source enumeration excludes, so the marketplace is never considered). Demand-side junk handling is separate: tenjin#704 plus the ephemeral-outcome plan (tenjin-notes plans/2026-08-17-outcome-taxonomy-and-167.md).

[vraspar]

PR #180 lands items 1 and 3 of this issue: WebFetch is on the trigger surface as a logging-only arm (source webfetch-hook, no injection, per the 45%-duplicate finding), and the research dispatch is hooked via PreToolUse on Agent|Task, forwarding the task description plus a 400-char prompt head and injecting candidates on a hit. A SessionStart primer ships in the same PR so the voluntary path gets taught, not just backstopped.

This issue stays open as the single tracker for what remains. In priority order:

1. Same-session-only publish nudge. The Stop nag currently raises unresolved deliberate MISSes for up to 8 hours, which includes fresh sessions where the agent has no memory of the miss and can only be annoyed. Rescope the strong arm to the session that made the search: at Stop, the agent still holds the context and can judge solved-or-not itself, which is the only reliable solve detector we have. Cross-session leftovers stay in the ledger as demand data and stop nagging. Ledger eligibility at ingest is tenjin#704's side of the same problem.
2. Shell-based research (item 2 of the original filing). Still an open design question, unchanged.
3. Check visibility (item 4). A day of research that never trips a matcher is still indistinguishable from a quiet day; something answerable like "did we check today, against what" is still missing.