[lhr0909]

Why

Simon tested RespondKit 0.6.1 in ReceiptGenie's iOS and Android apps and found three problems (RK-1):

• The email ask flashed even when the email was known.
• Android's attach control was a text button above the input.
• The empty state, the subtitle and the attach menu were plain literals outside RespondKit's i18n toolchain.

ReceiptGenie 2.9.0 should ship on the fixed SDK.

What changed

• Email-ask flash (asksForEmail on the iOS store, Android SupportState and the RN snapshot): the ask shows only after the contact lookup for the current identity has succeeded without finding an email. A host-supplied email counts as known immediately, and updateIdentity resets the state. A failed or canceled lookup keeps the ask hidden, and resolveContact retries it on the next request, including when the session is cached (review findings 1–2). The epoch is rechecked after that step, so an identity switch during a failed lookup can't leak the old session's token (follow-up P1). Before, iOS, Android and RN rendered the ask on email == nil while a stored contact was still being fetched.
• Web: no code change. The hook already reports resolving_context whenever the context doesn't match and sets the email before ready. Two MutationObserver tests now guard this; I confirmed they fail when the prompt does mount.
• Android attach: a 44dp paperclip IconButton in the composer row, left of the field and aligned with send. The photo/files menu stays anchored to it.
• Strings: one validated catalog feeds every client.
  • iOS: the generator writes RespondKit.xcstrings into RespondKitUI/Resources (defaultLocalization: "en", .process("Resources")).
  • Android: Compose adds localization/generated/android/res as a res dir and drops its own strings.xml.
  • Web and RN: compileJavaScriptMessages (in @respondkit/paraglide-resources, validated by the same parseResources) emits a typed messages(locale) module into packages/react/src/widget/messages.ts and packages/react-native/src/messages.ts. localization:check byte-checks both, and the npm files lists ship them.
  • On every client the empty state, "Ask us anything" and the attach menu (plus its a11y label) read from the catalog. Web picks by context.locale, RN by the device locale.
  • The macOS localization workflow compiles the catalog at its new path (review finding 4).
• 0.6.2: pnpm version:set 0.6.2 and docs/releases/0.6.2.md. Not published, and no GitHub release.

Scope

• Only the surfaces named on the card. Other strings ("Write a message…", the email prompt, Retry and so on) are still literals on every client.
• Locales: every SDK ships English only (settings.json has locales: ["en"]), so "every shipped locale" means en. This PR adds no new languages. Translating into ReceiptGenie's languages needs a decision and a follow-up.
• Web and RN don't use Paraglide's own JS compiler: it loads the inlang project, whose plugin module is a CDN URL in settings.json, at build time.

Tradeoffs

• Commits are per platform, not per issue, because each platform's screen file carries all three fixes.
• The Compose strings.xml was deleted rather than kept in parallel, because duplicate resource names in one module fail the merge.

Blast radius

• Android public resources: respondkit_new is removed (use respondkit_new_conversation), and respondkit_intro now holds the longer intro line. Hosts that override either name must update their overrides. ReceiptGenie doesn't.
• AttachmentPicker (internal) now takes a content slot. MessageComposer (web) takes an optional locale.
• While the contact lookup keeps failing (an older server without the contact endpoint, or an outage), every request on the session retries it and the ask stays hidden.
• The root package.json adds the @respondkit/paraglide-resources workspace devDependency; the lockfile change is 3 lines.
• The SwiftPM RespondKitUI target now has a resource bundle.
• No API or protocol change. The only apps/api and packages/discord diffs are the 0.6.2 version bumps; /approve and the Discord commands are untouched (a separate PR redesigns them).

Verification

