# TAG-VERDICT — un-collapse the tag-send verdict, and make the mid-turn leg observable

JIT plan, 2026-08-03. Field incident: doyle's session surfaced
`[tag-send] NO PERCH (not delivered) → todlando, hertz, hertz` while every one of those
bodies was **delivered** (attested by all three recipients) and the hook trace recorded
`QUEUED` for the same sends at 16:20:22 and 16:23:34.

## What actually broke

Two defects, neither of them in delivery:

1. **The verdict is a catch-all.** `SendOutcome::Failed` (`hook.rs:2167-2177`) is an `else`
   branch collapsing four distinct states — a true `NO_PERCH:` from core, an empty answer,
   an **unrecognized token**, and **`spt_send` returning `None`: the `spt` binary could not
   be spawned at all**. `hook.rs:2353` then renders all four as one flat assertion,
   `NO PERCH (not delivered)`. A process-spawn failure is reported as a claim about a
   *peer's perch*. The raw token is discarded, so the one send that genuinely failed
   destroyed the only evidence that could classify it.

2. **The mid-turn leg is invisible.** The Stop leg records its outcomes
   (`hook.rs:2491-2518`); the PreToolUse leg (`hook.rs:2415`) inlines its confirm and
   writes **nothing** to the trace. So `hook-trace.log` is structurally blind to whichever
   leg surfaced the false verdicts — which is why both perri and doyle reasoned from half a
   population before noticing.

Suspected trigger, stated as hypothesis with a falsifier, NOT as a finding: **some resource
starved the process spawn** during that window. `spt_send` returning `None` (spawn failed)
lands in the same catch-all as a real `NO_PERCH`, so a starved spawn renders as a claim
about a peer's perch.

**The resource is NOT established, and the disk figure is withdrawn.** An earlier draft of
this plan named 0.01–0.04 GB free on C:. Instrument, named because the claim needs one: that
number was quoted from doyle's advisory message, never measured here. doyle then produced two
readings against it — the CI floor gate printed `free_bytes=26224361472` (24.4 GiB) at 16:48
local, and his own `Get-PSDrive C` read 23.98 GiB at ~16:55. perri's own only measurement of
C: was 47.62 GB, taken after his reap, which corroborates his "free after 47.60 GB" and
nothing about the low point. So C: free bytes is not the established cause; candidate
pressures include handle/process exhaustion (his 23:48Z census: 556 processes, 245,738
handles) or a volume other than C:.

**Falsifier, which survives the withdrawal:** false verdicts should cluster inside the
incident window and be absent outside it — this does not depend on *which* resource starved.
Untestable from the current log, precisely because of defect 2. The fix is what makes the
next occurrence diagnosable; it is not itself proof of any trigger.

Related but NOT in scope: the cursor is written last (`hook.rs:2382`), after every send, so
a leg that dispatches then dies re-scans the same bytes on the next leg. That explains one
scan seeing two turns' tag blocks. Recipients report no duplicates, so this is not currently
costing delivery — logged here, not fixed here.

## Scope

- `SendOutcome::Failed` splits into `NoPerch` / `SpawnFailed` / `Unrecognized(token)`.
- The confirm names each apart and **carries the raw token** for the unrecognized case.
  A spawn failure must never render as a claim about the target's perch.
- The PreToolUse leg records its send outcomes in the hook trace, as the Stop leg does.

Out of scope: the cursor-write ordering; deployah's 17:07:23 same-second case (blocked on
this fix landing before it can be classified).

## Requirements

- `REQ-TAG-SEND-VERDICT-NOT-CATCHALL` — impl + unit
- `REQ-TAG-SEND-PRETOOL-TRACE` — impl + unit

## Gate

`sh ci/run-gates.sh` PASS + `traceable-reqs check` exit 0.

## Consequence to keep in the commit message (deployah, verbatim)

> a false NO PERCH invites the sender to resend or to conclude the target is unreachable, so
> the observable consequence is DUPLICATE delivery and a wrong belief about the roster…
> Tonight it cost nothing because your two bodies were compatible. Two bodies that
> CONTRADICTED each other, delivered in an order the sender does not know, is the same bug
> with a real bill.