Add generic deployment docs and fix stale references

Adds docs/deployment.md, a platform-agnostic guide (any Linux host with
Docker) built around a git-pull based fast-redeploy workflow, replacing the
Proxmox-specific deploy/proxmox_llm_deploy.md which was also stale (old
`persona` field, single-shared-token model predating multi-user auth).

Also: drops the unused DAYBOOK_API_TOKEN from deploy/env.example, documents
the new DELETE endpoint and capabilities `methods` field in docs/api.md and
docs/agent_quickstart.md, and fixes CLAUDE.md's OpenCode note now that
opencode.json is untracked (machine-specific MCP config).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs/agent_quickstart.md

@@ -124,6 +124,17 @@ Invoke-RestMethod `
   -Body $body
 ```
 
+## 8. Delete An Artifact
+
+```powershell
+Invoke-RestMethod `
+  -Uri "http://127.0.0.1:8001/api/artifacts/$($artifact.id)" `
+  -Method Delete `
+  -Headers @{ Authorization = "Bearer <your-personal-token>" }
+```
+
+Deletes the artifact's database row and its files. You can only delete artifacts your own token owns.
+
 ## Agent Payload Checklist
 
 Recommended fields for every agent post:

docs/api.md

@@ -333,6 +333,26 @@ Editable fields:
 
 You can only PATCH artifacts your own token owns; others return `404`.
 
+## Delete Artifact
+
+Endpoint:
+
+```http
+DELETE /api/artifacts/{id}
+Authorization: Bearer <your-personal-token>
+```
+
+Removes the artifact's database row and its files (primary file, markdown
+sidecar, and any attached assets). Returns `204` with no body on success.
+
+You can only delete artifacts your own token owns; others return `404`, as
+does a second delete of the same id.
+
+```bash
+curl -X DELETE "http://127.0.0.1:8001/api/artifacts/a1b2c3d4" \
+  -H "Authorization: Bearer <your-personal-token>"
+```
+
 Not editable yet:
 
 | Field | Reason |
@@ -403,7 +423,12 @@ Example response:
   "views": ["rendered", "raw"],
   "raw_supported_for": ["markdown", "html_full"],
   "source_types": ["agent", "person", "system"],
-  "auth": "bearer_token"
+  "auth": "bearer_token",
+  "methods": {
+    "/api/artifacts": ["GET", "POST"],
+    "/api/artifacts/{id}": ["GET", "PATCH", "DELETE"],
+    "/api/assets": ["POST"]
+  }
 }
 ```
 

docs/deployment.md

