diff --git a/CLAUDE.md b/CLAUDE.md
index d93a047..87430dc 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -277,17 +277,37 @@ Pi over J4 with the board on 12 V — device ID `04 02 02 00`, NCRA reset
 self-clearing, PAR0–5, MAR0–7, ANALOG, NWAYC, IMR `0x86` readback, NCRA SR,
 and NWAYS `0x17`. See `hardware/re-bba-rb/exi_fullpath_rpi.py`.
 
-⚠️ **OPEN: GC→wire TX does not complete, and the W5100 is unresponsive.**
-Setting the NCRA ST bits never produces TI, and NCRA keeps reading back `0x0a`
-(ST never clears), for EVERY frame length 8…60 with a full NCRA reset between
-attempts. The cause is NOT the EXI side and NOT `tx_bytes` depth (8-byte frames
-fail too): the **UART shell's own socket-3 `udp unicast` also hangs** — it
-echoes the command and never prints `sent` — so the W5100 bus master is stuck
-and `TXFrameDrain` is simply waiting on it. Check the ETH_3V3 rail / GC_ON
-(U12 gates the W5100 rail off GC_ON) before suspecting gateware. Note an
-earlier contaminated run appeared to transmit at one specific length; that was
-leftover state from a previous failed attempt feeding a still-pending drain
-request — always NCRA-reset between TX attempts when probing.
+✅ **GC→wire TX REACHES THE WIRE — the full path is proven.** A frame written
+over EXI to TXDATA and triggered via the NCRA ST bits was captured on a PC:
+`ff ff ff ff ff ff | 00 09 bf 00 00 01 | 08 06 | 00 01` — broadcast dst, our
+PAR0–5 source MAC and the ARP ethertype, all byte-perfect. So
+EXI → BBARegisterFile → tx_bytes → TXFrameDrain → W5100 → PHY works.
+
+⚠️ **OPEN BUG: TX truncates at exactly 16 bytes = the `tx_bytes` FIFO depth.**
+Past byte 16 the captured frame restarts from its own beginning and mixes in
+stale bytes from earlier attempts. Cause: `TXFrameDrain` sits in IDLE until it
+has a LENGTH, and the length only reaches `tx_ctrl` when the NCRA ST bits are
+written — i.e. *after* the GC has streamed the whole frame. So the entire frame
+has to fit in a 16-deep FIFO, and `BBARegisterFile` silently drops bytes when
+`tx_bytes.w_rdy` is low (SPI cannot back-pressure). Simulation never caught it:
+`TXFrameDrain`'s own tests drive the FIFO signals directly, and the `BBATop`
+test only exercises the W5100→SPRAM→GC **RX** loop.
+Fix direction (needs design + sim, NOT done): make the drain start as soon as
+data is available rather than waiting for the length — e.g. push the length into
+`tx_ctrl` when TWD_HI (0x35) is written, which the GC sets before streaming, so
+the drain consumes concurrently with the EXI writes and the 16-deep FIFO becomes
+a rate-matching buffer instead of whole-frame storage. Alternatively give TX an
+SPRAM ring like RX.
+When probing this, **NCRA-reset between every TX attempt**: a failed attempt
+leaves the drain waiting on a stale length, and later writes feed that pending
+request, which makes an unrelated frame length appear to succeed.
+
+⚠️ **The W5100 can wedge and does NOT recover on FPGA reconfigure.** Symptom:
+the UART shell's own socket-3 `udp unicast` echoes the command and never prints
+`sent`, and any EXI TX then hangs waiting on the bus master. `iceprog -t` does
+not clear it (RST_N floats to its pull-up while the FPGA is unconfigured). A
+12 V power cycle is required. Check ETH_3V3 and GC_ON (U12 gates the W5100 rail
+off GC_ON) before suspecting gateware.
 
 **`id_phase` is a ONE-SHOT.** The device ID is returned for reads of address 0
 only until the first NCRA write with the reset bit, which clears `id_phase`