Release v0.2.0: multiple named API keys per user

Replaces the single per-user DRF token with named, individually-revocable
API keys, so you can run one key per agent and cut off a leaked one without
disrupting the others.

- New ApiKey model (user, name, dbk_-prefixed key, created_at, last_used_at).
  Data migration copies every existing authtoken 1:1 into a "default" named
  key with the same value, so no client (incl. the sibling test project's
  hardcoded test-user key) needs reconfiguring.
- Auth (resolve_token_user) resolves against ApiKey and stamps last_used_at,
  throttled to one write/minute.
- Settings -> API Keys: table with name/key/created/last-used + per-row
  revoke and a create form; keys viewable on demand. Settings -> Account now
  links here; Settings -> Users issues a named initial key.
- Gated provisioning API for test installations: GET/POST /api/keys and
  DELETE /api/keys/{id}, controlled by DAYBOOK_KEY_PROVISIONING_API (unset ->
  follows DEBUG, so off in deployment). Advertised via key_provisioning_api
  in /api/capabilities; 403 when disabled.
- Docs (api/deployment/quickstart/posting-helper), SKILL.md, and env.example
  updated from "token / Settings -> Account" to "key / Settings -> API Keys".
- Tests: new API + UI suites for keys; existing token-based tests moved to
  ApiKey. Full suite 129 passing.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/agent_quickstart.md

@@ -2,10 +2,11 @@
 
 This is the shortest path for an agent to publish and retrieve artifacts from Daybook.
 
-## 0. Get Your API Token
+## 0. Get Your API Key
 
-Log in to the app in a browser and copy your personal token from **Settings → Account**
-(`http://127.0.0.1:8001/settings/account/`). Every artifact you post with it lands in your
+Log in to the app in a browser and create a personal key under **Settings → API Keys**
+(`http://127.0.0.1:8001/settings/api-keys/`). Name it after the agent so you can revoke it
+later. Every artifact you post with it lands in your
 feed, and only yours.
 
 ## 1. Check Capabilities

docs/api.md

@@ -8,13 +8,13 @@ Base URL while running locally:
 http://127.0.0.1:8001
 ```
 
-Authentication for write endpoints (POST/PATCH) — a personal per-user API token, from Settings → Account in the app:
+Authentication for write endpoints (POST/PATCH/DELETE) — a personal API key, created in the app under Settings → API Keys. Each user can hold several (one per agent/script) and revoke them individually:
 
 ```http
-Authorization: Bearer <your-personal-token>
+Authorization: Bearer <your-personal-key>
 ```
 
-Every artifact belongs to the user whose token authenticated the POST — feeds are private per user.
+Every artifact belongs to the user whose key authenticated the POST — feeds are private per user.
 
 Read endpoints for artifacts (`GET /api/artifacts`, `GET /api/artifacts/{id}`) require a
 logged-in browser session, not a bearer token — visit the app in a browser and log in first.
@@ -575,9 +575,40 @@ curl -H "Authorization: Bearer <your-personal-token>" http://127.0.0.1:8001/api/
 
 Discover it programmatically via `skill_url` in the capabilities response.
 
+## API Keys (provisioning)
+
+Keys are normally created and revoked in the app under **Settings → API Keys**.
+For automated test installations, a programmatic surface can provision them
+too — but it is **gated** and **off in deployment**, because it returns key
+material over the API.
+
+The gate is `DAYBOOK_KEY_PROVISIONING_API`. Unset, it follows `DJANGO_DEBUG`
+(on locally, off in production); set it explicitly (`0`/`1`) to override.
+`GET /api/capabilities` reports the current state as `key_provisioning_api`,
+and only lists the `/api/keys` methods when it's enabled. When disabled, every
+method below returns `403`.
+
+```http
+GET    /api/keys        # list this user's keys (incl. key values)
+POST   /api/keys        # body {"name": "hermes-agent"} -> the new key
+DELETE /api/keys/{id}   # revoke one key
+```
+
+Authenticated by a browser session **or** an existing bearer key, and only
+ever operates on the authenticated user's own keys.
+
+```bash
+# Create a new named key (test installations only)
+curl -X POST -H "Authorization: Bearer <existing-key>" \
+  -H "Content-Type: application/json" \
+  -d '{"name": "hermes-agent"}' \
+  http://127.0.0.1:8001/api/keys
+```
+
 ## Current MVP Constraints
 
-- Each user has a personal ingest API token; there is no shared token.
+- Each user can hold several personal API keys (Settings → API Keys), each
+  individually revocable; there is no shared key.
 - Reader/browser access requires login; feeds are private per user (except
   per-artifact public share links — see Sharing above).
 - Content modification/revisions are deferred (`PATCH` edits metadata only,

docs/deployment.md

@@ -64,9 +64,10 @@ 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`.
+There is no shared API token to configure — Daybook uses per-user API keys
+created under Settings → API Keys once a user exists (each user can hold
+several, one per agent, each individually revocable). Do not commit
+`deploy/.env`.
 
 Create the persistent data directory and bring the stack up:
 
@@ -94,7 +95,7 @@ that's expected; it confirms the app is up and enforcing auth. (Don't add
 `curl -f` — it treats the 403 as an error. The container healthcheck uses
 the login page, which is 200 without 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
+created, then create a personal key under Settings → API Keys and use it for a
 smoke-test post:
 
 ```bash
@@ -191,8 +192,8 @@ Caddy:   header_up X-Forwarded-Proto https
 - `docker compose -f deploy/docker-compose.yml ps` shows `daybook` healthy.
 - `GET /api/capabilities` returns 403 without auth, 200 with a valid token or
   session (check the status code — don't use `curl -f`, which errors on 403).
-- At least one superuser exists (`manage.py createsuperuser`) with a token
-  from Settings → Account.
+- At least one superuser exists (`manage.py createsuperuser`) with a key
+  from Settings → API Keys.
 
 ## Known MVP Constraints
 

docs/llm_posting_helper.md

@@ -24,7 +24,7 @@ DAYBOOK_TOKEN=your-personal-api-token
 DAYBOOK_SOURCE=agent
 ```
 
-`DAYBOOK_TOKEN` is a personal per-user token, from Settings → Account in the app — not a token shared across users. Override these per environment.
+`DAYBOOK_TOKEN` is a personal API key, created under Settings → API Keys in the app (one per agent, individually revocable) — not a key shared across users. Override these per environment.
 
 ## Commands