2026-10-27 bench task-42 verdicts -- UI-landed image, 4 counted reset-only circles
identity: fw build: Oct 26 2026 22:52:09 suite=NONE dstr=off   (suite=NONE => product build; dstr=off => non-destructive)
coordinate: HEAD b24b2b5f; firmware .c/.h identical to b623a406..HEAD (mechanically checked: no commit touched .c/.h after b623a406,
            working tree had no dirty .c/.h; the only source newer than the .hex is test/host/console_log/console_log_test.c,
            a HOST unit test not present in the uvprojx) => main-tree .hex IS HEAD firmware, no rebuild needed.
reporting rule (agreed with lead): flash boot and reset-only circles are counted SEPARATELY. A circle that had a flash in
            front of it does NOT join the "consecutive reset-only" count (task-32 rule 4), and the 01:34 attempt is excluded
            twice over: it had a flash behind it AND it captured 0 bytes (measurement failure, no data exists to count).

BOOTS REPORTED:
  flash boot x1  (00:25:06, @test rc=0, NOT in the reset-only sequence): 9 required markers incl. identity stamp,
       forbidden 0, banner x1, boot->net init 777 ms, readback "No difference found".
  reset-only x4  (01:46-01:52, the sequence proper):

boot_r1_gen272  verdict=FAIL  banner=0 cause=""  forbidden_hits=0  []  boot->net_init=n/a
      heap: -   ui: -   protect: -
      prot_set: -   comm: -   CONSOLE dropped: absent
boot_r1_gen273  verdict=PASS  banner=1 cause="software (NVIC_SystemReset)"  forbidden_hits=0  [PROT=91px nb=0 head_bad=0] [NAND_FTL=56px nb=0 head_bad=0] [APP=57px nb=0 head_bad=0]  boot->net_init=745 ms
      heap: heap free=15624 min_ever=8464   ui: [STACK] ui peak_used=4188/16384 free_min=12196 (74%)   protect: [STACK] protect peak_used=492/2048 free_min=1556 (75%)
      prot_set: prot set loaded (/prot_set.bin)   comm: comm init: OK (ca=1 port=2404)   CONSOLE dropped: absent
boot_r2_gen274  verdict=PASS  banner=1 cause="software (NVIC_SystemReset)"  forbidden_hits=0  [PROT=91px nb=0 head_bad=0] [NAND_FTL=56px nb=0 head_bad=0] [APP=57px nb=0 head_bad=0]  boot->net_init=786 ms
      heap: heap free=15624 min_ever=8464   ui: [STACK] ui peak_used=4188/16384 free_min=12196 (74%)   protect: [STACK] protect peak_used=492/2048 free_min=1556 (75%)
      prot_set: prot set loaded (/prot_set.bin)   comm: comm init: OK (ca=1 port=2404)   CONSOLE dropped: absent
boot_r3_gen275  verdict=PASS  banner=1 cause="software (NVIC_SystemReset)"  forbidden_hits=0  [PROT=91px nb=0 head_bad=0] [NAND_FTL=56px nb=0 head_bad=0] [APP=57px nb=0 head_bad=0]  boot->net_init=733 ms
      heap: heap free=15624 min_ever=8464   ui: [STACK] ui peak_used=4188/16384 free_min=12196 (74%)   protect: [STACK] protect peak_used=492/2048 free_min=1556 (75%)
      prot_set: prot set loaded (/prot_set.bin)   comm: comm init: OK (ca=1 port=2404)   CONSOLE dropped: absent
boot_r4_gen276  verdict=PASS  banner=1 cause="software (NVIC_SystemReset)"  forbidden_hits=0  [PROT=91px nb=0 head_bad=0] [NAND_FTL=56px nb=0 head_bad=0] [APP=57px nb=0 head_bad=0]  boot->net_init=776 ms
      heap: heap free=15624 min_ever=8464   ui: [STACK] ui peak_used=4188/16384 free_min=12196 (74%)   protect: [STACK] protect peak_used=492/2048 free_min=1556 (75%)
      prot_set: prot set loaded (/prot_set.bin)   comm: comm init: OK (ca=1 port=2404)   CONSOLE dropped: absent

