Auth OTP lock scope, recovery post-success route, return fallback hierarchy, and attempt-gate dismissal

DEC-0063 - Auth OTP lock scope, recovery post-success route, return fallback hierarchy, and attempt-gate dismissal

Context

DEC-0062 locked direction and reduced ambiguity, but still left concrete thresholds and fallback hierarchy open at operational level. This caused risk of inconsistent behavior across auth, recovery, and protected-entry routes.

Decision

OTP retry and lock:

• Baseline: 5 wrong OTP attempts -> lock 10 minutes.
• Lock scope: while lock is active, all OTP channels for the same auth intent are locked.
• No channel-switch bypass is allowed during active OTP lock.

Forgot-password completion:

• After password reset success, route user back to login step with success feedback and prefilled identity.
• Do not auto-login immediately after reset by default.

Return fallback hierarchy:

• If returnTo is invalid/expired, fallback first to nearest valid route in same program/skill context.
• If contextual fallback is unavailable, fallback to Home.

Attempt-start auth gate dismissal:

• Attempt-start auth gate can be dismissed by user.
• Dismissal keeps current page intact and does not execute protected attempt action.

Decision Value

• Makes OTP protection deterministic and hard to bypass.
• Keeps recovery flow safer and more predictable.
• Preserves user intent better when deep links are stale.
• Reduces friction by allowing exit from protected auth gate without dead-end behavior.

Rationale

This refinement keeps security guardrails explicit while preserving low-friction navigation and clearer intent continuity.