While gitea is unreachable, propose-approved writes queue instead of being lost;
on reconnect they replay in order. The hard requirement is no duplication.
The mechanism is coalescing by axis. Every write targets one field of one issue
(estimate / priority / assignee / milestone), so `issue:kind` is the axis identity.
Queuing a second write to the same axis supersedes the first (moved to the tail),
so a burst of edits replays as one final write — and replay is idempotent (the
apply path no-ops a change already reflected server-side).
- `enqueueWrite` (coalesce), `pendingWrites`, `coalesceKey`, `affectedIssues`
(what a post-replay reconcile re-reads), and `replayQueue(queue, apply)` which
drains through the same guarded write path and returns the writes that still
failed so they stay queued. Never throws — a failure is data.
Acceptance met: a burst of offline edits + reconnect lands the final state with a
single apply per axis (not one per edit); still-failing writes stay queued. +4
core tests; typecheck green.
Follow-up: persist the queue in main + trigger replay on the reconnect signal
(the offline banner + disabled composer already exist) — the coalesce/replay
core is the tested heart.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
e5ce3fe87a