Date, read and split money the same way everywhere (app review batch 3)

[EmotiveImpact]

Before: activity, "This month", statements and exports dated entries by their UTC day, so an expense entered at 9pm in New York showed the next day, and one entered just after midnight in London's summer time showed the day before. Amount fields refused "1,200", and a euro commune could not type "12,50". Add expense could show the spare penny on one person and save it on another. A commune whose only records were recurring bills or exact split templates could switch from pounds to dollars, turning a £90 bill into $90, and the settings screen and the database disagreed about when the currency was fixed. Statements could not be opened for someone who had left. After an attempt whose reply was lost, a later refusal in the money dialogs said nothing had been saved, which might not be true.

After: entries are dated by the member's own day, every money field reads amounts one way, the preview and the save agree on every penny, one rule fixes the currency and the screen says why, statements with former members open from the breakdown, and those dialogs say an earlier attempt may already have been saved and where to check. Each fix has a test that fails on the old code.

This is batch 3 of the app review fixes and is built on #25 (batch 2), so review that first; the diff here shows only this batch.

What changed, by finding

Finding	Change
33	One helper dates a stored time by the member's own calendar day, used by activity, "This month", statements and the CSV export. In a statement a repayment keeps its own date but is never listed before the share it pays, nor a reversal before its repayment.
41	One reader for typed amounts, in packages/core/src/money.ts, used by every money field and exact split value. "1,200" and "1,200.50" work everywhere; "12,50" and "1.200,50" work in euro communes; elsewhere a decimal comma gets "Use a full stop for pence, like 12.50." A group of thousands never starts with 0, so "0,500" is refused rather than read as 500. The limit is the database's, 10,000,000,000.00, everywhere.
52	The spare penny goes to the largest remainder, and ties go by user id, so the same people get the same amounts whatever order they were ticked in. Add expense also previews the split between the same people it saves when someone leaves while the form is open.
40	Migration 0035: the currency is fixed once a commune has an expense, fund, recurring bill or exact split template, voided or archived ones included. update_commune_details enforces it and the snapshot reports what fixes it, which the settings screen explains.
54	The breakdown's statement picker lists people who have left, under "Former members", when there is anything between you.
Follow-ups	The repayment, payment report, correction and void dialogs no longer say nothing was saved after an attempt that may have been.

Releasing

Nothing hosted was touched. Migration 0035 is local only and follows 0034; it does not change the release order. A client from before 0035 keeps working: its settings screen may still offer a currency change that the database now refuses with a clear message.

How it was checked

On the final branch: 21 SQL test files on fresh databases plus the lock order test, 15 local API suites on a disposable database and port, 414 web tests in 39 files (date tests run in New York and London time zones), the reminder worker's tests, typechecks for the web app, local API and worker, and a production build.

In a browser: "1,200" read as £1,200.00 and saved with an even split, "12,50" refused in a pound commune with the full stop message, "12,50" and "1.200,50" read in a euro commune, a commune whose only record is a recurring bill showing the currency locked and why, and a statement with someone who left after repaying their share.

How

The database stays the authority: commune_private.currency_locked_by decides the currency rule, the snapshot reports it, and the screen only displays it (with the same rule worked out from loaded records against a database without 0035). The commune row is locked while the details change, and adding any of those records waits for that lock, so the database rule cannot be raced. One gap remains: a form left open while an admin changes the currency of a commune with no money records yet saves its amount in the new currency, where it then shows with the new symbol. The patch to update_commune_details and the snapshot uses pg_get_functiondef and replace() and stops if the definition no longer matches.

🤖 Generated with Claude Code

https://claude.ai/code/session_01A6P7aTcMBccooYYr4xYnVS

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
commune-web	Error		Oct 9, 2026 4:45pm UTC

[EmotiveImpact]

The Vercel preview for commune-web shows Error here, as it has on every branch since 6 October. It is the project or account issue explained on #24 (app review finding 45), not this diff: the production build of this branch passes locally (vite build on 42fe7ea). It needs someone with the Vercel login to read a failed deployment's log.

---

Generated by Claude Code

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-12T02:01:29.051712Z	42fe7ea	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.