Files
PaperClipAI/tests/perf/collections
DottaandClaude Opus 5.5 b184e40108 perf(ui): serve every project list from one includeArchived read (#20395)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work
> - The board UI reads the company project list in many places: the
sidebar, starred projects, the command palette, the new-task dialog, and
archive-aware pages such as the Mine inbox
> - Active-only consumers read `GET /projects`, and archive-aware ones
read `GET /projects?includeArchived=true`, under two React Query keys
> - A Mine load therefore fetched the same large payload twice (580–590
KB each on our dev instance)
> - The two responses differ only by archived rows; the server's active
list is exactly the rows where `archivedAt` is null
> - This pull request makes every consumer share the
`includeArchived=true` query, and active-only consumers filter it with
`select`
> - The benefit is one project read per page instead of two

## Linked Issues or Issue Description

**What existing behavior does this improve?**
Duplicate project list reads on page load.

**Subsystem affected**
Board UI project queries (`ui/src/lib/company-projects-query.ts` and its
consumers).

**Current behavior**
A cold Mine load sends both `/companies/:id/projects` (sidebar) and
`/companies/:id/projects?includeArchived=true` (inbox).

**Proposed behavior**
One `includeArchived=true` read serves both. Active-only consumers apply
`selectActiveProjects`.

**Reason and benefit**
The project list is one of the largest shell payloads. Reading it once
saves a large response on every page that has both kinds of consumer.

## What Changed

- New `companyProjectsQuery(companyId, { includeArchived? })` in
`ui/src/lib/company-projects-query.ts`. It always uses the
`includeArchived: true` key and fetch. For active-only use it adds a
stable, module-level `select` that keeps rows without `archivedAt`.
- 22 files that read the active list now spread
`companyProjectsQuery(...)`, and so do the plugin SDK project picker and
16 archive-aware pages that wrote the shared key and fetcher inline.
Their `enabled` and other options are unchanged. `OnboardingWizard`'s
one imperative read is unchanged. `pages/Inbox.tsx` already reads the
same key and fetcher, so it shares the entry without an edit.
- Invalidation: project mutations and live events invalidate
`queryKeys.projects.all(companyId)`, which matches the shared key. The
onboarding wizard invalidated the old active-only key; it now
invalidates `projects.all`.
- Tests: new `company-projects-query.test.tsx` (one request for both
consumers, correct filtering, and one refetch after `projects.all`
invalidation). Three existing tests (`CommandPalette`, `CompanyExport`,
`GitHubBotManagement`) now seed or expect the shared key.
- New browser check
`tests/perf/collections/shared-project-list.spec.ts`: after the Mine
inbox read completes, the page has sent no active-only project request.

## Verification

- `pnpm verify` passes.
- `ui`: the consumer suites (`CoordinatorSidebar`, `SidebarProjects`,
`SidebarStarredProjects`, `CommandPalette`, `NewIssueDialog`,
`AgentWorkPanels`, `CoordinatorNeedsYou`, `IssueDetail`,
`ProjectDetail`, `Projects`, `CompanyExport`, `ChatExecutionDefaults`,
`GatewaysList`, `Search`, `IssueProperties`, `persisted-query-cache`)
pass.
- Browser check:
`PAPERCLIP_COLLECTION_PERF_BASE_URL=http://127.0.0.1:<port> pnpm exec
playwright test --config tests/perf/collections/playwright.config.ts
shared-project-list.spec.ts`. It passes on this branch and fails on
`master`.

## Risks

- A page that needs only active projects now downloads archived rows
too. For most companies that is a small difference; the duplicate read
it removes is a full copy.
- The server does not order either list, and consumers sort for display,
so filtering on the client keeps behavior.

## Model Used

- Claude Opus 5.5 (`claude-opus-5-5`), Anthropic, via Claude Code with
tool use (shell, file edits, browser). 1M-token context window. Extended
thinking was off.

## 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
- [ ] All Paperclip CI gates are green
- [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-09 17:42:47 -06:00
..

Tasks and Inbox cold-open checks

Run against a disposable local instance with production UI assets. The suite creates 220 unassigned backlog tasks and 110 board approvals. It does not invoke a model. The origin must be a loopback address.

pnpm --filter @paperclipai/ui build
PAPERCLIP_COLLECTION_PERF_BASE_URL=http://127.0.0.1:3219 \
  pnpm exec playwright test --config tests/perf/collections/playwright.config.ts

Start the isolated instance with PAPERCLIP_UI_DEV_MIDDLEWARE=false to serve the production build. The instance and its database must be disposable. These tests retain and reuse their fixture in test-results/collections/fixture.json; they only replace it when the previous company's API returns 404. Other errors fail.

The journeys check desktop and phone row budgets, incremental scrolling, retained row identity and height, shared count-only navigation, the Coordinator Inbox with Streamlined UI disabled, and the page-owned Needs You feed and Needs attention task index. Screenshots and failure traces stay in test-results. Request counts and row budgets are acceptance checks. They do not establish an end-to-end latency improvement. Measure cold, warm, and Back timings separately with the same fixture, assets, cache, viewport, and CPU/network settings.

parent-context.spec.ts holds the complete Mine response, including parent metadata, then checks row geometry through deferred visible diagnostics. Mine uses one assembled source read; it does not fetch parent or failed-task context from the browser before reveal. Recent retains its separate index/context path. startup-regressions.spec.ts covers session bootstrap and legacy fallback, partial source errors, resolved failure context, scoped 429 recovery, and archive/Undo persistence. Its authenticated session and failed-run responses are simulated transport fixtures over a real local board. They do not prove hosted login or model execution. The embedded bootstrap case holds separate company/access responses until Mine rows appear. Initial WebSocket reconciliation may request those endpoints in the background; their responses must not block the first rows. Missing or mismatched bootstrap data still requires the ordinary fallback reads. The two 429 cases keep the existing automatic backoff and Retry-After policy. They allow 45 seconds for its bounded retry window before exercising manual Retry. Other cases keep the normal short assertion timeout. Timing samples do not accelerate the browser clock.

Run these focused browser checks before the full collection suite:

PAPERCLIP_COLLECTION_PERF_BASE_URL=http://127.0.0.1:<candidate-ui-port> \
  pnpm exec playwright test --config tests/perf/collections/playwright.config.ts \
  parent-context.spec.ts startup-regressions.spec.ts

To collect timings, build the pinned baseline production assets once and retain that output. Build candidate UI assets only when their inputs change. Serve both outputs from stable loopback origins. If server behavior changes, each origin must proxy its matching pinned API revision against the same disposable database. Using the candidate API for both arms proves only a UI comparison. Keep agents and external providers inactive. Neither arm may migrate or reseed the shared fixture during a comparison.

The harness checks the configured API against each UI proxy, records HTML and entry-asset SHA-256 receipts, and records both serving API revisions. Supply full source SHAs to label the client artifacts, then run:

INBOX_BASELINE_URL=http://127.0.0.1:<baseline-port> \
INBOX_CANDIDATE_URL=http://127.0.0.1:<candidate-port> \
INBOX_BASELINE_API_URL=http://127.0.0.1:<baseline-api-port> \
INBOX_CANDIDATE_API_URL=http://127.0.0.1:<candidate-api-port> \
INBOX_BASELINE_SOURCE_REVISION=<full-baseline-sha> \
INBOX_CANDIDATE_SOURCE_REVISION=<full-candidate-sha> \
  node --import ./server/node_modules/tsx/dist/loader.mjs \
  tests/perf/collections/measure-mine-context.ts

The script retains a four-parent, 30-child fixture, archives three completed parents, and enables the personal Coordinator preference. Both APIs must expose that same company. It runs five alternating pairs by default. INBOX_PAIRS, INBOX_FIXTURE_FILE, and INBOX_OUTPUT override the count and evidence paths. No request interception is used in timings. INBOX_NETWORK_LATENCY_MS accepts an integer from 0 to 2000 and defaults to 0 (native loopback). A nonzero value uses Chromium CDP network emulation on every page, with unlimited throughput and unchanged CPU. Record native and 100 ms latency runs in separate INBOX_OUTPUT files; each sample labels its scenario. CDP specifies minimum request-to-response-header latency. This controlled extra round-trip scenario tests serial request dependencies; it does not prove hosted latency or reproduce the full staging network.

By default, INBOX_HTTP_CACHE=warm warms each browser context once, then reloads the document for each initial sample. This retains HTTP cache while clearing app query state. INBOX_HTTP_CACHE=cold uses fresh browser contexts; INBOX_HTTP_CACHE=both records these scenarios separately. Warm Recent-to-Mine navigation and task-to-Mine Back retain query state. Use INBOX_HEADFUL=1 and PAPERCLIP_PLAYWRIGHT_CHANNEL=chrome when installed Chrome is the intended browser.

Initial readiness requires visible Mine rows plus two animation frames. The report retains every sample and failure, exact row membership/order, row geometry, asset identities, full API resource timings, request statuses and primary-request start. Health, session, board access, companies and preferences remain timing controls. A faster initial total alone does not attribute a gain to its final context response. The fixed post-reveal window defaults to two seconds; INBOX_TAIL_MS changes it, up to 30 seconds. Counts retain 429s and unfinished requests rather than treating them as successful work. Use the same immutable asset cache policy on both origins and stop builds and suites during timing runs.

Startup cases also check that shared collection controls do not require the task-detail bundle before reveal, even when a different organization is remembered. Code warms after the collection paints, or on task-link intent. A successful immutable response allows module preloading to compile the cached chunk without executing it. A failed fetch leaves the collection usable and permits navigation without a document reload. Direct task URLs preload their static dependencies while identity is pending. These cases must run with production assets: development modules do not exercise the bundle boundaries.

The functional cases route feature settings and delayed responses. Routing disables browser HTTP caching. For warm-cache timings, set the real local feature settings and use fresh browser contexts without request interception. Keep normal cache writes enabled so code warmed after paint can be used on the next task open. Retain intercepted runs as separate diagnostic evidence. Match the server's hashed asset cache policy (public, max-age=31536000, immutable); Vite preview's default no-cache policy adds revalidation that the shipped server does not require. Keep HTML uncached and return 404 for missing assets.