docs(rag): rewrite the KB docs to the real gateway verb surface

The RAG knowledge base (indexed and queried by agents at runtime)
described entire fictional MCP tool surfaces — roboco_task_*,
roboco_journal_*, roboco_message_send, roboco_notify_send, roboco_agent_*,
roboco_session_*, roboco_workspace_*, roboco_project_* — that don't exist,
so agents searching the KB were handed invented tool names.

Rewrite every affected doc (tools, roles, workflows, troubleshooting, and
the stale architecture snippets) to the real surface: the gateway intent
verbs (give_me_work, i_will_work_on, open_pr, i_am_done, claim_review,
pass, fail, claim_doc_task, i_documented, triage, delegate, i_will_plan,
unblock, complete, escalate_up, escalate_to_ceo, ...) and content tools
(commit, note(scope=...), say, dm, evidence, notify*, open_session,
channels). Also reconcile the access-control docs to code: CEO can cancel
(Board/Auditor cannot); the management-channel membership and the
Auditor's silent-but-present status now match communications.py.

docs/rag/workflows/journaling.md

@@ -7,81 +7,91 @@
 3. Documents decisions and learnings
 4. Required before key transitions
 
-## Entry Types
+## The Tool
 
-| Type | Use For |
-|------|---------|
-| `task_reflection` | End of task summary |
-| `decision_log` | Architectural decisions |
+Journaling is a single content tool: `note(text, scope, ...)` on the
+`roboco-do` MCP server. There is **no** separate `roboco_journal_*` tool —
+the `scope` argument selects the kind of entry.
+
+| `scope` | Use For |
+|---------|---------|
+| `note` (default) | General observation |
+| `reflect` | End-of-task summary (what done / learned / struggled) |
+| `decision` | Architectural decision (context / options / chosen / rationale) |
 | `learning` | New knowledge gained |
 | `struggle` | Problems and solutions |
-| `general` | Other observations |
 
 ## Creating Entries
 
 ```python
 # General entry
-roboco_journal_entry({
-    type: "learning",
-    title: "Redis SCAN vs KEYS",
-    content: "SCAN is better for large datasets",
-    task_id: task_id,
-    tags: ["redis", "performance"]
-})
+note(
+    text="SCAN is better than KEYS for large Redis datasets",
+    scope="learning",
+    task_id=task_id,
+)
 
-# Decision log
-roboco_journal_decision({
-    title: "Session storage choice",
-    context: "Need fast session lookups",
-    options: ["PostgreSQL", "Redis", "In-memory"],
-    chosen: "Redis",
-    rationale: "Sub-millisecond reads, ephemeral data"
-})
+# Decision log — `decision` scope uses the structured fields
+note(
+    text="Chose Redis for session storage",
+    scope="decision",
+    task_id=task_id,
+    context="Need fast session lookups, ephemeral data",
+    options=[
+        {"name": "PostgreSQL", "pros": "durable", "cons": "slower"},
+        {"name": "Redis", "pros": "sub-ms reads", "cons": "ephemeral"},
+        {"name": "In-memory", "pros": "fastest", "cons": "lost on restart"},
+    ],
+    chosen="Redis",
+    rationale="Sub-millisecond reads; data is ephemeral by design",
+    consequences=["Adds Redis as a session dependency"],
+)
 
 # Struggle (problem and solution)
-roboco_journal_struggle({
-    task_id: task_id,
-    problem: "Tests failing intermittently",
-    attempts: ["Increased timeout", "Added retry"],
-    resolution: "Race condition in setup"
-})
-
-# Learning
-roboco_journal_learning({
-    content: "Use asyncio.gather for parallel calls",
-    how_applied: "Reduced endpoint latency 50%",
-    category: "performance",
-    tags: ["async", "performance"]
-})
+note(
+    text="Tests failing intermittently; root cause was a setup race condition",
+    scope="struggle",
+    task_id=task_id,
+)
 ```
 
+`options`, `consequences`, and `next_steps` accept either a list or a
+single value. For `decision` and `reflect` scopes the structured fields
+are recommended; the note is always recorded even if some are omitted.
+
 ## Required Reflections
 
-Before submitting for QA or completing:
+Before submitting for QA or completing, write a `reflect` entry:
 
 ```python
-roboco_journal_reflect({
-    task_id: task_id,
-    what_done: "Implemented rate limiting with Redis",
-    what_learned: "Lua scripts for atomic operations",
-    what_struggled: "Testing concurrent requests"
-})
+note(
+    text="Implemented rate limiting with Redis",
+    scope="reflect",
+    task_id=task_id,
+    what_done="Redis-backed token bucket on the API edge",
+    what_learned="Lua scripts give atomic check-and-decrement",
+    what_struggled="Testing concurrent requests deterministically",
+    next_steps=["Add a regression test for the boundary case"],
+)
 ```
 
 ## Searching Journals
 
-```python
-# Semantic search your journal
-roboco_journal_search("rate limiting patterns", top_k=5)
+Journal entries are indexed into the knowledge base. Search them through
+the `roboco-optimal` RAG tools (there is no dedicated journal-search verb):
 
-# Search team journals (if permitted)
-roboco_journal_read_team("be-dev-1", task_id=task_id)
+```python
+# Semantic search across the KB, filtered to journal entries
+roboco_kb_search(query="rate limiting patterns", index_types=["journals"])
+
+# Or ask the mentor, which searches all sources including journals
+roboco_ask_mentor(question="What did we decide about rate limiting?")
 ```
 
 ## Best Practices
 
 1. **Journal as you go** - Don't wait until end
 2. **Be specific** - Generic entries are less searchable
-3. **Use tags** - Helps categorization
-4. **Record failures** - They're valuable learning
+3. **Record failures** - They're valuable learning (`scope="struggle"`)
+4. **Use the right scope** - `decision` / `reflect` light up the panel views
 5. **Include context** - Future searchers need it