Exercise 1: Why the amount Column Uses STRICT — Possible Solution
====================================================================

WHAT THE CAPSTONE ACTUALLY DOES
------------------------------
Per this chapter, "both tables use STRICT — sqlite1-3's own opt-in
fix, applied here as a real design decision rather than an abstract
example: amount accidentally storing a text value instead of a number
would silently corrupt every later SUM()-based report, which is
exactly the class of bug STRICT exists to prevent at insert time."

CONNECTING THIS TO SQLITE1-3'S OWN TYPE AFFINITY MATERIAL
------------------------------
Per sqlite1-3, without STRICT, "a column declared INTEGER can still
end up storing a text string, if SQLite's own conversion rules can't
reasonably coerce the value — it's stored as-is." The same applies to
a REAL-affinity column like amount: without STRICT, a value that can't
be coerced to a number (perhaps due to an application bug, or a
malformed value from user input) would simply be stored as text
instead of being rejected, with no error raised at insert time.

A CONCRETE SCENARIO OF WHAT COULD GO WRONG WITHOUT STRICT
------------------------------
Imagine a bug in the application's own input-handling code
accidentally passes the string "12.5o" (a typo — an "o" instead of a
"0") to add_expense() instead of the intended value 12.50. Without
STRICT, this INSERT would succeed silently, storing "12.5o" as TEXT
in the amount column, since SQLite's own default type affinity system
only attempts coercion and falls back to storing the raw value when
coercion fails — exactly per sqlite1-3's own demonstrated 'five'
example. Then, per this chapter's own summary_by_category() query,
which runs SUM(expenses.amount), that single bad row would either
cause the SUM to behave unexpectedly (per sqlite1-3's own mixed-
storage-class sorting/comparison gotcha) or silently skip that value
in a way that produces a wrong total — corrupting the tool's entire
purpose (accurately summarizing expenses) without ever raising a
visible error.

WHY STRICT PREVENTS THIS
------------------------------
With STRICT applied, the same malformed insert attempt would be
rejected immediately at insert time with a real error, exactly as
sqlite1-3 demonstrated — the bug would surface immediately, at the
moment it's introduced, rather than silently corrupting a financial
summary the user might not notice until much later, if ever.

WHY THIS WORKS AS AN ANSWER
------------------------------
It ties the capstone's own STRICT usage back to sqlite1-3's own
type-affinity mechanism specifically, and constructs a concrete,
plausible failure scenario (a malformed amount value) showing exactly
how STRICT's insert-time rejection prevents a real, meaningful bug in
THIS specific application, rather than treating STRICT as a generic
best practice applied without justification.