[man612]

Purpose

Review-and-test integration only — DRAFT, DO NOT MERGE. Combine the independent, still-unmerged Gnirehtet lifecycle PR #55 and native log privacy PR #59 on actual main after #57, #61 and #62. This addresses their real same-file conflict and gives hosted Windows CI an integrated codebase to validate.

• Lifecycle single-flight Start/Stop, pending Start cancellation, retained old child tracking on shutdown timeout, generation/identity-bound close and cleanup, and new relay blocked until stale cleanup finishes (PR fix(lifecycle): serialize Gnirehtet start/stop and isolate stale child exits (#53) #55).
• Known/structured ADB device ID redaction, bounded per-child/per-stream native stdout/stderr line buffers and redacted per-device returned IPC action errors (PR fix(privacy): redact device serials in Gnirehtet native process logs (#58) #59).
• Merged both test additions: 14 service scenarios (6 baseline + 5 lifecycle + 3 privacy) and 6 additional privacy helper tests. The PR fix(privacy): redact device serials in Gnirehtet native process logs (#58) #59 scenario tests now use Readable.emit('data', Buffer.from(...)) rather than incorrect .write().
• Copy of both historic QA checkpoints, new integration QA contract, and AGENTS.md preserving existing main Gnirehtet lifecycle: guard concurrent Start, Stop-during-Start and late child exits #53/ADB privacy and cleanup: mask device IDs in warnings, count successful force-stops #56 notes alongside fix(lifecycle): serialize Gnirehtet start/stop and isolate stale child exits (#53) #55/fix(privacy): redact device serials in Gnirehtet native process logs (#58) #59 notes. No package/binary/dependency changes.

Existing evidence: #55 individual Windows CI green, 51 Vitest tests; #59 individual CI failed TypeScript on test-stream .write(), now corrected at its source branch HEAD. These are NOT proof this combined branch passes. Use this Draft PR's own CI as the next gate.

Release blockers remain: no tested real Windows Gnirehtet child shutdown/late-close/retry, real Android USB/VPN/TUN RX/TX, complete PII sanitizer proof, or approval to integrate UX #50 and startup #51. No global/shared ADB kill, other app reverse cleanup, Windows installer or main merge has occurred.

Keep #55 and #59 Draft/open until combined tests and maintainer's merge plan are independently accepted. This is not a release PR.

[man612]

Verified hosted Windows CI — 2026-10-28

The exact integration commit 62d0a8003f62244467eb123e70cb00a8ef01a470 finished GitHub Actions run #40624716806 with SUCCESS, and the job's full decoded log was inspected:

• Lint — SUCCESS.
• npm run typecheck — SUCCESS.
• Vitest — 62/62 PASS across 9 files; gnirehtetService.scenario.test.ts has 14/14 PASS and gnirehtetLogPrivacy.test.ts 6/6 PASS.
• Renderer/main build — SUCCESS.
• Windows electron-builder --win --dir unpacked package smoke — SUCCESS.

This proves that the combined lifecycle #55 + privacy #59 source builds and passes mocked scenarios on hosted Windows. It does not demonstrate correct real Gnirehtet child shutdown timeout, physical USB Android VPN connectivity, or absence of all possible PII. Issue #44's startup delay is separate. Keep DRAFT and UNMERGED pending authentic Windows/Android QA and an explicit integration/merge decision. This comment supersedes the older checkout-time statement in the QA checkpoint that CI had not yet run.

[man612]

2026-10-28 additional source-confirmed device Start/Stop race, fixed only in Draft integration #63

New audit discovered a gap beyond PR #55's start() cancellation: startDevice() can await adbService.ensureServerReady(), then stop() completes, and the stale device start still invokes gnirehtet start DEVICE, returning success: true. The exact startDevice() method body from Draft PR #63 was executed in an isolated JS harness with a pending fake ADB promise: after simulating Stop completion, releasing ADB yielded 1 stale device command + success=true. No real phone/serial/ADB was touched.

Proposed fix at PR #63 head 97538ee28b95ee920d1090843b08f3f0b28b033b: capture relay child identity and lifecycle generation before awaiting readiness, decline cancelled device starts after each await; track pending per-device start command promises and wait for those already dispatched to settle before stopAllClients() completes final cleanup. Add two fake-process regressions: Stop during device ADB readiness and Stop while an already dispatched device-start command is delayed. CI on this exact integration head is in progress; tests must not be called passed before GitHub reports it. Real Windows/Android device parity still pending; a lingering device command may delay Stop for up to its configured timeout. This is a safety-oriented fail-closed choice, not a universal cancellation of a native subprocess. Keep main and PR #55 unmodified; original issue #53 stays open.

[man612]

2026-10-28 final CI checkpoint: additional device-Start-vs-Stop race FIXED in Draft integration

Head 97538ee28b95ee920d1090843b08f3f0b28b033b of this Draft PR #63 completed GitHub Actions Windows run 40625799886 with SUCCESS, confirmed by full job step outcomes and decoded Vitest logs:

• Lint — PASS
• TypeScript typecheck — PASS
• Vitest — 64/64 PASS in 9 files; Gnirehtet service scenarios 16/16 PASS (including two new per-device Start vs Stop regressions); native log privacy helpers 6/6 PASS
• Main/renderer build — PASS
• Unpacked Windows package smoke — PASS

Additional vulnerability confirmed before the fix: a device-specific startDevice() awaiting ADB readiness could execute its native device command and report success after Stop had already finished, bypassing previous protections that only guarded engine start(). Exact unmodified source method was reproduced with a fake ADB promise, synthetic ID and process; it dispatched one stale device command after simulated Stop.

Fix commits 5bfe285 and 97538ee: capture native relay child identity and lifecycle generation; reject device operations that became stale while awaiting ADB or a command; keep a set of pending device-start operations and drain operations already dispatched before final stopAllClients() cleanup. This retains the prior PR #55 generation controls and PR #59 output privacy.

Limitations: the in-flight native command cannot itself be synchronously cancelled; Stop can therefore be delayed until it finishes or hits its per-command timeout. Mock/CI success does not prove Android VPN state, active USB Gnirehtet relay behavior, TUN RX/TX or complete personal-data redaction. A noninvasive check of authorized Windows host YASMAN found zero running Wirebound, Gnirehtet and adb processes, so we did not start global/shared ADB or interfere with any VPN to attempt hardware QA. No app installed, no merge/release, and current main remains unchanged. Keep this PR DRAFT until genuine isolated Windows + one-phone validation and explicit merge approval.

[man612]

2026-10-28 physical USB/ADB QA preflight — BLOCKED (device not enumerated in ADB)

After the maintainer reported connecting their physical phone, a read-only status preflight was conducted on their authorized Windows workstation (no app install, no global ADB kill, no VPN changes):

• Wirebound, Gnirehtet, ADB running-process counts were all 0 before the test.
• Standard local ADB TCP port 5037 was not listening before the test.
• ADB executable existed at the known platform-tools location.
• Windows present-device query did not return an entry matching the Android/Motorola/ADB device name filter; absence of that name alone does not conclusively prove absence of USB enumeration.
• Tested via private ADB server port 15379, with no serial numbers printed, by querying adb devices: command exited 0, device count 0. Thus neither device nor unauthorized was reported.
• A port-specific shutdown command for the temporary server was issued in finally; the QA PowerShell process completed with exit code 0. The standard ADB port and any unrelated process were not touched.
• Since the phone did not appear in ADB, no native Gnirehtet start/stop, Android VPN permission, USB tunnel, TUN RX/TX, reconnect or live shutdown-timeout testing was attempted. No real device IDs or support logs were captured.

Outcome: Android USB QA is BLOCKED by USB/ADB detection, not PASS or FAIL of the PR #63 tethering code. Next action for maintainer: unlock the phone, confirm Developer options → USB debugging, respond to any Android USB debugging RSA authorization dialog, check Windows USB data cable/mode/driver, then rerun a strictly isolated ADB enumeration before proceeding. Do not confuse adb devices zero results with the software's VPN working/failing.

Earlier exact-head PR #63 hosted Windows CI run 40625799886 remains green: 64/64 tests, lint, typecheck, build and package smoke, but that CI does not substitute for physical USB QA. Keep PR Draft, do not merge/release.

[man612]

2026-10-29 USB recheck — Windows sees a portable Android-related device, but ADB still sees zero

On the authorized Windows host YASMAN, read-only process preflight showed no Wirebound/Gnirehtet/ADB processes. ADB enumeration was repeated using a temporary isolated server on port 15379; adb devices exited successfully (0) but returned 0 device rows (no device, unauthorized, or offline). The temporary QA ADB server received a port-specific shutdown and its shell completed successfully; the ordinary server/port and any VPN were not touched.

A separate Windows Get-PnpDevice -PresentOnly check found one Android-related WPD (Windows Portable Devices) entry, status OK and two generic USB entries, status OK. Thus Windows recognizes at least a portable-device interface, but this does not establish an authorized Android Debug Bridge interface. Likely next diagnostics are USB debugging activation/RSA prompt, USB mode, or ADB driver/interface recognition; avoid declaring a defective cable solely from this evidence. The user must confirm authorization on their phone.

Physical Gnirehtet/VPN/TUN testing remains BLOCKED, not a product pass/fail. No serial/USB instance IDs were printed in the QA record, no app install, no merge. PR #63 remains draft; previously recorded hosted-Windows mock CI 64/64 is separate evidence.

[man612]

2026-10-29 physical handset preflight — ADB AUTHORIZED, shell verified (no VPN test)

On authorized Windows computer YASMAN, a fresh check via a temporary isolated ADB server on port 15379 found exactly one authorized Android USB device (adb devices exit code 0, state device). No device serial was printed or stored. A second read-only adb shell roundtrip succeeded (known echo sentinel returned expected value). The phone identifies as Motorola moto g45 5G, Android 15 / SDK 35. Windows has Node v24.21.0 and Git installed; no Wirebound/Gnirehtet/ADB process was running during preflight.

After each ADB check, adb -P 15379 kill-server was sent only to the temporary QA server and the command completed. The default ADB server, the installed Wirebound profile, USB reverse mappings, the Android VPN, and user network traffic were not intentionally altered.

Outcome: the previously blocking USB/ADB enumeration and RSA authorization gate is now PASS. Real Gnirehtet autorun/Stop/Retry, VPN prompt, TUN traffic, device detachment and crash/timeout recovery are NOT RUN. Keep Draft PR #63 unmerged until an isolated exact-HEAD Windows QA build and physical VPN/network acceptance are executed. Current PR head is 97538ee28b95ee920d1090843b08f3f0b28b033b, hosted CI 64/64 PASS remains separate evidence.

[man612]

2026-10-29 live Motorola / Gnirehtet 2.5.1 QA: ADB PASS, VPN BLOCKED, cleanup verified

Authorized Windows host YASMAN and one Moto g45 5G Android 15 (SDK 35). These native hardware trials used the already-existing Gnirehtet Rust v2.5.1 + ADB 37.0.1 in an isolated F: QA package, NOT the exact built implementation of PR #63. No private Android serial or native raw error log was committed or posted.

Read-only baseline: one authorized ADB device, adb shell roundtrip pass; Gnirehtet APK already installed, targetSdk 29; no existing Gnirehtet Android process, no reverse mapping and relay TCP port 31416 free.

First exploratory attempt: temporary script mistakenly set ADB_SERVER_PORT=15379; this does NOT override ADB 37's port. A QA-bundled adb server unexpectedly listened on default 5037, while the dedicated QA port was also in use. Native relay opened but no Android VPN/client/tunnel appeared; Gnirehtet stop returned failure. Verified the default-port adb was QA-owned by path/start time and had zero established clients, then targeted its exact PID for cleanup. No unrelated ADB was touched.

Correct isolation: changed runner to ANDROID_ADB_SERVER_PORT=15379 (the AOSP ADB port variable). Verified that an unqualified ADB command subsequently used 15379, detected one authorized device and left 5037 closed. With that correction, two bounded live gnirehtet autorun tests successfully opened the native relay TCP listener at 31416, but the Android Gnirehtet client was not detected as running in the 18-second observation, adb reverse --list did not show localabstract:gnirehtet, and no VPN transport was reported. gnirehtet stop returned success; however, an Android Gnirehtet process was seen transiently immediately after Stop and remained present at the final test's later cleanup. Used targeted adb shell am force-stop com.genymobile.gnirehtet only for that app after confirming it was still running. Verification afterward: Android Gnirehtet process absent, reverse absent, VPN transport absent.

Final host safety: Gnirehtet Windows processes 0; ADB ports 5037 and 15379 not listening, relay 31416 not listening. No installed Wirebound app/profile changed, no global/shared ADB server killed, and no other VPN or Android app intentionally modified.

Outcome: USB authorization and native Windows relay listener pass. Actual Android VPN activation, traffic routing/TUN counters, retry and PR #63 live lifecycle correctness remain BLOCKED / NOT VALIDATED. Coarse native error categories and filtered Android logs did not identify a definitive root cause; need maintainer confirmation of VPN permission prompt and bounded, sanitized, stage-specific native diagnostics before another live attempt. Do not infer Android 15 incompatibility or a PR #63 regression without evidence.

Local QA checkpoint (not committed) is F:\Wirebound-Lab\qa-tools\GNIREHTET_NATIVE_QA_2026-10-29.md; runner in same directory. Hosted CI on PR #63's current head 97538ee remains green 64/64 but is separate mocked evidence. Keep PR Draft, no merge/release.

[man612]

2026-10-29 Android VPN prompt confirmation and diagnosis checkpoint

The maintainer confirmed that NO Android VPN permission dialog appeared during the earlier physical Motorola moto g45 5G / Android 15 Gnirehtet native autorun trials. This is important new physical QA evidence; it does not distinguish a previously approved VPN from failure to reach the permission screen.

Reviewed the upstream Gnirehtet v2.5.1 Android client implementation GnirehtetActivity.java: startGnirehtet() calls VpnService.prepare(this); if it is null, logs VPN was already authorized and starts GnirehtetService without a popup. Otherwise logs VPN requires the authorization from the user, requesting... and launches an authorization activity. GnirehtetService.java may subsequently log VPN starting failed, please retry if Builder.establish() returns null. Thus absence of popup ≠ proof that the phone denied permission or ADB failed.

A very similar upstream issue #515 includes Motorola + no prompt, but no verified explanation has been demonstrated for this specific phone. Separate Android OEM WRITE_SECURE_SETTINGS errors are documented upstream, yet were not confirmed here; do not recommend granting insecure privileged permissions or mass reinstall/reset on speculation.

Attempted an additional read-only isolated ADB inspection of appops/installed package/VPN state and filtered Android log summaries. Windows host was responding too slowly (~77s without tool output), so the session was intentionally terminated without usable data. A subsequent non-destructive final host check completed: ADB processes = 0; Gnirehtet processes = 0; ports 5037/15379/31416 not listening. No further VPN Start/Stop run or host/profile changes occurred.

Next safe QA needs stage-specific evidence: a bounded, in-memory, redacted and structured log capture recording GnirehtetActivity Received request, VPN was already authorized vs VPN requires..., GnirehtetService Received request ... START_VPN, VPN starting failed, and shell activity launch return category. Never publish raw device serials, other app data or arbitrary logcat; preserve redaction and strict output limits. Only retry native VPN after verifying the phone's current VPN authorization state and agreeing on narrowly scoped live testing. Do not merge #63 or claim hardware success; CI 64/64 previously passed but live Android VPN is still BLOCKED.

[man612]

2026-10-29 Gnirehtet VPN status check — previously authorized, but disconnected

Maintainer checked Android VPN settings and confirmed the Gnirehtet entry reads “Tidak terhubung” (Disconnected). This is direct UI evidence, not an inferred status. Authorized YASMAN Windows workstation subsequently completed a read-only ADB QA on temporary port 15379 after one initially unsuccessful bounded ADB enumeration. Final successful check:

• adb devices: one device, authorized.
• adb shell cmd appops get com.genymobile.gnirehtet ACTIVATE_VPN: success, reported ACTIVATE_VPN: allow (interpreted only as Android AppOps allowing VPN activation, not as an active tunnel).
• adb shell pidof com.genymobile.gnirehtet: no active process returned.
• adb shell dumpsys connectivity: command succeeded, and the coarse VPN transport pattern check reported no active VPN transport.
• The dedicated QA ADB server was sent -P 15379 kill-server, and the QA process exited successfully. No native Gnirehtet start/stop, phone VPN permission change, revoke, reconnect, reinstallation, user profile edit or global ADB kill was performed in this follow-up.

The user also confirmed no VPN permission dialog appeared during native Gnirehtet tests. The AppOps result now supplies a plausible, stronger explanation: permission was already allowed. Gnirehtet's VpnService.prepare() can return null if permission exists, so absence of popup is NOT the current root-cause evidence. What remains blocked is client VPN service activation / relay tunnel formation on Moto g45 Android 15 when driven by the older native Gnirehtet 2.5.1 CLI. The issue has not been isolated to PR #63 code, because this phone test did not use a PR #63 build. The 64/64 Windows CI remains a separate mocked check.

Next stage should collect only narrowly filtered, privacy-safe GnirehtetActivity / GnirehtetService stage markers and Android ActivityTaskManager failure categories, without recording full logcat or device serials; do not repeatedly restart the VPN without observing why it failed. PR stays Draft/unmerged.

[man612]

2026-10-29 stage-marker native QA (one bounded retry) — Android VPN still blocked

A new bounded, in-memory diagnostic runner at F:\Wirebound-Lab\qa-tools\gnirehtet-stage-probes-20261029.cjs exercised the existing Gnirehtet 2.5.1 packaged runtime, NOT a PR #63 app build, with one authorized Motorola Android 15 and isolated ADB ANDROID_ADB_SERVER_PORT=15379. No full device serial or native/logcat raw lines were copied into the report.

Results: 1 authorized device; native relay TCP 31416 listener active after 12 seconds; Android Gnirehtet app process not detected at sample, Gnirehtet ADB reverse absent, VPN transport absent. Filtered logcat -d -t 1800 -v epoch request succeeded, but our post-start epoch filter matched zero rows. This is an inconclusive instrumentation/window result (not proof there were no Android errors); none of the bounded Rust output classification patterns matched. Native stdout/stderr chunk counts were 7/5, without storing raw output. The runner also has a diagnostic variable nativeExit='not_spawned' that is not a reliable process spawn-state indicator, because it is never updated on successful spawn. Do not misinterpret that label.

The native Gnirehtet CLI stop completed with success, but an Android Gnirehtet process was still detected afterward. A targeted adb shell am force-stop com.genymobile.gnirehtet completed; relay port was then confirmed closed. QA ADB server -P 15379 kill-server was issued, and the runner completed successfully. Subsequent Windows preflight confirmed 0 ADB processes, 0 Gnirehtet processes, with port 5037 not listening (remaining two port checks still in progress at the moment of note). No unrelated user VPN, installed Wirebound profile, ADB global server or production app was intentionally changed.

Existing result: Gnirehtet VPN AppOps ACTIVATE_VPN: allow and Android VPN settings Disconnected. Therefore no user permission popup is expected, but app/service stage still unexplained. Do not use repeated live Start/Stop or speculate Android 15 incompatibility without narrow evidence. Next diagnostics should correct the logcat timestamp boundary, run read-only activity/service state or capture filtered logcat at the same time as startup with adequate timeouts, and verify exact source branch build separately. Hardware VPN acceptance remains BLOCKED; PR #63 remains Draft/unmerged; hosted CI 64/64 PASS is separate.

[man612]

2026-10-29 root cause of isolated hardware QA failure FOUND; native Android VPN connection PASS with single-device run

Upstream source-confirmed discovery: Gnirehtet Rust adb_monitor.rs method track_devices() hardcodes 127.0.0.1:5037 for host:track-devices, ignoring the ADB CLI's ANDROID_ADB_SERVER_PORT. Our past QA launches of gnirehtet autorun on isolated ADB port 15379 could start the Windows relay TCP listener, but the monitor could not discover the authorized handset from the nondefault server. That explains the past QA isolation failures; it is NOT evidence of an Electron PR #63 regression, since Wirebound's default ADB server is intended to run on 5037.

Upstream main.rs cmd_run() directly executes async_start() on one device and bypasses the hardcoded monitor. Exercised native Gnirehtet Rust v2.5.1 using gnirehtet run -d 8.8.8.8 -p 31416, with ANDROID_ADB_SERVER_PORT=15379, one authorized Moto g45 5G Android 15, no existing Gnirehtet process, VPN or reverse, while capturing narrow Android logcat tag classes live. No Android serial or raw logs were emitted to the QA report.

Live native test PASS (single-device pathway): Windows Gnirehtet relay listener true; Android client process true; Gnirehtet ADB localabstract:gnirehtet reverse true; Android VPN transport true. Android logcat classification: ACTIVITY_START_RECEIVED, SERVICE_START_RECEIVED, VPN_PERMISSION_ALREADY_ALLOWED, VPN_TUNNEL_CONNECTED. 11 filtered log lines seen, 0 logcat errors. Rust classification: checking APK, starting client, starting relay server; no native stderr chunks in that successful test. The user's earlier “VPN listed but disconnected / no popup” is consistent with app preauthorization.

Shutdown: gnirehtet stop returned success, Windows relay was killed (our child PID only) and logcat listener was killed, Android Gnirehtet app still existed immediately afterward so targeted force-stop of only com.genymobile.gnirehtet was performed. A transient reverse mapping was seen immediately after Stop; a separate isolated, authorized follow-up verified reverse absent, Android app process absent, VPN transport absent, Windows TCP 31416 closed, default ADB 5037 closed. QA server port 15379 was also shut down. All other apps, VPNs, system/global ADB sessions were preserved. Note: the source CLI's stop does not itself remove the reverse mapping; Wirebound's AdbService.stopAllClients() is designed to target-clean Gnirehtet reverse mappings. Do not claim clean native Stop-only behavior; cleanup needs end-to-end PR #63 validation.

Still NOT proven: actual internet byte transfer / IPv4 TCP HTTPS over the VPN, TUN RX/TX changes, installed Wirebound/Electron PR #63 UI, PR #63 native Stop/Retry behavior. The successful test used the already-present Gnirehtet executable from an older F: QA package, not a rebuilt PR #63 Windows binary. Main branch unchanged; keep PR #63 Draft/unmerged.

Local QA runner: F:\Wirebound-Lab\qa-tools\gnirehtet-single-device-stage-20261029.cjs. Next: obtain a bounded HTTPS probe from Android through the active VPN and TUN counters if available, then build/validate the exact PR #63 under isolated QA without modifying the ordinary Wirebound profile or globally killing ADB.

[man612]

2026-10-29 hardware acceptance update: Gnirehtet native VPN + HTTPS + TUN bytes PASS

A follow-up bounded, isolated, one-device test using the pinned Gnirehtet Rust v2.5.1 runtime (older F: QA package; not a PR #63 Electron build) ran gnirehtet run -d 8.8.8.8 -p 31416 with ANDROID_ADB_SERVER_PORT=15379. Verified one authorized Motorola Android 15 handset, native TCP relay listening, Android Gnirehtet app process active, localabstract:gnirehtet ADB reverse present and Android VPN transport active.

Proof of real phone network traffic: Android /system/bin/curl, executed through isolated ADB with --connect-timeout 4 --max-time 9 -sS -L -o /dev/null -w '%{http_code}' https://example.com, succeeded with HTTP 200. Android /proc/net/dev was readable, and the VPN tun* receive bytes and transmit bytes both increased from immediately before to after the HTTPS request. These are stronger native connectivity signals than merely a Windows relay listener or VPN badge. No real serial, raw terminal/logcat dump, private IP, response body or packet data was exported. Filtered live Android logcat reported START activity, START_VPN service, VPN previously authorized and relay tunnel connected.

Stop and isolation: gnirehtet stop succeeded, then the specific Android Gnirehtet process still seen immediately afterward was force-stopped only for com.genymobile.gnirehtet. adb reverse --remove localabstract:gnirehtet removed only that QA mapping. Independent post-test verification: Windows Wirebound/ADB/Gnirehtet process count 0, TCP listeners on 5037/15379/31416 all absent, Android app process absent, Gnirehtet reverse mapping absent, VPN transport absent, authorized handset still visible, QA ADB server stopped. No unrelated VPN or ADB session was stopped.

Source-confirmed reason previous autorun QA failed: Rust AdbMonitor::track_devices() connects to 127.0.0.1:5037 unconditionally, so isolated ADB port 15379 cannot drive autorun device discovery; one-device run bypasses that monitor. This is a QA isolation property, not proof of a Wirebound production failure using its standard 5037. No new dependency upgrade, app installation, userData changes or merge.

Durable in-repo record: new docs/qa/GNIREHTET_MOTOROLA_NATIVE_QA_2026-10-29.md, plus updated AGENTS.md on this Draft branch. Exact current head after docs d9937c99144b26708d28c74d25a2918c866f0b28. Older PR #63 code head 97538ee passed Windows CI 64/64; native CLI connectivity does not validate the PR #63 Electron process lifecycle, UI Start/Stop/Retry or shutdown races. Draft stays open/unmerged. Next mandatory gate is an isolated exact-HEAD PR #63 Windows build + one-phone app-level QA on its expected default ADB port with explicit process ownership boundaries.

[man612]

2026-10-29 exact-head Windows QA preparation — checkout verified; local build status UNKNOWN after host disconnect

Following the native Motorola Android 15 Gnirehtet VPN + HTTPS 200/TUN RX/TX success, prepared a separate local Windows QA checkout:

• Host YASMAN was online for preflight; no Wirebound/Gnirehtet/ADB/Electron process, and ADB 5037, QA 15379 and relay 31416 ports were unoccupied at that time.
• Clean, shallow Git checkout: F:\Wirebound-Lab\qa-pr63-20261029; HEAD verified exactly d9937c99144b26708d28c74d25a2918c866f0b28, then current Draft PR test(integration): lifecycle #55 + Gnirehtet log privacy #59 on current main #63 head; source tracked files clean before build.
• package-lock.json Git blob SHA a3810f5731543e195216d395d3149948f57c88fd matches the existing clean local dependency checkout on D:. Rather than time-consuming npm ci, created a junction F:\Wirebound-Lab\qa-pr63-20261029\node_modules pointing to D:\Projects\wirebound-ux-review-20261021\node_modules (Electron 44.4.1). Do not recursively delete, clean, or robocopy through this junction.
• Copied pinned Gnirehtet 2.5.1 and platform-tools 37.0.1 runtime files and .runtime-versions marker into the QA checkout's existing bin directory without overwriting tracked bin/README.md. No dependency upgrade, system app installation or changes to ordinary Windows Wirebound profile.
• Hosted Windows exact-head GitHub Actions run 40818104050 has completed SUCCESS (lint/typecheck/64 Vitest/build/package smoke), independently of the local host.

Local build was started, in the isolated checkout, using npm.cmd run build (Desktop Commander session PID 13632). The Windows host then stopped responding to process-output queries and Desktop Commander YASMAN device 3dbbefa3-4477-4684-ba12-2eb531e1b92f showed OFFLINE. The attempt to terminate only that own session failed because the device was offline. Therefore local build result, child process status and presence of local build outputs are UNKNOWN. Do not mark it as a pass or failure, or assume the process was terminated. It is unsafe to schedule another heavy build or use npm ci while the host is in this state.

Immediate next check when host is accessible: inspect session PID 13632 and related node.exe/npm process tree without killing unrelated processes; verify checkout HEAD, out/main/index.js and out/renderer/index.html, and whether the original build is still running. Only if fully clean, continue with local unpacked packaging under this QA path, and independently verify a QA-only userData profile on F: before executing Wirebound; Electron's Windows default userData is appData plus app name. Avoid touching the existing user's real profile; preserve only Gnirehtet reverse mappings. Native Android/USB/HTTPS testing was previously completed in separate QA, but the PR #63 Electron app has NOT run on real hardware.

No merge/release; PR #63 remains Draft.

[man612]

2026-10-29 local build recovery — OWN QA SESSION termination requested, no app-level hardware test

Follow-up after earlier local preparation note: YASMAN briefly came back online. read_process_output for the exact-HEAD local npm.cmd run build session (Desktop Commander session PID 13632) still returned zero new lines, and list_sessions showed it still running after approximately 482 seconds. To avoid worsening the already-slow Windows workstation, I invoked force_terminate for that specific session 13632 only. The desktop tool confirmed “Successfully initiated termination of session 13632”. This confirms the termination request, not necessarily all descendant npm/node processes; do not infer recursive child cleanup.

I did not delete any files, recursively clean the node_modules junction, run npm ci, reset source, run a second build, install the app or start another ADB/VPN session. A separate non-destructive inspection of local build outputs was started but still had not produced usable results. Local build success/failure and whether an orphaned child process exists are unverified. Keep QA checkout F:\Wirebound-Lab\qa-pr63-20261029 with source HEAD d9937c99144b26708d28c74d25a2918c866f0b28, copied pinned runtimes, and the junction to D:\Projects\wirebound-ux-review-20261021\node_modules intact.

Hosted Actions at exact same PR head 40818104050 PASSED, but the PR #63 Electron app's live hardware Start/Stop/Retry remains NOT RUN. Next safe session must first inspect process ownership and build outputs, then choose an appropriate low-impact or hosted build transfer; preserve isolated APPDATA/LOCALAPPDATA and verify Electron's userData before launching. Continue to treat native Gnirehtet HTTPS 200/TUN RX/TX as separate verified success. PR stays Draft and unmerged.

[man612]

2026-10-29 actual packaged PR #63 Electron lifecycle QA — Windows PASS (no USB phone)

New source-of-truth document: docs/qa/PR63_PACKAGED_WINDOWS_ENGINE_SMOKE_2026-10-29.md, also linked in the updated AGENTS.md.

• The local Windows build had hung without output, so a separate workflow-only temporary Draft PR #66 was created at source head d9937c9; verified GitHub diff changed only CI artifact upload (10 YAML lines), no app code. Hosted Windows run 40820151487 passed lint, typecheck, 64/64 Vitest, build, packaged smoke and upload. Downloaded immutable qa-pr63-win-unpacked artifact ID 12873643698 via authenticated GitHub CLI to F:\Wirebound-Lab\qa-packages\pr63-hosted-20261029; verified wirebound.exe SHA256 f0b48fd16373ab10f9c5e88054852bcb890ec1c52f95414b96f76a0c37053392, ASAR SHA256 a140a6f8bb438894e77c968c22c1bc8abbc33ea1fd44ca5e4ef00d9b85389935, bundled Gnirehtet/ADB hashes. Unsigned unpacked QA only, no installation.
• Launched the real packaged Electron app with QA-only F: APPDATA/LOCALAPPDATA/TEMP and --user-data-dir under F:, loopback-only CDP for exercising the real renderer-exposed window.api. Positive profile-isolation proof: onboardingCompleted read false until seeding F: qa-profile\Chromium\settings.json, then read true. autoStart:false, telemetry disabled. Renderer version 1.2.0, title Wirebound, preload API works. No normal user settings saved.
• Actual packaged main/native relay lifecycle PASS: two sequential Start/Stop cycles, each opened relay TCP 31416, then Stop returned success, relay closed and engine state returned disconnected. Three concurrent Start IPC calls all returned success followed by successful Stop and no relay. Nearly simultaneous Start/Stop both completed; relay closed, status disconnected after settling. No unverified claim about exact native process spawn count under concurrent calls.
• USB hardware gate NOT RUN: at the time of app testing, renderer ADB snapshot 0 devices, ordinary 5037 adb devices 0, Windows Android/Motorola/ADB/MTP PnP presence 0. No real device VPN, TUN, HTTP or Android cleanup was tested through PR test(integration): lifecycle #55 + Gnirehtet log privacy #59 on current main #63 app. Earlier separate native CLI Gnirehtet test remains PASS on Motorola Android 15 (VPN, HTTPS HTTP 200, TUN RX/TX).
• Verified cleanup: after engine Stop, no Gnirehtet process or relay port remained. Terminated only the five F: QA executable processes; a single default-port ADB server was confirmed from F: QA LOCALAPPDATA runtime path with exclusive listener and zero established connections, then stopped by exact PID, not global adb kill-server. Final check: 0 Wirebound/Gnirehtet/ADB processes, no TCP listeners 5037/15379/31416/19665. Neither installed Wirebound nor personal userData was used for QA actions.
• Temp QA PR #66 CLOSED UNMERGED after artifact retrieval. Integration PR test(integration): lifecycle #55 + Gnirehtet log privacy #59 on current main #63 still DRAFT and UNMERGED. Source files remain unchanged since the tested d9937c9; later PR test(integration): lifecycle #55 + Gnirehtet log privacy #59 on current main #63 commits 224cfa3 and 258f630 add QA documentation/agent notes only. Current Windows CI for those documentation heads is in progress; prior app-source CI and temporary QA packaging run were green.

Next real hardware acceptance: restore one authorized Motorola on default ADB 5037, then exercise full app Start/VPN/HTTPS/TUN/Stop/Retry and UI clicks with privacy-safe evidence. Do not mistake successful native CLI or no-phone app engine smoke for that outstanding gate. No merge/release.

[man612]

2026-10-29 major milestone — actual packaged PR #63 Electron + Motorola VPN/HTTPS: 2/2 FULL CYCLES PASS

This is NOT merely mock CI or native Gnirehtet CLI: hosted Windows-packaged Wirebound v1.2.0 source from d9937c9 (artifact from workflow-only QA PR #66, Actions 40820151487) was launched on authorized YASMAN Windows from the unpacked, unsigned F: QA folder, with redirected F: APPDATA/LOCALAPPDATA/Chromium profile and autoStart/telemetry disabled. QA workflow differed only in CI artifact upload; app code unchanged. New durable exact hardware QA record and updated AGENTS.md.

Physical Moto g45 5G / Android 15, exactly 1 USB-authorized device; two full, consecutive cycles driven through actual packaged app renderer window.api IPC:

• Baseline engine disconnected, Android Gnirehtet process / reverse mapping / VPN absent, no competing VPN session.
• Each startGnirehtet('8.8.8.8','31416') success:true, Windows TCP 31416 relay listening, Android Gnirehtet process running, localabstract:gnirehtet reverse mapping present, Android VPN transport present, and Wirebound engine API status connected.
• Each Android /system/bin/curl https://example.com probe returned HTTP 200 (body discarded), while VPN tun* RX and TX counters both increased.
• Each stopGnirehtet() success:true, relay port closed, app engine disconnected, Android Gnirehtet process absent, reverse mapping absent, VPN transport absent. No force-stop or manually removing reverse mapping was necessary in these app-level cycles.
• Second complete cycle verified restart/reconnect after a clean Stop, but not a physical click of the UI Retry button.

Safety: No real serial, private IP, raw native logs, HTTP content, or arbitrary phone data published. After the app tests, stopped only 5 F: QA wirebound.exe processes, then stopped only the confirmed F: QA-owned default 5037 ADB PID after verifying no established clients and no native Gnirehtet process. Independent final check: 0 Wirebound/Gnirehtet/ADB processes, no listener at 5037/15379/31416/19665. No user installation/profile, unrelated ADB/VPN, dependency upgrades, or main branch changes.

Remaining untested: literal UX button clicks/animation, tray Quit, unplug-while-connected, fail-closed native process timeout, physical per-device Start/Stop overlap, and multiple physical phones (one-phone limit noted). Renderer read-only API access was sometimes sluggish; issue #44 startup remains open, do not mistake inspection elapsed time for exact window timing.

Source status: original tested application code d9937c9; a verified GitHub compare from d9937c9 to the then-head 258f630 showed only AGENTS.md plus the earlier QA doc; subsequent commits merely added this hardware QA document/AGENTS note. PR #63 stays DRAFT/UNMERGED; no release/merge approved.