Challenge 1 — Solution

Task: Explain why SB2's banner change was applied retroactively to all
five existing Sidebar pages, when P1 itself explicitly says banner
changes normally aren't retroactive. What made this case different?

P1's own default - that a banner-format change only applies to newly
generated files going forward, not files already written - exists
because retrofitting every already-generated file on a large site
would normally be a genuinely expensive undertaking, disproportionate
to the benefit of a formatting tweak. That's the assumption the default
is built around: many existing files, real cost to touch them all.

SB2's own situation didn't actually match that assumption. At the
exact moment the Category:/Subcategory: banner was decided, there were
only five Sidebar pages in existence across the entire site (the small
number itself a direct consequence of Sidebar being a very new,
just-created category at the time). Updating five files in the same
session is a small, cheap task, not a large one - so the normal
justification for P1's "not retroactive" default (the cost is too
high) simply didn't apply here. With the cost genuinely low and the
benefit of full internal consistency genuinely real, updating all five
in the same step was the better call, and was made and documented as
a deliberate, explicit exception rather than silently ignoring P1's
own default.

Notes:
- The chapter is careful to call this out as a real, DOCUMENTED
  exception, not a quiet override - SB2's own text explicitly says
  "Retroactive as of 2026-08-07," naming the exact five files affected,
  which is exactly the kind of transparency that keeps a rules system
  trustworthy even when it deviates from its own normal default.
- This is a good example of a rule's own general default (P1) still
  being the right baseline, while a specific situation genuinely
  warranting a different call gets handled as an explicit, reasoned
  exception rather than either blindly following the default or
  silently ignoring it.