[Fooftilly]

Evidence and rationale (#740)

Post-#939 manual Person durability profiler #40541579974 on master@326cbf4 passed one excluded warm-up plus 3/3 isolated real Chromium measured trials per scenario. Median inclusive Work navigation (person_{create,edit}_link_nav) remained 3.258s / 3.279s, consuming roughly half the inclusive role-link phase (6.943s / 6.825s), even after the independent role-modal parallel-catalog optimization (#939). Modal medians were 3.046s / 3.161s; these separate runs do not prove attributable production speedups.

The current _open_work_from_home helper deliberately traverses the actual Folders → Recently Added → Work path. Without stage-level attribution, we cannot tell whether repeated ~3.3s is the Folders transition, recently-added projection, clicking the card, or Work-detail readiness. Do not change production Work fetch/retry/cache/durability semantics based on unproven hypotheses.

Scope

• Add an optional, keyword-only profile_prefix to the existing tests/e2e/test_app.py::_open_work_from_home helper. With no prefix (all existing callers), retain the exact same clicks/waits and no phase recording; with a prefix, nest four non-overlapping timings without changing the helper's UI interactions:
  • link_nav_folders: Folders sidebar click and route-hash readiness.
  • link_nav_recent: Recently Added tab click and target Work card presence.
  • link_nav_card_click: real Work card click.
  • link_nav_work_ready: original Work route/hash + displayed title barrier.
• Enable these diagnostics only for the existing person_create_link_nav and person_edit_link_nav phases in the two offline Person durability browser scenarios. Both tests still perform exactly the same UI, offline/reload, dependency, server and ACK assertions.
• Extend the existing parameter-free manual-only profiler's phase inventory and reporting, and its browser-free AST contract: exact helper stage set, both opt-in callsites nested under their parents, and mandatory phase presence in measured trials.
• The new stage rows are nested in link_nav, which itself is nested inside role_link. Do not add the overlapping parent/child times to infer total runtime.

No production/browser source or database changes, CI gate policy, new workflow, auto-trigger, retries, timeouts, fixtures, isolation, or assertion changes.

Validation and follow-up

• Gate on exact-head static/unit/API, source E2E and applicable packaged E2E CI, relevant security and review checks before maintainer-approved merge.
• After merge, run gh workflow run e2e-offline-person-profile.yml -R Fooftilly/PRKS --ref master once. Read all four nested stage medians across three passing fresh Chromium trials for both scenarios.
• Only then consider a narrowly guarded, independently measured optimization for the dominant phase; especially preserve offline Work read coherency, pending-delete/create semantics, route-owner/stale-result fences, and original click/readiness assertions. No speculative retry suppression, shortcut navigation, or 6→8-shard decision.

Refs #740.

---

[coldtea-pr-lens]

Note

The title starts with test(e2e):, so PR Lens left this pull request undrawn. Comment @pr-lens draw to draw it

_{github.comment.notice: false in .github/pr-lens.yml turns this note off}

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.

[Fooftilly]

2026-10-27 measurement clarification: manual Person profiler #40544348639 succeeded (one excluded warm-up + 3/3 fresh Chromium trials each for Create/Edit, all tests passed, no skips/errors). However, it was dispatched with ref=master at 326cbf4767fdadd2cad964c156ecf3aab81f48f9, not this PR's bf59905a090ed7bfa108d7c2d9efbc80e1a47bd4. Therefore it cannot report the newly added link_nav_{folders,recent,card_click,work_ready} phases. The previous profiler run #40541579974 likewise targeted master; avoid treating the new green run as PR #943 instrumentation validation or comparing its whole-test times as an attributable optimization.

Exact-head PR #943 CI now green: seven GitHub workflow runs successful, including full six-shard Chromium E2E, unit/API gate, static, CodeQL, workflow lint and zizmor; SonarCloud and Codacy passing; Codex and Devin report no findings; no unresolved review threads. PR remains open, unmerged, without maintainer merge approval.

Correct command to measure PR's new subphases before merge:

gh workflow run e2e-offline-person-profile.yml -R Fooftilly/PRKS --ref test/e2e-person-work-navigation-phases-740

Confirm resulting Actions run's head_sha equals bf59905a090ed7bfa108d7c2d9efbc80e1a47bd4. Alternatively, after explicit maintainer-approved merge, dispatch against master. Do not touch production offline Work reader or reduce browser assertions until these new stage medians are captured.

[Fooftilly]

2026-10-27 — PR #943 exact-head navigation profile complete

Manual Actions run #40545986986 completed successfully on head bf59905a090ed7bfa108d7c2d9efbc80e1a47bd4 (branch test/e2e-person-work-navigation-phases-740), with one excluded warm-up + three passing fresh-storage Chromium trials each for offline Person create and edit. No failures/skips/errors or assertion/policy change.

Nested stage, median of 3 (seconds)	Person create	Person edit
Whole test wall	13.141	11.690
Inclusive role_link	7.349	6.562
Inclusive link_nav	3.552	3.289
link_nav_folders	0.037	0.052
link_nav_recent (tab switch + target card visible)	2.579	2.078
link_nav_card_click	0.017	0.019
link_nav_work_ready	1.005	1.123
link_modal	3.461	2.086
link_save	0.048	0.047

Parents overlap children. Across three trials the Recently Added stage varied from 2.094–2.582s for Create and 2.075–2.095s for Edit. It is ~73% / ~63% of inclusive navigation (ratio of medians); Work readiness adds ~28% / ~34%. This is not whole-suite savings evidence; trials were isolated, not controlled before/after A/B.

Source-informed diagnosis and guarded follow-up

The Vue FolderLibraryRoute.vue setActiveTab / loadRecentlyAdded awaits a metadata-overlay refresh and, when the in-memory projection cannot be reused, prksOfflineRecentlyAddedFetch. Its list path readThroughList is server-first even when already confirmed offline, only reading IndexedDB after a network failure. The request coordinator permits two GET network retries with jittered 250ms and 750ms nominal delays. This is a plausible explanation for the repeated two-second phase, not yet a per-request measured attribution; the stage also includes pending-overlay work and Vue paint.

Next targeted action: test a narrow, explicitly opted-in cache-first path for already-confirmed-offline Recently Added, or first capture scoped request/overlay timings, with parity checks for invalidated/missing/malformed snapshots, fresh-storage absence, abort/superseded route, reconnect during IndexedDB reads, generation sweeps, online read-through, and server HTTP domain errors. Do not globally turn off retries, switch navigator.onLine to authority, shortcut connectivity probes, hide UI assertions or activate packaged smoke default. Coordinate with completed probe fixes #818/#819 and ongoing coordinator lifecycle #822. If the guarded semantics cannot be shown safe, retain network-first design.

PR #943 is still open, its seven exact-head CI workflow runs passed, no unresolved review threads and no Codex/Devin findings. This run completes the PR's requested diagnostic acceptance; leave merge to explicit maintainer approval.