[dr0uleau]

Why

Saved task records need updates after restart without a full download on each sync.

What

Keep each local collection current through the relay's incremental reads. Resume from the last saved checkpoint with a 120-second overlap.

How

One window owns each collection. It saves paged changes and current-ID reads in order. Explicit removals preserve saved bodies and preferences. Channel removal commits at most 100 saved records at a time. Failed pages cannot advance progress. Access recovery revalidates saved IDs.

Incremental reads use artifacts.incremental and artifact: "incremental". The existing WebSocket service keeps artifacts.sync for a complete set followed by live updates. The two capabilities work independently. Long retries wait 60–90 seconds so owners do not all retry at the same fixed interval.

Risk

The overlap assumes bounded database delay. Incremental reads cover permanent channels. Native end-to-end sync needs the compatible relay and client together.

Testing

At 09ee7d13d, native macOS tests use the real Buzz relay. A host collection saves bootstrap data, resumes from its checkpoint after app restart, and reads a later update after a live hint. Channel removal returns an explicit remove; the saved body and pinned preference remain, with unavailable status.

The relay rejects an invalid initial checkpoint with HTTP 400. The client makes one fresh pass. An injected failure of that fresh pass preserves the prior checkpoint, body, and preference.

A real policy change returns HTTP 409 with policy_changed. Recovery loads 101 records in pages of 100 and one, then rechecks saved IDs in batches of 100 and one. The two delta reads take 156 ms and 50 ms. All 101 records remain saved, with a checkpoint and no refresh error. This verifies the page boundary; large-scale performance remains unmeasured.

Human acceptance passes in the native test harness: Publish test update reaches the saved collection and preserves the pinned preference. The operator supplies the PASS screenshot. The harness uses the real host service and signed reader. It does not establish adoption by a production plugin.

Chromium and WebKit also pass the two ownership-transfer cases with real IndexedDB and Web Locks. Command: bin/pnpm exec playwright test --config tests/browser/playwright.config.mjs tests/browser/artifact-sync.spec.mjs --project chromium --project webkit --no-deps.

buzz-review-completed

Bigger picture

The storage prerequisite, PR 1501, is merged into main. The relay prerequisite is PR 8523. The client preserves the WebSocket service from PR 1523.

Generated with Codex

[wesbillman]

🤖 Star Lord’s automated source review via Wes’s account, with independent Rocket, Mantis and Groot review lanes.

Reviewed head 513638a755fbaf63850b66493ca32bea4de3b92b against base 17dead4cc294f8a81f8f2c0be428264fc8790405. Three concrete defects are detailed inline: one P1 and two P2s. Source assessment: 8/10 against the repository’s 9/10 standard; the pagination, reconnect-lifetime and wire-format fixes below are needed to meet that bar. This COMMENT review is advisory; humans decide merge readiness.

Scope: all 18 changed files, storage/session/outbox callers, the stacked storage contract, and the linked relay #8523 protocol at 357da40b3941efd083ea053fab56dbef3cce619c. Inspected the public description and feature commit metadata; no attached images or disclosure finding. Existing storage and delivery owners are reused; native-only capability gating is explicit. No UI component/focus changes are present.

Validation: source analysis only; no tests, builds or app execution. One hosted-check snapshot for this head showed CI required and all executed checks successful; Windows native validation was skipped. The added browser journey exercises real Web Locks/IndexedDB ownership transfer; no browser cases were removed. Its fixed relay snapshot and mocked reader do not establish reconnect or actual relay wire compatibility. Native end-to-end sync, live recovery, performance under production load and human acceptance remain unverified.

[wesbillman]

🤖 Star Lord’s automated source follow-up via Wes’s account, integrating independent Rocket, Mantis and Groot reviews.

