jsyqrt · Oct 2, 2026 · Sep 26, 2026 · Sep 26, 2026 · Sep 26, 2026 · Sep 26, 2026
diff --git a/docs/AGENT-RUNTIME.md b/docs/AGENT-RUNTIME.md
@@ -80,7 +80,7 @@ MUST: `reflex` tool set MUST be a subset of:
 
 `task_list`, `task_get`, `memory_save`, `memory_search`, `notify_user`, `request_user_input`,
 `schedule_wakeup`, `cancel_wakeup`, `set_heartbeat_interval`, `discover_tools`,
-`check_mailbox`, `file_read`, `agent_send_message`, `update_notebook`,
+`check_mailbox`, `file_read`, `agent_send_message`, `notebook_upsert`,
 and for managers additionally `team_status`.
 
 MUST NOT: Include `package_install`, `package_list`, `goal_create`, `goal_update`, `goal_status`,

diff --git a/docs/ARCHITECTURE.md b/docs/ARCHITECTURE.md
diff --git a/docs/COGNITIVE-ARCHITECTURE.md b/docs/COGNITIVE-ARCHITECTURE.md
diff --git a/docs/CONCURRENT-PROCESSING.md b/docs/CONCURRENT-PROCESSING.md
@@ -317,7 +317,9 @@ argument so that *different* resources run in parallel:
 > ① `update_notebook` was registered under domain `notebook` while its alias
 > `update_working_memory` lived under `working-memory` — both write the **same** Map
 > (`Agent.writeNotebookEntry`), yet they were judged non-conflicting, so the lock did
-> nothing. ② `file_write knowledge.md` took `fs:<path>` while `memory_update` took
+> nothing. (The alias has since been **removed** and the tool renamed `notebook_upsert`;
+> the resource-key fix below is what makes any such duplication impossible.)
+> ② `file_write knowledge.md` took `fs:<path>` while `memory_update` took
 > `memory` — the same file, two mutually non-exclusive paths, so a hand edit could be
 > **silently overwritten** by the next in-memory whole-file rewrite.
 > Both are fixed by resolving tools to a **resource key** via
@@ -338,7 +340,7 @@ argument so that *different* resources run in parallel:
 | `task` / `requirement` / `workflow` / `project` / `deliverable` | entity id | `task_update`, `requirement_update_status`, `workflow_run`, `deliverable_update` |
 | `terminal` / `browser` | terminal id / page id | `exec_terminal`, `click`, `navigate_page` |
 | `a2a-out` | target agent / channel | `agent_send_message`, `feishu_send_message` |
-| `agent-memory` | **resource key** (`knowledge` / `notebook` / `identity` / `state`) | `memory_save`, `memory_update`, `memory_update_longterm`, `memory_delete`, `update_notebook`, **`update_working_memory` / `clear_working_memory`** (alias → same key), `file_write` / `file_edit` on an agent memory file |
+| `agent-memory` | **resource key** (`knowledge` / `notebook` / `identity` / `state`) | `memory_save`, `memory_update`, `memory_update_longterm`, `memory_delete`, `notebook_upsert` / `notebook_clear`, `file_write` / `file_edit` on an agent memory file |
 | `session`, `session-tools`, `schedule`, `llm-config`, `org`, `ui`, `deliberation`, `mailbox-admin`, `notify` | single resource or item id | `session`, `discover_tools`, `team_update` |
 
 **Classification is closed and test-enforced.** `Agent.isWriteTool` is *default-deny*:
@@ -377,10 +379,8 @@ read → transform → write, and synchronous code still yields between those st
 whenever the read-modify-write spans an `await` — which it does on the dream-cycle
 path. Concretely (see §4.9 defect registry):
 
-- Tool-path writes (`memory_save` / `memory_update` / `update_notebook`) take the
-  `agent-memory:<resource>` lock (`knowledge` / `notebook`), so they mutually exclude —
-  including the `update_working_memory` alias, which now resolves to the *same* key
-  instead of a separate `working-memory` domain.
+- Tool-path writes (`memory_save` / `memory_update` / `notebook_upsert`) take the
+  `agent-memory:<resource>` lock (`knowledge` / `notebook`), so they mutually exclude.
 - The dream cycle (`consolidateMemory` → `dreamConsolidateMemory(entries)` →
   `pruneMemoryMd()` → `compressLongTermMemory()`) runs from a timer, **outside any tool
   call**, and therefore **outside any lock**. A concurrent `memory_update` could land
