# Build a Generative Art Studio: start prompts

Paste this into your AI after you get Build a Generative Art Studio.

There are two prompts. Paste the first one in the session where you start using the journal on your studio. Paste the second one at the start of every later session, so your AI picks up where it stopped.

## Prompt 1: first session (read, map, audit)

```text
I bought the journal "Build a Generative Art Studio". It is the engineering memory of one in-browser studio that shipped: visual and audio-reactive engines on a canvas, live parameters, presets, still and video exports, a free tier with watermarked exports, a render API other apps call, and remote control by an AI through an MCP server. It records the architecture that held, the bugs that cost real hours, their root causes and fixes, and the decisions with their reasoning. Your job is to read it, map my project onto it, and build or repair my studio in its order, one piece at a time, checking each piece the way the journal says.

WHAT IT IS FOR
Building the engine side of a generative art app: the engine contract and lifecycle, state and parameters, the canvas and GPU resources, audio, scene switches that do not freeze the page, exports that match the approved frame, the cost of each piece, free-tier metering, AI control, and a render API. Selling and gating access is not here: that lives in the companion journal "Ship a Digital Business Website".

WHEN TO USE IT
- Before you add an engine, change how state is stored or synced, touch the canvas mount, or build an export.
- When something renders black, freezes on a scene switch, leaks GPU contexts, or exports differently from the preview.
- Before you copy any engine into another product (the journal's answer is: do not; call the studio).

HOW TO GET AND READ THE JOURNAL
- With the Vibedna connector: call list_library, find the slug build-a-generative-art-studio, then read_journal(slug="build-a-generative-art-studio", part=1), then part=2, 3 and so on until there are no more parts. Read every part before you propose changes.
- With Journals DNA paired: journal_get(slug="build-a-generative-art-studio") writes it into ~/.journal/library; read it from there with journal_read (use offset and limit).
- Read in this order: "What you get after your AI reads this", "What you bring, and where this comes from" and "How to read the decisions here" first (numbers are starting points that worked for one studio: verify them on my case). Then the sections in the order the journal builds: engine architecture and lifecycle, state and parameters, canvas, WebGL and audio, scene switching, export and render, cost per piece, free-tier metering, driving the studio from an AI, the render API. Before any change, read "Bug to Root Cause to Fix catalog", "Decisions and reasoning" and "What we killed, and why".

ASK ME FIRST (only what the journal says changes the build)
1. My stack: Next.js and React (what the journal shipped on), or something else? (If different, keep my stack and apply the lessons; the file names will not transfer.)
2. Which backends: WebGL2, Canvas2D, or both? Any engine that runs its own frame loop?
3. Is any engine audio-reactive, and do I want a music-visualizer surface?
4. Which exports: stills, recorded video, frame-by-frame bakes, loops? Where do renders run: in the visitor's browser (the journal's default), a cloud render service, or my own machine?
5. Do I want a free tier with watermarked, metered exports and a paid tier?
6. Do I want an AI or MCP bridge to control the studio, and do other apps of mine need its art (render API)?
7. Which platforms must not freeze (the journal measures Windows shader compiles separately)?

THE BUILD, IN THE JOURNAL'S ORDER
1. The engine contract: identity, paramSchema, defaultParams, init, setParams, step, render, resize, dispose, getState and loadState. A fresh instance per getEngine call, never a singleton.
2. The lifecycle as a state machine (init, ready, step, dispose) with "ready" as one source of truth in the store.
3. The canvas mount keyed by engine, seed and preview resolution, so a remount releases the GPU context. Never destroy the shared context inside dispose. Wrap each frame call in try and catch.
4. State: one store with a small persisted slice; schema-filter shared parameters on every engine swap, preset load and mid-track change; coerce every uniform to a number with a default; global layers in their own slice.
5. Audio: one audio graph outside the UI framework, created once.
6. Scene switches: compile in the background, warm the next scene off screen, keep the old one up until the new one draws.
7. Export: composite onto a 2D canvas the recorder owns; deterministic bakes with every other clock frozen; design space separate from device pixels; audio codec fallback; check files for black frames the right way.
8. Cost per piece and free-tier metering, measured before building pipelines.
9. The AI bridge, with lean endpoints by default and heavy payloads opt-in.
10. The render API: a render door and a live player, answering only an allowlist of origins, releasing GPU contexts after each job.

HOW TO VERIFY EACH PIECE (the journal's own tests)
- Check the visible result, not the object: a value forced in a derived object does nothing if mounting is decided elsewhere.
- Run any smoke test both with a seed and without, and test no-input, bad-input and cancelled-mid-init.
- Measure freezes honestly (count a freeze still running at the end, click scenes by exact name, use a production build) and test every checker against a known broken case before trusting its green.
- "Identical" means decoded frames (frame hashes), and determinism means seed plus frame count only.
- Compare the export against the preview at the export size, and audit any offline bake runner the same day.

WHAT TO CHECK FIRST
Read my code for: whether getEngine returns fresh instances, where "ready" lives, how the canvas is keyed, whether dispose destroys the context, how params merge on swap, every persistence layer that exists (browser storage, any server state file, saved files), and whether any endpoint returns heavy data by default.

NEVER
- Never deploy, publish, change prices or tiers, or delete my files or engines without my yes in this session. Show me the change first.
- Never copy an engine into another product; give the studio a render API instead.
- Never merge shared params without the schema filter, and never write music-modulated values back into the store.
- Never write a server state file inside the watched project folder, and never read one without validating it (size caps, clamps).
- Never send a visitor's own photo, video or camera feed to the server.
- Never make the heaviest engine the default.
- Never kill a feature only at the surface: remove it from defaults and persisted state too, with a migration.
- Never record a hypothesis as a finding.
- Never put keys or tokens in code, a journal or this chat.

KEEP MY PROJECT JOURNAL
- If I have Journals DNA: after each piece, journal_append(name_or_path="<PROJECT>", entry="<what you built or fixed, root cause, how you verified it>", tag="ship" or "fix"). When I choose something (stack, default engine, tiers, a rule), journal_decision_add(name_or_path="<PROJECT>", decision="...", why="..."). When the state changes, journal_update_section(name_or_path="<PROJECT>", "Current state", new_content, mode="replace").
- If I do not: keep a plain <PROJECT>_JOURNAL.md in my project folder with a dated line for each piece done, each decision, and each bug with its root cause.

HOW TO REPORT BACK
Result first, in plain words: what you changed (file by file) and how you proved it (what you saw on the canvas, the measurement). Anything visual gets shown to me as it actually moves, not as a still. Name the journal section you relied on. End with one question if a decision is mine.

FIRST TASK NOW
Read part 1 of the journal (and the rest before proposing anything). Ask me the seven questions above. Then audit my project against the ten pieces of the build, reading the code only: for each piece say done, missing or broken, with the evidence, and list any row of the bug catalog my code already matches. Change nothing yet. End with the one piece you would fix first and why.
```

## Prompt 2: every later session (continue)

```text
We are building my studio with the journal "Build a Generative Art Studio". Continue from where we stopped.

1. Read my project journal first (journal_handoff_brief("<PROJECT>") if I have Journals DNA, or my <PROJECT>_JOURNAL.md). Tell me in five lines which pieces are done, which one is next, and what is waiting on me.
2. Re-open the journal section for the next piece (read_journal with the part that holds it, or the copy in ~/.journal/library) and its rows in the bug catalog before you touch anything.
3. Check the current code and the running app before you trust what my journal says.
4. Do one piece, verify it the way the journal says (visible result, both seed modes, a known bad case for any new check), log it with journal_append, then stop and show me.
5. Deploys, price or tier changes and deletions wait for my yes.
6. At the end of the session, replace the Handoff section of my project journal: what is done, what is next, what is blocked by me.
```