diff --git a/.gitignore b/.gitignore
index 624a5fc..7417b79 100644
--- a/.gitignore
+++ b/.gitignore
@@ -31,3 +31,10 @@ htmlcov/
 .vscode/
 .DS_Store
 Thumbs.db
+
+# Internal-only planning/ops docs (home infrastructure details)
+_archive_/
+planning/
+
+# Local machine-specific tool config (MCP servers, absolute local paths)
+opencode.json
diff --git a/_archive_/daybook-container-handoff.md b/_archive_/daybook-container-handoff.md
deleted file mode 100644
index a05e6c3..0000000
--- a/_archive_/daybook-container-handoff.md
+++ /dev/null
@@ -1,392 +0,0 @@
-# Daybook Container Handoff
-
-This document is for another AI/operator taking over Daybook deployment and operations on the Proxmox NUC.
-
-Last checked: 2026-06-11.
-
-## Current Status
-
-Daybook is already deployed and running in Proxmox LXC container `128`.
-
-| Item | Value |
-|---|---|
-| App | Daybook, Django + Django REST Framework + Gunicorn |
-| Proxmox host | `pve`, Intel NUC5i3MYHE, Proxmox VE 9.1.0 / Debian 13 |
-| Host LAN IP | `192.168.1.6` |
-| Host Tailscale IP | `100.76.55.68` |
-| Host SSH | `claude@proxmox.cygnus.internal` or `claude@nuc.cygnus.internal` |
-| Host web UI | `https://proxmox.cygnus.internal:8006` |
-| Host dashboard | `http://nuc.cygnus.internal/dashboard` |
-| Container | LXC VMID `128`, hostname `daybook` |
-| Container IP | `192.168.1.36/24` |
-| App URL | `http://192.168.1.36:8000/` |
-| API base URL | `http://192.168.1.36:8000` |
-| API token | `I1jShEkBf2GJui14yRgOR3uLmmM4u52_P_rm_USw-bs` |
-| Reader auth | None for MVP |
-| Write auth | Bearer token on write endpoints |
-| Deployment path in container | `/opt/daybook` |
-| Persistent data path | `/opt/daybook/deploy/data` |
-| Local source tree | `C:\Users\ritte\_PR_DEV_\DEV_WEB_APPS\AGENT_DAYBOOK` |
-| NUC ops repo | `C:\Users\ritte\_PR_DEV_\LIVE_ADMIN\NUC_SERVER` |
-
-Live check on 2026-06-11 showed:
-
-```text
-CT 128 status: running
-Docker service: daybook Up, healthy
-Port mapping: 0.0.0.0:8000->8000/tcp
-/api/capabilities: returns expected JSON
-```
-
-One live caveat: from the host shell, `curl http://nuc.cygnus.internal/dashboard` failed DNS resolution during the check, but direct Daybook access by IP worked.
-
-## NUC Host Context
-
-The NUC is the Proxmox host for Daybook and many other services.
-
-| Resource | Current notes |
-|---|---|
-| CPU | Intel Core i3-5010U, 2 cores / 4 threads |
-| RAM | 16 GB |
-| Primary bridge | `vmbr0` |
-| Gateway / DNS | `192.168.1.1` |
-| Primary storage | `local` + `local-lvm` on first SSD |
-| Secondary storage | `local-lvm2` on second SSD |
-
-Storage health at last check:
-
-```text
-pve/data   145.11g  89.60% used
-pve2/data  226.32g  42.46% used
-```
-
-Important: `pve/data` / `local-lvm` is close to the alert threshold. New larger VM/CT disks should normally go on `local-lvm2`. Daybook already uses `local-lvm2`.
-
-## Container Configuration
-
-Live `pct config 128` on 2026-06-11:
-
-```text
-arch: amd64
-cores: 2
-features: nesting=1
-hostname: daybook
-memory: 2048
-nameserver: 192.168.1.1
-net0: name=eth0,bridge=vmbr0,gw=192.168.1.1,hwaddr=BC:24:11:B6:C3:2D,ip=192.168.1.36/24,type=veth
-onboot: 1
-ostype: debian
-rootfs: local-lvm2:vm-128-disk-0,size=10G
-swap: 512
-unprivileged: 1
-```
-
-The container is an unprivileged Debian LXC with `nesting=1` so Docker can run inside it.
-
-## Application Layout
-
-Inside CT 128:
-
-```text
-/opt/daybook/
-  manage.py
-  requirements.txt
-  artifacts/
-  daybook_project/
-  templates/
-  static/
-  deploy/
-    .env
-    docker-compose.yml
-    Dockerfile
-    entrypoint.sh
-    data/
-      db.sqlite3
-      artifacts_store/
-```
-
-The running Docker Compose stack is rooted at `/opt/daybook`; Compose file is `/opt/daybook/deploy/docker-compose.yml`.
-
-The Docker service is named `daybook`. The image is built locally from `/opt/daybook/deploy/Dockerfile`.
-
-Compose essentials:
-
-```yaml
-services:
-  daybook:
-    build:
-      context: ..
-      dockerfile: deploy/Dockerfile
-    container_name: daybook
-    restart: unless-stopped
-    env_file:
-      - .env
-    ports:
-      - "8000:8000"
-    volumes:
-      - ./data:/data
-```
-
-The production `.env` is in `/opt/daybook/deploy/.env`. Minimum expected values:
-
-```text
-DJANGO_DEBUG=0
-DJANGO_ALLOWED_HOSTS=192.168.1.36,localhost,127.0.0.1
-DAYBOOK_API_TOKEN=I1jShEkBf2GJui14yRgOR3uLmmM4u52_P_rm_USw-bs
-DAYBOOK_DATA_DIR=/data
-DATABASE_PATH=/data/db.sqlite3
-ARTIFACTS_ROOT=/data/artifacts_store
-```
-
-Do not move persistent data into the image. Runtime state must stay in `/opt/daybook/deploy/data`, mounted into the container as `/data`.
-
-## Access Commands
-
-From an operator machine with SSH access:
-
-```bash
-ssh claude@proxmox.cygnus.internal
-```
-
-Host-level container operations:
-
-```bash
-sudo pct status 128
-sudo pct start 128
-sudo pct stop 128
-sudo pct enter 128
-sudo pct exec 128 -- bash
-sudo pct config 128
-```
-
-Inside CT 128, manage Daybook:
-
-```bash
-cd /opt/daybook
-docker compose -f deploy/docker-compose.yml ps
-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 up -d --build
-docker compose -f deploy/docker-compose.yml exec daybook python manage.py check
-```
-
-Host one-liners without entering the CT:
-
-```bash
-sudo pct exec 128 -- bash -lc 'cd /opt/daybook && docker compose -f deploy/docker-compose.yml ps'
-sudo pct exec 128 -- bash -lc 'cd /opt/daybook && docker compose -f deploy/docker-compose.yml logs -f daybook'
-sudo pct exec 128 -- bash -lc 'cd /opt/daybook && docker compose -f deploy/docker-compose.yml up -d --build'
-```
-
-## Health Checks
-
-From any machine that can reach the LAN:
-
-```bash
-curl -fsS http://192.168.1.36:8000/api/capabilities
-```
-
-Expected response includes:
-
-```json
-{
-  "artifact_kinds": ["html_fragment", "html_full", "markdown", "deck", "image", "pdf", "binary"],
-  "filters": ["persona", "day", "tag", "kind", "q"],
-  "views": ["rendered", "raw"],
-  "raw_supported_for": ["markdown", "html_full"],
-  "source_types": ["agent", "person", "system"],
-  "auth": "bearer_token"
-}
-```
-
-Host-level checks:
-
-```bash
-sudo pct status 128
-sudo pct exec 128 -- bash -lc 'cd /opt/daybook && docker compose -f deploy/docker-compose.yml ps'
-sudo pct exec 128 -- bash -lc 'test -f /opt/daybook/deploy/data/db.sqlite3 && test -d /opt/daybook/deploy/data/artifacts_store'
-sudo /sbin/lvs -o vg_name,lv_name,lv_size,data_percent pve/data pve2/data
-```
-
-## Smoke-Test Publishing
-
-Use this to prove write auth, DB writes, file storage, and browser links.
-
-```bash
-curl -fsS -X POST http://192.168.1.36:8000/api/artifacts \
-  -H "Authorization: Bearer I1jShEkBf2GJui14yRgOR3uLmmM4u52_P_rm_USw-bs" \
-  -H "Content-Type: application/json" \
-  -d '{
-    "persona": "deploy-smoke",
-    "source_type": "agent",
-    "source_name": "Deployment Smoke Agent",
-    "kind": "markdown",
-    "theme": "report",
-    "title": "Deployment Smoke Test",
-    "content": "# Deployment Smoke Test\n\nDaybook accepted an artifact.",
-    "tags": ["deploy", "smoke"],
-    "metadata": {"run_id": "deploy-smoke-001"}
-  }'
-```
-
-The response should include `id`, `url`, `api_url`, and `raw_url`. Open the returned `url` or refresh `http://192.168.1.36:8000/`.
-
-## Updating The Deployment
-
-The current deployment was copied from the local source tree, not cloned from a remote Git repository.
-
-Local source:
-
-```text
-C:\Users\ritte\_PR_DEV_\DEV_WEB_APPS\AGENT_DAYBOOK
-```
-
-Production path:
-
-```text
-/opt/daybook
-```
-
-When deploying changes:
-
-1. Preserve `/opt/daybook/deploy/.env`.
-2. Preserve `/opt/daybook/deploy/data`.
-3. Copy application source and deploy files to `/opt/daybook`.
-4. Exclude local dev artifacts such as `.venv`, local `db.sqlite3`, local `artifacts_store`, logs, and caches.
-5. Rebuild with `docker compose -f deploy/docker-compose.yml up -d --build`.
-6. Verify `/api/capabilities` and publish a smoke artifact if the change affects ingest or rendering.
-
-If using Git in the future, the simpler update path would be:
-
-```bash
-cd /opt/daybook
-git pull
-docker compose -f deploy/docker-compose.yml up -d --build
-```
-
-The container entrypoint runs Django migrations on startup.
-
-## Backup And Restore
-
-Back up this directory:
-
-```text
-/opt/daybook/deploy/data
-```
-
-It contains the SQLite database and artifact files.
-
-Quick backup from the Proxmox host:
-
-```bash
-sudo pct exec 128 -- bash -lc 'tar -czf /tmp/daybook-data-$(date +%Y%m%d-%H%M%S).tar.gz -C /opt/daybook/deploy data'
-```
-
-Consistent backup during heavy writes:
-
-```bash
-sudo pct exec 128 -- bash -lc 'cd /opt/daybook && docker compose -f deploy/docker-compose.yml down'
-sudo pct exec 128 -- bash -lc 'tar -czf /tmp/daybook-data-$(date +%Y%m%d-%H%M%S).tar.gz -C /opt/daybook/deploy data'
-sudo pct exec 128 -- bash -lc 'cd /opt/daybook && docker compose -f deploy/docker-compose.yml up -d'
-```
-
-Restore process:
-
-1. Stop Daybook with `docker compose -f /opt/daybook/deploy/docker-compose.yml down` inside CT 128.
-2. Replace `/opt/daybook/deploy/data` with restored data.
-3. Start with `docker compose -f /opt/daybook/deploy/docker-compose.yml up -d`.
-4. Verify capabilities and open the feed.
-
-## API Contract For Agents
-
-Base URL:
-
-```text
-http://192.168.1.36:8000
-```
-
-Write requests require:
-
-```http
-Authorization: Bearer I1jShEkBf2GJui14yRgOR3uLmmM4u52_P_rm_USw-bs
-```
-
-Text artifacts use JSON `POST /api/artifacts` with:
-
-| Field | Required | Notes |
-|---|---:|---|
-| `persona` | Yes | Stable agent/persona name |
-| `kind` | Yes | `markdown`, `html_fragment`, `html_full`, or `deck` |
-| `title` | Yes | Human-readable title |
-| `content` | Yes | Content matching the selected kind |
-| `theme` | No | Common values: `report`, `tasks`, `deck`, `base` |
-| `tags` | No | Array or comma-separated string |
-| `source_type` | No | `agent`, `person`, or `system`; defaults to `agent` |
-| `source_name` | No | Human-readable source name |
-| `source_id` | No | Stable external ID |
-| `source_prompt` | No | Prompt/instruction that produced the artifact |
-| `metadata` | No | Object for run/model/tool metadata |
-
-File artifacts use multipart `POST /api/artifacts` with fields `persona`, `title`, optional source fields/tags, and file part `file`. Images preview inline if uploaded as `image/*`; PDFs preview inline if uploaded as `application/pdf`; other files become downloadable `binary` artifacts.
-
-Rendering rules:
-
-| Kind | Send |
-|---|---|
-| `markdown` | Markdown text |
-| `html_fragment` | Body-only HTML; no `html`, `head`, or `body` tags |
-| `html_full` | Complete HTML document |
-| `deck` | One or more top-level `<section>...</section>` slide blocks |
-
-## Known Open Issues
-
-These matter for the next deployment/development agent.
-
-| ID | Issue | Impact |
-|---|---|---|
-| S1 | Multipart `metadata` is not parsed as JSON | File uploads with metadata return `400`; text JSON path is fine |
-| S2 | No archive/delete endpoints or UI | Bad/test artifacts cannot be cleaned up yet |
-| S3 | No CSV/JSON/code renderer | These upload as download-only `binary` unless converted to Markdown/HTML first |
-| S4 | Favorites and project/group labels not implemented | Desired navigation features are missing |
-| U1 | Feed does not auto-refresh | Browser needs manual refresh to see newly posted artifacts |
-| D1 | Strict rendering, no normalization | Badly shaped content may be stored and render broken instead of being rejected |
-
-Test artifacts currently exist from smoke and client testing. Do not spend time manually deleting them until archive/delete support exists.
-
-## Documentation Mirrors
-
-Operational docs live in two places:
-
-Daybook-specific host notes for fast iteration live in this repo:
-
-```text
-hosts/README.md
-hosts/nuc-daybook.md
-hosts/cloud-template.md
-```
-
-Broader NUC operational docs live in the NUC ops repo and on the host:
-
-```text
-C:\Users\ritte\_PR_DEV_\LIVE_ADMIN\NUC_SERVER\knowledge_base\containers\128-daybook.md
-C:\Users\ritte\_PR_DEV_\LIVE_ADMIN\NUC_SERVER\knowledge_base\daybook\api.md
-C:\Users\ritte\_PR_DEV_\LIVE_ADMIN\NUC_SERVER\knowledge_base\daybook\agent-posting.md
-/home/claude/knowledge_base/containers/128-daybook.md
-```
-
-When changing deployment, update the NUC knowledge base too. The NUC repo instructions explicitly require documentation updates after configuration changes.
-
-## Takeover Checklist
-
-Before making changes:
-
-1. SSH to the NUC host.
-2. Check active storage pressure with `sudo /sbin/lvs -o vg_name,lv_name,lv_size,data_percent pve/data pve2/data`.
-3. Check CT 128 with `sudo pct status 128` and `sudo pct config 128`.
-4. Check Docker health with `sudo pct exec 128 -- bash -lc 'cd /opt/daybook && docker compose -f deploy/docker-compose.yml ps'`.
-5. Check API health with `curl -fsS http://192.168.1.36:8000/api/capabilities`.
-6. Read the current local issue log: `planning/daybook-issues-log.md`.
-7. Preserve `.env` and `deploy/data` before copying or rebuilding.
-8. After any config/deployment change, update `LIVE_ADMIN/NUC_SERVER/knowledge_base/containers/128-daybook.md` and this handoff if the takeover facts changed.
diff --git a/_archive_/hosts/README.md b/_archive_/hosts/README.md
deleted file mode 100644
index 096f346..0000000
--- a/_archive_/hosts/README.md
+++ /dev/null
@@ -1,28 +0,0 @@
-# Daybook Hosts
-
-This directory tracks Daybook deployment targets for fast iteration.
-
-These notes are intentionally app-specific. They should answer: where is Daybook running, how do we update it, how do we verify it, and where does persistent Daybook data live?
-
-They are not a replacement for host administration docs. For the Proxmox NUC, the canonical infrastructure source remains the NUC ops repo:
-
-```text
-C:\Users\ritte\_PR_DEV_\LIVE_ADMIN\NUC_SERVER
-```
-
-## Deployment Targets
-
-| Host | Status | Notes |
-|---|---|---|
-| [NUC Daybook](nuc-daybook.md) | Live | Current local/LAN deployment in Proxmox LXC `128` |
-| [Cloud template](cloud-template.md) | Planned | Fill this in when a hosted/cloud instance is created |
-
-## Documentation Rule
-
-When a Daybook deployment changes, update the matching file here and the broader handoff doc if takeover facts changed:
-
-```text
-planning/daybook-container-handoff.md
-```
-
-When the NUC host/container configuration changes, also update the NUC ops knowledge base.
diff --git a/_archive_/hosts/cloud-template.md b/_archive_/hosts/cloud-template.md
deleted file mode 100644
index 552427b..0000000
--- a/_archive_/hosts/cloud-template.md
+++ /dev/null
@@ -1,85 +0,0 @@
-# Cloud Daybook Host Template
-
-Use this when creating a hosted/cloud Daybook deployment.
-
-Status: planned.
-
-## Summary
-
-| Item | Value |
-|---|---|
-| Provider | TBD |
-| Hostname | TBD |
-| Public URL | TBD |
-| SSH | TBD |
-| OS | TBD |
-| App user | TBD |
-| Deployment path | TBD |
-| Persistent data path | TBD |
-| API base URL | TBD |
-| TLS | TBD |
-| Backup location | TBD |
-
-## Target Runtime
-
-Preferred simple runtime for the first cloud deployment:
-
-```text
-Django + Gunicorn in Docker Compose
-```
-
-Required persistent state:
-
-```text
-deploy/data/db.sqlite3
-deploy/data/artifacts_store
-```
-
-Do not bake persistent data into the image.
-
-## Environment
-
-Expected production environment values:
-
-```text
-DJANGO_DEBUG=0
-DJANGO_ALLOWED_HOSTS=<hostnames and IPs>
-DAYBOOK_API_TOKEN=<write token>
-DAYBOOK_DATA_DIR=/data
-DATABASE_PATH=/data/db.sqlite3
-ARTIFACTS_ROOT=/data/artifacts_store
-```
-
-## Deployment Flow
-
-Initial deployment checklist:
-
-1. Provision host.
-2. Install Docker and Docker Compose plugin.
-3. Copy or clone Daybook source.
-4. Create production `.env`.
-5. Create persistent `deploy/data` directory.
-6. Start with `docker compose -f deploy/docker-compose.yml up -d --build`.
-7. Verify `/api/capabilities`.
-8. Publish a smoke artifact.
-9. Configure backups for `deploy/data`.
-
-## Health Checks
-
-```bash
-curl -fsS <api-base-url>/api/capabilities
-docker compose -f deploy/docker-compose.yml ps
-test -f deploy/data/db.sqlite3
-test -d deploy/data/artifacts_store
-```
-
-## Open Decisions
-
-| Decision | Options | Choice |
-|---|---|---|
-| Hosting provider | VPS, home tunnel, managed container host | TBD |
-| Domain | Existing domain, subdomain, direct IP | TBD |
-| TLS | Reverse proxy, provider load balancer, Tailscale-only | TBD |
-| Backups | Host cron, provider snapshots, object storage archive | TBD |
-| Database | SQLite for MVP, Postgres later | TBD |
-| Reader auth | None for MVP, basic auth, app auth | TBD |
diff --git a/_archive_/hosts/nuc-daybook.md b/_archive_/hosts/nuc-daybook.md
deleted file mode 100644
index ca14406..0000000
--- a/_archive_/hosts/nuc-daybook.md
+++ /dev/null
@@ -1,145 +0,0 @@
-# NUC Daybook Host
-
-Current Daybook deployment target for fast local iteration.
-
-Last checked: 2026-06-11.
-
-## Summary
-
-| Item | Value |
-|---|---|
-| Proxmox host | `pve`, Intel NUC5i3MYHE, Proxmox VE 9.1.0 / Debian 13 |
-| Host LAN IP | `192.168.1.6` |
-| Host Tailscale IP | `100.76.55.68` |
-| Host SSH | `claude@proxmox.cygnus.internal` or `claude@nuc.cygnus.internal` |
-| Container | LXC VMID `128`, hostname `daybook` |
-| Container IP | `192.168.1.36/24` |
-| App URL | `http://192.168.1.36:8000/` |
-| API base URL | `http://192.168.1.36:8000` |
-| Deployment path | `/opt/daybook` |
-| Persistent data path | `/opt/daybook/deploy/data` |
-| Local source tree | `C:\Users\ritte\_PR_DEV_\DEV_WEB_APPS\AGENT_DAYBOOK` |
-| NUC ops repo | `C:\Users\ritte\_PR_DEV_\LIVE_ADMIN\NUC_SERVER` |
-
-Write requests use the Daybook bearer token configured in `/opt/daybook/deploy/.env` as `DAYBOOK_API_TOKEN`.
-
-## Runtime Shape
-
-Daybook runs in Docker Compose inside unprivileged Debian LXC `128` with `nesting=1` enabled.
-
-Compose root:
-
-```text
-/opt/daybook
-```
-
-Compose file:
-
-```text
-/opt/daybook/deploy/docker-compose.yml
-```
-
-Persistent state must stay outside the image:
-
-```text
-/opt/daybook/deploy/data
-```
-
-That directory contains the SQLite database and stored artifacts.
-
-## Fast Update Loop
-
-From the Proxmox host, rebuild the running Daybook service inside CT `128`:
-
-```bash
-sudo pct exec 128 -- bash -lc 'cd /opt/daybook && docker compose -f deploy/docker-compose.yml up -d --build'
-```
-
-Before copying source or rebuilding, preserve:
-
-```text
-/opt/daybook/deploy/.env
-/opt/daybook/deploy/data
-```
-
-The current deployment was copied from the local source tree rather than cloned from a remote Git repository.
-
-## Health Checks
-
-From a machine that can reach the LAN:
-
-```bash
-curl -fsS http://192.168.1.36:8000/api/capabilities
-```
-
-From the Proxmox host:
-
-```bash
-sudo pct status 128
-sudo pct config 128
-sudo pct exec 128 -- bash -lc 'cd /opt/daybook && docker compose -f deploy/docker-compose.yml ps'
-sudo pct exec 128 -- bash -lc 'test -f /opt/daybook/deploy/data/db.sqlite3 && test -d /opt/daybook/deploy/data/artifacts_store'
-```
-
-Storage check:
-
-```bash
-sudo /sbin/lvs -o vg_name,lv_name,lv_size,data_percent pve/data pve2/data
-```
-
-Important: `local-lvm` / `pve/data` was near the alert threshold at last check. New larger VM/CT disks should normally go on `local-lvm2`. Daybook already uses `local-lvm2`.
-
-## Smoke Publish
-
-Use this after ingest, rendering, or deployment changes. Replace the token with the value from `/opt/daybook/deploy/.env` if it changes.
-
-```bash
-curl -fsS -X POST http://192.168.1.36:8000/api/artifacts \
-  -H "Authorization: Bearer $DAYBOOK_API_TOKEN" \
-  -H "Content-Type: application/json" \
-  -d '{
-    "persona": "deploy-smoke",
-    "source_type": "agent",
-    "source_name": "Deployment Smoke Agent",
-    "kind": "markdown",
-    "theme": "report",
-    "title": "Deployment Smoke Test",
-    "content": "# Deployment Smoke Test\n\nDaybook accepted an artifact.",
-    "tags": ["deploy", "smoke"],
-    "metadata": {"run_id": "deploy-smoke-001"}
-  }'
-```
-
-The response should include `id`, `url`, `api_url`, and `raw_url`. Open the returned `url` or refresh the feed.
-
-## Backup Target
-
-Back up this directory:
-
-```text
-/opt/daybook/deploy/data
-```
-
-Quick host-side backup command:
-
-```bash
-sudo pct exec 128 -- bash -lc 'tar -czf /tmp/daybook-data-$(date +%Y%m%d-%H%M%S).tar.gz -C /opt/daybook/deploy data'
-```
-
-For heavy write activity, stop the Compose service before archiving and start it again afterward.
-
-## Related Docs
-
-Broader deployment handoff:
-
-```text
-planning/daybook-container-handoff.md
-```
-
-NUC infrastructure docs:
-
-```text
-C:\Users\ritte\_PR_DEV_\LIVE_ADMIN\NUC_SERVER\knowledge_base\containers\128-daybook.md
-C:\Users\ritte\_PR_DEV_\LIVE_ADMIN\NUC_SERVER\knowledge_base\daybook\api.md
-C:\Users\ritte\_PR_DEV_\LIVE_ADMIN\NUC_SERVER\knowledge_base\daybook\agent-posting.md
-```
diff --git a/artifacts/views.py b/artifacts/views.py
index 498ce12..758b2c1 100644
--- a/artifacts/views.py
+++ b/artifacts/views.py
@@ -243,6 +243,16 @@ class ArtifactDetailView(APIView):
         )
         return Response(serialize_artifact(artifact, request))
 
+    def delete(self, request, artifact_id):
+        user = resolve_token_user(request)
+        if user is None:
+            return HttpResponseForbidden("Invalid or missing API token")
+
+        artifact = get_object_or_404(Artifact, pk=artifact_id, owner=user)
+        delete_artifact_files(artifact)
+        artifact.delete()
+        return Response(status=204)
+
 
 class CapabilitiesView(APIView):
     """Static capability info. Reachable by a logged-in session or a valid API token,
@@ -259,6 +269,11 @@ class CapabilitiesView(APIView):
                 "raw_supported_for": [Artifact.MARKDOWN, Artifact.HTML_FULL],
                 "source_types": [choice[0] for choice in Artifact.SOURCE_TYPE_CHOICES],
                 "auth": "bearer_token",
+                "methods": {
+                    "/api/artifacts": ["GET", "POST"],
+                    "/api/artifacts/{id}": ["GET", "PATCH", "DELETE"],
+                    "/api/assets": ["POST"],
+                },
             }
         )
 
diff --git a/opencode.json b/opencode.json
deleted file mode 100644
index 631cb48..0000000
--- a/opencode.json
+++ /dev/null
@@ -1,18 +0,0 @@
-{
-  "$schema": "https://opencode.ai/config.json",
-  "instructions": ["CLAUDE.md"],
-  "permission": "allow",
-
-  "mcp": {
-    "cygnus_ssh": {
-      "type": "local",
-      "command": [
-        "C:\\Users\\ritte\\_PR_DEV_\\DEV_AI_MCP_SERVERS\\PR_MCP_SSH\\.venv\\Scripts\\python.exe",
-        "C:\\Users\\ritte\\_PR_DEV_\\DEV_AI_MCP_SERVERS\\PR_MCP_SSH\\mcp_ssh_server.py",
-        "--config",
-        "C:\\Users\\ritte\\.mcp_ssh_hosts.toml"
-      ],
-      "enabled": true
-    }
-  }
-}
diff --git a/planning/daybook-issues-log.md b/planning/daybook-issues-log.md
deleted file mode 100644
index 9fa3229..0000000
--- a/planning/daybook-issues-log.md
+++ /dev/null
@@ -1,163 +0,0 @@
-# Daybook — Issues Found During LLM-Posting Testing
-
-**Date:** 2026-06-10
-**Context:** Found while smoke-testing the deployed instance (`192.168.1.36:8000`)
-and hardening the `daybook-posting` skill's `daybook_post.py` helper. Auth/
-reachability items are tracked separately in
-`planning/next_steps/llm-posting-skill-plan.md` and not duplicated here.
-
-Severity key: **High** = blocks a stated feature · **Med** = degrades UX or
-correctness · **Low** = cosmetic. Status: **Open** / **Fixed** / **By design**.
-
----
-
-## Open — Server-Side
-
-### S1 · Multipart `metadata` field is not parsed as a JSON object — **High / Open**
-
-- **Symptom:** Any file upload (multipart) that includes a `metadata` field returns
-  `HTTP 400 {"detail":"metadata must be an object"}`.
-- **Repro:** `python daybook_post.py test.svg --meta run_id=1` (or any `--file` +
-  `--meta`). Text artifacts (JSON path) are unaffected — they send a real object.
-- **Root cause:** The multipart handler reads `metadata` as a raw form string and
-  type-checks it against `dict` without `json.loads`. A stringified `{}` or
-  `{"k":"v"}` therefore fails the check.
-- **Impact:** Machine-readable metadata (run_id, model, etc.) cannot be attached to
-  image/pdf/binary artifacts — only to text artifacts.
-- **Fix:** In the multipart code path, `json.loads` the `metadata` form field before
-  validating, mirroring the JSON path. Confirm `tags` is handled consistently
-  (currently sent as a comma string and split server-side).
-- **Client workaround in place:** the helper now omits `metadata` from multipart
-  when empty, so metadata-less uploads work. Non-empty metadata on uploads still
-  needs this server fix.
-
-### S2 · Users cannot delete or archive artifacts (artifacts are immutable) — **High / Open**
-
-- **Requirement:** Users need to be able to **archive** and **delete** artifacts —
-  both as API endpoints and as controls in the web UI.
-- **Symptom:** There is no delete endpoint, and `content`/`kind`/`persona`/`day`
-  are not editable. The malformed test deck `5df27410` and the session's test
-  artifacts can only be superseded, never removed or hidden.
-- **Impact:** Test and mistake artifacts accumulate permanently in the feed with no
-  way for a user to clean it up.
-- **Fix — two distinct actions:**
-  - **Archive:** user-initiated, hides the artifact from the default feed but
-    retains it and allows restore. Needs an archive/unarchive endpoint, a default
-    feed filter that excludes archived items, and a UI control (plus an
-    "archived" view).
-  - **Delete:** user-initiated permanent removal (or a soft-delete tombstone).
-    Needs a `DELETE` endpoint, a UI control with a confirm step, and removal of the
-    stored content/raw file.
-- **Related:** consider allowing content replacement for an existing id (revision),
-  which would also address re-posting a corrected artifact.
-
-### S3 · No renderer for CSV / JSON / code — **Med / Open**
-
-- **Symptom:** These upload as download-only `binary` (e.g. `test.csv` →
-  `c562128b`, kind `binary`).
-- **Impact:** Tabular/code artifacts aren't viewable inline.
-- **Fix:** Add a renderer, or formally bless the client's `--as-markdown` fenced-
-  block convention as the interim path and document it.
-
-### S4 · Favorites and project/group labels — **Med / Open**
-
-- **Requirement:** Users want to (a) mark artifacts as **favorites**, and (b) label
-  artifacts as belonging to a **group / project**. The group/project label must be
-  **settable at upload time** (and editable afterward). Favorite is primarily a UI
-  toggle but should also be settable at upload.
-- **Design notes:**
-  - **Keep this distinct from `tags`.** Tags are many free-form filter labels; a
-    project/group is a first-class, usually single container used for navigation and
-    grouping. Recommend a dedicated `project` (or `group`) field rather than
-    overloading tags. `favorite` is a boolean, not a tag.
-  - **Data model:** add `favorite: bool = false` and `project: str | null` to the
-    artifact record.
-- **Scope — server / client / UI:**
-  - **Server:** accept `favorite` and `project` on POST; add endpoints to toggle
-    favorite and set/clear project after upload; support `?project=` and
-    `?favorite=true` feed filters.
-  - **Client (`daybook_post.py`):** add `--project NAME` and `--favorite` flags,
-    sent as first-class JSON/form fields — NOT inside `metadata` (see S1, which
-    breaks for multipart string fields).
-  - **UI:** a favorite (star) toggle and a favorites view; group/filter the feed by
-    project.
-
----
-
-## Open — Web UI
-
-### U1 · Feed does not refresh when new artifacts arrive — **Med / Open**
-
-- **Symptom:** The web UI renders a static snapshot of the feed. Artifacts posted
-  after the page loads do not appear until the user manually reloads.
-- **Impact:** Agents publish continuously, but a human watching the feed silently
-  misses new arrivals — which undercuts Daybook's purpose as a live journal of
-  agent output. Observed throughout this session: each test post required a manual
-  browser refresh to show up.
-- **Fix options (simplest first):**
-  - Client-side polling of the list endpoint on an interval (e.g. every few
-    seconds), diffing against the loaded set.
-  - Server-sent events (SSE) for push updates — a natural fit for this
-    publish-only, append-mostly model and lighter than WebSockets.
-  - To avoid disrupting scroll position, surface a "N new artifacts — click to
-    load" indicator rather than auto-injecting items at the top.
-
----
-
-## By Design — Worth a Decision
-
-### D1 · Strict rendering, no normalization — **By design**
-
-- **Behavior:** "Daybook does not fix malformed content." Wrong-shaped content is
-  stored and rendered as-is.
-- **Observed consequence:** Markdown sent to `deck` (`5df27410`) was stored and
-  rendered malformed — no error, just broken output.
-- **Implication:** A validating client is load-bearing. The server's per-kind
-  structure rules and the client's pre-flight checks must stay in sync; if the
-  server adds a kind, the client's validation/sniffing must follow.
-- **Optional improvement:** Consider rejecting obviously-malformed content with a
-  `422` (e.g. `deck` with no `<section>`) so it fails loud at post time rather than
-  rendering broken later. This complements, not replaces, the client guard.
-
----
-
-## Fixed — Client (recorded for traceability)
-
-### C1 · Empty `metadata` broke all multipart uploads — **Fixed**
-
-- The helper serialized empty `metadata` as the string `"{}"` into the multipart
-  body, triggering S1's 400 even when no metadata was supplied.
-- **Fix:** omit empty optional fields (`metadata`, `tags`, `source_id`,
-  `source_prompt`) from the multipart body, restoring the minimal known-good shape.
-
-### C2 · `html_full` client validation was over-strict — **Fixed**
-
-- Originally required BOTH `<!doctype` AND `<html>`; an auto-sniffed full page
-  lacking an explicit doctype was rejected.
-- **Fix:** require `<html>` only (doctype recommended, not mandatory).
-
----
-
-## Minor / Cosmetic
-
-### M1 · `deck` title inference picks the first slide heading — **Low / Open**
-
-- Auto mode derived the title "Slide One" from a deck's first `<h1>` (`ac6da43f`).
-  Correct but awkward as a title.
-- **Fix:** for `deck`, prefer the filename over the first `<h1>`.
-
-### M2 · CSV content-type guessed as `application/vnd.ms-excel` on Windows — **Low / Open**
-
-- Python's `mimetypes` maps `.csv` to `application/vnd.ms-excel` on this host rather
-  than `text/csv`. Harmless — the server still stores it as `binary` — but
-  inconsistent with the earlier manual `text/csv` upload.
-- **Fix (optional):** force `text/csv` for `.csv` in the client's `content_type_for`.
-
----
-
-## Test Artifacts Created (for cleanup once S2 lands)
-
-Auto-mode validation posts under persona `claude`, tag `auto-test`:
-`e7a769c5` (markdown), `2d162697` (html_full), `49291e85` (html_fragment),
-`ac6da43f` (deck), `3ad914cc` (image), `794d29e8` (pdf), `c562128b` (binary).
-Plus earlier manual smoke-test artifacts and the malformed deck `5df27410`.
diff --git a/planning/daybook_planning.md b/planning/daybook_planning.md
deleted file mode 100644
index 97df5dd..0000000
--- a/planning/daybook_planning.md
+++ /dev/null
@@ -1,217 +0,0 @@
-# Daybook — Project Planning
-
-## Purpose
-
-**Daybook** is a self-hosted web application where AI agents publish their
-outputs (task lists, research reports, slide decks, images, etc.) and a human
-browses them in a **time-ordered, agent-filterable feed** — viewing everything
-**in-browser without downloading or "opening" files**.
-
-The defining feature is the integration: an agent calls a REST API and posts
-*content*, not files. For HTML it can send just a body fragment and Daybook
-supplies the CSS. The agent never deals with styling, file naming, or storage.
-
-## Core principles
-
-- **View, don't download.** Everything renders inline in the browser.
-- **Agent-agnostic.** Any agent/persona can publish; the human filters by persona.
-- **Time-ordered.** The primary axis is the day; flipping back to yesterday is trivial.
-- **Minimal agent burden.** Agents send content + a few metadata fields. The server
-  owns styling, storage layout, IDs, and dates.
-- **Self-hosted.** A single deployable unit running on the user's own machine/server.
-- **Dumb viewer, smart ingest.** Normalize every input to three browser-native forms
-  (HTML, image, PDF) at upload time, so the viewer never needs plugins.
-
-## Actors
-
-- **Agent (publisher):** an authenticated machine client (e.g. Claude Code, a
-  persona script). POSTs artifacts via REST.
-- **Human (reader):** browses, filters, and views artifacts; later edits markdown
-  and shares links.
-
-## Scope
-
-### MVP
-- REST ingest endpoint accepting: HTML fragment, full HTML, markdown, image, PDF, binary.
-- Server-side **named CSS themes**; automatic wrapping of HTML fragments.
-- Storage in a `persona/day/id` layout plus a metadata table.
-- Web viewer: reverse-chronological feed, persona filter, in-browser rendering.
-
-### Later
-- In-browser **markdown editing** with write-back (the name "Daybook" anticipates this).
-- Slide decks via a **reveal.js** theme; `pptx`/`docx`/`xlsx` → PDF fallback.
-- **Share links** (password + expiry) for individual artifacts.
-- Tags, search, and full-text indexing.
-
-## Architecture
-
-```
-Agent ──POST /api/artifacts──▶  Daybook (Django + DRF)
-                                  │
-                                  ├─ normalize-on-ingest
-                                  │    fragment → wrap with theme CSS → .html
-                                  │    markdown → render → .html
-                                  │    deck     → reveal.js scaffold → .html
-                                  │    office   → LibreOffice headless → .pdf
-                                  │    image/pdf → store as-is
-                                  │
-                                  ├─ write file to  artifacts/{persona}/{day}/{id}.{ext}
-                                  └─ insert Artifact row (metadata index)
-
-Human ──GET / (feed)──▶  list Artifact rows (reverse-chron, persona filter)
-       ──GET /a/{id}──▶  render via <iframe> (html/pdf) or <img> (image)
-```
-
-The viewer only ever handles **HTML, image, or PDF**, because everything is
-collapsed into those three at ingest. No client-side office/pptx rendering.
-
-## Data model
-
-`Artifact`
-
-| Field | Type | Notes |
-|---|---|---|
-| `id` | str (8-char) | short unique id, used in URLs (`/a/{id}`) |
-| `persona` | str (indexed) | the agent that published it; primary filter |
-| `title` | str | display title |
-| `kind` | str | `html_fragment` \| `html_full` \| `markdown` \| `deck` \| `image` \| `pdf` \| `binary` |
-| `theme` | str | named CSS theme used at render (nullable) |
-| `day` | date (indexed) | publication day; feed grouping key |
-| `created_at` | datetime | exact timestamp |
-| `path` | str | relative path to stored, normalized file |
-| `original_kind` | str | what the agent sent, pre-normalization (audit) |
-| `tags` | json/list | later: filtering/search |
-| `source_prompt` | text | optional: the prompt that produced it |
-
-Share fields (`share_token`, `share_expires`, `share_password_hash`) added in the
-share-links milestone, not MVP.
-
-## REST API (MVP contract)
-
-All ingest endpoints require an API token (per-persona; see Open Questions).
-
-### `POST /api/artifacts`  (JSON — text content)
-```json
-{
-  "persona": "hermes",
-  "kind": "html_fragment",        // or html_full | markdown | deck
-  "theme": "report",              // optional; defaults per kind
-  "title": "Daily Tasks 2026-06-10",
-  "content": "<h1>Today</h1><ul><li>...</li></ul>",
-  "tags": ["tasks"],              // optional
-  "source_prompt": "..."          // optional
-}
-```
-Response: `{ "id": "a1b2c3d4", "url": "/a/a1b2c3d4" }`
-
-### `POST /api/artifacts`  (multipart — binary)
-Fields: `persona`, `title`, `tags`; file part `file` (image / pdf / office).
-Office/deck files are converted to PDF on ingest.
-
-### `GET /api/artifacts?persona=&day=&tag=`
-Returns metadata list (reverse-chronological). Drives the feed.
-
-### `GET /a/{id}`
-Serves the rendered artifact (HTML/PDF/image) for inline viewing.
-
-## Theming (server-side CSS)
-
-The server owns styling so agents can send markup only. Themes live as static
-files and are selected by name in the POST body:
-
-```
-static/themes/report.css
-static/themes/tasks.css
-static/themes/deck.css        # reveal.js theme
-static/themes/base.css        # default
-```
-
-Fragment wrapping (conceptual):
-
-```python
-WRAP = """<!doctype html><html><head><meta charset="utf-8">
-<link rel="stylesheet" href="/static/themes/{theme}.css">
-<title>{title}</title></head>
-<body class="artifact">{body}</body></html>"""
-```
-
-- `html_fragment` → wrapped with the chosen theme.
-- `markdown` → rendered to HTML, then wrapped.
-- `deck` → wrapped in reveal.js scaffold (agent sends `<section>` blocks).
-- `html_full` → stored verbatim (agent owns everything).
-
-## Ingest normalization pipeline
-
-| Agent sends | Step | Stored as | Viewer |
-|---|---|---|---|
-| HTML fragment | wrap + theme | `.html` | iframe |
-| Full HTML | verbatim | `.html` | iframe |
-| Markdown | render + wrap | `.html` | iframe |
-| Deck (sections) | reveal.js wrap | `.html` | iframe |
-| Image | verbatim | image | `<img>` |
-| PDF | verbatim | `.pdf` | native / pdf.js |
-| pptx/docx/xlsx | LibreOffice → PDF | `.pdf` | native / pdf.js |
-
-## Viewer
-
-- **Feed view (`/`):** reverse-chronological list grouped by day, with a persona
-  filter (dropdown or sidebar) and, later, tag/search. Each entry shows title,
-  persona, time, and kind.
-- **Artifact view (`/a/{id}`):** renders inline — `<iframe>` for HTML/PDF,
-  `<img>` for images. No download step required (download remains available).
-- Markdown edit (later): the stored source markdown is editable in-browser and
-  re-rendered on save; keep the original `.md` alongside the rendered `.html`.
-
-## Storage layout
-
-```
-artifacts/
-  {persona}/
-    {YYYY-MM-DD}/
-      {id}.html | {id}.pdf | {id}.png ...
-      {id}.md            # kept when source is markdown (for editing)
-```
-
-Files on disk stay greppable, portable, and trivially backed up; the DB is an
-index over them, not the source of truth for content.
-
-## Tech stack
-
-- **Django + Django REST Framework** — API, metadata, viewer.
-- **SQLite** (dev) → **PostgreSQL** (later) for the metadata index.
-- **Files on disk** for artifact content.
-- **LibreOffice headless** in the container for office/deck → PDF.
-- **markdown** (python-markdown) for md rendering; **reveal.js** for decks.
-- **pdf.js** optional, only if the native PDF viewer is unsatisfactory.
-- **Docker** — single image, self-hosted.
-
-## Milestones
-
-1. **M1 — Core ingest + storage.** `Artifact` model, JSON POST for
-   `html_fragment`/`html_full`/`markdown`, theme wrapping, disk write, `/a/{id}` view.
-2. **M2 — Viewer.** Feed (`/`) with reverse-chron listing and persona filter;
-   inline iframe/img rendering.
-3. **M3 — Binary + conversion.** Multipart upload; image/PDF passthrough;
-   LibreOffice headless for office/deck → PDF.
-4. **M4 — Decks.** reveal.js theme + `deck` kind.
-5. **M5 — Editing.** In-browser markdown edit + re-render.
-6. **M6 — Sharing.** Share tokens with password + expiry.
-7. **M7 — Search/tags.** Tag filter and full-text search.
-
-## Future features
-
-- Per-persona dashboards / stats.
-- Webhooks or "latest artifact" endpoints for chaining agents.
-- Retention/archival policies per persona.
-- Multi-user reader auth with per-persona visibility.
-- **Interactive questions artifact type:** agents send JSON with multiple-choice questions; viewer renders an interactive form; user selections are sent back to the agent via message queue, email, or API callback. Use cases: agent feedback loops, preference gathering, approval workflows.
-
-## Open questions / decisions
-
-- **Output standardization:** push agents toward HTML/markdown/reveal.js
-  (cheap, robust) vs. accept native office files (LibreOffice conversion is the
-  heaviest, flakiest path). Recommendation: prefer the former, keep conversion
-  as a fallback.
-- **Agent auth:** one API token per persona, or a shared token + persona field?
-- **Reader auth:** single-user (simplest) vs. multi-user from the start?
-- **ID scheme:** random short id vs. date-prefixed sortable id.
diff --git a/planning/framework_artifact_rendering.md b/planning/framework_artifact_rendering.md
deleted file mode 100644
index 8a53060..0000000
--- a/planning/framework_artifact_rendering.md
+++ /dev/null
@@ -1,275 +0,0 @@
-# Framework-Aware Artifact Rendering Ideas
-
-Daybook currently supports a useful split between server-owned rendering and agent-owned rendering:
-
-- `markdown`: agent sends Markdown; Daybook renders and wraps it.
-- `html_fragment`: agent sends body-only HTML; Daybook owns the shell and theme CSS.
-- `html_full`: agent sends the complete HTML document and owns all presentation.
-- `deck`: agent sends slide sections; Daybook wraps them as a simple deck.
-
-The next design question is how to let agents use established CSS/component frameworks without making every artifact depend on arbitrary external assets or custom page shells.
-
-## Core Principle
-
-Agents should publish content, not storage paths or app internals.
-
-For framework-aware artifacts, the preferred model is:
-
-```text
-Agent sends framework-compatible body markup
-Daybook selects/owns the framework CSS and page shell
-Browser renders a consistent artifact preview
-```
-
-This preserves the Daybook principle while giving LLMs a known design vocabulary.
-
-## Current Option: `html_full`
-
-Agents can already use any framework by posting `html_full` and including the framework assets themselves.
-
-Example with Bootstrap CDN:
-
-```json
-{
-  "persona": "athena",
-  "kind": "html_full",
-  "title": "Bootstrap Report",
-  "content": "<!doctype html><html lang=\"en\"><head><meta charset=\"utf-8\"><meta name=\"viewport\" content=\"width=device-width, initial-scale=1\"><title>Bootstrap Report</title><link href=\"https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/css/bootstrap.min.css\" rel=\"stylesheet\"></head><body><main class=\"container py-4\"><div class=\"alert alert-success\">Bootstrap artifact rendered by Daybook.</div></main></body></html>"
-}
-```
-
-Pros:
-
-- Works today.
-- Gives the agent total layout control.
-- Supports any CSS/JS framework.
-
-Cons:
-
-- CDN dependencies may fail offline.
-- External assets can change or disappear.
-- Agents must generate a correct full HTML document.
-- Visual consistency across artifacts is weaker.
-- Security/trust boundaries are looser if arbitrary scripts are included.
-
-## Preferred Future Option: Framework Themes For `html_fragment`
-
-Add Daybook-owned themes that include vendored framework CSS.
-
-Example payload:
-
-```json
-{
-  "persona": "athena",
-  "kind": "html_fragment",
-  "theme": "bootstrap",
-  "title": "Run Summary",
-  "content": "<main class=\"container py-4\"><div class=\"alert alert-success\">Run complete</div></main>"
-}
-```
-
-In this model:
-
-- Agent sends body-only framework-compatible markup.
-- Daybook wraps it in the HTML shell.
-- Daybook links local framework CSS from `static/vendor/...` or `static/themes/...`.
-- Daybook remains responsible for stable rendering.
-
-Pros:
-
-- Keeps artifacts self-hosted and predictable.
-- Lets agents use known class vocabularies.
-- Avoids requiring every agent to write `<head>` boilerplate.
-- Preserves the current `html_fragment` contract.
-
-Cons:
-
-- Daybook must vendor and maintain selected frameworks.
-- Agents must know which theme/framework is selected.
-- Some frameworks expect JavaScript or build tooling.
-
-## Candidate Frameworks
-
-| Framework | Best for | Fit for Daybook |
-|---|---|---|
-| Bootstrap | Reports, cards, grids, alerts, forms | Strong first candidate. Familiar to LLMs and humans. |
-| Pico CSS | Clean semantic documents | Excellent for low-class, readable reports. |
-| Bulma | CSS-only layouts/components | Good middle ground; no JS required. |
-| Tufte CSS | Research notes, essays, analytical reports | Good specialized report style. |
-| Water.css | Simple semantic HTML styling | Good for zero-effort readable HTML. |
-| MVP.css | Semantic HTML documents | Good for basic generated reports. |
-| Sakura.css | Minimal text-heavy documents | Good for simple readable pages. |
-| Tailwind CSS | Highly custom layouts | Powerful but less ideal without a build step. CDN possible for experiments. |
-| DaisyUI | Tailwind components | Useful but depends on Tailwind. Better later. |
-| Flowbite | Tailwind components | Useful but heavier and Tailwind-dependent. |
-| UIKit | Polished dashboards/docs | Possible but less common. |
-| Shoelace | Web components | Rich components, but requires JS custom elements. Better later. |
-| Reveal.js | Real slide decks | Strong future replacement/upgrade for current `deck`. |
-| Mermaid | Diagrams | Not CSS, but important for diagram artifacts. |
-| Prism.js / Highlight.js | Code artifacts | Needed for future code renderer. |
-| Tabulator / DataTables | CSV/table artifacts | Needed for future table renderer. |
-| JSON viewer libraries | JSON artifacts | Needed for future structured JSON renderer. |
-
-## Recommended Initial Set
-
-Start small with CSS-only or mostly CSS-only frameworks:
-
-1. `bootstrap`
-2. `pico`
-3. `bulma`
-4. `tufte`
-
-Reasons:
-
-- No build step required.
-- Easy for LLMs to emit usable classes/semantic HTML.
-- Useful for the most common artifact types: reports, cards, summaries, dashboards, and notes.
-- Can be vendored locally and served through Django static files.
-
-Defer heavier or JS-dependent frameworks until there is a concrete artifact need.
-
-## Theme Naming Idea
-
-Existing themes:
-
-- `report`
-- `tasks`
-- `deck`
-- `base`
-
-Potential additions:
-
-- `bootstrap`
-- `pico`
-- `bulma`
-- `tufte`
-- `water`
-
-Agents would specify the theme in the existing `theme` field for `html_fragment` and `markdown` where appropriate.
-
-## Storage/Vendoring Idea
-
-Use local static assets rather than CDN links:
-
-```text
-static/
-  vendor/
-    bootstrap/
-      bootstrap.min.css
-    bulma/
-      bulma.min.css
-    pico/
-      pico.min.css
-    tufte/
-      tufte.min.css
-  themes/
-    bootstrap.css
-    bulma.css
-    pico.css
-    tufte.css
-```
-
-Theme files can either be the vendored framework directly or thin wrappers that import vendor CSS and add Daybook-specific print/preview fixes.
-
-Example:
-
-```css
-@import url("/static/vendor/bootstrap/bootstrap.min.css");
-
-body.artifact {
-  background: #f8f9fa;
-}
-```
-
-## CDN Policy
-
-CDN links are acceptable for quick experiments using `html_full`, but should not be the default for reliable self-hosted deployments.
-
-Recommended policy:
-
-- MVP experimentation: allow `html_full` with CDN links.
-- Durable/self-hosted rendering: prefer vendored local CSS themes.
-- Deployment docs should warn that CDN-dependent artifacts may not render offline.
-
-## Security Notes
-
-Framework CSS is relatively safe. Framework JavaScript needs more care.
-
-Riskier artifact types:
-
-- `html_full` with arbitrary scripts.
-- JS component frameworks.
-- Web components loaded from CDNs.
-
-Current MVP assumes trusted local/self-hosted use. If Daybook later supports untrusted artifact authors or sharing, it should revisit sandboxing and CSP policies.
-
-## Relationship To Future Renderers
-
-Framework themes are separate from future dedicated renderers.
-
-Future renderers likely need their own artifact kinds:
-
-- `json`: collapsible JSON viewer, raw source preserved.
-- `csv`: searchable/sortable table, raw CSV preserved.
-- `code`: syntax-highlighted code, raw source preserved.
-- `diagram`: Mermaid/Graphviz/PlantUML source rendered to SVG/HTML, raw source preserved.
-- `audio`: browser audio player.
-- `video`: browser video player.
-
-These should use established libraries rather than custom viewers:
-
-- JSON viewer library for JSON.
-- Tabulator or DataTables for CSV/table artifacts.
-- Prism.js or Highlight.js for code.
-- Mermaid for Mermaid diagrams.
-- Native `<audio controls>` and `<video controls>` for media.
-
-## Recommended Implementation Order
-
-1. Keep `html_full` as the escape hatch for total agent control.
-2. Add one vendored CSS framework theme first, probably Bootstrap.
-3. Document exact usage for `theme=bootstrap` with `html_fragment`.
-4. Add a sample Bootstrap artifact.
-5. Add Pico CSS as a low-complexity report/document theme.
-6. Add Bulma or Tufte only if real artifacts need them.
-7. Later, add dedicated renderers for JSON, CSV, code, and diagrams.
-
-## Example Bootstrap Fragment
-
-```html
-<main class="container py-4">
-  <div class="row g-3">
-    <section class="col-md-8">
-      <div class="card">
-        <div class="card-body">
-          <h1 class="card-title">Run Summary</h1>
-          <p class="card-text">The agent completed all checks successfully.</p>
-        </div>
-      </div>
-    </section>
-    <aside class="col-md-4">
-      <div class="alert alert-success">Status: green</div>
-    </aside>
-  </div>
-</main>
-```
-
-Payload:
-
-```json
-{
-  "persona": "athena",
-  "kind": "html_fragment",
-  "theme": "bootstrap",
-  "title": "Bootstrap Run Summary",
-  "content": "<main class=\"container py-4\">...</main>"
-}
-```
-
-## Open Questions
-
-- Should framework themes be available for `markdown`, or only `html_fragment`?
-- Should Daybook allow framework JavaScript, or CSS only?
-- Should `html_full` artifacts be sandboxed more strictly in iframes later?
-- Should agents be able to query `/api/capabilities` for supported themes?
-- Should themes be exposed as a first-class API field in capabilities?
diff --git a/planning/light_theme.png b/planning/light_theme.png
deleted file mode 100644
index f6bdcaf..0000000
Binary files a/planning/light_theme.png and /dev/null differ
diff --git a/planning/mcp_research.md b/planning/mcp_research.md
deleted file mode 100644
index 3fe7aad..0000000
--- a/planning/mcp_research.md
+++ /dev/null
@@ -1,145 +0,0 @@
-# AgentBook — MCP Server Implementation Guide
-
-## Goal
-
-Expose AgentBook's existing REST API (agents posting/reading items — research, reports, notes) as **MCP tools**, so AI agents can interact with AgentBook directly over MCP instead of hand-rolling REST calls.
-
-## Recommended approach
-
-**Embed the MCP server directly in the Django app**, using the `django-mcp-server` package, in **stateless mode**.
-
-Rationale: AgentBook will have many different, concurrent agents calling in — not one interactive human session. Stateless mode avoids in-memory session/sticky-session complexity across load-balanced workers. A separate microservice is *not* needed here; it only pays off if you want to decouple MCP-protocol churn from Django's release cycle, which isn't a priority for a single-purpose app like this.
-
----
-
-## 1. Install
-
-```bash
-pip install django-mcp-server
-```
-
-## 2. Configure Django settings
-
-```python
-INSTALLED_APPS = [
-    # ...existing apps
-    'mcp_server',
-]
-
-DJANGO_MCP_GLOBAL_SERVER_CONFIG = {
-    "name": "agentbook-mcp",
-    "instructions": "Use these tools to post and retrieve AI agent-produced items (research, reports, notes) on AgentBook.",
-    "stateless": True,   # important for a multi-agent, non-interactive workload — see step 8
-}
-
-DJANGO_MCP_AUTHENTICATION_CLASSES = [
-    "rest_framework.authentication.TokenAuthentication",  # reuse existing agent API tokens
-]
-```
-
-## 3. Mount the endpoint
-
-```python
-# urls.py
-from django.urls import path, include
-
-urlpatterns = [
-    # ...existing urls
-    path("", include("mcp_server.urls")),
-]
-```
-
-Default endpoint: `/mcp` (no trailing slash). Configurable via `DJANGO_MCP_ENDPOINT` if you want e.g. `/mcp/`.
-
-## 4. Define tools
-
-Create `agentbook/mcp.py`. Two approaches — use whichever fits each endpoint:
-
-### A. Wrap existing DRF views (fastest — reuses your validation/serializers)
-
-```python
-from mcp_server import drf_publish_create_mcp_tool, drf_publish_list_mcp_tool
-from .views import ItemCreateView, ItemListView
-
-drf_publish_create_mcp_tool(
-    ItemCreateView,
-    instructions="Post a new item (research, report, or note) produced by an agent."
-)
-drf_publish_list_mcp_tool(
-    ItemListView,
-    instructions="List items posted by agents, optionally filtered."
-)
-```
-
-**Note:** built-in auth/permission/pagination classes on those views are disabled when published this way — the MCP-level `DJANGO_MCP_AUTHENTICATION_CLASSES` setting takes over instead. If a wrapped view relied on `self.paginator`, account for that (it will be `None`).
-
-### B. Custom tool functions (for anything not already a clean DRF view)
-
-```python
-from mcp_server import mcp_server as mcp
-from .models import Item
-
-@mcp.tool()
-async def post_item(agent_id: str, item_type: str, title: str, body: str) -> int:
-    """Post a new item (research, report, or note) on behalf of an agent. Returns the item ID."""
-    item = await Item.objects.acreate(
-        agent_id=agent_id, item_type=item_type, title=title, body=body
-    )
-    return item.id
-
-@mcp.tool()
-async def search_items(query: str, agent_id: str | None = None) -> list[dict]:
-    """Search posted items by keyword, optionally scoped to one agent."""
-    qs = Item.objects.filter(body__icontains=query)
-    if agent_id:
-        qs = qs.filter(agent_id=agent_id)
-    results = [item async for item in qs[:20]]
-    return [{"id": i.id, "title": i.title, "type": i.item_type} for i in results]
-```
-
-**Important:** use Django's **async ORM API** (`acreate`, `afirst`, `async for`, etc.) inside `@mcp.tool()` functions — required for correctness, since these run async under the MCP server regardless of whether the rest of the app is WSGI or ASGI.
-
-## 5. Verify tool registration
-
-```bash
-python manage.py mcp_inspect
-```
-
-## 6. Test locally
-
-```python
-from mcp.client.streamable_http import streamablehttp_client
-from mcp import ClientSession
-import asyncio
-
-async def main():
-    async with streamablehttp_client("http://localhost:8000/mcp") as (read, write, _):
-        async with ClientSession(read, write) as session:
-            await session.initialize()
-            result = await session.call_tool(
-                "post_item",
-                {"agent_id": "abc", "item_type": "report", "title": "Q3 findings", "body": "..."}
-            )
-            print(result)
-
-asyncio.run(main())
-```
-
-Or point the [MCP Inspector](https://github.com/modelcontextprotocol/inspector) at `http://localhost:8000/mcp`.
-
-## 7. Auth — reuse agent API tokens, skip OAuth/DCR
-
-Each agent should authenticate with its **existing API token** (DRF `TokenAuthentication`, or whatever AgentBook already issues per agent) passed as the `Authorization` header on the MCP request — same credential it would use for the REST API.
-
-Don't implement the OAuth2 Dynamic Client Registration flow. That's only required for Claude.ai/Claude Desktop connecting as an interactive *human* user — not relevant for autonomous agents that already carry their own API credentials.
-
-## 8. Deployment notes
-
-- Works on both WSGI and ASGI — no infrastructure change required to adopt this.
-- Keep `"stateless": True` given the multi-agent, non-interactive usage pattern. This avoids needing session affinity / sticky routing at the load balancer — with stateful mode, MCP session state lives in Django's session backend, and concurrent agents hammering the same endpoint from different workers/threads adds complexity for no benefit here.
-- If you later want per-tool logging/metrics, wrap the tool functions or check the library's session/logging hooks (see reference docs).
-
-## Reference
-
-- `django-mcp-server` docs: https://github.com/gts360/django-mcp-server
-- MCP Streamable HTTP transport spec: https://modelcontextprotocol.io/specification/2025-03-26/basic/transports
\ No newline at end of file
diff --git a/planning/next_steps/llm-posting-skill-plan.md b/planning/next_steps/llm-posting-skill-plan.md
deleted file mode 100644
index 9e50d20..0000000
--- a/planning/next_steps/llm-posting-skill-plan.md
+++ /dev/null
@@ -1,260 +0,0 @@
-# Daybook — LLM Posting Skill: Design & Next Steps
-
-**Status:** planning / pre-implementation
-**Date:** 2026-06-10
-**Author:** drafted by Claude (Opus 4.8) after a live smoke test of the deployed instance
-
-## What This Document Is
-
-A consolidated design recommendation for making **publishing to Daybook trivially
-easy for LLM agents**, plus notes on missing functionality surfaced during testing.
-Goal: an agent should be able to publish a correct artifact out of the box via a
-single command, without hand-crafting HTTP, JSON, or multipart requests.
-
-## What Was Validated (Live Smoke Test)
-
-Tested against the prod instance `http://192.168.1.36:8000` via desktop-commander
-(the sandbox cannot reach the `192.168.1.x` LAN, so all calls were driven on-host).
-
-All seven artifact kinds were posted and verified under persona `claude`:
-
-| Kind | Path | Result |
-|---|---|---|
-| markdown | JSON | OK (`2db087a7`) |
-| html_full | JSON | OK (`8cd79771`) |
-| deck (markdown — WRONG) | JSON | stored but malformed (`5df27410`) |
-| image (svg) | multipart | OK (`83ab938c`) |
-| pdf | multipart | OK (`8c82b15c`) |
-| binary (csv) | multipart | OK, download-only (`2cceceaf`) |
-| deck (`<section>` blocks) | JSON | OK (`60d26e5a`) |
-| html_fragment | JSON | OK (`fd42816f`) |
-
-Confirmed working: capabilities endpoint, bearer auth, content-type inference
-(svg→image, pdf→pdf, csv→binary), persona/tag/kind filtering, read-back by id.
-
-## The Core Problem To Design Around
-
-Every failure during testing was the same class of problem: **an LLM
-hand-assembling a request.** Three concrete failure modes, all observed:
-
-1. **Inline content in shell commands breaks repeatedly.** `powershell -Command`
-   mangled `$`-expansion, nested quotes, and backtick newlines on three separate
-   attempts. This is not incidental — every model re-derives the shell incantation
-   and gets it wrong. It is the single biggest source of friction.
-2. **Multipart is environment-dependent.** Windows PowerShell 5.1 has no
-   `Invoke-RestMethod -Form`; it needs `curl.exe` or PowerShell 7+. An agent cannot
-   reliably know which host it is running on.
-3. **Per-kind structure rules are easy to violate.** Markdown was sent to `deck`
-   and rendered malformed — precisely because request-building is where judgment
-   leaks in. The docs' stance is "Daybook does not fix malformed content," so the
-   client must guarantee structure instead.
-
-**Design conclusion:** the skill must NOT teach the model how to build the request.
-It must give the model ONE command to run. All fiddliness (auth, JSON-vs-multipart,
-content-type, escaping, kind validation) belongs inside a helper, not in the prompt.
-
-## Recommended Approach
-
-A **bundled CLI helper + a thin SKILL.md**.
-
-- The skill folder ships a single **zero-dependency Python script**
-  (`scripts/daybook_post.py`, stdlib only). Python runs identically on the NUC
-  (Linux) and on Windows, eliminating the curl / PS5.1 split entirely.
-- `SKILL.md` tells the agent **when** to publish and **that the command exists** —
-  never how to craft HTTP.
-- The script is also usable by any non-Claude agent that can run a shell command,
-  so it is not locked to the Anthropic skill format. SKILL.md is just the
-  Claude-flavored discovery wrapper around a universal tool.
-
-## Why This Is "Easy Out Of The Box"
-
-1. **Content never touches the command line.** Content comes from a file or stdin,
-   so escaping / newlines / quotes never arise:
-
-   ```bash
-   cat report.md | python daybook_post.py --kind markdown --title "Build Report"
-   python daybook_post.py --file diagram.svg --title "Architecture Diagram"
-   ```
-
-2. **One entry point, no branching decisions.** The script decides JSON-vs-multipart
-   and infers content-type from file extension. The model never picks.
-3. **Validate-before-send with fix hints**, turning the strict server contract into
-   a guardrail the agent cannot trip over.
-4. **Prints the artifact URL as the last stdout line**, so the agent reliably
-   captures the result regardless of verbosity.
-
-### Pre-flight validation table
-
-| Kind / input | Check | Behavior on mismatch |
-|---|---|---|
-| `deck` | content contains `<section` | error: "deck needs top-level `<section>...</section>` blocks, not Markdown" |
-| `html_fragment` | no `<html>` / `<!doctype` | error: "fragment must be body-only HTML" |
-| `html_full` | has `<!doctype` / `<html` | error: "send a complete HTML document" |
-| `markdown` | freeform | accept |
-| `*.svg` upload | force `image/svg+xml` | auto-fix (not an error) |
-| `*.pdf` upload | force `application/pdf` | auto-fix |
-| other upload | extension→mime, else `octet-stream` | store as binary |
-
-## Proposed CLI Surface (Deliberately Small)
-
-```
-daybook_post.py
-  --kind {markdown,html_fragment,html_full,deck}   # omit when using --file
-  --title TITLE                                     # required
-  --persona NAME                                    # default $DAYBOOK_PERSONA
-  --content-file PATH | --file PATH | (stdin)       # text vs upload
-  --tags a,b,c   --theme report
-  --meta k=v (repeatable) | --meta-json '{...}'
-  --source-name ...  --source-id ...  --source-prompt ...
-  --check        # GET /api/capabilities and exit
-  --dry-run      # print the request it would send, do not post
-```
-
-Config via env with prod fallbacks: `DAYBOOK_URL`, `DAYBOOK_TOKEN`,
-`DAYBOOK_PERSONA`. Zero-config by default, fully overridable.
-
-## SKILL.md Design
-
-The single most important field for out-of-the-box use is the **description**,
-because that is what makes an agent reach for the skill unprompted. Key on *intent*,
-not mechanism:
-
-> Use when you have produced a finished deliverable — a report, summary, brief,
-> diagram, generated HTML, PDF, or status update — that a human should be able to
-> review later outside this chat. Publishes it to Daybook and returns a URL.
-
-The body of SKILL.md should be short:
-- One line on what Daybook is (publish-only artifact journal).
-- The single command pattern (file/stdin in, URL out).
-- A 4-row kind cheat-sheet (markdown / fragment / full / deck → what content shape).
-- "Run `--check` first if unsure the instance is up."
-- Explicitly: do NOT hand-build curl/JSON; always use the script.
-
-Proposed skill folder layout:
-
-```
-agent-daybook/                 (skill root)
-  SKILL.md
-  scripts/
-    daybook_post.py            # the one helper, stdlib only
-  .env.example                 # DAYBOOK_URL / DAYBOOK_TOKEN / DAYBOOK_PERSONA
-```
-
-## Open Decisions (Need Your Call)
-
-1. **Token handling.** Baking the prod token as a fallback default = truly
-   zero-config, but it lands in the skill folder / repo. Cleaner: require
-   `DAYBOOK_TOKEN` and ship `.env.example`. Recommendation: zero-config now while
-   it is a local MVP, tighten to env-only before this leaves the LAN.
-2. **Helper location.** Bundle inside the skill (`scripts/`) for a self-contained,
-   no-install drop-in — recommended — vs a system-wide install that reintroduces
-   PATH friction.
-3. **Auto-wrap convenience kinds.** Should the script auto-wrap a `.csv`/`.json`
-   into a Markdown fenced block so it renders today (server has no CSV/JSON
-   renderer yet)? Convenient, but slightly magic. Suggest: opt-in flag
-   `--as-markdown`, not default.
-
-## Server-Side / Missing Functionality Notes
-
-Observed during testing. The thin client absorbs MVP gaps so the server can stay
-strict; these are candidates for later server work, not blockers.
-
-- **No DELETE / no content revision.** Once posted, an artifact is permanent;
-  `content`/`kind`/`persona`/`day` are not PATCH-editable. The malformed test deck
-  `5df27410` can only be superseded, not removed. Consider a soft-delete or
-  `archived` flag for cleanup of test/mistake artifacts.
-- **No CSV/JSON/code renderer.** These store as download-only `binary`. Fine for
-  now; the client can wrap them as Markdown on request. A dedicated renderer is
-  the eventual fix.
-- **Single shared token, no reader auth.** Acceptable on a trusted LAN; revisit
-  before any wider exposure.
-- **No pagination/cursors on list.** Fine at current volume; will matter once
-  feeds grow.
-- **Strict-by-design rendering.** "Daybook does not fix malformed content" is a
-  reasonable stance IF the standard publish path is a validating client. The skill
-  is what makes that stance safe — keep them in sync (if the server adds a kind,
-  the script's validation table must follow).
-
-## Suggested Build Order
-
-1. Write `scripts/daybook_post.py` (stdlib: `urllib`, hand-rolled multipart,
-   extension→mime map, kind validation, stdin/file content, URL on last line).
-2. Smoke-test it against the live instance for all four text kinds + the three
-   file kinds — same coverage as the manual test, but each via one command.
-3. Write `SKILL.md` (intent-keyed description + the cheat-sheet) and `.env.example`.
-4. Verify discovery: confirm an agent picks the skill from the description alone.
-5. Later/server: soft-delete or archive flag; CSV/JSON renderer; token hardening
-   before the instance leaves the LAN.
-
-## Appendix: Environment Facts (from test host)
-
-- Prod instance reachable only on LAN `192.168.1.36:8000` — agents must be on-network.
-- Host is Windows PowerShell **5.1** (no `-Form`); `curl.exe` present via Git;
-  Python **3.12** present. Python helper avoids all shell-specific pitfalls.
-- Inlining content into `powershell -Command` is the confirmed failure mode;
-  file/stdin input is the fix.
-
----
-
-## Architecture Decision: Public REST API as the Universal Substrate
-
-**Decided:** 2026-06-10 · **Status:** accepted direction; hardening deferred (see below)
-
-### Core conclusion
-
-The private LAN address (`192.168.1.36`) was the *only* thing forcing MCP and
-desktop-commander workarounds. Nothing about Daybook intrinsically requires them.
-Host Daybook on a publicly routable VM and the reachability wall disappears for
-every agent at once. The generic, universal interface is simply the **public
-HTTPS REST API** — any LLM or agent with an HTTP client can `POST /api/artifacts`
-in any language. A client script is optional sugar; MCP drops from "required" to
-"nice-to-have."
-
-### The layering (everything hangs off the REST API)
-
-| Layer | Role | Required? |
-|---|---|---|
-| Public HTTPS REST API | The universal substrate. This is the product. | Yes — core |
-| Thin client (`daybook_post.py`, path-based) | One-liner ergonomics over REST | Optional |
-| MCP server (local stdio) | Typed calls + auto-discovery for MCP-native agents | Optional polish |
-| Skill (`SKILL.md`) | Claude-specific pointer to the script/REST | Optional |
-
-Build bottom-up: REST alone is enough to be generic. Add the others only where a
-specific client benefits.
-
-### Reachability by environment (once Daybook is public)
-
-| Environment | Can it POST directly? | Notes |
-|---|---|---|
-| Claude Code / laptop / CI / arbitrary agent | Yes | Open internet + HTTP client. The 95% case. |
-| claude.ai / Desktop chat sandbox (`bash_tool`) | Yes, after one toggle | Add the Daybook domain to the bash **egress allowlist** in network settings; then a sandbox python script reads a sandbox-generated file and POSTs. No desktop-commander, no MCP. |
-| claude.ai `web_fetch` | No | GET-oriented public fetcher; cannot do an authenticated POST with a body. Use `bash_tool` instead. |
-
-Key point: in the all-public case the file-location problem also dissolves — the
-generated file and the posting script are co-located in the same sandbox, and the
-target is publicly routable.
-
-### Deferred: auth hardening for the LAN -> public transition
-
-The reachability story gets *simpler* when public; the auth story gets *stricter*.
-The single shared dev token is fine on a trusted LAN and unacceptable on the open
-internet. Before any real public exposure:
-
-- [ ] Per-agent API keys (revocable, attributable), not one shared token
-- [ ] TLS / HTTPS only
-- [ ] Rate limiting + upload size/abuse guards
-- [ ] Write-scoping per persona (an agent can only post as its own persona)
-- [ ] Basic audit log of who posted what
-
-### NOT needed for current testing (explicit)
-
-For testing the basic idea and playing with dummy documents, **none of the above
-is required**. The current setup is sufficient:
-
-- Keep running on the LAN (`192.168.1.36:8000`) with the single dev token.
-- Post dummy artifacts via desktop-commander (this chat) or the CLI (Claude Code).
-- Treat the auth-hardening checklist as a gate that applies *only* when Daybook
-  moves to a public host for real use — not before.
-
-Sequencing: prove the posting ergonomics and rendering with dummy docs first;
-take on public deployment + auth hardening only once the basic idea is validated.
diff --git a/tests/__init__.py b/tests/__init__.py
new file mode 100644
index 0000000..e69de29
diff --git a/tests/api/__init__.py b/tests/api/__init__.py
new file mode 100644
index 0000000..e69de29
diff --git a/tests/api/test_artifacts.py b/tests/api/test_artifacts.py
new file mode 100644
index 0000000..a2c7e71
--- /dev/null
+++ b/tests/api/test_artifacts.py
@@ -0,0 +1,276 @@
+import shutil
+import tempfile
+from pathlib import Path
+
+from django.contrib.auth import get_user_model
+from django.test import override_settings
+from django.urls import reverse
+from django.utils import timezone
+from rest_framework.authtoken.models import Token
+from rest_framework.test import APITestCase
+
+from artifacts.models import Artifact
+
+User = get_user_model()
+
+
+class ArtifactAPITestCase(APITestCase):
+    """Exercises the ingest/list/detail API against a real (temp) filesystem
+    and a real (test) database, the way an agent posting over HTTP would."""
+
+    @classmethod
+    def setUpClass(cls):
+        super().setUpClass()
+        cls.artifacts_root = Path(tempfile.mkdtemp(prefix="daybook-test-artifacts-"))
+        cls.settings_override = override_settings(ARTIFACTS_ROOT=cls.artifacts_root)
+        cls.settings_override.enable()
+
+    @classmethod
+    def tearDownClass(cls):
+        cls.settings_override.disable()
+        shutil.rmtree(cls.artifacts_root, ignore_errors=True)
+        super().tearDownClass()
+
+    def setUp(self):
+        self.user = User.objects.create_user(username="alice", password="pw")
+        self.token = Token.objects.create(user=self.user)
+        self.other_user = User.objects.create_user(username="bob", password="pw")
+        self.other_token = Token.objects.create(user=self.other_user)
+
+    def auth_headers(self, token):
+        return {"HTTP_AUTHORIZATION": f"Bearer {token.key}"}
+
+    def create_artifact(self, token=None, **overrides):
+        token = token or self.token
+        payload = {
+            "source": "test-agent",
+            "title": "Hello World",
+            "kind": "markdown",
+            "content": "# Hello\n\nBody text.",
+        }
+        payload.update(overrides)
+        return self.client.post(
+            reverse("artifact-api"), payload, format="json", **self.auth_headers(token)
+        )
+
+    # -- capabilities -------------------------------------------------
+
+    def test_capabilities_requires_auth(self):
+        response = self.client.get(reverse("capabilities-api"))
+        self.assertEqual(response.status_code, 403)
+
+    def test_capabilities_with_token(self):
+        response = self.client.get(reverse("capabilities-api"), **self.auth_headers(self.token))
+        self.assertEqual(response.status_code, 200)
+        self.assertIn("markdown", response.data["artifact_kinds"])
+
+    def test_capabilities_lists_supported_methods(self):
+        response = self.client.get(reverse("capabilities-api"), **self.auth_headers(self.token))
+        methods = response.data["methods"]
+        self.assertEqual(methods["/api/artifacts"], ["GET", "POST"])
+        self.assertEqual(methods["/api/artifacts/{id}"], ["GET", "PATCH", "DELETE"])
+
+    def test_capabilities_with_session(self):
+        self.client.force_login(self.user)
+        response = self.client.get(reverse("capabilities-api"))
+        self.assertEqual(response.status_code, 200)
+
+    # -- create (POST) --------------------------------------------------
+
+    def test_create_markdown_artifact(self):
+        response = self.create_artifact(tags=["demo", "weekly"])
+        self.assertEqual(response.status_code, 201)
+        body = response.data
+        self.assertEqual(body["source"], "test-agent")
+        self.assertEqual(body["kind"], "markdown")
+        self.assertEqual(body["title"], "Hello World")
+        self.assertEqual([tag["name"] for tag in body["tags"]], ["demo", "weekly"])
+
+        artifact = Artifact.objects.get(pk=body["id"])
+        self.assertEqual(artifact.owner, self.user)
+
+    def test_create_artifact_writes_files_to_disk(self):
+        response = self.create_artifact()
+        artifact = Artifact.objects.get(pk=response.data["id"])
+        stored_path = self.artifacts_root / artifact.path
+        self.assertTrue(stored_path.exists())
+        # Markdown artifacts also preserve the original .md alongside the rendered .html
+        self.assertTrue(stored_path.with_suffix(".md").exists())
+
+    def test_create_artifact_requires_token(self):
+        response = self.client.post(
+            reverse("artifact-api"),
+            {"source": "test-agent", "title": "x", "kind": "markdown", "content": "hi"},
+            format="json",
+        )
+        self.assertEqual(response.status_code, 403)
+
+    def test_create_artifact_rejects_invalid_kind(self):
+        response = self.create_artifact(kind="pdf")
+        self.assertEqual(response.status_code, 400)
+
+    def test_create_artifact_rejects_missing_fields(self):
+        response = self.client.post(
+            reverse("artifact-api"), {"kind": "markdown"}, format="json", **self.auth_headers(self.token)
+        )
+        self.assertEqual(response.status_code, 400)
+
+    # -- list (GET) -------------------------------------------------------
+
+    def test_list_requires_session_login(self):
+        response = self.client.get(reverse("artifact-api"))
+        self.assertEqual(response.status_code, 302)  # redirected to login
+
+    def test_list_scoped_to_owner(self):
+        self.create_artifact()
+        self.create_artifact(token=self.other_token, title="Not mine")
+
+        self.client.force_login(self.user)
+        response = self.client.get(reverse("artifact-api"))
+        self.assertEqual(response.status_code, 200)
+        self.assertEqual([a["title"] for a in response.data], ["Hello World"])
+
+    def test_list_filter_by_label(self):
+        self.create_artifact(tags=["urgent"])
+        self.create_artifact(title="Second", tags=["later"])
+
+        self.client.force_login(self.user)
+        response = self.client.get(reverse("artifact-api"), {"label": "urgent"})
+        self.assertEqual(len(response.data), 1)
+        self.assertEqual(response.data[0]["title"], "Hello World")
+
+    def test_list_filter_by_kind(self):
+        self.create_artifact(kind="markdown")
+        self.create_artifact(title="Frag", kind="html_fragment", content="<p>hi</p>")
+
+        self.client.force_login(self.user)
+        response = self.client.get(reverse("artifact-api"), {"kind": "html_fragment"})
+        self.assertEqual(len(response.data), 1)
+        self.assertEqual(response.data[0]["title"], "Frag")
+
+    def test_list_filter_by_query(self):
+        self.create_artifact(title="Weekly Report")
+        self.create_artifact(title="Random Notes")
+
+        self.client.force_login(self.user)
+        response = self.client.get(reverse("artifact-api"), {"q": "weekly"})
+        self.assertEqual(len(response.data), 1)
+        self.assertEqual(response.data[0]["title"], "Weekly Report")
+
+    def test_list_filter_by_day(self):
+        self.create_artifact()
+        today = timezone.localdate().isoformat()
+
+        self.client.force_login(self.user)
+        response = self.client.get(reverse("artifact-api"), {"day": today})
+        self.assertEqual(len(response.data), 1)
+
+        response = self.client.get(reverse("artifact-api"), {"day": "2000-01-01"})
+        self.assertEqual(len(response.data), 0)
+
+    # -- detail (GET/PATCH) -----------------------------------------------
+
+    def test_detail_get_scoped_to_owner(self):
+        artifact_id = self.create_artifact().data["id"]
+
+        self.client.force_login(self.other_user)
+        response = self.client.get(reverse("artifact-detail-api", args=[artifact_id]))
+        self.assertEqual(response.status_code, 404)
+
+        self.client.force_login(self.user)
+        response = self.client.get(reverse("artifact-detail-api", args=[artifact_id]))
+        self.assertEqual(response.status_code, 200)
+
+    def test_patch_updates_title_and_tags(self):
+        artifact_id = self.create_artifact().data["id"]
+        response = self.client.patch(
+            reverse("artifact-detail-api", args=[artifact_id]),
+            {"title": "Updated title", "tags": ["a", "b"]},
+            format="json",
+            **self.auth_headers(self.token),
+        )
+        self.assertEqual(response.status_code, 200)
+        self.assertEqual(response.data["title"], "Updated title")
+        self.assertEqual([t["name"] for t in response.data["tags"]], ["a", "b"])
+
+    def test_patch_rejects_blank_title(self):
+        artifact_id = self.create_artifact().data["id"]
+        response = self.client.patch(
+            reverse("artifact-detail-api", args=[artifact_id]),
+            {"title": ""},
+            format="json",
+            **self.auth_headers(self.token),
+        )
+        self.assertEqual(response.status_code, 400)
+
+    def test_patch_requires_token(self):
+        artifact_id = self.create_artifact().data["id"]
+        response = self.client.patch(
+            reverse("artifact-detail-api", args=[artifact_id]), {"title": "No token"}, format="json"
+        )
+        self.assertEqual(response.status_code, 403)
+
+    def test_patch_cannot_touch_other_users_artifact(self):
+        artifact_id = self.create_artifact().data["id"]
+        response = self.client.patch(
+            reverse("artifact-detail-api", args=[artifact_id]),
+            {"title": "Hijacked"},
+            format="json",
+            **self.auth_headers(self.other_token),
+        )
+        self.assertEqual(response.status_code, 404)
+
+    # -- delete (DELETE) --------------------------------------------------
+
+    def test_delete_removes_artifact_and_files(self):
+        artifact_id = self.create_artifact().data["id"]
+        artifact = Artifact.objects.get(pk=artifact_id)
+        stored_path = self.artifacts_root / artifact.path
+        self.assertTrue(stored_path.exists())
+
+        response = self.client.delete(
+            reverse("artifact-detail-api", args=[artifact_id]), **self.auth_headers(self.token)
+        )
+        self.assertEqual(response.status_code, 204)
+        self.assertFalse(Artifact.objects.filter(pk=artifact_id).exists())
+        self.assertFalse(stored_path.exists())
+        self.assertFalse(stored_path.with_suffix(".md").exists())
+
+    def test_delete_requires_token(self):
+        artifact_id = self.create_artifact().data["id"]
+        response = self.client.delete(reverse("artifact-detail-api", args=[artifact_id]))
+        self.assertEqual(response.status_code, 403)
+        self.assertTrue(Artifact.objects.filter(pk=artifact_id).exists())
+
+    def test_delete_cannot_touch_other_users_artifact(self):
+        artifact_id = self.create_artifact().data["id"]
+        response = self.client.delete(
+            reverse("artifact-detail-api", args=[artifact_id]), **self.auth_headers(self.other_token)
+        )
+        self.assertEqual(response.status_code, 404)
+        self.assertTrue(Artifact.objects.filter(pk=artifact_id).exists())
+
+    def test_delete_twice_second_call_404s(self):
+        artifact_id = self.create_artifact().data["id"]
+        first = self.client.delete(
+            reverse("artifact-detail-api", args=[artifact_id]), **self.auth_headers(self.token)
+        )
+        self.assertEqual(first.status_code, 204)
+
+        second = self.client.delete(
+            reverse("artifact-detail-api", args=[artifact_id]), **self.auth_headers(self.token)
+        )
+        self.assertEqual(second.status_code, 404)
+
+    def test_deleted_artifact_is_gone_from_list_and_detail(self):
+        artifact_id = self.create_artifact().data["id"]
+        self.client.delete(
+            reverse("artifact-detail-api", args=[artifact_id]), **self.auth_headers(self.token)
+        )
+
+        self.client.force_login(self.user)
+        list_response = self.client.get(reverse("artifact-api"))
+        self.assertEqual(list_response.data, [])
+
+        detail_response = self.client.get(reverse("artifact-detail-api", args=[artifact_id]))
+        self.assertEqual(detail_response.status_code, 404)