PaperClipAI

Jannik/PaperClipAI

0 Fork 0

mirror of https://github.com/paperclipai/paperclip.git synced 2026-11-14 00:14:02 +01:00

Commit Graph

Author	SHA1	Message	Date
scotttong squadbot Claude Opus 5.5	a5e01634f6	feat(ui): ask self-hosted users to star Paperclip on GitHub after 5 done tasks (#20453 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Many teams run Paperclip self-hosted, so the project grows when those users tell others about it > - A GitHub star is the cheapest way for a user to do that, but the app never asks > - Asking too early is noise. A user who has finished a few tasks knows whether Paperclip helps them > - This pull request adds a one-time, dismissable modal that asks self-hosted users for a star after their company has 5 done tasks > - The benefit is more visibility for the project, and no repeated prompt for the user ## Linked Issues or Issue Description Subsystem affected Board UI (dialogs shown in the main app shell). Problem or motivation Self-hosted users have no prompt to star the repository. Users who like Paperclip often do not think of it. A prompt at the right moment helps other teams find the project. Proposed solution Show a small modal once the selected company has 5 tasks with status "done". The modal shows the Paperclip mark, the headline "You completed 5 tasks!", a short body, a "Star on GitHub" button and a "Not now" button. It shows only once per browser. Closing it in any way counts as seen. Alternatives considered A permanent banner or sidebar link. Both stay on screen after the user decides, so they cost attention every day. A one-time modal costs attention once. Roadmap alignment This is a small UI addition. It does not overlap with planned core work in ROADMAP.md. No related public issues or PRs found (searched for "star", "github star"). ## What Changed - Added `GitHubStarPrompt` (`ui/src/components/GitHubStarPrompt.tsx`). It reads the health endpoint and shows only on self-hosted instances (never on Cloud), never during onboarding, and only after 5 done tasks in the selected company. It waits for any other open dialog to close. It stores a "seen" flag in `localStorage` when it opens, so a reload does not show it again. - Mounted the prompt in `BoardDialogs`. - Exported the modal-detection helpers (`MODAL_SELECTOR`, `useModalOpen`) from `AnnouncementWell` so both components use the same rule. - Added `PaperclipMark`, the mark alone from the existing lockup geometry. The lockup and the mark now share one path constant. - Added the `issues.starPromptDone` query key. - Added tests for when the prompt opens and when it stays hidden. ## Verification - `pnpm --filter @paperclipai/ui exec vitest run src/components/GitHubStarPrompt.test.tsx src/components/AnnouncementWell.test.tsx` - `pnpm check:token-gates` (all gates clean) - `pnpm typecheck` - Manual: on a self-hosted dev instance, mark 5 tasks in one company as done. The modal opens. "Star on GitHub" opens github.com/paperclipai/paperclip in a new tab. Reload: the modal does not open again. To see it again, delete the `paperclip.github-star-prompt.seen` key from `localStorage`. ## Risks - Low risk. The change is UI only and additive. - The prompt runs one small issues query (limit 5) while it is still eligible. After it is seen, the query is disabled. - If `localStorage` is not available, the prompt treats itself as already seen and does not show. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - Claude Opus 5.5 (Anthropic), model id `claude-opus-5-5`, run through Claude Code with tool use (shell, file edits). Standard context window; extended thinking at low effort. ## 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: squadbot <squadbot@squadbots-Mac-mini.local> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>	2026-11-09 21:11:29 -08:00
DottaandPaperclip	f66d590899	fix(ui): open the new-task form immediately (#17041 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - People use New task to send work to an agent. > - The board currently downloads the task dialog code after the first click. > - This shows a loading window before people can enter their request. > - The form already loads agent and project choices after it opens. > - This pull request loads the task dialog code with the board. > - People can start writing immediately and keep their text as choices arrive. ## Linked Issues or Issue Description Related change: #16849. Commit `fa50cab5685b9cdbb26ad9c610cc5b6c373d3ff4` added the deferred dialog and its loading window on October 19, 2026. What happened? The first New task click shows “Loading new task…” while the browser downloads the dialog code. Expected behavior The form opens on click. Agent and project choices load in place. Text entered during those requests stays in the form. Steps to reproduce 1. Open the board in a fresh browser session. 2. Select New task before its code is cached. 3. Observe the loading window before the form appears. Paperclip version or commit Source baseline: `8b4ab65b1c3d863d282752e83307943720a5c85c`. Deployment mode The browser code applies to local and hosted boards. Verification used a source checkout. ## What Changed - Import NewIssueDialog with the board. Keep the existing mount and draft lifecycle. - Add a first-open test that fails if the form waits for an asynchronous render. - Cover text entry during delayed agent and project requests and defaults that arrive later. - Document the behavior and its verification recipe. ## Verification - Regression proof: the first-open test failed before the import change and passed after it. - All 125 tests in BoardDialogs, DeferredOverlay, NewIssueDialog and Layout passed. - The production UI build and UI TypeScript check passed. The typecheck passed with `NODE_OPTIONS=--max-old-space-size=2400` after the competing test process was stopped. - Token gates, map validation and Git diff checks passed. - The first UI typecheck could not resolve the unbuilt local plugin SDK. The SDK was then built. - Full typecheck and build attempts hit the sandbox's 4 GB memory limit when run with the full test suite. Two later UI typecheck attempts also hit that limit during other validation. The cgroup recorded four OOM kills in total. The full repository test attempt and a broader UI test attempt were stopped. No complete suite result is claimed. Serial repository typecheck reached the missing Rust `cargo` executable. Full CI passed on head `9dde4bc`; local limits remain recorded here. - First CI run at `e5a99b8`: typecheck, build, all unit-test shards and seven browser shards passed. Browser shard 2 failed at `chat-adapters-ui-providers.spec.ts:185`, waiting for Slack setup Success after reload. The saved page showed the working connection and Continue button. The cause is not confirmed; this failure is retained for follow-up. [Failed job](https://github.com/paperclipai/paperclip/actions/runs/39522214527/job/118968542923). - Removed the added import comment after Greptile review. Head `9dde4bc` changes only that comment. The review thread is resolved. Fresh CI passed on head `9dde4bc`. Greptile reviewed that exact head at 5/5 with no open findings. All eight browser shards passed, including the earlier Slack failure. The earlier failure remains unexplained; the only intervening code change removed a source comment. A passing retry establishes recovery, not its cause. - Component tests use mocked directory requests. No deployed latency or browser persistence claim is made. Latest CI: [run 39523376437](https://github.com/paperclipai/paperclip/actions/runs/39523376437). Reviewed head: `9dde4bc0caa3556e315a2fc197268b7c9879efa4`. ## Risks - Task dialog code is part of board startup again. This adds its dependencies to the initial code graph. No startup latency benchmark is claimed. - Other creation dialogs retain their existing lazy imports and loading behavior. ## Model Used OpenAI Codex, GPT-6, with reasoning, repository tools and code execution. The runtime does not expose a more precise model ID 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>	2026-10-24 08:15:35 -07:00
DottaandPaperclip	fa50cab568	perf(ui): speed task loading without shifting the conversation (#16849 ) ## 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>	2026-10-19 10:16:23 -05:00

Author

SHA1

Message

Date

a5e01634f6

feat(ui): ask self-hosted users to star Paperclip on GitHub after 5 done tasks (#20453 )

## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work
> - Many teams run Paperclip self-hosted, so the project grows when
those users tell others about it
> - A GitHub star is the cheapest way for a user to do that, but the app
never asks
> - Asking too early is noise. A user who has finished a few tasks knows
whether Paperclip helps them
> - This pull request adds a one-time, dismissable modal that asks
self-hosted users for a star after their company has 5 done tasks
> - The benefit is more visibility for the project, and no repeated
prompt for the user

## Linked Issues or Issue Description

**Subsystem affected**

Board UI (dialogs shown in the main app shell).

**Problem or motivation**

Self-hosted users have no prompt to star the repository. Users who like
Paperclip often do not think of it. A prompt at the right moment helps
other teams find the project.

**Proposed solution**

Show a small modal once the selected company has 5 tasks with status
"done". The modal shows the Paperclip mark, the headline "You completed
5 tasks!", a short body, a "Star on GitHub" button and a "Not now"
button. It shows only once per browser. Closing it in any way counts as
seen.

**Alternatives considered**

A permanent banner or sidebar link. Both stay on screen after the user
decides, so they cost attention every day. A one-time modal costs
attention once.

**Roadmap alignment**

This is a small UI addition. It does not overlap with planned core work
in ROADMAP.md.

No related public issues or PRs found (searched for "star", "github
star").

## What Changed

- Added `GitHubStarPrompt` (`ui/src/components/GitHubStarPrompt.tsx`).
It reads the health endpoint and shows only on self-hosted instances
(never on Cloud), never during onboarding, and only after 5 done tasks
in the selected company. It waits for any other open dialog to close. It
stores a "seen" flag in `localStorage` when it opens, so a reload does
not show it again.
- Mounted the prompt in `BoardDialogs`.
- Exported the modal-detection helpers (`MODAL_SELECTOR`,
`useModalOpen`) from `AnnouncementWell` so both components use the same
rule.
- Added `PaperclipMark`, the mark alone from the existing lockup
geometry. The lockup and the mark now share one path constant.
- Added the `issues.starPromptDone` query key.
- Added tests for when the prompt opens and when it stays hidden.

## Verification

- `pnpm --filter @paperclipai/ui exec vitest run
src/components/GitHubStarPrompt.test.tsx
src/components/AnnouncementWell.test.tsx`
- `pnpm check:token-gates` (all gates clean)
- `pnpm typecheck`
- Manual: on a self-hosted dev instance, mark 5 tasks in one company as
done. The modal opens. "Star on GitHub" opens
github.com/paperclipai/paperclip in a new tab. Reload: the modal does
not open again. To see it again, delete the
`paperclip.github-star-prompt.seen` key from `localStorage`.

## Risks

- Low risk. The change is UI only and additive.
- The prompt runs one small issues query (limit 5) while it is still
eligible. After it is seen, the query is disabled.
- If `localStorage` is not available, the prompt treats itself as
already seen and does not show.

> For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and
discuss it in `#dev` before opening the PR. Feature PRs that overlap
with planned core work may need to be redirected — check the roadmap
first. See `CONTRIBUTING.md`.

## Model Used

- Claude Opus 5.5 (Anthropic), model id `claude-opus-5-5`, run through
Claude Code with tool use (shell, file edits). Standard context window;
extended thinking at low effort.

## 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: squadbot <squadbot@squadbots-Mac-mini.local>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

2026-11-09 21:11:29 -08:00

DottaandPaperclip

f66d590899

fix(ui): open the new-task form immediately (#17041 )

## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - People use New task to send work to an agent.
> - The board currently downloads the task dialog code after the first
click.
> - This shows a loading window before people can enter their request.
> - The form already loads agent and project choices after it opens.
> - This pull request loads the task dialog code with the board.
> - People can start writing immediately and keep their text as choices
arrive.

## Linked Issues or Issue Description

Related change: #16849. Commit
`fa50cab5685b9cdbb26ad9c610cc5b6c373d3ff4` added the deferred dialog and
its loading window on October 19, 2026.

**What happened?**

The first New task click shows “Loading new task…” while the browser
downloads the dialog code.

**Expected behavior**

The form opens on click. Agent and project choices load in place. Text
entered during those requests stays in the form.

**Steps to reproduce**

1. Open the board in a fresh browser session.
2. Select New task before its code is cached.
3. Observe the loading window before the form appears.

**Paperclip version or commit**

Source baseline: `8b4ab65b1c3d863d282752e83307943720a5c85c`.

**Deployment mode**

The browser code applies to local and hosted boards. Verification used a
source checkout.

## What Changed

- Import NewIssueDialog with the board. Keep the existing mount and
draft lifecycle.
- Add a first-open test that fails if the form waits for an asynchronous
render.
- Cover text entry during delayed agent and project requests and
defaults that arrive later.
- Document the behavior and its verification recipe.

## Verification

- Regression proof: the first-open test failed before the import change
and passed after it.
- All 125 tests in BoardDialogs, DeferredOverlay, NewIssueDialog and
Layout passed.
- The production UI build and UI TypeScript check passed. The typecheck
passed with `NODE_OPTIONS=--max-old-space-size=2400` after the competing
test process was stopped.
- Token gates, map validation and Git diff checks passed.
- The first UI typecheck could not resolve the unbuilt local plugin SDK.
The SDK was then built.
- Full typecheck and build attempts hit the sandbox's 4 GB memory limit
when run with the full test suite. Two later UI typecheck attempts also
hit that limit during other validation. The cgroup recorded four OOM
kills in total. The full repository test attempt and a broader UI test
attempt were stopped. No complete suite result is claimed. Serial
repository typecheck reached the missing Rust `cargo` executable. Full
CI passed on head `9dde4bc`; local limits remain recorded here.
- First CI run at `e5a99b8`: typecheck, build, all unit-test shards and
seven browser shards passed. Browser shard 2 failed at
`chat-adapters-ui-providers.spec.ts:185`, waiting for Slack setup
Success after reload. The saved page showed the working connection and
Continue button. The cause is not confirmed; this failure is retained
for follow-up. [Failed
job](https://github.com/paperclipai/paperclip/actions/runs/39522214527/job/118968542923).
- Removed the added import comment after Greptile review. Head `9dde4bc`
changes only that comment. The review thread is resolved. Fresh CI
passed on head `9dde4bc`. Greptile reviewed that exact head at 5/5 with
no open findings. All eight browser shards passed, including the earlier
Slack failure. The earlier failure remains unexplained; the only
intervening code change removed a source comment. A passing retry
establishes recovery, not its cause.
- Component tests use mocked directory requests. No deployed latency or
browser persistence claim is made.

Latest CI: [run
39523376437](https://github.com/paperclipai/paperclip/actions/runs/39523376437).
Reviewed head: `9dde4bc0caa3556e315a2fc197268b7c9879efa4`.

## Risks

- Task dialog code is part of board startup again. This adds its
dependencies to the initial code graph. No startup latency benchmark is
claimed.
- Other creation dialogs retain their existing lazy imports and loading
behavior.

## Model Used

OpenAI Codex, GPT-6, with reasoning, repository tools and code
execution. The runtime does not expose a more precise model ID 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>

2026-10-24 08:15:35 -07:00

DottaandPaperclip

fa50cab568

perf(ui): speed task loading without shifting the conversation (#16849 )

## 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>

2026-10-19 10:16:23 -05:00