--- name: research-use-storefront description: Use when building a research-use-only storefront. Covers copy rules, visual proof and the dark-not-delete rule for compliance changes. version: 1.0.0 author: Pixel Rainbow (shagghiesuperstar) license: MIT metadata: hermes: tags: [storefront, research-use-only, compliance, copy, design, medusa, ecommerce] category: commerce related_skills: [regulated-catalog-content, regulated-commerce-compliance-gates, medusa-docs-first] --- # Research-Use Storefront ## Overview A research-use-only storefront sells laboratory materials to professional buyers under a strict copy contract. It makes no health or dosing claims, shows lot evidence instead of marketing, and never offers checkout until the payment and compliance work is done. The design is dark and editorial, with one 3D hero, a sticky-track layout, and journal pages for method and checkout. This skill sets the copy rules, the commerce fallbacks used before a backend is live, and the visual checks that must pass before a gallery is called done. ## When to Use - Building a second storefront head that shares a commerce backend later and sells research materials. - Reviewing copy, layout or catalog pages for a research-use-only store. - Deciding how to handle a compliance change that would otherwise delete features. Skip it for telehealth, for age-gated consumer brands, and for storefronts that take payment today. ## Features - A copy contract with allowed claim types, forbidden claim types and the exact calls to action. - Commerce fallbacks: a fixed catalog, a session-stored bench, and a checkout that is a quote desk until payment is ready. - Gallery rules for object photography, cards, product pages and lot evidence. - Visual proof steps that require screenshots, not only markup checks. - A rule that compliance changes are switched off behind flags, never deleted. ## Benefits - Copy that passes a payment processor's review on the first pass. - A storefront that works before the backend is live, without calling endpoints that hang. - A reversible compliance change that can be turned back on after review. ## Procedure ### 1. Keep one head and one preview Serve one storefront. A concept prototype can supply the visual engine, but it is copied into the storefront and then stopped. Do not run two public previews. - Serve 3D assets from the storefront's own public path. A broken asset path makes the engine fall back to a placeholder, so probe the asset URL on the storefront port before judging the hero. - Put WebGL in a sticky stage about four viewports tall, with absolute positioning inside the stage and overflow hidden. A fixed-position canvas paints over later sections. - Do not place a paper card directly under the first viewport. Method, cart and checkout keep the journal leaf. The home page after the 3D track uses the dark field. ### 2. Apply the copy contract - **Allowed:** purity statements the lot paper supports, lot evidence, method, materials, appearance and trust statements. - **Forbidden:** health or medical benefits, dosing amounts, telehealth, drug trade names, and "buy now". - **Calls to action:** "Add to bench", "Request a research quote", "Download lot paper". Empty bench: "The bench is clear." with a link "Open the store". Success: "Received." - **Required line** in the hero and footer: "For research use only. Not for human consumption." - **Names:** use each product's registered name, as the owner supplies it. Alternate names can appear only in hidden search metadata, and only from a list the owner supplies. - **Numbers:** reject quantity, concentration and dose wording. Check with a rule for a number followed by a unit, not with a rule on letter pairs, because letter pairs match markup. - **Drafts:** writing generated by a model often arrives as sales copy or as invented lab completeness. Remove urgency, hype, invented analyte tables and invented usage. If the owner did not state how a product is used, do not state it. - **Fix the copy, not the check.** When a check flags valid text, decide whether the rule is wrong, and change the rule only with the owner's approval. ### 3. Build commerce that works before the backend is live 1. If the commerce backend does not answer on its expected port, do not call its region or cart endpoints. Pages that wait on them hang or fail. 2. Ship a fixed catalog of handles, names and short research blurbs, shared by the home page, the store and the product pages. 3. Store the bench in session storage as handle and quantity. Do not send bench changes to the backend until a live region answers. 4. Make checkout a quote desk: an optional email, default submission prevented, and an on-page "Received." message. Include no payment fields. 5. Mark payment, personal data, hosting and deployment as not done until each is finished. ### 4. Design the gallery - Use object photography on a near-black field with cream type. The accent colour fills controls, and the text on accent fills is dark ink. Cream or white text on a bright accent is unreadable. - Use one live helix motif on the hero. Do not overlay a second helix or a video of one on the same hero. - Keep the wood or texture plate visible. Darken the text column with a gradient, not by hiding the plate. - Non-strand particles must be soft and out of focus. Hard floating circles look like dust on the lens. - Rooms (one per product format) are stacked headings with air around them, not tabs or radio buttons. - Each card has its own image and its own alternative text, equal to the product title. Reusing one image across a room is a template, not a catalog. - No price on cards. A hover state changes only the border. - A product page's first view shows the image, the title, the research-use line, the bench button and the lot paper link. - Lot evidence is the lot paper. The first row names the sample lot, or the real lot when the catalog is live. Other sections say "See lot paper". Never invent percentages or analyte tables to make a page look complete. - After "Add to bench", stay on the product page, show "Reserved." and a link "On the bench" to the cart. - Journal pages (method, cart, checkout, the research statement) share one journal leaf with a flat right edge. - The research navigation is four words in capitals: brand, store, method, bench. The active item uses accent text only. - On narrow screens, hero buttons stack full width, navigation words wrap instead of collapsing into a menu, touch targets are at least 44 pixels, and the journal leaf fits inside the screen width. ### 5. Prove visually before calling a gallery done Markup greps and a text-only review cannot judge layout. Take screenshots at about 1440 by 900 pixels, at the hero and after the first scroll, and at a phone width. Fail the pass if type overlaps, the 3D canvas sits over the journal or the research line, the product image is cut off, a card has no title, a product page shows only an image, a room is missing, starter template chrome is visible, or two local addresses are offered as the site. ### 6. Treat compliance changes as switches When a payment processor, a regulator or the owner asks for a feature to be removed, do not delete the code. Put the feature behind a flag that defaults to off, for example an environment flag for a reviews module. Keep components, routes, data and tests in place. A renamed product keeps its original title and description in metadata so the change can be reversed. A compliance change is complete when: - The diff for the change contains no deleted feature files. - A test with the flag on shows the old behaviour returns. - The flag and its default are recorded in the change description. Removing boilerplate text, such as a starter template's placeholder string, is a plain text edit and does not need a flag. ### 7. Stay in scope while blocked When a visual judge marks a page ready but the owner's goal still lists work as open, keep working on the parts of the goal that are allowed. Do not stop because one judgement passed, and do not ask the owner about decisions already recorded. ## Pitfalls - **Writing the storefront from the orchestration layer.** Specifications and tasks go to the orchestration layer. Code is written by the implementing agent in the repository. - **Forking a branded storefront** copies its age gate and its identity. Start from a clean commerce starter and bring the engine in as a client component. - **Leaving generated sales copy on the site.** A numeric dose or a sales line is a compliance problem, not a tone problem. - **Calling the backend while it is down.** Use the bench fixture until a region answers. - **Showing dose numbers on product formats** to fill a product page. Use names and formats only. - **Repeating method text as specifications.** Method is not lot evidence. - **Calling a gallery done from HTML alone.** Titles and buttons can sit below the fold, and a fixed canvas can cover the paper. - **Two live previews.** Keep one, and stop the rest. - **Two project trees with the same name.** Confirm the working directory of a running process before judging what it serves. - **A fixture catalog that outlives the database.** Probe one direct product URL to tell a design problem from a data problem. A product URL that returns 200 means the data is present, even when the listing page shows placeholder products. - **Hard bokeh and fixed full-screen canvases** make the page look broken on phones. ## Verification - Copy matches the contract: no health claims, no dosing, the required research line present, and the calls to action exact. - The storefront renders with the backend stopped, using the fixture catalog and the bench. - Screenshots at desktop and phone widths pass each item in the visual checklist. - Each product card has its own image and title, and each product page shows lot evidence. - Any compliance change is behind a flag, with the flag-on test recorded.