enricobuehler
2b066b3e11
windows-client / client (arm64, --no-default-features, aarch64-pc-windows-msvc, C:\t-a64) (pull_request) Successful in 2m50s
ci / rust-arm64 (pull_request) Successful in 2m40s
ci / bun-nix (pull_request) Successful in 3m13s
ci / docs-site (pull_request) Successful in 4m3s
ci / web (pull_request) Successful in 4m5s
android / android (pull_request) Successful in 5m48s
windows-client / client (x64, , x86_64-pc-windows-msvc, C:\t) (pull_request) Successful in 6m21s
ci / rust (pull_request) Successful in 11m34s
99eb679cwired the learned management port through every client, and its own commit message records the hole: 'NOT verified: the Windows client (192.168.1.133 unreachable)'. The Windows shell's usage sites landed, but the three definitions they lean on did not exist anywhere, so main's windows-client build has been red since the merge of #230: * clients/windows/src/trust.rs re-exports core's trust surface — learn_mgmt_port was added to core but never joined the re-export list (hosts.rs:729, E0425). * The Windows shell's own mDNS browser (discovery.rs, 'ported verbatim from the GTK client') never learned the mgmt TXT that pf_client_core::discovery already parses — DiscoveredHost gains the field, parsed the same way (hosts.rs:725/727/1062, E0609). * HostTarget ('the host a plan dials') never carried the port, so the Target the shell builds from a ConnectPlan had nothing to read (mod.rs:414, E0609). Wired From<&KnownHost> like mac; the two spawn-path literals stay None — a spawn plan never fetches the library, and each shell resolves the port itself at its fetch site. cargo fmt --all --check clean. pf-client-core/linux/session compile via the rust CI job; the windows-client job on this PR is the verification99eb679ccould not run.