* feat(sync-guard): extend SyncState with BLOCKED + add shrink event variants
* feat(sync-guard): add detectSuspiciousShrink pure function with 12 unit tests
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* polish(sync-guard): drop unnecessary cast, sharpen test naming, pin priority invariant
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix(test): include domain/*.test.ts in npm test glob
* feat(sync-guard): gate syncToProvider with shrink detection + force-push override
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix(sync-guard): reset overrideShrinkOnce before early return for invariant strictness
* fix(sync-guard): extend shrink guard to syncAllProviders (the actual sync entry point)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* feat(sync-guard): apply empty-vault guard uniformly to auto and manual sync
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* feat(sync-guard): preserve merge base on same-account re-auth
Adds providerAccountId persistence; completePKCEAuth and completeGitHubAuth
now only clear syncBase/anchor when the authenticated account id differs from
the previously stored one, preventing zombie-entry resurrection on token
refresh. disconnectProvider clears the stored id so a reconnect starts fresh.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* feat(sync-guard): add i18n strings for sync-blocked banner + force-push modal
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* feat(sync-guard): add SyncBlockedBanner showing shrink findings with restore/force-push actions
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix(sync-guard): stable subscribeToEvents reference + type-safe finding narrowing
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* feat(sync-guard): force-push confirmation modal + scroll restore button into view
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* ux(local-backups): show version as title, demote reason+timestamp to meta line
* feat(local-backups): record + display sync data version (v5/v6...) on each backup
Each backup now captures the live CloudSyncManager.localVersion at creation
time. UI shows it as title (v5, v6, ...) with timestamp + reason demoted to
the meta line. Backups created before this field existed (or before any
successful cloud sync) fall back to timestamp as title.
Replaces the earlier app-version-transition title which conflated app
version with sync data version.
* fix(sync-guard): consume override flag at sync entry + restore provider status on block
- Snapshot+clear overrideShrinkOnce at top of syncToProvider and
syncAllProviders so an early-return cannot leak the flag to a later
unrelated sync (Codex P1).
- Restore provider status to 'connected' when shrink-block returns from
syncToProvider; previously left provider stuck on 'syncing' in the
UI (Codex P2).
- Process pre-existing check errors before returning from the
shouldBlockAll branch in syncAllProviders so a check-failed provider
isn't dropped from results (Codex P2).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix(sync-guard): refactor force-push to parameter passing + add credential-availability guard
The previous design used a one-shot boolean flag on CloudSyncManager set
by forcePushOverrideShrink(). Even with snapshot+clear at sync entry
points, the renderer wrapper's await ensureUnlocked() could throw before
the flag was consumed, leaving it armed for the next unrelated sync.
Fix: pass overrideShrink as a call-time parameter through the chain.
Eliminates the persistent flag and its leak surface.
Also: force-push now runs the same ensureSyncablePayload(...) guard the
other manual sync entry points use, so a vault with encrypted-credential
placeholders won't be uploaded via the force path either.
Addresses the latest two Codex P1/P2 findings on #742.
* fix(sync-guard): backfill account id from in-memory state for upgrade-path re-auth
Users upgrading to this PR have no netcatty.sync.accountId.* persisted yet.
On their first re-auth the guard saw previousId=null and cleared the
merge base anyway, defeating the point of the same-account preservation.
Snapshot the in-memory account id BEFORE overwriting providers[provider]
and use it as a fallback when the persisted id is missing. New users
(no prior connection at all) still get the clear-on-first-auth path.
Addresses Codex P1 on #742.
* fix(sync-guard): inspect force-push results + mark blocked single-provider as error
- Force-push handler now inspects syncNow result entries: applies any
mergedPayload to local state, only clears the banner when all providers
report success, surfaces a toast error otherwise. Previously the banner
cleared unconditionally regardless of network/auth failures (Codex P1).
- syncToProvider shrink-block branches now mark provider status as
'error' with a 'Sync blocked: would delete too much' message instead
of 'connected'. Status aggregators treat 'connected' as healthy, so
the blocked upload was surfacing as 'synced' in the UI (Codex P2).
syncAllProviders already used this pattern; this brings the
single-provider path in line.
* fix(sync-guard): exempt USE_LOCAL conflict + clear post-merge BLOCKED + expose 'blocked' status
- USE_LOCAL conflict resolution now passes { overrideShrink: true }: the
conflict modal already served as user confirmation, and shrink-blocking
it left users with a closed modal and an opaque banner (Review C-1).
- Post-merge round-trip in useAutoSync now detects shrink-blocked results
and resets syncState to IDLE via new manager.clearShrinkBlockedState().
The merged data is already applied locally; the next user-triggered
sync will re-check, and we don't wedge the manager in BLOCKED with no
visible banner outside the Settings tab (Review I-1).
- overallSyncStatus now reports 'blocked' as a distinct value from
'error', so downstream UI (status icon, future badges) can offer
shrink-block-specific affordances (Review I-2).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix(sync-guard): stabilize banner subscription dep + map 'blocked' status to error indicator
- The SyncBlockedBanner subscription useEffect depended on [sync] (the
whole hook return object), which gets a new reference every render.
This caused the listener to be unsubscribed+resubscribed on every
render, opening a tiny race window where a SYNC_BLOCKED_SHRINK event
could be missed and the banner would never appear. Destructure
subscribeToEvents (already useCallback-stable) and depend on it
directly, so the effect runs exactly once on mount.
- SyncStatusButton's status mapping had no arm for the new 'blocked'
value, falling through to 'none' (idle). The global status indicator
said healthy while the in-page banner said paused. Map 'blocked' to
the same error indicator used for 'conflict' so the UI is consistent.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix(sync-guard): only clear banner on actual success + hydrate from manager state
- Banner subscription now clears only on SYNC_COMPLETED with result.success.
SYNC_STARTED (auto-sync timer ticks) and SYNC_FORCED (fires BEFORE upload)
could clear the banner prematurely, removing the user's recovery affordance
while the underlying issue was unresolved (Codex P2).
- Manager now persists the last shrink finding in state.lastShrinkFinding
alongside the SYNC_BLOCKED_SHRINK emission. New public getter
getShrinkBlockedFinding() returns it when syncState is BLOCKED. Renderer
hydrates the banner on mount so a block that happened off-screen
(auto-sync while user was on another tab) is still visible when they
open Sync Settings (Codex P2).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix(sync-guard): unified BLOCKED-cleared event + USE_LOCAL inspects results
- USE_LOCAL conflict resolution now inspects syncNow() results, applies
any mergedPayload to local state, surfaces a toast error and KEEPS the
modal open on failure (so user can switch to USE_REMOTE). Mirrors the
force-push handler pattern. Without this, USE_LOCAL silently 'succeeded'
even when providers failed (Codex CLI P1).
- New SYNC_BLOCKED_CLEARED event emitted on every BLOCKED -> non-BLOCKED
transition via a private exitBlockedState() helper. Banner subscribes to
this single signal instead of guessing from per-provider SYNC_COMPLETED
events. Fixes:
- Multi-provider scenarios where first SYNC_COMPLETED clears the banner
while a later provider was still going to fail (Codex CLI P1).
- clearShrinkBlockedState() (post-merge self-heal) silently leaving
the banner stuck because no event was emitted (Codex CLI P2).
- disconnectProvider() now also exits BLOCKED state. Disconnecting
implicitly resolves any pending shrink-block warning, otherwise the
stale alert carried over to the next-account reconnect (Codex CLI P2).
- All BLOCKED -> non-BLOCKED transitions consolidated through
exitBlockedState() so lastShrinkFinding cleanup + event emission are
always paired (Codex CLI P3 #6 covered).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix(sync-guard): only clear BLOCKED on actual success, not on transient ERROR/SYNCING/CONFLICT
Previous patch called exitBlockedState() at every BLOCKED -> non-BLOCKED
transition, but this clears the banner on transitions that don't actually
resolve the shrink concern:
- SYNCING (sync just started — about to try, may fail)
- ERROR (transient transport failure, shrink concern still real)
- CONFLICT (separate concern; doesn't resolve the shrink)
If a user was in BLOCKED then triggered a sync that failed for an unrelated
reason (network, auth), the banner cleared and they lost the warning.
Restrict exitBlockedState() to terminal-success transitions:
- IDLE on successful upload (data made it to cloud — concern resolved)
- explicit clears (disconnectProvider, clearShrinkBlockedState)
- conflict resolution (USE_REMOTE/USE_LOCAL also end in IDLE)
Found by Codex CLI review of commit 12d7fa7b.
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
54b26511a1