Update to Brainerce
Snapshot Oct 24, 2026 · 18:05 UTC · version 2.0.4
Collection source: downloaded plugin package. These snapshots do not have a confirmed matching collection source. Differences in file lists alone do not establish changes to the package.
Payment or plan references changed
Skill instructions — Now says: '1.0.0' `references/required-features.md` is the checklist. Each entry is marked either MANDATORY or BUILD when the store has it enabled. Count them from the...
Observed in published text. Live prices and checkout terms have not been verified by this change.
Up to 10 plugins free · no card required.
All fields and original values.
Skill instructions
Sep 30, 2026 · 23:07 UTC
"1.0.0" `references/required-features.md` is the checklist. `references/business-flows.md` carries the sequences each feature has to follow, and `references/critical-rules.md` the rules that cause incidents. - `handlePaymentSuccess` foll...
Oct 24, 2026 · 18:05 UTC
'1.0.0' `references/required-features.md` is the checklist. Each entry is marked either MANDATORY or BUILD when the store has it enabled. Count them from the file rather than from memory, because entries get added: a number quoted here w...
Supporting files
Sep 30, 2026 · 23:07 UTC
[{"relative_path":"agents/openai.yaml","size_in_bytes":753},{"relative_path":"assets/icon.png","size_in_bytes":3208},{"relative_path":"references/business-flows.md","size_in_bytes":21739},{"relative_path":"references/critical-rules.md","...
Oct 24, 2026 · 18:05 UTC
[{"relative_path":"agents/openai.yaml","size_in_bytes":753},{"relative_path":"assets/icon.png","size_in_bytes":3208},{"relative_path":"references/required-features.md","size_in_bytes":70278}]
Compare saved observations
Download comparison JSONSKILL.md text changes
− removed · + added
--- before +++ after @@ -5,7 +5,7 @@ maintainer: Brainerce metadata: author: Brainerce - version: "1.0.0" + version: '1.0.0' --- Check a Brainerce integration honestly, feature by feature, against what is actually required. @@ -34,7 +34,7 @@ ### 1. Establish what is required -`references/required-features.md` is the checklist. `references/business-flows.md` carries the sequences each feature has to follow, and `references/critical-rules.md` the rules that cause incidents. +`references/required-features.md` is the checklist. Each entry is marked either MANDATORY or BUILD when the store has it enabled. Count them from the file rather than from memory, because entries get added: a number quoted here would be stale within the week. It is a functional coverage list, not a page list or a file tree, so audit each entry as a capability a customer can reach however the build lays it out. The sequences each feature has to follow are in `skills/brainerce-checkout-flows/references/business-flows.md`, and the rules that cause incidents in `skills/brainerce-storefront-build/references/critical-rules.md`, which is where each of those lives (this skill keeps no copy of either). Read them at those paths, or call `get-business-flows` and `get-critical-rules` when the MCP server is connected. When the Brainerce MCP server is connected (Claude Code, Cursor, or the CLI), `get-required-features` with the connection id returns the list tailored to that store's live configuration. Prefer that. In ChatGPT there is no connection, so use the reference file and say that the audit is against the general checklist rather than that specific store. @@ -46,48 +46,88 @@ Pay closest attention to the ones that are almost always skipped: +- **Regions and multi-currency, first and hardest.** Every other omission hides itself; this one does not. A storefront that never resolves a region renders the default region's prices to every customer on earth, and the page looks perfectly fine. Check that `getStoreRegions()` is called at all, and then that the resolved `regionId` reaches **every** product read **and** `createCheckout`. Passing it to the reads alone shows one price and charges another. - Email verification with a six-digit code - Forgot password and reset password - The OAuth button area and callback handling, including when no provider is currently enabled - Coupon input in the cart - The inventory reservation countdown, visible to the customer -- `handlePaymentSuccess` followed by `waitForOrder` on the confirmation page +- The payment step is one `client.startPayment()` call (no `renderType` / provider-name branching, no Stripe Elements or PayPal buttons, no hand-built payment iframe), with `session.destroy()` on unmount +- `/payment-complete` calls `relayPaymentReturn()`; `/order-confirmation` calls `completePaymentReturn(checkoutId)`, then `handlePaymentSuccess` on `'succeeded'` - Sitemap built with the dedicated SDK helpers rather than a plain product list - Slug-redirect handling on product and blog not-found paths +**Cart and checkout behaviour (R1 to R6).** These are not entries on the feature list: the cart can be present, reachable and still broken on a phone. Check them by reading the code, then confirm them by running the behaviour check in step 4. A store on an SDK older than 3.11.0 has no cart store, so the same rules apply to its `smart*` calls and are checked by hand: + +- **R1, no empty cart before the first answer.** Find the string the empty state renders and trace the condition that shows it. `cart === null`, `!cart?.items.length` or `items.length === 0` evaluated before the first answer is the bug: a shopper with items sees "empty" until the request lands. The view must render in this order: loading skeleton (sized from the remembered count, `hintCount`, with a cap), error with a retry button, empty, cart. A failed load drawn as empty, or a header badge that prints 0 until the answer arrives, is the same defect. +- **R2, no full-page reloads between store pages.** `grep` for `<a href=` to an internal path and for `window.location.href`, `location.assign` and `location.replace` used to move around the store. Check the header, footer, menu items, announcement bar and product cards: links that come from merchant content (`item.url`) are the usual leak. Router links only; a plain anchor is for external URLs, `mailto:`, `tel:`, `#anchors` and `target="_blank"`. +- **R3, the returned cart is the cart.** Look for a cart write followed by a read (`smartAddToCart` then `smartGetCart`, `addToCart` then `getCart`, an `await write(); await refresh()` pair) and for the cart copied into the app's own state. On SDK 3.11.0 or newer (read `package.json`) the UI should sit on `createCartStore` or `CartProvider` and `useCart` from `brainerce/react`, change a line by `CartItem.id` and not by product, and the checkout button should `await flush()` (an older SDK: the last pending write) before it navigates. A bare link to `/checkout` skips that wait. +- **R4, the Vercel function region.** If the project deploys to Vercel, `vercel.json` sets the function region to `fra1`, next to the Brainerce API (the default `iad1` adds roughly 300 to 450 ms to every proxied call). This is the hosting region, not the commerce regions above. +- **R5, nothing floats over the cart or the checkout fields.** Chat bubbles, WhatsApp buttons, cookie bars and the storefront bot are not mounted on `/cart` and `/checkout`; the primary button under the order total is Checkout, not "Continue shopping"; a phone gets a sticky checkout bar on the cart page; the site header and footer are hidden on checkout. +- **R6, autofill tokens.** Every checkout input has `autocomplete` (`email`, `given-name`, `family-name`, `tel`, `postal-code`, `address-level1`, `address-level2`, `address-line1`, `address-line2`, `country`), a `name`, and `inputmode` for email and phone. The one allowed exception is address line 1 when it is the Places typeahead: that input is `autocomplete="off"`. + +Newer entries on the checklist, skipped most often because older builds predate them: + +- An estimated tax line before checkout, rendered only when `appliesTax` is true, labelled an estimate, and showing the returned `note` +- Loyalty: points, referrals, badges, and paid membership +- Saved payment methods: a customer saving a card and seeing their saved cards +- Order bumps at checkout and bundle offers in the cart +- A contact form that files a real inquiry, and email newsletter signup, both as real submissions rather than a mailto or a dead input +- A back-in-stock alert on a sold-out product, and the low-stock badge on product detail. `getStockStatus` defaults `lowStockThreshold` to 0, so a build that never passes it silently ignores the threshold the merchant configured and the badge never appears. +- The gift-card field at checkout: applying a code, seeing what it paid, removing it, and applying more than one. Check the rendering as hard as the wiring, because a field that works and is drawn inside the discount block is still wrong. +- The saved address book inside the account area, not only the checkout address form. It has no capability flag and is always on, so there is no store setting that excuses leaving it out. Check that checkout prefills from the default address too. + ### 3. Check the critical rules against the code - Prices parsed before arithmetic, everywhere, including totals - Nested and flat line-item shapes handled as they actually arrive - No auth token in browser storage without a backend-for-frontend - No hardcoded currency, locale or store id -- No invented SDK methods +- `regionId` reaching `createCheckout`, not only the product reads. Half-wired is worse than unwired: the customer is shown one price and charged another. +- No invented SDK methods. Wishlists have no SDK surface, so a call that looks like one is a fabrication, not a version gap. **Subscriptions are no longer in that category:** paid membership ships as `getMembershipPlans`, `subscribeToMembership` and `cancelMembership`, and it is a mandatory feature — flagging those three as invented tells a developer to delete working code. What is still absent is a self-serve subscription CHECKOUT: recurring PLANS are configured by the merchant, and there is no storefront API to start one. **Gift cards are the opposite case and the one to get right in both directions:** `applyGiftCard`, `removeGiftCard` and `checkGiftCardBalance` are real, so do not flag them as invented, and a build that omits the redemption field is missing a mandatory feature rather than declining an optional one. +- No gift card folded into `discountAmount` or rendered inside the discount block. It is a tender, not a discount: `total` is unchanged and tax is calculated on it, so the card belongs on its own line below the total with an "Amount due" row underneath. A build that discounts it misstates the taxable base to the shopper and on the receipt, which is a correctness bug rather than a styling one. +- The six cart and checkout behaviour rules above (R1 to R6), each cited with a file and line like any other finding. They are critical rules in `skills/brainerce-storefront-build/references/critical-rules.md`, and a violation is a critical rule violation in the report. + +### 4. Run the behaviour check against the running store + +Reading code proves the rules are followed on paper. A script proves the store behaves. Brainerce publishes one that drives a real browser through any storefront (the starter, a store built by an AI tool, localhost or a live shop) and never judges design: + +The script ships inside the storefront starter. A store scaffolded by the `create-brainerce-store` release that includes the cart store (it needs SDK 3.11.0 or newer) already has it as `scripts/verify-storefront.mjs`, and the developer runs it from the project with `npm run verify:storefront -- --url http://localhost:3000 --viewport 390x844 --slow`. Do not download the script, fetch it from a URL or run anything that is not already in the project. For a store that was not scaffolded that way, tell the developer that the same script is published at brainerce.com/verify-storefront.mjs and that fetching and running it is their own step, then audit by reading code. Run it twice: once as a phone (`--viewport 390x844 --slow`, and `--locale he-IL` for a right-to-left store, or the store's own locale tag), once as a desktop with no flags. It adds items to an anonymous cart in a throwaway browser profile and opens the checkout page; it never submits an order, never enters payment details and never logs in. `--only a,b` runs named checks. A FAIL makes it exit with code 1; a WARN is worth fixing and does not. + +What the checks look at, by id: `nav-no-reload` (header links move between pages without a full reload), `add-requests` (adding to the cart is one request and the response is the cart), `cart-first-paint` (the cart page never shows "empty" or zero totals before the real cart arrives), `burst-taps` (quick taps on `+` end on the right quantity in few requests), `write-failure` (a failed update rolls back and tells the shopper), `load-failure` (a failed cart load shows an error with a retry, not "empty" and not an endless spinner), `checkout-waits` (checkout waits for a pending cart update), `floaters-overlap` (no popup, chat or widget covers a cart control or a form field), `checkout-fields` (email, phone and name inputs carry `autocomplete`) and `no-overflow` (no horizontal overflow on home, product, cart and checkout). Report each FAIL and WARN with its id and the file that causes it, as findings in the matching state below. -### 4. Report, then fix only what is approved +It needs a running store, a shell and a Chromium build. When you have none of those (ChatGPT, no deployed URL, no permission to start a dev server), skip it, and say in the report that the behaviour of the cart was audited by reading code only. Run it against a deployed URL or one the user already has running; start a dev server yourself only because the user asked for the audit, and keep it to this one pass. + +### 5. Report, then fix only what is approved ## Report shape Three states, and use all three. A report that is all ticks was not an audit. -> ✓ Audit of your Brainerce integration. 14 of 19 mandatory features are reachable. +> ✓ Audit of your Brainerce integration. 24 of the 34 mandatory features are reachable. > > **Implemented and reachable** +> > - Product listing, product detail with variants, cart with persistence > - Checkout through payment, with the reservation countdown visible > - Registration and login > - Order confirmation > > **Present but broken or unreachable** +> > - `ResetPasswordForm.tsx` exists and no route renders it. A customer who forgets their password has no way in. `src/components/auth/ResetPasswordForm.tsx` > - Coupon input is in the cart component but is behind a flag that is never set. `src/components/cart/CartSummary.tsx:82` > > **Missing** +> > - Email verification. Registration completes and the account cannot be used. This is mandatory. > - OAuth button area. The store has no providers today, so it looks unnecessary, but the owner enabling Google later would need a code change. > - Sitemap uses `getProducts({ limit: 1000 })`, which the API caps at 100. Your sitemap silently lists 100 products. > > **Critical rule violations** +> > - `src/lib/totals.ts:14` adds `item.price` without parsing. Prices are strings, so this concatenates. +> - `src/components/Cart.tsx:31` renders "Your cart is empty" whenever `cart` is null, which is every render until the API answers (R1). The behaviour check agrees: `cart-first-paint` FAIL. > > Want me to start with email verification? It is the one that blocks real customers today. @@ -98,7 +138,7 @@ - Use all three states. "Present but unreachable" is the most useful finding and the one a shallow check misses. - Never mark a mandatory feature not applicable because the store has it disabled. - Report before fixing, and fix only what the developer approves. -- Say what you could not check, and why. An audit that quietly skipped the payment path is worse than one that says it did. +- Say what you could not check, and why. An audit that quietly skipped the payment path is worse than one that says it did. The same goes for the behaviour check: if you did not run it, say so, rather than letting a clean code read stand in for a clean run. - Order findings by what blocks a real customer today, not by checklist order. ## Cross-skill connections
Full technical diff · 2 changed fields
changed /included_files
[
{
"relative_path": "agents/openai.yaml",
"size_in_bytes": 753
},
{
"relative_path": "assets/icon.png",
"size_in_bytes": 3208
},
{
"relative_path": "references/business-flows.md",
"size_in_bytes": 21739
},
{
"relative_path": "references/critical-rules.md",
"size_in_bytes": 7087
},
{
"relative_path": "references/required-features.md",
"size_in_bytes": 20554
}
][
{
"relative_path": "agents/openai.yaml",
"size_in_bytes": 753
},
{
"relative_path": "assets/icon.png",
"size_in_bytes": 3208
},
{
"relative_path": "references/required-features.md",
"size_in_bytes": 70278
}
]changed /skill_md_contents
"---\nname: brainerce-integration-verify\ndescription: \"Audit a Brainerce storefront against the mandatory-feature checklist and the critical rules, and report what is missing, present but unreachable, or wrong. Use when a developer says is my integration complete, check my Brainerce build, did I miss anything, review this before launch, why is this feature not working, or before shipping a storefront to a real store owner. Walks the actual code rather than trusting that a file exists, with particular attention to the features that are almost always skipped. For developers. Do not choose this to build something new, use brainerce-storefront-build. Do not choose this for one method's signature, use brainerce-sdk. Do not choose this for the correct order of a checkout or login sequence while writing it, use brainerce-checkout-flows. Do not choose this for a merchant auditing their shop's products and promotions, that is brainerce-store-health. Keywords: verify, audit, checklist, did I miss anything, pre-launch, mandatory features, critical rules, ready to ship.\"\ncompatibility: ChatGPT, Claude Code, Claude Desktop, Cursor\nmaintainer: Brainerce\nmetadata:\n author: Brainerce\n version: \"1.0.0\"\n---\n\nCheck a Brainerce integration honestly, feature by feature, against what is actually required.\n\n## Core principle\n\nReachable in the running UI, or it does not count. A component that exists in the repo but no route renders is not an implemented feature, and reporting it as one is how storefronts ship with no password reset. Walk the code and trace each feature to something a customer can actually get to.\n\n## When to use this skill first\n\n- \"Is my integration complete\", \"did I miss anything\", \"check this before launch\".\n- Handing a build to a real store owner.\n- \"This feature is not working and I do not know why\".\n- After following `brainerce-storefront-build`, as the closing step.\n\n## When NOT to use this skill first\n\n- Building something new: use `brainerce-storefront-build`.\n- One method's signature: use `brainerce-sdk`.\n- Getting a sequence right while writing it: use `brainerce-checkout-flows`.\n- A shop owner auditing products and promotions in their store: that is `brainerce-store-health`, a merchant skill on a different tool surface.\n\n---\n\n## How to run the audit\n\n### 1. Establish what is required\n\n`references/required-features.md` is the checklist. `references/business-flows.md` carries the sequences each feature has to follow, and `references/critical-rules.md` the rules that cause incidents.\n\nWhen the Brainerce MCP server is connected (Claude Code, Cursor, or the CLI), `get-required-features` with the connection id returns the list tailored to that store's live configuration. Prefer that. In ChatGPT there is no connection, so use the reference file and say that the audit is against the general checklist rather than that specific store.\n\n⛔ **Mandatory features must exist even when the store has them switched off today.** They auto-hide, and the owner turns them on months later without touching the code. A build that omits them is not complete, it is a delayed outage. Do not mark a feature as not applicable because the store currently has it disabled.\n\n### 2. Walk the code, feature by feature\n\nFor each item, find the code, then find the route or component that makes it reachable. Both, not either.\n\nPay closest attention to the ones that are almost always skipped:\n\n- Email verification with a six-digit code\n- Forgot password and reset password\n- The OAuth button area and callback handling, including when no provider is currently enabled\n- Coupon input in the cart\n- The inventory reservation countdown, visible to the customer\n- `handlePaymentSuccess` followed by `waitForOrder` on the confirmation page\n- Sitemap built with the dedicated SDK helpers rather than a plain product list\n- Slug-redirect handling on product and blog not-found paths\n\n### 3. Check the critical rules against the code\n\n- Prices parsed before arithmetic, everywhere, including totals\n- Nested and flat line-item shapes handled as they actually arrive\n- No auth token in browser storage without a backend-for-frontend\n- No hardcoded currency, locale or store id\n- No invented SDK methods\n\n### 4. Report, then fix only what is approved\n\n## Report shape\n\nThree states, and use all three. A report that is all ticks was not an audit.\n\n> ✓ Audit of your Brainerce integration. 14 of 19 mandatory features are reachable.\n>\n> **Implemented and reachable**\n> - Product listing, product detail with variants, cart with persistence\n> - Checkout through payment, with the reservation countdown visible\n> - Registration and login\n> - Order confirmation\n>\n> **Present but broken or unreachable**\n> - `ResetPasswordForm.tsx` exists and no route renders it. A customer who forgets their password has no way in. `src/components/auth/ResetPasswordForm.tsx`\n> - Coupon input is in the cart component but is behind a flag that is never set. `src/components/cart/CartSummary.tsx:82`\n>\n> **Missing**\n> - Email verification. Registration completes and the account cannot be used. This is mandatory.\n> - OAuth button area. The store has no providers today, so it looks unnecessary, but the owner enabling Google later would need a code change.\n> - Sitemap uses `getProducts({ limit: 1000 })`, which the API caps at 100. Your sitemap silently lists 100 products.\n>\n> **Critical rule violations**\n> - `src/lib/totals.ts:14` adds `item.price` without parsing. Prices are strings, so this concatenates.\n>\n> Want me to start with email verification? It is the one that blocks real customers today.\n\n## Rules\n\n- Trace every feature to something reachable. A file is not a feature.\n- Cite file paths and line numbers. An audit without references cannot be acted on.\n- Use all three states. \"Present but unreachable\" is the most useful finding and the one a shallow check misses.\n- Never mark a mandatory feature not applicable because the store has it disabled.\n- Report before fixing, and fix only what the developer approves.\n- Say what you could not check, and why. An audit that quietly skipped the payment path is worse than one that says it did.\n- Order findings by what blocks a real customer today, not by checklist order.\n\n## Cross-skill connections\n\n- Building what the audit found missing: `brainerce-storefront-build`.\n- Getting a sequence right while fixing it: `brainerce-checkout-flows`.\n- A method signature you need mid-fix: `brainerce-sdk`.\n\nRoute once, and do not bounce back and forth.\n""---\nname: brainerce-integration-verify\ndescription: \"Audit a Brainerce storefront against the mandatory-feature checklist and the critical rules, and report what is missing, present but unreachable, or wrong. Use when a developer says is my integration complete, check my Brainerce build, did I miss anything, review this before launch, why is this feature not working, or before shipping a storefront to a real store owner. Walks the actual code rather than trusting that a file exists, with particular attention to the features that are almost always skipped. For developers. Do not choose this to build something new, use brainerce-storefront-build. Do not choose this for one method's signature, use brainerce-sdk. Do not choose this for the correct order of a checkout or login sequence while writing it, use brainerce-checkout-flows. Do not choose this for a merchant auditing their shop's products and promotions, that is brainerce-store-health. Keywords: verify, audit, checklist, did I miss anything, pre-launch, mandatory features, critical rules, ready to ship.\"\ncompatibility: ChatGPT, Claude Code, Claude Desktop, Cursor\nmaintainer: Brainerce\nmetadata:\n author: Brainerce\n version: '1.0.0'\n---\n\nCheck a Brainerce integration honestly, feature by feature, against what is actually required.\n\n## Core principle\n\nReachable in the running UI, or it does not count. A component that exists in the repo but no route renders is not an implemented feature, and reporting it as one is how storefronts ship with no password reset. Walk the code and trace each feature to something a customer can actually get to.\n\n## When to use this skill first\n\n- \"Is my integration complete\", \"did I miss anything\", \"check this before launch\".\n- Handing a build to a real store owner.\n- \"This feature is not working and I do not know why\".\n- After following `brainerce-storefront-build`, as the closing step.\n\n## When NOT to use this skill first\n\n- Building something new: use `brainerce-storefront-build`.\n- One method's signature: use `brainerce-sdk`.\n- Getting a sequence right while writing it: use `brainerce-checkout-flows`.\n- A shop owner auditing products and promotions in their store: that is `brainerce-store-health`, a merchant skill on a different tool surface.\n\n---\n\n## How to run the audit\n\n### 1. Establish what is required\n\n`references/required-features.md` is the checklist. Each entry is marked either MANDATORY or BUILD when the store has it enabled. Count them from the file rather than from memory, because entries get added: a number quoted here would be stale within the week. It is a functional coverage list, not a page list or a file tree, so audit each entry as a capability a customer can reach however the build lays it out. The sequences each feature has to follow are in `skills/brainerce-checkout-flows/references/business-flows.md`, and the rules that cause incidents in `skills/brainerce-storefront-build/references/critical-rules.md`, which is where each of those lives (this skill keeps no copy of either). Read them at those paths, or call `get-business-flows` and `get-critical-rules` when the MCP server is connected.\n\nWhen the Brainerce MCP server is connected (Claude Code, Cursor, or the CLI), `get-required-features` with the connection id returns the list tailored to that store's live configuration. Prefer that. In ChatGPT there is no connection, so use the reference file and say that the audit is against the general checklist rather than that specific store.\n\n⛔ **Mandatory features must exist even when the store has them switched off today.** They auto-hide, and the owner turns them on months later without touching the code. A build that omits them is not complete, it is a delayed outage. Do not mark a feature as not applicable because the store currently has it disabled.\n\n### 2. Walk the code, feature by feature\n\nFor each item, find the code, then find the route or component that makes it reachable. Both, not either.\n\nPay closest attention to the ones that are almost always skipped:\n\n- **Regions and multi-currency, first and hardest.** Every other omission hides itself; this one does not. A storefront that never resolves a region renders the default region's prices to every customer on earth, and the page looks perfectly fine. Check that `getStoreRegions()` is called at all, and then that the resolved `regionId` reaches **every** product read **and** `createCheckout`. Passing it to the reads alone shows one price and charges another.\n- Email verification with a six-digit code\n- Forgot password and reset password\n- The OAuth button area and callback handling, including when no provider is currently enabled\n- Coupon input in the cart\n- The inventory reservation countdown, visible to the customer\n- The payment step is one `client.startPayment()` call (no `renderType` / provider-name branching, no Stripe Elements or PayPal buttons, no hand-built payment iframe), with `session.destroy()` on unmount\n- `/payment-complete` calls `relayPaymentReturn()`; `/order-confirmation` calls `completePaymentReturn(checkoutId)`, then `handlePaymentSuccess` on `'succeeded'`\n- Sitemap built with the dedicated SDK helpers rather than a plain product list\n- Slug-redirect handling on product and blog not-found paths\n\n**Cart and checkout behaviour (R1 to R6).** These are not entries on the feature list: the cart can be present, reachable and still broken on a phone. Check them by reading the code, then confirm them by running the behaviour check in step 4. A store on an SDK older than 3.11.0 has no cart store, so the same rules apply to its `smart*` calls and are checked by hand:\n\n- **R1, no empty cart before the first answer.** Find the string the empty state renders and trace the condition that shows it. `cart === null`, `!cart?.items.length` or `items.length === 0` evaluated before the first answer is the bug: a shopper with items sees \"empty\" until the request lands. The view must render in this order: loading skeleton (sized from the remembered count, `hintCount`, with a cap), error with a retry button, empty, cart. A failed load drawn as empty, or a header badge that prints 0 until the answer arrives, is the same defect.\n- **R2, no full-page reloads between store pages.** `grep` for `<a href=` to an internal path and for `window.location.href`, `location.assign` and `location.replace` used to move around the store. Check the header, footer, menu items, announcement bar and product cards: links that come from merchant content (`item.url`) are the usual leak. Router links only; a plain anchor is for external URLs, `mailto:`, `tel:`, `#anchors` and `target=\"_blank\"`.\n- **R3, the returned cart is the cart.** Look for a cart write followed by a read (`smartAddToCart` then `smartGetCart`, `addToCart` then `getCart`, an `await write(); await refresh()` pair) and for the cart copied into the app's own state. On SDK 3.11.0 or newer (read `package.json`) the UI should sit on `createCartStore` or `CartProvider` and `useCart` from `brainerce/react`, change a line by `CartItem.id` and not by product, and the checkout button should `await flush()` (an older SDK: the last pending write) before it navigates. A bare link to `/checkout` skips that wait.\n- **R4, the Vercel function region.** If the project deploys to Vercel, `vercel.json` sets the function region to `fra1`, next to the Brainerce API (the default `iad1` adds roughly 300 to 450 ms to every proxied call). This is the hosting region, not the commerce regions above.\n- **R5, nothing floats over the cart or the checkout fields.** Chat bubbles, WhatsApp buttons, cookie bars and the storefront bot are not mounted on `/cart` and `/checkout`; the primary button under the order total is Checkout, not \"Continue shopping\"; a phone gets a sticky checkout bar on the cart page; the site header and footer are hidden on checkout.\n- **R6, autofill tokens.** Every checkout input has `autocomplete` (`email`, `given-name`, `family-name`, `tel`, `postal-code`, `address-level1`, `address-level2`, `address-line1`, `address-line2`, `country`), a `name`, and `inputmode` for email and phone. The one allowed exception is address line 1 when it is the Places typeahead: that input is `autocomplete=\"off\"`.\n\nNewer entries on the checklist, skipped most often because older builds predate them:\n\n- An estimated tax line before checkout, rendered only when `appliesTax` is true, labelled an estimate, and showing the returned `note`\n- Loyalty: points, referrals, badges, and paid membership\n- Saved payment methods: a customer saving a card and seeing their saved cards\n- Order bumps at checkout and bundle offers in the cart\n- A contact form that files a real inquiry, and email newsletter signup, both as real submissions rather than a mailto or a dead input\n- A back-in-stock alert on a sold-out product, and the low-stock badge on product detail. `getStockStatus` defaults `lowStockThreshold` to 0, so a build that never passes it silently ignores the threshold the merchant configured and the badge never appears.\n- The gift-card field at checkout: applying a code, seeing what it paid, removing it, and applying more than one. Check the rendering as hard as the wiring, because a field that works and is drawn inside the discount block is still wrong.\n- The saved address book inside the account area, not only the checkout address form. It has no capability flag and is always on, so there is no store setting that excuses leaving it out. Check that checkout prefills from the default address too.\n\n### 3. Check the critical rules against the code\n\n- Prices parsed before arithmetic, everywhere, including totals\n- Nested and flat line-item shapes handled as they actually arrive\n- No auth token in browser storage without a backend-for-frontend\n- No hardcoded currency, locale or store id\n- `regionId` reaching `createCheckout`, not only the product reads. Half-wired is worse than unwired: the customer is shown one price and charged another.\n- No invented SDK methods. Wishlists have no SDK surface, so a call that looks like one is a fabrication, not a version gap. **Subscriptions are no longer in that category:** paid membership ships as `getMembershipPlans`, `subscribeToMembership` and `cancelMembership`, and it is a mandatory feature — flagging those three as invented tells a developer to delete working code. What is still absent is a self-serve subscription CHECKOUT: recurring PLANS are configured by the merchant, and there is no storefront API to start one. **Gift cards are the opposite case and the one to get right in both directions:** `applyGiftCard`, `removeGiftCard` and `checkGiftCardBalance` are real, so do not flag them as invented, and a build that omits the redemption field is missing a mandatory feature rather than declining an optional one.\n- No gift card folded into `discountAmount` or rendered inside the discount block. It is a tender, not a discount: `total` is unchanged and tax is calculated on it, so the card belongs on its own line below the total with an \"Amount due\" row underneath. A build that discounts it misstates the taxable base to the shopper and on the receipt, which is a correctness bug rather than a styling one.\n- The six cart and checkout behaviour rules above (R1 to R6), each cited with a file and line like any other finding. They are critical rules in `skills/brainerce-storefront-build/references/critical-rules.md`, and a violation is a critical rule violation in the report.\n\n### 4. Run the behaviour check against the running store\n\nReading code proves the rules are followed on paper. A script proves the store behaves. Brainerce publishes one that drives a real browser through any storefront (the starter, a store built by an AI tool, localhost or a live shop) and never judges design:\n\nThe script ships inside the storefront starter. A store scaffolded by the `create-brainerce-store` release that includes the cart store (it needs SDK 3.11.0 or newer) already has it as `scripts/verify-storefront.mjs`, and the developer runs it from the project with `npm run verify:storefront -- --url http://localhost:3000 --viewport 390x844 --slow`. Do not download the script, fetch it from a URL or run anything that is not already in the project. For a store that was not scaffolded that way, tell the developer that the same script is published at brainerce.com/verify-storefront.mjs and that fetching and running it is their own step, then audit by reading code. Run it twice: once as a phone (`--viewport 390x844 --slow`, and `--locale he-IL` for a right-to-left store, or the store's own locale tag), once as a desktop with no flags. It adds items to an anonymous cart in a throwaway browser profile and opens the checkout page; it never submits an order, never enters payment details and never logs in. `--only a,b` runs named checks. A FAIL makes it exit with code 1; a WARN is worth fixing and does not.\n\nWhat the checks look at, by id: `nav-no-reload` (header links move between pages without a full reload), `add-requests` (adding to the cart is one request and the response is the cart), `cart-first-paint` (the cart page never shows \"empty\" or zero totals before the real cart arrives), `burst-taps` (quick taps on `+` end on the right quantity in few requests), `write-failure` (a failed update rolls back and tells the shopper), `load-failure` (a failed cart load shows an error with a retry, not \"empty\" and not an endless spinner), `checkout-waits` (checkout waits for a pending cart update), `floaters-overlap` (no popup, chat or widget covers a cart control or a form field), `checkout-fields` (email, phone and name inputs carry `autocomplete`) and `no-overflow` (no horizontal overflow on home, product, cart and checkout). Report each FAIL and WARN with its id and the file that causes it, as findings in the matching state below.\n\nIt needs a running store, a shell and a Chromium build. When you have none of those (ChatGPT, no deployed URL, no permission to start a dev server), skip it, and say in the report that the behaviour of the cart was audited by reading code only. Run it against a deployed URL or one the user already has running; start a dev server yourself only because the user asked for the audit, and keep it to this one pass.\n\n### 5. Report, then fix only what is approved\n\n## Report shape\n\nThree states, and use all three. A report that is all ticks was not an audit.\n\n> ✓ Audit of your Brainerce integration. 24 of the 34 mandatory features are reachable.\n>\n> **Implemented and reachable**\n>\n> - Product listing, product detail with variants, cart with persistence\n> - Checkout through payment, with the reservation countdown visible\n> - Registration and login\n> - Order confirmation\n>\n> **Present but broken or unreachable**\n>\n> - `ResetPasswordForm.tsx` exists and no route renders it. A customer who forgets their password has no way in. `src/components/auth/ResetPasswordForm.tsx`\n> - Coupon input is in the cart component but is behind a flag that is never set. `src/components/cart/CartSummary.tsx:82`\n>\n> **Missing**\n>\n> - Email verification. Registration completes and the account cannot be used. This is mandatory.\n> - OAuth button area. The store has no providers today, so it looks unnecessary, but the owner enabling Google later would need a code change.\n> - Sitemap uses `getProducts({ limit: 1000 })`, which the API caps at 100. Your sitemap silently lists 100 products.\n>\n> **Critical rule violations**\n>\n> - `src/lib/totals.ts:14` adds `item.price` without parsing. Prices are strings, so this concatenates.\n> - `src/components/Cart.tsx:31` renders \"Your cart is empty\" whenever `cart` is null, which is every render until the API answers (R1). The behaviour check agrees: `cart-first-paint` FAIL.\n>\n> Want me to start with email verification? It is the one that blocks real customers today.\n\n## Rules\n\n- Trace every feature to something reachable. A file is not a feature.\n- Cite file paths and line numbers. An audit without references cannot be acted on.\n- Use all three states. \"Present but unreachable\" is the most useful finding and the one a shallow check misses.\n- Never mark a mandatory feature not applicable because the store has it disabled.\n- Report before fixing, and fix only what the developer approves.\n- Say what you could not check, and why. An audit that quietly skipped the payment path is worse than one that says it did. The same goes for the behaviour check: if you did not run it, say so, rather than letting a clean code read stand in for a clean run.\n- Order findings by what blocks a real customer today, not by checklist order.\n\n## Cross-skill connections\n\n- Building what the audit found missing: `brainerce-storefront-build`.\n- Getting a sequence right while fixing it: `brainerce-checkout-flows`.\n- A method signature you need mid-fix: `brainerce-sdk`.\n\nRoute once, and do not bounce back and forth.\n"Full snapshot data
{
"description": "Audit a Brainerce storefront against the mandatory-feature checklist and the critical rules, and report what is missing, present but unreachable, or wrong. Use when a developer says is my integration complete, check my Brainerce build, did I miss anything, review this before launch, why is this feature not working, or before shipping a storefront to a real store owner. Walks the actual code rather than trusting that a file exists, with particular attention to the features that are almost always skipped. For developers. Do not choose this to build something new, use brainerce-storefront-build. Do not choose this for one method's signature, use brainerce-sdk. Do not choose this for the correct order of a checkout or login sequence while writing it, use brainerce-checkout-flows. Do not choose this for a merchant auditing their shop's products and promotions, that is brainerce-store-health. Keywords: verify, audit, checklist, did I miss anything, pre-launch, mandatory features, critical rules, ready to ship.",
"included_files": [
{
"relative_path": "agents/openai.yaml",
"size_in_bytes": 753
},
{
"relative_path": "assets/icon.png",
"size_in_bytes": 3208
},
{
"relative_path": "references/required-features.md",
"size_in_bytes": 70278
}
],
"name": "brainerce-integration-verify",
"skill_md_contents": "---\nname: brainerce-integration-verify\ndescription: \"Audit a Brainerce storefront against the mandatory-feature checklist and the critical rules, and report what is missing, present but unreachable, or wrong. Use when a developer says is my integration complete, check my Brainerce build, did I miss anything, review this before launch, why is this feature not working, or before shipping a storefront to a real store owner. Walks the actual code rather than trusting that a file exists, with particular attention to the features that are almost always skipped. For developers. Do not choose this to build something new, use brainerce-storefront-build. Do not choose this for one method's signature, use brainerce-sdk. Do not choose this for the correct order of a checkout or login sequence while writing it, use brainerce-checkout-flows. Do not choose this for a merchant auditing their shop's products and promotions, that is brainerce-store-health. Keywords: verify, audit, checklist, did I miss anything, pre-launch, mandatory features, critical rules, ready to ship.\"\ncompatibility: ChatGPT, Claude Code, Claude Desktop, Cursor\nmaintainer: Brainerce\nmetadata:\n author: Brainerce\n version: '1.0.0'\n---\n\nCheck a Brainerce integration honestly, feature by feature, against what is actually required.\n\n## Core principle\n\nReachable in the running UI, or it does not count. A component that exists in the repo but no route renders is not an implemented feature, and reporting it as one is how storefronts ship with no password reset. Walk the code and trace each feature to something a customer can actually get to.\n\n## When to use this skill first\n\n- \"Is my integration complete\", \"did I miss anything\", \"check this before launch\".\n- Handing a build to a real store owner.\n- \"This feature is not working and I do not know why\".\n- After following `brainerce-storefront-build`, as the closing step.\n\n## When NOT to use this skill first\n\n- Building something new: use `brainerce-storefront-build`.\n- One method's signature: use `brainerce-sdk`.\n- Getting a sequence right while writing it: use `brainerce-checkout-flows`.\n- A shop owner auditing products and promotions in their store: that is `brainerce-store-health`, a merchant skill on a different tool surface.\n\n---\n\n## How to run the audit\n\n### 1. Establish what is required\n\n`references/required-features.md` is the checklist. Each entry is marked either MANDATORY or BUILD when the store has it enabled. Count them from the file rather than from memory, because entries get added: a number quoted here would be stale within the week. It is a functional coverage list, not a page list or a file tree, so audit each entry as a capability a customer can reach however the build lays it out. The sequences each feature has to follow are in `skills/brainerce-checkout-flows/references/business-flows.md`, and the rules that cause incidents in `skills/brainerce-storefront-build/references/critical-rules.md`, which is where each of those lives (this skill keeps no copy of either). Read them at those paths, or call `get-business-flows` and `get-critical-rules` when the MCP server is connected.\n\nWhen the Brainerce MCP server is connected (Claude Code, Cursor, or the CLI), `get-required-features` with the connection id returns the list tailored to that store's live configuration. Prefer that. In ChatGPT there is no connection, so use the reference file and say that the audit is against the general checklist rather than that specific store.\n\n⛔ **Mandatory features must exist even when the store has them switched off today.** They auto-hide, and the owner turns them on months later without touching the code. A build that omits them is not complete, it is a delayed outage. Do not mark a feature as not applicable because the store currently has it disabled.\n\n### 2. Walk the code, feature by feature\n\nFor each item, find the code, then find the route or component that makes it reachable. Both, not either.\n\nPay closest attention to the ones that are almost always skipped:\n\n- **Regions and multi-currency, first and hardest.** Every other omission hides itself; this one does not. A storefront that never resolves a region renders the default region's prices to every customer on earth, and the page looks perfectly fine. Check that `getStoreRegions()` is called at all, and then that the resolved `regionId` reaches **every** product read **and** `createCheckout`. Passing it to the reads alone shows one price and charges another.\n- Email verification with a six-digit code\n- Forgot password and reset password\n- The OAuth button area and callback handling, including when no provider is currently enabled\n- Coupon input in the cart\n- The inventory reservation countdown, visible to the customer\n- The payment step is one `client.startPayment()` call (no `renderType` / provider-name branching, no Stripe Elements or PayPal buttons, no hand-built payment iframe), with `session.destroy()` on unmount\n- `/payment-complete` calls `relayPaymentReturn()`; `/order-confirmation` calls `completePaymentReturn(checkoutId)`, then `handlePaymentSuccess` on `'succeeded'`\n- Sitemap built with the dedicated SDK helpers rather than a plain product list\n- Slug-redirect handling on product and blog not-found paths\n\n**Cart and checkout behaviour (R1 to R6).** These are not entries on the feature list: the cart can be present, reachable and still broken on a phone. Check them by reading the code, then confirm them by running the behaviour check in step 4. A store on an SDK older than 3.11.0 has no cart store, so the same rules apply to its `smart*` calls and are checked by hand:\n\n- **R1, no empty cart before the first answer.** Find the string the empty state renders and trace the condition that shows it. `cart === null`, `!cart?.items.length` or `items.length === 0` evaluated before the first answer is the bug: a shopper with items sees \"empty\" until the request lands. The view must render in this order: loading skeleton (sized from the remembered count, `hintCount`, with a cap), error with a retry button, empty, cart. A failed load drawn as empty, or a header badge that prints 0 until the answer arrives, is the same defect.\n- **R2, no full-page reloads between store pages.** `grep` for `<a href=` to an internal path and for `window.location.href`, `location.assign` and `location.replace` used to move around the store. Check the header, footer, menu items, announcement bar and product cards: links that come from merchant content (`item.url`) are the usual leak. Router links only; a plain anchor is for external URLs, `mailto:`, `tel:`, `#anchors` and `target=\"_blank\"`.\n- **R3, the returned cart is the cart.** Look for a cart write followed by a read (`smartAddToCart` then `smartGetCart`, `addToCart` then `getCart`, an `await write(); await refresh()` pair) and for the cart copied into the app's own state. On SDK 3.11.0 or newer (read `package.json`) the UI should sit on `createCartStore` or `CartProvider` and `useCart` from `brainerce/react`, change a line by `CartItem.id` and not by product, and the checkout button should `await flush()` (an older SDK: the last pending write) before it navigates. A bare link to `/checkout` skips that wait.\n- **R4, the Vercel function region.** If the project deploys to Vercel, `vercel.json` sets the function region to `fra1`, next to the Brainerce API (the default `iad1` adds roughly 300 to 450 ms to every proxied call). This is the hosting region, not the commerce regions above.\n- **R5, nothing floats over the cart or the checkout fields.** Chat bubbles, WhatsApp buttons, cookie bars and the storefront bot are not mounted on `/cart` and `/checkout`; the primary button under the order total is Checkout, not \"Continue shopping\"; a phone gets a sticky checkout bar on the cart page; the site header and footer are hidden on checkout.\n- **R6, autofill tokens.** Every checkout input has `autocomplete` (`email`, `given-name`, `family-name`, `tel`, `postal-code`, `address-level1`, `address-level2`, `address-line1`, `address-line2`, `country`), a `name`, and `inputmode` for email and phone. The one allowed exception is address line 1 when it is the Places typeahead: that input is `autocomplete=\"off\"`.\n\nNewer entries on the checklist, skipped most often because older builds predate them:\n\n- An estimated tax line before checkout, rendered only when `appliesTax` is true, labelled an estimate, and showing the returned `note`\n- Loyalty: points, referrals, badges, and paid membership\n- Saved payment methods: a customer saving a card and seeing their saved cards\n- Order bumps at checkout and bundle offers in the cart\n- A contact form that files a real inquiry, and email newsletter signup, both as real submissions rather than a mailto or a dead input\n- A back-in-stock alert on a sold-out product, and the low-stock badge on product detail. `getStockStatus` defaults `lowStockThreshold` to 0, so a build that never passes it silently ignores the threshold the merchant configured and the badge never appears.\n- The gift-card field at checkout: applying a code, seeing what it paid, removing it, and applying more than one. Check the rendering as hard as the wiring, because a field that works and is drawn inside the discount block is still wrong.\n- The saved address book inside the account area, not only the checkout address form. It has no capability flag and is always on, so there is no store setting that excuses leaving it out. Check that checkout prefills from the default address too.\n\n### 3. Check the critical rules against the code\n\n- Prices parsed before arithmetic, everywhere, including totals\n- Nested and flat line-item shapes handled as they actually arrive\n- No auth token in browser storage without a backend-for-frontend\n- No hardcoded currency, locale or store id\n- `regionId` reaching `createCheckout`, not only the product reads. Half-wired is worse than unwired: the customer is shown one price and charged another.\n- No invented SDK methods. Wishlists have no SDK surface, so a call that looks like one is a fabrication, not a version gap. **Subscriptions are no longer in that category:** paid membership ships as `getMembershipPlans`, `subscribeToMembership` and `cancelMembership`, and it is a mandatory feature — flagging those three as invented tells a developer to delete working code. What is still absent is a self-serve subscription CHECKOUT: recurring PLANS are configured by the merchant, and there is no storefront API to start one. **Gift cards are the opposite case and the one to get right in both directions:** `applyGiftCard`, `removeGiftCard` and `checkGiftCardBalance` are real, so do not flag them as invented, and a build that omits the redemption field is missing a mandatory feature rather than declining an optional one.\n- No gift card folded into `discountAmount` or rendered inside the discount block. It is a tender, not a discount: `total` is unchanged and tax is calculated on it, so the card belongs on its own line below the total with an \"Amount due\" row underneath. A build that discounts it misstates the taxable base to the shopper and on the receipt, which is a correctness bug rather than a styling one.\n- The six cart and checkout behaviour rules above (R1 to R6), each cited with a file and line like any other finding. They are critical rules in `skills/brainerce-storefront-build/references/critical-rules.md`, and a violation is a critical rule violation in the report.\n\n### 4. Run the behaviour check against the running store\n\nReading code proves the rules are followed on paper. A script proves the store behaves. Brainerce publishes one that drives a real browser through any storefront (the starter, a store built by an AI tool, localhost or a live shop) and never judges design:\n\nThe script ships inside the storefront starter. A store scaffolded by the `create-brainerce-store` release that includes the cart store (it needs SDK 3.11.0 or newer) already has it as `scripts/verify-storefront.mjs`, and the developer runs it from the project with `npm run verify:storefront -- --url http://localhost:3000 --viewport 390x844 --slow`. Do not download the script, fetch it from a URL or run anything that is not already in the project. For a store that was not scaffolded that way, tell the developer that the same script is published at brainerce.com/verify-storefront.mjs and that fetching and running it is their own step, then audit by reading code. Run it twice: once as a phone (`--viewport 390x844 --slow`, and `--locale he-IL` for a right-to-left store, or the store's own locale tag), once as a desktop with no flags. It adds items to an anonymous cart in a throwaway browser profile and opens the checkout page; it never submits an order, never enters payment details and never logs in. `--only a,b` runs named checks. A FAIL makes it exit with code 1; a WARN is worth fixing and does not.\n\nWhat the checks look at, by id: `nav-no-reload` (header links move between pages without a full reload), `add-requests` (adding to the cart is one request and the response is the cart), `cart-first-paint` (the cart page never shows \"empty\" or zero totals before the real cart arrives), `burst-taps` (quick taps on `+` end on the right quantity in few requests), `write-failure` (a failed update rolls back and tells the shopper), `load-failure` (a failed cart load shows an error with a retry, not \"empty\" and not an endless spinner), `checkout-waits` (checkout waits for a pending cart update), `floaters-overlap` (no popup, chat or widget covers a cart control or a form field), `checkout-fields` (email, phone and name inputs carry `autocomplete`) and `no-overflow` (no horizontal overflow on home, product, cart and checkout). Report each FAIL and WARN with its id and the file that causes it, as findings in the matching state below.\n\nIt needs a running store, a shell and a Chromium build. When you have none of those (ChatGPT, no deployed URL, no permission to start a dev server), skip it, and say in the report that the behaviour of the cart was audited by reading code only. Run it against a deployed URL or one the user already has running; start a dev server yourself only because the user asked for the audit, and keep it to this one pass.\n\n### 5. Report, then fix only what is approved\n\n## Report shape\n\nThree states, and use all three. A report that is all ticks was not an audit.\n\n> ✓ Audit of your Brainerce integration. 24 of the 34 mandatory features are reachable.\n>\n> **Implemented and reachable**\n>\n> - Product listing, product detail with variants, cart with persistence\n> - Checkout through payment, with the reservation countdown visible\n> - Registration and login\n> - Order confirmation\n>\n> **Present but broken or unreachable**\n>\n> - `ResetPasswordForm.tsx` exists and no route renders it. A customer who forgets their password has no way in. `src/components/auth/ResetPasswordForm.tsx`\n> - Coupon input is in the cart component but is behind a flag that is never set. `src/components/cart/CartSummary.tsx:82`\n>\n> **Missing**\n>\n> - Email verification. Registration completes and the account cannot be used. This is mandatory.\n> - OAuth button area. The store has no providers today, so it looks unnecessary, but the owner enabling Google later would need a code change.\n> - Sitemap uses `getProducts({ limit: 1000 })`, which the API caps at 100. Your sitemap silently lists 100 products.\n>\n> **Critical rule violations**\n>\n> - `src/lib/totals.ts:14` adds `item.price` without parsing. Prices are strings, so this concatenates.\n> - `src/components/Cart.tsx:31` renders \"Your cart is empty\" whenever `cart` is null, which is every render until the API answers (R1). The behaviour check agrees: `cart-first-paint` FAIL.\n>\n> Want me to start with email verification? It is the one that blocks real customers today.\n\n## Rules\n\n- Trace every feature to something reachable. A file is not a feature.\n- Cite file paths and line numbers. An audit without references cannot be acted on.\n- Use all three states. \"Present but unreachable\" is the most useful finding and the one a shallow check misses.\n- Never mark a mandatory feature not applicable because the store has it disabled.\n- Report before fixing, and fix only what the developer approves.\n- Say what you could not check, and why. An audit that quietly skipped the payment path is worse than one that says it did. The same goes for the behaviour check: if you did not run it, say so, rather than letting a clean code read stand in for a clean run.\n- Order findings by what blocks a real customer today, not by checklist order.\n\n## Cross-skill connections\n\n- Building what the audit found missing: `brainerce-storefront-build`.\n- Getting a sequence right while fixing it: `brainerce-checkout-flows`.\n- A method signature you need mid-fix: `brainerce-sdk`.\n\nRoute once, and do not bounce back and forth.\n"
}SHA-256 of public snapshot: f1dd5e5248e71391a923b9e1a12ff29fc52dba7bca9b3c8eb2a4194515db3a6c