peter
532b4bd4eb
#009: html_fragment's content-shape check is substring-based, so it can false-positive on inert text inside <script>/<pre> (e.g. a JS string literal that happens to contain "<html>"). Documented as a known limitation in docs/api.md rather than implementing real HTML parsing - a proper fix is a much bigger change than the narrow trigger justifies, and substring matching is the same approach the client helper already uses. #011: added a curated CDN Snippets section to SKILL.md for html_full (Tailwind, Chart.js, with an offline/air-gapped caveat), scoped explicitly to that kind only. Fixed daybook_post.py's --theme help text, which named a non-existent "bootstrap" theme (written ahead of a vendored-Bootstrap feature that was planned but never built, not a typo). Also updated SKILL.md's kind cheat sheet, which never mentioned the json/csv kinds and still pointed at the old --as-markdown workaround for them - and filed issue #012 for a real gap that surfaced doing so: the posting script itself doesn't support --kind json/csv yet, only the raw API does. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
79 lines
4.1 KiB
Markdown
79 lines
4.1 KiB
Markdown
# 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.
|