docs: record t-display s3 acceptance evidence

Author: VincenzoImp

docs/flash.md

@@ -276,3 +276,7 @@ This target runs only `espefuse.py --chip esp32s3 --port <port> summary` and
 prints JSON for secure boot, flash encryption, download-mode, and debug-lock
 state. It is an M9 gap measurement tool, not a provisioning command. It must
 not be treated as production hardening and does not enable signing.
+
+After the read-only fuse audit, hard-reset the board before running app
+protocol smokes or manual review-display commands. The audit can leave the
+chip outside the running application protocol until reset.

docs/roadmap.md

@@ -332,6 +332,19 @@ color change. The smoke records protocol/display-path evidence only; human
 visual color confirmation remains separate from production trusted-display
 acceptance.
 
+Hardware note, 2026-05-21: revision `3a67803` was built with ESP-IDF
+`v5.5.4`, flashed to the attached T-Display S3 on `/dev/cu.usbmodem1101`, and
+passed capability smoke with 40 exchanges, 9 response frames, and 31 expected
+rejections. The review-scenario smoke passed 8 scenarios with 9 exchanges, 8
+response frames, and 1 expected rejection. Human observation confirmed the
+basic Event review, dense structured tags, control-character escapes, Unicode
+fallback, request-error state, long KEY/GPIO14 approve path, and long
+BOOT/GPIO0 reject path rendered or behaved as expected. The read-only
+security-fuse audit reported secure boot, flash encryption, debug lock,
+download mode, and manual flash-encryption download as production blockers.
+A hard reset after the fuse audit was required before the application serial
+protocol responded again. Signing remains disabled.
+
 Status note, 2026-05-09: the T-Display S3 button press classifier is now
 factored into a host-buildable state machine shared by the ESP-IDF GPIO polling
 adapter. Host-core tests cover debounce rejection, short press mapping, long

docs/security.md

@@ -75,6 +75,15 @@ enable secure boot, enable flash encryption, disable download mode, or lock
 debug access. It reports whether those irreversible production-hardening steps
 are still blockers.
 
+Hardware note, 2026-05-21: revision `3a67803` was built with ESP-IDF
+`v5.5.4`, flashed to the attached T-Display S3 on
+`/dev/cu.usbmodem1101`, and passed capability smoke, review-scenario smoke,
+manual visual review scenarios, approve/reject button observation, and the
+read-only security-fuse audit. The audit still reported secure boot, flash
+encryption, debug lock, download mode, and manual flash-encryption download as
+production blockers. A hard reset was required after the fuse audit before the
+application serial protocol responded again.
+
 Before any real signing path can be enabled, the production profile must prove:
 
 - trusted display acceptance

docs/testing.md

@@ -343,6 +343,16 @@ tests with strict C++ warnings.
   Host-core raster tests verify Value lines use the dedicated yellow color;
   the hardware smoke does not replace human visual color inspection and does
   not enable signing.
+- T-Display S3 physical acceptance evidence recorded for revision `3a67803` on
+  `/dev/cu.usbmodem1101`: ESP-IDF `v5.5.4` build and flash passed,
+  capability smoke passed with 40 exchanges, review-scenario smoke passed with
+  8 scenarios, manual visual inspection passed for basic review, dense tags,
+  control escapes, Unicode fallback, and request-error screens, and manual
+  button observation passed for long-press approve and reject paths. The
+  read-only security-fuse audit reported secure boot, flash encryption, debug
+  lock, download mode, and manual flash-encryption download as production
+  blockers. A hard reset was required after the fuse audit before app-protocol
+  smokes resumed.
 - Regression tests require the ESP-IDF console defaults to use native USB
   Serial/JTAG as the primary console; secondary USB logging is not enough for
   input-driven protocol smoke tests.