a review pass, not a rewrite — nothing here changes without Isabel + Marie sign-off.
Tone-of-voice review — is the app's own copy actually on-voice?
The Week-1 priority: check every piece of in-app language against the established voice — lowercase, warm, somatic, non-punitive. An agent grepped every user-visible string across 20 files (alerts, errors, buttons, settings, paywall, crisis screen) against the app's own best existing copy as the baseline. This is the full findings list — nothing padded, nothing trimmed.
How this works, and the baseline it's measured against
There's no separate brand-voice document — "lowercase, warm, somatic, non-punitive" is the whole spec. So the baseline is the app's own best existing copy: the lines below are already right, and everything flagged is measured against them.
Each card is the exact string, verbatim · why it breaks the voice · one possible rewrite — always labeled a suggestion, never a decision, because Allin's rule is all user-facing copy needs Isabel + Marie sign-off. Choose Flag to Isabel · Hold · Leave as is per finding, then Copy my decisions.
Not systemically broken — two concentrated clusters
The exemplar screens (crisis support, consent, "how allin works," the check-in body copy, most CTAs) are genuinely good and consistent with each other. The problems cluster in two places: error/alert/failure paths — every single alert or error string found breaks the established voice, several by surfacing raw engineering text straight to a user who's already frustrated — and nav headers / settings-style rows, where roughly half the screens use lowercase and half use Title Case for the identical UI pattern. ForceUpgradeView.swift is the one outright outlier that reads like a different app entirely.