QR scan

Problem Context

• The product wants to decode a QR or barcode from camera preview, a delegated OS scanner, a static image, or a pasted/manual code.
• Codes may contain URLs, payment intents, Wi-Fi credentials, device-pairing tokens, tickets, one-time login secrets, coupons, inventory IDs, contact cards, or plain text.
• Users may face denied camera permission, unsupported web APIs, missing scanner modules, dim light, glare, motion, tiny codes, damaged labels, multiple visible codes, expired codes, reused codes, or unsafe destinations.
• QR scan is adjacent to camera capture, permission request, file upload, two-factor authentication, security warning, sensitive-data reveal, and payment or device-pairing flows.

Selection Rules

• Choose QR scan when decoding a code and acting on the decoded payload is the central task.
• Use camera capture when the task is creating and reviewing media rather than interpreting a code value.
• Use permission request for the standalone camera-access rationale; QR scan includes permission only as one state inside the scan lifecycle.
• Use file upload when users provide an existing file; scan from photo is a QR fallback only when the file is an image containing a code to decode.
• Use two-factor authentication when the QR code enrolls, verifies, or recovers an identity factor; the scanner must protect secrets and hand results to the auth flow.
• Use security warning when the decoded QR payload is suspicious, external, destructive, payment-related, or credential-related.
• Preview decoded URLs, merchants, device names, account issuers, ticket IDs, or inventory IDs before opening, pairing, paying, submitting, or importing.
• Support scan repair actions such as torch, move closer, hold steady, clean lens, switch camera, choose from photo, paste code, or manual entry.
• Treat multiple visible codes as a selection problem and avoid executing whichever code happens to decode first.
• Clear camera frames, decoded secrets, and temporary payloads after cancel, timeout, successful action, or route change unless the task explicitly saves them.

Required States

• Unsupported detector, missing scanner module, insecure context, or unsupported format state.
• Pre-scan rationale state with task purpose, camera use, payload type, privacy, and fallback.
• Camera permission not requested, requesting, granted, denied, and revoked states.
• Delegated scanner state when the OS or platform scanner handles camera access outside the app.
• Live preview state with aim guide, active camera status, torch, switch camera, and stop control.
• Focusing, too far, too close, glare, low light, motion blur, damaged code, and no code found states.
• Detecting and decoding state with progress or frame feedback.
• Multiple codes found state with target selection before action.
• Decoded payload preview state with format, destination, issuer, merchant, device, or ID summary.
• Invalid, unsupported, malformed, expired, already used, duplicate, or wrong-task payload state.
• Unsafe URL, external destination, payment, credential, or account-change warning state.
• Scan from photo or image import fallback state.
• Manual code, paste key, enter URL, or typed fallback state.
• Successful action state for open, pair, pay, import, check in, redeem, or attach.
• Cancel, timeout, retry, and cleanup state that stops camera and clears transient values.
• Sensitive secret retention state for authenticator seeds, Wi-Fi credentials, payment payloads, and login tokens.
• Offline decode or offline validation state that explains what can be decoded locally and what needs network verification.

Interaction Contract

• Scanning starts only after users choose a QR-dependent task and can see purpose, fallback, and privacy impact.
• Users can tell whether the scanner is unsupported, waiting for permission, active, focusing, decoding, blocked, invalid, warning, confirmed, or complete.
• The detected payload is not executed silently when it can navigate, pay, pair, import credentials, join a network, or change account state.
• Poor scan conditions produce actionable repair guidance rather than an endless spinner.
• Camera denial or unsupported detection preserves the task through scan from photo, paste code, manual key entry, or another device path.
• Multiple visible codes require target selection or a stable highlighted target before action.
• Secrets, frames, decoded raw values, and failed payloads are cleared when no longer needed.

Implementation Checklist

• Define payload types, supported code formats, trusted domains, validation endpoints, expiry rules, duplicate handling, fallback paths, and retention before building the scanner.
• Check detector support and supported formats, and provide a platform fallback when BarcodeDetector, scanner modules, or camera APIs are unavailable.
• Use camera access only after explicit user action, and show active camera state, aim guide, torch, switch camera, cancel, and fallback controls while scanning.
• Throttle frame analysis, limit formats to expected values, handle decode errors, and avoid repeated actions from the same payload.
• Parse and validate decoded values before action, including scheme, domain, issuer, merchant, amount, account target, device ID, expiry, and replay status where relevant.
• Show a confirmation or warning for external links, payments, authenticator seeds, Wi-Fi credentials, device pairing, account changes, and irreversible actions.
• Provide scan from photo, paste code, manual key, typed URL, or support path when scanning fails or camera access is denied.
• Stop camera streams, clear decoded secrets, remove transient frames, and avoid logging raw payloads after cancel, timeout, or success.

Common Generated-UI Mistakes

• Opening the first decoded URL without showing the destination or risk.
• Using a camera capture flow that saves images when only the decoded QR value is needed.
• Blocking the task after camera denial despite available manual code or image fallback.
• Showing a scanner with no guidance for distance, light, glare, focus, or damaged codes.
• Executing the wrong code when several codes are visible in one frame.
• Treating an expired, duplicate, unsupported, or wrong-task code as a generic scan failure.
• Persisting authenticator secrets, Wi-Fi passwords, payment payloads, or camera frames after setup.

Critique Questions

• What decoded payload types are accepted, and what happens when the QR contains a URL, payment, credential, device token, ticket, or unknown text?
• Can users understand scan state, repair poor scan conditions, and complete the task without camera access?
• Does the flow preview or confirm consequential payloads before opening, paying, pairing, importing, or changing account state?
• How does the scanner handle multiple codes, repeated detections, expired codes, and unsupported formats?
• What decoded values, frames, or secrets are retained, logged, or cleared?
• Is this really QR scan, or does camera capture, permission request, file upload, two-factor authentication, or security warning own the main problem?