indifferentketchup
006226cce5
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>
33 lines
1.4 KiB
Markdown
33 lines
1.4 KiB
Markdown
# 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.
|