docs: the v2.11.1 release gate, on both boards, and the bench as it stands

[angeloINTJ]

The release gate of AGENTS.md §2 for v2.11.1, recorded in the changelogs and the three verification logs, and AGENTS.md §1 brought up to the bench as it stands since today. The gate ran on the images release-ota.yml signed on main a8b7de5 (run 37259233322, approved by the maintainer): the Pico W and the over-the-air steps of the Pico 2 W on 2026-10-05, the Pico 2 W's soak and web suite on 2026-10-12, after the board had been off the bench for a week.

The candidate

Each of the four images verifies against keys/: v=0, release signer serial 1, security version 1. Its image part is byte for byte the local build of a8b7de5. The Pico 2 W's is its firmware_ota.bin, flagged for trial. Rebuilt today from this branch, the four images came out byte for byte the same, and the Pico 2 W's partition table is v2.11.0's.

image	signed .bin	sha256 (first 16)
release	1,033,357 B	e05f93910ff1b340
alpha	990,621 B	815fdba193650311
Air	1,031,485 B	6aa3559d86c45db2
Pico 2 W (releasetwo)	997,417 B	1daeff0caa0701b6

The factory .uf2, made from the artifact by tools/release_manifest.py as the publish job will make it: 1,995,776 B, sha256 f0de8055455821b8.

The Pico 2 W

The bench board, an RP2350 A2, started from the published v2.11.0 in slot B, which trusts the release root alone (configuration CRC AC385271, 555 values).

