Make peer host updates reconcile manifests and embedded artifacts atomically #562

Activity

1. DRSDavidSoft

   added

   ⚡ priority: highImportant near-term implementation workImportant near-term implementation work

   🖥️ hostPC host, CLI, TUI, or libraryPC host, CLI, TUI, or library

   🧪 testingAutomated, simulated, UX, or hardware verificationAutomated, simulated, UX, or hardware verification

   🏗️ tooling-buildBuild scripts, dependencies, packaging, and developer toolingBuild scripts, dependencies, packaging, and developer tooling

   domain: integrationCross-process, cross-host, Pealayer, transports, and shared contractsCross-process, cross-host, Pealayer, transports, and shared contracts

   on Sep 30, 2026
2. DRSDavidSoft commented on Sep 30, 2026

   

   DRSDavidSoft

   on Sep 30, 2026

   Last edited by DRSDavidSoft

   CollaboratorAuthor

   More actions

   Live regression found during native CAFE self-update

   On 2026-09-30 the native updater transferred and verified the exact merged executable (b0462d91701e898d82b2758bc52379a8c83980aefcf4895e630b2d72839ac37d) and relaunched a healthy primary, but the replacement initially came up in Windows session 0 instead of preserving the signed-in desktop session 4. This left the Web/API healthy while the visible console/TUI silently disappeared.

   Required alongside the manifest/artifact reconciliation already specified here:

   • preserve or explicitly re-establish the signed-in interactive TUI surface after activation;
   • report old/new Windows session IDs in update progress and the authoritative host inventory;
   • treat a healthy session-0 primary without the previously active session-4 TUI as degraded, not fully terminal-verified;
   • test updates initiated through a local SSH/CLI delegate while the actual primary/TUI owns an interactive desktop session;
   • never rely on a permanent scheduled-task workaround.

   Immediate recovery was non-destructive: the canonical default command was launched once in signed-in session 4 through a temporary interactive task, and that task was then removed. The session-0 replacement exited during takeover. Current verified state is one canonical controller.exe in session 4, owning TCP 8787 and the full TUI/primary lifecycle.
3. DRSDavidSoft

   added

   🚧 in progressImplementation is actively underwayImplementation is actively underway

   🐛 regressionKnown defect or behavior regressionKnown defect or behavior regression

   on Sep 30, 2026
4. DRSDavidSoft commented on Sep 30, 2026

   

   DRSDavidSoft

   on Sep 30, 2026

   CollaboratorAuthor

   More actions

   Three-host native updater retest on final main

   The final 5806d0ff host executable (71f536d2bd3a434b3e9715ed996ac9143f72188102e08f2288b53ac0da14dc6d) was delivered entirely through the Go updater:

   • DAVID -> CAFE: op-65f4adee0fd4553b, terminal verified
   • CAFE -> ERFAN: op-0b7f0beb50bd0b4f, terminal verified
   • DAVID local primary: op-ea6a7ae2b4acb3fd, terminal verified

   This CAFE replacement correctly returned as the sole canonical controller.exe in signed-in Windows session 4, so the prior invisible-session regression did not reproduce in this run. TUI ownership, HTTP 200, board connection, and Pealayer recovery were all verified afterward.

   The issue must remain open: CAFE's disk bin/host-manifest.json still describes old executable 9716018248aa50ca7525b64a7f187de9e36cb29bb519ec3413c4f40107705cb2, while the authoritative live manifest correctly reports 71f536d2.... Native executable replacement is reliable, but atomic package/sidecar reconciliation and explicit interactive-session acceptance are still required exactly as specified above.
