Every item's install payload — the files under data/items/ and items/ — is now published into a timestamp-hashed folder (v/20260920b/) rather than a flat, permanent path. This is a different problem from the fetch recovery pattern above, and worth keeping distinct: that section is about a fetch tool correctly rejecting a URL it hasn't genuinely seen; this section is about a fetch tool serving stale content for a URL it has already cached, with no way for the fetching AI to detect that the content it received isn't actually current.
Why this exists: a real, repeated incident — not a hypothetical. AI fetch-tool-side caching (not this site's own hosting, not a CDN misconfiguration on this end) served content for FTR-01 that was weeks stale relative to what was actually live, including "Kevin Framework" branding and a personal contact email that had already been removed from the live site. A separate, independent Claude conversation, installing this feature into a real downstream project, had no way to know its fetch was stale — the fetch simply succeeded and returned content, and nothing about that response signaled staleness. It was reasonably about to ask its user whether to strip branding and contact info that, on the actual live site, didn't exist anymore.
Why a query string wasn't the fix: cache-busting via ?v=hash was tested directly against this exact problem, on this exact site, earlier in the same investigation — several different query-string values, tried in sequence, returned byte-identical stale content every time. Whatever layer was caching this clearly doesn't key on the query string. A version segment baked into the URL path is the only approach confirmed to force a genuinely new, never-before-cached URL — there is no possible stale cache entry for a path that has never existed before.
The scheme: the hash is timestamp-based (e.g. 20260920b — date, plus a letter suffix if more than one publish happens the same calendar day) rather than content-derived per file, since this project has no build tooling to compute per-file content hashes — one hash covers the whole payload set per publish. The current hash is tracked in admin\Site_Version.md, the single source of truth for what's actually live.
What's versioned, and what isn't: data/items/*.md and items/*.html — the actual install-payload content, the only place a stale fetch has real, concrete consequences (content written into someone's real project). index.html, browse.html, prerequisites.html, and this file's own hosted copy (data/index.md) stay at fixed, permanent URLs, re-uploaded fresh on every publish exactly as before. If one of those does go stale for a while after a publish, the failure mode is much smaller — an outdated feature list or version badge — than what versioning the payload URLs is specifically designed to prevent.
Why no feature file needed editing for this: every item file's own internal cross-references are relative links (e.g. FTR-06's own file linking to ../items/connectors-and-capabilities.md). Moving the whole data/items/ and items/ subtree into a version folder together required zero edits to any of the 34 feature files or 4 non-feature assets — every relative link continues to resolve correctly as long as both ends of a link move together, which they always do here, since the whole subtree moves as one atomic copy.
Publishing a change, going forward: whenever any feature file changes, generate a new hash (next calendar day, or the next letter suffix for a same-day republish), copy the current data/items/ and items/ folders into a fresh v/[new-hash]/ folder, update this file's own Full URLs table below and index.html/browse.html's copy-button JS to point at the new folder, update admin\Site_Version.md, then zip and upload feature_library_site\ as one folder exactly as always — the version folder is just another subfolder inside it, no separate deploy step required. Old version folders are left in place rather than deleted: they cost nothing (small text files), remain valid and internally self-consistent snapshots of a past publish, and could be useful if anything ever needs comparing against an earlier state.