@@ -424,7 +424,7 @@ Defect registry (found 2026-09-16; each row is a *fixed* bug kept as a regressio
 
 | ID | Defect | Root cause | Fix | Guard |
 |---|---|---|---|---|
-| **P0-1** | `update_notebook` and its alias `update_working_memory` write the same Map yet never exclude each other | lock granularity was the **tool name**, and the alias was registered under a different domain (`working-memory`) | both resolve to `agent-memory:notebook` via `WRITE_TOOL_DOMAINS.resource` | `lock-resource-keys.test.ts` — alias key equality + live serialisation |
+| **P0-1** | two paths to the same notebook Map (formal name + alias) never excluded each other | lock granularity was the **tool name**, and the alias was registered under a different domain (`working-memory`) | both resolve to `agent-memory:notebook` via `WRITE_TOOL_DOMAINS.resource` (the alias was later removed and the tool renamed `notebook_upsert`) | `lock-resource-keys.test.ts` — resource key equality + live serialisation |
 | **P0-2** | a hand edit to `knowledge.md` / `NOTEBOOK.md` could be **silently overwritten** by the next in-memory whole-file rewrite | `file_write` took `fs:<path>` while `memory_update` took `memory` — same file, two non-exclusive paths | `Agent.resourceLocksFor(tc, dataDir)` rewrites an fs lock into the memory resource lock when the path names an agent memory file | same file — `file_write`/`file_edit` key equality |
 | **P0-3** | two OS processes (desktop + CLI) on the same agent have **no** mutual exclusion | `ResourceLockRegistry` and entity locks are in-process maps | **not fixed** — needs a process-level arbiter (file lock / single-instance election) | listed in §7 |
 

diff --git a/docs/GUIDE.md b/docs/GUIDE.md
@@ -348,7 +348,7 @@ A: This depends on the governance policy. By default, standard tasks need Manage
 A: Human-created tasks start in `pending` status. You will not receive a self-notification or approval request. Click "Start Execution" in the task detail page to begin execution. This differs from agent-created tasks, which show an "Approve" button and go through the HITL approval flow.
 
 **Q: How do Agents share knowledge?**  
-A: Agents contribute via the `knowledge_contribute` tool to the project knowledge base; other Agents search with `knowledge_search`. Humans can view and manage entries on the Knowledge page.
+A: Agents contribute via the `knowledge_contribute` tool to the project knowledge base; other Agents search with `kb_search`. Humans can view and manage entries on the Knowledge page.
 
 **Q: How do I assign Agents to different projects?**  
 A: Create projects on the Projects page and link them to Teams. When Agents are assigned to tasks within a project, they automatically get project context and isolated workspaces.

diff --git a/docs/MAILBOX-SYSTEM.md b/docs/MAILBOX-SYSTEM.md
@@ -1336,7 +1336,7 @@ Defined by `DELIBERATION_ALLOWED_TOOLS` in `@markus/shared`:
 | Context gathering | `task_list`, `task_get`, `requirement_list`, `requirement_get`, `list_projects`, `team_list`, `team_status`, `recall_activity`, `memory_search`, `memory_search_longterm` |
 | Inline communication | `notify_user`, `task_comment`, `requirement_comment`, `agent_send_message`, `agent_send_group_message`, `agent_create_group_chat`, `agent_list_group_chats` |
 | Mailbox management | `check_mailbox`, `defer_mailbox_item`, `drop_mailbox_item`, `prioritize_mailbox_item` |
-| Working memory | `update_working_memory`, `clear_working_memory` |
+| Working memory | `notebook_upsert`, `notebook_clear`, `notebook_read` |
 | Decision output | `complete_deliberation` |
 
 **Excluded**: `task_create`, `task_update`, `requirement_propose`, code/shell tools, `spawn_subagent`. These are heavy side-effect tools that belong in the processing phase.
@@ -1352,8 +1352,8 @@ individual mailbox items using dedicated tools:
 | `defer_mailbox_item` | Deliberation + focused processing | Postpone an item |
 | `drop_mailbox_item` | Deliberation + focused processing | Discard stale item |
 | `prioritize_mailbox_item` | Deliberation only | Re-prioritize item |
-| `update_working_memory` | All scenarios | Update situational awareness |
-| `clear_working_memory` | All scenarios | Clear stale awareness |
+| `notebook_upsert` | All scenarios | Update situational awareness |
+| `notebook_clear` | All scenarios | Clear stale awareness |
 
 **Safety**: `human_chat` items are protected — they cannot be deferred, dropped,
 or reprioritized by tool calls. **Strict state items**（正式任务执行 / 评审 / 需求·工作流收尾动作，
@@ -1413,7 +1413,7 @@ replaces the former `currentCognition` string. Each entry has:
 Working memory is populated from three sources:
 1. **Deliberation**: `situationalAwareness` → key `"deliberation"`
 2. **Triage**: reasoning → key `"triage-decision"`
-3. **Agent tools**: `update_working_memory` / `clear_working_memory`
+3. **Agent tools**: `notebook_upsert` / `notebook_clear`
 
 All entries are injected into every system prompt as `## Working Memory` with
 age labels per entry. The agent decides what to keep, update, or expire.