[FIX] The wrap seam detected the wrong thing, and the correct fix is what blinded it

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

claude/governance/fool/TARBUCKLE-SPEC-13.1-2026-08-25.md

@@ -88,6 +88,18 @@ that fires into nothing and reports success. **Owed, not dropped.** The remainin
 the `/wrap-up` skill itself, which is a skill change and therefore goes through the
 skill-harvest register rather than being taken unilaterally.
 
+⚠ **THE WRAP SEAM DID NOT FIRE ON ITS FIRST REAL WRAP, and the reason is the sharpest
+finding in PENDING-160.** It detected the steward *typing* `/wrap-up`. On the day it
+shipped the steward wrote **"then wrap"** in prose and the executor invoked the skill:
+**0 user-typed records, 29 assistant invocations, detector correctly returns False, fool
+silent.** The detector was not broken — *what it was built to detect is not how a wrap
+arrives*. ⚠ **And the fix that made it correct is what blinded it:** restricting to `user`
+records was the right answer to the self-reference bug, and that same restriction excludes
+the real path. Fixed to accept a `Skill` tool_use naming wrap-up, with negative controls
+for a Bash echo and for a different skill. **A heartbeat file (`tarbuckle-wrap-lastrun`,
+overwritten, never appended) now proves the hook runs at all** — the silent-net objection
+this surface carried from the start.
+
 ⚠ **Bounded generation is legitimate because of the steward's ruling**, not despite it:
 *"A guaranteed occasion is not a guaranteed utterance. If a seam produces nothing that
 passes, let it produce nothing."* Timeout ⇒ silence, logged.