NEGATIVE CONTROL (proves these PASSes are not vacuous) -- same verifier, same flags, pointed at the pre-fix defective capture:
rc=1
[FAIL] exact line: \[[^\]]*\]\[PROT\] uncalibrated -> protection blocked \(UA/UN/IA  hits=0 lens=[] loose_neighbours=0
[FAIL] exact line: \[[^\]]*\]\[NAND_FTL\] Initializing NAND FTL\.\.\.  hits=0 lens=[] loose_neighbours=1
       inexact neighbour: 26-10-26 08:37:07][NAND_FTL] Initializing NAND FTL...
VERDICT: FAIL

EXECUTIVE-ACTION PAGE GATE, PROVEN ON REAL HARDWARE (not simulator):
  --to clear -> refused before ANY key was injected (no trace file was even written), rc non-zero:
      raise RuntimeError("刻意跳过执行类页面 " + pid + "：进入后第二次 ENTER 即真执行"
      RuntimeError: 刻意跳过执行类页面 clear：进入后第二次 ENTER 即真执行（强制复归 = 复归保护位并写 SOE；清除记录 = 清 SOE/运行/操作记录）。显示正确性请走模拟器黄金参考；确需真机下钻才加 --allow-exec-pages。
  --to reset -> same refusal, same reason:
      raise RuntimeError("刻意跳过执行类页面 " + pid + "：进入后第二次 ENTER 即真执行"
  reason text names the exact stacking hazard: entering the page + a SECOND ENTER executes
  (强制复归 = reset protection bits + write SOE; 清除记录 = clear SOE/run/op records).
  clock page navigation (9 steps, keys e,l,d,d,d,d,e,e,e -- every ENTER in a menu context): reached, kind=PAGE, ink=3018

FINAL READBACK (last hardware action, after every capture, since -CmpFile resets the target):
  rc=0
  CMP: MDK-ARM\STM32F407-Demo\STM32F407-Demo.hex vs device flash @ 0x08000000  (NOTE: connecting resets the target)
  No difference found.

INCIDENTS AND SELF-REPORTED MEASUREMENT ERRORS IN THIS WINDOW (kept because they are the useful part):
  1) 01:34 first attempt captured 0 bytes. Root cause NOT the board: the long-running serial-assistant daemon
     (pid 18020, uptime 156589 s) had DIED, and "serial_tool.py status" auto-spawns a fresh daemon, so status kept
     answering happily with port.ready=false / rx_lines=0 / 58-byte log. Verified afterwards: the board had booted
     normally from that very reset (uptime t=386840 ticks matched 01:34:08 and PROF lines streamed).
     => Rule for every window: run "open" and assert port.ready AND watch rx_lines grow BEFORE the first reset;
        never assume the port state left behind by @test survives (it does not survive an hour).
  2) My own forbidden pattern "Fault" is a false red: it substring-matches "de*fault*" and hit two innocent lines
     ([FTP] using factory default password / [STACK] default peak_used). Replaced by the explicit fault tokens.
     Any Fault dump starts with [ERR] anyway (platform convention), so bare "Fault" added nothing but noise.
  3) My harness parsed the verifier's --json from stdout+stderr concatenated; on a non-zero exit that breaks parsing.
     Fixed by keeping the streams apart. Also "serial_tool.py log" returns JSON, not plain text (first attempt
     filtered lines starting with "[RX]" and silently got zero) -- that is the second time tonight I assumed an
     output format instead of reading it.
  OBSERVATION (not a verdict, not my scope): the device wall clock reads 2026-10-26 18:00:35 while the host logged
  2026-10-27 01:5x+08:00, i.e. ~8 h behind local and a few minutes off true UTC; firmware log stamps show the same
  8 h offset against the daemon stamps. Frame evidence: 20261027_bench42_ui_clock_page.png. Left for the lead to
  route (RTC/timezone semantics), with no claim attached.
