Exercise 2: Why readonly_fields Still Matters for added_at — Possible Solution
====================================================================

WHY IT SEEMS REDUNDANT AT FIRST
------------------------------
Chapter 2's auto_now_add=True already implicitly sets editable=False on added_at, and Django's admin normally responds to a non-editable field by omitting it from the add/change form entirely - so it might seem like readonly_fields would have nothing left to do for a field that's already excluded from the form.

WHAT readonly_fields ACTUALLY ADDS
------------------------------
Per this chapter, listing added_at in readonly_fields keeps its current value visible - displayed read-only - directly in the admin's change form, rather than the field being invisible in that form altogether the way a plain non-editable field would otherwise be. In other words, editable=False alone hides the field from the form completely; adding it to readonly_fields specifically brings it back into view, just without allowing it to be edited.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that editable=False by itself would exclude added_at from the admin form entirely, and correctly identifies that readonly_fields exists specifically to make that value visible again in a read-only way, rather than being a redundant restatement of something already enforced.