@@ -0,0 +1,184 @@
+# Deployment
+
+Daybook deploys the same way on any Linux host with Docker: a cloud VM, a home
+server, a Proxmox guest, whatever. It runs as a single Docker container
+(Gunicorn) with all persistent state — the SQLite database and artifact files —
+on a bind-mounted `./data` directory outside the image.
+
+```text
+Target host (cloud VM, home server, ...)
+  Docker Engine
+    daybook container
+      /app     application code baked into the image
+      /data    persistent volume: db.sqlite3, artifacts_store/
+```
+
+## Files In `deploy/`
+
+| File | Purpose |
+|---|---|
+| `Dockerfile` | Builds the Daybook image. |
+| `docker-compose.yml` | Runs Daybook with a persistent `./data:/data` bind mount. |
+| `entrypoint.sh` | Runs migrations, collects static files, then starts Gunicorn. |
+| `env.example` | Template for deployment environment variables. |
+
+## Prerequisites On The Target Host
+
+- Docker Engine + the Docker Compose plugin
+- Git (for the clone-and-pull workflow below)
+
+```bash
+docker --version
+docker compose version
+```
+
+## First-Time Setup
+
+Clone the repo onto the host at a stable path:
+
+```bash
+git clone <REPO_URL> /opt/daybook
+cd /opt/daybook
+```
+
+Create the environment file:
+
+```bash
+cp deploy/env.example deploy/.env
+```
+
+Generate a secret key:
+
+```bash
+python3 -c "import secrets; print('DJANGO_SECRET_KEY=' + secrets.token_urlsafe(50))"
+```
+
+Edit `deploy/.env` and set at minimum:
+
+```text
+DJANGO_DEBUG=0
+DJANGO_SECRET_KEY=<generated-secret>
+DJANGO_ALLOWED_HOSTS=<vm-ip-or-dns-name>,localhost,127.0.0.1
+DAYBOOK_DATA_DIR=/data
+DATABASE_PATH=/data/db.sqlite3
+ARTIFACTS_ROOT=/data/artifacts_store
+```
+
+There is no shared API token to configure — Daybook uses per-user tokens
+(DRF `Token` model) issued from Settings → Account once a user exists. Do not
+commit `deploy/.env`.
+
+Create the persistent data directory and bring the stack up:
+
+```bash
+mkdir -p deploy/data
+docker compose -f deploy/docker-compose.yml up -d --build
+```
+
+Create your first login (superuser) so you have something to log in with and
+a personal API token to post through:
+
+```bash
+docker compose -f deploy/docker-compose.yml exec daybook python manage.py createsuperuser
+```
+
+## Verify Deployment
+
+```bash
+docker compose -f deploy/docker-compose.yml ps
+curl -fsS http://127.0.0.1:8000/api/capabilities
+```
+
+An unauthenticated capabilities check returns 403 (login/token required) —
+that's expected; it confirms the app is up and enforcing auth. Open
+`http://<vm-ip>:8000/` in a browser and log in with the superuser you just
+created, then grab a personal token from Settings → Account and use it for a
+smoke-test post:
+
+```bash
+curl -fsS -X POST http://127.0.0.1:8000/api/artifacts \
+  -H "Authorization: Bearer <your-personal-token>" \
+  -H "Content-Type: application/json" \
+  -d '{
+    "source": "deploy-smoke",
+    "kind": "markdown",
+    "title": "Deployment Smoke Test",
+    "content": "# Deployment Smoke Test\n\nDaybook accepted an artifact."
+  }'
+```
+
+## Fast Redeploys
+
+Once the host has a git clone, shipping a new version is two commands:
+
+```bash
+cd /opt/daybook
+git pull
+docker compose -f deploy/docker-compose.yml up -d --build
+```
+
+The entrypoint runs Django migrations on every start, so schema changes are
+picked up automatically. `deploy/.env` and `deploy/data/` are untouched by
+`git pull` since they aren't tracked in the repo.
+
+## Operational Commands
+
+```bash
+docker compose -f deploy/docker-compose.yml logs -f daybook
+docker compose -f deploy/docker-compose.yml restart daybook
+docker compose -f deploy/docker-compose.yml down
+docker compose -f deploy/docker-compose.yml up -d
+docker compose -f deploy/docker-compose.yml exec daybook python manage.py check
+docker compose -f deploy/docker-compose.yml exec daybook sh
+```
+
+## Backup And Restore
+
+Back up `deploy/data/` — it contains the SQLite database and all artifact
+files:
+
+```bash
+tar -czf daybook-data-$(date +%Y%m%d-%H%M%S).tar.gz -C /opt/daybook/deploy data
+```
+
+For a consistent snapshot during heavy writes, stop the container first:
+
+```bash
+docker compose -f deploy/docker-compose.yml down
+tar -czf daybook-data-$(date +%Y%m%d-%H%M%S).tar.gz -C /opt/daybook/deploy data
+docker compose -f deploy/docker-compose.yml up -d
+```
+
+To restore: stop Daybook, replace `deploy/data/` with the backup contents,
+then start it again.
+
+## Reverse Proxy Notes
+
+If putting Daybook behind Nginx, Caddy, Traefik, or a cloud load balancer:
+
+- Proxy to `http://<vm-ip>:8000`.
+- Add the public hostname to `DJANGO_ALLOWED_HOSTS`.
+- Terminate TLS at the proxy; keep `DJANGO_DEBUG=0`.
+
+```text
+DJANGO_ALLOWED_HOSTS=daybook.example.com,localhost,127.0.0.1
+```
+
+## Deployment Checklist
+
+- `deploy/.env` exists with a real (non-placeholder) `DJANGO_SECRET_KEY`.
+- `DJANGO_DEBUG=0`.
+- `DJANGO_ALLOWED_HOSTS` includes the hostname/IP being used.
+- `deploy/data/` exists and persists across `git pull` + rebuild.
+- `docker compose -f deploy/docker-compose.yml ps` shows `daybook` healthy.
+- `curl -fsS http://127.0.0.1:8000/api/capabilities` returns 403 without auth,
+  200 with a valid token or session.
+- At least one superuser exists (`manage.py createsuperuser`) with a token
+  from Settings → Account.
+
+## Known MVP Constraints
+
+- SQLite is used by default — fine for a single-VM self-hosted deployment.
+- Per-user ingest tokens; no shared/global token.
+- Reader/browser access requires login; feeds are private per user.
+- Manual drag/drop upload and content revisions are deferred.