--- name: build-html-dashboard description: 'ONLY for writing dashboard or chart HTML BY HAND. NOT needed on the normal path — create_artifact(type="html-app") followed by generate_artifact writes the dashboard itself and carries this contract internally. NOT needed to change the content of a report or add sections (report_tools does that; see DIRECT REPORTS). Recall this before rewriting the code of a generated dashboard, or when generate_artifact failed and the user asked you to continue manually: it is the output contract — self-contained file rules, Apache ECharts setup, dark theme, layout/design standards, large-dataset handling. Not needed to repair a page generate_artifact returned as browser_check_failed: that result''s instruction says how.' metadata: display_name: HTML dashboard & visualization output format provenance: builtin --- LIST THE INSIGHTS (terse — one line each, not an essay): Before coding, list the insights you want to present/convey/highlight as `1 - : ..` Example: `1 - Line chart of weekly signups: shows growth inflection after the March launch, flags whether momentum is sustained.` This is a checklist, not a brief — no narrative prose, no design discussion. BUILD THE DASHBOARD — use multiple scratchpad cells, but produce ONE single self-contained HTML file: Before the first write, call `create_artifact(type="html-app", name=..., description=..., primary="index.html")` and use the returned `` for every file you write. All paths below referring to "the output directory" mean ``. The final dashboard MUST be a single .html file with all data, CSS, JS and images inlined, with no exception: the web app preview shows only the page itself, so a separate file next to it (`dashboard_data.js`, `logo.png`) does not load there, whatever its size. Build every page this way so it renders on every deployment. Keep the whole page under 8 MB; a larger page cannot be checked in a browser. REROUND DISCIPLINE (critical — most "round-cap exhaustion" failures we've seen on real dashboards come from drifting off one or more of these): 1. ONE scratchpad, ONE name. Pick a name on the first cell (e.g. `dash`) and reuse it for the entire build. Switching names (`build_pres` → `write_html` → `pres1` …) creates *separate isolated environments* — variables in one don't exist in another — and burns rounds on recovery. 2. WRITE TO DISK INCREMENTALLY. Open the output `.html` once in 'w' mode, then `open(path, 'a')` to append head → body skeleton → each chart section → nav/JS → closing tags. Each cell appends a small chunk you can sanity-check. Do NOT build a single 20KB+ HTML string in memory and write it at the end. 3. CAP STRING SIZE PER CELL at ~5KB. Large-string scratchpad calls are the single biggest cause of silent failures (the tool occasionally drops the `code` payload on oversized inputs and the cell comes back with an empty-code error, which still counts against the round cap). If a section is too big, split it. 4. NEVER re-emit the full HTML mid-build. Append deltas, don't re-print the world. Assembly is a one-line concat at the end, not a re-render of everything you've written so far. 5. KEEP READS SMALL. To verify what landed, `os.path.getsize(path)` or the `read_text_file` tool with `start_line=-20` — never read a multi-KB HTML whole. HOST CONTRACT (critical — the checks `generate_artifact` runs on every page it produces: 1–7 fail the step (`` in 1 is not checked), 8–9 are warnings, 10 runs in a headless browser. A hand-built page gets the browser check too: after every scratchpad cell that changes an artifact's `.html` file, the host loads the page in a browser where the deployment can and adds what it found under `[artifact lint]` in the cell's result, with a screenshot of the page when the check sent one. When it could not check the page, that line says the page was not checked in a browser and why: then tell the user the page is unverified in a browser. Items 1–9 are not checked for a hand-built page, so verify them yourself before you finish): 1. A complete HTML document with an explicit ``...``, and `` set to the language the user writes in, unless they ask for another language for the page (UI text follows it too). 2. `` in ``. 3. No absolute URL in any `fetch()` call. A map loads its atlas, `https://cdn.jsdelivr.net/npm/world-atlas@2.0.2/countries-110m.json`, with `d3.json(...)` (item 9), not with `fetch()`. No root-relative path either, in `src`, `href`, `fetch()` or `new EventSource()`: a value that starts with a single `/` (`/logo.png`, `/api/export`) breaks in the app preview and once published, because the page is served under a path prefix that a path from the root drops. Use a relative path for a link to another page (`details.html`); in a fullstack app, call the backend through the `api()` helper that build-fullstack-backend defines. `https://`, `//`, `data:`, `blob:`, `#` and `mailto:` values are fine, so `href`/`src` links to external sources stay allowed. Moving the same root-relative path into a JS string does not fix it. 4. Every opened `` — an unclosed one silently disables all JS. 5. The global name `window.__antonCommentsLayer` is never used; the host app reserves it for its comment layer. 6. No universal `* { ... !important }` rule (a reduced-motion media query is the one accepted exception). 7. Every `z-index` is 1000 or below — the host app's own overlays sit above the page. 8. Significant block containers (`div`, `section`, `table`, `main`, `article`) carry stable `id` attributes — the host app attaches comments to them. 9. The web app preview runs the page in a sandboxed frame under a content security policy that blocks what it does not allow. Build to that policy so the page renders on every deployment. Scripts load only from `https://cdn.jsdelivr.net/npm/@/...`: pin an exact version, since a floating `@4`, `@5` or `@latest` cannot be checked. Styles are inline only (`