Stardust is a brand extraction and prototype generation pipeline (from the adobe/skills plugin). It crawls a live site, captures its visual design system — colors, typography, spacing, logo, icons, screenshots — and stores it in a structured stardust/current/ directory with DESIGN.json and PRODUCT.md. The prototype step then uses this to generate pixel-perfect HTML pages. Stardust is NOT used to redesign the site — it extracts and faithfully reproduces it.

Snowflake is the EDS conversion layer (from the ai-ecoverse/snowflake plugin). It takes the stardust prototypes (HTML files) and converts them into a working AEM Edge Delivery Services site — creating custom blocks/ directories with JS and CSS, generating EDS-compatible content HTML for DA, and building a block catalog page. The result is a real EDS site that previews at https://main--{repo}--{owner}.aem.page/.

AEM Edge Delivery Services (EDS) is Adobe's JAMstack-style web platform. Content lives in DA.live (a headless CMS), code in GitHub. EDS builds blocks via a lightweight JS architecture: each block has a decorate(block) function that transforms raw HTML table markup into the final rendered component. Preview URLs follow the pattern https://main--{repo}--{owner}.aem.page/. Live URLs use .aem.live. Static files in git (like /deliverables/*.html) are served at their exact path including the .html extension.

DA (Document Authoring) is the headless CMS that powers EDS content. Content is uploaded via the DA Admin API (PUT https://admin.da.live/source/{owner}/{repo}/{page}.html) and then previewed via the AEM Admin API (POST https://admin.hlx.page/preview/...). DA requires both Authorization and x-content-source-authorization headers with the IMS token. Critical limitation: DA strips all <img>, <picture>, and inline <svg> from programmatically uploaded HTML. Images must be stored as plain text URLs in block cells.

The OF1 worker is a Cloudflare Worker at of1-gen-web-service.franklin-prod.workers.dev that handles AI generation. Each demo gets a tenant — identified by main--{repo}--{owner}. Config JSON files are committed to the git repo at of1/config/, served as static files by EDS, then synced to the worker's R2 storage via POST /api/tenants/{id}/sync. The worker auto-indexes vectors for products, features, and FAQs during sync. Generation is tested via POST /api/generate.

The block guide (of1/config/block-guide.json) is a prompt string (stored in a "guide" field) that teaches the OF1 LLM what JSON to output. It defines each block with a description, rules, and a complete rows-format example. The worker's json-to-html.js converts the LLM output to EDS block HTML at runtime. Blocks are output as separate JSON objects separated by === — never wrapped in an array. The guide is the single most important config file for generation quality.

In SLICC's architecture, a scoop is a sub-agent (spawned via scoop_scoop()) that handles a specific task. A sprinkle is a persistent UI panel that the cone (orchestrator scoop) communicates with via sprinkle send. The of1-demo orchestrator is a cone — it opens the sprinkle panel, spawns step scoops named of1-s1 through of1-s13, polls for status files, and pushes status updates to the sprinkle UI. Step scoops never call sprinkle send directly — they write status files and the cone picks them up.