diff --git a/docs/bugs.md b/docs/bugs.md
index 8a646deb9..eb7bd9d2d 100644
--- a/docs/bugs.md
+++ b/docs/bugs.md
@@ -23,13 +23,14 @@ shard run reported as exit 0, 7a7e873).
 | 4 Oct 2026 | PC 2 came back on 0.3.4 (the canary) and its card's OTA state read "none" | the OTA state parsed only `OTA: …` lines, and the install lines sit in the previous run's log file; the new run only says `update check: 0.3.4 is current (manifest 0.3.4)` | 797a844 then 2nd commit: every update line the app logs (`is available: downloading`, `downloaded and verified`, `is ready; it installs at the next safe moment`, `installing`, `update to X complete`, `is marked failed`, `has no build yet`, `is current`) is parsed and the newest decides the state; the Mac's card had read "0.3.3 is current" from a 70-minute-old check while 0.3.4 was downloaded, verified and staged | test: staged beats the older check, a finished run reads current, a newer OTA line wins, failed and updated; live cards after the deploy |
 | 4 Oct 2026 | the live 0.3.3 Mac bundle's `Info.plist` said 0.3.2 while the engine reported 0.3.3 (Finder and Get Info showed the wrong version) | the 0.3.3 cut was by hand and the plist was not bumped | nothing to do: 0.3.4 was cut by `tools/ship-app.mjs`, which bumps the six version files, and its plist says 0.3.4 | `PlistBuddy` on the staged 0.3.4 bundle |
 | 4 Oct 2026 | 0.3.4 reports `igneumd/2.1.0-73fc2fd` on Windows and `-1b65132` on the Macs; neither is a fork commit (both are igneum-repo commits), so the suffix says nothing about the node source | the fork's `build-info/build.rs` looks for a `.git` directory; a worktree's `.git` is a file, so the walk climbs into the vendoring igneum repository and embeds its HEAD; then it reads `.git/HEAD` as a path, which a worktree lacks | fork branch `bugfix-build-info-worktree` (vendor/igneum-node-bughunt, commits 92e1b030 and its follow-up): the root is any `.git`, the HEAD file comes from `git rev-parse --absolute-git-dir`, the ref from `--git-common-dir`; for the main session to merge into devnet-v4 and finality-fixes (the fork has no remote) | `cargo build -p kaspa-build-info` in the fixed worktree embeds the fork's `92e1b030` and watches the worktree's HEAD; the unfixed devnet-v4 worktree embeds the outer repo's `ebce665` and watches the outer repo's files |
-| 4 Oct 2026 | PC 1's card went from "installing 0.3.4" to "none" while the install was still stuck (the Windows helper bug, 0d123b3) | the app uploads at most the last 256 KiB of its log (262,144 chars per upload on PC 1) and a PC logs every block, so an update line leaves the parsed tail in about 30 min | 699d0d8: `console_ota_memo` keeps the last OTA state per machine and app run, written when a parse finds one and read back for the same run when the tail has none; a relaunch starts clean (0855c44 widened the SQL window first, which cannot help against the upload cap) | after the deploy all five machines carry memo rows and the cards read installing (PC 1), staged (PC 37ba0461), updated (the rest) |
+| 4 Oct 2026 | PC 2's card went from "updated 0.3.4 @20:41" to "none" by 21:12 while nothing had changed on PC 2 | the console parsed the last 60 KB of the app upload and a PC logs every block, so an update line left that window in about 30 min; the app itself uploads at most the last 256 KiB (262,144 chars per upload on PC 1), the hard cap | 699d0d8: `console_ota_memo` keeps the last OTA state per machine and app run, written when a parse finds one and read back for the same run when the tail has none; a relaunch starts clean (0855c44 widened the SQL window first, which cannot help against the upload cap) | after the deploy all five machines carry memo rows and the cards read installing (PC 1), staged (PC 37ba0461), updated (the rest) |
 
 ## Open
 
 - INCIDENT 20:45 UTC, CLOSED 21:00: Sam's Mac (3a9bf309) quit for the 0.3.4 install at 20:45:03 and its run began at 21:00:05 (15 min; this Mac took the same bundle in 2 s). Its `ota-apply.log` (collect job `collect-sam-ota-034`) shows the helper verified, swapped and saw "0.3.4 is running" within seconds, so the gap is between a process the helper matched and the engine's first log line: a first-launch prompt on that Mac or a first launch that died before logging; the app logs nothing until the engine is up. Open for the main session: the host should log the moment it starts and the helper the pid it matched (app code). Console #309 and #312.
 - Nothing ties a shipped node binary to a fork commit: `payload-inputs.json`'s `node_source_commit` is the fork HEAD at push time, `igneumd --version` prints no hash. With the build-info fix the log header carries the fork commit; the ship tool could then compare both platforms' headers with `--node-commit` (main session).
 - The observer's proving endpoint is the Mac app's node (`IGNEUM_EVM_RPC` default 127.0.0.1:26800, by design): every app restart or quit blips the proving feed (11 `fetch failed` lines at 20:57:04 during this Mac's OTA); the observer's own node has no `--evm-rpclisten` (devnet node owners).
+- Windows OTA wording (0.3.4, PC 1 at 21:31:52 UTC): after 15 minutes without word from a per-user installer that never ran (0d123b3, DETACHED_PROCESS), the app logs "administrator approval not given … the update waits for the next time someone is at this PC" and the card reads "waiting for approval"; there was no prompt to answer. For 0.3.5: say "the installer never reported" (app code).
 - `ota-apply.sh` (embedded in `app/igneum-app/src/ota.rs`) logs `chdir: error retrieving current directory: getcwd` because it runs with the old bundle's directory as cwd and moves it aside; harmless; a `cd /` at the top removes it (app code, for the main session).
 
 - Sam's Mac (3a9bf309): CLOSED 19:15 UTC; the console side (stopped versus silent) shipped in 4d208c9. Earlier note: CLOSED 19:15 UTC, the app came back on 0.3.3 and mines (11.4 MH/s): it was stopped by its user for 4.5 h. What stays: the last node upload (14:47:02 UTC) ends with `SIGTERM - shutting down` and `igneumd has stopped`, the miner upload stops at 14:46:56, nothing after: a clean app-driven stop (quit or Stop), not a crash and not a network loss (the stop lines reached the intake). Its app predates the app-log upload (`app ?` on the console), so there is no app stream to say which. The app posts nothing on a clean quit, so the console shows "silent 4h" for a machine that was stopped on purpose. Proposed: one `[ok] app quit by the user` line uploaded before the engine stops, and the console card saying "stopped (quit) at 14:47" instead of "silent".