signal-intake

信号入账工序

必载片已经判完「触发没有、算哪一档、落哪个点」。本文只管落盘那一步的形状。

1. 写入前必做（A.U.N. 工序）

Assert 存在 → Update 合并 → New 新增，三选一，顺序不可换。

1. 落笔前先 Read 目标文件，确认它存在且结构匹配。不存在就参照同目录已有文件的格式创建；YAML 字段名与现有条目不一致时以现有条目为准。绝不猜测字段结构。
2. 检索同主题旧条目——同一事实 / 口径 / 对象，表述可能完全不同，按语义判，不是按字符串找。
3. 三选一：
   • 无同主题 → 新增
   • 有同主题 → 改写合并成一条：保留信息量更大的表述，条目内标注更新时间与来源；被取代的旧表述移对应 notes.md 留档，不并排堆同主题的多条版本
   • 已有等价记录 → 不写，在响应里说明「该口径已有记录」

同主题合并、异主题追加：不同主题才追加新条目。查重合并的判据与 librarian 的融合整理 SOP 同源，别另立一套。

2. 执行规范

1. P0 先确认再写入：任何 P0 变更一律「回显摘要 → 等用户确认 → 写入」。顺序不许颠倒，不允许先写后确认。
2. P1/P2 即时更新：通过排除判据后立即写，不等额外确认。但目标若在受保护资产清单内，或是需求文档 / 批量看板任务，仍走草稿与 owner 角色路径。
3. 冲突处理：新信息与现有数据冲突时先提示用户确认，不自动覆盖；确认后走 supersede——保留最新、旧的移 notes 或归档区留档，不直接删。
4. 位序自检：写记忆或事件之前先自检「这个事实是不是已经被更早的那一步消费过了」。已写入则跳过，只处理未消费的那部分。
5. 升级条件：P1/P2 满足升级条件时按升级后的档处理。
6. 关联任务：P0 类紧急变更在用户确认后，往看板 tasks: 末尾追加单条 status: pending（tags: [auto-update, <类别>]），仅作信号标记入队，不自动派发。

3. Issue 落盘

类别	文件	备注
安全 / 权限 / Prompt 泄露	projects/issues/SEC-{序号}.yaml	泄露类 title 前缀 [Prompt泄露]
故障	projects/issues/BUG-{序号}.yaml

模板随项目骨架初始化，见项目内 projects/issues/TEMPLATES.md——字段以那份为准，本文不复制字段表（复制一份就是第二个事实源）。序号取该前缀下当前最大值 +1，建之前先列目录，别按记忆猜。

4. 记忆条目的写入格式

纠正类条目的形状是硬要求——librarian 的同主题查重与 entry_key 归一都吃这个形状：

- [纠正] {日期}：{正确信息}（用户纠正，原错误认知：{错误认知}）

日期在标记之后、正确信息之前；括注在末尾。位置与措辞都不是自由发挥的：查重按语义找同主题，而归一按前缀截断，形状漂了两边都会 miss。

指针化的那一档（业务事实类，正文已移交权威文档）写成：

- [纠正] {日期}：{一行结论}（权威口径见 [[<文档路径>]]）

指针化不算清理：标记、日期与 sidecar 保护都还在。

5. sidecar 与 entry_key

写入 MEMORY.md 之后同步维护 <state>/memory-index.json。文件不存在先初始化：

{"__schema__":"workframe.memory-index.v2","entries":{}}

entry_key 三段式：

<scope>:<YYYY-MM-DD>:<正确信息前 20 字规范化>

规范化三条，缺一不可，顺序不可颠倒：

1. 先删除全部空白字符
2. 再取前 20 字（Unicode 字符数，不是字节）
3. 同日同前 20 字碰撞时追加 -2 / -3

顺序反了会算出另一个 key：先截断会让落在前 20 字内的空白占掉有效字符，两种顺序对同一条目得出不同 key，跨 producer 的 supersede 与去重随之 miss。改序之前生成的历史 key 保持不变，不回改。