# 011 — Document vetted CDN framework snippets for `html_full`, scoped to that kind only

**Status:** Fixed

## Description

`html_full` is documented (`SKILL.md`'s kind table) as the kind for
"complete custom pages/frameworks" — Daybook injects nothing into it
(`create_text_artifact`: `rendered = content` verbatim), so a poster
wanting Tailwind, Chart.js, or similar has to already know a CDN URL and
hand-write the `<link>`/`<script>` tags themselves. There's currently no
guidance anywhere in `docs/` or `skills/daybook-posting/` pointing to
known-good CDN URLs, so an agent has to search for one from scratch every
time.

Separately (found while investigating this): `daybook_post.py`'s own
`--theme` argparse help text reads `"Example: report, tasks, bootstrap"`
— but `bootstrap` isn't a real theme (only `report`/`tasks`/`deck`/`base`
exist as files under `static/themes/`). Requesting it silently produces a
`<link>` to a 404'ing stylesheet, rendering unstyled with no error. Worth
fixing alongside this, since it's the same "help the agent avoid a dead
end" spirit.

Update: the `bootstrap` example wasn't a random typo — `planning/framework_artifact_rendering.md`
already plans a vendored-Bootstrap-theme feature that just hasn't been built
yet, and the help text was almost certainly written ahead of that. Worth
linking that doc (and `planning/2026-09-02-theme_variants_and_user_palettes.md`,
a related-but-distinct design conversation about palette variants within the
existing theme families) when this is picked up, rather than treating the
example as simply wrong.

**Explicitly out of scope / not being requested here**: injecting CDN
references into the *themed* kinds (`markdown`/`html_fragment`/`deck`).
Those exist specifically so Daybook — not the poster — owns styling
(stated principle in Daybook's own `CLAUDE.md`: "Do not make agents
responsible for styling"), and giving agents a default-reach-for CDN
snippet for those kinds would undermine that. This is scoped to
`html_full` only, where the poster has already opted out of managed
styling by choosing that kind.

## Suggested Fix

- Add a short, curated list of CDN snippets (Tailwind, and whatever else
  comes up often — Chart.js is a reasonable second) to `SKILL.md`'s
  `html_full` row or a new subsection, so agents can copy-paste instead
  of searching. Note Tailwind's own CDN build
  (`cdn.tailwindcss.com`) is marked "not for production" by Tailwind
  themselves (compiles in-browser on every load) — worth linking a
  precompiled build instead, or explicitly caveating if using the Play
  CDN anyway for convenience.
- Note the self-hosted/offline tension explicitly: Daybook runs locally
  and can be deployed air-gapped; any CDN-linked artifact won't render
  fully offline. A one-line caveat in the docs is enough — this is a
  tradeoff to flag, not something to solve.
- Fix the `--theme` help text's `bootstrap` example to name a real theme
  (or drop the example value entirely and just say "see docs/api.md for
  available themes").

## Resolution

Added a "CDN Snippets For `html_full`" section to `SKILL.md` with Tailwind
(Play CDN, with a one-line caveat that it's not a production-grade build)
and Chart.js, an explicit offline/air-gapped caveat, and a reminder that
this is scoped to `html_full` only — never the themed kinds. Fixed
`daybook_post.py`'s `--theme` help text (`bootstrap` was never a real theme;
it was written ahead of the vendored-Bootstrap-theme feature described in
`planning/framework_artifact_rendering.md`, not a random typo) to name real
themes instead.

While in `SKILL.md`'s kind cheat sheet, also found and fixed a second stale
spot: it never mentioned the `json`/`csv` kinds added this session, and
still told agents to use the `--as-markdown` fenced-code-block workaround
for them even though they now have real first-class support. Updated the
cheat sheet accordingly.

That surfaced a real, separate gap: the posting *script* itself
(`daybook_post.py`) doesn't actually support `--kind json`/`csv` yet — filed
as issue #012 rather than fixing inline here, since it needs real script
changes (TEXT_KINDS, auto-detection, validation), not a doc tweak.