DottaandPaperclip
fa50cab568
## Thinking Path > - Paperclip's board should open a task quickly while keeping its conversation and composer stable. > - The browser currently downloads unrelated screens and unopened dialog implementations before task content appears. > - Splitting routes alone creates many shared requests and did not improve measured cold loading. > - This change groups the startup and task dependency trees, preloads the task chunk, and defers optional routes and dialogs. > - Existing coordinated history reveal stays intact so late data does not insert content above the reader. > - Hidden routes must not overwrite saved scroll positions with zero-height geometry. > - Repeated browser measurements and delayed-response tests establish the result independently of bundle-file size. ## Linked Issues or Issue Description Refs #14758. Related prior work: #10463 and #14727. **What existing behavior does this improve?** Cold task-page opening downloads and evaluates code for other screens and globally mounted, unopened dialogs. A direct task link should reach its saved conversation sooner without moving already-visible messages or the composer. **Subsystem affected** Board UI startup, route boundaries, dialog loading, task scroll restoration, and the issue-detail performance harness. **Proposed behavior** Load optional screens and dialogs when needed, keep startup requests bounded, and preload the task route. Preserve the current history reveal policy. Keep the shell mounted during route loading and preserve the reader's position when a route is temporarily hidden. **Additional context** The older bundle-splitting attempt in #10463 is still open from August. This implementation targets current master and deliberately preserves today's editor, composer, and transcript reveal behavior. It does not implement the alternative transcript-row design discussed in #14758. ROADMAP.md does not describe overlapping startup-bundle work. ## What Changed - Lazy-load board routes, standalone screens, the legacy layout, onboarding, and unopened create dialogs. - Keep activated dialogs mounted across close/reopen to retain their existing draft lifecycle. - Group startup and issue dependencies and preload the emitted issue chunk from the production HTML. - Contain route loading within the shell and retain existing chunk-error recovery. - Contain dialog import failures locally, support cancellation, and keep setup dismissed after a late download. Warm the task module from task lists and keep the small chat redirect eager. - Wait for task-creation dialog fields in the browser fixture before filling an explicit title. - Ignore zero-height scroll geometry while a route is hidden. - Reuse the same persisted performance fixture between builds, record actual network spans, and distinguish concealed loading content from the ready thread in browser assertions. ## Verification - Production UI build and UI TypeScript check passed. - Recovery follow-up: 74 focused UI tests passed; the cancellation change passed 23 focused tests plus all 131 onboarding tests (the latter with a 15-second per-test timeout on the contended local host). - Setup cancellation was reproduced against the prior production build and verified fixed after releasing the held real wizard download. - 91 focused UI tests passed; the final route registrations were checked again after making standalone screens lazy (33 routing tests passed). - All eight real-browser layout scenarios passed: delayed comments, late media, properties changes, growing drafts, older history, Back navigation, deep links, desktop/mobile same-task links, request failure/retry, and stalled native/log reads. - Browser walkthrough: read a populated task, submit one reply, refresh, navigate to Projects, and return. The reply persisted once and the normal composer remained usable. - Token design gates passed. The separate repository-wide publish-token scan fails on pre-existing references to the local maintainer username in unchanged files; this change adds none. - Production-build measurements use the same persisted task, local API/database, fresh browser contexts for cold opens, and five samples per scenario/profile. These measurements do not establish deployed staging latency. - Final head `076466816a`, consecutive before/after production builds: five samples per scenario/profile, same saved task and server. Cold Fast 4G/4x CPU content paint: **5,775 → 4,248 ms (26%)**; issue API server timing was 23 ms in both sets. Warm Fast 4G: 989 → 971 ms. JavaScript transferred before content: **2,596 → 1,722 KiB (34%)**. - Unthrottled cold content paint: 1,306 → 676 ms; warm: 269 → 224 ms. These local timings vary with host load. Earlier measurements showed about 20% cold improvement, and a contended intermediate run had substantially higher API latency; those runs are retained in the local evidence. The final matched pair meets the proposed 25% target, but it does not establish a guaranteed 25% improvement across environments. - All four browser scenarios that failed on the first CI run passed locally after the readiness fixes; the subsequent CI run passed all eight browser shards. - Fault-injection browser checks: delayed route loading preserves shell geometry; a failed route recovers through Back; cancelled or failed dialog loading preserves an unsent reply; Back dismisses pending setup and contains its late failure. - Final head `076466816a`: all CI gates green (55 successful checks, no pending or failed checks); Greptile 5/5 with no actionable findings and all review threads resolved. ## Risks - Dynamic chunks add a loading state on first entry to optional screens and dialogs. Route failures use the existing error boundary. Optional dialog failures are dismissible without unmounting the board; retrying a rejected import requires a reload. - The task preload prioritizes the primary board journey, including when another screen is opened first. - Chunk grouping should be revisited when the dependency graph changes; bundle size alone does not establish a speedup. - No API, authorization, migration, editor semantics, or transcript-reveal policy changes. ## Model Used OpenAI Codex, GPT-6, with reasoning, repository tools, code execution, and browser verification. The runtime does not expose a more precise model identifier or context-window size. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>
Issue-detail performance baseline
Run the repeatable baseline from the repository root:
pnpm exec playwright test --config tests/perf/issue-detail/playwright.config.ts
The rig starts an isolated seeded Paperclip instance, runs five samples for each scenario/profile, and writes median-ready raw data plus a Markdown table to test-results/issue-detail-perf/.
Scenarios:
- S1 warm in-app navigation: loads the Issues list, clears the waterfall, and clicks the seeded issue.
- S2 cold open: creates a fresh browser context and deep-links to the seeded issue.
Profiles:
- Unthrottled.
- Fast 4G network with 4x CPU slowdown.
Override the sample count (minimum five) or port when needed:
PAPERCLIP_ISSUE_PERF_RUNS=7 PAPERCLIP_ISSUE_PERF_PORT=3210 pnpm exec playwright test --config tests/perf/issue-detail/playwright.config.ts
Outputs include baseline.md, baseline.json, and a Chrome trace for the first run of each scenario/profile. Open *.trace.json in Chrome DevTools Performance to inspect the issue-detail:* user-timing marks.
For bundle comparisons, build the UI and serve the production assets from an
isolated local instance with PAPERCLIP_UI_DEV_MIDDLEWARE=false. The default
managed server above uses development middleware, which does not reproduce
production chunk loading. Keep the server, database, browser profile and sample
count the same for both builds, and avoid concurrent builds or test suites while
measuring latency.
Copy the first run's output outside test-results/issue-detail-perf, then reuse
its persisted task with PAPERCLIP_ISSUE_PERF_SEED_FILE=/path/to/before/baseline.json
and PAPERCLIP_ISSUE_PERF_BASE_URL pointing to that disposable instance. The
harness validates the task identity before measuring. Network spans in the trace
use recorded request start/end timestamps relative to task navigation; they
include completed requests observed during the sample, even after content paint.
Task layout stability
layout-stability.spec.ts exercises the real task route, including Inbox
navigation, with 160 Markdown comments and a resolved interaction. It delays
initial comments, tests failures and retry, tracks a reading anchor across
media growth, composer resizing, properties toggles, older-page loading and
Back navigation, and covers mobile reduced motion and explicit comment links.
The eight scenarios also exercise same-task hash navigation without remounting
on desktop and mobile, and stalled native/log reads that expose Retry after
the 15-second request deadline.
Videos and per-frame layout.json measurements are written under each test's
output directory. The two-pixel assertion measures a logical row's viewport
offset; total scroll offset legitimately changes when history is prepended.
To run against an existing disposable local test-drive instance:
PAPERCLIP_ISSUE_PERF_BASE_URL=http://127.0.0.1:3102 \
pnpm exec playwright test --config tests/perf/issue-detail/playwright.config.ts layout-stability.spec.ts
The suite creates its own company and fixtures. The URL override accepts only loopback origins and rejects remote hosts. Use a disposable local instance, not a shared or production instance. Without the override, the harness starts its own isolated instance as before. Live provider walkthroughs additionally require a configured native Paperclip runner and Codex authentication; deterministic browser fixtures do not substitute for watching an actual provider run.
For the live walkthrough, first assign a disposable task to a native Paperclip
runner configured with the Codex provider. Its scratch project should contain
a small sum.mjs fixture. The script sends a paced job, scrolls up, disconnects
and reconnects, steers a follow-up, and records through completion:
PAPERCLIP_LAYOUT_LIVE_URL=http://127.0.0.1:3102/LAY/issues/LAY-8 \
node tests/perf/issue-detail/live-feed.walkthrough.mjs
Inspect test-results/task-layout/live-acceptance/ for the video, screenshots,
per-frame positions, layout shifts, browser timing counters, and reading-anchor
measurement. The live script rejects non-local URLs and uses real provider
capacity. Review the video as well as the assertions: layout-shift scores alone
do not capture programmatic scrolling or replacement flashes.