hooks.json registers ISASync on Write/Edit/MultiEdit only, so its documented PostToolUse(Read) branch and the sessionUUID rebind are unreachable #2192

Observed on 7.54.0.

What

ISASync.hook.ts advertises a Read trigger and implements it:

// hooks/ISASync.hook.ts:5
 * TRIGGER: PostToolUse (Write, Edit, MultiEdit, Read)

// hooks/ISASync.hook.ts:76
// v6.9.0: Read trigger — bump heartbeat on the slug, rebind UUID, debounced.
if (toolName === 'Read') {
  const slugMatch = filePath.match(/MEMORY\/WORK\/([^/]+)\//);
  if (slugMatch) bumpLastToolActivityBySlug(slugMatch[1], input.session_id);
  return null;
}

Nothing registers it on Read. The PostToolUse "Read" matcher, in both hooks/hooks.json and the shipped skills/LifeOS/install/hooks/hooks.json, carries ISAStaleWriteGuard.hook.ts alone:

jq -r '.hooks.PostToolUse[]|select(.matcher=="Read")|.hooks[].command' hooks/hooks.json
# -> $HOME/.claude/hooks/ISAStaleWriteGuard.hook.ts

bumpLastToolActivityBySlug has exactly two call sites: the dead branch above, and bumpLastToolActivity() in hooks/lib/isa-utils.ts, which calls it without a sessionUUID. So the rebind / placeholder-collapse block guarded by that parameter is unreachable code.

Observed

A session that only reads a prior ISA never rebinds work.json's sessionUUID and never collapses its own starting placeholder row, so the board carries a duplicate nameless session beside the real run until something writes the ISA.

Expected

Per the v6.9.0 comment in isa-utils.ts: "a fresh session UUID reading an ISA still registers as a heartbeat for that ISA's slug", rebinding the row.

Fix sketch

Either add ISASync.hook.ts to the PostToolUse "Read" matcher in hooks/hooks.json and in skills/LifeOS/install/hooks/hooks.json, or — if the behaviour was retired deliberately — delete the branch, the sessionUUID parameter and the header's Read claim, so the code stops advertising a trigger it does not have.

Filed as an issue rather than a PR because which of those two is correct is a maintainer call: registering it adds a hook to every Read, which is the hottest event in the stack.