PaperClipAI

Jannik/PaperClipAI

0 Fork 0

mirror of https://github.com/paperclipai/paperclip.git synced 2026-11-03 01:27:09 +01:00

Commit Graph

Author	SHA1	Message	Date
DottaandPaperclip	4d92589799	perf(ui): defer hidden task rendering until history is ready (#16878 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - People open a task to read saved work and reply. > - The conversation waits for its initial data so messages do not move after reveal. > - The hidden conversation and editor still render while those reads are pending. > - Profiling showed a useful cold-load gain when that hidden rendering was delayed. > - Prepare ordinary task content after its initial data is ready. Keep the existing preparation path for comment links. > - Keep the skeleton, measured reveal, timeout, and mounted conversation during refresh. ## Linked Issues or Issue Description Follow-up to #16862 and #16849. Related task-layout work: #14758. Searches found no overlapping open rendering change. What existing behavior does this improve? Opening a task mounts hidden message rows and the rich editor while supporting reads are still pending. These trees can render again as data arrives before the user can see or use them. Subsystem affected UI task conversation startup and its browser acceptance suite. Proposed behavior Keep the existing skeleton and outer layout containers. Prepare the hidden conversation and composer when initial history is ready, then use the existing measured reveal. Keep content mounted after reveal. Hash navigation retains eager preparation so older comment targets can be positioned before reveal. The existing 15-second timeout still reveals available history and the composer. ## What Changed - Gate concealed history and composer children with the existing history readiness, revealed-task latch, timeout, and scroll-navigation hash. - Keep data queries, shell geometry, scroll ownership, and the reveal frame unchanged. - Update unit coverage for deferred content, comment-link preparation, task changes, history timeout, and mounted editor identity during refresh. - Add a real browser journey that holds a background task read, retains the same editor and draft, reloads the saved draft, sends one reply, and checks the persisted comment independently. - Document the loading and draft acceptance paths. ## Verification - Repository-wide `pnpm -r typecheck` and `pnpm build` passed locally. Token gates and all 231 task-thread unit cases passed. - Seven regression cases failed against the old rendering behavior before the source change. - All 14 loading and layout browser cases passed again against the final production UI and API build at `15c360aa63e01ad9318aaf7865c07d1ee0d36968`. Coverage includes delayed initial data, reading anchors, media growth, composer sizing, older history, cold comment links, desktop/mobile same-task links and Back, rapid switching, reduced motion, failed reads and retry, stalled history, plan reuse, and cached-task profiling. - The new draft journey retained the same editor during a blocked background task refresh, restored the draft after reload, and persisted exactly one reply. - Final performance comparison used current master `249ab47d41834f174ddd5e9523dc07fa8ebd8e4c` and implementation `15c360aa63e01ad9318aaf7865c07d1ee0d36968` against the same local 160-message Markdown conversation and API process. Conditions: 50 ms network latency, 9 Mbps down/1.5 Mbps up, 4x CPU slowdown, fresh browsers, five alternating pairs per scenario, no CPU profiler, and no concurrent local build/test work. Warm task navigation improved in all five pairs: median paired saving 405 ms; variant medians 1,787 → 1,456 ms. Cold results were mixed: paired saving −89 ms (slower), despite variant medians 3,188 → 3,021 ms. There is no consistent cold-load gain established by this comparison. - Earlier prototype comparisons showed paired cold savings of 259–283 ms. Those gains did not consistently reproduce in the final comparison. These are bounded local measurements and do not establish deployed staging latency. - The first prototype delayed comment-link preparation too and failed the older-comment anchor check by 240.5 px. The narrowed implementation keeps hash navigation on the existing eager path. That case and the full suite now pass. The original failure trace is retained locally. - A visual browser walkthrough read the saved conversation and plan, restored a draft after reload, sent it once, reloaded again, and independently checked that exactly one reply was saved. - Greptile reviewed this exact commit at 5/5, with no actionable findings or inline comments. - The duplicate local `pnpm test:run` attempt was interrupted while the same suites were completing in sharded CI so local performance could be measured on an idle host. It is not counted as a local full-suite pass. - All current-head [CI jobs passed](https://github.com/paperclipai/paperclip/actions/runs/39296740548), including the server, workspace, Runner, serialized, browser, typecheck, build, canary, and final verification gates. The first run failed one native-process supervision test (`preserves a real listening process and its marker when a health RPC times out`). Its unchanged shard and dependent gate passed on retry. The specific test also passed locally. No source change was made for that transient failure. ## Risks Delaying preparation can change initial scroll geometry. Hash navigation keeps the existing preparation path because it needs the target present before positioning. The revealed-task latch keeps refreshes from removing history or the editor. The existing timeout still makes saved content and the composer accessible when reads stall. No API, database, permission, or provider changes. ## Model Used OpenAI Codex, GPT-6, with reasoning, repository tools, code execution, and browser verification. A more precise runtime model identifier and context-window size are unavailable. ## 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 14:01:37 -05: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
DottaandPaperclip	cd4c4ed205	fix(ui): stabilize task loading and live feeds (#13095 ) Coordinate initial conversation reveal, preserve message identity and reading anchors during live updates, and bound transcript reads with recoverable retries. Cover desktop/mobile navigation and rich task loading with actual-route browser tests. Verified all Linux CI gates, 5,575 local UI tests, eight layout browser scenarios, and recorded native Codex walkthroughs. Greptile: 5/5; all review findings resolved. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-09-09 10:00:37 -05:00

Author

SHA1

Message

Date

DottaandPaperclip

4d92589799

perf(ui): defer hidden task rendering until history is ready (#16878 )

## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - People open a task to read saved work and reply.
> - The conversation waits for its initial data so messages do not move
after reveal.
> - The hidden conversation and editor still render while those reads
are pending.
> - Profiling showed a useful cold-load gain when that hidden rendering
was delayed.
> - Prepare ordinary task content after its initial data is ready. Keep
the existing preparation path for comment links.
> - Keep the skeleton, measured reveal, timeout, and mounted
conversation during refresh.

## Linked Issues or Issue Description

Follow-up to #16862 and #16849. Related task-layout work: #14758.
Searches found no overlapping open rendering change.

**What existing behavior does this improve?**

Opening a task mounts hidden message rows and the rich editor while
supporting reads are still pending. These trees can render again as data
arrives before the user can see or use them.

**Subsystem affected**

UI task conversation startup and its browser acceptance suite.

**Proposed behavior**

Keep the existing skeleton and outer layout containers. Prepare the
hidden conversation and composer when initial history is ready, then use
the existing measured reveal. Keep content mounted after reveal. Hash
navigation retains eager preparation so older comment targets can be
positioned before reveal. The existing 15-second timeout still reveals
available history and the composer.

## What Changed

- Gate concealed history and composer children with the existing history
readiness, revealed-task latch, timeout, and scroll-navigation hash.
- Keep data queries, shell geometry, scroll ownership, and the reveal
frame unchanged.
- Update unit coverage for deferred content, comment-link preparation,
task changes, history timeout, and mounted editor identity during
refresh.
- Add a real browser journey that holds a background task read, retains
the same editor and draft, reloads the saved draft, sends one reply, and
checks the persisted comment independently.
- Document the loading and draft acceptance paths.

## Verification

- Repository-wide `pnpm -r typecheck` and `pnpm build` passed locally.
Token gates and all 231 task-thread unit cases passed.
- Seven regression cases failed against the old rendering behavior
before the source change.
- All 14 loading and layout browser cases passed again against the final
production UI and API build at
`15c360aa63e01ad9318aaf7865c07d1ee0d36968`. Coverage includes delayed
initial data, reading anchors, media growth, composer sizing, older
history, cold comment links, desktop/mobile same-task links and Back,
rapid switching, reduced motion, failed reads and retry, stalled
history, plan reuse, and cached-task profiling.
- The new draft journey retained the same editor during a blocked
background task refresh, restored the draft after reload, and persisted
exactly one reply.
- Final performance comparison used current master
`249ab47d41834f174ddd5e9523dc07fa8ebd8e4c` and implementation
`15c360aa63e01ad9318aaf7865c07d1ee0d36968` against the same local
160-message Markdown conversation and API process. Conditions: 50 ms
network latency, 9 Mbps down/1.5 Mbps up, 4x CPU slowdown, fresh
browsers, five alternating pairs per scenario, no CPU profiler, and no
concurrent local build/test work. Warm task navigation improved in all
five pairs: median paired saving **405 ms**; variant medians **1,787 →
1,456 ms**. Cold results were mixed: paired saving **−89 ms** (slower),
despite variant medians **3,188 → 3,021 ms**. There is no consistent
cold-load gain established by this comparison.
- Earlier prototype comparisons showed paired cold savings of 259–283
ms. Those gains did not consistently reproduce in the final comparison.
These are bounded local measurements and do not establish deployed
staging latency.
- The first prototype delayed comment-link preparation too and failed
the older-comment anchor check by 240.5 px. The narrowed implementation
keeps hash navigation on the existing eager path. That case and the full
suite now pass. The original failure trace is retained locally.
- A visual browser walkthrough read the saved conversation and plan,
restored a draft after reload, sent it once, reloaded again, and
independently checked that exactly one reply was saved.
- Greptile reviewed this exact commit at 5/5, with no actionable
findings or inline comments.
- The duplicate local `pnpm test:run` attempt was interrupted while the
same suites were completing in sharded CI so local performance could be
measured on an idle host. It is not counted as a local full-suite pass.
- All current-head [CI jobs
passed](https://github.com/paperclipai/paperclip/actions/runs/39296740548),
including the server, workspace, Runner, serialized, browser, typecheck,
build, canary, and final verification gates. The first run failed one
native-process supervision test (`preserves a real listening process and
its marker when a health RPC times out`). Its unchanged shard and
dependent gate passed on retry. The specific test also passed locally.
No source change was made for that transient failure.

## Risks

Delaying preparation can change initial scroll geometry. Hash navigation
keeps the existing preparation path because it needs the target present
before positioning. The revealed-task latch keeps refreshes from
removing history or the editor. The existing timeout still makes saved
content and the composer accessible when reads stall. No API, database,
permission, or provider changes.

## Model Used

OpenAI Codex, GPT-6, with reasoning, repository tools, code execution,
and browser verification. A more precise runtime model identifier and
context-window size are unavailable.

## 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 14:01:37 -05: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

DottaandPaperclip

cd4c4ed205

fix(ui): stabilize task loading and live feeds (#13095 )

Coordinate initial conversation reveal, preserve message identity and reading anchors during live updates, and bound transcript reads with recoverable retries. Cover desktop/mobile navigation and rich task loading with actual-route browser tests.

Verified all Linux CI gates, 5,575 local UI tests, eight layout browser scenarios, and recorded native Codex walkthroughs. Greptile: 5/5; all review findings resolved.

Co-Authored-By: Paperclip <noreply@paperclip.ing>

2026-09-09 10:00:37 -05:00