Fresh-start validation runbook

Status: hardware flow complete through FS-118; v0.1.0-rc.1 publication and clean, zero-device installation are verified in FS-119. FS-120 records a post-release local-file permission hardening. This document records the operator-led procedure; it does not authorize a router, controller-data, RF, or package change.

Validation rows are chronological. A Waiting or pending status records the hold at that moment; later numbered rows supersede it and do not rewrite the historical checkpoint.

Rules

• Work on one router at a time. Do not start the next router until the current router reaches its stated hold point.
• Stop at every human confirmation gate. Silence, navigation, discovery, inspection, or continuing adoption is never consent.
• Keep router backups outside the repository. They contain credentials and network identifiers; never inspect, attach, log, or commit them here.
• Record only sanitized evidence. Exclude IP/MAC addresses, hostnames, SSIDs, serial numbers, public addresses, passwords, keys, tokens, and backup names.
• A manual workaround is evidence, not a product fix. Reproduce it, define its rollback, then expose it through an explicit supported UI path or reject it.
• Declining an optional change must leave the router unchanged and show the affected observation as unavailable or partial, never as an empty network.

Change classes

Class	Runs or persists where	Consent and current contract	Rollback
Controller software	Controller host only: Go daemon, embedded UI, database, and keyring	Installed and started by the operator. Router discovery and Inspect are read-only. The database and keyring are a matched recovery pair.	Stop the controller; restore or remove the explicitly named controller data pair only after a destructive confirmation.
Router controller access payload	/usr/share/rpcd/acl.d/oonfeewrt.json plus the scoped config login 'oonfeewrt' in /etc/config/rpcd	Adoption's checkbox is unchecked by default and Adopt remains unavailable until accepted. Acceptance sends acknowledge_router_changes:true, installs or replaces the ACL, creates the scoped login, and grants documented reads plus writes for controller-owned network/wireless/firewall/DHCP sections during a later acknowledged Apply and runtime 802.11k neighbour-list updates. It cannot disconnect or steer clients and installs no package, binary, daemon, service, or firmware.	Un-adopt reverts owned UCI sections, then—after a fresh administrator credential—deletes the scoped login before the ACL. Report any residue.
Optional package or service	Router official package feed and named OpenWrt service	None is part of default adoption. The LLDP option first refreshes the package index under an explicit acknowledgement and displays the exact package-manager plan; a second acknowledgement installs official-feed lldpd and enables/starts only lldpd. A credentialed read-only plan separately identifies physical interfaces, and changing only lldpd.config.interface requires another unchecked acknowledgement. Never run an opaque script, custom feed, package upgrade, or firmware change.	Schema 17 records the full package before-state, actual added-package diff, prior service state, exact UCI baseline/applied exports, and operation state. Removal is separately planned/acknowledged, drift-checks and restores the UCI baseline, removes that exact controller-added set, keeps every pre-existing package, restores and independently verifies the final lldpd service/package state, and must finish before un-adoption.
RF scan	Existing OpenWrt iwinfo.scan; no installed artifact	Manual only. A separate unchecked acknowledge_disruption:true gate must say that clients on the radio may disconnect. ACL installation never starts a scan.	No artifact to remove; retain the bounded scan result/failure record.
Managed configuration	Router UCI configuration owned by the controller	Preview and Apply are separate. Show the exact diff and affected routers before Apply; a capability acknowledgment does not authorize configuration.	Revert from the ownership ledger and verify the committed result.

Package-backed functionality must use official OpenWrt feeds. Functionality that requires a custom router agent, daemon, firmware fork, kernel module, or opaque payload is out of scope; record the gap instead of installing it manually.

Gates

0. Protect recovery material

• [x] Operator reported that every pre-reset router backup was downloaded.
• [x] Move the archives outside runtime state to ignored, access-controlled local storage.
• [x] Confirm the archives are not tracked or staged without opening them.
• [x] Confirm which physical router is Router 1 without recording its identifier here.

Hold: no reset until every box above is human-confirmed.

1. Capture the pre-reset baseline for Router 1

Read-only collection only:

• firmware release/build and package-manager type;
• installed package names and enabled services;
• free overlay space;
• presence or absence of the ACL path and scoped rpcd login above;
• controller-owned configuration or other known residue.

Store a sanitized summary, not raw command output. Hash lists when exact before/after comparison is needed.

Hold: operator reviews the sanitized inventory and explicitly accepts any missing evidence before saying reset Router 1.

2. Factory-reset Router 1

• Reset only Router 1. Do not restore its backup.
• Configure only what stock OpenWrt requires for secure administrator access and controller reachability. Record every manual change in the log.
• Verify the capability ACL/login are absent and capture a new stock package, service, and configuration baseline.

Hold: stock baseline recorded; the other router remains untouched.

3. Start a fresh controller

• Record the source commit/build under test.
• Stop the controller before changing its data.
• Show the exact database/keyring/volume targets and the recovery copy.
• Delete or recreate controller state only after a separate destructive human confirmation; never keep a database with an unrelated keyring.
• Start the controller and create the first administrator through its normal UI.

Hold: clean controller starts without recovery, bootstrap, or console errors.

4. Prove read-only discovery and inspection

• Run on-demand discovery or add Router 1 by address.
• Run Inspect capabilities.
• Verify no SSH bootstrap, ACL/login, UCI write, package operation, inventory adoption, background scan, or RF scan occurred.
• Record denied/unknown sources as gaps, not negatives.

Hold: operator reviews the inspection result and router-side no-change proof.

5. Review and adopt

• Review Gateway, Access Point, and Switch selections.
• Confirm the router-capability option begins unchecked and Adopt is unavailable.
• Expand its disclosure. It must itemize the ACL path, scoped login, unlocked reads, administrator-credential use, preserved configuration, and rollback; it must say that no package, binary, daemon, service, or firmware is installed.
• If packages are offered, keep them unchecked and verify every field required by the package row above. A missing field is a failure; do not install.
• Only the operator may select the capability and press Adopt.
• Compare post-adoption package/service/config evidence with the stock baseline.

Hold: adoption and its exact router footprint are proven.

6. Validate features without hidden changes

Check controller session, inventory, presence freshness, topology provenance, clients, radios, logs, settings, policy Preview, and Apply disclosure. For every missing source, record whether the cause is controller code, ACL scope, a stock capability, or an optional official package. Do not widen the ACL or install a package during diagnosis.

RF scan is a separate test and hold point. Run it only after the operator reads and accepts its disruption warning.

7. Prove rollback

• Preview un-adoption and provide a fresh administrator credential only for the cleanup transaction.
• Verify owned UCI state is reverted, then the scoped login and ACL are removed.
• Verify no controller-installed package/service remains; never remove an item that existed in the stock baseline.
• Compare sanitized configuration, package, service, and artifact hashes.
• Record any residue before considering Router 1 complete.

Hold: only after Router 1 passes may the same gates begin for Router 2.

Warning and notice acceptance

• Non-blocking warnings/notices default to a concise summary, visually limited to two lines, with keyboard-accessible Show details / Hide details.
• Expanded text remains selectable and available to assistive technology.
• Counts and affected sources belong in the summary when they change meaning.
• Destructive, credential, install, Apply, and RF-disruption confirmations must keep the action, target, impact, default-off state, and rollback visible; the essential disclosure must never be hidden by truncation.
• Audit every signed-in desktop route in dark and light themes. Mobile is deferred to the planned UI overhaul.

Validation log

Add one row per observation. Evidence must be sanitized and reproducible.