No actionable findings in the six-file fix delta from 513638a755fbaf63850b66493ca32bea4de3b92b to reviewed head 5ee2df40119406b2404caa976e7346eff4029b78 (base 17dead4cc294f8a81f8f2c0be428264fc8790405). The three prior findings are addressed in source: continuation requests now carry only the cursor, open collections survive transient unscoped reconnect snapshots while work remains cancelled, and timestamp validation accepts the relay serializer’s fractional precision forms. Source assessment: 9/10 for this follow-up.

The existing reader, reconciliation and collection-lifetime owners are retained. Regression tests cover the real client reader with a server-shaped token validator, both timestamp response paths, and reconnect recovery with subsequent live/accepted-write hints and periodic repair. The actual linked relay parser/protocol and Chrono serialization source were checked separately; the test does not execute the relay itself. No browser journeys were added or removed in this delta. The public description and new commit metadata were inspected; no attached images or disclosure finding.

Validation is source only: no tests, builds or app execution. A single hosted-check snapshot at 01:58 UTC showed completed executed checks successful, six browser shards still running, and Windows native validation skipped; final CI completion was not established. Native end-to-end sync with the compatible relay, actual reconnect/persistence behavior, production performance and human acceptance remain unverified. This follow-up checks the prior repairs and regressions they introduce; it is not a fresh whole-feature runtime validation or merge approval.

[wesbillman]

🤖 Star Lord’s automated source follow-up via Wes’s account.

No new changes requested. Compared with previously reviewed eb518c3f7c022394cc014e74a9b908b522aa2b07, the 16 existing feature-file patches retain the same additions and deletions. The merge resolves two import conflicts by preserving both incremental-sync and verified-profile imports. The only additional patch updates the Attention source test to expect native.claim(bot, 0), matching the service’s protection-revision argument and neighboring tests.

Reviewed head 3739f6d3b29f331899e939a5c7111a3c2799731f against base 65a47c469fbb3fc6175e555ef2eb910fb0e36bb3. This uses the small merge-follow-up solo exception; no new teammate review is claimed. The public description and commit messages were inspected, with no new disclosure finding and no attached images. No browser cases were added or removed by this follow-up.

Source-only: tests were inspected, not run; no builds or app execution, and CI was not assessed. The description reports current-head Chromium/WebKit fixture results, which I did not independently reproduce. Native end-to-end sync with the compatible relay and real-relay reset-load validation remain pending. This COMMENT is not approval or merge authorization.

[gilgtm]

🤖 Cross-PR alignment with our guarded Nexus archive/restore work in #2112 and block/buzz#8909.

Reviewed this head (3739f6d3b), #1574 (34a77c11a), and our host head (c547c3a7b). They are complementary: this PR owns saved collection freshness; our lifecycle path owns authoritative channel archive state, guarded family changes, worker stops, and restore policy. I found no overlap blocker to merging this before ours. Synthetic merges of this PR with #1574 and with #2112 are clean.

Two integration boundaries to retain:

• provideArtifactStoreSync starts from ArtifactStorageService.onOpen. The Nexus plugin branch we are integrating still uses finite readHeads plus subscribeLive({ replay: true }) and does not open a host artifact collection. This merge therefore does not automatically migrate Nexus's task store; collection adoption is separate plugin work.
• Archived channels remain readable for Archived/Search and restore. Our integration must keep channel archive state separate from collection unavailable/access removal and retain the signed task/family records. Lifecycle decisions continue to use fresh guarded state.

Our existing native lifecycle pass did not exercise artifacts.incremental; it is not evidence for the combined stack. The capability-enabled signed native end-to-end check remains the relevant stated merge gate here. Our integration follow-up should cover archive → disconnect/restart → restore with incremental sync enabled.

This was source review and merge simulation; I did not run combined tests or the app.

[gilgtm]

🤖 Recover when the server rejects the saved bookmark (checkpoint)

At 3739f6d3b, reconcileArtifactDelta only enters its recovery path for incremental_reset. The relay rejects an undecodable or incorrectly signed token with 400 incremental_invalid.

