Session Handoff [rv3028-eeprom]: No upstream movement; the two held MeshCore bugs drafted fork-only as #26 and #28 #29

Next steps, in priority order

1. Sweep every upstream PR and issue authored by ptr727. The commands are in link Session Handoff [rv3028-eeprom]: All upstream PRs answered; watch for maintainer review #18, step 1. Anything with updatedAt after 2026-10-10T00:00Z is new; the sweep on 2026-10-10 found nothing after the 2026-10-08T14:33Z description edit on Read and write the RV3028 clock atomically, and reject switchover-garbled transfers 🤖🤖 meshcore-dev/MeshCore#3421. Done means each maintainer comment is answered, or put to Pieter as a dialog.
2. #3421 is converged at 0f038054, and the RV3028 position stays FROZEN. Change code only if a maintainer requires it or a test fails, and park every other finding for Pieter. Any code change re-runs the full acceptance matrix A-H on the exact commit before it is pushed. After that, ask Pieter in a dialog to re-request Copilot in the web UI, with the URL.
3. When Read and write the RV3028 clock atomically, and reject switchover-garbled transfers 🤖🤖 meshcore-dev/MeshCore#3421 or #3545 merges, rebase the other. They conflict in AutoDiscoverRTCClock::begin(), though each merges cleanly onto dev.
   • Store RV3028 backup switchover and trickle charger config in EEPROM 🤖🤖 meshcore-dev/MeshCore#3545 still calls rtc_rv3028.set24HourMode() in begin(), and Read and write the RV3028 clock atomically, and reject switchover-garbled transfers 🤖🤖 meshcore-dev/MeshCore#3421 removed it on purpose, so the rebase must keep it removed.
   • If the rebase lands on Read and write the RV3028 clock atomically, and reject switchover-garbled transfers 🤖🤖 meshcore-dev/MeshCore#3421, re-run the matrix under step 2's rule.
4. The two formerly held bugs are now fork drafts, and stay fork-only (Pieter, 2026-10-10: "Draft on fork only"). File them upstream only once a maintainer engages with any of our open upstream PRs, and only after asking Pieter. Each needs a clean fix/ branch cut from its work branch first.
   • CLI reply bound: issue CommonCLI bounds replies at 160 bytes, but every caller gives it at most 158 #25, iteration PR Bound CommonCLI replies at the 157 bytes every caller can give (iteration branch) #26 (work/cli-reply-bound).
   • Stored out_path_len: issue A damaged stored out_path_len makes every DIRECT reply to that peer drop before sending #27, iteration PR Forget a stored peer path whose length byte is invalid (iteration branch) #28 (work/stored-path-len).
5. Keep Read and write the RV3028 clock atomically, and reject switchover-garbled transfers 🤖🤖 meshcore-dev/MeshCore#3421's description of the other two projects accurate. Edit it only with Pieter's go, using fully qualified owner/repo#N references, and tell the peer session afterwards.
6. Parked for Pieter, not code:
   • RTClib's DS3231 now() ignores the 12-hour flag. Revisit after the RTC PRs land.
   • In every MeshCore version, an RV3028 that doesn't ACK at boot is never probed again until a reboot. Pieter chose no shared boot-recovery rule on 2026-10-10, so this stays documented only.
   • The companion's CMD_ADD_UPDATE_CONTACT takes out_path_len from the app's frame unchecked. It's out of A damaged stored out_path_len makes every DIRECT reply to that peer drop before sending #27's scope and left for a separate decision. ZephCore tracks its own copy as CMD_ADD_UPDATE_CONTACT stores the app's out_path_len unchecked liquidraver-ZephCore#57.
   • The sensor list and neighbours loops stop at a fixed 134 bytes. They're out of CommonCLI bounds replies at 160 bytes, but every caller gives it at most 158 #25's scope, and the neighbours loop isn't audited.
7. Cleanup stays deferred ("Watch only"). Keep the hardware builds and worktrees until a PR merges or is declined.

External blockers

• MeshCore maintainers: review of Read and write the RV3028 clock atomically, and reject switchover-garbled transfers 🤖🤖 meshcore-dev/MeshCore#3421, Adopt an RTC only if its time registers read like that chip 🤖🤖 meshcore-dev/MeshCore#3544, Store RV3028 backup switchover and trickle charger config in EEPROM 🤖🤖 meshcore-dev/MeshCore#3545, Write and read the RX8130CE WEEK register as one-hot 🤖🤖 meshcore-dev/MeshCore#3550, Reject a negative sensor list start index 🤖🤖 meshcore-dev/MeshCore#3433 and Pass TELEM_RAK12500_ADDRESS to the RAK12500 I2C probe 🤖🤖 meshcore-dev/MeshCore#3434, plus Do not feed an invalid GPS time into the RTC 🤖🤖 meshcore-dev/MeshCore#3422, Make GPS status reporting say what was actually checked 🤖🤖 meshcore-dev/MeshCore#3423 and Treat the GPS enable pin as a pin number, not a truth value 🤖🤖 meshcore-dev/MeshCore#3425 (draft). Nothing is owed from our side.
• Copilot re-request upstream: after any upstream push it still needs Pieter in the web UI. On the fork, pr_review.py wait requests it.
• Counterparts: drivers: rtc: rv3028: reject time accesses cut short by a switchover zephyrproject-rtos/zephyr#121389 and drivers: rv3028: disable backup switchover during EEPROM access zephyrproject-rtos/zephyr#121252 wait on Zephyr reviewers. Each peer session owns its own.