ID	Gate	Observation and expected result	Class	Remediation/product decision	Status
FS-001	0	Router archives, package inventories, and a consistent controller database/keyring/passphrase backup were moved to ignored, mode-restricted local storage. SQLite integrity check returned ok; archive contents were not inspected.	Safety	Preserve this directory when runtime state is cleared; copy it to separate encrypted storage before final cleanup.	Verified locally
FS-002	1	Sanitized baseline: Archer C6 (US), hardware v2.8; LuCI model TP-Link Archer C6 v2/A6 v2; target ath79/generic; OpenWrt 25.12.5; kernel 6.12.94; 155 installed-package records.	Router baseline	Enabled-service, overlay-path, and exact ACL/login residue were not captured before reset. The full router archive preserves rollback state, but this remains an evidence gap.	Accepted evidence gap
FS-003	2	Archer C6 reset completed while isolated from the gateway. Default <management address>, blank root password warning, unchanged OpenWrt 25.12.5 build, and fresh uptime were observed.	Router reset	Keep isolated until secure first-run configuration.	Verified
FS-004	2	Pre/post package inventories are identical at 155 records. The controller ACL file and scoped rpcd login are absent after reset.	Capability residue	Prior controller use installed no package on this router; its ACL/login additions were overlay configuration removed by factory reset. Enabled-service comparison remains unavailable because it was not captured before reset.	Verified with accepted evidence gap
FS-005	1	WRT3200ACM baseline: mvebu/cortexa9, OpenWrt 25.12.5, kernel 6.12.94, 174 package records, 25 overlay file/link paths, controller ACL and scoped rpcd login present, and zero UCI sections carrying oowrt_owned=1. Enabled-service names were retained in the ignored evidence file.	Router baseline	Reset must remove the ACL/login. The lack of on-router ownership markers reinforces that adoption disclosure and the controller ledger are the authoritative change record. Preserve the inactive dual-firmware partition as recovery until the clean active-partition run passes.	Verified
FS-006	2	WRT3200ACM active-partition reset completed while isolated. Default <management address>, unchanged OpenWrt 25.12.5 build, and fresh uptime were observed. Pre/post inventories are identical at 174 packages and 27 enabled services; overlay file/link count fell from 25 to 22; controller ACL/login are absent.	Router reset	Prior controller use installed no package or enabled service on this router. Preserve the inactive firmware partition until the clean run and recovery checks pass.	Verified
FS-007	3	The validated controller process stopped cleanly. Active database, keyring, and passphrase were moved to ignored, mode-restricted rollback storage; every active source path is absent and the archived SQLite database reports integrity_check=ok.	Controller reset	Generate a new passphrase/keyring/database through the documented first-run path; never reuse one member of the archived identity set.	Verified
FS-008	3	A newly built controller started through the documented interactive passphrase path. Health reports ok; the new database/keyring are mode 0600; administrator, device, network, and WLAN counts are all zero.	Controller first run	Create the first administrator through the localhost UI without importing old state.	Verified
FS-009	3	First administrator was created through localhost and signed in. Device, network, and WLAN counts remain zero.	Controller first run	Proceed to explicit router security setup; do not adopt with a blank root password.	Verified
FS-010	4	Operator set a new WRT3200ACM root password while the reset router remained isolated, then verified authenticated SSH.	Router security	Keep the router isolated until the controller access payload and its exact permissions have been reviewed in the signed-in adoption screen.	Verified
FS-011	4	Controller restarted on the tested fresh-start-transparent-20260821 binary (sha256:76b2ba0e…) with the same new schema-16 data set; /healthz reports ok. After a full navigation, the live prompt is unchecked, Adopt is disabled, and the expanded review names the exact file/login, read scope, later acknowledged UCI writes, runtime 802.11k update, and excluded client-control/package actions.	Controller access-payload disclosure	Proceed only on the newest verified UI bundle; never accept the payload from a stale tab.	Verified
FS-012	4	The tab retained the pre-restart JavaScript bundle after the daemon changed and continued showing its older disclosure until a full navigation.	Controller upgrade UX	API responses now carry a per-process identifier. On a same-binary restart the untouched signed-in tab detected the changed identifier, reloaded, and presented the signed-out page rather than continuing stale state. Focused API/UI tests and production build pass.	Verified
FS-013	5	The first read-only WRT inspection rendered an access-denied radio inventory as Radios: 0, advised a never-adopted router to “Re-adopt”, and reported both allow-listed package-manager commands as NOT_FOUND. The reset WRT subsequently proved apk at /usr/bin/apk and no opkg, exactly matching the payload's primary package-inventory command.	Inspection truth and remediation	Radio count is now nullable; the probe falls back from denied iwinfo.devices to luci-rpc.getWirelessDevices; first-adoption and existing-device remedies are distinct. Focused capability/daemon/API/UI tests pass. No package or payload path change is required; reproduce the corrected inspection before adoption.	Fixed; clean UI reproduction pending
FS-014	5	Strict SSH verification rejected the WRT after reset because its ED25519 host key changed. The saved pre-reset key and the isolated router's current key have distinct fingerprints, as expected when factory reset regenerates Dropbear identity. The independently scanned current fingerprint exactly matched the value shown by the refused direct connection, and a subsequent strict SSH connection succeeded with the promoted dedicated trust file.	Router identity	Preserve the old dedicated trust file. Never modify the user's default known_hosts for this test.	Verified
FS-015	5	A new controller artifact, dev-schema16-fresh-start-transparent-v3 (sha256:b2e454c6…), was built with the corrected nullable/fallback radio inspection and first-adoption remediation copy after the reset WRT proved its package-manager path. The process-boundary sign-in reset worked. Repeated read-only inspection reported two radios, four LAN ports, wan, DSA, DHCP-derived Gateway evidence, and recommended Gateway + Access point + Switch while the payload remained unchecked and Adopt disabled.	Inspection clean-run artifact	Preserve this as the clean reproduction of the radio-count and first-adoption fix.	Verified
FS-016	5	The corrected inspection still exposed raw file.exec: NOT_FOUND and session.access protocol text. The router separately proved /usr/bin/apk exists, so the raw package result could be misread as a missing package manager; the scan result likewise did not prove missing RF support.	Inspection warning truth	Both branches now state that the current inspection credential could not prove package/scan access, that no scan ran, and that this is not evidence of missing router support. They explain that accepting the optional payload enables a post-adoption re-probe. Normal/race regressions and a clean v4 UI inspection pass.	Verified
FS-017	6	Immediately before adoption, the live default-off disclosure identifies the exact ACL file and scoped login, read-only inventory/topology/radio/scan/log/fixed-target ICMP scope, controller-owned UCI writes gated by a later Preview + acknowledged Apply, and optional 802.11k neighbour-list updates. It states that adoption installs no package, binary, daemon, service, or firmware and does not change network, WLAN, firewall, or DHCP settings. The operator explicitly selected this consent; Gateway, Access point, and Switch remained selected. Adoption completed and the controller stored one adopted Gateway/AP/Switch. Live verification found the exact embedded ACL hash, scoped login present, packages unchanged at 174, enabled services unchanged at 27, zero controller-owned UCI sections, and zero pending UCI changes.	Router access-payload consent	Preserve these counts and hash as the clean-run access-payload contract.	Verified
FS-018	6	The post-adoption probe successfully read installed packages but still marked RF scan authorization undetermined with JSON-RPC -32602. The ACL already grants both session.access and iwinfo.scan. OpenWrt's HTTP ubus bridge rejects an ubus_rpc_session field inside call arguments because it injects that reserved field from JSON-RPC parameter zero itself.	HTTP ubus request correctness	The duplicate reserved argument is removed from capability probing and RF-scan preflight. The mock reproduces the stock bridge rejection. Normal/race focused tests pass. A live read-only re-probe under dev-schema16-fresh-start-transparent-v5 (sha256:ba87a470…) changed iwinfo-scan from undetermined to present without running a scan or refreshing the ACL.	Verified
FS-019	6	The first adopted-device panel truthfully shows Packages we installed: none, but still labels its optional ACL action Install controller access payload even though the exact payload is already installed. It also collapses a standing file.exec: NOT_FOUND into the object/method name without identifying which allow-listed command was absent.	Existing-device remediation UX	The adopted-device action now says review or refresh and explains install-if-missing/replace-if-present behavior. Collector degradations retain the fixed controller-side command for file.exec, and the API appends it to the call identity. Focused normal/race Go tests, 124 focused UI tests, and the production build pass. A signed-in dev-schema16-fresh-start-transparent-v6 check showed Review or refresh controller access payload, install-if-missing/replace-if-present copy, Packages we installed: none, and the exact active failure file.exec /bin/ping. No payload refresh or router write ran.	Verified
FS-020	6	Repeated corrected-build validation required the operator to stop, restart, and re-enter the controller passphrase manually.	Local controller restart	The operator explicitly chose the supported passphrase-file mode for this test harness. The ignored local file is mode 0600; its contents were never read into this log or model output. dev-schema16-fresh-start-transparent-v6 (sha256:46eff9c8…) reopened the same schema-16 database and passed /healthz. This affects only the local controller process, not the router.	Verified
FS-021	6	Current topology shows the one directly observed wired client on its physical LAN port. Coverage is partial for two explicit reasons: stock LLDP is unsupported, and BusyBox brctl showmacs does not identify VLAN provenance.	Topology capability coverage	Preserve the measured/inferred link and the explicit gaps. Do not install anything automatically. LLDP is a candidate for a future separately selected official-package option with exact size, dependency, service, risk, and rollback disclosure; VLAN provenance remains unavailable unless a proven stock source exists.	Verified with explicit gaps
FS-022	6	Opening Radios on the factory-default device blanked the entire application. The disabled radios were valid inventory rows with interfaces:null; the screen called .some() on that value.	Radio inventory/UI resilience	The API now normalizes disabled-radio interfaces to []; the UI also accepts legacy null. A route error boundary keeps navigation usable if any screen throws. Focused API/App/Radios tests and the production build pass. Embedded v7 (b176214f…) was then verified live: the page rendered two radios, 0/2 known channel plans, explicit unavailable measurements, and no runnable scan button; no RF scan ran.	Verified
FS-023	6	Settings recovered an Apply operation ID retained by the browser from the pre-reset controller, then presented it as a current request even though the new database had no such operation and contained zero desired-state objects.	Controller identity boundary	A retained operation that returns authoritative 404 apply operation not found is now removed from browser storage and replaced with a concise notice. Embedded v8 (dd1ef192…) cleared the stale ID live and restored “Nothing above has touched a device”; no Preview or Apply ran.	Verified
FS-024	6	Factory-reset WRT logs carried router source timestamps about 53 days behind controller receive time because the isolated router had no NTP source. General Logs showed those dates without explaining the ordering.	Event-time truth	General Logs now detects a five-minute-or-greater source/ingest skew, names its approximate size, recommends checking router time/NTP, and states that ordering follows router source time. Embedded v8 reproduced the 53-day warning live. No router clock change was made.	Verified
FS-025	7	Creating all-aps succeeded, but assigning the adopted WRT failed with store: an AP group needs a name; the membership update sent only the group ID and devices even though the replacement endpoint validates the full group record.	Desired-state API contract	Membership updates now preserve the existing group name as well as the serialized desired device list. Focused regressions and the production build pass. Embedded v9 (26582196…) assigned WRT successfully. The controller now has one lan network and one all-aps group; Preview and Apply have not run, so the router is unchanged.	Verified
FS-026	7	The operator saved WLAN <initial transition SSID> to controller desired state with both available bands, WPA2/WPA3 transition mode, optional PMF, 802.11r, and 802.11k/v on the existing VLAN-1 lan through all-aps.	First managed WLAN preview	Read-only Preview checked one device and proposed exactly two creates: wireless.oowrt_wlan1_radio0 and wireless.oowrt_wlan1_radio1, 19 options each including the write-only passphrase. Existing untagged LAN is explicitly omitted and remains router-owned. Because factory-default radios have no interface, iwinfo cannot yet report hardware names; the known-defect check is unproved, not passed. No Apply has run.	Waiting for explicit Apply consent
FS-027	7	Apply operation 23029110-… durably completed the two approved WLAN creates and a subsequent Preview reported zero drift. Both radios broadcast <initial transition SSID>; channel inventory became known (35 channels), and two clients associated on 2.4 GHz. Re-probe then identified Marvell 88W8964 and disclosed that WPA3/SAE and PMF can wedge WRT3200ACM radios until a physical power cycle. The first factory-default Preview had only reported unidentified hardware and therefore allowed the hazardous defaults before identification.	First-Apply hardware safety	Known defects now also key from authoritative WRT3200ACM board identity, so disabled factory radios surface the Marvell PMF/WPA3 warnings before their first WLAN Apply. Capability/render regressions pass. The corrective controller draft is WPA2-only with PMF disabled while retaining 802.11r; saving it requires the operator's explicit WPA2+FT compatibility acknowledgement, and applying it requires a second explicit router-change action.	Fix tested; corrective consent pending
FS-028	7	The operator acknowledged and saved the WPA2-only, PMF-disabled correction while retaining 802.11r and 802.11k/v. Apply operation 90cc49bd-b088-4513-8404-2d02d5da2921 durably completed exactly two wireless-section updates; router health passed and confirm landed. The stored model is psk2 with PMF 0. Embedded v10 (sha256:63cec24b…) includes the pre-first-Apply board-identity defect check. Its signed-in Preview reports zero pending changes, both radios and all 35 channels remain visible, <initial transition SSID> broadcasts on both bands, and the focused live panel reports one currently associated 2.4 GHz client.	WRT3200ACM WLAN safety correction	No package, service, network, firewall, or DHCP change was part of the correction. Preserve the explicit hardware warning: WPA3/SAE and PMF remain unsupported choices for this router; the controller prevents silent first-Apply exposure but does not repair mwlwifi.	Verified
FS-029	6	After the WPA2-only correction, router logs ingested 70 Unsupported authentication algorithm (3) messages in about six minutes while one 2.4 GHz client remained successfully associated. The repeating algorithm is SAE, consistent with another client retaining the earlier WPA2/WPA3 transition-mode profile and retrying it against the corrected WPA2-only BSS.	Client migration after security downgrade	On every device that joined <initial transition SSID> before the correction, explicitly forget the saved network and rejoin it. Confirm the SAE retries stop before treating the migration as clean. This is client-side profile cleanup; do not widen the router payload or change packages.	Waiting
FS-030	7	Two wireless test clients could not join the corrected <initial transition SSID> BSS or obtain a fresh password prompt. Live hostapd evidence showed repeated SAE (authentication algorithm 3) attempts, brief WPA2 handshakes, disconnects, and retries. The current single-AP WLAN still had 802.11r enabled.	WRT3200ACM client compatibility	Controller desired state is staged as the new SSID <managed WPA2 SSID>, WPA2-only, PMF disabled, and 802.11r disabled; 802.11k/v remains enabled. Read-only Preview proposes exactly the two managed wireless-section updates and nothing else. The new SSID bypasses synchronized/cached Apple Wi-Fi profiles; disabling fast transition removes an unnecessary single-AP compatibility and measured-driver-risk variable. Apply remains pending explicit operator action.	Waiting
FS-031	7	Apply operation c5a649f0-217c-4d54-bfd9-9b73784f0b46 durably completed the two reviewed <managed WPA2 SSID> updates; router health passed and confirm landed. A subsequent Preview reports zero drift. Controller inventory labelled the new SSID present on channels 36 and 1. The old client continued explicitly probing the removed <initial transition SSID>; no client join to the new SSID had yet been tested.	WRT3200ACM client compatibility	The inventory result proved configuration, not an on-air beacon. FS-032 supersedes its apparent broadcasting success.	Superseded by FS-032
FS-032	7	Neither wireless test client nor the wired test client could discover <managed WPA2 SSID>, despite zero UCI drift and the controller labelling both interfaces as broadcasting. Router logs show hostapd reloaded the new configuration and receives directed probes for the removed <initial transition SSID> SSID, but no post-reload AP-ENABLED transition proves a fresh beacon. Apply nevertheless recorded health passed and confirm landed.	Apply health and live-state truth	Treat this as an unproved/failed wireless outcome, not successful broadcasting. The WRT3200ACM mwlwifi firmware has no reliable in-place recovery; perform one physical power cycle and validate the clean-boot beacon. Product fix required: wireless Apply health must verify expected hostapd BSS/SSID readiness, and the UI must not call configuration inventory Broadcasting when beacon readiness is unproved.	Reproduced; physical recovery pending
FS-033	7	After the operator physically power-cycled the WRT3200ACM, both managed BSSs emitted fresh AP-ENABLED events. An wireless test client then associated with phy0-ap0, completed the WPA2 four-way handshake, and received <wireless-client address> by DHCP. The controller reports one live client on the 5 GHz <managed WPA2 SSID> BSS. Since the boot boundary, router logs contain zero unsupported-authentication/SAE errors and zero probes for the removed <initial transition SSID> SSID.	WRT3200ACM clean-boot recovery	The WPA2-only, PMF-off, FT-off configuration is operational after a cold start. This validates the compatibility correction, not the prior in-place Apply health result. Keep the FS-032 product defect open: Apply must verify hostapd/BSS readiness, and configuration inventory must not be labelled as proven on-air broadcasting. Validate client Internet access next.	Verified recovery; Internet check pending
FS-034	7	With cellular disabled, the joined wireless test client could not load an Internet page. The WLAN association and DHCP lease remained healthy, but the router repeatedly reported no default route; network.interface.dump was authoritatively empty, topology contained no Internet/uplink edge, and no WAN-probe series existed. The Dashboard still showed the gateway device online without a site-WAN warning.	Physical WAN and dashboard truth	This is not a Wi-Fi or payload/package failure. Connect the WRT Internet/WAN port to the isolated test setup's Internet-capable upstream network, then require a default route, successful fixed-target probe, and client Internet access. Product improvement: surface gateway default-route/WAN-probe absence prominently instead of equating device reachability with site connectivity.	Reproduced; upstream WAN connection pending
FS-035	7	After connecting the physical WAN port, the WRT negotiated a 1 Gbps link, received DHCP lease <upstream WAN lease> from the upstream network, loaded upstream DNS, and brought wan up. The next authoritative network.interface.dump was observed rather than empty, and topology added a measured wan uplink from the WRT to the synthetic Internet node. The wireless test client remained associated with <managed WPA2 SSID> and loaded an HTTPS page with cellular disabled.	Physical WAN recovery	Router-side addressing, route evidence, WLAN client transport, DNS, and Internet access are healthy. Retain FS-034's missing Dashboard WAN-state disclosure as a product improvement.	Verified
FS-036	8	The wired test client was moved from the WRT LAN to an isolated C6 LAN port. Route <management address> is scoped to the wired interface, the factory LuCI page answers directly, and the live ED25519 fingerprint exactly matches the dedicated post-reset C6 trust record while differing from the WRT fingerprint.	Second-router identity boundary	The endpoint is conclusively the factory-reset C6 rather than the WRT. Set a unique C6 root password before changing its management address or connecting it to the WRT LAN.	Verified
FS-037	8	The operator set a unique C6 root password. A direct JSON-RPC login attempt with an empty root password now returns ubus permission-denied status 6.	Second-router security	The factory blank credential is closed. Configure the isolated C6 as a non-conflicting LAN-managed AP/switch before attaching it to the WRT LAN.	Verified
FS-038	8	While correcting the C6 LAN setup, the operator intentionally factory-reset it again and repeated the password/address configuration. This explains the otherwise unexpected Dropbear fingerprint change. The C6 now answers only at <AP management address>, retains the same directly attached LAN MAC, and rejects an empty root password. The pre-reset fingerprint was preserved separately and the dedicated trust record was replaced with the new reset identity at .2.	Second-router reset/recovery	The identity transition is explained rather than silently accepted. Continue from the isolated .2 baseline; add gateway/DNS only after the address change is active.	Verified
FS-039	8	The operator connected WRT LAN3 to C6 LAN1 and returned the wired test client to WRT LAN2, leaving the C6 WAN unused. The wired test client retained <wired-client address>; DHCP server identifier is exclusively WRT <management address>; both management addresses answer; ARP maps .1 and .2 to the expected distinct router MACs; and both live SSH fingerprints exactly match their dedicated trust records.	Second-router LAN integration	The physical LAN-to-LAN baseline is collision-free and preserves one router/DHCP authority. Inspect the C6 read-only at .2 before offering the optional controller access payload.	Verified
FS-040	8	Read-only inspection identified the C6, two radios, disabled LAN DHCP, no active WAN default route, and stock legacy-swconfig evidence only after the payload widened the allow-listed observations. The UI kept Gateway off, recommended Access point, and explicitly labelled Switch unobservable; Switch was selected from known LAN-to-LAN responsibility. The operator authorized the expanded disclosure. Adoption then installed exactly the one ACL JSON file plus scoped rpcd.oonfeewrt login. It installed no package, binary, daemon, service, or firmware and changed no network, WLAN, firewall, or DHCP configuration. The durable device record is AP+Switch, the device is live, the audit records device.adopted, the C6 owns zero UCI sections, and the panel reports Packages we installed: none.	Second-router access-payload consent	Preserve the distinction between installed stock packages discovered by the probe and packages installed by the controller (none). Disabled radios leave driver behavior unproved; re-probe after the first managed WLAN is active.	Verified
FS-041	8	The C6 was added to the existing all-aps group in controller desired state. Read-only Preview checked both devices: WRT already matches; C6 proposed exactly two creates, wireless.oowrt_wlan1_radio0 and wireless.oowrt_wlan1_radio1, 19 options each including the existing write-only passphrase. The existing untagged lan, management address, gateway, DNS, DHCP, firewall, and wired switch configuration remained explicitly omitted and operator-owned.	Second-AP WLAN rollout	The operator separately approved this exact two-section write. FS-042 records the result.	Verified preview
FS-042	8	Apply operation d35c7f41-3c98-4e61-8b89-d42e68d00c6b durably completed the two approved C6 wireless creates. WRT required no change. Both C6 BSSs emitted fresh AP-ENABLED; the C6 now owns exactly those two wireless sections, owns no network/firewall/DHCP section, and still reports Packages we installed: none. A second capability probe was stable and identified both radios plus stock hostapd/survey/scan/802.11k/mesh observations. Read-only Preview reports zero drift. Radio inventory now contains four radios and four known channel plans; C6 telemetry initially remains unavailable until counter baselines and a completed rollup exist.	Second-AP WLAN rollout	No package, binary, daemon, service, firmware, RF scan, or unrelated router configuration was installed or changed. Verify topology after the next fresh WRT bridge observation, then associate a client through the C6 and prove DHCP/DNS/Internet.	WLAN apply verified; client test pending
FS-043	8	Before the WRT's next bridge poll, topology temporarily showed the C6's aggregate eth0.1 view as reverse/duplicate candidate links. The fresh WRT observation at 05:05:22 proved the C6 directly on physical lan3, the wired test client on physical lan2, and closed every contradicted aggregate C6 edge. The rendered current graph now has exactly four active links: wired test client→WRT lan2, wireless test client→WRT phy0-ap0, C6→WRT lan3, and WRT→Internet wan.	Multi-device topology convergence	This was stale cross-device evidence during the expected polling interval, not an install or router defect. The UI remains partial because BusyBox FDB lacks VLAN provenance and stock LLDP is unsupported.	Verified
FS-044	8	With no controller or router write, the operator moved the wireless test client near the C6 and toggled Wi-Fi. WRT emitted the disconnect; C6 phy0-ap0 emitted the association/connect; the controller durably correlated an explicit WRT→C6 roam at 05:10:28. The current client row attributes <wireless-client MAC> to the C6 at -56 dBm, online/wireless, with DHCP address <wireless-client address>. C6 radio counter rollups are now populated for utilization, interference, and RX/TX airtime. With cellular disabled, the wireless test client loaded a unique HTTPS URL through this C6 association.	Second-AP client association	This proves C6 BSS operation, roaming correlation, DHCP/DNS/Internet continuity, and radio observation without an RF scan. Verify the reverse C6→WRT roam next.	Verified
FS-045	8	The operator moved the same wireless test client back near WRT and toggled Wi-Fi without changing either router. C6 authoritatively became empty, WRT observed the station on phy0-ap0, and the controller durably recorded the C6→WRT roam/connect at 05:14:52. The client kept <wireless-client address>.	Bidirectional AP transition	Both directions now have source, durable correlation, current-state, and address-continuity evidence.	Verified
FS-046	8	After the second AP joined the fleet, all same-LAN client rows intermittently changed from local to upstream. Each device's observation was individually correct: WRT serves <management subnet> locally, while the C6 reaches its gateway through that same management subnet. The global client merge used last-writer-wins, allowing the C6 to overwrite the gateway's site-local classification.	Fleet client scope truth	Same-IP merge now gives a managed local-side observation precedence over upstream; a real IP change still reclassifies. Store/API regressions pass. Local controller v11 (sha256:fb381201…) reopened the same database; signed-in fleet polling and UI now show the wired and wireless test clients as two local/online rows, the wireless client on WRT, one true upstream row, and matching Dashboard counts of two LAN devices and one wireless client. No router was changed.	Verified
FS-047	8	A signed-in read-only pass after both roam directions found zero desired-state drift on both routers. Logs expose the retained continuity gap and exact C6/WRT disconnect, roam, connect, DHCP, and WPA2 handshake evidence. Client Observability joins the selected roam to the measured client→WRT→Internet path and names historical-coverage limits. The C6 device panel shows two enabled <managed WPA2 SSID> BSSs, live utilization/occupancy rollups, and Packages we installed: none. Policy Engine truthfully reports no managed routed zones and makes no router change.	Cross-screen evidence consistency	Current partial results are explicitly unavailable/partial rather than fabricated. RF scanning remains unexecuted and requires its own disruption acknowledgement.	Verified
FS-048	8	FS-034 proved that an online controller connection to a gateway did not imply site Internet connectivity, but Dashboard exposed only device reachability.	Site-WAN truth	Dashboard now derives each adopted gateway's up, missing, or unknown uplink state from its fresh authoritative network.interface.dump source plus the active topology edge. It raises a critical warning only when an online gateway freshly answered and no default route exists; stale, failed, offline, or absent evidence remains unknown. API/UI regressions, the full API suite, all 257 UI tests, and the production build pass. Embedded v12 showed the current active WRT→Internet wan edge without a false warning; the missing-route branch is regression-proved rather than recreated by unplugging a working WAN. No router was changed.	Verified
FS-049	8	The device panel called hostapd/interface inventory Broadcasting, even though FS-032 showed that this control-plane state can outlive failed radio/firmware beacon readiness.	Wireless evidence wording	The panel now labels these rows Reported enabled BSSs and states that they are not an independent on-air scan. Apply health separately verifies every desired UCI section's runtime interface, exact SSID, hostapd enabled state, and bridge-isolation state inside the rollback window; it still does not silently run a disruptive scan or claim independent beacon proof. Embedded v12 reproduced the corrected wording for both active WRT BSSs.	Verified
FS-050	8	Opening the WRT detail panel after restart showed its older REST status as offline while a successful focused live frame in the same panel said just now (live), listed the associated station, and carried fresh metrics.	Live/REST consistency	A fresh live stats frame now supersedes the older REST status as well as Last seen; when that timestamp expires, the panel falls back to the durable status. Embedded v13 reproduced one consistent online status with just now (live), the associated station, and fresh metrics. Focused regression and all 258 UI tests pass. No router was changed.	Verified
FS-051	8	Final clean-run controller artifact dev-schema16-fresh-start-transparent-v13 (sha256:71fd32c28c3462246d7c6b403e2d22cdf2de28a85c6a91529d9bb50842deab4f) reopened the same schema-16 data set and passed health/sign-in. Dashboard reports both devices online, two local clients, one wireless client, and one excluded upstream row with no false WAN warning. Current topology has the two clients, C6, WRT, Internet, and exactly four links; read-only Preview checks both routers with zero changes.	Clean-run checkpoint	No package, binary, daemon, service, firmware, RF scan, access-payload refresh, neighbour push, or router configuration change occurred during the v11–v13 verification cycle. The next hold is destructive rollback/un-adoption testing and requires separate explicit operator consent.	Verified
FS-052	8	The operator separately authorized exactly one disruptive RF scan on Archer C6 radio0 (5 GHz). The default-off dialog named the device/radio and warned that associated clients could briefly disconnect; no other radio was selected. The scan completed at 05:59:40 with 14 BSS observations and produced a scan-v1 channel suggestion of channel 44 (score 100.0). Immediately afterward both managed devices were online, the C6 had a fresh baseline poll, and read-only Preview checked both routers with zero changes pending.	Explicit RF-scan consent	This action ran one allow-listed iwinfo.scan; it installed no package, binary, daemon, service, firmware, ACL, or configuration. Do not repeat it or scan another radio without a new acknowledgement.	Verified
FS-053	7	The operator authorized complete C6 un-adoption. The confirmation named exactly wireless.oowrt_wlan1_radio0 and wireless.oowrt_wlan1_radio1; the administrator credential was entered by the operator and not retained. The cleanup transaction reported both sections reverted, the scoped rpcd login removed, and the ACL file removed. Durable audit event device.unadopted records config_revert_complete=true, reverted_sections=2, and footprint_remains=false. The controller now contains only the WRT device and its two owned WLAN sections, has no orphan ownership rows or foreign-key violations, and read-only Preview reports one checked device with zero changes. C6 management remains reachable at <AP management address> by ICMP and HTTP. The independent post-cleanup check found ACL absent, scoped login absent, package count unchanged at 155, zero controller-owned sections, zero pending UCI changes, zero <managed WPA2 SSID> WLAN sections, and retained LAN address <AP management address>/24.	C6 rollback	C6 returned to its operator-managed LAN/AP-switch baseline with no controller residue and no package change. Preserve the evidence file before testing the WRT rollback.	Verified
FS-054	7	The operator authorized complete WRT un-adoption. The confirmation named exactly wireless.oowrt_wlan1_radio0 and wireless.oowrt_wlan1_radio1; the administrator credential was entered by the operator and not retained. The cleanup transaction reported both sections reverted, scoped rpcd login removed, and ACL file removed. Durable audit event device.unadopted records config_revert_complete=true, reverted_sections=2, and footprint_remains=false. The controller now contains zero devices and zero owned sections, with no foreign-key violations; Dashboard truthfully reports 0/0. WRT management remains reachable at <management address> by ICMP and HTTP, and an HTTPS Internet check still succeeds. The independent post-cleanup check found ACL absent, scoped login absent, package count unchanged at 174, enabled-service count unchanged at 27, zero controller-owned sections, zero pending UCI changes, zero <managed WPA2 SSID> WLAN sections, and retained LAN address <management address>/24.	WRT rollback	WRT returned to its operator-managed gateway baseline with no controller residue, package/service change, or loss of wired Internet. Both router rollback gates are complete.	Verified
FS-055	7	Immediately before WRT removal, its management-overhead panel said 45 requests were not polls — that should only be session logins. This run also made explicitly acknowledged Apply, RF-scan, capability-probe, neighbour-update, and cleanup-related calls, so the copy incorrectly treated every non-poll request as a login anomaly.	Overhead accounting truth	The panel now distinguishes scheduled poll rate from total HTTP request rate and explains that non-poll requests include session setup and explicit discovery, capability-probe, and RF-scan actions; the count alone is not evidence of unexpected logins. Backend/API comments preserve the same contract. A 45-request regression, 129 focused screen tests, all 259 UI tests, the production build, and collector/API tests pass. Embedded v15 reproduced the separate live Scheduled poll rate and HTTP request rate fields after re-adoption.	Verified
FS-056	7	Post-rollback artifact dev-schema16-fresh-start-transparent-v14 (sha256:df32a2c03a4ea645e759b52ec40c6e9cb6a26ad258c8823ca3db587b7a92182b) reopened the same schema-16 controller data after both devices were cleanly removed. It started healthy with zero collector devices and embeds the corrected management-overhead copy. After the process-boundary sign-in reset, Dashboard truthfully rendered zero devices, clients, focus subscriptions, and active series while retaining the durable cleanup audit history.	Controller post-rollback checkpoint	Re-adoption must begin from the default-off payload disclosure; read-only inspection itself installs nothing.	Verified
FS-057	5	From the verified empty baseline, read-only WRT inspection again identified the exact model/build, two radios, four LAN ports, wan, DSA, active WAN default route, enabled LAN DHCP, and recommended Gateway + AP + Switch. Before payload installation, package-derived mesh/uplink checks were explicitly undetermined rather than reported missing. The access-payload checkbox remained off and Adopt remained disabled.	WRT re-inspection	The inspection credential made no router or controller inventory change. Re-adoption required a new, separate payload acknowledgement.	Verified
FS-058	6	The operator separately authorized WRT re-adoption and the exact controller payload after rollback. Adoption installed the one ACL JSON and scoped login, stored Gateway + AP + Switch, and recorded a durable device.adopted event. The controller has one adopted device and zero owned configuration sections; the first live poll is online and reports Packages we installed: none, with only stock lldpcli absence as a standing source limit. The independent post-adoption check found the exact embedded ACL hash d82edf01bd4c658be05d500e2a89f38eae1144fba18f2c75b2ed4cc9066956f3, scoped login present, package count unchanged at 174, enabled-service count unchanged at 27, zero controller-owned sections, zero pending UCI changes, and zero <managed WPA2 SSID> WLANs. No network, WLAN, firewall, DHCP, package, binary, daemon, service, or firmware change was made.	WRT re-adoption	The payload boundary is reproduced after a complete rollback. WLAN restoration remains a separate Preview and acknowledged Apply.	Verified
FS-059	6	The immediate adoption-result card grouped inactive-interface, idle-counter, and hardware/driver-uncertainty outcomes under copy that said every check was refused and only a wider ACL could help. The next live poll proved the installed payload worked and retained only the expected unsupported LLDP gap.	Adoption-result truth	The card now states that insufficient evidence may come from permission, inactive interfaces, idle counters, or driver uncertainty, and tells the operator to widen access only when the corresponding note names a permission denial. Focused 129-screen tests and the production build pass. Reproduce on the next embedded artifact.	Fixed; clean UI reproduction pending
FS-060	6	Re-adoption artifact dev-schema16-fresh-start-transparent-v15 (sha256:60a3039e90adbd9746ef70502a3b53b4f0506a0426dcc55e3d7f6ba620ec524a) reopened the same schema-16 data with the one re-adopted WRT and embeds the corrected adoption-result explanation. Health and process-boundary sign-in pass. Dashboard reports one online device while the wireless-client total is explicitly unavailable because no WLAN/station source exists yet. The live WRT panel reports Packages we installed: none, corrected overhead fields, and only stock lldpcli absence as a standing source limit.	Controller re-adoption checkpoint	Independently verify the WRT payload/package boundary, then Preview the WLAN restoration; do not Apply from a stale bundle.	Verified
FS-061	7	After WRT re-adoption, the operator restored its membership in controller group all-aps. Read-only Preview checked only WRT and proposed exactly two creates: wireless.oowrt_wlan1_radio0 and wireless.oowrt_wlan1_radio1, 19 options each including the retained write-only passphrase. The screen also rendered the terminal pre-rollback Apply operation beside this new Preview as though both were current.	Apply-history truth	Completed operation IDs are now removed from browser recovery storage. A terminal result remains visibly labelled Previous Apply operation until a new Preview loads, then disappears; queued, running, and unknown operations remain recoverable and visible. Focused 130-screen tests, all 260 UI tests, production build, and diff check pass. Embedded v16 first labelled the recovered result as previous, then a fresh live Preview hid it and restored “Nothing above has touched a device.” No Apply or router write ran.	Verified
FS-062	7	Controller artifact dev-schema16-fresh-start-transparent-v16 (sha256:9894674333873fb888b98969a8d03bce3916399dc932670b45aa885d9e25e56c) reopened the same schema-16 data, started one collector, passed process-boundary sign-in, and embeds the Apply-history fix. Its live read-only Preview checked one WRT and reported exactly the two managed <managed WPA2 SSID> wireless-section creates; the pre-reset completed operation was absent from the new plan. The operator then separately authorized this exact Apply.	WLAN restoration checkpoint	Apply operation e0ea6c07-d76a-453d-94e6-62ee2c3107b9 durably completed both creates; health passed and confirm landed. The preview named the WRT3200ACM/mwlwifi radio-wedge history; the retained WLAN is WPA2-only with PMF and 802.11r disabled, while 802.11k/v remain enabled.	Verified
FS-063	7	The post-Apply Preview checked one WRT and reported zero pending changes. Router logs recorded both phy0-ap0 and phy1-ap0 enabled and forwarding; the device panel reported <managed WPA2 SSID> on channels 36 and 1 with zero clients. Packages, enabled services, networks, firewall, DHCP, and firmware were unchanged; only wireless.oowrt_wlan1_radio0 and wireless.oowrt_wlan1_radio1 are controller-owned. Immediately after Apply, fresh BSS rows briefly retained stale section provenance and displayed ownership as unknown until the next interface poll.	Apply completion freshness	Collector.Rediscover now wakes the poller after invalidating interface provenance, closing an apply-completion wake race that could delay the authoritative remap. Focused collector/daemon tests and the wake regression pass. A future acknowledged Apply can reproduce the exact live boundary; repeating this already-zero-drift Apply solely for evidence is not justified.	Fixed and regression-proved
FS-064	7	Controller artifact dev-schema16-fresh-start-transparent-v17 (sha256:b04da54dc8650cc182e651a9b4f8839ea536fbe414d1c1c39c88ab74f658f9a3) embeds the Apply-completion wake fix and reopened the same schema-16 data with one WRT collector. After the first focused poll, both <managed WPA2 SSID> BSS rows had authoritative section provenance, zero associated clients, and no unknown-ownership marker. Dashboard reported one online device, zero wireless clients with complete current station evidence, and one current LAN client.	Post-Apply controller checkpoint	The restart changed no router state. Proceed to a one-client association test; do not change WLAN security or run an RF scan.	Verified
FS-065	7	With cellular disabled, the operator joined one wireless test client to <managed WPA2 SSID> and loaded a unique HTTPS URL. WRT durably recorded association and a completed WPA2 four-way handshake on phy0-ap0; DHCP assigned <wireless-client address>. The client row is online/wireless on WRT at -53 dBm. Current topology contains measured wireless test client→WRT phy0-ap0 and WRT→Internet wan links, and Dashboard reports one wireless client.	First restored-WLAN client	Association, WPA2 authentication, DHCP, DNS, IPv4 Internet, controller presence, and topology correlation pass. Repeated odhcpd: No default route present, setting ra_lifetime to 0! messages did not block IPv4 and are retained as an IPv6 router-advertisement/default-route coverage issue; do not reinterpret them as an IPv4 WAN failure.	Verified with explicit IPv6 gap
FS-066	7	The operator disabled Wi-Fi on the associated wireless test client. WRT durably recorded AP-STA-DISCONNECTED, disassociation, and deauthentication from phy0-ap0. The next successful empty station observation immediately removed the current AP/signal evidence; the client moved to the offline filter while retaining its last-seen timestamp and <wireless-client address> history. Dashboard no longer reported a wireless client.	Client presence truth	Successful known-empty evidence clears online state instead of leaving the departed client falsely online. Reconnect the same client once to prove recovery before beginning C6 adoption.	Verified
FS-067	7	Re-enabling Wi-Fi produced a new WRT phy0-ap0 association, completed WPA2 four-way handshake, and DHCP renewal for the same wireless test client identity and <wireless-client address>. The current client row recovered to online/wireless on WRT at -49 dBm.	Client presence recovery	Connect→disconnect→reconnect truth passes without changing the router. Proceed to read-only C6 inspection with its payload option left unchecked.	Verified
FS-068	8	Read-only C6 inspection identified TP-Link Archer C6 v2 (US)/A6 v2, OpenWrt 25.12.5, two radios, no local DHCP, no active WAN default route, and recommended Access point. Pre-payload permissions did not expose LAN-port/switch evidence or allow the package-inventory command, so Switch, mesh, and wireless-uplink support remained explicitly undetermined rather than absent.	C6 pre-adoption inspection	Prepare Access point + Switch because this physical C6 provides the downstream AP/bridge role, while Gateway remains off. The exact default-off disclosure names one ACL JSON and one scoped login, observation scope, later separately acknowledged controller-owned UCI writes, and no package/binary/daemon/service/firmware installation. Inspection made no router or inventory change.	Verified
FS-069	8	The operator explicitly authorized C6 payload installation and adoption as Access point + Switch. Adoption created the scoped login and installed the one ACL JSON; the post-payload probe proved legacy swconfig switch/FDB visibility, RF scanning support, and installed wireless-uplink software. Radio-driver metrics and mesh remain partly undetermined until a WLAN activates the radios. The first scoped poll changed C6 from unknown to online, and its device panel reports Packages we installed: none.	C6 payload/adoption	Adoption changed no network, WLAN, firewall, DHCP, package, binary, daemon, service, or firmware. Only the access payload and controller inventory were added.	Verified
FS-070	8	C6 was added to controller group all-aps, a controller-database-only desired-state edit. Read-only Preview checked both devices: WRT already matches; C6 proposes exactly two creates, wireless.oowrt_wlan1_radio0 and wireless.oowrt_wlan1_radio1, 19 options each including the retained passphrase. Untagged VLAN-1 lan remains router-owned and is not rendered.	C6 WLAN Preview	C6 hardware names remain unavailable while its factory radios have no interface, so the known-defect check is explicitly unproved rather than passed. Apply only after a separate exact authorization; then re-probe with active radios and retain rollback evidence.	Waiting for explicit Apply consent
FS-071	8	The operator separately authorized the exact C6 <managed WPA2 SSID> Apply. Operation 2791e58a-8112-49dc-be1f-bd5667703b1d durably completed the two approved C6 wireless-section creates; WRT required zero operations. Health passed, confirm landed, and the next Preview reported zero drift on both devices.	C6 WLAN Apply	Only C6 wireless.oowrt_wlan1_radio0 and wireless.oowrt_wlan1_radio1 were created. No network, firewall, DHCP, package, binary, daemon, service, or firmware change was included. The result copy Applied to 2 devices counts checked targets rather than changed targets and should be made explicit.	Verified with copy improvement noted
FS-072	8	Both C6 BSSs became active as <managed WPA2 SSID> on channels 36 and 1. Two read-only re-probes proved airtime split, hostapd control, survey, mesh software, neighbour reporting, and both radio identities; the second probe settled a transient old/new radio-name ambiguity. The probe also detected and suppressed the known unsigned radio-counter quirk.	C6 post-Apply capability truth	No RF scan or package installation ran. Retain unavailable metrics when the driver cannot prove them.	Verified
FS-073	8	The first dual-device topology poll falsely placed WRT, the wired test client, and the WRT-associated wireless test client beneath C6 eth0.1. C6's legacy aggregate CPU/VLAN port sees upstream bridge traffic but did not prove that C6 itself was physically attached there.	Topology fail-closed inference	Fleet reconciliation now withholds aggregate-parent edges until that parent device has a measured physical, wireless/mesh, or Internet placement. Normal/race topology and daemon regressions pass. Under dev-schema16-fresh-start-transparent-v18 (sha256:65cec3b5f37b147142131a91b0c037e75e83b38ae2d66c8898e78866e49eb94c), reconciliation closed all three false C6 intervals while preserving history. Signed-in UI reproduction shows exactly wired test client→WRT lan2, wireless test client→WRT phy0-ap0, WRT→Internet wan, and newly learned C6→WRT lan3; a fresh Preview reports both routers already match with zero changes.	Verified
FS-074	8	Moving and repeatedly reconnecting the wireless test client did not select C6. Durable WRT logs show each disconnect followed by a successful WRT association, WPA2 four-way handshake, and DHCP renewal; current WRT signal remains about -59 dBm. C6 reports both BSSs enabled with zero clients and no corresponding association attempt.	Client AP selection	This is not evidence that C6 rejected the password. The phone kept choosing a still-strong WRT BSSID. A deterministic C6 authentication test requires a separately acknowledged temporary WRT publication override, followed by its own rollback Apply; do not disconnect or steer the client behind the scenes.	Waiting for explicit temporary-change consent
FS-075	8	The operator authorized a temporary WRT-only <managed WPA2 SSID> suppression test. Preview proposed exactly two WRT removals and zero C6 operations; Apply operation d9c883e3-dca7-47a3-84f1-0d008f682068 completed and the next Preview reported zero drift. The same wireless test client then associated with C6 phy0-ap0; C6 recorded the WPA2 connection and the live client table moved its AP attribution to C6 at about -56 dBm. With cellular disabled, the operator loaded the unique HTTPS test URL successfully; the association remained current on C6 at about -53 dBm.	Deterministic C6 association	C6 authentication, LAN bridge, DHCP continuity, DNS, and Internet data plane pass. No package, payload, network, firewall, DHCP, service, or firmware change occurred. FS-076 records the separately authorized restoration.	Verified
FS-076	8	The operator separately authorized restoring WRT publication. The override was cleared; Preview proposed exactly two WRT creates and zero C6 operations. Apply operation 168d50d9-b191-442b-ba71-5c87276e5e73 completed, and the next Preview reported zero drift. Both WRT BSSs are active again on channels 36 and 1; the wireless test client subsequently associated to WRT phy0-ap0 at about -58 dBm. The WRT panel still reports Packages we installed: none.	Temporary-test rollback	The Settings result said two devices were applied even though only WRT changed; the override toggle could visually snap back while its request was pending; and authoritative BSS ownership waited for the next focused poll after the intended ten-second settle point. Result copy now separates changed from already-matching devices, override toggles use pending truth and reject duplicate input, and Rediscover schedules an explicit settled re-read. Focused UI and collector regressions pass; embedded live reproduction remains pending.	Router rollback verified; UI fixes tested
FS-077	8	Controller artifact dev-schema16-fresh-start-transparent-v19 (sha256:08c519172e227d40bc8cc155f512159553d79ca7ce923f8d36383756f554d0c2) embeds the rollback-test UI and settled-interface fixes and reopened the same schema-16 data. After process-boundary sign-in, Dashboard reports both devices online and one wireless client; Client Devices attributes the wireless test client only to WRT at -55 dBm, with no transient competing-AP warning. A fresh read-only Preview checked both routers and reported zero changes; both already match.	Post-rollback controller checkpoint	The restart and Preview changed no router state. The changed-device result copy and pending-toggle behavior are regression-proved; the explicit ten-second settled re-read should be reproduced during the next independently justified Apply rather than by manufacturing another router write.	Verified with deferred live boundary
FS-078	8	The v19 read-only screen pass shows five topology nodes and exactly four current links: wired test client→WRT lan2, wireless test client→WRT phy0-ap0, WRT→Internet wan, and C6→WRT lan3. Partial coverage is limited to two explicitly unsupported LLDP sources and three BusyBox FDB edges without VLAN provenance. Radios reports all four stable radios and all four channel plans; no scan ran. General Logs retains the successful WRT WPA2 handshake and the known WRT odhcpd IPv6 RA/default-route warnings.	Read-only observability pass	Radio measurements are initially unavailable after the controller restart because only completed five-minute rollups are canonical; keep them unknown until a later completed bucket rather than fabricating current values. The IPv6 warnings remain a documented coverage/configuration issue and did not block the verified IPv4 client path.	Verified with explicit gaps
FS-079	8	With both APs publishing normally, the operator moved the wireless test client near C6, disabled cellular, toggled Wi-Fi, and loaded the unique HTTPS check. C6 phy0-ap0 recorded authentication, association, AP-STA-CONNECTED, and a completed WPA2 four-way handshake at 22:32:14; the gateway renewed the same <wireless-client address> lease. Client Devices attributes the wireless test client only to C6 at -46 dBm, and current topology moved the measured wireless edge from WRT to C6 while preserving WRT→Internet and C6→WRT.	Normal dual-AP client selection	This proves client selection/reassociation, DHCP continuity, DNS/HTTPS reachability, event correlation, and topology movement with both APs enabled. Because Wi-Fi was toggled and the WLAN intentionally has 802.11r disabled for WRT3200ACM compatibility, this is not a claim of seamless fast-transition roaming.	Verified
FS-080	8	With both APs still publishing and no Wi-Fi toggle or router change reported, the wireless test client subsequently selected WRT. WRT phy0-ap0 recorded association, AP-STA-CONNECTED, and a completed WPA2 four-way handshake at 22:34:58. Client Devices now attributes the wireless test client only to WRT; the latest focused reading is -76 dBm. C6 later recorded the old attachment's inactivity disconnect.	Natural dual-AP reassociation	This is a successful natural C6→WRT reassociation with the same SSID and standard WPA2. Router evidence explicitly says fast_transition=false; that is intentional because 802.11r remains disabled for WRT3200ACM stability/compatibility. Do not relabel this as an FT roam.	Verified
FS-081	8	The current topology data remained fail-closed, but its graph was visually misleading: a device with no fresh active parent edge was laid beside the Internet as another root, long Bézier links crossed the hierarchy, bare port labels overlapped nodes/links, and narrow nodes truncated useful names.	Topology presentation	The layout now reserves a labelled Unplaced · no current link evidence lane, keeps the connected hierarchy separate, uses high-contrast orthogonal routes with small independent lanes for competing parents, places each port name in a bordered pill, and widens node boxes. Controller artifact dev-schema16-fresh-start-transparent-v20 (sha256:b5aee3f9ff13349f78f0e1bf3e4ba11882d41fe53da16bd5467a8cfbe3f3434d) reopened the same schema-16 data. After sign-in and Refresh, the live graph cleanly rendered Internet→WRT→{wired test client,wireless test client} with three current links and placed C6 only in the unplaced lane because its current wired-parent evidence had expired. Sixteen focused topology tests, all 263 UI tests, and the production build pass. No router, package, payload, service, firmware, or desired state changed.	Verified
FS-082	8	Read-only follow-up distinguished the unplaced C6 from an offline device. C6 remained online under focused polling with both <managed WPA2 SSID> BSSs enabled, zero current clients, and fresh telemetry. Its last C6→WRT lan3 interval was proved at 22:20:45 and expired at 22:36:20; later successful WRT topology observations no longer contained that dynamic FDB entry. Direct controller traffic still reached <AP management address> over the wired test client's wired the dedicated wired interface route, but did not restore a port-bearing observation. Both routers report LLDP as unsupported operation; BusyBox FDB evidence is dynamic and does not identify VLAN.	Durable physical-link evidence	The graph correctly keeps C6 in Unplaced · no current link evidence instead of fabricating a root or parent. A durable LLDP-based link is now an optional capability candidate, but no package, daemon, service, ACL, payload, firmware, or router setting was installed or changed. Any future LLDP installation must name the exact packages/services/files, require a separate unchecked-by-default acknowledgement, show its payload, and provide rollback verification.	Accepted limitation; explicit capability candidate
FS-083	8	Showing only the truthful unplaced lane made the physically connected C6 appear completely decoupled even though FS-082 retained a recent closed WRT lan3 interval.	Last-known topology presentation	The current API now returns a separate bounded last_known_edges field: at most the latest closed interval per unplaced device, no older than 24 hours, only when its former parent remains placed. It is never mixed into active edges or historical snapshots. The graph renders that evidence across the unplaced divider as a gray dashed last known · lan3 connection and visibly states its expiration time. Store/API normal and race suites, all 265 UI tests, and the production build pass. Controller artifact dev-schema16-fresh-start-transparent-v21 (sha256:ffcca9815da7ac5ee50eeee01e4affcf5a23949e4801f27042c608c50f840bf9) reopened the same schema-16 data. Signed-in live reproduction shows five nodes, three active links, one distinct last-known C6→WRT lan3 route, the C6 retained in the unplaced lane, and the exact 22:36:20 expiration notice. No router was changed.	Verified
FS-084	8	Both routers' stock firmware reports LLDP unavailable, so the current C6→WRT wired link can expire when dynamic FDB evidence ages out.	Optional official-feed LLDP capability	Source now targets schema 17 and implements a two-stage LLDP workflow: explicitly refresh/resolve and display the exact apk/opkg plan, hash-bind it, then separately authorize installing official-feed lldpd and enabling/starting its service. The durable ledger records pre-existing packages, actual additions, prior service state, and interrupted/error states; separately planned rollback removes the exact recorded additions, preserves all pre-existing packages, restores prior service state, and must finish before un-adoption. Topology presents a truthful compact LLDP notice and never installs from that screen. Full Go normal tests, affected race tests, go vet, module-tidiness, 266 UI tests, production build, secret scan and diff check pass. The live controller remains schema 16 and no router package, service, payload, firmware, configuration or live database changed during this source work.	Fixed in source; migration and separately authorized live install/rollback pending
FS-085	8	The operator authorized only the controller schema-17 migration. Before shutdown, SQLite .backup captured an ignored pre-migration recovery copy; integrity was ok, maximum schema was 16, the matching keyring was copied, and no backup sidecar remained.	Controller migration and recovery	Artifact dev-schema17-fresh-start-transparent-v22 (sha256:e055b6a34ddcfce2456ffbb28a561ead70c8106deddd6a81baf46a74ba6cfe69) migrated the live database to schema 17 and reopened two collectors. Health and database integrity are ok; device_capability_installs exists with zero rows. An independently opened, ignored post-migration recovery pair reports schema=17 devices=2 credentials=2 owned_sections=4 wlans=1 meshes=0. The embedded UI reached the expected sign-in boundary after restart. No router package, service, payload, firmware or configuration changed.	Verified; LLDP plan/install remains separately unauthorized
FS-086	8	After process-boundary sign-in, Dashboard reported 2/2 devices online. Both device panels showed Packages we installed: none and Not installed by this controller. Opening each LLDP review left the package-index acknowledgement unchecked and the plan button disabled; both reviews were cancelled. Topology showed the compact two-router LLDP notice and collapsed three coverage issues.	Schema-17 UI safety boundary	No package-index refresh, credentials submission, plan request, package/service action or router mutation occurred. The durable capability ledger remains empty. Device panels were closed after inspection so focused polling returned to normal.	Verified; next router action requires separate authorization
FS-087	8	The operator authorized only the WRT package-index refresh and simulated LLDP plan. The first attempt ran apk -U --simulate add lldpd; OpenWrt returned missing packages.adb cache warnings and lldpd (no such package). No package or service was installed; the durable capability ledger remained empty.	OpenWrt 25.12 APK plan	OpenWrt's APK documentation identifies apk update as the forced index refresh. Artifact dev-schema17-fresh-start-transparent-v24 now runs apk update before apk --simulate add lldpd. The signed-in retry succeeded and showed the exact proposed additions: libcap 2.69-r1, libevent2-7 2.1.12-r2, and lldpd 1.0.20-r1; the simulated final total is 20.9 MiB in 177 packages. The separate installation acknowledgement remains unchecked, its button remains disabled, and the durable ledger remains empty.	Verified plan only; installation separately unauthorized
FS-088	8	The LLDP package-index acknowledgement rendered its inline lldpd code element as a separate flex item, splitting one sentence into competing narrow columns.	Capability-review layout	The prose and inline code now share one shrinkable text wrapper. Focused UI tests and the production build pass. Artifact dev-schema17-fresh-start-transparent-v24 (sha256:ceac695356bca84436b9cfd6422c141f5c56994b8e2af32427ed0a266a233363) is healthy; database integrity is ok. The signed-in WRT review visually renders the acknowledgement as one normal wrapped paragraph.	Verified live
FS-089	8	After reviewing the exact WRT plan, the operator separately authorized installation.	WRT optional LLDP capability	The controller installed only libcap 2.69-r1, libevent2-7 2.1.12-r2, and lldpd 1.0.20-r1, then enabled and started only lldpd. Schema 17 durably records state installed, package manager apk, requested package lldpd, exact added set [libcap,libevent2-7,lldpd], and the prior lldpd service state as disabled/stopped. The next WRT probe removed its LLDP coverage gap; the only remaining LLDP gap is device:2 (C6 stock firmware). The C6→WRT link remains last-known because LLDP must run on the peer as well.	Verified; C6 plan/install remains separately unauthorized
FS-090	8	The operator authorized only the C6 package-index refresh and simulated LLDP plan.	C6 optional LLDP plan	apk update and the simulation succeeded. The exact proposed additions are libcap 2.69-r1, libevent2-7 2.1.12-r2, and lldpd 1.0.20-r1; the simulated final total is 18.3 MiB in 158 packages. The separate installation acknowledgement remains unchecked and disabled, no C6 package/service was installed, and the durable ledger still contains only the installed WRT record.	Verified plan only; C6 installation separately unauthorized
FS-091	8	After reviewing the exact C6 plan, the operator separately authorized installation. The controller installed only libcap 2.69-r1, libevent2-7 2.1.12-r2, and lldpd 1.0.20-r1, then enabled and started only lldpd. Schema 17 records the exact added set and the prior disabled/stopped service baseline for rollback. Both routers now answer the bounded lldpcli neighbor call without an error, but both return an answered-empty neighbor set; the current C6→WRT lan3 edge still comes from dynamic FDB evidence rather than LLDP.	LLDP runtime diagnosis	Do not claim the capability is operational and do not silently alter /etc/config/lldpd. Artifact dev-schema17-fresh-start-transparent-v26 (sha256:2fdef716c90c13ae1a0d410ebe645168bc684fde0fab657e0d132bbdbd4b954c) adds a separately acknowledged, read-only SSH diagnostic that can read only the lldpd UCI configuration, runtime interfaces, and neighbors. It records that the diagnostic ran but changes no router setting, package, or service. Focused Go/UI tests and the production build pass; controller health, schema 17, and database integrity are ok.	Installed with durable rollback; peer discovery unresolved; diagnostic authorization pending
FS-092	8	The operator authorized the C6 read-only LLDP diagnostic. It found the package-default UCI selection interface='loopback' 'lan'; runtime lldpcli show interfaces exposed only logical br-lan, and show neighbors hidden returned an answered-empty object.	LLDP configuration payload	This proves the installed service is healthy but bound to the wrong abstraction for physical-link discovery. Credentials were cleared after the action and only a durable audit event records that it ran. Do not silently rewrite /etc/config/lldpd: inspect WRT the same way, then present an exact per-router interface configuration plan with a separately acknowledged write and an exact pre-change rollback baseline.	C6 cause verified; WRT read-only comparison pending
FS-093	8	The separately authorized WRT diagnostic found the identical package default: UCI selects loopback and logical lan, runtime exposes only br-lan, and neighbors are answered-empty. This matches the confirmed OpenWrt 25.12 package-default bug and proves both services are bound to bridges rather than the physical adjacency.	Exact LLDP interface configuration	Artifact dev-schema17-fresh-start-transparent-v27 (sha256:55c923fb5f8d9d6e295b3864ed6dc731ef016d64c1a837bde475488473b2f30e) derives only non-wireless members of br-lan, displays and hash-binds the exact interface plan, stores the full current uci export lldpd in the existing durable capability ledger, changes only lldpd.config.interface, commits only lldpd, restarts only lldpd, and verifies every planned runtime interface. Rollback restores the exact baseline and refuses external drift. Focused normal/race tests, vet, module tidiness, 135 screen tests, production build and diff check pass. The live controller is healthy on schema 17; no interface configuration has been authorized or changed.	Both causes verified; separately authorized plans pending
FS-094	8	The operator authorized the exact WRT plan lan1, lan2, lan3, lan4. The controller stored the pre-change UCI export, replaced only lldpd.config.interface, committed only lldpd, and restarted only that service. Immediate verification raced service startup and failed because /var/run/lldpd.socket did not yet exist; the durable record remained error with its rollback baseline retained.	LLDP service-start readiness	Artifact dev-schema17-fresh-start-transparent-v28 (sha256:b84b932abb21f7c36bdc45f641e05f1c01669c5318c987469b8a86f4860ae11b) waits up to five seconds for the control socket and keeps configuration planning/rollback available while the daemon is down. Focused adoption/daemon/API/store tests, vet and diff check pass. The same authorized WRT plan will be retried after the process-boundary sign-in; no C6 interface write is authorized.	Fix tested; WRT clean retry pending
FS-095	8	The v28 retry proved the control socket readiness fix, then exposed a second verifier incompatibility: this lldpcli emits lldp.interface as an array after physical interfaces are selected, while the new verifier accepted only the singleton object form. The WRT service started and the authorized lan1–lan4 configuration remained applied; the exact rollback baseline remained retained, but the ledger correctly stayed error because verification could not be decoded.	LLDP runtime JSON compatibility	Artifact dev-schema17-fresh-start-transparent-v29 (sha256:50e1c87f2112209aaed0bdfb248b1747bd073d6bbd53789b2b539992677bf5d0) accepts and validates both documented singleton-object and repeated-array interface shapes, including regular named rows, while rejecting ambiguous rows. Focused tests, vet and diff check pass. A process-boundary sign-in and one final retry of the same authorized WRT plan remain pending; C6 configuration is still untouched.	Fix tested; WRT clean retry pending
FS-096	8	The final v29 retry of the already-authorized WRT plan completed. The service control socket became ready within the bounded wait; runtime decoding verified lan1, lan2, lan3, and lan4; the UI reports Interface configuration: controller-managed (lan1, lan2, lan3, lan4); and durable event 5799 records device.capability_configured with that exact list at 05:39:44. The capability ledger returned from error to installed while retaining the exact pre-configuration rollback baseline.	WRT LLDP physical-interface configuration	No package, payload, firmware, WLAN, network, firewall, DHCP, or unrelated service changed during the retry. Physical neighbor discovery still requires a separate C6 interface plan and separately acknowledged C6 write; none has run.	Verified; C6 plan pending separate authorization
FS-097	8	The operator separately authorized the read-only C6 LLDP interface plan. The controller read its current UCI export and non-wireless br-lan membership and produced the exact plan eth0.1.	C6 LLDP physical-interface plan	The proposed write would replace only lldpd.config.interface with eth0.1, commit only /etc/config/lldpd, restart only lldpd, verify that runtime interface, and retain the exact current export for drift-checked rollback. The apply acknowledgement remains unchecked and disabled; no C6 setting changed.	Verified plan only; C6 write separately unauthorized
FS-098	8	The operator separately authorized the exact C6 eth0.1 interface write. The controller retained the pre-change UCI export, replaced only lldpd.config.interface, committed only lldpd, restarted only that service, verified runtime eth0.1, and recorded durable event 5836 at 05:42:38. The first refresh then briefly showed reciprocal measured WRT↔C6 links because only the changed device was rediscovered while its peer retained an older answered-empty LLDP observation.	Fleet LLDP convergence	Artifact dev-schema17-fresh-start-transparent-v30 (sha256:63f6b9f4ce14c7233e912f108b53757edad775d5bad83b112a12810ec35eee0d) schedules rediscovery for every adopted peer after LLDP install, configure, or remove. Both LLDP sources became observed; the transient reverse interval closed; live UI and schema-17 state now show one measured C6→WRT link on WRT lan3, supported by physical FDB, IPv4 neighbor, and LLDP evidence. No additional router write, package, firmware, WLAN, network, firewall, DHCP, or unrelated service change was made.	Verified live
FS-099	8	The truthful topology graph was difficult to read: edge labels could overlap one another, long device names were clipped, zoom changed the card's layout footprint, and the viewport required scrollbars instead of direct panning.	Topology interaction and layout	The graph now paints all paths before labels, places wan and phy0-ap0 on their own line segments, wraps long node names, uses a fixed-height clipped viewport, and supports background drag-to-pan without stealing node or control interactions. Artifact dev-schema17-fresh-start-transparent-v34 (sha256:8035a1c9f29fe5b52f1ea3b783af2f7f702788930dec7248861af88c9ed3ad64) is healthy; focused topology tests and the production UI build pass. This is controller UI only.	Verified live
FS-100	8	The first C6 LLDP rollback review named the exact package removals and configuration restoration but referred only generically to the “recorded service baseline”; the durable record specifically says lldpd was disabled and stopped before installation. No removal acknowledgement was selected and no rollback ran.	Rollback transparency	The exact reviewed plan now begins Recorded pre-install lldpd service baseline: disabled and stopped. (with all four enabled/running combinations regression-tested), and the removal authorization hash binds that text. Artifact v34 reproduced the corrected plan live: restore the exact prior /etc/config/lldpd, then remove only lldpd, libcap, and libevent2-7, yielding the original 155-package total. The removal acknowledgement remains unchecked.	Verified plan only; removal separately unauthorized
FS-101	8	After separately authorizing the exact C6 rollback, the controller's drift guard and uci/apk commands returned success and durable event 5889 completed at 06:38:28. The C6 capability-ledger row is gone while the WRT installed/configured record is unchanged; SQLite integrity and foreign keys are clean.	C6 LLDP rollback	The live C6 panel reports Packages we installed: none, lldpcli unavailable, both managed <managed WPA2 SSID> BSSs still enabled, and the device online. Topology returned to one explicit LLDP-unavailable router and retained C6→WRT lan3 as ambiguous FDB/neighbor evidence rather than LLDP-measured evidence. However, this version did not perform an independent post-delete package/service readback before clearing the ledger, so the exact 155-package count and disabled/stopped final state are not independently proved by the controller.	Controller-side success; explicit verification gap
FS-102	8	FS-101 exposed that a successful package-manager exit was treated as complete rollback without a final bounded state readback.	Rollback completion invariant	The controller now verifies the restored UCI export hash before removal, then re-reads package/service state before deleting the ledger: every recorded controller-added package must be absent; a pre-existing lldpd package and its enabled/running flags must exactly match the durable baseline; a removed service must not remain enabled or running. Failure retains the ledger in error. Successful audit detail now records the exact removed set, final package count, and service flags. Normal/race tests, vet and diff check pass. Artifact dev-schema17-fresh-start-transparent-v35 (sha256:c64599ecddb7ccd65463de5a8d44bfd125b97f01ce9f98653d48271d3b9560b7) is healthy on schema 17.	Fixed in source; live rollback proof pending
FS-103	8	Under hardened v35, the operator supplied WRT administrator credentials only for a read-only rollback-plan request.	WRT hardened rollback plan	The hash-bound plan names the recorded disabled/stopped service baseline, exact pre-configuration UCI restoration, and only three package removals: lldpd 1.0.20-r1, libcap 2.69-r1, and libevent2-7 2.1.12-r2; apk projects the original 174-package total. The separate removal acknowledgement remains unchecked and disabled.	Verified plan only; removal separately unauthorized
FS-104	8	The operator separately authorized the exact WRT LLDP rollback under hardened v35. Durable event 5929 completed at 06:52:40 with removed_packages=[libcap,libevent2-7,lldpd], package_count=174, service_enabled=false, and service_running=false. Both LLDP capability-ledger rows are now absent; SQLite integrity is ok and the foreign-key check is clean.	Hardened WRT LLDP rollback	The controller verified the restored UCI export hash, exact package absence, final package inventory, and disabled/stopped service state before deleting the ledger. WRT remains online; both <managed WPA2 SSID> BSSs remain enabled and one client remains associated. Both routers now report LLDP as unsupported, and topology truthfully shows C6 as unplaced with its expired lan3 placement marked last-known rather than asserting a current link. This closes the live-proof hold in FS-102.	Verified live
FS-105	8	The operator authorized only a WRT package-index refresh and exact LLDP installation plan. apk refreshed eight OpenWrt 25.12.5 repositories and reported 11,009 distinct packages; no package or service was installed by this step.	WRT LLDP reinstall plan	The hash-bound plan adds exactly libcap 2.69-r1, libevent2-7 2.1.12-r2, and lldpd 1.0.20-r1, moving the router from 174 to 177 installed packages, then enables and starts only lldpd. The installation acknowledgement remains unchecked.	Verified plan only; installation separately unauthorized
FS-106	8	Under the operator's continuing authorization for the disclosed validation flow, the controller applied the exact FS-105 WRT plan. Durable event 5946 completed at 06:58:08; the capability ledger records state installed, package manager apk, added packages [libcap,libevent2-7,lldpd], and the pre-install lldpd baseline disabled/stopped.	WRT LLDP reinstall	WRT remained online, both <managed WPA2 SSID> BSSs stayed enabled, and the associated wireless test client remained connected. The controller reports only the three disclosed packages as installed. Physical-interface selection remains at the OpenWrt package default and requires a credentialed read-only plan followed by the already-scoped configuration write.	Verified install; interface plan pending
FS-107	8	A credentialed read-only WRT plan resolved exactly lan1, lan2, lan3, and lan4. Under the continuing validation authorization, the controller replaced only lldpd.config.interface, committed only /etc/config/lldpd, restarted only lldpd, waited for its control socket, and verified every listed runtime interface. Durable event 5982 completed at 07:02:38 with the exact interface list; the ledger retains both the package-default UCI baseline and applied export for drift-checked rollback.	WRT LLDP physical-interface restore	WRT and both managed BSSs remained online, and the wireless test client remained associated. SQLite integrity is ok and foreign keys are clean. A final credentialed read-only runtime diagnostic remains before restoring C6.	Verified configuration; runtime diagnostic pending
FS-108	8	WRT read-only diagnostic event 6017 completed at 07:08:34. The UCI export contains exactly lan1–lan4; runtime reports every interface RX and TX; and the neighbor set is empty while C6 remains without LLDP, which is the expected fail-closed state.	WRT LLDP runtime verification	The diagnostic did not change the router. It exposed a UI truth defect: the diagnostic response contains runtime text but omits the richer installed/configuration fields, and replacing local state with that response falsely labels the still-configured ledger as package-default. The durable ledger and router export remain configured.	Runtime verified; UI state-merge fix in progress
FS-109	8	The diagnostic result now carries the durable installed state, package lists, detail, and service-derived configured interfaces, so a read-only inspection cannot erase configuration truth. The LLDP credential disclosure now says credentials remain only in the open review for its plan/apply pair, are never stored, and clear when the review closes or after a change. Regression tests cover both contracts.	LLDP diagnostic and credential truth	UI 271/271, daemon/API tests, production build, and diff checks pass. Artifact dev-schema17-fresh-start-transparent-v36 (sha256:1c8b189f62f64d58193f974addbd9b3fd2b15b6b9451d9cdf085d61c3d5c98fa) is healthy on schema 17 and listening at 127.0.0.1:8080; no router change occurred during rebuild/restart.	Fixed and running; process-boundary sign-in pending
FS-110	8	Under v36, WRT read-only diagnostic event 6024 completed at 07:16:46. Runtime again reports lan1–lan4 as RX and TX with no neighbor while C6 lacks LLDP. After the response, the live panel correctly remains Interface configuration: controller-managed (lan1, lan2, lan3, lan4) and displays the corrected credential-lifecycle disclosure.	Process-boundary diagnostic regression	No router setting, package, or service changed. SQLite integrity is ok and foreign keys are clean. This closes the FS-108/FS-109 UI-truth hold; C6 restoration can begin.	Verified live
FS-111	8	The C6 package-index plan resolved exactly libcap 2.69-r1, libevent2-7 2.1.12-r2, and lldpd 1.0.20-r1 from 11,003 distinct OpenWrt 25.12.5 packages, projecting 155 to 158 installed packages. Earlier rejected credential attempts produced no capability event or router mutation. Under the continuing disclosed validation authorization, durable event 6037 completed the exact install at 07:24:42.	C6 LLDP reinstall	The ledger records package manager apk, added packages [libcap,libevent2-7,lldpd], and the pre-install lldpd service baseline disabled/stopped. C6 remained online with both <managed WPA2 SSID> BSSs enabled. SQLite integrity is ok and foreign keys are clean. Physical-interface selection remains package-default until the separate read-only interface plan and scoped configuration step complete.	Verified install; interface plan pending
FS-112	8	The credentialed C6 read-only plan resolved exactly eth0.1. Under the continuing disclosed validation authorization, the controller replaced only lldpd.config.interface, committed only /etc/config/lldpd, restarted only lldpd, verified runtime eth0.1, and recorded durable event 6105 at 07:27:53.	C6 LLDP physical-interface restore	The ledger retains the exact package-default UCI baseline and applied export with configured_interfaces=[eth0.1]; WRT retains lan1–lan4. C6 remained online with both managed BSSs enabled. SQLite integrity is ok and foreign keys are clean. The configuration write intentionally cleared the transient SSH credential; one final credentialed read-only runtime diagnostic remains.	Verified configuration; runtime diagnostic pending
FS-113	8	C6 read-only diagnostic event 6138 completed at 07:32:43. The UCI export contains only eth0.1; runtime marks it RX and TX; and its LLDP neighbor is WRT MAC <gateway chassis MAC> on remote port lan3.	Restored physical topology	Both routers' LLDP sources are observed. Current edge 414 is measured C6→WRT on lan3, backed by bridge FDB, IPv4 neighbor, and LLDP evidence. The signed-in graph and accessible table show five nodes and four current links. Its only two coverage notices truthfully report that BusyBox brctl showmacs lacks VLAN identity for the two wired edges; no source failure remains. SQLite integrity is ok and foreign keys are clean.	Verified live
FS-114	8	Rejected LLDP install/removal or interface-plan requests now clear the transient password/private-key fields before retry, preventing replacement credentials from being appended to a rejected secret. Successful plan/apply reuse remains unchanged and regression-tested.	LLDP credential retry safety	UI 273/273, production build, daemon/API tests, vet, and diff checks pass. Artifact dev-schema17-fresh-start-transparent-v37 is 15,278,546 bytes with sha256:8acff57bf625c16eb154a8e5bcbeabb51e4a384dc75b1576a640276154f2e7fb; PID 27810 is healthy on schema 17 at 127.0.0.1:8080. The restart changed no router state and invalidated the prior controller session as expected.	Fixed and running; signed-in boundary check pending
FS-115	8	The v37 signed-in sweep passed the joined UI checks but found that a direct request for /topology rendered Dashboard after authentication.	Direct-route rendering	App route initialization now honors the browser pathname across the sign-in boundary and has regression coverage for direct routes. No router, package, service, database intent, or network configuration changed.	Fixed in v38 and verified live
FS-116	8	v38 verified the direct /topology fix. Its first topology refresh briefly exposed reciprocal gateway↔AP LLDP edges, producing five links before peer rediscovery closed the reverse interval.	Startup LLDP direction	Source-aware reconciliation now withholds a new managed-device LLDP edge while its claimed parent lacks a proven path to the Internet root. If both directions are reported, it retains only the direction consistent with the rooted parent/child depths; without a unique rooted direction, it withholds both. The transient v38 state is retained as historical evidence rather than rewritten.	Fixed in v39; clean startup pending
FS-117	8	v39 startup and a signed-in direct /topology request show five nodes and four current links. Only the AP→gateway edge on lan3 is measured; no reverse duplicate appears, and both LLDP sources are observed. At that checkpoint, notices truthfully identify unavailable hostapd.get_clients association coverage on one device and unavailable VLAN identity from BusyBox brctl showmacs; neither is treated as an empty source.	Live artifact and recovery proof	Artifact dev-schema17-fresh-start-transparent-v39 is 15,278,850 bytes with sha256:c2a69e4703cd4745bd07f4e23d7f59818e382432bf0e6dd056ad58ec7201e9d1; PID 30591 was healthy on loopback. A mode-0700 ignored recovery directory holds a mode-0600 database (3,198,976 bytes; SHA-256 35d3d5fea6e1026d0bbc83fd58da85c8c7403c1836c1fd8a92c052716b5f999a) and mode-0600 keyring (275 bytes; SHA-256 8ee24ba977f355d38b8433ba3112185e8338015927f7f5577828cbc535aaaa80). recoverycheck passed with schema=17 devices=2 credentials=2 owned_sections=4 wlans=1 meshes=0. The consistent SQLite .backup initially had no nonempty -wal or -journal; recoverycheck may create a transient empty -wal plus -shm, neither of which contains recoverable database pages or belongs to the database/keyring recovery pair. The passphrase is intentionally excluded. This retained v39 checkpoint is superseded by FS-118 without erasing its evidence.	Verified v39 checkpoint; superseded by FS-118
FS-118	8	Final release-candidate binary .run/oonfeewrtd-fresh-start-transparent-v40, embedded dev-schema17-fresh-start-transparent-v40, is 15,312,098 bytes with SHA-256 9c3a797c1470d8630f42dc77619007370aad553fae00078716a5a5a457c6b4cc. It started at 2026-08-22 08:50:48 PDT; PID 39083 reported health ok. schema_version contains 14, 16 and 17; integrity and foreign-key checks are clean; two capability ledgers remain. The signed-in /topology deep link stayed on route and rendered five nodes/four active links: gateway→Internet wan, AP→gateway lan3, and wireless test client→gateway phy0-ap0 measured; wired test client→gateway lan2 ambiguous. No reciprocal gateway→AP edge appeared. After the complete poll, hostapd.get_clients was observed for device 1 (gateway) and empty for device 2 (AP); only two truthful BusyBox VLAN ambiguity gaps remained. The LLDP UI retained controller-managed lan1–lan4 on the gateway and eth0.1 on the AP.	Merge-ready runtime, gates and recovery	Full Go normal/race/vet/tidy/module-verification, all 274 UI tests plus production build, bundle budget, diff check, tree/history secret scans and binary reproducibility passed. Final-RC recovery directory .run/recovery-schema17-v40-a3VvOj5a is mode 0700 and contains only mode-0600 database/keyring files. Database: 3,198,976 bytes, SHA-256 950fca2fef80707b1333b7b240dc1b11875929a0c54ba5f0327e126c29e85762; keyring: 275 bytes, SHA-256 8ee24ba977f355d38b8433ba3112185e8338015927f7f5577828cbc535aaaa80. recoverycheck returned schema=17 devices=2 credentials=2 owned_sections=4 wlans=1 meshes=0; its transient zero-byte WAL and 32,768-byte SHM were removed. The build, restart, checks and recovery copy changed no router state. This is a final release candidate, not a tagged or published release.	Verified merge-ready RC; not released
FS-119	9	Protected PR #4 merged to main; all five required checks passed. Annotated tag v0.1.0-rc.1 targets that merge and its workflow published four deterministic binary archives, SHA256SUMS, and a public OCI index for linux/amd64 and linux/arm64 with attestations. An anonymous fresh clone, unauthenticated asset downloads, and anonymous container pull all succeeded. Every archive checksum matched. The extracted Darwin/arm64 binary and public container both reported the exact release version, served /healthz=ok, returned needs_setup=true, created schema 17 with integrity ok and zero devices, stopped cleanly, and passed the bundled recovery checker with all object counts zero. The container ran non-root with a read-only root filesystem, all capabilities dropped, and no-new-privileges; its test port was bound only to loopback.	Published clean-install proof	Fresh state and credentials lived only in a mode-0700 temporary directory. No administrator was created, no device was configured, and no discovery, adoption, RF scan, package action, or router request ran. The exact test container was removed after its clean exit.	Verified public release; no router change
FS-120	9	Clean-install inspection found that SQLite's live -wal and -shm files inherited the process umask as mode 0644. The enclosing data directory was already enforced as mode 0700, and shutdown removed both sidecars, so the published RC's documented installation remained private; individual copied sidecars could nevertheless retain an unsafe mode.	Post-release local-file hardening	Daemon startup now tightens the database, WAL, and SHM to mode 0600 before serving and fails closed on a real permission error. The existing-directory regression covers mode 0700 for the directory and 0600 for keyring/database/sidecars; focused race, full Go, vet, and diff checks pass. This source change is newer than v0.1.0-rc.1 and belongs to the next release.	Fixed in source; next release
FS-121	External	A reporter ran read-only Inspect capabilities on a Cudy M3000 v2 with Motorcomm YT8821, OpenWrt 25.12.5, board cudy,m3000-v2-yt8821, target mediatek/filogic. Before the fix, six BSS interfaces were counted as radios and the direct LAN device was lost. The corrected nightly reported two physical radios, LAN eth1, WAN eth0, active WAN-route evidence, DHCP disabled, no switch capability, and Gateway + AP; the reporter confirmed “Looking good” in issue #19.	External read-only hardware inspection	This proves the corrected Inspect path only. It does not authorize or validate adoption, Apply/rollback, WLAN operation, tagged VLANs, polling/resource budgets, LLDP/topology, RF scans, speed tests, un-adoption, or any other Filogic board.	Verified read-only inspection only
FS-122	External	Issue #20 reproduces the pre-v0.1.3 WAN-selection defect on v0.1.1: the controller selected draytek_mgmt even though the installed main-table default route used pppoe-wan, leaving traffic counters empty. The supplied router evidence includes default ... dev pppoe-wan.	Effective WAN route and PPPoE mapping	v0.1.3 replaces the interface-name heuristic with a jointly decoded installed IPv4 route plus active netifd-interface mapping, including logical wan to runtime pppoe-wan; focused parser, collector, API and UI release tests cover the correction. The reporter has not yet confirmed the result after upgrading. This is not hardware proof for ECMP, mwan3, custom policy routing, multiple equal-best defaults, bonds, per-uplink health or manual WAN selection.	Reproduction verified; release-tested fix; reporter confirmation pending

Status values: waiting, reproduced, fixed, accepted limitation, or verified. A fix closes only after its clean-run reproduction and rollback test pass from the relevant baseline.