Captured from a real `mvn test -Dtest=FreezingArchRuleTest` run with no archunit_store/
directory present yet and freeze.store.default.allowStoreCreation=true in
src/test/resources/archunit.properties.

[INFO] Running com.ankurm.tutorials.junit.archunit.FreezingArchRuleTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.268 s -- in com.ankurm.tutorials.junit.archunit.FreezingArchRuleTest
[INFO] Results:
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[INFO] BUILD SUCCESS

The build is green even though LegacyOrderExporter.export() genuinely declares
`throws Exception` -- the one thing noMethods().should().declareThrowableOfType(Exception.class)
exists to ban. That's the point of freeze(): on this first run there was no stored
baseline yet, so FreezingArchRule recorded every violation it found right now as
"already known" and created the store on disk instead of failing. The store this
run produced, committed alongside this module:

archunit_store/stored.rules:
    #
    #Sun Oct 04 02:49:04 IST 2026
    no\ methods\ should\ declare\ throwable\ of\ type\ java.lang.Exception,\ because\ a\ specific\
    exception\ type\ documents\ what\ a\ caller\ actually\ has\ to\ handle;\ `throws\ Exception`\
    documents\ nothing=9e504a56-cf50-43d0-a977-82f8a097091b

archunit_store/9e504a56-cf50-43d0-a977-82f8a097091b:
    Method <com.ankurm.tutorials.junit.archunit.service.LegacyOrderExporter.export()> does
    declare throwable of type java.lang.Exception in (LegacyOrderExporter.java:14)

stored.rules maps one line per frozen rule (keyed by the rule's full description) to a
UUID; that UUID is also a filename holding the exact violation text frozen under it, in
the same format the live failure message uses. Delete that second file and the rule
forgets the violation was ever acceptable -- which is exactly how you make a frozen
violation start failing again once someone finally fixes it.