docs(02-08): re-measure every surface on archi-dev-box, commit Results/Outstanding

Re-ran the plan 02-01 harness unmodified against archi-dev-box (same
target, same runs:3 contract) producing 02-PERF-AFTER.json (15/15 rows,
matching the baseline row count). Appended FINDINGS.md's Results table
(per-surface baseline/after comparison, Verdict) and an Outstanding
list of every regression, unmeasured surface, and unsettled gap.

Discovered and cross-verified (via a corrected, harness-independent
remount probe, reproduced twice) that the harness's own remount-probe
selector ('.view-container', generic and shared across every main tab)
became ambiguous once real KeepAlive caching keeps multiple instances
alive simultaneously — the raw artifact's 'remounted' field is
confounded for main tabs whose instance actually survives. Corrected
readings show Home/Apps/Marketplace/Cloud/Web5/Fleet genuinely survive
a round-trip; Server genuinely does not (a real, confirmed gap against
this phase's own must-have truth, flagged in Outstanding, not fixed
here — out of this task's measurement-only scope).

Also recorded real timing regressions (Discover, Server, Web5, Fleet,
AppDetails, OpenWrtGateway) honestly rather than averaging them away,
per the plan's own prohibition, alongside a timing-variance caveat
(baseline and after-run were taken at different times of day on the
same multi-service node).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

.planning/phases/02-ui-performance/02-FINDINGS.md

@@ -188,3 +188,131 @@ The shared foundation both 02-02 and every other per-surface plan depend on —
 Dashboard.vue nested-`<router-view>` KeepAlive restructure and the `useCachedResource`
 `onActivated` extension — is owned by **02-04**, per RESEARCH.md's own recommendation to
 land that shared work before converting individual views.
+
+## Results
+
+**Method:** Re-ran `neode-ui/e2e/perf/{surfaces,measure,surface-perf.spec}.ts` **unmodified**
+(no harness file was edited to produce these numbers) against `archi-dev-box` — the same
+target, same `runs: 3`, same `ARCHY_PERF_OUT` contract as the baseline. Run header:
+`baseUrl: "http://archi-dev-box"`, `commit: "3ee20430"`, `runs: 3`, taken
+`2026-07-31T01:27:30.384Z` (baseline was taken `2026-07-30T10:30:40.048Z` — a different
+time of day on the same physical node; see the timing-variance note under Outstanding).
+15/15 rows present (same count as baseline); Mesh and Chat are again `unmeasured`, for
+reasons recorded per-row below.
+
+**A new methodology finding, discovered and independently cross-verified this run (not
+present at baseline time because no `<KeepAlive>` existed then):** `SURFACES.rootSelector`
+for every main tab is the generic class `.view-container`, which `DashboardRouterView.vue`
+falls through onto *every* routed view's own root (`<component :is="Component" :class="…
+'view-container flex-none'" />` — see `dashboardViewWrappers.ts`/`DashboardRouterView.vue`).
+Before this phase, only one view was ever mounted at a time, so `.view-container` was
+unambiguous. Now that multiple main tabs are simultaneously KeepAlive-cached (up to
+`KEEP_ALIVE_MAX`), **more than one `.view-container`-classed element can coexist in the
+document at once**, and `measure.ts`'s `stampRoot`/`readRootProbe` (`document.querySelector`,
+first DOM match) can silently stamp/read a *different* cached instance than the one actually
+being tested — confirmed directly by DOM inspection (`document.querySelectorAll('.view-container').length`
+returning 2 on a fresh visit to Marketplace, and the same call's *return order* changing
+between the stamp step and the read-back step as Vue relocates deactivated subtrees into its
+internal KeepAlive storage). This was not something I could fix by editing the harness (out of
+this task's `files_modified`, and re-running the historical baseline commit to keep the pair
+comparable would be invasive for a field — `remounted` — whose baseline value is trivially
+`true` everywhere pre-KeepAlive regardless of selector precision). Instead, for every
+main-tab row I independently re-verified `remounted` with a corrected, harness-independent
+method: stamp/read the specific `.view-container` ancestor of the surface's own **visible**
+`contentSelector` match (`getBoundingClientRect`/`offsetParent`, since KeepAlive's inactive
+cached instances are not laid out on screen) rather than the first DOM match. Reproduced
+twice for Server specifically to rule out a fluke. The **"Remounted (verified)"** column below
+is this corrected reading; the **"Remounted (raw)"** column is the harness artifact's own
+(sometimes confounded) field, kept visible rather than silently replaced.
+
+| Surface | Kind | Baseline revisit ms | After revisit ms | Baseline RPC | After RPC | Remounted (raw, baseline→after) | Remounted (verified) | Verdict |
+|---|---|---|---|---|---|---|---|---|
+| Home | main-tab | 390 | 395 | 1 | 1 | true → true | **false (survives)** | improved — remount fixed; ms was already fast (D-02) and unaffected |
+| Apps | main-tab | 267 | 184 | 1 | 1 | true → true | **false (survives)** | improved — faster ms and remount fixed |
+| Marketplace | main-tab | 2033 | 683 | 13 | 8 | true → true | **false (survives)** | improved — 66% faster and remount fixed; RPC count still confounded by the Home-transit artifact 02-01 documented, unchanged this run |
+| Discover | secondary (cache-registered) | 1083 | 1257 | 1 | 1 | true → true | not independently re-verified | regressed — revisit got slower; raw remounted unchanged |
+| Cloud | main-tab | 247 | 129 | 0 | 0 | true → true | **false (survives)** | improved — faster ms and remount fixed |
+| Mesh | main-tab | — | — | — | — | — | — | **unmeasured** — `.mesh-status-grid` stayed hidden 20s across all 3 runs; device not reporting `connected` in this window, identical reason to baseline |
+| Server | main-tab | 738 | 849 | 8 | 2 | true → true | **true (genuinely remounts)** | **regressed** — slower ms AND the KeepAlive promise is not delivered for this tab, confirmed by two independent reproductions of the corrected probe. RPC count did drop (8→2, real `useCachedResource` benefit), but the surface still fully remounts on revisit |
+| Web5 | main-tab | 566 | 709 | 0 | 0 | true → true | **false (survives)** | regressed on ms despite remount being fixed — a split signal (0 RPC either time, so the added ~140ms is pure client-side re-render/re-activation cost on an instance that isn't actually being destroyed); flagged for direct profiling, not fixed here |
+| Fleet | main-tab | 330 | 1054 | 0 | 0 | true → true | **false (survives)** | **regressed, prominently** — 3.2× slower on revisit despite the instance surviving and zero RPC either time; the same split-signal pattern as Web5 but much larger. Reached via a 2-hop chain through Web5 first, so some of this may be transition-chain noise, but the raw number is recorded as measured, not adjusted |
+| Chat | main-tab | — | — | — | — | — | — | **unmeasured** — but for a *different* specific reason than baseline: baseline's block was the AIUI connecting-overlay outliving the close-button click budget; this run's block is the disk-usage `HealthNotifications.vue` toast (see below) intercepting `.chat-close-btn` for the same reason it now interferes elsewhere. Recorded as unmeasured either way, per the plan's own rule that an unmeasured surface is never presented as improved |
+| AppDetails | secondary | 1204 | 1510 | 2 | 1 | true → true | not independently re-verified (expected to remount; D-04 doesn't cache secondary screens) | regressed — revisit got slower despite one fewer RPC call |
+| MarketplaceAppDetails | secondary | 1793 | 1532 | 14 | 8 | true → **false** | not independently re-verified | improved on ms; the raw `remounted: false` reading is very likely the same rootSelector-ambiguity artifact described above (its `navSteps` transit a KeepAlive-cached Marketplace instance immediately before reaching the detail page) rather than evidence this secondary screen is now incorrectly instance-cached — flagged, not asserted either way. RPC count improvement is still confounded per 02-01's original note (13 of 14 baseline calls were Home-transit bleed-through; only `package.versions` was trustworthy) |
+| CloudFolder | secondary | 1212 | 985 | 0 | 0 | true → true | not independently re-verified | improved — faster ms, 0 RPC both times as before |
+| OpenWrtGateway | secondary | 663.5 | 1148 | 4 | 2 | true → true | not independently re-verified | regressed — revisit got slower; RPC count still confounded per 02-01's original note (captured methods are a subset of Server's own call set) |
+| Wallet / send flow | secondary (modal) | 2607 | 2556 | 0 | 0 | true → true | not independently re-verified (modal always remounts via `v-if`, by design) | unchanged — the anomaly 02-01 flagged (revisit slower than first-visit, pure client-side cost, 0 RPC) persists; no plan's `files_modified` touched `SendBitcoinModal.vue` (see Outstanding) |
+
+## Outstanding
+
+- **Server.vue does not survive a tab round-trip on real archi-dev-box hardware**, despite
+  being registered in `KEEP_ALIVE_PATHS` since 02-04 and 02-04's own Task 3 checkpoint
+  reporting it as approved. Confirmed genuinely (not a measurement artifact) via two
+  independent reproductions of a corrected, harness-independent remount probe. This directly
+  violates this plan's own must-have truth ("every main-tab path registered in
+  `KEEP_ALIVE_PATHS` has `After remounted` false"). Root cause not investigated here — Task 2's
+  scope is measurement, not per-view debugging, and this is a pre-existing 02-04 behavior, not
+  something this plan's own files touched. **Needs a follow-up plan or a targeted fix to
+  Server.vue/its KeepAlive wrapper registration before PERF-02's per-tab claim can be
+  considered fully verified for this specific tab.**
+- **Web5 and (especially) Fleet revisit ms regressed significantly despite their component
+  instances now genuinely surviving the round-trip** (confirmed via the corrected probe) and
+  zero RPC calls either visit. This is a split signal: the KeepAlive architecture is working
+  (no remount, no refetch) but something client-side is adding real wall-clock cost on
+  reactivation — Fleet's 330ms→1054ms (3.2×) is the more severe of the two. Not profiled or
+  fixed here; flagged for direct DevTools/Performance-panel investigation, the same class of
+  work 02-01 already flagged for Wallet-send's anomaly and never resolved.
+- **Discover, AppDetails and OpenWrtGateway all regressed on revisit ms** without an
+  independent remount re-verification (not main tabs subject to the plan's KeepAlive
+  must-have truth, so not re-probed under time constraints); OpenWrtGateway's RPC count is
+  still confounded per 02-01's original note (its captured methods are a subset of Server's
+  own call set from the Server-transit in its `navSteps`) and needs DevTools re-verification
+  before treating the RPC drop as this screen's own fix rather than confound noise shifting.
+- **MarketplaceAppDetails's raw `remounted: false` reading is very likely a rootSelector-
+  ambiguity artifact**, not evidence this secondary screen picked up incidental instance
+  caching — flagged, not independently re-verified given time constraints. If a future plan
+  needs to confirm D-04 (secondary screens are NOT instance-cached) still holds for this
+  screen specifically, re-run the corrected probe method documented above against it directly.
+- **Wallet-send's anomaly (revisit slower than first-visit, 0 RPC either time) is still
+  unaddressed** — 02-03 reported it as an unplanned-item gap (owned by 02-03 per this
+  findings doc, but `SendBitcoinModal.vue` never appeared in any plan's `files_modified`).
+  Carried forward unresolved.
+- **CloudFolder.vue's residual TTL gap**: `cloudStore.navigate()` (`cloud.ts`) still always
+  re-fetches on revisit — it just doesn't block paint. 02-03 explicitly left this as a gap
+  (outside its `files_modified`) rather than bolting on a second, parallel cache. Still open.
+- **PeerFiles.vue** was found by 02-03 to not actually use `useCachedResource` (contrary to
+  that plan's own `read_first` assumption) and force-refetches unconditionally on every mount
+  with the same loading/refreshing conflation bug 02-03 fixed elsewhere. Flagged by 02-03, not
+  fixed by any plan since. Still open.
+- **`/dashboard/settings` remains withheld from `KEEP_ALIVE_PATHS`** (02-04's own deliberate
+  exclusion, unaudited risk — `SystemDangerZone.vue`'s reboot poll, several `onMounted`-only
+  fetches in its child sections). Not part of this phase's scope to resolve; carried forward
+  as a known gap for whichever future plan audits Settings.
+- **`ContainerAppDetails.vue`** reconfirmed fully unreachable dead code (02-01, re-confirmed
+  02-03). A candidate for a follow-up cleanup deletion, not part of this phase.
+- **archy-x250-dev (the dev pair's second node) was offline** for both this plan's deploy
+  (Task 1) and this re-measurement — `tailscale status` showed it "offline, last seen 2h ago"
+  at Task 1 and unchanged when re-checked before Task 2. Only `archi-dev-box` received this
+  phase's build and was measured. D-11's verification target is `archi-dev-box` specifically,
+  so this does not block the plan, but the second dev-pair node has not received this phase's
+  changes at all and should get the same `--frontend-only` deploy once it's back online.
+- **Chat/Mesh remain unmeasured**, same as baseline for Mesh (device not reporting
+  `connected`); Chat's specific blocking cause changed from an AIUI-connection timeout
+  (baseline) to a disk-usage toast intercepting the close button (this run) — both are
+  environmental/UI-affordance issues rather than something either run's numbers can speak to.
+  The disk-usage toast (`HealthNotifications.vue`, no `pointer-events: none` on its
+  `.fixed.right-4.z-[200]` wrapper) intercepting clicks elsewhere on the page is itself worth a
+  follow-up fix independent of this phase — the node's disk is genuinely at 85% right now,
+  so the toast is a real, current, recurring condition, not a one-off.
+- **Baseline vs. after timing-variance caveat**: the baseline was taken at 10:30 local time;
+  this after-run at 01:27 the next day — different system load on the same physical,
+  multi-service node (85% disk, live containers, this same box also serving as the build
+  machine) may contribute to some of the regressed rows above independent of any code change.
+  This is recorded as an interpretive note, not used to soften any verdict above — every
+  regressed row is reported as regressed with its measured numbers. A same-time-of-day re-run
+  would help disambiguate real regression from environmental noise for Discover/Server/Web5/
+  Fleet/AppDetails/OpenWrtGateway.
+- **Assumptions & Flagged Items from the plan set not yet settled by this run**: FA-D
+  (`KEEP_ALIVE_MAX`) was settled in Task 1 (see its SUMMARY — confirmed at 6 via an on-device
+  memory reading). FA-B (`ContainerAppDetails.vue`) — see the dead-code note above. FA-E
+  (AIUI source) — settled by 02-07 (source located, D-14 landed upstream).