peter
07328a3412
- #006 (high, data loss): make_room_for() no longer deletes unkept artifacts on a doomed request - checks whether eviction can possibly succeed before deleting anything. Also fixed a related latent bug found while testing: the function returned evicted Artifact objects after calling .delete() on them, so their .id was always None (Django clears pk on delete); now returns ids captured beforehand. - #003: added server-side field-length validation (source/title/ source_name/source_id/theme) on POST and PATCH, matching the model's own max_length limits, which were previously unenforced on the ingest path entirely. - #004: ported daybook_post.py's content-shape validation (html_fragment/html_full/deck/markdown) to the server, closing the gap for any client that doesn't go through the helper script. - #005: PATCH now rejects wrong-typed `tags` (previously silently wiped existing tags) and rejects immutable fields (content/source/kind/day) with 400 instead of silently no-op'ing them. - #002: deleted the misleading skills/daybook-posting/.env.example (a zero-dependency script that never reads .env files) and clarified SKILL.md/docs/llm_posting_helper.md that these must be real process/shell env vars. Adds tests/unit/ for storage-layer tests. 46 tests passing (was 25). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2.5 KiB
002 — .env.example implies persistent config that daybook_post.py never loads
Status: Fixed
Description
skills/daybook-posting/.env.example ships alongside the posting helper:
DAYBOOK_URL=http://127.0.0.1:8001
DAYBOOK_TOKEN=your-personal-api-token
DAYBOOK_SOURCE=agent
The presence of a .env.example file conventionally means "copy this to
.env, fill it in, and the tool picks it up automatically." That's not
true here. daybook_post.py is intentionally zero-dependency (no
python-dotenv, no manual .env parsing) and only reads real process
environment variables via os.environ.get(...) (confirmed: the only
.env-related string in the whole skills/ tree is this example file
itself — nothing in daybook_post.py reads it).
Found while doing a first interactive posting session against the test
account from a sibling project (AGENT_DAYBOOK__LLM_TEST): copying
.env.example to .env and populating it did nothing; the script still
required the vars to be exported into the shell (or set with set/
$env: on Windows) for every new session/terminal. Neither SKILL.md
nor docs/llm_posting_helper.md mention this — both just say "use
environment variables" without clarifying that a .env file specifically
will not work unless the caller's shell/agent harness sources it itself.
This is minor but wastes a round trip for exactly the audience this skill targets (an agent following the docs literally).
Suggested Fix (pick one)
- Simplest: delete
.env.example, or rename/annotate it clearly as "copy these lines into your shell profile / CI secrets / agent harness env config — this file itself is not read automatically." - Alternative: add ~10 lines of manual
.envparsing todaybook_post.py(still zero third-party deps — just read.envin the working directory if present, without overriding already-set real env vars) if the goal really is per-project persistent config.
Resolution
Took the simplest option: deleted skills/daybook-posting/.env.example
entirely rather than adding .env parsing to a helper that's deliberately
zero-dependency. Its content was already duplicated in both SKILL.md and
docs/llm_posting_helper.md's Configuration sections, so nothing was lost.
Also reworded both of those sections to say explicitly that these must be
real process/shell environment variables — the helper reads os.environ
directly and has no .env file support — rather than just "use environment
variables" without ruling out the natural .env-file assumption.