• pnpm exec vp check passes.
• pnpm localization:check matches.
• pnpm test:release passes.
• pnpm test:all passes: 410 tests at 1c7f181 (paraglide-resources 37 with the new exporter test, react-native 20 with the retry and identity-race cases, API 159).
• swift test: 24 tests in 3 suites, including the failed-lookup (2 cases), canceled-lookup and identity-switch-during-failed-lookup tests; each fails on the store before its fix. The iOS simulator build of RespondKitUI succeeds, and the built bundle contains en.lproj/RespondKit.strings with all six keys.
• ./gradlew :core:test :compose:assembleRelease :compose:lint :compose:assembleAndroidTest: BUILD SUCCESSFUL, with 24 core tests including the failed, canceled and identity-switch lookup tests. The identity-switch test fails at c653a6c with 1 stale statuses call.
• :compose:connectedDebugAndroidTest on an API 36 emulator: 6/6, including the new attachIconSitsLeftOfTheMessageFieldInTheSendRow.
• Screenshots from the example apps against native/examples/demo_server.py are attached to RK-1 on the board:
  • Android composer and menu: paperclip left of the input.
  • iOS empty state: catalog strings resolved.
  • The demo server has no stored email, so the ask correctly shows after lookup.
• CI at 1e58df7: every check passes, including verify-npm. The smoke install now pins the React Native peers to the tested versions (react-native 0.87.1, device-info 15.0.2, get-random-values 2.0.0, safe-area-context 5.10.1). Before, it resolved react-native 0.88.0, which needs react ^19.3.0 and failed with ERESOLVE against the pinned 19.2.8.
• npm pack --dry-run includes src/widget/messages.ts (react) and src/messages.ts (react-native).
• Not done: no web or RN UI run after the string wiring (the web tests render the strings), no screenshot of the open iOS attach menu (simctl can't tap), and no on-device check inside ReceiptGenie itself.

🤖 Generated with Claude Code

[simon-langoustine]

VERDICT changes-requested / verifier-failed at head 1de16ef23a576e9b0eab1ba86e0ff191f01b5854, compared with fixed base cd38add8d98719db3c626fce74a0bc0716e7b2fe.

Four act-on findings are detailed in the inline threads:

1. Failed contact lookups mark the email as resolved and show the ask even when the server stores an address. Healthy refreshes do not retry the lookup. Reproduced with the actual RN store/API client and in the Android example.
2. Canceling the first native contact lookup leaves contactResolved false behind a cached session. Reopening and refreshing never resolves it, so customers without email never see the ask. Reproduced against unchanged Swift sources; Android has the same sequence.
3. The specified web/RN empty-state, subtitle and attachment strings still bypass the shared localization toolchain. Only English currently ships, so additional languages are not required; removing the named literals is required.
4. The Swift catalog moved, but the macOS localization workflow still compiles its deleted path. The command fails locally and in this head's CI.

Verification passed locally: pnpm exec vp check; pnpm test:all with 406 tests; localization:check; test:release with 8 tests; release:check; swift test with 21 tests; Android core tests, Compose release build/lint/instrumentation build and example debug build; all 6 connected Compose tests; iOS example simulator build. Version wiring is consistent at 0.6.2. The excluded API and Discord source files are unchanged.

Live UI: drove Android's empty state, paperclip menu, system Files picker and selected-file row, and reproduced the contact-error behavior. Drove web sending, close/reopen, a second send at 390x844, file-upload failure/removal and email-save failure. Android layout looks aligned. Local fixtures were used; no customer-facing sends occurred. The attachment fixture returned a precompleted upload, so this is not proof of real file transfer.

Consider: verify-npm also fails because its smoke installation combines React 19.2.8 with automatically selected React Native 0.88.0, which requires React ^19.3.0. The checker and peer constraints are unchanged here; resolve or track this before publishing.

Noted / limits: interactive iOS testing was blocked by simulator launch delays and an agent-device XCTest runner timeout. RN UI and ReceiptGenie host integration were not run. CONTEXT.md, the project verify skill and feature map were absent; used the native demo instructions and independent consistency reviewers. Interrogate's configured Claude/Grok models were unavailable, so GPT-6.1 Sol and GPT-6 Astra reviewed independently; both identified cancellation and localization issues. No product code was edited, pushed, merged or published.

Evidence is attached to RK-2: logs and runnable reproductions, Android layout, attach menu, selected file, incorrect ask after recovery, and web narrow-screen second send. Board links require access to the local Office instance.

[simon-langoustine]

VERDICT changes-requested / verifier-failed at head c653a6c9643a28701a7ab549e2bb3445b45b3c39.

Re-review is limited to the four findings from 1de16ef and the stated iOS/RN UI gaps. The four original findings are addressed:

• Failed contact lookup keeps the ask hidden and retries on a cached session.
• Canceled native lookup resumes on subsequent use; new regression tests cover it.
• The named web/RN strings now consume generated canonical catalogs; generation checks and package file lists cover them.
• The Apple localization workflow uses the moved catalog. Its compile/runtime check passed locally, and macOS CI passes.

One new act-on issue in the retry fix blocks approval: a failed contact lookup skips the identity-generation check before an API write. Both independent reviewers found this. Using the actual RN store and API client, I reproduced a queued message POST to user A's existing thread with A's token after updateIdentity(B), before logout. The same reproduction produces 1 stale write on this head and 0 on the previous head. A second reproduction shows saveContact after the switch. Swift and Kotlin contain the same unchecked failure return. The inline thread identifies the fix and required test.

The previous iOS/RN execution gaps are now closed for the local demo flows:

• iOS: built this head and used the working agent-device runner. Checked empty state, email ask after lookup, attach menu, system Files picker/cancel, send/reply, close/reopen through the alternate host trigger, and save-email prompt dismissal. With contact returning 503, the ask remained hidden; changing the fixture to a successful empty contact made it appear on a later poll without resetting the store.
• RN Android: built this head, used its Metro bundle, sent RK2, received the demo reply, opened the catalog-backed attach alert and system Files picker. The demo's custom greeting replaces its no-greeting empty state; that branch was checked in code and catalog tests.
• Web: sent a message, checked the catalog-backed subtitle/attach label, reopened, and checked 390x844 layout.

Passed locally: vp check; all 409 package tests; localization:check; 23 Swift tests; 23 Android core tests; Compose release build/lint and example debug build; native iOS simulator build; RN Android debug build; Apple catalog compile/runtime tests. Standard suites do not cover the newly reproduced rejected-lookup identity race.

Consider: the unchanged npm smoke peer-dependency conflict still fails verify-npm. No new act-on finding beyond the identity race. No ReceiptGenie host integration or real file-transfer check; all sends used local fixtures. Android multiword input was truncated by the adapter, so only the actual RK2 send is claimed. No product source changes, push, merge or publication.

Evidence on RK-2: logs and runnable head/baseline reproductions, iOS attach menu, iOS send/reply, failed contact hidden, recovered contact ask, RN send/reply, RN attach menu, web narrow layout. Board links require the local Office instance.

[simon-langoustine]

Approved at 1c7f1816ef84d0e19aca60eab5aafc3ee34381f4 — unit-test-verified.

Scoped re-review of the remaining P1 identity race, from fixed point c653a6c9643a28701a7ab549e2bb3445b45b3c39.

The RN, Swift, and Kotlin token paths now recheck the identity epoch immediately after resolving contact, before returning the token to an authorized operation. A failed contact request can no longer let the old identity perform the pending operation after an identity switch. The new regression tests cover this interruption. Both independent reviewers found no remaining issue in this six-file delta.

Act-on: none. The remaining P1 is resolved; the four original findings were resolved in the preceding review.

Verification at this head:

• React Native: 20 tests passed.
• Swift: 24 tests passed.
• Kotlin core: 24 tests passed.
• pnpm exec vp check: passed.
• Both prior adversarial reproductions rerun against current source: zero stale message writes and zero stale contact saves after switching identity. Logout of the old session still occurs as intended.

Consider: the existing verify-npm smoke-install failure remains a pre-publication issue (React 19.2.8 / automatically selected RN 0.88 peer conflict), outside this scoped logic fix. Current failing job.

Noted: unchanged screens were not driven again at this head. The preceding review closed the iOS adapter and RN UI gaps at c653a6c9643a28701a7ab549e2bb3445b45b3c39; that review records the UI coverage and limits. This approval is for the scoped pure-logic follow-up, not a store-release or publication verdict. No product code edits, merge, or publication performed.

Evidence: RK-2 logs and standalone reproductions (Office board access required).