QA: cross-surface verification (session sync, storage reconnect, workflow publish, blog/comments, loading feedback)

[zo-sol]

Context

Over the last two days we shipped features and fixes that all touch the same flows across three surfaces (VSCode webview, mobile/Android, CLI). Before calling them done, we need one coordinated end-to-end pass on every surface, and critically, confirmation that none of the fixes added extra API/RPC/storage traffic.

Relevant recent work:

• Cloud sync auto-recovery (retry transient failures, surface reconnect on dead token) - a8d7263
• Backfill on reconnect (push only sessions the cloud is missing) - 9d71c31
• Storage pill phantom-connected fix - a53b336
• Workflow builder UI + exclude owned workflows from the skill picker - 279b8e6, 92ddeaa (PRs Workflow publishing: contract + backend + webview/VSCode/mobile + CLI + MCP tool (#88) #95 / Mobile: add workflow publishing UI (parity with VSCode) #99)
• Note title/image "unknown key" write fix - PR Fix: note title/image write fails with unknown key #98
• Completion overlay redesign (LED plaque), VSCode + mobile - 279b8e6
• Dynamic model picker from installed CLI - f233e2c

Surfaces to cover

• VSCode webview (core chat/ui/webview.ts via extension host)
• Mobile / Android (React surfaces/webview via the localhost server)
• CLI (Ink app)

---

1. Session-list sync between devices

Sign at least two devices/surfaces into the same wallet + same Google Drive and confirm the session list converges.

• Device A creates a new session -> it appears on Device B after a refresh
• Cold start on each surface loads the cloud + local union (not a local-only stale list)
• Deleting a session on one device removes it on the other
• Confirm the "mobile shows a 2-day-old list" report cannot recur (root cause was an expired PC refresh token that silently killed uploads)

Pass: both surfaces show the same set within one refresh; backfill has pushed the backlog.

2. Storage disconnect / reconnect smoothness

A tester reported disconnect/reconnect felt clumsy; the phantom-connected state was fixed (a53b336). Verify the full cycle is smooth on each surface.

• Disconnect -> pill immediately shows "no cloud / connect" (no "undefined", no ghost "disconnect" button)
• Reconnect -> one-tap re-auth, then uploads resume
• On a dead token (invalid_grant), the UI surfaces a clear "reconnect" affordance instead of failing silently
• Reconnect triggers backfill exactly once (not on every passive boot, not on a timer)

Pass: no confusing states, no dead-ends, clear status at each step.

3. Workflow publishing (manual UI + agent-driven)

• Publish a workflow by hand in the UI (skill/workflow toggle -> owned-skill checklist -> mint & publish)
• Ask an agent to publish a workflow and confirm it produces the same on-chain result
• Behavior with the 2 default (bundled) skills: are they shown/selectable in the builder? Default skills have no on-chain mint and cannot be required skills (would fail NotInOfficialCollection). Confirm they are either correctly excluded or handled with a clear message, not a raw chain error.
• Both paths land a valid type: workflow NFT with a non-empty base58 requiredSkills in the official workflows collection

Pass: both manual and agent publish succeed; the default-skill edge case is handled gracefully.

4. Blog posting + commenting on another agent

• Post to your own blog with and without a title/image - verify PR Fix: note title/image write fails with unknown key #98 fixed the "unknown key: title" write failure on all surfaces
• Comment on another agent's profile
• Both land on-chain and render back after a refresh

Pass: no unknown-key failures; posts/comments appear.

5. Loading / completion feedback

While doing 1-4, watch for missing "loading..." or "done" signals that leave the user unsure.

• Every long action (list load, publish, buy, post, comment, backfill, reconnect) shows a loading state
• Every success shows a clear completion signal (e.g. the COMPLETE overlay) and every failure shows an error
• Flag any surface where feedback is missing or inconsistent (VSCode has skeletons + LED overlay; confirm CLI and mobile have equivalents)

6. Desktop approval popup on Linux / Windows

The OS approval popup that fires when the VSCode window is unfocused (user is looking at another app) was built for all three OSes but only macOS was live-tested. Verify it actually shows and behaves on Linux and Windows machines.

• Linux (zenity, with kdialog fallback): with VSCode unfocused, trigger an approval -> a native popup appears; Approve / Always / Deny work; Deny opens a reason input; session title shows in the dialog
• Windows (PowerShell WinForms): same checks - popup appears while VSCode is in the background, Approve is the default (Enter) button, reason-with-back works
• Both: answering the popup resolves the in-app approval card (no double-prompt); returning to VSCode without answering dismisses the popup and hands off to the webview card
• Both: popup fires only when unfocused, not when VSCode is in the foreground

Pass: on Linux and Windows, an unfocused approval reliably raises an OS popup and resolves cleanly, matching macOS behavior.

---

Deliverable

File a separate, focused issue for each concrete gap found (per surface), linking back here.

Constraint - do NOT add API / RPC / storage traffic

Any fix that comes out of this pass must not increase call volume or introduce loops:

• No polling, no per-render network calls. Drive list stays a single call per sync, not per item.
• Backfill stays one-shot on explicit (re)connect - never on passive boot, never on a timer.
• No recursive or retry storms. Transient retries must be bounded with backoff (already the case in mirror.ts); invalid_grant must fail fast, not retry.
• Reuse already-fetched data (ownedSkills, mints, on-chain groups) instead of refetching.
• When in doubt, measure: log call counts before/after and confirm parity.