FounderCLI public evidence record: cache invalidation defect isolation

Snapshot revision: 98ac613c18c8d10b4fa2eee57c2c64c3ecd4b9f8
Source records: docs/DECISIONS.md decision 10 and docs/DEPLOY.md at the snapshot revision
Event date: 2026-08-17
Publisher: FounderCLI

Observed defect

After an article was unpublished through the application, its public article URL returned 404 and it disappeared from the journal index and RSS, but journal-sitemap.xml still listed it. Header and Footer edits made through Admin also failed to change the rendered site. The stale results survived a container restart because the Next.js data cache was stored on the container's writable layer.

Isolation method

The fault and candidate fix were reproduced against a restored copy of production with a matched control. revalidateTag(tag, "max") left the sitemap and Footer stale, while revalidateTag(tag, { expire: 0 }) invalidated both for the next request. revalidatePath worked in both trials, isolating the tag invalidation calls rather than the path invalidation calls.

Harness defects found during the trial

The first harness did not reliably kill the prior next start process, so one trial could inherit another trial's server. Rebuilding also retained .next/cache, so a new process could still inherit the previous cache entry. Both defects could produce confident before-and-after readings unrelated to the code under test.

Boundary

The result supports immediate tag expiry for the inspected Payload hook context. It does not establish a general Next.js caching rule, and a direct database write still bypasses application invalidation hooks entirely.