Repository navigation
fix(mobile): bound sign-in email input and code destination - #8670
Conversation
|
bot: E2E captures from the isolated local stack, using owned fake test accounts and the local email sink.
|
Code Review SummaryStatus: No Issues Found | Recommendation: Merge Executive SummaryThe incremental change extracts the destination-abbreviation literals into named constants with unchanged behavior (24 + ellipsis + 23 = the 48-character display bound) and adds regression assertions that the destination text carries no truncation props; no new defects found. Assumptions: Files Reviewed (5 files)
Previous Review Summary (commit c577c90)Current summary above is authoritative. Previous snapshots are kept for context only. Previous review (commit c577c90)Status: No Issues Found | Recommendation: Merge Executive SummaryThe mobile email step now caps the trimmed, lowercased address at 254 characters before any delivery request, and the code-step destination shortens only its display beyond 48 characters while submission and verification keep the full address; the accompanying regression tests cover both the rejection and the 254-character boundary. Assumptions: Files Reviewed (5 files)
Reviewed by deepseek-flash-latest · Input: 32.3K · Output: 2.3K · Cached: 116K Review guidance: REVIEW.md from base branch |
# Conflicts: # apps/mobile/README.md
|
bot: Merge-head re-check of the email sign-in flow on the isolated local stack: headless Android emulator, local backend, local mail sink, owned fake test account. The captures come from the email step and the code step only.
The re-check stops at the code step: the local device check refused the token exchange, which is unrelated to these two steps. |
|
bot: Android proof on the current head, against the isolated local stack (headless emulator, local backend, local database, locally captured mail).
Each capture was taken right after a uiautomator dump that reported the quoted text, enabled state and bounds; the assertions are those dumps. |












Evidence
Evidence: demonstrated — on the Android emulator against the isolated local stack, a 3,508-character address and a malformed address stayed on the email step with the localized inline error and created no sign-in token; a 249-character fake address and a normal fake address reached a code step whose destination was middle-abbreviated (or complete) with the code input, Verify, Resend and Back all visible, and the normal fake address completed sign-in with an OTP read from the local email sink. On iOS, a 74-character fixture showed the abbreviated destination with the code input and actions visible, and six digits enabled Verify. New regression cases fail against the previous behavior and pass with the change; the mobile auth and form suites pass (163 tests), and the same checks were repeated after merging
main.Change
The mobile email step validates the trimmed, lowercased address against the existing syntax rule and a 254-character maximum, keeping the localized inline message beside the field and never sending an ineligible address. The code step's destination prompt abbreviates addresses longer than 48 characters in the middle, so the code input, Verify, Resend and Back stay in the normal layout. Delivery, challenge binding and verification still use the full address; server eligibility, SSO and token policy are unchanged.
The full-address layout assertions that pinned the previous rendering are replaced by a boundary case that keeps submission intact.
Verification
pnpm --filter kilo-app exec vitest run src/lib/auth/use-native-auth.test.ts src/components/login/__tests__/email-otp-form.mounted.test.tsx: 163 passed, also after themainmerge.pnpm --filter kilo-app typecheck, changed-fileoxlint, andoxfmtare clean, also after themainmerge.Known limits: the 254-character maximum is a client rule; the shared OTP route is unchanged. The destination abbreviation is display-only.
Proxy answers
Answer: Client cap and bounded display
Confidence: 0.60 · Precedent: Put each separate concern in its own PR: session debabfb38c82 asked for the flag removal "in a separate PR". The brief scopes this item to the mobile files, and a server cap on the shared OTP auth API is a separate concern.
Answer: Accept the previous review
Confidence: 0.72 · Precedent: Regrade a PR only after meaningful changes since the last grade: session 55c9c80332a7, "regrading should only happen if there were meaningful changes"; main-merge commits do not change the reviewed implementation, and human ready is met (clean Kilobot review, CI green, no conflicts).