peter/daybook
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
daybook/issues/012-posting-script-missing-json-csv-support.md
peter e137725cab Add json/csv support to the posting script (issue #012) 
TEXT_KINDS and TEXT_SUFFIXES now include json/csv, with matching
sniff_text_kind branches so both explicit --kind and positional auto-mode
work. Added validate_payload's JSON shape check mirroring the server.
Updated SKILL.md/docs/llm_posting_helper.md with real usage examples,
replacing the stale --as-markdown workaround guidance (kept only for
genuinely unstructured code, which still has no dedicated kind). Also
fixed an unrelated stale doc line found in the same table: html_full's
validation was documented as requiring <!doctype AND <html, but only
<html is actually required.

Verified via dry-run (explicit --kind, auto-mode, invalid-JSON rejection)
and one real end-to-end post through the script against the live dev
instance.

Added tests/scripts/test_daybook_post.py - 17 tests, plain unittest, zero
new dependencies, loaded via importlib since the script isn't a package.
Closes the test-coverage question the issue raised.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-02 15:38:47 +01:00

3.4 KiB
Raw Blame History

012 — daybook_post.py doesn't know about the json/csv kinds

Status: Fixed

Description

Found while updating SKILL.md's kind cheat sheet for issue #011. artifacts/views.py added first-class json and csv kinds, but the posting helper script wasn't updated alongside it:

  • skills/daybook-posting/scripts/daybook_post.py's TEXT_KINDS = {"markdown", "html_fragment", "html_full", "deck"} doesn't include json/csv, so --kind json is rejected by argparse before a request is ever sent.
  • TEXT_SUFFIXES (used by positional auto-mode to sniff a file's kind from its extension) doesn't include .json/.csv either — posting data.json via the simple daybook_post.py data.json auto-mode path uploads it as a generic downloadable binary artifact instead of using the new interactive kind.
  • validate_payload() has no shape-check branch for json (mirroring the server's json.loads validation, per how every other kind's client-side check mirrors its server-side one).

Net effect: the API itself supports json/csv fully (confirmed working via direct HTTP), but an agent following the documented, recommended workflow ("always use the helper script") currently cannot reach either kind at all.

Suggested Fix

  • Add "json", "csv" to TEXT_KINDS.
  • Add .json/.csv to TEXT_SUFFIXES with matching sniff_text_kind logic (or a clear rule — e.g. .csv always maps to kind=csv; .json maps to kind=json unless some other signal suggests it's meant as metadata).
  • Add a json branch to validate_payload(): attempt to parse and raise a clear ValueError on invalid JSON, mirroring the server.
  • Add a usage example to SKILL.md/docs/llm_posting_helper.md for both kinds (e.g. daybook_post.py --kind json --content-file data.json).
  • No test suite currently exists for this script at all (it's exercised manually / via the API tests on the server side only) — worth deciding whether this is finally worth a small script-level test file, or whether server-side coverage is considered sufficient.

Resolution

Added "json"/"csv" to TEXT_KINDS and .json/.csv to TEXT_SUFFIXES with matching sniff_text_kind branches, so both explicit --kind json/csv and plain positional auto-mode (daybook_post.py data.json) work. Added a json branch to validate_payload() mirroring the server's json.loads check (no branch needed for csv - matches the server's own lenient stance). Updated SKILL.md and docs/llm_posting_helper.md with real usage examples, replacing the stale --as-markdown workaround guidance for CSV/JSON (kept for genuinely unstructured "code" only, which still has no dedicated kind). Also fixed an unrelated pre-existing doc inaccuracy noticed in the same table: html_full's validation was documented as requiring both <!doctype and <html, but the code (and server) only require <html.

Verified via dry-run for both explicit and auto-mode paths, invalid-JSON rejection, and one real end-to-end post through the script against the live dev instance.

Added tests/scripts/test_daybook_post.py (plain unittest, zero new dependencies, loaded via importlib since the script isn't a package) - 17 tests covering sniff_text_kind, validate_payload, and resolve_auto_path. Answers this issue's open question about test coverage: yes, worth having now that the script's logic has real per-kind branches worth protecting against regression.