Attempt execution reliability and submit-integrity baseline

DEC-0068 - Attempt execution reliability and submit-integrity baseline

Context

Attempt Flow remained placeholder-level, creating execution risk for core learning behavior: answer safety, submit safety, and timed-mode consistency.

Decision

Attempt modes:

• Support two modes:
  • untimed (default for normal practice),
  • timed (simulation/full-test style).

Draft safety:

• Attempt answers are continuously saved during the session.
• If network is unstable, local draft fallback is kept and re-synced when possible.
• Re-entering an unfinished attempt resumes from latest valid draft state.

Submit safety:

• Before submit, show lightweight review summary (answered/unanswered).
• Submit remains non-blocking even with unanswered items.
• Apply idempotent submit guard to prevent duplicate finalization from multi-click or retry race.

Submit failure behavior:

• On transient submit failure, keep attempt state and allow retry without answer loss.
• Surface explicit state feedback: saving/submitting/retry-needed.

Timed expiration:

• Timed attempts use authoritative countdown.
• On time expiry, attempt follows timeout submit path and transitions to result.

Pipeline boundary:

• Only successful submit creates finalized attempt output for result pipeline.
• submitted_at remains source-of-truth for streak/progress attribution.

Decision Value

• Protects core user trust by reducing accidental answer loss.
• Keeps attempt flow simple for learners (no harsh blocks) while improving data integrity.
• Gives implementation teams one consistent baseline instead of variant-by-variant behavior drift.

Rationale

The attempt step is the highest-frequency action in the product. A minimal, deterministic baseline here improves both UX quality and operational reliability without adding heavy complexity.