diff --git a/harness/mame/README.md b/harness/mame/README.md
index 14d6b52..2c784c6 100644
--- a/harness/mame/README.md
+++ b/harness/mame/README.md
@@ -77,10 +77,21 @@ instead of reaching level 1.
 That test wants **10 bytes** on DUART2 channel A and nothing is attached, so this
 is an honest failure. **It used to "pass" by accident:** the write-back latch
 returned `0x0099` from DUART2's status register, and bit 0 of `0x99` is `RXRDY` —
-stuck asserted — so the firmware's drain loop counted ten phantom bytes. An LK401
-model cannot fix it either (the keyboard's `FD` reply is 4 bytes, not 10). See
-`reference/level1-test-sequence.md`, where the `0xE1` + 10-byte question was first
-raised and where it remains open.
+stuck asserted — so the firmware's drain loop counted ten phantom `0x8C` bytes.
+
+**It is not satisfiable by any documented device** — see
+`reference/level0-10byte-puzzle.md`. The routine writes exactly one byte (`0xE1`,
+"disable auto-repeat", which has no reply), sets `MR2A=0x07` so the channel is in
+**normal mode, not loopback** (confirmed statically *and* from a live access log),
+and checks **only the count**: the received byte is stored and never compared, and
+there is no expected-value table. The keyboard's `FD`/power-up reply is 4 bytes,
+the mouse's `T` reply is 4, the tablet's 5 — none is 10. A faithful LK401 would not
+help either: the init sequence's receiver-reset **flushes the FIFO**.
+
+So no responder will be added. The real terminal *does* pass this test, so the
+bytes exist on real hardware — they are simply not inferable from the ROM, and the
+only honest way to close the question is to observe a real keyboard port at
+power-up.
 
 ### How far the OS gets