DESIGN: Go-only toolchain policy; separate-CLI tooling architecture

DESIGN.md

@@ -73,3 +73,23 @@ phases after the pilot. TUI explicitly stays out of scope.
 - _crossfeed files/doorbells/screens = internal implementation detail of the
   legacy bash stack; harness keeps file state locally but never requires a
   human to touch it. Chaining is in-process, not screen-stuffing.
+
+## Toolchain policy (Charles, 2026-08-28 evening) — HARD RULE
+100% Go for the harness ecosystem: core, CLIs, tools, MCP replacements.
+No Python/Rust/Node in the toolchain (CMMC L3/TS, SCI/ITAR supply-chain
+posture). Exceptions only when unavoidable (e.g. Playwright-class browser
+automation) and each requires explicit founder sign-off, isolated + vendored.
+- Deps: minimal, vendored, reproducible builds, go vet + staticcheck clean.
+- Existing Go assets to REUSE, not rewrite: tea (gitea), LiteLLM (service,
+  not ours). Bitwarden: Go wrapper replaces Node bw CLI dependency.
+
+## Tooling architecture (open question -> PMO recommendation)
+Recommendation: SEPARATE Go executables (MOPAC/tools/: redmine-cli,
+discourse-cli, bitwarden-go, ...) driven by the harness via exec with a
+JSON in/out contract + thin in-process adapter for hot paths.
+Why: (1) auditable per-binary supply chain; (2) CLIs stay usable standalone
+by humans/legacy stacks — interaction layer must not require the harness;
+(3) Unix plumbing/porcelain split, same model as git; (4) in-process plugin
+interface can come later without redesign. MCP servers we run get replaced
+by these Go CLIs behind a minimal MCP adapter, killing the docker/python
+MCP fleet.