5. DRSDavidSoft commented on Sep 30, 2026

   

   DRSDavidSoft

   on Sep 30, 2026

   CollaboratorAuthor

   More actions

   Live peer-update verification exposed the installation-inventory drift described by this issue.

   • Source DAVID-PC artifact SHA-256: 08E9BB67271414C8B5EE1A557A7B1F12E0646E7C84A5D6D88842014E53F925C3 (6,426,624 bytes).
   • Transfer was performed through controller exec peer-update host cafe-pc ..., not manual binary copying.
   • Peer operation: op-603f09151db95366; terminal state completed; terminal_verified: true; detail says the peer restarted and acknowledged the exact active SHA-256.
   • CAFE-PC now has one running canonical controller process at C:\Users\Asus\AppData\Local\Programs\PCController\bin\controller.exe, exact matching SHA-256, and /healthz returns { "ok": true }.
   • Regression/evidence: controller installation status reports healthy: false because installation-package.json still expects the preceding executable size (6,395,392 bytes), while the peer-updated executable is 6,426,624 bytes. The updater commits the executable but does not reconcile the durable installation inventory/state.

   Acceptance must therefore include: after the peer has acknowledged the exact running executable, controller installation status is healthy and the canonical package/inventory points to the exact active artifact without weakening integrity checks.
6. atomicdeploy commented on Oct 13, 2026

   

   atomicdeploy

   on Oct 13, 2026

   Owner

   More actions

   Fresh read-only verification reproduces the inventory ambiguity while active RF gesture work is preserved: running executable fingerprint996E1C1B matches the artifact in the active679 worktree, but build info has no VCS revision and adjacent development host-manifest source/build metadata differs from the live source fingerprint. Artifact correspondence alone is not exact build/deployment provenance. Current process health and authenticated board snapshot succeed; that does not prove package coherence. No inventory regeneration, integrity bypass, overwrite, downgrade or runtime mutation was performed by this source lane. Sole runtime owner retains current learned records, new16 gesture bindings and recall settings. Required next source action remains an atomic hash-bound updater/package reconciliation with interrupted-update regressions; exact final tested merged679+681+683 package must be distinguished from the independently active development executable.
7. atomicdeploy commented on Oct 14, 2026

   

   atomicdeploy

   on Oct 14, 2026

   Owner

   More actions

   Fresh read-only live audit: canonical current running EXE differs from controller.exe digest in installed installation-package.json; installed host-manifest still reports an earlier embedded firmware and skipped local tests. Health and a bounded authenticated status probe succeed, but stale sidecar must not be treated as source/deployment identity. Sole runtime owner notified; no installer trust bypass, sidecar rewrite, output action, restart or reset from source lane. Exact tested merged main93cc package build1608 is available; legitimate owner must reconcile full package inventory/provenance before claiming deployment.
8. DRSDavidSoft commented on Oct 26, 2026

   

   DRSDavidSoft

   on Oct 26, 2026

   CollaboratorAuthor

   More actions

   Additional live updater verification gap found during synchronized-playback repair (2026-10-27): on-disk controller.exe/artifact inventory named the new ci.1647 bytes, while the old ci.1631 TUI still owned the actual HTTP listener and board. The old executable had been renamed during replacement; its canonical path now resolved to the new file. A digest of that path therefore did not identify the running image. The replacement could survive as a secondary, acknowledge health, then disappear without becoming the primary.

   The LIVE /api/ui-config compiled identity exposed the old host_version/source_hash, while /api/artifacts/manifest exposed the new on-disk digest. The responsible owner identified that self-update health acknowledgement is scheduled before primary acquisition/listener publication, and completion verification trusts shared artifact inventory.

   Please include this in #562 acceptance: acknowledge only after the candidate owns the primary/listener, bind completion to the candidate's compiled identity and stable live PID as well as the exact artifact SHA, and regression-test an old healthy primary plus a surviving replacement secondary. A renamed running image/path hash must never count as proof of candidate activation. Preserve unsaved terminal work; do not solve this by force-closing an unapproved healthy TUI.

   For this repair the user explicitly approved old-console closure; it exited gracefully and subsequent updates are checked against the actual listener, ping PID and compiled identity. That operational recovery does not fix this updater-source gap. Playback evidence/coordination: ToghrolTP/pealayer#80 (comment). Keep this source follow-up separate from the frozen serial-reservation candidates in #701.