step	result
candidate over the air (2026-10-05)	stage in 16.7 s; back 39.3 s later from slot A, on trial; kept 50.4 s after that; 555 values, 0 differ
refused, the board left running on its slot	the candidate with one byte changed (v=9); an image signed by the bench key (v=12, SIG_SCOPE)
candidate over itself, slot A to B	stage 16.7 s, back 24.9 s, kept 60.4 s later, 0 differ
factory .uf2 dragged onto BOOTSEL by the maintainer	up on 2.11.1 from slot A, not on trial, 0 differ. The buy of the update over itself erased slot A's first sector, so A could boot only if the drag had written it
web suite on the candidate, as its admin (2026-10-12)	67 passed, 0 failed, 1 skipped (it needs an account without admin)
soak, 30 min (2026-10-12)	119 reads: 0 restarts, five sensors valid in every sample, free heap 299,876 to 299,908 B; 4 lost their chunked framing (#189, under Known)

The soak of 2026-10-05 did not count. It was cut at 6.3 min, when the board left the bench, and every sample had the GP0 probe in error: the probe on GP0 had been swapped for the Pico W's while the boards changed places, and the slot sat in the mismatch quarantine (Hardware mismatch, by design: a slot reads only the ROM it was paired with). Today the maintainer chose to adopt the probe that is there: POST /api/action?op=sensor_accept&slot=0, the page's Adopt the probe wired here. It answered {"ok":true,"epoch_moved":true}, and the next /api/status, 0.1 s later, read the probe (23.56 °C): the reload of #255 on the RP2350. Slot 0 sits on GP0, so this does not exercise the other half of that fix, a slot on a GPIO of another number. In /api/config only the slot's hwid changed (STM0009 → LIB_SENS: this board has no calibration curve for that probe).

The RESET wire stayed on the RUN pin for this soak, against AGENTS.md §1; the maintainer kept it on. The serial of the board was recorded throughout. No restart came, and the serial printed nothing in the 30 minutes.

The Pico W

The bench board with the touch display and five sensors, from the published v2.11.0 with the bench's configuration, a throwaway admin account and the web on :8080. That start is the v2.11.0 gate's own, written by USB and read back, then updated over the air to v2.11.0 with its .bkp put back. The board's flash was dumped first (two equal reads) and written back at the end, byte for byte.

step	release	alpha	Air
v2.11.0 → candidate over the air	stage 200 v=0 in 35.6 s	35.0 s	35.2 s
/api/config + users, network, alarms, sensors	567 values, 0 differ	558, 0	558, 0
.bkp back, dump	71/75 files identical, system.bin identical	71/75, identical	71/75, identical
slot against the signed file	identical, trailer after it	identical but the BTstack bank (0xee000)	identical but the BTstack bank (0xf8000)
candidate over itself (v=0 from the candidate)	35.7 s, 0 differ	36.4 s, 0	33.6 s, 0

The four files that differ are the log, its previous file and two of the history's, which move while the device runs. The Air's air.bin went with the update (idle 777 → 300) and came back with the .bkp (777).

On the release only:

• Refused, 422, the configuration intact before and after a reset: the local unsigned build (v=8), the Air's signed image (v=7), the Pico 2 W's signed update (v=6, which the Files page now explains) and the candidate with one byte changed (v=9).
• Cut uploads: one cut at 400 kB, then a reset; then the same with the filesystem filled to its last 8 KB and emptied before the reset. The configuration intact both times.
• Back to the published v2.11.0 over the air, and up again: v=0 both ways (35.6 s each), 567 values equal; the telemetry queue rebuilt at each boot from the other version's cursor.
• Web suite on the candidate, as the throwaway admin: 67 passed, 0 failed, 1 skipped.
• Soak, 30 min, with the RESET wire off the RUN pin: 120 samples, 0 restarts, 0 failed requests, five sensors in every sample, free heap 55,336 to 55,432 B.
• With the wire on, over six hours, the board restarted itself four times, none through the watchdog (no SYS_BOOT, no WATCHDOG_REBOOT line). One came 33.8 s into an update from the board's arrival state on v2.10.0: it came back on v2.10.0 with its configuration identical byte for byte, as the cut step expects, and the same update passed on the next try. AGENTS.md §1 now says this is not only a soak's problem.

The bench changed today

The maintainer moved the PicoHand from its Pico to a Pico W, the board that was the target until 2026-10-05; the old Pico went to another project and is still on this PC's USB. The Pico 2 W is now the target, with the five sensors and the TFT. AGENTS.md §1 says so, with the three boards' USB ids and serials as udev reports them:

board	USB	serial
PicoHand, on a Pico W	2e8a:f00a	E6642815E34C1824
target, the Pico 2 W	2e8a:f00f	6A73539D612923CA
the old hand, off the bench	2e8a:000a	E660C062131E3E27

Ten scripts in tools/ still look for the target as a Pico W, by E6642815E34C1824 or by the glob usb-Raspberry_Pi_Pico_W_*, and both now land on the hand: a 1200 bps touch there puts the hand in BOOTSEL. Three (air_test_suite.py, bt_auth_test.py, rig_validate_history_clock.py) look for the hand by the old hand's serial, which is still plugged in. Setting SIMUT_TARGET_SERIAL and PICO_HAND_SERIAL does not help: they build the by-id path with the old model names. AGENTS.md §1 says not to run them until they learn the new bench; that change is code and follows the release. The hand answered PONG, VERIFY gave OK on both lines, and its firmware is the one in tools/PicoHand/.

Found on the way

• Four of the soak's 119 reads lost their chunked framing (/api/status: a chunked reply occasionally loses its framing (0.15–0.6 % of reads) #189, under Known), where the v2.11.0 soak on this board lost none of 120. The soak counts them and reads again, and fails only on a restart or a missing sensor, as since /api/status: a chunked reply occasionally loses its framing (0.15–0.6 % of reads) #189. The 0.15–0.6 % under Known was measured in a tight loop on the Pico W; this soak reads every 15 s on a kept-alive session, on the Pico 2 W, and what makes the framing break is still not known. No file of the reply path changed since v2.11.0: git diff --stat v2.11.0 a8b7de5 -- src/ lists the panel, the sensors, the access point, the PIN keypad and the version.
• Adopting a probe, or sensor_wipe, does not start the slot's history anew. Both stamp provisionEpoch, and nothing in src/ or the web UI reads it (grep: five writers, the config table, no reader). The history keys every record of a slot by the slot's current hwId (WebManager_History.cpp:593). On the bench, after today's adoption, slot 0's readings of 2026-10-04, taken by the board's own probe as STM0009, come back from /api/history_multi as tLIB_SENS. Chapter 26 of the manual says sensor_wipe "grava a hora atual como início do histórico do slot", and docs/API_POST.md says it erases the slot: neither is what happens. Under Known.
• After a boot, a probe that is not the slot's can have its first reading recorded. The DS18B20 read path checks the ROM when totalReadings % 5 == 0, after the increment: from the fifth read on. On the bench the board booted at 17:25:56.8 with the swapped probe on GP0; the history's record of 17:26:17 holds 23.38 °C for slot 0, and the records of 17:27 to 17:34 hold nothing for it, the quarantine. Under Known.
• The adoption itself costs no history. In V5 the schema holds no hwId, and a slot is matched by its GPIO (AppManager_HistoryAlarm.cpp:383): the records went on from 17:35 with the new probe, in the same day file.

All three are older than this release, and none of them moves the gate: a fix needs a candidate of its own.

Docs

• CHANGELOG.md and CHANGELOG.pt-BR.md: the v2.11.1 The bench / A bancada section for both boards, the way back to v2.11.0 over the air marked as checked on the Pico W, two sensor findings under Known, and the release date moved to 2026-10-12, the day it is published.
• docs/VERIFICATION*.md ×3: the two gate rows.
• AGENTS.md §1: the bench as it stands, the scripts that do not know it yet, and not only in a soak for the RESET wire.
• README*.md ×3, docs/_manual/cap01-o-simut.md, docs/_manual/ap-c-versoes.md: the release date; docs/MANUAL.pt-BR.html regenerated by tools/build_manual.py, which changed only those three dates.

Checked here: check_angulo.py, check_readme_numbers.py, check_flash_budget.py --table, gen_logcodes.py --check, check_authz.py, check_license.py, gen_notices.py --check and build_manual.py --check, all clean.

🤖 Generated with Claude Code