Skip to content

fix(hooks): register ToolFailureTracker + ISASync (shipped but never wired)#1398

Open
krikauskis wants to merge 1 commit into
danielmiessler:mainfrom
krikauskis:digibrain/fix-toolfailuretracker-isasync-registration
Open

fix(hooks): register ToolFailureTracker + ISASync (shipped but never wired)#1398
krikauskis wants to merge 1 commit into
danielmiessler:mainfrom
krikauskis:digibrain/fix-toolfailuretracker-isasync-registration

Conversation

@krikauskis

Copy link
Copy Markdown

What

Registers two hooks that ship in the release but are never wired in settings.json:

  • hooks/ToolFailureTracker.hook.ts on a new PostToolUseFailure event.
  • hooks/ISASync.hook.ts as an async, self-filtering PostToolUse entry.

Why

Both hooks ship in v5.0.0, both declare their own trigger in their headers, and
hooks/README.md documents both as wired — but settings.json registers neither,
so neither hook ever fires. This is a documentation-vs-config drift.

ToolFailureTracker (grep -c ToolFailureTracker settings.json0): the hook
declares TRIGGER: PostToolUseFailure and hooks/README.md documents it under a
"PostToolUseFailure Hooks" section, but no PostToolUseFailure event exists in
settings.json. The observability hook meant to populate
MEMORY/OBSERVABILITY/tool-failures.jsonl never runs, so Pulse failure metrics are
silently empty for every user. (If a config instead wires this hook matcher-less
under PostToolUse, it fires on success too and logs a false tool_failure after
every call — registering it on the correct event fixes that failure mode as well.)

ISASync (grep -c ISASync settings.json0): ISASync is the documented sole
writer of session.phase/phaseHistory into work.json (see hooks/lib/isa-utils.ts
and the hook header), and hooks/README.md documents it as a PostToolUse hook — but it
is never wired. Result: no ISA → work.json sync ever fires, so the Pulse Algorithm phase
view (/api/algorithm) and the Agents pane are empty for every Algorithm run on a
stock install. The hook self-filters on MEMORY/WORK/**/ISA.md, so it is inert for all
other writes.

Change

Two additions to settings.json hooks, matching each hook's documented contract:

  1. A PostToolUseFailure block registering ToolFailureTracker (async).
  2. An async PostToolUse entry for ISASync (self-filtering; mirrors how
    ToolActivityTracker is already registered).

No hook-body change.

Testing

  • Before: grep -c ToolFailureTracker settings.json → 0; grep -c ISASync settings.json → 0; no PostToolUseFailure key.
  • After: both hooks registered; JSON validates. A failing tool call appends one structured event to MEMORY/OBSERVABILITY/tool-failures.jsonl (successful calls append nothing); an Algorithm task that writes MEMORY/WORK/<slug>/ISA.md syncs phase to work.json so /api/algorithm returns the live phase and the Agents pane populates.

Note for maintainers

The PostToolUseFailure registration assumes the Claude Code harness in your target
version emits a PostToolUseFailure hook event (the project documents it as one, and the
hook's own header declares it). If the harness has renamed/removed it, the alternative is
to keep ToolFailureTracker on PostToolUse and have it self-filter on a populated
failure field. PostToolUse (for ISASync) is unambiguously supported — five entries in
the same file already use it.

…wired)

Both hooks ship in v5.0.0 but settings.json registers neither on any event:
- ToolFailureTracker.hook.ts declares TRIGGER: PostToolUseFailure and is
  documented under a 'PostToolUseFailure Hooks' section in hooks/README.md,
  but no PostToolUseFailure event exists in settings.json.
- ISASync.hook.ts is the documented sole writer of session.phase/phaseHistory
  into work.json and is documented as a PostToolUse hook, but is never wired.

Adds a PostToolUseFailure block registering ToolFailureTracker on the event its
own header documents, and an async self-filtering PostToolUse entry for ISASync.
No hook-body change.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant