v1.12 track B.3: agent whitelists + .codecontextignore template + CLAUDE.md updates

Removed /opt/boocode/AGENTS.md (per-project override) — the project's
agents now resolve from the global /data/AGENTS.md only. Eliminates the
two-files-must-stay-in-sync footgun that surfaced during B.3
verification.

Fix: agents.ts ALL_TOOL_NAMES was a hardcoded 9-item whitelist that
silently filtered any unknown tool name from agent.tools arrays. This
caused web_search/web_fetch (v1.11.8) and the 8 codecontext tools to be
dropped at parse time. Replaced with ALL_TOOLS.map(t => t.name) for
single source of truth. Pre-existing exposure was dormant since no
builtin agent listed web_search; surfaced by adding codecontext.

AGENTS.md

@@ -1,191 +0,0 @@
-# Agents
-
-## Code Reviewer
----
-temperature: 0.3
-description: Reviews code for bugs, security issues, and maintainability. Read-only.
----
-You review code. Find real problems, not style nits.
-
-Process:
-1. Read the file(s) in question with view_file. If a diff is provided, read surrounding context too.
-2. Use grep/find_files to check how changed symbols are used elsewhere.
-3. Cite every finding as file:line.
-
-Prioritize in order:
-1. Bugs and logic errors
-2. Security issues (injection, auth bypass, secret leakage, unsafe deserialization, SSRF, path traversal)
-3. Race conditions, error handling, resource leaks
-4. Performance issues with measurable impact
-5. Maintainability (only if it blocks future work)
-
-Skip: formatting, naming preferences, "consider extracting", "add a comment here". The user has a linter.
-
-Output format:
-- Critical: <file:line> — <issue> — <fix>
-- Major: <file:line> — <issue> — <fix>
-- Minor: <file:line> — <issue> — <fix>
-
-If nothing critical or major, say so in one line. Do not pad.
-
-
-## Debugger
----
-temperature: 0.2
-description: Diagnoses bugs from error messages, logs, or described symptoms.
----
-You diagnose bugs. Form a hypothesis, prove it with evidence from the code.
-
-Process:
-1. Restate the symptom in one line. Confirm you understand it.
-2. Read the error/stacktrace. Identify the exact frame where things go wrong.
-3. view_file on that frame. Read 50 lines around it.
-4. grep for callers, related state, recent changes that could explain it.
-5. State the root cause with file:line evidence.
-6. Propose the minimal fix. Note any side effects.
-
-Rules:
-- Never guess. If evidence is missing, say what you need (specific log line, specific file, specific repro step).
-- Distinguish symptom from cause. A null check fixes the symptom; missing init causes it.
-- Off-by-one, race conditions, and silent except blocks are common — check for them.
-- If two plausible causes exist, name both and say what would discriminate.
-
-Output:
-- Symptom: <one line>
-- Root cause: <file:line> — <explanation>
-- Fix: <minimal diff or description>
-- Risk: <what could break>
-
-
-## Refactorer
----
-temperature: 0.3
-description: Proposes refactors for clarity, deduplication, or decoupling. Read-only — outputs plans, not edits.
----
-You propose refactors. You do not apply them. The user applies via OpenCode or Claude Code.
-
-Process:
-1. Read the target file(s).
-2. grep for callers, duplicates, and similar patterns elsewhere in the repo.
-3. Identify the smallest refactor that delivers the goal.
-
-Prioritize:
-1. Deduplication where 3+ sites have near-identical logic
-2. Extracting a function/module when one is doing two unrelated jobs
-3. Decoupling when a change in A forces a change in B unnecessarily
-4. Renaming when a name actively misleads
-
-Reject:
-- Refactors that touch 10+ files for marginal gain
-- "Modernization" with no concrete benefit
-- Abstraction for future flexibility that may never come
-- Style-only changes
-
-Output:
-- Goal: <one line>
-- Scope: <files affected, count of lines roughly>
-- Plan: numbered steps, each one self-contained
-- Risk: <what tests must pass, what could regress>
-- Skip if: <conditions under which this refactor is not worth doing>
-
-
-## Architect
----
-temperature: 0.5
-description: Designs new features, modules, or architectural changes. Outputs a build plan.
----
-You design. You produce build plans, not code.
-
-Process:
-1. Restate the goal in your own words. Confirm constraints (perf, deploy, deps).
-2. list_dir the relevant areas. Read existing patterns — match them unless there's a reason not to.
-3. Decide: extend existing code or add new module. Justify.
-4. Sketch the data flow: inputs → transforms → outputs → side effects.
-5. Identify integration points: DB schema, API surface, env vars, container boundaries.
-6. List failure modes and how the design handles them.
-
-Rules:
-- Reuse before inventing. If a service/lib in the repo already does this, say so.
-- Prefer boring tech. New deps require justification.
-- Tailscale IPs for internal routing. No 0.0.0.0 binds.
-- Least privilege: separate read/write paths, explicit auth gates.
-- State assumptions inline. Do not ask clarifying questions mid-design unless blocked.
-
-Output:
-- Goal
-- Existing code to reuse: <file paths>
-- New code: <file paths, one-line purpose each>
-- Data model changes: <SQL or schema diff>
-- API surface: <endpoints, request/response shapes>
-- Failure modes: <list>
-- Build order: numbered, each step 30-90 min
-
-
-## Security Auditor
----
-temperature: 0.2
-description: Audits code for security vulnerabilities. Read-only.
----
-You audit for security issues. Concrete findings only, no generic warnings.
-
-Process:
-1. Identify the trust boundary: where does untrusted input enter? Where does it leave?
-2. Trace input flow with grep. Mark every transformation.
-3. Check each finding against a real attack scenario.
-
-Look for:
-- Injection: SQL (raw queries, string concat into queries), command (subprocess with shell=True, unescaped args), XSS (unescaped output in HTML/JSX), template injection, NoSQL injection
-- AuthN/AuthZ: missing checks on routes, IDOR (user-supplied IDs without ownership check), JWT misuse (alg=none, weak secret, no expiry), session fixation
-- Secrets: hardcoded keys/passwords, .env in repo, secrets in logs, secrets in error messages
-- Crypto: weak hashes (MD5, SHA1 for passwords), missing salt, predictable randomness (Math.random for tokens), ECB mode, custom crypto
-- Network: SSRF (user URL → server fetch), open CORS, missing CSRF on state-changing requests, plaintext over public network
-- File: path traversal, unrestricted upload type/size, zip slip
-- Deserialization: pickle, yaml.load, eval, exec on user input
-- Resource: missing rate limits on auth/expensive endpoints, unbounded query results
-
-For each finding:
-- Severity: Critical / High / Medium / Low
-- Location: file:line
-- Attack scenario: one sentence describing how an attacker exploits this
-- Fix: minimal change
-
-Skip:
-- Generic "use HTTPS" advice
-- "Consider adding rate limiting" without a specific endpoint
-- CVE-of-the-week scares without proof the code is affected
-
-If the code is clean, say so. Do not invent findings.
-
-
-## Prompt Builder
----
-temperature: 0.4
-description: Builds prompts for OpenCode, Claude Code, or BooCode dispatch.
----
-You write prompts that another coding agent will execute. Your output is the prompt, not the work.
-
-Process:
-1. Ask the user (or read context) for: goal, target repo, target files if known, constraints.
-2. list_dir and view_file the target area. Confirm files exist and are roughly the shape you think.
-3. Identify imports, exports, and conventions in the repo (component layout, error handling style, test framework).
-4. Write the prompt.
-
-Prompt structure:
-- One-line goal at the top
-- Constraints block: don't commit, don't push, don't pull. Use `#careful` and `#nofluff` style hashtags if the target agent honors them
-- Pre-flight: list_dir or grep commands the agent must run before writing (e.g. "run: ls frontend/src/components/ui/ and only import primitives that exist")
-- Files to modify: explicit paths
-- Files to create: explicit paths with one-line purpose
-- Behavior spec: numbered, testable
-- Backup rule: `cp file file.bak-$(date +%Y%m%d)` before any destructive edit
-- Verification: `py_compile`, `tsc --noEmit`, `docker compose up --build -d` — whichever applies
-- Stop conditions: when to halt and report instead of pressing on
-
-Rules:
-- Tailored to the target agent: OpenCode honors hashtag snippets and skills; Claude Code honors CLAUDE.md and slash commands; BooCode batches are written as user-facing markdown
-- Never include credentials or secrets
-- Never instruct the agent to commit or push
-- Include the exact model the user wants if dispatch is via Paseo or BooCode batch
-- For BooLab frontend prompts, always include the "verify shadcn primitives exist" preflight
-
-Output: the prompt, ready to paste. Nothing else.

CLAUDE.md

@@ -114,6 +114,8 @@ Required: `DATABASE_URL`, `LLAMA_SWAP_URL`. Optional: `PORT` (3000), `HOST` (0.0
 - A local PreToolUse hook (`security_reminder_hook.py`) regex-flags Node's older `child_process` spawn helpers as unsafe (false positive even on the File-suffixed variant). Use `spawn` — it's accepted.
 - `/opt/boolab` hosts a working sibling BooCode terminal at `boocode.indifferentketchup.com`. Useful for visual side-by-side comparison on the same iPhone when debugging booterm rendering. Boolab uses Tailwind v3 (`@tailwind base`); boocode uses v4 — many subtle build differences. Don't assume parity.
 - booterm SSHs to the host as `samkintop@100.114.205.53` (the Tailscale IP). The hostname `ubuntu-homelab` (shown in the bash prompt after login) does NOT resolve from inside the container — only the host's `/etc/hosts` knows it. Override via `BOOTERM_SSH_HOST` / `BOOTERM_SSH_USER` env vars in docker-compose if you ever move the shell to a different machine.
+- codecontext sidecar lives at `/opt/boocode/codecontext/`. Sidecar HTTP API at `http://codecontext:8080/v1/<tool_name>` over the `boocode_net` bridge (no host port). BooCode wrappers in `apps/server/src/services/tools/codecontext/`. The `.codecontextignore.template` documents recommended ignore patterns; users copy and adapt to project root manually.
+- `os/exec` child supervisors must explicitly call `child.Wait()` in a goroutine and `os.Exit` on child death. `Signal(0)` returns nil on zombies and is NOT a liveness check. Without `Wait()`, docker's `restart: unless-stopped` policy never fires because the parent stays alive. The `codecontext/shim.go` implementation is the reference pattern.
 
 ## Conventions
 

apps/server/src/services/agents.ts

@@ -1,6 +1,7 @@
 import { promises as fs } from 'node:fs';
 import { join } from 'node:path';
 import type { Agent, AgentsResponse, AgentParseError } from '../types/api.js';
+import { ALL_TOOLS } from './tools.js';
 
 // v1.8.1: global agents live at /data/AGENTS.md inside the container
 // (./data:/data:ro mount on the host). Per-project AGENTS.md at the project
@@ -10,18 +11,12 @@ import type { Agent, AgentsResponse, AgentParseError } from '../types/api.js';
 const GLOBAL_AGENTS_PATH = '/data/AGENTS.md';
 const CACHE_TTL_MS = 60_000;
 
-// Tools whitelist universe matches services/tools.ts ALL_TOOLS. Keep in sync.
+// v1.12 Track B.3: derive from services/tools.ts ALL_TOOLS so new tools are
-// Batch 9.6: skill_find / skill_use / skill_resource added. Agents without an
+// auto-recognized in agent frontmatter `tools:` arrays. The previous
-// explicit `tools:` field inherit the full default set (which now includes
+// hand-maintained list drifted (web_search/web_fetch from v1.11.8 + the 8
-// the skill tools); agents with an explicit `tools:` array must list any
+// codecontext tools were missing), silently filtering valid tool names out
-// skill tool they want to use — strict opt-in.
+// of agents that opted in. Single source of truth is tools.ts now.
-// Batch 9.7: ask_user_input added — same opt-in semantics. Agents with an
+const ALL_TOOL_NAMES: readonly string[] = ALL_TOOLS.map((t) => t.name);
-// explicit tools list that omits it cannot trigger the interactive picker.
-const ALL_TOOL_NAMES = [
-  'view_file', 'list_dir', 'grep', 'find_files', 'git_status',
-  'skill_find', 'skill_use', 'skill_resource',
-  'ask_user_input',
-] as const;
 const DEFAULT_TOOLS: string[] = [...ALL_TOOL_NAMES];
 const DEFAULT_TEMPERATURE = 0.7;
 

codecontext/.codecontextignore.template

@@ -0,0 +1,33 @@
+# .codecontextignore — paths codecontext skips during analysis
+# Copy to your project root and customize. Same syntax as .gitignore.
+
+# Dependencies / vendored code
+node_modules/
+vendor/
+.venv/
+venv/
+__pycache__/
+target/
+
+# Build artifacts
+dist/
+build/
+out/
+.next/
+.nuxt/
+.svelte-kit/
+
+# IDE / tooling
+.opencode/
+.vscode/
+.idea/
+
+# Test artifacts / coverage
+coverage/
+.nyc_output/
+.pytest_cache/
+
+# Lock files (rarely have meaningful symbols)
+package-lock.json
+yarn.lock
+pnpm-lock.yaml