3.5 KiB
Applied Wi-Fi and Linux control-path contract R7
The owner UI attempt on R6 confirmed K1 station Wi-Fi with an assigned private address. The network operation succeeded; its owned read-only control bootstrap then failed with TypeError. The terminal attempt is network_applied, side_effect_status=applied, stage=control-bootstrap-failed. This differs from the preceding pre-dispatch Bluetooth failure. A repeat provisioning write is not the appropriate next action.
Reproduced implementation defect
HostWifiAssociationProbe defines observe(interface_name, *, timeout_seconds). The real service _sample_host_path calls that positional interface contract. LinuxWifiAssociationProbe instead declared interface_name keyword-only. Consequently every real Linux service path observation raised TypeError before examining Ethernet/Wi-Fi or probing the K1 control endpoint. The earlier adapter test called observe by keyword and therefore missed this consumer boundary.
A new test invokes the actual service host-path and correlated TCP observation with the real Linux adapter and synthetic OS route/sysfs/TCP endpoints. Before the fix it reproduces TypeError at facade.py:_sample_host_path. The Linux adapter now accepts the existing protocol signature. Stable Ethernet reaches a single TCP probe without nmcli or host association; a route change across that probe still fails closed. The caller, route fingerprints, supervisor, Wi-Fi protocol, application authority and MQTT/Rerun profiles are unchanged.
Operator continuation and messages
The modal previously displayed read-only verification only for network_outcome_unknown, leaving an applied network without its prescribed next action. It now exposes Check K1 state whenever the backend permits that read-only action for the explicitly selected device, including an applied or restored configured network. No credentials are required and the existing verification contract remains fenced by runtime/mode/discovery/target. The ordinary check still submits one explicit provisioning intent; final Connect still only completes a currently verified dialog.
Messages in the modal use SettingsCard align=center. The canonical Design Guideline change is 5b882bc3d9b13a86e6c26111ef5ded687ea3a2fc, including registry, documentation and a catalog example. Centered cards omit an empty body and center their content on both axes; ordinary settings groups keep their existing start layout. No local CSS override, fixed height, new colors or decoration. Node packaging pins this exact DG source.
Validation and pending physical acceptance
The failing reproduction is retained privately. After the fix: 18 NodeBridge / package lifecycle checks passed, four applied-network bootstrap lifecycle checks passed, 23 focused frontend/architecture checks passed and 794 full Core frontend tests passed. Changed Linux/backend files pass Ruff. DG ui-react build, catalog typecheck and registry validation passed. Production package and installation results follow separately.
Node 0.8.5 and K1 0.1.4 are reserved for this source. The next owner UI test must clear browser cache, select K1 and use read-only Check K1 state to observe the already applied network. It must prove DeviceInfo/control readiness before claiming Bridge or live acceptance. Private screenshot, exact operation, UTC/monotonic manifest and hashed logs are retained under private/acceptance/k1-node085-20260907-core-ui. No agent CLI BLE/MQTT commands were sent. Publication of prior installation reports remains blocked by the earlier automatic review decision; no remote push workaround is used.