local-first-ledger

Summary

Every write applies locally first and the server write queues behind it, so no screen in the product has a loading state.

Why it matters

Offline is the normal case — a bill is split at a table, in a basement restaurant, on a train. An expense that cannot be recorded there is worse than one recorded without its photo.

Implications

• There is no loading wireframe in this set, and that is a property of the architecture rather than an omission. The two real waits are the store round-trip (plans) and a receipt upload (expense-receipt), and both are drawn.
• The two failure paths must never be silent: a denied read looks exactly like an empty account and a refused write looks like a row that saved and then vanished. Both surface through the SyncBanner — see balances.
• A receipt's receiptPath is written to the expense only AFTER the upload lands. Writing it up front shows every other member a path to an image that is not there.

Related

• balances — where the banner is read
• expense-receipt
• a-record-is-never-erased

Sources

• src/data/actions.ts
• src/data/store.ts
• src/services/receipt-queue.ts