The literal question left at the wrap was 'did the wrap seam fire?'. It did not, and the
diagnosis is exact: 0 user-typed /wrap-up records, 29 assistant Skill invocations. The
steward wrote 'then wrap' in prose and the executor invoked the skill. The detector looked
for the steward TYPING the command.
⚠ The detector was not broken. It did exactly what it was built to do. What it was built
to detect is not how a wrap actually arrives — and it was built while the steward was
instructing in prose, which is the only way a wrap had ever arrived in that session.
⚠ AND THE EARLIER FIX IS WHAT CAUSED THIS. Restricting to type=user with string content
was the correct answer to the self-reference bug, where the executor's own tool_use inputs
matched the literal marker. That same restriction excludes the legitimate path. 'The
correct fix caused the next failure' is not a shape any control can see, and it is
PENDING-160's subject exactly.
Now accepts a tool_use whose NAME is Skill and whose input names wrap-up — structural, so
a Bash command echoing the string still does not match. Negative controls for both that
and for a different skill.
And a heartbeat: one timestamp, OVERWRITTEN never appended, so the hook can prove it runs
at all. That closes the silent-net objection this surface carried from the day it shipped
— an append-only log of every turn would be noise and would become the ledger §9 forbids.
25/25. wrap_invoked() now returns True on the live transcript. ⚠ Unproven until the next
Stop actually fires — which is the same claim that was wrong last time.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01J6hZXNYSxEfZseBGTni4sf
