Lahfir 030a565011 chore: merge main into the windows adapter branch ... v0.8.1 adds `launch --cdp`, which launches a Chromium app fresh with the remote-debugging switches and returns a verified DevTools endpoint. The claim that this leaves Windows untouched is nearly right, and the part that is wrong is small but worth stating. `LaunchResult` gained `cdp`, `renderer` and `suggestion`, so the Windows launch had to populate them; core fills `cdp` and `suggestion` itself after the adapter returns. `--cdp` genuinely works on Windows, and this was verified rather than assumed. Core pushes `--remote-debugging-port` and `--remote-debugging-address=127.0.0.1` into the launch args and probes the loopback endpoint itself, and Windows already passes `options.args` to `CreateProcessW` - none of that path is platform-gated. Driving an Electron target on this box returned a real `cdp.port`, `cdp.websocket_url` and `product: Chrome/142.0.7444.265`. What does not cross is renderer detection. macOS reads it from the bundle; Windows reports nothing, so `renderer` is absent there and the unprompted nudge core derives from it - launch a Chromium app *without* `--cdp` and be told to close and relaunch with it - never fires on Windows. The same target launched without `--cdp` here returned neither field. An agent not already told to ask for `--cdp` therefore walks a dense Electron tree on Windows where macOS would have redirected it. Docs follow the measurement rather than the assumption. The conflict resolution first carried a "(macOS)" caveat on the `--cdp` example; the endpoint test disproved it and it is gone. `commands-system.md` now says `--cdp` is platform-neutral and that `renderer` is not, and warns that an absent `renderer` on Windows means undetected, never "not Chromium" - the inference that would send an agent down the slow path. `docs/phases.md` records the divergence in the 2.15 catalogue on the same normalize-or-ratify terms as its siblings, noting that the detector is available rather than missing: 2.4 already ships Chromium recognition by window class, so the open question is which signal to read when a launch may report no window at all. Conflicts were the two skills docs, both additive; the Windows launch paragraph and main's new CDP section both survive. Gates: core 1002, windows 1051, binary 140, FFI passthrough 8 tests pass; clippy -D warnings clean; fmt, file-size, no-phase-reference and Win32_UI_Shell gates pass; cbindgen --verify reports no drift; core names no platform crate.		2026-08-14 00:30:56 -06:00
..
examples
src	chore: merge main into the windows adapter branch	2026-08-14 00:30:56 -06:00
build.rs
Cargo.toml