Prototype Delivery Structure

Prototype Delivery Structure

Defined in generation contract §7.

<prototype-name>/
├─ AGENTS.md              copied verbatim from templates/AGENTS.md
├─ prototype.html
├─ prototype/
│  ├─ prototype.css
│  ├─ prototype.js
│  ├─ notes.snapshot.js   formal annotation data (written only by the author server)
│  ├─ display-mode.js     ┐
│  ├─ state.js            │ verbatim copies of runtime/client/*
│  ├─ model.js            │
│  └─ viewer.js           ┘
├─ screenshots/           <scene-id>.png from screenshot.mjs
└─ assets/                on demand, never empty

Rules:

• prototype.html loads ./prototype/prototype.css in <head>, and before </body>: notes.snapshot.js, display-mode.js, state.js, model.js, viewer.js, prototype.js in that order. Relative paths so it works under file://.
• No large inline CSS or business scripts; no annotation-editing logic in the HTML; no localStorage for formal notes.
• When chart components are selected, copy every resolve-pack deliver[] entry (from → to) and load ECharts and the chart runtime before notes.snapshot.js. Map geo must be pre-registered in window.PrototypeMapRegistry (no fetch, no CDN).
• Author Bootstrap, Direct edit, Notes editor, Inspector, sketch board, server and source tokens never enter the deliverable.

Before handoff, walk the delivery checklist. Iteration rules: delivery.md.