@tokenoftrust/storefront-runner 2.2.27 → 2.2.29

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tokenoftrust/storefront-runner",
-  "version": "2.2.27",
+  "version": "2.2.29",
   "license": "SEE LICENSE IN LICENSE",
   "description": "World-shareable storefront runner: multi-tenant renderer on Astro/Cloudflare. No control plane.",
   "packageManager": "pnpm@11.9.0",

package/scripts/tenant/validate.mjs

@@ -624,11 +624,15 @@ export const LARGE_PUBLIC_ASSET_IDEA_ID = "fb-1790956035713-snpovm";
 export const LARGE_PUBLIC_ASSET_FIX =
   `storing it under public/ will work, but every publish re-copies it into R2 and ` +
   `your Gitea repo keeps it forever — on a tenant with many of these, expect ` +
-  `slower publishes and slower clones over time. Today, host it on a shared drive ` +
-  `you control and tell us the URL so we can pull it in and serve it from R2 directly, ` +
-  `rather than committing it to the tenant repo. We're tracking a built-in fix ` +
-  `(automatic relocation to deduped storage, idea ${LARGE_PUBLIC_ASSET_IDEA_ID}) — ` +
-  `vote for it if you'd like this handled for you sooner.`;
+  `slower publishes and slower clones over time. If this is an image, you don't ` +
+  `need to do anything extra: reference its public URL directly in your <img>/ ` +
+  `background-image/srcset and our capture step pulls it into CDN storage ` +
+  `automatically on publish. For a PDF or other non-image file, that auto-capture ` +
+  `doesn't apply yet — linking straight to an external URL avoids the repo-size ` +
+  `problem entirely, or send us the URL and we'll pull it in manually. We're ` +
+  `tracking a built-in fix to auto-relocate large files of any type the same way ` +
+  `images already work (idea ${LARGE_PUBLIC_ASSET_IDEA_ID}) — vote for it if ` +
+  `you'd like this handled for you sooner.`;
 
 /**
  * The advisory rules LOUD enough to call out by NAME at `tot validate` / `tot