Internal dependencies

• Step 3 waits on an upstream merge, and step 4 on a maintainer engaging.
• A Read and write the RV3028 clock atomically, and reject switchover-garbled transfers 🤖🤖 meshcore-dev/MeshCore#3421 code change must finish its matrix run before step 3's rebase.

State

Re-derive all of this; it was true on 2026-10-10.

• Upstream dev is at 2dbd463e, unchanged since link Session Handoff [rv3028-eeprom]: meshcore-dev/MeshCore#3421 description now tracks liquidraver/ZephCore#106; boot-recovery facts sent to Zephyr #24, and the fork's dev mirror is synced to it. All six fix branches still merge cleanly onto it.
• Fork drafts: cut from dev 2dbd463e. The worktrees are worktrees/meshcore-dev-MeshCore-cli-reply and worktrees/meshcore-dev-MeshCore-path-len. The host harnesses are ~/meshcore-harness/cli-reply-bound-harness.cpp and stored-path-len-harness.cpp, with constructed inputs only. Builds pass for the repeater, room server, sensor, companion and terminal chat envs, as each PR lists. Neither was tested on hardware.
• Counterparts:
  • ZephCore: rtc: write the RTC time only for years 2000-2099 liquidraver/ZephCore#105 and [Feature Request] Get meshcore:// map link from serial console meshcore-dev/MeshCore#106 are MERGED.
    • The CLI and ClientACL fixes are already in ZephCore dev (liquidraver/ZephCore@ad23dcb, liquidraver/ZephCore@fcfee67).
    • Its companion-loader and add-contact gaps are Companion contact load takes a stored out_path_len unchecked; an invalid one sends replies as zero-hop direct liquidraver-ZephCore#56 and [Enhancement] add ability to sign data in companion fw. meshcore-dev/MeshCore#57, fork-only.
  • Zephyr: drivers: rtc: rv3028: reject time accesses cut short by a switchover zephyrproject-rtos/zephyr#121389 at 82e160257cc and drivers: rv3028: disable backup switchover during EEPROM access zephyrproject-rtos/zephyr#121252 at 751beb04cba, both open. Copilot's 2026-10-08 summary on #121389 still lists the year-2000 thread (4188740984) as open, though it's answered. The Zephyr session has been told.
• Host: server-3, native Debian, with no usbipd. USB tooling now lives in the HomeAutomation-Config repo, USBDev/ (read its README). usbdev nrf52 touch replaces the old touch scripts but is untested on hardware. USB tooling problems are filed on ptr727/HomeAutomation-Config, with synthetic examples only. The board map is ~/usb-devices.md.
• Hardware: unchanged. The MeshCore test board is still on the acceptance build local/hw-accept (src/ identical to 0f038054).

The parked decision queue

0 parked. This round's four dialog questions were all answered (boot-recovery rule, held bugs, Zephyr note, this handoff).

What the last round did

• Swept upstream: no activity since link Session Handoff [rv3028-eeprom]: meshcore-dev/MeshCore#3421 description now tracks liquidraver/ZephCore#106; boot-recovery facts sent to Zephyr #24.
• Synced the fork's dev to 2dbd463e.
• Got Pieter's answers to four dialog questions:
  • No shared boot-recovery rule.
  • Draft the held bugs on the fork only.
  • Tell the Zephyr session about the stale finding.
  • Write this link.
• Drafted both held bugs as fork issues and PRs, each with a host harness and builds. Copilot ran on both.
• Told the peers: the Zephyr session about its stale finding, and the ZephCore session about both drafts. ZephCore filed its own gaps as Companion contact load takes a stored out_path_len unchecked; an invalid one sends replies as zero-hop direct liquidraver-ZephCore#56 and [Enhancement] add ability to sign data in companion fw. meshcore-dev/MeshCore#57.

What not to repeat

• A Bash call that ends with a cd into the primary checkout gets git add blocked by the guard, even when the git add itself targets a worktree. Run git with -C <worktree>, and put gh calls in a separate invocation.

New learnings

• In MeshCore, an invalid path_len never goes on air. Dispatcher::sendPacket() frees it, whereas ZephCore sends zero-hop direct. The reply is lost either way.