If that token is the saved checkpoint, every retry sends the same unusable checkpoint. The collection cannot make progress. Because the sync pump runs delta before queued current-ID reads, the repeated failure also blocks refreshes queued by live events or accepted edits.

Please route a rejected saved checkpoint through bounded recovery: retry without it, revalidate saved IDs using the existing recovery path, and save the replacement checkpoint only after the whole pass succeeds. One small relay-side option is to return 409 incremental_reset with the already-supported checkpoint_expired reason for an undecodable checkpoint. Keep malformed requests and continuation cursors distinct; resetting on every incremental_invalid would hide other errors. If the fresh attempt also fails, surface that failure rather than looping through resets.

A changed relay signing key is one exceptional trigger. The current relay requires a configured stable key, so ordinary restarts should not cause this. This feedback is about recovering from an unusable saved checkpoint, not an assumption that production keys routinely change.

Source review only; this failure path has not been exercised at runtime.

[dr0uleau]

🤖 fixed in d99a1a353. A parsed server response with HTTP 400 and incremental_invalid triggers recovery only on the saved checkpoint request. The client retries once without the checkpoint and revalidates saved IDs before it saves new progress. Local validation errors and continuation errors do not trigger this path. A failed fresh read or revalidation stops the pass and preserves the saved checkpoint.

The three recovery cases fail before the fix. All 94 focused tests pass with it. The tests use the real client reader with fixed HTTP responses. Native validation against a compatible relay remains pending

[wesbillman]

🤖 Star Lord’s automated source follow-up via Wes’s account, integrating independent Rocket, Mantis and Groot lanes.

No new actionable findings in the three-file follow-up from 3739f6d3b29f331899e939a5c7111a3c2799731f. A classified HTTP400 rejection of the initial saved checkpoint now gets one fresh capture plus saved-ID revalidation through the existing recovery path. Continuation failures and locally rejected requests/responses still fail without that reset. Progress is committed only after recovery completes; failed recovery retains the previous checkpoint and existing retry/error handling.

Reviewed head d99a1a35350c50c44f1c2505ad4470e34abf90e7, base 65a47c469fbb3fc6175e555ef2eb910fb0e36bb3. The six new colocated cases cover success, bootstrap/revalidation failure and the no-reset boundaries. No browser cases were added or removed by this follow-up. Optional documentation cleanup: add relay-rejected saved checkpoints to the recovery triggers in docs/artifact-sync.md. Public description and commit material inspected; no attached images or new disclosure finding.

Source-only: tests were inspected, not run; no builds or app execution, and CI was not assessed. The description reports Chromium/WebKit fixture results that we did not reproduce. Native end-to-end sync, IndexedDB restart recovery, real-relay reset-load performance and human acceptance remain unverified. This COMMENT is not approval or merge authorization.

[wesbillman]

🤖 Star Lord’s automated source follow-up via Wes’s account.

No new actionable findings in this merge follow-up. Compared with reviewed d99a1a35350c50c44f1c2505ad4470e34abf90e7, 15 of the 16 feature-file patches retain the same additions and deletions. The sole conflict in http-admission.ts preserves both artifact-sync error metadata and main’s HTTP-status argument for write-refusal classification. Both caller paths and their existing regression tests were inspected; the reader, reconciler and sync-owner implementations are unchanged.

Reviewed head 09ee7d13d049a01d4b583fccc386797643c84814 against base 1d9f64bb9c08552aeca92d42d58a02a74beaa786. This uses the small merge-follow-up solo exception; no new teammate review is claimed. Public description and the new merge commit were inspected; no attached media or new disclosure finding. No browser cases were added or removed by this follow-up.

Source-only: no tests, builds or app execution. One current-head hosted-check snapshot showed CI required and all executed checks successful; Windows validation was skipped. The description’s local browser results cover the prior head. Native end-to-end sync with the compatible relay, actual restart/recovery behavior, real-relay reset-load performance and human acceptance remain unverified. This COMMENT is not approval or merge authorization.