Exercise 3: Confirming Automatic Content-Hashed CSS Output — Possible Solution
====================================================================

RUNNING THE BUILD
------------------------------
Per this chapter, npx next build (or npm run build) compiles the
project, including every imported stylesheet - app/globals.css and
PageShell.module.css both end up bundled into .next/static/css/.

LOCATING THE OUTPUT
------------------------------
Listing the contents of .next/static/css/ shows filenames that are not
"globals.css" or "PageShell.module.css" - they're renamed to a hash
string plus a .css extension, e.g. something like a1b2c3d4e5f6.css,
with no human-readable trace of the original filename left in the
output.

CONFIRMING THE HASH CHANGES
------------------------------
Making a small, real change to one style rule (e.g. changing the
--accent value in app/globals.css) and re-running next build produces a
genuinely different hash for that file's own compiled output - the old
hashed filename is gone, replaced by a new one reflecting the new
content.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly locates the real build output rather than just trusting
the claim, and correctly demonstrates the hash is content-derived (it
changes when the content changes) rather than random or fixed per
build - directly confirming this chapter's own "automatic cache-busting"
claim, and the identical claim Express Rebuild's own Chapter 5 already
made about Next.js before this chapter existed to verify it.