事件与 Feed
核心定位
- Event（事件）：系统里可审计的工作事实——一条决策、里程碑、发布记录、审批请求等。
- Feed（动态）：人类阅读与操作这些事件的工作台，支持评论、审批、排期等（视事件类型与权限而定）。
Agent 通过 MCP 创建或查询事件；成员在 Feed 里浏览与协作。
写什么、何时写
适合写入时间线的内容：
- 架构或产品定稿结论
- 阶段性开发完成节点
- 需要团队对齐的接口/流程约定
- 跨周仍需追溯的决策背景
不必每条日常聊天都写事件；重点是可检索、可负责的结论。
项目归属（projectSlug）
讨论属于哪个业务线，就应挂到对应项目：
- 写本仓库 / 产品中台本身 → 常用
opc-feed（以你实例项目列表为准） - 其它业务 → 先
projects_list或projects_search确认 slug - 不确定时不要随便默认项目；可请 Agent 列出候选
全局动态（不挂项目）仅在明确需要时使用。
在 Feed 里做什么
- 阅读：按时间或筛选查看应关注的事件。
- 未读：新事件会出现在未读计数（主导航「动态」旁）。
- 评论：对真实事件补充观点（需事件开启评论且你有可见权限）。
- 审批 / 事项：部分事件类型支持同意、拒绝、标记进度等（视类型配置）。
- 详情：点进事件可看完整正文、关系与修订历史。
文档、资源、成员变动等也可能出现在 Feed，但多为导航型条目，与完整事件能力不同。
Agent 写事件的习惯
在 Cursor 等环境中，可约定 Agent：
- 先
projects_search确认项目。 - 用
events_create写入，正文 Markdown 包含：背景、结论、后续。 - 重要配置变更、里程碑完成后主动提议同步。
团队可在项目规则（如 .cursor/rules）里固化这些习惯。
刷一刷（Swipe）
/swipe 提供「批处理」式界面，优先露出当前最需要你判断的动作（审批、事项状态等）。适合集中清空待办队列。
与团队文档的区别
| 事件 / Feed | 团队文档 /docs | |
|---|---|---|
| 形态 | 时间线上的动态条目 | 项目下的长文文档 |
| 典型用途 | 决策、节点、可追溯结论 | 规范、手册、设计说明 |
| Agent 写正文 | 通常不直接写 Event 正文 | documents_create / documents_update |
| Agent 写时间线 | events_create（如 record-entry、knowledge-outcome） | 勿用 document-* 类型（系统自动） |
知识沉淀工作语言包（业务向）：
| 场景 | 工具 / 类型 |
|---|---|
| 写入/修改组织文档 Markdown | documents_create / documents_update |
| 宣布规范/Playbook 已定稿 | events_create + typeSlug=knowledge-outcome |
| 日常决策、阶段小结 | events_create + typeSlug=record-entry |
| 新文档发布出现在动态 | 系统自动 document-created（列表可见，角标不计；勿手动 events_create） |
| 文档删除/归档 | 不在动态展示；审计在 Event 表与文档上下文 |
| 主动宣布知识定稿 | events_create + typeSlug=knowledge-outcome |
讨论产生稳定结论后，可沉淀为文档（管理后台或文档模块）。