The offline write-queue (packages/core/src/queue/write-queue-v0.ts, #33) was a
tested pure module that nothing imported. Approving a change while gitea was
unreachable made gitea:applyChange call the client directly and throw, losing
the write. Now it's wired end to end:
- queue-store.ts persists the queue next to the snapshot store (same
degrade-to-empty-on-corruption discipline; injectable path for tests).
- applyChange extracts the guarded write into applyChangeLive and, on
unreachability (any error that is NOT a GiteaApiError rejection), enqueues the
intent — coalesced by (issue, axis) — instead of throwing, returning
{ ok, queued, pending }. A genuine GiteaApiError still surfaces (a doomed
write must not replay forever).
- reconcile drains the queue once a successful read proves gitea is reachable,
re-reading so the board reflects the replays; replays are idempotent
(label plan.noop, assignee/milestone re-set). boot + stale reconcile report
the pending count so the badge shows immediately offline.
- Renderer: use-backlog threads `pending`; the OfflineBanner shows "N queued";
the chat approve message distinguishes a queued (offline) approval from an
applied one.
Also wires vitest into the desktop workspace (was missing, so the main-process
suite couldn't run via `yarn test`) and fixes a stale Capture copy assertion
left by the earlier posh-copy pass.
Tests: queue-store.test.ts (persist/reload/coalesce/replay-drain, real core fns);
9 main-process + 169 core green; 12 demo e2e green. A one-off GITEA_LIVE smoke
verified an online write lands+reverts and an offline approve queues+drains
against the real repo (not committed, per the repo's no-mutating-test convention).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
