Shorten the app's wording, and tell users to tap Read menu

[AnirudhG15]

Stacked on #42 — based on fix/auto-capture-always-fires so the diff shows only the wording changes. Merge #42 first, and this retargets to main automatically.

Two changes, both about what the user actually hears.

Plain language

Everything the app says is read aloud by a screen reader, usually while someone is holding a phone over a table. A long sentence is one the listener is still hearing after the thing it described has already changed. An uncommon word is one they have to stop and decode. Both cost time at exactly the moment the user is trying to act.

25 strings were over 90 characters. Capture coaching took the biggest cut, since it plays over and over:

before	"I don't see menu text yet. Slide the phone slowly over the table until I find it, or tap Take photo to capture now."
after	"I don't see it yet. Move the phone slowly over the table."
before	"Still dark. Tilt the menu toward the nearest light, or ask for a phone flashlight. You can also tap Take photo and I will try anyway."
after	"Still dark. Tilt the menu toward a light."
before	"This menu is wider than it is tall. Turning the phone sideways, so its long edge runs left to right, will fit more of it. You can also keep going as you are."
after	"This menu is wide. Turn the phone sideways to fit more. Or keep going."

Also shortened: the capture announcements, the Browse Menu and Pause Voice messages, the mode-toggle labels, the camera error, the photo-quality notes, and the Settings hints. Nothing lost meaning — the long versions were explaining where they should have been instructing.

The Read menu step

Taking photos does not start the reading. analyze() is reachable only from the "Read menu" button, so nothing happens until the user activates it — and neither tutorial said so. A blind user who doesn't know that is left holding a phone full of photos wondering why the app has gone quiet.

Both tutorials now carry the step:

Then tap Read menu
Photos are not read until you tap Read menu. With Voice Control, say "Tap Read menu."

The full tutorial also gained a Take your photos step, so the capture flow reads in order.

Note on wording: the request mentioned saying "read menu" to VoiceOver. VoiceOver is a screen reader and doesn't take spoken commands — the Apple feature that does is Voice Control, where "Tap Read menu" is the correct phrasing. That's what the step says. With VoiceOver alone the user swipes to the button and double-taps, which the first sentence covers. Happy to reword if a different flow was meant.

Tests

7 new guards:

• ceilings on coaching (80 chars) and tutorial (100 chars) length
• no single spoken sentence over 60 chars
• a small list of words with plainer equivalents ("activate" → "choose/tap", "prior to" → "before", …)
• two tests that fail if either tutorial stops mentioning Read menu, or stops explaining that photos aren't read until it's tapped

Mutation-checked: reinstating one long, jargon-heavy message fails 3 of the guards.

Three existing tests hard-coded the old wording and broke on this change. Rather than re-copying the new strings into them, they now import the message tables directly (STAGE_MSGS, ROTATE_MSGS, RELAX_NOTICE are exported for this), so future rewording can't silently stop them checking anything.

Full suite 189/190, tsc -b clean, vite build clean. The one failure (auth.test.ts) fails identically on main — jose is declared but not installed.

Verified both tutorials render correctly in the browser at mobile size. The only console errors are /api/events 404s, which are the telemetry endpoint not existing under plain vite dev.

🤖 Generated with Claude Code

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
meetmymenu-ai	Ready	Preview	Aug 13, 2026 12:13am
meetmymenu-ai-site	Ready	Preview	Aug 13, 2026 12:13am