Skip to content

E5 follow-up: completion authority tightenings (#75)#82

Merged
AtomicTrxn merged 1 commit into
mainfrom
e5-followup-completion-authority-tightenings
May 17, 2026
Merged

E5 follow-up: completion authority tightenings (#75)#82
AtomicTrxn merged 1 commit into
mainfrom
e5-followup-completion-authority-tightenings

Conversation

@AtomicTrxn

Copy link
Copy Markdown
Owner

Closes #75. Implements the five tightenings recommended in docs/architecture/completion-authority.md (landed in #74).

Summary

  • Task 1SolveScreen.dispose now flushes the autosave when the puzzle is in a terminal state, backstopping the unawaited markComplete in SolveNotifier._persistCompletion so a normal screen tear-down still persists the completion to solve_sessions even if the markComplete write is still in flight or fails.
  • Task 2 — New solve_completion_roundtrip_test.dart drives SolveNotifier through every terminal status (solved / solvedWithHelp / solvedWithReveal / revealed) against a real SolveRepositoryImpl, disposes the container, then resumes from the same in-memory DB. Locks the inverse-mapping invariant between _deriveCompletionType (notifier) and _statusFromDb (repo).
  • Task 3 — Reset-while-saving race test uses a _GatedMarkCompleteRepository spy that lets markComplete's inner DB writes complete but holds its Future open. The test then triggers resetPuzzle and asserts:
    • puzzle_completions retains the completion row (append-only)
    • solve_sessions.status ends in in_progress (reset wins the session-row race)
    • In-memory SolveState reflects the reset
  • Task 4 — Doc comments on usedCheck / usedReveal in solve_sessions_table.dart marking them as session-state-only inputs to CompletionType derivation. Reading them post-completion to infer the type is a bug.
  • Task 5 — Doc comment on completionType in solve_sessions_table.dart explaining the intentional duplication with puzzle_completions.completion_type (hot read for Archive; puzzle_completions remains the history authority).

Acceptance criteria

  • Task 1: flushPendingSave invoked on solve-screen dispose when status is terminal
  • Task 2: round-trip test passes (4 status scenarios)
  • Task 3: reset-race test passes
  • Task 4: schema comment added on usedCheck / usedReveal
  • Task 5: schema comment added explaining intentional completionType duplication
  • flutter analyze clean
  • Full flutter test passes (328 tests)
  • No behavior changes visible to the user

Test plan

  • flutter analyze — no issues
  • flutter test — 328/328 pass
  • flutter test test/features/solve/solve_completion_roundtrip_test.dart — 5/5 pass

Out of scope (per issue)

  • Schema changes (drop/add columns)
  • Replacing autosave with synchronous writes

@AtomicTrxn
AtomicTrxn force-pushed the e5-followup-completion-authority-tightenings branch from 85fe444 to 91a4942 Compare May 17, 2026 04:27
Implements the five tightenings recommended in
docs/architecture/completion-authority.md:

1. SolveScreen.dispose flushes the autosave when the puzzle is in a
   terminal state, backstopping the unawaited markComplete in
   SolveNotifier._persistCompletion so a normal screen tear-down still
   persists the completion to solve_sessions.

2. New solve_completion_roundtrip_test.dart drives the SolveNotifier
   through every terminal status (solved / solvedWithHelp /
   solvedWithReveal / revealed) against a real SolveRepositoryImpl, then
   disposes the container and resumes — locking the inverse-mapping
   invariant between _deriveCompletionType (notifier) and _statusFromDb
   (repo).

3. New reset-while-saving race test uses a gated SolveRepository spy
   that holds markComplete's Future open after its DB writes land, then
   triggers resetPuzzle and asserts puzzle_completions retains the
   completion row while solve_sessions and in-memory state reflect the
   reset.

4. solve_sessions_table.dart: doc comments on usedCheck / usedReveal
   marking them as session-state-only inputs to CompletionType
   derivation; reading them post-completion is a bug.

5. solve_sessions_table.dart: doc comment on completionType noting the
   intentional duplication with puzzle_completions.completion_type (hot
   read for Archive; puzzle_completions remains the history authority).

No behavior changes visible to the user; flutter analyze clean, full
flutter test passes (328 tests).
@AtomicTrxn
AtomicTrxn force-pushed the e5-followup-completion-authority-tightenings branch from 91a4942 to 8c7a8f9 Compare May 17, 2026 04:36
@AtomicTrxn
AtomicTrxn merged commit 661ed1e into main May 17, 2026
3 checks passed
@AtomicTrxn
AtomicTrxn deleted the e5-followup-completion-authority-tightenings branch May 17, 2026 04:40
AtomicTrxn added a commit that referenced this pull request May 17, 2026
- Color Guide HTML version string 3.0 → 3.5 to match the v3.5 spec
  already in force across the codebase (issue #83, PR #84).
- completion-authority.md: "Required tightenings (after this doc lands)"
  rewritten as "Tightenings (implemented)" with a link to PR #82, since
  all six tightenings have landed. Issue-ref format updated to current
  E-series naming (#59 Sprint E5 → #59 E5).
AtomicTrxn added a commit that referenced this pull request May 17, 2026
- Color Guide HTML version string 3.0 → 3.5 to match the v3.5 spec
  already in force across the codebase (issue #83, PR #84).
- completion-authority.md: "Required tightenings (after this doc lands)"
  rewritten as "Tightenings (implemented)" with a link to PR #82, since
  all six tightenings have landed. Issue-ref format updated to current
  E-series naming (#59 Sprint E5 → #59 E5).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Completion authority tightenings (E5 follow-up)

1 participant