Exercise 3: Why WAL Mode Was Deliberately Left Out — Possible Solution
====================================================================

WHAT THE SCOPE NOTE SAYS
------------------------------
Per this chapter's own scope note, "this capstone... deliberately does
not enable WAL mode from sqlite1-4 — a single-process CLI tool has no
meaningful concurrent-reader/writer scenario for WAL to improve, an
honest acknowledgment that not every chapter's own feature belongs in
every real project, the same pattern postgres1-12's own capstone set."

WHY WAL MODE DOESN'T APPLY HERE
------------------------------
Per sqlite1-4, WAL mode exists specifically to solve one problem:
allowing readers to keep reading a consistent snapshot of the database
WHILE a write is happening concurrently, rather than being blocked
until the write finishes. This only provides real value when there's
a genuine possibility of a read and a write genuinely overlapping in
time. A personal expense tracker run as a CLI tool is, by its own
nature, a single-process application — a single person runs one
command (add an expense, list expenses, view a summary) at a time from
their own terminal, and that command runs to completion before the
next one starts. There is no scenario in this specific application
where one process is reading the database while a genuinely separate,
concurrent process is simultaneously writing to it — the entire
premise WAL mode exists to improve simply doesn't arise here.

WHY THIS IS PRESENTED AS AN HONEST DESIGN CHOICE, NOT AN OVERSIGHT
------------------------------
The scope note explicitly frames this as a deliberate decision, not a
gap in the capstone's own coverage — it's presented as "an honest
acknowledgment that not every chapter's own feature belongs in every
real project." This mirrors the exact same pattern postgres1-12's own
capstone established: that course's own capstone left several
PostgreSQL-specific features (full-text search, replication) out of
its schema deliberately, explicitly stating that a real, well-designed
project reaches for only the features it genuinely needs, not
every feature a course happened to cover. Applying WAL mode here for
no real reason would actually work against this course's own stated
values — sqlite1-1's own "richness is a capability, not an obligation"-
style discipline (echoed from postgres1-3's own material) applies here
too: adding a feature because it exists, rather than because the
project actually needs it, isn't good design.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains precisely why WAL mode's own mechanism (helping concurrent
readers during a write) has no genuine application to a single-process
CLI tool, and explicitly names the parallel to postgres1-12's own
capstone to show this is a recurring, deliberate course-wide pattern
rather than an isolated excuse.