TRACKER — Historical closeout: owner actions and acceptance sessions

[timohueser]

Current historical closeout

The original source waves remain complete. New planner and onboarding code cleanup is outside this tracker.

Current open owners:

Work	Issue
Production key, update host, first release and real OTA	#773
Requested USB PID awaiting external allocation	#993
Upstream stock-TrouBLE lost-bond fix	#481
Captured import licences and second provider	#1946
Landmark publication, fixture re-pinning, maps and hut/tower acceptance	#2026
Remaining desktop physical/Windows acceptance	#994
Real bonded-reconnect diagnostics capture	#2086
Exact watchdog-expiry investigation	#2128
Deferred features, including landmark refresh	#1518

#1805 is closed: its source stages are merged; publication/acceptance remains in #2026 and refresh is deferred in #1518. #993 already has an open allocation request; do not request it again.

#1830, #1892, #1928 and #2048 are closed source records. Their unperformed S1/S5 checks and owner steps below remain tracker obligations; the closed issue state is not proof that those checks pass. In particular, retain Peak View text-only/Sources/multiple-article checks, separate reference-archive publication, pending owner requirement wording, and real-riding map/terrain/theme checks. Auto-theme is deferred in #1518; it is not active closeout implementation.

The recorded S3 result remains complete. S4 phone/storage gaps and the decisive #2128 repeat remain unpassed. Preserve the existing evidence limits and owner deferrals. Do not reopen the historical ride-loss issue #2107 without new actionable evidence.

The newer three-day trip/journal acceptance belongs to #2056. Device onboarding acceptance belongs to #2214. Planner code cleanup belongs to #2385; planner acceptance belongs to #2236.

Close this tracker only when each retained owner action/session is complete or explicitly deferred to an open named owner. Issue count is not a close condition.

Historical scope and evidence — use the current work above

This tracker superseded #1448 and closed the old source backlog. The original waves are complete. Do not restart them. New product work was added after this tracker began. The newer routes, trips and rides programme is owned by #2056 and is outside this historical closeout.

Audited on 2026-09-23 against every open issue, its recent comments, merged pull requests and origin/develop at 6278e6aa. The retained session records are the Sol closeout, S4 hardware record, and overnight continuation.

Current remainder

Kind	Issues	Next action
Owner or external action	#481, #773, #993, #1892, #1928, #1946	Upstream trouble-host PR; signing key, GitHub environment and first release; pid.codes PR; SYS-034 criterion 3; reference archive publication and the already-filed skyline requirement suggestion; Komoot authored-part licence confirmation and a redistributable bikepacking.com capture.
Landmark content pipeline	#1805, #2026	Local Swiss preparation is complete in #2095. Publish and re-pin the content, rebuild dependent maps and run the remaining content checks under #2026. L4 refresh mode stays deferred until a refresh needs it.
Physical acceptance	#773, #994, #1830, #1892, #1928, #2048, #2086, #2128	Run only the unmet checks listed below.
Backlog	#1518	Keep as the single deferred-feature backlog.

#2048 is partly complete. PR #2053 merged theme persistence, paired Light/Dark map styles, OBCM v19, themed frames and a published Baden-Württemberg v19 catalogue. Auto mode still needs a product decision. Peak View and normal riding still need the relevant on-glass checks.

#1892 no longer needs a production re-bake. PR #2053 published all 215 Baden-Württemberg cells as OBCM v19 and the live catalogue-version guard passes. The remaining gates are the owner rewrite of SYS-034 criterion 3, the resulting coverage-plan proposal, and the riding-view check.

#1928 no longer needs a general production map/terrain re-bake. PR #2053 rebuilt and published the live v19 map and terrain catalogue, including DGM1 summit corrections in 27 terrain cells. The separate reference archive still needs publication and configuration. The separate Peak View reference-photograph fixture is published through #1954. It is skyline evidence and does not close article UI acceptance. The open skyline-accuracy suggestion still waits for the owner to create the requirement; an agent can then propose its coverage plan.

#2107 is closed by the owner. Its unexplained historical ride-402 loss remains unexplained; later accepted recovery tests do not retroactively explain it. Do not reopen it unless new evidence establishes an actionable defect.

#2128 has a complete source audit. It identified a plausible probe-rs programming path but cannot distinguish when the watchdog expired. The only remaining decisive investigation is the bounded hardware repeat already specified in that issue. The neutral reset diagnostic from #2130 was later reverted by #2120; #2156 restores the neutral diagnostic and closes #2155. It has independent GPT-5.6 Sol review and passing selected CI. The merge is aa1734f89eb9c7559194f7e6eab08fdf83960229. This does not explain the historical reset timing.

The accepted scope decisions still apply: no power-cut rig or manual power cuts (D1); Windows stays a real-machine S6 check (D2); no marginal-card programme; no DACH bake or >4 GiB requirement (D3); ride-time estimation stays in #1518 (D4); settings codec versioning stays (D5); Peak View photos were accepted and delivered (D6); AR4 and software-complete shells stay closed with physical checks retained here (D7-D8); landmark refresh mode L4 stays deferred until a refresh needs it (D9); and the map-polish and #1518 refresh decisions remain complete (D10-D11). The full decision record remains in the earlier tracker text and comments.

Owner actions

1. Firmware release: production key, update host and end-to-end OTA acceptance #773: rotate the release signing key, create the protected release environment, configure its secrets, and run the first verification-console release. The U1-U6 source phases are merged.
2. USB PID: wait for B1CE allocation, then update shipped identifiers #993: submit the pid.codes request, then update the three repository locations named by the issue after allocation.
3. [bug] Forget phone → advertising⇄connected reconnect flap until the device is removed in iOS Settings #481: file the prepared trouble-host issue and pull request upstream. Keep the repository on stock trouble-host until the upstream result warrants a dependency update.
4. EPIC — Crest planes: finish the pipeline and widen the reference registry #1928: publish the reference archive to R2 and set OBC_REFERENCE_ARCHIVE as documented. The live v19 production re-bake is already complete.
5. Captured Komoot and bikepacking.com waypoint imports, through to a drawn waypoint chip #1946: confirm the licence for the authored part of the existing Komoot fixture. Then provide a redistributable bikepacking.com GPX export with waypoints and choose its fixture location. The Komoot fixture and coverage are merged, but its canonical README still marks the chosen route and five waypoint names as unconfirmed pending the owner.
6. Epic: Settlement names on the map with bounded label placement #1892: rewrite SYS-034 criterion 3. An agent can then check and submit the coverage-plan proposal.
7. Dark mode: ship the Lantern theme, persist it, auto-toggle, dark map style #2048: choose the Auto-theme trigger and override model before implementation.

Independent work without the board

The capture recipe is corrected in #2160, which closes #2158 after separate Sol review and passing CI. A bounded frozen fallback case has byte-identical normal and photo-request outputs from the same-source development and release compilers. This is compiler compatibility evidence, not the final country reproducibility check. #2163 closes #2162 and limits later photo-request rounds to the affected candidates. It has separate Sol review and passing selected CI. #2095 owns the recorded compiler transitions and remaining data validation.

• Landmarks: prepare local Swiss capture for expanded categories #2095 is complete and closed. One retry resolves all 17 transport failures. Two fresh offline compiles produce byte-identical 1,331-file trees with 1,453 records, 2,492 language variants and 1,330 photos. A separate Sol reviewer accepts provenance, completeness, all category counts, resource limits, and actual hut/tower sources. Final evidence. The capture and outputs remain local; publication, re-pinning, map builds and actual-content UI acceptance stay in Landmarks: publish Swiss content, re-pin maps and verify hut/tower cards #2026. This landmark capture is separate from the remaining Peak View article checks in S1.

The #2056 routes, trips and rides tree has current owners and active pull requests. #2092 is complete through merged PR #2154. Do not absorb or duplicate that work here. #2125 needs the new piezo board. #2048 has recent implementation ownership; do not duplicate it.

Acceptance sessions

The detailed accepted evidence remains in the linked session comments. Pending checks are listed below. S3 is retained as a completed session.

S1 — board evidence sweep

Accepted S1 record.

• Run the same-ID route-replacement check from closed AR4 — Firmware runtime: explicit RideRuntime state machine and a glanceable board hardware module #1262. It was the only AR4 row that the S1 J3 failure made unreachable.
• Peak View: verify a text-only article, Sources, and a map with multiple article-bearing peaks. The linked EPIC — Offline Wikipedia articles and photos in Peak View #1830 S1 record already accepts opening, linked text/photo, unlinked peaks, Back, retained selection, scratch reuse, language change and stack cost.

The deep_ride_high_water measurement and #2027 re-pin pass at 31,340 / 45,080 B. Receiver startup, late fix, reset recovery, wake rate and frame latency pass. S1 measured four no-path N5 plans and their release, then observed a clean arena handoff with no allocation fault or ownership warning; it did not inject an allocation fault or time a successful board path. #1400's later source-and-evidence closeout accepts N5 as complete, so those unperformed variants are not retained as new tracker gates. The map upload smoke and its map/terrain reads pass. Do not repeat these checks only to satisfy the old wave text.

S3 — update install and rollback — complete

Second run; final third run.

• Accepted in the second and third S3 runs: USB staging and arm, install, trial confirmation, a forced-failure install, rollback to the previous bytes, both extent lists in the boot-state page, post-rollback vectors, catalogue preservation, and the obc-boot size guard.
• The final third run verifies the obc-boot: grant the VPR secure access the FLPR lifecycle needs #2047 fix with four installs and one rollback on the unmodified shipping bootloader. Keep this evidence; do not schedule another S3 run.

Warm reset, active J3 interruption and unrelated-object preservation also have accepted evidence in S4. Do not repeat them as FS11 source work.

S4 — phone and storage

