Read the open page in slices, so an edit re-reads a slice instead of the whole page

Where the bytes go

Source: cost harness E:\w\convex-io\harness, session.mjs (one query) and session-slices.mjs --slices 4|8|16, against the prototype queries on branch t3/page-slices (main 5c7b867 + page:getFrame, page:getElementSlice, index elements.by_pageId_and_publicId); local backend loaded with an export of dev; one text-element drag. Byte counts match Convex cloud exactly.

The page re-read is expensive because Convex re-runs a live query in full whenever any row it read is written, and the editor's page query reads every row on the page. Its cost tracks the size of the page, not the size of the change. A slice re-runs only when a row in its ID range changes, so the re-read shrinks with the slice. What doesn't shrink is a fixed cost of about 2 KB per run (the strategy, user and page rows that every read checks for access), which is why 16 slices save less over 8 than 8 do over 4.

Already shipped today

Source: #346 counted from websocket frames on beta.icarusstrats.com with a test account (E:\w\trash-gt-live), before and after deploy; #347 and #348 from the cost harness, main vs branch.

Proposal 1: the open page in slices

Recommended decision: build sliced page reads now (server queries first, then the app), and keep the whole-page query for every shipped build and as the app's fallback.

• Server, additive only. A new index on elements by page and public id, and two new queries: page:getFrame (the page, its settings, its lineups and their images) and page:getElementSlice(fromId, toId) (the page's elements in that id range, with their images and picture aliases, serialized exactly as page:getSnapshot does today). page:getSnapshot stays as it is for every shipped desktop build and the live web build.
• App. When it opens a page, the editor picks a slice count from the page's size (about one slice per 10 elements, between 1 and 16) and subscribes to the frame and each slice. It shows the page only when every part has answered, and from then on rebuilds the whole page from the latest answer of each part. Everything downstream (conflict handling, the "live" rule for queued work, the offline copy, media) keeps receiving a complete page, as it does today.
• Why slices stay correct. Each slice is an ordinary complete query over a fixed id range. A row that moves to another page, gets deleted, restored or purged leaves or enters its range, and Convex re-runs that slice with the row gone or present. No change numbers, no history, nothing to keep in step across write paths.
• Element ids. Element ids are random UUIDs (3,067 of 3,119 dev rows), so fixed hexadecimal boundaries split pages evenly. Copies (<root>~cp1~<uuid>) sort with their original, which only affects balance, never correctness.

Source: harness results results-base2.json, results-slices4.json, results-slices8.json, results-slices16.json. "Page open, live queries" covers the editor's live queries plus the library's, as the harness holds them. A batch of 10 moves touched 2 slices at 8 and 4 slices at 16.

Function calls per edit stay at one re-run, except when one batch touches rows in several slices. Opening a page costs a few more calls and 10 to 32 KB more, once. For a page someone opens and then edits, the slices pay for themselves after the first or second edit.

Proposal 2: skip unchanged strategies in the offline pass

The desktop offline copy re-reads every strategy in full once a day per device, changed or not: 418 KB for one 20-page strategy. For a light user who opens the app and edits little, this is most of their day. The fix is to know, cheaply, which strategies changed since the copy was taken.

• One small row per strategy holding a content version, bumped once by any mutation that writes the strategy's content, and listed for the whole library by one query. It is its own table, so bumping it never re-runs the library lists.
• The pass re-reads a strategy in full only when its version moved. It records the version for a strategy only after every page and image of that strategy is written to disk, never from one page the editor happened to read.
• Missing a bump would leave a copy stale, so: every write goes through one wrapped database handle with a test that rejects writes around it, a failed bump fails the whole transaction (outside applyBatch's per-op error handling), and every copy is still re-read in full at least once a week. Opening a strategy online always reads it fresh, as it does today.

This one needs its own design pass (what counts as a content write, how rollback or a data import resets versions) before it's built. It saves about 1.2 MB on an unchanged 4-strategy library per device per day; libraries with more strategies save more.

Set aside: per-row change numbers

Version 1 of this proposal stamped every row with a per-strategy change number and sent clients only the rows changed since the number they held. It would have cut an edit to about 4 KB. Astra's review found six independent ways it could leave a user looking at stale work, each one fixable but together a protocol with many places to be wrong:

Source: Astra design review round 1 (gpt-6-astra, high), 2026-10-19, against main and the v1 doc. Its recommendation was the sliced design above, then version-based skipping for the offline copy.

Slices give up about 6 KB per edit against that design and keep every answer complete. If slices plus the offline skip aren't enough once real users arrive, change numbers can be revisited with those six holes as the spec.

One heavy user-day, before and after

Computed from the harness per-action numbers above; the offline skip and the open cost with slices are estimates. A "heavy user-day" is a scripted stand-in (200 single drags on an 87-element page); we have no production numbers for real sessions.

How it ships

Proof for step 2: the harness on the branch, the two-account editing run on a real build (a teammate's move, delete and restore showing up live), and a page with images uploading while open.

Not covered

• Production library sizes and real session lengths: all numbers come from our dev test data and a scripted day. The ratios are what these changes move.
• The hourly token refresh: the app re-runs its whole Convex sign-in setup on each Supabase auth event, which may re-run every live query once an hour per client. Astra is measuring it now.
• The library list reads every page of every strategy to label it Attack or Defend, about 1 KB per strategy per run. A separate small PR.
• The plan. Even after these cuts, a hard cap that stops everyone's saves at once is the real risk. Starter (pay as you go, no hard stop) would cost a few dollars a month at our size.

Appendix