Main's windows-client build has been red since #230 merged: 99eb679c wired the learned management port through every client and its own message records the hole — "NOT verified: the Windows client (192.168.1.133 unreachable)". The Windows usage sites landed; the three definitions they lean on existed nowhere.
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 ("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 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.
The windows-client job on this PR is the verification 99eb679c could not run.
Main's `windows-client` build has been red since #230 merged: `99eb679c` wired the learned management port through every client and its own message records the hole — "NOT verified: the Windows client (192.168.1.133 unreachable)". The Windows usage sites landed; the three definitions they lean on existed nowhere.
* `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 ("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` 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.
The `windows-client` job on this PR is the verification `99eb679c` could not run.
99eb679c wired 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 verification 99eb679c could not run.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Main's
windows-clientbuild has been red since #230 merged:99eb679cwired the learned management port through every client and its own message records the hole — "NOT verified: the Windows client (192.168.1.133 unreachable)". The Windows usage sites landed; the three definitions they lean on existed nowhere.clients/windows/src/trust.rsre-exports core's trust surface —learn_mgmt_portwas added to core but never joined the re-export list (hosts.rs:729, E0425).mgmtTXT thatpf_client_core::discoveryalready parses —DiscoveredHostgains the field, parsed the same way (hosts.rs:725/727/1062, E0609).HostTargetnever carried the port, so theTargetthe shell builds from aConnectPlanhad nothing to read (mod.rs:414, E0609). WiredFrom<&KnownHost>likemac; the two spawn-path literals stayNone— a spawn plan never fetches the library, and each shell resolves the port itself at its fetch site.The
windows-clientjob on this PR is the verification99eb679ccould not run.