Personal Catalogue: React & Firebase — Chapter 3, Exercise 2
=====================================================================

TASK
Explain why `allow read: if true` is a reasonable choice for this
specific app today, and name the exact condition under which it would
stop being reasonable.

SOLUTION

`allow read: if true` is reasonable right now because this app has no
concept of "someone else's data" to protect in the first place. It's a
single-user, personal cataloguing tool with no login and no
Authentication layer at all — every document in the `items` collection
belongs to the one person using the app, and nothing in the shared spec
stores anything more sensitive than "I own this book/CD/DVD/Blu-ray."
Restricting reads would need some notion of identity to restrict them
*to*, and this app deliberately has none, by the same decision made
back in Chapter 1 not to build user accounts for a tool this narrowly
scoped.

The condition that would change this answer is the addition of real
user identity to the app — either because it grows into a genuinely
multi-user tool (so one person's catalogue shouldn't be readable by
another), or because Firebase Authentication is added for some other
reason and the app starts storing anything meaningfully private per
user. At that point, `allow read: if true` would let anyone who can
reach the Firestore project read every user's data regardless of who
they are, which is exactly the failure mode Security Rules exist to
prevent. The fix at that point would be gating reads on
`request.auth.uid` matching a stored owner field on each document, the
same mechanism this chapter names the Food Tracker (React + Firebase)
sibling course reaching for once it adds Authentication.

WHY THIS WORKS AS AN ANSWER
----------------------------
It grounds the "reasonable today" half in this app's own real,
documented lack of any identity concept to protect (rather than a vague
"it's fine for now"), and names the precise, concrete trigger — real
user accounts or genuinely private per-user data — that would flip the
answer, along with the actual real mechanism (`request.auth.uid`) that
would need to replace it.