项目定位

AtomTopicClaw 当前不是一个泛聊天 bot，也不是只会做摘要的单次脚本，而是围绕固定 topic 持续运转的 personal topic intelligence pipeline。它的目标是把“零散搜索 + 手动收藏”升级成一条可重复执行的本地生产链路：从候选信息进入，到 signal card、brief、review package，再到人工审批后的正式写入，都有明确边界。

当前版本已经落地的内容

在 codex/demo_v0.1 这条分支上，它已经不只是 PRD 或契约草稿，而是一个可在本地跑通的 demo。当前阶段已经完成了：

• P0 契约层与 schema 约束
• mock-driven local pipeline
• review / review-note 命令链路
• package-scoped immutable draft artifacts
• Feishu chat-only HITL 的本地模拟闭环
• review session、MCP-style review tools 与 nanobot review agent 的串联

我最关心的设计边界

这个项目最核心的规则不是“agent 能写多少内容”，而是 review package 是唯一人工审查单元。这意味着：

• agent 可以先自动生成 triage、signal card、draft report 与 topic artifacts
• 这些内容只能先写进 proposal / pending 草稿区
• 真正写入长期知识区或正式报告区，必须先经过一次完整的 HITL 审查
• approve 与 apply 被刻意拆开，保证人工确认与落盘写入不是一回事

当前阶段的价值

我把 AtomTopicClaw 当成一个 topic intelligence runtime 的验证场，而不是立刻做成“全能助手”。当前版本真正验证的是三件事：

1. topic intelligence 的工作单元应该如何定义。
2. agent 自动产物与 durable knowledge 之间应该如何隔离。
3. Feishu-style chat review、review agent 与本地工作区状态机能否拼成稳定闭环。

下一步方向

在现有 demo_v0.1 的基础上，接下来更值得继续推进的，不是再改一轮底层审批规则，而是把外层接口和真实环境接起来：

• 真实 Feishu event adapter
• 更完整的 nanobot tool registration / MCP server
• runtime LLM constrained parsing
• 更完整的多 topic 样例闭环与文档整理