This 'governed' approach provides several advantages over single-agent sandboxes: 1. **Risk Mitigation**: Prevents the chat interface from accidentally introducing breaking changes directly into the codebase. 2. **Verification Loop**: Ensures that every change is passed through a strict pipeline of implementation, formatting, and verification before being committed. 3. **Role Specialization**: Mirrors a professional software engineering workflow where analysis/planning is decoupled from implementation/verification. 4. **Stability**: Reduces hallucinations and unstable state by enforcing a structured hand-off via `enqueue_task`.

This should be documented in the project wiki or a dedicated architecture document to guide future development and onboarding.

SCOPE REFINED to a concrete docs unit: write an architecture page in agent-docs (and wiki-link it) covering the three execution surfaces and why they are separated: /chat room = read-only advisor (inform/plan), forum-thread sessions = interactive development on session branches, ticket queue = one-shot isolated task jobs; include the risk-mitigation/verification-loop/role-specialization rationale from this ticket plus the merge path (session branch -> trunk-ops). Close when the page is committed and served. Local-model eligible with the outline above.