Feature Request: Expose tdai_memory_write tool for subagent sessions

[MOOSChen1989]

Problem

The memory-tencentdb plugin (v0.3.5) exposes two read/search tools but provides no write tool:

Tool	Available
tdai_memory_search	Yes
tdai_conversation_search	Yes
tdai_memory_write	Missing

This creates a one-way memory trap for subagent sessions: subagents can read via tdai_memory_search but have no tool to write memories back. Their write tool targets memory/*.md files which are never captured by L0 auto-capture.

Proposed Solution

Add a tdai_memory_write tool with signature:

{
  "name": "tdai_memory_write",
  "label": "Memory Write",
  "description": "Write a new entry into long-term memory",
  "parameters": {
    "type": "object",
    "properties": {
      "content": { "type": "string", "description": "The memory content to store" },
      "type": { "type": "string", "enum": ["persona", "episodic", "instruction"] },
      "scene_name": { "type": "string" }
    },
    "required": ["content"]
  }
}

Implementation Reference

• Tool registration pattern: dist/index.mjs line 17044 (api.registerTool for tdai_memory_search)
• Plugin source root: src/core/tools/
• write_memory_entries() already exists in plugin exports
• L1 JSONL schema: {id, content, type, priority, scene_name, source_message_ids, metadata, timestamps, createdAt, updatedAt, sessionKey, sessionId}

Why This Matters

Essential for multi-agent systems where subagents need bidirectional memory access. Currently subagents are second-class memory citizens — they can read but cannot contribute.

[Maxwell-Code07]

Thanks for your interest!
You're right, the current write path is implicit (L0 auto-captures conversations → L1 extracts structured memories). We're cautious about exposing direct writes because it would bypass the L1 dedup/conflict-detection pipeline, which could lead to duplicate or contradictory data. We'll evaluate this internally and get back to you.