• Run OTA end to end after key rotation: release candidate, manifest, app notification, download, BLE stream, on-glass confirmation and trial boot (Firmware release: production key, update host and end-to-end OTA acceptance #773).
• Run Forget phone through the current iOS client. Keep the upstream reconnect flap in [bug] Forget phone → advertising⇄connected reconnect flap until the device is removed in iOS Settings #481.
• Complete archive-receipt interruption/retry, duplicate handling, remount survival and changed-source refusal; then run BLE and USB v4 operations per object kind through the real clients (closed EPIC — Ride domain: durable retention metadata and final closeout #1398 and FS10 — Finish v4 client acceptance and runtime store convergence #1392 acceptance).
• Capture a real bonded reconnect and confirm the fix(ble): keep bond secrets out of board logs #2097 diagnostics expose state without key material (BLE diagnostics: verify the merged secret-log protection on hardware #2086).
• Test a replacement card with a new StoreId when a second prepared card exists.
• Repeat Investigate watchdog flag after app-only shipping restore #2128 only with the issue's required flash-routine timing, core state, first-boot boundary and RESETREAS capture.

Cold boot, cardless boot, original-card recovery, physical J3 interruption, full USB retry/readback, real iPhone identity, durable warm-reset recovery, same-card hot recovery with paused input, final Save/readback and protected-object preservation already pass in the S4 record. Sustained-input hot recovery remains outside the accepted paused-input result; retain it as an explicit acceptance gap if the product requires it.

S5 — one real ride

• Record one real-GPS ride with a Visit, arrival, dwell, return and rejoin; check moving navigation, power use, buttons and readability (closed RA13 — Deliver a real-data simulator build and device-test handoff #1748).
• Restart mid-route and verify navigation resume (closed Offer navigation resume after restart for ordinary routes and Assistant journeys #1860).
• Check settlement names, crest contours, map icons and Light/Dark map styles at riding zoom (Epic: Settlement names on the map with bounded label placement #1892, EPIC — Crest planes: finish the pipeline and widen the reference registry #1928 and Dark mode: ship the Lantern theme, persist it, auto-toggle, dark map style #2048).

S6 — Windows

• Download the CI desktop build, launch the real frontend, connect the device, confirm enumeration and upload one route (Desktop: Windows launch and physical USB acceptance #994). Add only actual Windows setup requirements to apps/obc-desktop/README.md.

Close rule

Close #1978 when the owner actions and acceptance sessions above are either complete or explicitly deferred to named issues. Keep #1518 open. Do not use the total repository issue count as the close condition because new feature programmes continue to add legitimate issues.

[timohueser]

Overnight run 2026-09-22 — waves 1 to 3, software half

One Opus implementer per task in its own worktree off origin/develop, one adversarial Opus reviewer per pull request, a delta check after each fix round, merge on green CI with every thread resolved. No board, no phone, no owner action was used.

Merged (21)

PR	Issue	What landed
#1982	#1944	observer on a NODATA posting uses the measured eye
#1986	#1983 (from the N2 audit of #1400)	stale climbs and waypoints dropped on a route switch without a reader
#1990	#1946	Komoot import through to a drawn waypoint chip; obligation still open for bikepacking.com
#1985	#1815 1.6	UI docs page true to the code; vocabulary guard trimmed
#1989	#1892	icons on the shared point placer; reader tests build plain
#1988	#1805 L1	landmarks are an artifact class of the bake tree
#1981	#1501	resident ceiling re-pinned (CI 313,264 B) with a 4,096 B band both ways
#1992	#1166	storage breaker: limit 2, half-open after 30 s, refusals never count
#1993	#1433	host card create is a no-clobber rename on every non-wasm platform
#1991	#1391	FS9: update and rollback are flat-store objects; FAT sideload gone
#1995	#1815 1.2	one sheet engine for both drawers, −181 lines
#1999	#1177	upload smoke as a manual suite driving the shipping USB client from Node
#2003	#1805 L2	cell bake merges every intersecting region's landmarks by QID; global file flag gone
#2001	#1815 1.5	one fitter, .. ellipsis, pixel budget inside the fitter
#2002	#1815 1.4	dead UI facts deleted, −85 lines; depth-descent test
#2005	#1398	receipt and metadata observation seam; R5 deletions
#2004	#1860	Resume navigation after a restart for an ordinary route
#2010	#1815 1.1	wrap counts characters; three clipped strings re-authored; 12 new language frames
#2008	#1805 L3	OSM-first discovery; batched, back-off-aware capture
#2014	#1815 2.1, 2.3, 2.4	hold sample carries both buttons; exact Statistics key fields; one base-screen helper
#2016	#1805 L5 code	verify and publish know the landmark artifact class; catalogue carries the credit

Closed: #1944, #1983, #1391 (to S3), #1860 (to S5), and every sub-issue above. #1400's N2–N4 box is ticked; #1398's R5 box is ticked.

Stopped here, and why

• FS11 (FS11 — Remove remaining FAT users and prove storage acceptance #1393) waits for session S3: deleting FatFs before the flat-store install is seen on glass would leave no update path if FS9 has a defect.
• L5 publish run and the large-map session need the owner's R2 publish and the published BW catalogue.
• UI closeout 1.3 — copy-fit gate on the real render path #1996 copy-fit gate: there is no Surface seam at frame level; four costed options, owner's pick.
• The quick drawer's Settings row stacks Settings to MAX_DEPTH #2006 quick-drawer Settings pushes without bound (found by the depth test); reviewer notes cards are deferred, not lost.
• Map polish: intermediate-zoom buildings and stable dash patterns #1894: dashes were already fixed by d848e07b; buildings are a one-number preset choice (V1 recommended), 24 PNGs in the scratchpad.
• Peak articles: more coverage, a photo per article, and photos of the peak rather than from it #1956: counts posted; decision D6.
• EPIC — Ride domain: durable retention metadata and final closeout #1398: the retention stamp writer was removed with the retention sweep in 9c7cc0ce, so the R4 line "expiry requires that nonzero stamp" and the ticked automatic-retention box describe removed code. Owner decides whether the writer returns or the text changes.
• Hazard: clean-r2 on develop purges the whole bucket, including the terrain reference archive, until reference: per-tile country ingests, and an archive no bake can purge #1979 lands. Do not run it before then.
• Leftover, trivial: BLETransport.swift still names the uploaded object UPDATE.BIN.

Owner items unchanged

The eight actions at the top of this issue and decisions D6, D10, D11 plus #1996, #2006 and the #1398 stamp question.

[timohueser]

Session S1 — 2026-09-22

nRF54LM20-DK, one serialized probe session (tools/board.py), buttons and fixes over the J-Link
VCOM. Worktree at 0ff49e0c. Release ELF dfd54c18…fceb; debug-uart ELF 17cb922a…e1bc.
Card at the start: store dc2b0e053244229207bd15bb4812750e, one map object — object 1 revision 2,
"Box — Baden-Württemberg", 160,410,112 B.

Check	Result	Evidence
#1177 upload smoke: connect	pass	LIST answered; store dc2b0e05…750e
upload	pass	grimsel-demo.obcm, 10,093,056 B, sha256 6a59043a…e47f, through the shipping sendMapBytes
verify	pass	STATUS, the catalog entry and a whole GET agree; every other object still at its revision, length and CRC
reboot	pass	flat: map object 1 revision 3 open — 10093056 B · map: streaming from SD; bbox lon[7392879..8422373] lat[46369864..46695523] · map: terrain mounted from the §1.3 region (7807488 B)
reverify	fail — blocked on hardware	After the probe reset J3 does not return usable: absent from board doctor for minutes, then every open fails configuration error: device is not configured. Firmware says usb: device plane up. Only a physical J3 replug can clear it
two smoke-harness defects	fixed	PR #2028; without it the command cannot reach the first byte
#1501 deep-ride high-water	pass	31,340 / 45,080 B, on ride entry, reproduced on two boots. PR #2027 re-pins it (was 37,016 B from the FS8 spine)
release-image residual stack	pass	46,328 B; resident 313,096 B; poll frame 9,776 B; task body 4,816 B; boot chain 17,488 B. Margin over the new pin 14,988 B (floor 8,704 B)
#1836 Peak View opens on the board	pass	Menu ▸ Peaks; peak-view: first view 716 ms / generated 6,141 ms / ready 6,762 ms
linked peak, text and photo	pass	Mönch (the map's one association, 4 language variants, photo). Press in Browse → PeakArticle; Step → second text page; Step → LandmarkPhoto; Back → PeakArticle
peak without a link	pass	Press on an unlinked peak leaves Browse and opens nothing; 16 peaks walked
Back, and panorama scratch reuse	pass	PeakArticle → PeakView with peak-view: first view in 186 ms; no WARN, ERROR or fault in 1,100 s of RTT
retained selection	pass	one Press after that Back reopened the article: selection and Browse heading survived the article and the photo
language change	pass	Settings ▸ System ▸ Language cycled; the article still opens; the language was cycled back
text-only peak	not reachable	this map holds exactly one peak article and it has a photo
Sources	not verified	a second text page exists, but nothing names it in RTT and the glass cannot be photographed from here
Freiburg–Engelberg map with 204 peak articles	not reachable	it is OBCM v17 (obc inspect: "OBCM header: BadVersion"); the firmware reads v18, and it is not in the fixture registry. The production re-bake owns this
#1262 receiver absent through startup	pass	~10 min with no F line: one boot, no WDT, no panic, and no log line at all after t=1.35 s
valid fix after startup, and after a reset	pass	fixes injected ~10 min after boot were accepted; every walk starts after a run --preverify reset
warm reset mid-ride, recovery card	pass	RESETREAS=0x00000040; flat: §7.3 recovered a ride — object 381 revision 1, checkpoint 10, 0 B flushed + 340 B tail; RideRecovery; Continue resumed it; a later Finish committed 1,204 B
no watchdog reset loop	pass	one boot per reset; no WDT line in 1,100 s
wake rate	pass	idle with no fix and no input produces no log traffic at all
frame latency	pass	962 ui frames: render 3.4 / 33.7 / 64.2 ms (min/median/max), push 8.6 / 12.0 / 411.8 ms. 768 map frames: render 21.6 / 49.7 / 157.4 ms, push 8.6 / 8.6 / 52.9 ms. The 411.8 ms push is the first full present after boot
same-ID route replacement	not reachable	needs a product-cable upload; J3 is unusable, as above
#1400 planner timing and release	pass	four N plans: total_ms 57–117, released after 157–217 ms, each one released
arena handoff, allocation fault	pass	a Find a place search opened straight after a plan and returned; no arena-ownership warning, no allocation fault, no nav: cannot start a plan refusal in 1,100 s
a plan that finds a path	not reachable	grimsel-demo answers no-path for every pair tried, so no success-path timing from this session

The one blocking device finding

After the smoke's reset, J3 does not come back usable on this host. It first vanished from the
bus, then returned enumerated but unconfigured: selectConfiguration(1) fails with
configuration error: device is not configured, in a fresh process, with no other owner, while the
firmware logs usb: device plane up — 1209:0001 … HS bulk 512 B. It survived several later resets
and a reflash. The board README already names a related signature ("a plug that is never noticed").
This blocks the smoke's reverify and #1262's same-ID route replacement, and it needs a physical
J3 replug, which an agent session cannot do.

One DAP FAULT also appeared once, on the run --preverify right after the release reflash
(Failed to read register DRW at address 0xd0c → FAULT). The retry was clean. The README lists
this as "a USBHS core access escaped the VBUS gate".

Board end state

Shipping release image dfd54c18…fceb (0ff49e0), flashed and verified. Boot #137:
flat: catalog holds 1 map object(s), 8 route(s), **0 ride(s)**, 1 other, map object 1 revision 3,
terrain mounted, usb: device plane up. The Swiss map (grimsel-demo, Grimsel pass) and the eight
routes are on the card. Every ride this session made was finished or discarded and then deleted;
nothing else was written, and the card was never formatted. The UI language was cycled and cycled back.

Pull requests

• fw: re-pin the deep-ride high-water from a run on the current loop #2027 — re-pin deep_ride_high_water (closes the last Re-ratchet the board resident ceiling: ~15 KB stale since FS7.5, and deep_ride_high_water predates the loop rewrite #1501 item).
• test(smoke): let the upload smoke run against a real cable #2028 — the two device-smoke harness defects the physical run found.

[timohueser]

Large-map evidence — browser half, 2026-09-22

D3 is measured for the browser. The input is the live Baden-Württemberg catalogue,
generated_at 2026-09-18T20:40:55Z, catalogue SHA-256
31249ebaf394ac2937e9bcc4883cce3f56aabf158d616794ac5506cbc2f8b600: every published cell of the
region, 243 objects, 889,017,984 bytes, at the UI-default 256 MiB sort budget with full
verification. Full numbers are on #1162 (time and I/O) and #1503 (memory).

Question	Answer
Browser against native engine time	1.40× (46.5 s against 33.2 s) — the #1162 goal is roughly 2–3×
Same bytes out?	Yes. 887,781,376 B, SHA-256 2a31e0c0…83344a26, identical native and browser
Dominant I/O channel	Input reads: 27.6 GB logical in 6.60 M OPFS calls, 52% of ledger time
WASM linear memory	404,946,944 B, 0.954 × the estimator's engine term
Chromium process tree RSS, assembly	901,742,592 B peak
Registered memory gate	Not landed. Two pieces of plumbing are missing; they are named on #1503

Full verification passes on both sides: 215 cells, 3,010,861 navigation nodes, 3,872,546 edges,
41,031 POI records and 28 terrain cells. No tuning was done and no production setting changed. The
scope is one host, one region, a warm page cache and headless Chromium; the ratio is evidence, not
a universal figure.

Three limits are worth recording. performance.measureUserAgentSpecificMemory() refuses on this
host, so JavaScript heap stays unmeasured and process RSS is the substitute. Native verification is
slower than browser verification here (11.4 s against 6.6 s), which is the opposite of the expected
direction and belongs to native, not the browser. Switzerland is not needed: BW spills the sort
budget on its own, with 1.59 GB written to scratch and a 453 MB live-scratch peak.

The device half waits. Upload of the assembled BW map to the board, and its render, need the
J3 replug and session S3.

[timohueser]

Session S3 — 2026-09-22

nRF54LM20-DK, one serialized probe session (tools/board.py), buttons over the J-Link VCOM,
objects over J3 with the shipping WebUSB client. Worktree at eb8d95a5 (origin/develop).
J3 was back on the bus at the start of this session, so the S1 blocker had been cleared by hand.

Card at the start: store dc2b0e053244229207bd15bb4812750e, 11 entries — map object 1 revision 3
(grimsel-demo, 10,093,056 B), 8 routes, one kind-9 metadata object, and one open ride
(object 383, RESERVED, 0 B committed) left over from an earlier device session.

The install and the rollback did not run. The ceiling refuses today's image

obc-mkimage wrap refuses every image this tree builds:

$ obc-mkimage wrap --bin ship-release.bin --version ... --out UPDATE.BIN --sign-seed ...
obc-mkimage: image is 1796752 bytes, over the 1480000-byte slot limit — build too large to stage

Figure	Bytes
MAX_IMAGE_LEN (obc-dfu/src/image.rs, OBCU_Spec.md §1.1)	1,480,000
Shipping release image, eb8d95a5 (llvm-objcopy -O binary)	1,779,336
debug-uart image, same commit	1,796,752
App slot (0x8000 → SEMMC_STAGE, 1976 KiB)	2,023,424

The ceiling is 299,336 B below the shipping image and 543,424 B below the slot it claims to
describe. It has not moved since #616 set it on 2026-07-09, while the image grew past it.
Nothing catches the drift: firmware/tools/resource_guard.py gates board RAM, frames and the
32 KB bootloader slot, and no gate compares the app image with MAX_IMAGE_LEN; the repository
still has zero tags and zero releases, so release.yml has never wrapped a real image either.

Three gates read the same constant — obc-mkimage wrap, armer::scan (Oversize) and the
bootloader's install engine — so the number is also a normative clause in specs/OBCU_Spec.md
§1.1 and a value in obc-boot. Raising it is a gate number and a spec change, which CLAUDE.md
makes the owner's call, so this session did not raise it. Steps 2, 3 and 4 of the session plan
are unreachable until it moves: no confirm-and-arm, no trial boot, no rollback reserve, no
forced-failure rollback, and RollbackReserve (kind 8) was never allocated on this card.

Raising it to about 1,900,000 leaves ~244 KB of real headroom under the slot today. The owner
picks the number and the reason; a guard that fails the board build when the image passes it is
what keeps this from happening a second time.

What did run

Check	Result	Evidence
obc-boot size guard (untouched, eb8d95a5)	pass	16,636 / 32,768 B; ELF 5f91ea6a…c557
Base image on the board	pass	debug-uart ELF 1aa3f837…17ae, obc-fw-nrf54l 0.1.0+eb8d95a, boot #139, dfu: running image is eb8d95a (no installed record — an SWD-flashed board is a first install)
Scan with nothing staged	pass	Settings ▸ System ▸ Update ▸ Install update → input: Step 1 on DfuError; the catalog held no kind-7 object
PUT of a kind-7 update package over J3, shipping client	pass	PUT ok in 1143 ms: id=385 rev=1 len=1779336 crc=0x26771f89; flat/v4: link up (usb) — control 8208 B, stream 8208 B
LIST commits it with its revision	pass	id=384 rev=1 kind=7 (update package) flags=0x0 len=1779336 crc=0x26771f89 name="s3-raw-image", commitSequence 783 → 784
The armer reads the staged object out of the catalog (the FS9 seam)	pass	dfu: scanning the staged update package (running eb8d95a) → dfu: install failed (scan): the update package is not a valid update image (bad header) → dfu: the arm failed after the card was presented: Scan(Damaged). Minutes earlier, with no kind-7 entry on the card, the same path put up the error card without reading anything. The verdict now comes from the staged object's own bytes, so the scan is reading the kind-7 head through the store, not /UPDATE.BIN through FatFs. The card names the reason on glass and the log does not, so the two scans are told apart by the armer's D line, not by the card
Nothing armed on a refused scan	pass	no boot-state write, no reserve, the device kept riding
Confirm screen shows installed against staged	not reachable	needs a container the ceiling permits
Arm, rollback reserve, both extent lists, install	not reachable	same
Trial-boot confirm, catalogue intact after install	not reachable	same
Forced-failure rollback, boot-state vectors	not reachable	same. A reserve exists only after one successful install, so the failure case cannot be staged first

FS11 matrix (#1393)

Row	Result	Evidence
Warm reset (no transfer)	pass	RESETREAS=0x00000040, boot #142, flat: ReadWrite at sequence 784 — 12 entries, mount 4,606 us
Warm reset mid-transfer	pass	A 21,352,032 B kind-7 upload cut by board.py reset at 6,291,456 B. The host failed with transferOut error; the next mount carried no half object — commitSequence stayed 784 and the catalog held the same 12 entries. Free extents at that mount were 60,881 of 1,048,576 B against 60,853 at the session's first mount, so nothing leaked; other commits sit between the two readings, so the figure is not a direct measure of the cut's own reclaim
Unrelated objects preserved	pass	Every pre-existing entry identical before and after: map object 1 revision 3 / 10,093,056 B / 0x520fb508, the 8 routes at their revisions, lengths and CRCs, and metadata object 85 revision 22
Cold boot	not reachable	no hand on the power switch; both cables feed the board, so a software reset is a warm reset only
Cardless boot	not reachable	needs a hand on the card
Card replacement with a new StoreId	not reachable	needs a hand on the card
USB unplug mid-transfer	not reachable	needs a hand on J3

Notes for the next session

• The debug-uart build was used for everything that needs buttons; it is the only way an agent
  can drive the glass. The shipping release shape is what the board carries now.
• The shipping USB client exits only under process.exit: link.close() never settles in Node
  because a read loop stays outstanding. The smoke's main.ts ends its process, so this does not
  reach it, but any new tool on openWebUsbLink hangs after its last line without that.
• The open ride the card carried (object 383) was discarded through the RideRecovery card, which
  is modal and blocks every other screen. Its two ways out are Continue and a guarded Discard.

Board end state

Shipping release image baf5ca0c…dace (eb8d95a5), flashed and verified; the bootloader was
never reflashed. The card holds exactly what it held at the start, less the open ride: store
dc2b0e05…750e, map object 1 revision 3 (grimsel-demo), 8 routes, metadata object 85.
Both kind-7 objects this session created were removed (commitSequence 786). No ride is on the
card, nothing was formatted, and no object this session did not create was deleted.

[timohueser]

Assistant chord rule applied in #2039 (merged 2026-09-22, owner decision with the caveat that it may be revisited): the chord lands [Home, Map, Assistant] from anywhere and Back returns to Map; the deepest reachable stack is 8 with a free slot on every path. On the way it fixed a stranded detour plan and an unreleased route search that both the chord and #2020's Settings row left behind.

[timohueser]

Session S3 (second run) — 2026-09-22

nRF54LM20-DK, one serialized probe session (tools/board.py), buttons over the J-Link VCOM,
objects over J3 with the shipping WebUSB client. Worktree at 0429956c7 (origin/develop, which
carries #2040). J3 and J4 were both on the bus for the whole session.

Card at the start: store dc2b0e053244229207bd15bb4812750e, 10 entries — map object 1 revision 3
(grimsel-demo, 10,093,056 B), 8 routes, one kind-9 metadata object. No ride.

#2040 clears the ceiling, and a second wall stands behind it

obc-mkimage wrap now takes the shipping image: MAX_IMAGE_LEN is the app slot, 2,023,424 B, and
the release image is 1,779,784 B. The first install then failed on the board. obc-boot
hard-faults on every install and rollback entry — the bootloader writes the VPR00 secure alias
before anything grants it, so the write is a precise BusFault. It is filed with the backtrace,
the cause and two fixes as #2045. The board does not boot after that fault, because the Armed
page survives it; three resets and two reflashes repeated it.

Everything from "confirm and arm" below ran on a locally patched obc-boot (the one-line
change #2045 measures, never committed). The app, the armer, the install engine and the rollback
are the tree's own code. The board carries the unmodified origin/develop bootloader again.

Check	Result	Evidence
Build the release image	pass	ELF 1d561856…c02d, raw image 1,779,784 B, sha256 0bd57781…37af
wrap accepts it (the #2040 fix)	pass	container 1,779,912 B, image_crc32 0xDDE06204, Ed25519-signed; inspect = valid against the compiled-in release key
Signed with the committed test seed	pass	keys/test/obcu-test.seed. The release key is not rotated, so keys/obcu-release.pub still holds the test key and the device armer accepts it today (sig.rs pins that fact in a test)
A second image that differs visibly	pass	board crate patch version bumped to 0.1.1 in the worktree only; debug-uart shape, 1,798,976 B, container 1,799,104 B, version string v0.1.1-s3b. The installed image must be debug-uart: it is the only way an agent reaches the glass, so the staged shape is the debug one and the release shape is the end state
Stage as a kind-7 object over J3	pass	PUT ok in 1119 ms: id=386 rev=1 len=1799104 crc=0x23fa39dd, through the shipping openWebUsbLink + FlatStoreClient
LIST commits it with its revision	pass	commitSequence 786 → 787, id=386 rev=1 kind=7 (update package) flags=0x0
The DFU screen opens on the staged version	pass	Settings ▸ System ▸ Update ▸ Install update → the scan passes and the confirm card is up: input: Press on DfuConfirm. The glass cannot be photographed from here; the staged string is named by the arm's own line below
Install: the arm sequence	pass	dfu: arming from the scan's validated image · dfu: staged sEMMC blob (13636 B) to RRAM @ 0x001f6000 · dfu: wrote boot state (112 B) to RRAM @ 0x001fb000 · dfu: scan ok: v0.1.1-s3b (1798976 B, 1 extent(s)) · dfu: armed gen=1
Rollback reserve on a first install	correct, and not a reserve	dfu: no rollback: first install -- an unconfirmed trial will be accepted. An SWD-flashed board has no installed record, so the first install gets no kind-8 reserve by design (armer::arm, Rollback::FirstInstall)
The bootloader installs it	pass, on the patched bootloader	verify 1756 KiB in 2190 ms (802 KiB/s) · flash 1756 KiB in 16192 ms (108 KiB/s) · readback 1756 KiB in 1655 ms (1061 KiB/s) · WDT started for the trial boot (24 s) · install complete — jumping into the new image (trial boot)
The board boots the bumped version	pass	obc-fw-nrf54l 0.1.1+0429956 · dfu: running image is v0.1.1-s3b · boot #146. run --preverify against the 0.1.1 ELF programmed nothing, so the installed slot is byte-identical to the built image
Trial confirm	pass	boot-state page read back: Idle, installed = v0.1.1-s3b (signed header), last_outcome = Installed, generation 1
Catalogue after the install	pass	map object 1 revision 3 / 10,093,056 B / 0x520fb508 and the 8 routes unchanged; 0 rides
Second arm: the rollback reserve	pass	dfu: rollback reserve written (1798976 B raw image, 1 extent(s)) · dfu: rollback written to the reserve · dfu: wrote boot state (192 B) — 112 B with one extent list, 192 B with both, so both lists reach the page · LIST shows id=388 kind=8 (rollback reserve) flags=0x4
Forced-failure image	pass	the 0.1.1 image with the reset vector set to 0xF000_0001, re-CRC'd, wrapped and signed as v0.1.2-trialfail. It passes the armer (CRC and signature are its own), the bootloader installs it, and the trial boot faults before it can confirm — the shape obc-boot designs for, where the trial WDT owns the outcome
The bootloader falls back	pass	after the install the trial never confirmed; the 24 s trial WDT reset the board, and the next entry took the Rollback decision and restored the reserve
Boot-state vectors after the rollback	pass	Idle, installed = v0.1.1-s3b with sig_scheme = 0 — the reserve's unsigned snapshot header, not the signed staged one — and last_outcome = RolledBack, generation 1
The device boots the previous version	pass	obc-fw-nrf54l 0.1.1+0429956, dfu: running image is v0.1.1-s3b, boot #148; --preverify matched, so the restored bytes are byte-identical to the image the reserve held
The rider is told	pass	the one-time card is on the glass: two screen probes both answer DfuFailed
Catalogue after the rollback	pass	13 entries: the map at revision 3 with the same length and CRC, the 8 routes unchanged, 0 rides
The reserve after a rollback	retained, as #1991 says	id=388 kind=8 is still committed after the rollback. The next arm's batch removed it and published id=390 in the same commit, so an arm never leaves two
A reserve cannot be removed over the wire	by design	REMOVE on the kind-8 entry is refused (invalidRequest/badCombination); EntryFlags::RESERVED.is_untouchable(). One reserve therefore stays on the card until the next arm
Unrelated objects preserved through everything	pass	LIST before and after every step: map object 1 revision 3 / 10,093,056 B / 0x520fb508, and all 8 routes at their revisions, lengths and CRCs. Only the app's own kind-9 metadata object moved (revision 22 → 23), which the app rewrites on its own
Cold boot	not reachable	tools/board.py has no power control and both cables feed the board, so every reset this session was warm (RESETREAS=0x00000040)
obc-boot size guard	pass	16,632 / 32,768 B on the unmodified origin/develop build, ELF b3b2b2ac…82f2

Artifacts

File	Bytes	sha256
release raw image (0429956)	1,779,784	0bd57781…37af
release container, version 0429956	1,779,912	e2f61ae9…7bfc
debug-uart 0.1.1 raw image	1,798,976	41dde369…7b0d
debug-uart 0.1.1 container	1,799,104	804614ae…1f62
forced-failure container	1,799,104	85e91069…e6ab

Board end state

The shipping release image built from origin/develop 0429956 is in the app slot, and it was
put there by the DFU path, not by the probe: it was staged as a kind-7 object, armed on the glass,
installed by the bootloader and confirmed on its trial boot. run --preverify against the release
ELF then programmed nothing, so the slot matches the build. The boot-state page reads Idle,
installed = 0429956 (the container's version, chosen to match what a probe-flashed build reports),
last_outcome = Installed. The board carries the unmodified origin/develop bootloader again.

Card: store dc2b0e05…750e, 11 entries — map object 1 revision 3 (grimsel-demo), the 8 routes,
the kind-9 metadata object, and one kind-8 rollback reserve (id=390) that the last arm published
and that the wire cannot remove. Both update packages this session staged were removed. No ride is
on the card, nothing was formatted, and nothing this session did not create was deleted.

One DAP FAULT appeared once, on the last run --preverify (Failed to read register DRW at address 0xd0c). The retry was clean. The board README lists it.

[timohueser]

Session S3 (third run, #2047) — 2026-09-22

nRF54LM20-DK. Worktree closeout-boot-vpr-secure at b1fc6f39f (origin/develop + the #2047
commit). The bootloader under test is #2047's option 2 — semmc::grant_secure_access() writing
SPU00.PERIPH[12].PERM, called first in park_hart(). The second run's install evidence came from
a locally patched bootloader that was never committed; this run repeats it on the branch.

Card at the start: store dc2b0e053244229207bd15bb4812750e, 11 entries — map object 1 revision 3
(grimsel-demo, 10,093,056 B), 8 routes, one kind-9 metadata object, one kind-8 reserve (id=390).
commitSequence 795. No ride.

#2045 is fixed by the branch, not by a patch

Four installs and one rollback completed with no HardFault at park_hart. The install reads
1.8 MB off the card through the FLPR, which is the whole VPR00 path the fault used to kill at its
first register write, so a completed install is the proof.

Check	Result	Evidence
Ordinary boot is untouched	pass	obc-boot: generation=0 → deciding, then the app: boot #153, flat: catalog holds 1 map object(s), 8 route(s). The Idle fast path returns before the grant
Arm over the VCOM	pass	dfu-install on cu.usbmodem…963: D scanning the staged update package (running b1fc6f3) · D scan ok: v0.1.2-pr2047 (1799344 B, 1 extent(s)) · D armed gen=1 -- rebooting into the bootloader
First arm writes no reserve	correct	D no rollback: running image differs from installed record (SWD reflash?) — the baseline image was probe-flashed. Later arms wrote one
The bootloader installs	pass	obc-boot: adopted the app's running WDT — petting through the install · verify 1738 KiB in 2192 ms (793 KiB/s) · flash 1738 KiB in 41198 ms · readback 1738 KiB in 1645 ms (1056 KiB/s) · install complete — jumping into the new image (trial boot)
Flash rate varies with the probe	noted	8816 ms (199 KiB/s) with probe-rs attached late, 41198 ms with it attached throughout, against the second run's 16192 ms (108 KiB/s). The debug session pays for it; nothing in the engine changed
The bumped version boots	pass	dfu: running image is v0.1.2-pr2047, boot #156. run --preverify against the built ELF programmed nothing, so the slot is byte-identical to the image that was staged
Trial confirm	pass	boot-state page at 0x001FB000: tag Idle, installed header image_len 1799344, image_crc32 0xBF9E615A, version v0.1.2-pr2047, last_outcome = Installed
Forced-failure image	pass	the same image with the reset vector set to 0xF000_0001, re-wrapped and signed as v0.1.3-trialfail; container 1,799,472 B, sha256 5a3bf031…0cf6. The armer accepts it (D rollback written to the reserve), the bootloader installs it, the trial boot faults
The bootloader falls back	pass	the trial never confirmed; the 24 s trial WDT reset the board and the next entry restored the reserve
Boot-state vectors after the rollback	pass	Idle, installed = v0.1.2-pr2047, last_outcome = RolledBack
The previous version is back	pass	boot #157, dfu: running image is v0.1.2-pr2047, and dfu: staged v0.1.3-trialfail is not the running image — rejected or rolled back
The rider is told	pass	two net-zero screen probes both answer input: Step 1 on DfuFailed
Catalogue preserved	pass	LIST before and after every step: map object 1 revision 3 / 10,093,056 B / 0x520fb508, the 8 routes at their revisions, lengths and CRCs, 0 rides. Only the kind-8 reserve id moved (390 → 399), because each arm republishes one and the wire cannot remove it
obc-mkimage wrap stops warning	pass	the board image's first word is 0x2007_8000; with #2047's RAM_END (the LM20's 512 KB) wrap emits no "not an initial SP" line. The old 0x2004_0000 bound warned on every board image
obc-boot size guard	pass	16,688 / 32,768 B, ELF 5df70fad…7d49 (shipping shape)

The bring-up recipe needs one flag

probe-rs run and probe-rs attach enable reset and hardfault vector catch by default, so the
armer's warm reset halts the core: the session exits with Firmware exited unexpectedly: Exception
and a stale backtrace (__INTERRUPTS @ 0x4c8, DefaultHandler_) that names nothing real, before
the bootloader prints a line. Three attempts lost the install log to it. What streams the whole
install is

probe-rs attach --chip nRF54LM20A --non-interactive \
    --no-catch-reset --no-catch-hardfault <boot elf>

started before the arm. Reported on #2047 as the one change the README owes.

Artifacts

File	Bytes	sha256
debug-uart 0.1.2 raw image	1,799,344	e7179289…fe59
v0.1.2-pr2047 container	1,799,472	e9920155…385f
forced-failure container	1,799,472	5a3bf031…0cf6
release raw image (b1fc6f3)	1,780,136	9e822ed7…d961
release container	1,780,264	0ffd9ad3…b8cf

Board end state

The release image built from the branch (b1fc6f3, the tree that merges) is in the app slot,
put there by the DFU path: staged as a kind-7 object, armed over the VCOM, installed by the
bootloader, confirmed on its trial boot. run --preverify against its ELF then programmed nothing.
Boot #162, dfu: running image is b1fc6f3, boot-state page Idle / installed = b1fc6f3 /
last_outcome = Installed. 0x0 carries #2047's bootloader in the shipping (silent) shape,
because the pull request is approved.

Card: store dc2b0e05…750e, 11 entries — the map at revision 3, the 8 routes, the kind-9 metadata
object and one kind-8 reserve (id=399). All four update packages this session staged were
removed. No ride is on the card, nothing was formatted, and nothing this session did not create was
deleted.

One DAP FAULT appeared once on a run --preverify (Failed to read register DRW at address 0xd0c); the retry was clean, exactly as the second run and the board README describe.

[timohueser]

Addendum — J3 after the session

The board is healthy and its last boot logged usb: device plane up — 1209:0001, serial 'FF7CB6E1732BD34B', HS bulk 512 B, but the host stopped enumerating J3 after the last probe
session closed. board doctor says J3 device: not enumerated and ioreg finds nothing. This is
the signature the first S1 run recorded and the board README names: J3 needs a physical replug
before the next cable session. The app, the card and the bootloader need nothing.

[timohueser]

Sol closeout session — 2026-09-22

One GPT-5.6 Sol implementer per bounded task, a separate Sol adversarial reviewer, and delta-only review after fixes. A GPT-5.6 Terra agent audited the landmark category scope. The supervisor wrote #2049 and the acceptance notes, coordinated the work, and merged only reviewed heads with green CI.

PR	Result	Reviewed head
#2050	Landmark IDs 7–16, codec, four-language labels and contract. #2049 closed; #2026 retains content work.	836741424a21ffbaf20383c14482df752aa42981
#2051	Retired scratch is truncated; cached input is counted correctly; quota failures are actionable. #2038 closed.	694667629299c1239bff7f840571584a8bd83805
#2052	FAT runtime, serial ingest, obsolete storage adapters and pre-v4 BLE transfer/list code removed. #1393 and #1256 closed.	9f9cbac5e23e33c8041c513bcee7950b04a3f2ef

Review corrections: spring labels now cover both hot and mineral springs; builder readiness counts cached input before enabling the button; FS11 removes the remaining dead BLE adapters. CI also exposed a persisted test preference; the test isolation fix passed a separate delta review.

Validation records and exact commands are in each PR. The landmark change passed focused app/packer/codec suites, lint, policy/docs checks and one frame comparison. The builder passed 1,005 local frontend tests and the exact CI-style 1,001-test component run under coverage. Its full ordinary-profile Baden-Württemberg build keeps the same output hash. In real Chromium under an enforced 96 MiB quota, 64 MiB of live scratch blocks another 64 MiB allocation; removal drops usage from 67,109,198 B to 334 B; 64 MiB then succeeds, while 112 MiB still fails with QuotaExceededError. The attempted whole-region 3 GiB run was stopped as inconclusive; it is not claimed as a pass.

FS11 passed its focused tests, lint, vector regeneration, guards, and 293 UI frames. The historical counter from 97ccc567 (3c7b67573^) reports 4,796/6,000 raw production lines on the final head. The tool remains retired. The net deletion is 5,011 lines. The repository-tools coverage wrapper was unavailable locally; final CI ran the selected checks and passed, including resource and platform gates.

No device was flashed and no map or fixture was published. Cold boot, cardless boot, the new-StoreId card swap and J3 unplug checks are retained in S4. S3's committed install/rollback evidence is unchanged. The signing key, production re-bake/publish, content refresh, phone/ride/Windows sessions and other owner actions remain open.

[timohueser]

Session S4 — hardware acceptance in progress

The session uses one GPT-5.6 Sol hardware operator and a separate Sol evidence reviewer. All probe access uses the shared board lock. The owner performs one confirmed physical step at a time. An iPhone is available. No second prepared card is available.

Accepted checks

• Initial shipping app: 5eda4e250402b164bfdff1312e0b19142f1a966e, built without extra features. ELF SHA-256: c53dcd59b2266ae42fee41261f2933e4bfa464f56db593069a09f03d8361b78e. Raw app: 1,763,640 B; SHA-256 37cecc3fa977471544a600a10e9c6eb0be2ad52f399303f692a5900fc3ac0efa. App-only programming preserves the bootloader and installed DFU record. Exact image readback passes.
• Warm boot: count 166, RESETREAS 0x40. Store dc2b0e053244229207bd15bb4812750e, commit sequence 809. All 11 LIST entries and their STATUS replies match the baseline.
• Cold boot: the owner removes both J3 and J4 and confirms the board is completely dark. The owner reconnects J4 only. A read-only probe read records count 167 and RESETREAS 0x1 (reset pin). J4 repower can assert the target reset pin; the confirmed power removal establishes the cold start. No run, reset, or flash command occurs. After the owner reconnects J3, count remains 167 and the same store, sequence, LIST entries, and STATUS replies return.
• Preserved objects: map 1 revision 3, all eight routes, metadata 85 revision 23, and protected rollback reserve 399 revision 1. No ride or RECORDING entry exists. Settings remain valid v22. Only clock fields and their CRC change with the GNSS clock refresh.

Independent evidence review accepts both warm and cold checks. The cold diagnostic is 16 bytes, SHA-256 27a6725d5d355de08510d3055911995f3cdd56532034b2509b682144a3de732f. Local raw artifacts are /tmp/obc-hw-inventory-before.json, /tmp/obc-hw-inventory-after-warm.json, /tmp/obc-hw-inventory-after-cold.json, /tmp/obc-settings-before.bin, /tmp/obc-settings-after-warm.bin, /tmp/obc-settings-after-cold.bin, and /tmp/obc-boot-diagnostics-after-cold.bin.

Cardless boot

The owner again removes both cables and confirms the board is dark, removes the card while power is off, then reconnects J4 only. The owner sees NO SD CARD. A no-reset attach captures a fresh 5eda4e2 boot with RESETREAS 0x0. At 1.662 s the log reports typed NoCard, the warning screen, and the heartbeat-idle path. Sensor activity continues through a GPS fix at 16.233 s without another boot banner, panic, or reset. Independent review accepts cardless detection and fault-screen handling. Log: /tmp/obc-5eda-cardless-attach.rtt.log.

The saved boot counter remains 167 because this early path exits before settings initialization and bump_boot_count. That unchanged record is not evidence of this boot. The physical sequence and fresh RTT log establish it.

The owner sees no blinking LED. Visible heartbeat is not observed, and its cause is unconfirmed. Nordic documents that DK revisions before 0.5.0 lose LED function above 2.7 V; this display setup requires 3.3 V. The board revision and LED power configuration are not established. This is a possible explanation, not a measured diagnosis. Continued sensor activity does not independently prove the main heartbeat loop. No voltage, solder bridge, or LED setting changes occur. Source: Nordic LED limitation.

Original-card recovery

The owner powers the board off, confirms darkness, reinserts the original card, then reconnects J4 only. The normal screen returns. A no-reset read records boot count 168 and RESETREAS 0x0; count stays 168 after J3 reconnects. The RTT capture starts at 8.057 s, after mount messages have left the buffer. It shows healthy GNSS, BLE, and UI activity through 60.95 s, but is not a direct mount log.

USB LIST and every STATUS reply match the pre-cold baseline: the same StoreId, sequence 809, all 11 objects, and no ride or RECORDING entry. Settings change only in the clock and its CRC. Independent review accepts original-card recovery and preservation. This does not establish replacement-card/new-StoreId behavior.

Artifacts: /tmp/obc-hw-inventory-after-card-recovery.json (SHA-256 94df055486bb1f8ed452e6fcb013dad1d30da48e28f35d8d26964e91d519ecde), /tmp/obc-settings-after-card-recovery.bin (3e112f42164b0bd4950b3cad9e033b5f0163d252debc827024dfbb7ab4511ba5), /tmp/obc-boot-diagnostics-after-card-recovery.bin (215263350d3673c9653533047dcb73d00e8f0d591dcfb8860db444a4e2c7e3e2), and /tmp/obc-5eda-card-recovery-attach.rtt.log (eeebbe531c51ef71a16e8e7939a4b10dd4b158aa29644df9065439fb93cc0866).

Finding and fix

The retained installed DFU header reports b1fc6f3 after the verified probe flash. #2054 records this stale firmware-identity defect. #2055 fixes it with a bounded image match before publishing the installed version. A separate Sol reviewer accepts exact head bacd438323bcd40628157c4363291046f18b3211; selected CI passes. The PR merges as 2930be8b869bab6c2ce9a45a9059ece82f870efa. Hardware verification of the stale-header fallback passes independent review on the shipping merge build. Clean source is 2930be8b869bab6c2ce9a45a9059ece82f870efa; ELF SHA-256 is a2b52ae80cb49de3d58e837b3d6d861a58415aaae1957be2e6f6a75714a3ac22. App-only programming and exact no-program readback verification pass. Boot 169 reports the record mismatch and running version 2930be8; real USB device info also reports 2930be8.

A direct nonsecret boot-state read still decodes Idle, installed version b1fc6f3, length 1,780,136, CRC 0x6c845c54, signature scheme 1, and last outcome Installed generation 1. Its SHA-256 is c1037ba885d9a74fd0c2f20289873c1f6ff1b76f18e48740648b452581d26b1d. The record was not cleared as a workaround. The same StoreId, sequence 809, all 11 object/status tuples, and functional settings survive. Only clock and checksum bytes change. The BLE DIS construction log uses the corrected value. The later real-iPhone check below confirms the actual BLE client read; actual DFU-screen observation remains separate.

Artifacts: /tmp/obc-2930be8-firstboot.rtt.log, /tmp/obc-2930be8-readback-preverify.log, /tmp/obc-hw-inventory-after-2930be8.json, /tmp/obc-settings-after-2930be8.bin, /tmp/obc-boot-diagnostics-after-2930be8.bin, and /tmp/obc-boot-state-after-2930be8.bin.

USB transfer and physical J3 interruption

The shipping USB client completes PUT, STATUS, full GET with byte comparison and an independent CRC, and REMOVE for one owned 262,144-byte test object (400 revision 1). Only that object is removed. Store sequence advances 809→811; the original 11 entries and their STATUS replies remain exact.

The first interruption attempt pauses its source too long while waiting for the owner. It exceeds the 21-second PUT stall limit. It is invalid evidence of an active physical interruption, even though unplugging later produces a link error. It is not counted as a pass.

The corrected source continuously sends 4 KiB every 500 ms. Settled progress arrives about every four seconds. The owner removes J3 only while J4 keeps the board powered. Request 3 disconnects at 294,912 of 4,194,304 bytes, 2.024 seconds after its last settled progress, before onSent or commit. The boot count remains 169.

After the owner reconnects J3, a fresh LIST returns the same StoreId, sequence 811, and original 11 entries. No exact match exists for the owned test tuple: kind 1, name HA-S4-owned-paced-pull-2930be8, length 4,194,304, CRC 0x7457fc39. A new request 4 retries from byte zero and commits only object 401 revision 1. STATUS matches. Full GET returns all bytes exactly and its independent CRC matches. REMOVE deletes only 401 revision 1. Final sequence 813 accounts for exactly one retry commit and one removal; all original entries and STATUS tuples remain exact, with no ride, RECORDING, or temporary object. No board reset occurs.

Independent Sol review accepts the normal cycle, active physical interruption, reconciliation, fresh retry, full readback, and cleanup. These use synthetic kind-1 payloads to test USB transport and flat-store behavior. They do not establish route parsing, navigation, or acceptance of every object kind.

Artifacts: /tmp/obc-usb-owned-cycle-2930be8.jsonl (SHA-256 f87fd3ff00faa8c714c7bd7aea22ec489962b1a69cc8933fda11315082781866), /tmp/obc-usb-paced-pull-2930be8.jsonl (b3b4e55063472dc32f6701b905ef0240fbeb76f750285be2b52f153524d80ed1), /tmp/obc-usb-reconcile-retry-2930be8.jsonl (e30148fdae177f27c6795a9391aedc1eb49b1fc57b456c31bb66a4a2735ba46d), /tmp/obc-hw-inventory-after-paced-retry.json, and /tmp/obc-boot-diagnostics-after-paced-retry.bin.

Real iPhone connection and identity

The current iOS Release app is built from the protected 5eda4e250 checkout and installed over the existing com.openbikecomputer.companion bundle, without uninstall or data clearing. After J3 is disconnected and J4 remains connected, the owner sees the app connect. The board log records an authenticated encrypted link restored from its stored bond, MTU 247, 2M PHY, a v4 channel, and app-originated DIS, config, and object-control traffic. No new pairing prompt occurs.

The owner opens Settings and reads Firmware version v2930be8. This establishes the corrected identity through the actual iOS BLE client. That app call also completes a LIST-backed store-scope handshake. The exact BLE StoreId value remains pending direct phone or receipt evidence; it is not inferred from USB.

Independent review accepts the bonded BLE session and firmware identity. On connection, the app updates the clock, sets known UTC offset +120 minutes, and restores device name OBC from its saved bond preference. The name reconciler has no OBC default. The history of that saved preference is not observed. All other decoded settings remain exact. Record these expected app-managed changes, not byte-for-byte settings preservation.

Artifacts: /tmp/obc-ios-companion-release-install-signed.log, /tmp/obc-2930-ble-app-connected.redacted.rtt.log, and /tmp/obc-settings-after-real-ble.bin. A dependency emits an IRK in raw debug output; #2086 records the bounded logging follow-up. The retained log is redacted and the raw file is removed. No key is included in this record.

Instrumented card-pull check — failed

The user asks the agent to operate the board menus. The operator switches to exact 2930be8 with debug-uart and verifies the app-only flash. ELF SHA-256: f85b3926d99984da28e8d7ffe230afaafa14907bbd68fa0739eee4250e3a7822. This build replaces real GNSS input with the existing injected-input harness; its evidence is separate from the shipping checks above.

The first tap helper is incorrectly timed and produces a Hold. No recording or store change occurs in that attempt. The corrected official tap format produces verified UI transitions and starts only test ride 402 revision 1, with RECORDING set. Sequence becomes 814, with all original 11 tuples unchanged.

The owner removes the card while J4 supplies power and injected position samples continue. The breaker correctly opens after two failures and schedules its 30-second probe. Failed checkpoint requests nevertheless repeat in a tight loop, then the instrumented UART reports an overrun panic. The check fails. The owner's no-card message is not evidence of healthy recovery. No shipping-image panic is claimed.

#2089 owns the bounded fix, its source diagnosis, exact log chronology, and artifact hashes. The feeder and probe stop. The owner powers off, confirms darkness, and reinserts the original card. Both cables remain disconnected. No operator repair or removal is sent for ride 402. Its next-mount survival is unverified at this point. A Sol implementation agent works on the fix, with separate adversarial review and green CI required before merge and hardware retest.

Checkpoint retry fix

#2093 fixes #2089. A separate Sol reviewer accepts head a9ace0756dedb52212551db6a05da500efc42965. The first CI run then rejects an 8-byte App allocation increase. The implementation replaces two checkpoint flags with one three-state enum. The delta review accepts exact head 8ff80ae81de94dad88ca7611560a6a4ea43fcf07 with no findings. App size returns to the pinned 57,384 bytes; no resource limit changes. All selected CI checks pass on that head, and no review thread is unresolved. The PR merges as bd279d4ffb913584ed91ea028ae93b49885c4b09.

The recorder preserves the owed checkpoint and starts a 30-second retry delay when DeviceCore consumes the failed media outcome. Append and Save wait behind the checkpoint; explicit Discard remains available. Repeated failure starts another delay. Physical recovery is not yet verified. The operator builds both images from clean merged head bd279d4ffb913584ed91ea028ae93b49885c4b09. Debug-UART ELF SHA-256: 95ec655aa8e8f134317fafe8bb9f26d1c0c50058042de0fbe3cda6de816ee3b1. Shipping ELF SHA-256: acaf56c1d3c013e484bb514582dd8ce138493ec65f7e56c5a29e3d12a113c4a1. Neither image is flashed. The owner pauses physical acceptance overnight. The board stays off, with both cables disconnected and the original card seated. No probe or VCOM process remains. The next step requires the owner to return and confirm J4-only power before the operator flashes the fixed debug image.

Morning firmware candidate

While the board stays off, #2097 merges the software logging fix after independent review and green CI. Its actual bonded-reconnect capture remains pending in #2086. The next debug image and final shipping candidate now use exact merged source 8640d5b2c60c83d85a648b3419c4be35aafeb59a, which includes both #2093 and #2097. The clean-source debug ELF SHA-256 is 4a57e3964d83c9ad1c51ad6bd08e528de5ffbc6858187a439f99f841f80caff7; the shipping ELF SHA-256 is 93a2992bf141a0f10270f05e0b3b6288a4b4143854533eb842477c611cc4f9bd. Both are built offline before the owner returns. The debug image is then flashed and verified after the owner confirms J4-only power. The shipping candidate is not yet flashed. The old bd279d4 and 2930be8 artifacts remain unchanged.

Morning recovery and fresh recording

The owner returns with the original card installed, J4 connected, and J3 unplugged. The board shows Home before the fixed flash. After the verified app-only flash of debug source 8640d5b2c60c83d85a648b3419c4be35aafeb59a, the census shows the same StoreId and the original 11 tuples at sequence 815. Ride 402 is absent. #2107 records this unexplained preservation gap. A live recording's zero catalog length does not prove an empty journal. No removal actor is established. The initial boot capture is lost after an incorrect redactor invocation; the later no-reset capture survives. The new test below does not resolve that gap.

The operator starts fresh owned ride 403 revision 1 at sequence 816 and injects accepted fixes. A controlled reset with capture returns boot 174 and RESETREAS 0x40. Recovery reports checkpoint 15 and 2,020 tail bytes for that exact ride. A normal Continue action resumes 403. A later census still has the original 11 tuples plus 403 RECORDING, with no duplicate. Independent Sol review accepts this durable reset/recovery evidence for the debug-UART build. It does not establish shipping GNSS behavior.

Artifacts: /tmp/obc-8640d5-recovery-baseline.redacted.rtt.log, /tmp/obc-8640-recovery-census.jsonl, /tmp/obc-8640d5-durable-retest-pre-reset.redacted.rtt.log, /tmp/obc-8640-durable-retest-vcom.jsonl, and /tmp/obc-8640d5-durable-remount.redacted.rtt.log.

The owner removes the card while the device remains powered through J4. The owner confirms Storage stopped on the display. The live capture shows the breaker opening after two failures and recorder checkpoint retries at about 30-second intervals, with continued UI and sensor activity and no observed panic or reset. Separate repeated storage reads of block 12955 remain an unresolved finding. This is an interim observation, not a complete card-recovery pass.

The owner then confirms hot reinsertion of the original card, with J4 still connected and J3 unplugged. Recovery fails across several probe windows. Eighteen checkpoint failures span device time 741.787 through 1256.085 s; the capture ends at 1263.236 s with no recovery message. It also contains 877 failed storage reads: 863 Unhealthy, 11 Timeout, and 3 Aborted. Their median gap is 0.512 s. Attribution to map redraws is a source inference; the log does not identify the caller. #2110 tracks safe hot-card recovery and bounded map retries. This card-recovery check fails; the bounded checkpoint cadence is only one part of it.

The feeder and capture stop. No Save, Discard, reset, or deletion follows. The owner is asked to power off with the card seated. The closed capture is /tmp/obc-8640d5-durable-cardpull-hot-reinsert.redacted.rtt.log, SHA-256 396dded908a9fcf53bd1f0de12bf075cc8921d8599b9b26195abf09a8bb7690b. Its VCOM trace is /tmp/obc-8640-durable-continue-vcom.jsonl, SHA-256 39c9a08b97be649d828c327f53b1355e3da4874c16becc912472b4c2fe465ce4. Independent Sol review accepts the same-object Continue, bounded checkpoint cadence, failed hot recovery, repeated storage reads, and absence of an observed panic or reset in this captured window. Physical removal and reinsertion are established by the owner; the log has no insertion timestamp. The review does not establish successful recovery, final readback, pending-data preservation, or shipping GNSS behavior.

Cold recovery after failed hot reinsertion

The owner confirms J4 is unplugged and the board is dark. The original card stays seated and J3 stays unplugged. The owner reconnects only J4 and sees Ride Recovery. A no-reset attach retains the natural boot from 0.001 s: image 8640d5b, RESETREAS 0x0, boot 175, and ReadWrite mount at sequence 816 with 12 entries. There is no run, reset, or flash command.

Recovery reports exact ride 403 revision 1, checkpoint 95, with 16,384 flushed bytes and 10,596 tail bytes. Before any button or sensor input, a read-only census proves the same StoreId and every original protected tuple, plus 403 RECORDING. The first census command has no retained RTT output; the operator repeats the same read-only command once during capture. No other UART input is sent before this snapshot.

Independent Sol review accepts cold recovery of the durable pre-pull data and preservation of the original 11 catalog tuples. It does not establish hot recovery, survival of pending RAM, shipping GNSS, or final Save/readback. Normal Continue and Save are authorized next to prepare the phone checks. Ride 403 remains session-owned and is not removed.

Artifacts and SHA-256:

• /tmp/obc-8640d5-cold-recovery403.redacted.rtt.log: f3c2df10331bdf35733ede30bb81b54b934577d3cdb6422708cb4ab055063679.
• /tmp/obc-8640d5-cold-recovery403-census.redacted.rtt.log: a4c016e8b5f775f7f2c236140d80a7cd2df3c0f889985067ded6fe3052884a68.
• /tmp/obc-8640-cold-recovery403-census.jsonl: 35a75bdacbaeee537813569ffce4bd4486867598a6d01f8fc22a00a8c2b63aba.

Normal Continue, Save, and complete readback of 403

The official harness selects Continue for the recovered object 403. The closed trace records that action at device time 392.015880 s and the same-object continuation at 392.101994 s. The operator sends accepted test positions, then uses normal RideControl and Finish. The footer and one commit complete at 582.701442 s.

The saved ride is 403 revision 1, kind 3, flags 0, 31,824 bytes, CRC 0x7a24553e. Sequence advances once to 817. The complete GET contains 1,587 v3 samples and the 84-byte v3 footer. Compared with the independently recovered 26,980-byte pre-Continue body, 238 new samples span 121.349 seconds. This is injected-input evidence.

The shipping host client talks to the debug-UART firmware over J3. LIST and STATUS return the exact saved tuple. Full GET returns all 31,824 bytes, and the device, catalog, STATUS, and independent CRC agree. The catalog stays at sequence 817. Every original protected tuple remains unchanged, including metadata 85 revision 23. Thus no archive receipt commit exists through this snapshot.

Independent Sol review accepts normal Continue, Save, complete byte/format/footer readback, CRC, and protected-catalog preservation. No phone import, GPX export, hot recovery, pending-RAM survival, or shipping-GNSS result is claimed.

Two earlier USB attempts time out before enumeration and send no protocol request. A no-reset RTT attach then produces USB startup messages without a cable action. A further owner-confirmed J3-only reseat during live capture restores enumeration. The cause of the detached execution state is still being diagnosed; no explicit halt status was recorded. The live capture owns that chronology and is not yet closed. These absent-device attempts are not counted as protocol successes.

Artifacts and SHA-256:

• /tmp/obc-8640d5-cold-continue-save403.redacted.rtt.log: 9601a694dbb00d6b11b56ddee848c237e341597660b6106b953f846de05138a1.
• /tmp/obc-8640-cold-continue403-vcom.jsonl: bf821adb689ecac400bd38eec65f24bdb87391b7757b48bfd2b92ccee38452be.
• /tmp/obc-hw-inventory-after-save403.json: deb47a5dc08e7a5dbffc2ae1f0f4be679bc2010f0184639f0604a9ac4382376a.
• /tmp/obc-usb-get403.json: e72eb81682e3baec18b35249df12f8fc4635ebd78b1e7e6286b9acc96986168c.
• /tmp/obc-ride403-full-get.bin: a6a7be55426ed29decc7eea74009d71acd0bfb1e2897222c2a4107194a0470d1.

Phone sync stops before archive confirmation

With J3 unplugged, J4 connected, and the original card inserted, the owner opens Rides and confirms the app is connected. The owner taps Sync, then Resume once. Both attempts show Sync interrupted. Got 0 of 0 rides. No archive breakpoint fires. This is not an interrupted-receipt pass.

The source comparison uses the previously recorded app source 5eda4e250402b164bfdff1312e0b19142f1a966e; the installed app UUID is not verified before the owner defers this work. The board image remains 8640d5b. Source inspection shows that listRides() downloads and decodes completed rides before it returns the catalog. A failure in that stage produces the observed zero count. The ride codec and protocol client are unchanged between these sources. Offline checks of the closed USB GET payload pass every installed ride-codec structural guard. They do not prove the BLE transfer delivered the same bytes.

The first post-error control buffer contains GET for 403 revision 1, request 128; its timestamp is unknown. After Resume, the buffer contains a ride LIST, request 194. The engine is idle; residual GET fields name request 186 and the expected 403 tuple. Residual fields are not a live transfer snapshot. A subsequent no-reset RTT capture shows transfer activity ending, later control traffic, and a remote BLE termination. It contains no adapter refusal, send, indication, or staged-control timeout report. The app-side error remains unknown.

Every breakpoint is cleared, the core is explicitly resumed, and the bounded RTT capture is closed normally. No reset, flash, app reinstall, or card mutation is performed for this diagnosis. The capture is /tmp/obc-receiptA-rtt-after-fail.redacted.log, 9,725 bytes, SHA-256 882c67255359188aefd958dc19ffe9d4560c93a0bd66c8f1a9bd5d0605f7c481. Receipt acceptance remains pending.

Owner defers phone/device acceptance

The owner defers all phone/device interaction checks to Adrian's parallel transfer work with the newest app and firmware. Stop sync-error diagnosis, receipt interruption/retry, changed-source receipt, and Forget-phone checks in this session. These checks are deferred, not passed. The existing sync observations and captured artifacts remain available for that work. Non-phone hardware acceptance continues, starting with hot-card recovery on merged #2114, followed by final firmware restoration.

Fixed same-card hot recovery passes with paused input

Separate Sol review accepts the exact-6357bfc hot-card trace, catalog snapshots, and complete USB payload. The card removal opens the breaker; same-card reinsertion produces the retained-media recovery message without an observed reset. Ride 404 continues, then normal Finish produces sequence 819. Its 8,224-byte OBRF v4 payload has CRC32 0x22b17602; 210 samples occur after the paused-input interval. All 12 protected catalog entries remain unchanged. The full record and scope limits are in #2114 (comment).

This is a paused-input storage recovery pass. Sustained input, pending RAM samples, pending Save intent, actual GNSS, and a foreign card are not covered. Phone/device tests remain deferred. Ride 403 is retained in OBRF v3 and 404 in OBRF v4. Exact shipping firmware 6357bfc is restored, verified, and independently reviewed. The final catalog is sequence 819 with all 13 expected entries and no recording object. The clock updates from GNSS; other settings and the bond hash are preserved. RESETREAS 0x44 includes an unexplained watchdog indication, tracked in #2128; boot count stays 178 during the bounded stability check. No continuing reset loop is observed. All hardware tools are closed; J3, J4, and the original card remain connected.

Still pending

Sustained-input recovery remains pending. Phone/receipt and per-kind phone/device client checks are deferred to Adrian. Exact shipping image 6357bfc is restored. #2128 tracks the unexplained watchdog flag across restoration; no continuing reset loop is observed. #2107 remains open for the unexplained loss of 402. Earlier USB test objects are removed. The second-card/new-StoreId check is unavailable. True release OTA still needs the owner signing-key and publication steps in #773. Typed bond-failure injection has no safe shipping-tool path and remains open. No unperformed check is a pass.

[timohueser]

Overnight continuation — 2026-09-23

The owner pauses S4 with the board off, both cables unplugged, and the original card seated. No hardware is accessed. One Sol agent implements each software task, a separate Sol agent reviews it, and a Terra agent audits the remaining tracker scope.

• fix(ble): keep bond secrets out of board logs #2097 merges the software half of BLE diagnostics: verify the merged secret-log protection on hardware #2086 at 8640d5b2c60c83d85a648b3419c4be35aafeb59a. Reviewed head: 815787cad113ce52143364f72f7c88f56c50ac31. Selected CI passes; no review thread is unresolved. The full review finds a default-only feature-policy gap. The delta checks the full all-features graph, passes separate review, and keeps dependency secret logs disabled while retaining board-owned state diagnostics. The real bonded-reconnect capture remains pending in BLE diagnostics: verify the merged secret-log protection on hardware #2086.
• D8 closes software-complete EPIC — Ride domain: durable retention metadata and final closeout #1398 and EPIC — DeviceCore: finish runtime store parity and typed platform outcomes #1433. Their receipt, Forget phone, and related physical checks remain in S4. No closure claims a hardware pass.
• Landmarks: prepare local Swiss capture for expanded categories #2095 starts the fresh local Swiss capture under Landmarks: publish Swiss content, re-pin maps and verify hut/tower cards #2026, then stops cleanly at the end of the overnight window. It retains 176 of 2,031 selected place files and 18,935 request outcomes, including 17 transport errors. The first pass is incomplete, no retry or compile runs, and no content acceptance is claimed. Independent review verifies the immutable inputs and partial handoff. A later independent power-log audit invalidates the multi-day estimate: macOS records 4:59:28 asleep during the 6:36:46 capture window. There is no reliable awake-runtime estimate. Landmark capture: exhaust Commons category pages before declaring completeness #2106 separately fixes the confirmed Commons category pagination defect before acquisition resumes. The issue record contains the exact resume command and the stale pre-asset manifest caveat. The older capture remains present in its locked checkout; this run does not target it. Publication, fixture re-pinning, map rebuilds, and visual acceptance remain in the parent issue.

The scope audit finds no other unclaimed software task in the older tracker rows. The remaining work needs hardware, owner content or wording, or publication. Firmware artifacts containing both #2093 and #2097 are ready from clean source 8640d5b2c60c83d85a648b3419c4be35aafeb59a. Debug-UART ELF /tmp/obc-8640d5-debug-uart.elf: SHA-256 4a57e3964d83c9ad1c51ad6bd08e528de5ffbc6858187a439f99f841f80caff7. Shipping ELF /tmp/obc-8640d5-shipping.elf: SHA-256 93a2992bf141a0f10270f05e0b3b6288a4b4143854533eb842477c611cc4f9bd. Neither is flashed. The old images remain as evidence. The merged BLE task worktree is removed, recovering about 2.3 GiB; shared caches and artifacts are preserved.

All overnight agents finish their handoff. No capture, compiler, probe, or VCOM task from this session is left running. The board remains off. S4 resumes only after the owner returns and confirms J4-only power. The new capture source checkout remains available for an exact resume.

[timohueser]

Overnight closeout audit

The tracker now describes the remaining owner actions and physical acceptance checks. The original waves stay complete. The total issue count is no longer a close condition because #2056 adds a separate product programme.

The audit removes stale re-bake gates after #2053, records the completed OTA source phases and S3 session, and preserves the narrower S1/S4 evidence. The unexplained historical #2107 loss stays unexplained; the owner's closure remains in force. The outstanding licence, requirement wording, release-key, publication and physical acceptance gates remain explicit. Current-status notes also update #773, #1892, #1928, #1946 and #2048. Reviewed status sections on #1805, #1830 and #2026 distinguish merged source work from the remaining content or physical checks. The separate skyline photograph fixture does not close Peak View article UI acceptance.

Merged work:

• fix(firmware): restore neutral watchdog diagnostic #2156 restores the neutral watchdog reset diagnostic after a later merge reverted fix(firmware): report watchdog reset neutrally #2130. It closes Restore neutral watchdog reset diagnostic after merge regression #2155. This fixes the message but does not resolve the physical reset-timing question in Investigate watchdog flag after app-only shipping restore #2128.
• docs: use release landmark compiler consistently #2160 makes the capture recipe use an optimized compiler for acquisition and both reproducibility compiles. It closes Use the optimized landmark compiler throughout country capture #2158. The retained Swiss capture uses a separately reviewed same-source compiler transition; Landmarks: prepare local Swiss capture for expanded categories #2095 holds its evidence.
• Avoid repeated landmark photo preparation #2163 makes later photo-request rounds compile only the candidates with fresh requests. It closes Capture: limit later photo-request rounds to affected landmarks #2162. The request compiler keeps its input snapshot immutable. The new command writes only the request control document.

Each pull request has independent GPT-5.6 Sol review and passing selected CI. No owner action or physical gate was treated as completed by a source change.

Additional checks found no actionable source regression:

• BLE diagnostics: verify the merged secret-log protection on hardware #2086: the fix(ble): keep bond secrets out of board logs #2097 log protection and resolved-feature dependency guard remain intact. A separate Sol reviewer confirms the result. The real bonded-reconnect RTT check remains open.
• S1: existing app and simulator tests cover text-only/Sources logic and same-ID replacement behavior. The remaining S1 rows still need a board session and suitable current map content. Current OBCM is v19. The registered Grimsel fixture has one photo-bearing linked peak; the old multi-article v17 map cannot serve as current acceptance evidence. A separate Sol reviewer confirms this limit.

Local content preparation is complete and #2095 is closed. The initial pass finishes, then exactly one retry resolves all 17 transport failures. Two fresh offline compiles produce byte-identical 1,331-file trees: 1,453 usable landmark records, 2,492 language variants and 1,330 photos, totalling 81,068,551 bytes. A separate Sol reviewer accepts the complete provenance, category counts, current resource limits and actual hut/tower sources. The final evidence records all hashes and retained paths. #1805 and #2026 now link that result. Publication, fixture re-pinning, map builds and actual-content UI acceptance remain in #2026; this is separate from the remaining Peak View article checks.

Checks run:

• fix(firmware): restore neutral watchdog diagnostic #2156: cargo fmt -- --check in firmware/obc-fw-nrf54l, cargo check --bin obc-fw-nrf54l, cargo clippy --locked -- -D warnings, obc test affected --base origin/develop --dry-run, and git diff --check; selected CI also builds release firmware and checks default/debug-uart variants.
• docs: use release landmark compiler consistently #2160: python3 docs/build_docs.py --check-links, obc prose --check, obc docs check, and git diff --check; selected CI passes.
• Capture compiler: cargo build --locked --release -p obc-bake from pinned source; obc test -p obc-pack passes 462 tests. A bounded frozen Q176775 fallback case has byte-identical normal and photo-request outputs with the retained development and release compilers. This comparison alone is not country reproducibility evidence.
• Avoid repeated landmark photo preparation #2163: python3 -m unittest tools.tests.test_landmark_capture passes 29 tests; obc test -p obc-pack passes 463 tests; obc test -p obc-bake passes 96 tests; cargo clippy -p obc-pack -p obc-bake --all-targets -- -D warnings, obc suites check, cargo build --release --locked -p obc-bake, format and diff checks pass. Selected CI passes. A separate Sol reviewer confirms that a frozen full-country intermediate snapshot produces identical current-base and optimized content except the expected policy fingerprint, identical 1,316 RGB files, and exactly equal ordered lists of 1,056 photo requests. This is compatibility evidence, not final capture reproducibility.
• Landmarks: prepare local Swiss capture for expanded categories #2095 final: two normal landmark-content --snapshot …/manifest.json --boundary …/boundary.geojson --out …/first and --out …/second runs with the pinned release binary exit 0. The reviewed final validator exits 0. The linked evidence and retained receipts contain the exact resolved paths and commands.
• S1 source health: obc test -p obc-app passes 1,160 tests and one doctest; obc test -p obc-sim passes 74 tests.
• BLE guard: python3 -m unittest firmware.tools.tests.test_dependencies passes 14 tests; python3 firmware/tools/check_dependencies.py passes; locked all-feature board metadata excludes trouble-host/defmt and trouble-host/log.

No board, RTT, product-cable, iPhone, real-ride or Windows acceptance ran. For #2156, no local release/resource build or selected repository suite ran; the selected CI was the gate. No full-workspace local test run or final map/package build ran. No signing key, production content, installed card, public fixture registration or dependent map publication changed.