Removes the "Daybook" name from everything user- and agent-facing, since no
agents are configured yet and this is the cheap moment to do it.
- UI brand, docs, README, CLAUDE.md -> AgentFeed.
- Ingest env vars DAYBOOK_URL/TOKEN/SOURCE/DATA_DIR/BIND_ADDR/HOST_DATA_DIR/
KEY_PROVISIONING_API -> AGENTFEED_* (token *values* unchanged).
- Skill: skills/daybook-posting -> skills/agentfeed-posting, daybook_post.py
-> agentfeed_post.py (+ scripts/ wrapper and its test).
- static/daybook.css -> static/agentfeed.css; localStorage daybook.* ->
agentfeed.*; templatetag daybook_extras -> agentfeed_extras; multipart
boundaries; json/csv viewer element ids; daybook_exception_handler ->
agentfeed_exception_handler; compose service/container -> agentfeed.
- Key-provisioning API now OFF by default (independent of DEBUG); enable with
AGENTFEED_KEY_PROVISIONING_API=1 on test installs only.
- Posting helper now points at Settings -> API Keys.
Deferred on purpose (a later, separate step): the Django package
`daybook_project`, the `/opt/daybook` install path, and the Forgejo repo name.
The sibling AGENT_DAYBOOK__LLM_TEST name is intentionally untouched.
Full suite: 129 passing; live server verified serving under the new name.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Fixes the deploy blocker found deploying v0.1.0 to cloud-vm-1: the vendored
gridjs.umd.js ended with a //# sourceMappingURL=gridjs.umd.js.map trailer,
but that .map isn't in the repo. The strict CompressedManifestStaticFilesStorage
backend follows the reference and raises MissingFileError, aborting the
entrypoint's collectstatic so the container never served. Stripped the
debug-only trailer (no runtime effect); collectstatic now succeeds from a
pristine checkout (169 copied, 481 post-processed).
Also rolls up this release's already-committed work: GET /api/skill and the
location-agnostic posting-skill rewrite.
- Bump __version__ to 0.1.1.
- Runbook: note that a post-build crash-loop is most likely a collectstatic
MissingFileError (check docker logs), and how to clear on-server tracked
drift before checking out a tag.
- CHANGELOG: 0.1.1 entry.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- CHANGELOG.md started (Keep a Changelog style), with the v0.1.0 release
notes; versions track the git tags and __version__.
- Runbook §7 now deploys a specific tag (git fetch --tags && checkout
vX.Y.Z) and rolls back to the previous tag, with a note that rollback
reverts code not data (restore the data backup if a migration ran).
(The deploy kickoff brief lives in planning/, which is gitignored — it's a
local hand-to-the-agent note, not shipped in the repo.)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Real bug: the container healthcheck (and the docs' verify step) hit
/api/capabilities, which returns 403 unauthenticated; curl --fail treats
403 as an error, so a healthy container would report "unhealthy" and the
verify step would look like a failure. Healthcheck now hits /accounts/login/
(200, no auth). Verify commands now print the status code and note not to
use curl -f on the 403.
Also reframed cloud_agent_deploy.md's intro for an Opus-class deploy agent:
it's a guide + Daybook-specific gotchas, not a rigid script — points at the
authoritative sources (repo incl. the git-SSH :2222 note, deploy/ files,
requirements.txt deps auto-installed, entrypoint runs migrate+collectstatic,
docs/deployment.md) and trusts the agent's judgment. Dropped the now-
redundant Source Of Truth section.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The app-side fix (CSRF_TRUSTED_ORIGINS, SECURE_PROXY_SSL_HEADER in
settings.py) was already committed as d458cd3 after the first Cloud-VM-1
deployment hit "CSRF verification failed" on login behind Apache. This
finishes the rest of that issue's checklist: documents
DJANGO_CSRF_TRUSTED_ORIGINS in deploy/env.example, adds the required
X-Forwarded-Proto header to the Apache/Caddy examples in
cloud_agent_deploy.md (plus a checklist item that verifies via an actual
login, not just an unauthenticated capabilities curl), and adds the same
proxy-agnostic guidance to docs/deployment.md.
Also introduces issues/, a tracked one-file-per-issue log for the project
going forward.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
A follow-up review of the previous fix caught that M1's DAYBOOK_HOST_DATA_DIR
override wasn't carried through to the backup step or checklist - both still
hardcoded deploy/data. Exactly when the override matters (a host with a
separate/larger volume), the backup would silently tar the wrong directory
while the checklist still read as complete.
Backup and checklist now derive the path from deploy/.env instead of
restating it. Also documents in docker-compose.yml why the .env
interpolation only resolves correctly when invoked as
`docker compose -f deploy/docker-compose.yml`, per a non-blocking note from
the same review.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Addresses a review of deploy/cloud_agent_deploy.md against Cloud-VM-1 (a
shared Hetzner VPS already running ~10 other services, including the
Forgejo instance this repo is hosted on):
- Blocking: git.cygnus.systems' git-SSH listens on port 2222, not 22 -
fixed the SSH config example and clone fallback, with a note not to
assume 22 if it changes again.
- High: container port now binds via configurable DAYBOOK_BIND_ADDR
(defaults to all interfaces, set to 127.0.0.1 when a reverse proxy fronts
it) instead of always publishing to 0.0.0.0; reverse-proxy+TLS is now the
only path presented for internet-facing hosts, not a coequal option with
direct exposure.
- High: replaced the Caddy-only hardening example with an Apache vhost +
certbot path (matching how this specific host already terminates TLS for
everything else on it), plus a check-before-assuming-80/443-are-free step.
- High: added mem_limit/mem_reservation to docker-compose.yml so this
doesn't risk OOM-killing other services on a memory-tight box.
- Medium: added configurable DAYBOOK_HOST_DATA_DIR so persistent data can
land on a separate/larger volume instead of a space-constrained main disk.
- Medium/Low: checklist now prompts checking the target's own
service-inventory/monitoring/changelog conventions, and .env guidance
notes it should stay low-stakes since a deploy agent reads/writes it.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Self-contained operational SOP for an autonomous agent deploying and
operating Daybook on a cloud VM: bootstrapping its own scoped SSH deploy
key, cloud-specific network/firewall setup, the git-pull redeploy loop with
rollback, TLS hardening for internet-facing hosts, and a completion
checklist.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
