feat(app): Published tab + Settings → Account + cross-device sync

[graydawnc]

What

The renderer side of "what I've already published, and what my account looks like" — the surfaces a signed-in user spends time in after they've made a share.

• SharesPage: tabbed (Drafts ← existing | Published ← new). The Published tab lists the user's live shares with title, slug, status, last republish time, copy-link, view, unpublish — sourced from the new published_shares_cache.
• Settings → Account: handle claim (with live availability check), Sign out, Schedule deletion / Cancel deletion (24h grace), Connect provider (when signed-out)
• published_shares_cache (schema v15): local mirror of /api/me/shares so the Published tab renders instantly on cold start and stays readable offline. NOT the source of truth — D1 on the backend is. Rows are upserted whenever myShares() succeeds; entries dropped from the remote response are pruned via clearAll + upsertMany.
• usePublishedShares hook (with regression test): SWR shape with optimistic mutation generation counter — a stale myShares response can't clobber an in-flight local revoke/republish.
• DeleteAccountConfirmModal: centered confirm dialog mirroring the publish-side UnpublishConfirmModal — destructive actions get the same visual weight.
• Main IPC additions: cached-published, cache-published, get-published-by-draft, schedule-delete, cancel-delete.

Why

A share's lifecycle doesn't end at publish. The user comes back to read, copy, share with someone else, edit, republish, unpublish. None of that worked before this PR; the editor's Share menu could publish but the renderer had no surface to list what you'd published. Bundling these two surfaces lets one cache (published_shares_cache) serve both the Published tab and the editor's "is this draft already published?" lookup.

Cache-first matters because:

• Sign-in happens on first publish, but most renderer launches don't trigger a fresh sync. The Library / Drafts / Published tabs should render in the same beat as the Library tab — a network-gated render would be a regression
• The user might be offline. We don't want the Published tab to throw Network error when the user just wants to copy a slug they published last week
• Cross-device sync is correct: on next online tick, SWR fetches /api/me/shares and reconciles

Data model

flowchart LR
    subgraph local["local (better-sqlite3)"]
        SD[(share_drafts)]
        PSC[(published_shares_cache<br/>v15)]
    end
    subgraph remote["backend D1"]
        PS[(published_shares)]
    end

    SD -- draft_id --> PSC
    PSC -- draft_id --> PS

    subgraph renderer
        PT[Published tab]
        EM[Editor manage view]
        SA[Settings Account]
    end

    PT --> PSC
    EM --> PSC
    SA --> A[GET /api/me]
    PSC -.SWR.-> MS[GET /api/me/shares]
    MS -.upsertMany.-> PSC

Loading

Published tab — SWR with optimistic guard

sequenceDiagram
    autonumber
    participant U as User
    participant ST as SharesPage / Published
    participant H as usePublishedShares
    participant C as published_shares_cache
    participant API as /api/me/shares

    ST->>H: mount
    H->>C: listAll() — instant
    C-->>H: cached rows
    H-->>ST: render rows
    H->>API: fetch (SWR)
    Note over H: localMutationGen captured at fetch start

    par concurrent revoke
        U->>ST: click Unpublish
        ST->>H: noteLocalMutation()
        H->>H: mutationGen++
        ST->>API: POST /api/revoke/:id
        ST->>C: markRevoked(slug)
    end

    API-->>H: { shares: [...] } (started before mutationGen++)
    H->>H: localMutationGen != current → drop response
    Note over H: Without the guard, the stale response would<br/>resurrect the just-revoked row in the cache

Loading

Account deletion lifecycle (renderer side)

stateDiagram-v2
    [*] --> Idle: /api/me deletion_pending_until = null
    Idle --> ConfirmModal: click "Delete account"
    ConfirmModal --> Idle: cancel
    ConfirmModal --> Scheduling: confirm
    Scheduling --> Pending: 200 from POST /api/me/delete
    Pending --> Cancelling: click "Keep my account"
    Cancelling --> Idle: 200 from DELETE /api/me/delete
    Pending --> Pending: render countdown ("Executes in 23h 45m")
    Pending --> Tombstoned: grace expired, worker ran<br/>(handled in PR #360)
    Tombstoned --> [*]
    Idle --> Pending: deletion_pending_until seeded<br/>from /api/me (cross-device)

Loading

The deletion banner's seed-from-server step matters: if the user scheduled deletion on web at 10:00 and opens the desktop app at 10:15, the desktop surface must show the pending banner and the Cancel CTA. Without this, the desktop UI would look idle and the user couldn't recover within the grace window.

Schema v15

CREATE TABLE published_shares_cache (
  id                 TEXT PRIMARY KEY,         -- slug
  title              TEXT NOT NULL DEFAULT '',
  visibility         TEXT NOT NULL,            -- unlisted|profile-listed
  version            INTEGER NOT NULL DEFAULT 1,
  published_at       INTEGER NOT NULL,
  revoked_at         INTEGER,
  expires_at         INTEGER,
  draft_id           TEXT,                     -- link back to share_drafts
  client_request_id  TEXT,                     -- content hash, drives "Unpublished edits" badge
  updated_at         INTEGER NOT NULL
);
CREATE INDEX idx_published_shares_cache_published_at ON published_shares_cache(published_at DESC);
CREATE INDEX idx_published_shares_cache_draft_id ON published_shares_cache(draft_id) WHERE draft_id IS NOT NULL;

Gating (prod-safe)

Same as PR #361/#362: the Published tab + Settings Account section render through useSharePublish(), which is false in prod (Vite inlines VITE_FEATURE_SHAREPUBLISH at build time, CI doesn't set it, Terser strips every guarded branch). The schema migration runs on every launch (additive, no-op if v15 already applied), but until the gate flips no UI exposes the new cache.

SettingsPanel.tsx only includes the Account tab when useSharePublish() is true.

Verification

• pnpm --filter @spool-lab/core test — published-shares-cache.test.ts (insert / upsert / list / clearAll / by-draft lookup) + migration-v15
• pnpm --filter @spool/app test — usePublishedShares.test.ts (the localMutationGen guard) + SettingsAccount tests
• pnpm --filter @spool/app test:e2e — share-published-tab specs (existing list, revoke triggers row strike-through, copy-link uses the live URL, empty state when never published)
• Manual: with VITE_FEATURE_SHAREPUBLISH=1, publish two drafts → Published tab lists both; revoke one → tombstone; restart app offline → both rows render from cache; schedule delete in web → desktop banner appears on next foreground

Risk

Schema migration is additive (CREATE TABLE IF NOT EXISTS). The cache layer is opt-in via the gate; until enabled, the rows never get written and the surfaces never render. No callers in main reach into the new IPCs.

Submitted by @graydawnc.