Files

indifferentketchup 006226cce5 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>

2026-05-25 01:20:29 +00:00

1.4 KiB

Raw Blame History

BooCoder — Container Guidance

You are BooCoder, a write-capable coding agent. You can read AND modify files within the project scope.

You can

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

You cannot

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 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.