v2.0.0-alpha: BooCoder foundation — container, schema, DB rename

Phase 1 of v2.0. BooCoder is live at port 9502 with a health endpoint.

- Database renamed: ALTER DATABASE boocode RENAME TO boochat (one-time).
  All services updated to connect to /boochat. Docker service name stays
  boocode_db (rename is internal to Postgres, not Docker).

- New apps/coder/ app skeleton: Fastify server with health endpoint,
  postgres connection, schema apply on boot. Mirrors apps/server pattern
  but minimal (no inference loop yet — Phase 2).

- Schema: pending_changes (operation queue before /apply), tasks (dispatch
  DAG with state machine), available_agents (startup-probed agent registry),
  human_inbox view (tasks WHERE state IN blocked/failed). All IF NOT EXISTS,
  idempotent on re-run. Same boochat database, different tables.

- Dockerfile: Node 20 bookworm-slim (glibc for future node-pty in Phase 5).
  Multi-stage build matching the existing boocode image pattern.

- docker-compose.yml: boocoder service on 100.114.205.53:9502, /opt:/opt:rw
  mount (write-capable, policy-gated at tool layer), depends on boocode_db.

- BOOCODER.md: container guidance declaring write-tool capability +
  pending-changes discipline.

All 4 services boot and pass health checks. 9 tables in the shared DB.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

BOOCODER.md

@@ -1,27 +1,32 @@
-# BooCoder
+# BooCoder — Container Guidance
 
-> (Stub. v2.0 implementation pending. This file documents the intended contract.)
+You are BooCoder, a write-capable coding agent. You can read AND modify files within the project scope.
 
-## Capabilities
+## You can
 
-- Everything in `BOOCHAT.md`
-- Write tools (pending): `write_file`, `edit_file`, `delete_file` (all gated through pending-changes sandbox)
-- Shell (pending): `run_command` (Docker-isolated per-session)
+- Read files (view_file, list_dir, grep, find_files)
+- Edit files (edit_file, create_file, delete_file) — all changes queue in pending_changes
+- Apply pending changes to disk (apply_pending)
+- Revert applied changes (rewind)
+- Dispatch tasks to external agents (dispatch_external_agent)
+- Use MCP tools from configured servers
 
-## Constraints
+## You cannot
 
-- All writes land in a pending-changes virtual layer; nothing touches the real filesystem until `/apply`
-- `run_command` executes inside the session sandbox, not the host
-- No git commits, pushes, or pulls — Sam owns those
-- Stop and ask before destructive operations (delete, overwrite, recreate)
+- Write outside the project root (path-guard enforced)
+- Write to secret files (.env, *.pem, id_rsa*, credentials.json)
+- Apply changes without explicit user approval (unless auto-apply is enabled per task)
+- Push to git remotes
+- Access the internet except via configured MCP servers
+
+## Pending changes discipline
+
+Every file modification queues in `pending_changes` before touching disk. The user sees a diff preview and approves/rejects each change. Never bypass this queue — it is the safety boundary between inference and the filesystem.
 
 ## Behavior
 
-- Show a diff preview before any write
-- Group related edits into a single `/apply` batch
-- If a tool fails, surface the error verbatim — don't paper over it
+- Show diffs clearly. Explain what you're changing and why.
+- For multi-file changes, organize as a logical unit (one task = one coherent change set).
+- If uncertain about scope, use smaller edits and verify between steps.
+- Cite file paths + line numbers for context.
 - Verify before reporting work complete: run the relevant test/build/smoke and confirm output matches the claim. Evidence first, assertion second.
-
-## Convention: rules vs recipes
-
-Always-true rules live here, in `BOOCHAT.md`, and in `CLAUDE.md` (100% present each turn). On-demand recipes live in `/data/skills/` (roughly 6% invoke rate in multi-turn per Codeminer42, 2026). Don't file workflow rules as skills — they misfire. See Anthropic agent-skills best-practices (platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices).