Signal Intake

---
name: signal-intake
description: '信号入账的落盘工序库：Issue 模板与编号规则、写入执行规范八条、记忆条目的写入格式与 supersede 工序、memory-index sidecar 的字段与 `entry_key` 归一规则、两个端到端示例。判据那一半（什么触发、算哪一档、落哪个点）不在这里——它在主会话的必载注入片里，本 skill 只回答「已经判定要写了，怎么写」。'
user-invocable: false
allowed-tools: [Read, Write, Edit, Glob, Grep, Bash]
---

# 信号入账工序

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

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

**A**ssert 存在 → **U**pdate 合并 → **N**ew 新增，三选一，顺序不可换。

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`。文件不存在先初始化：

```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 保持不变，不回改。**

> **20 字是硬截断，不是「大约」**。数的是**规范化后**的 Unicode 字符：先删空白，再数 20 个，**不管断在哪儿**——断在词中间是正常的，key 是标识符不是摘要。贪心到「语义完整」会让同一事实被两个 producer 算出两个 key、sidecar 出现重复项。

**条目字段**：

```json
{
  "scope": "pm",
  "created_at": "2026-04-19",
  "provenance": "user-decree",
  "protected": true,
  "source": "[纠正]"
}
```

**`scope` 必须填实际值**（角色名 / `shared` / 主会话层填 `main`）。把 `"role"`、`"<role>"` 这类占位符原样写进去的条目**谁都查不到、也不参与容量与保护判断，等于白写**——上面那个 `"pm"` 是**示例值**，照抄它同样是错的。

**两个跳过 sidecar 的分支**（跳过的是 sidecar，不是事件）：
- 落点是主会话侧官方记忆的——那边没有 sidecar，事件仍写，`scope` 填 `main`、省略 `entry_key`
- 落点是项目判据文件或 skill 的——sidecar 只索引 MEMORY 条目；事件仍写但省略 `entry_key`，落点文件路径写进 `summary`

## 6. 事件

写完记忆**当场**写一条 `user_correction`，机械写法用 `workframe-event`（`user-correction` 子命令）。**收尾时不要为同一条纠正再补一条**——那会让问题加权分双倍计入。

## 7. supersede 的落盘动作

同一主题被再次纠正时：

1. 新条目写入高置信区
2. **旧条目整段移入同角色 `notes.md`**，标注 `→ 已被 {日期} 纠正取代`
3. **同步删除旧条目的 memory-index entry**——留着它，一条 stale 的 `protected` 条目会继续参与容量与衰减判断

## 8. 两个端到端示例

**P0 需求变更** — 用户：「这个新功能要支持批量导出，优先级比之前讨论的高。」

1. 排除判据通过（陈述新事实 + 下达指令）→ 需求变更 → P0
2. **回显摘要 + 等待确认**（P0 必须先于写入）：告知将输出 PRD 草稿 + 看板 task 草稿，问是否继续
3. 确认后：响应中输出两份草稿；PRD 由 @pm 落盘、task 由主会话落盘——**本工序不直接写**（安全 / 线上故障类 P0 例外：确认后可直接 append issue + 单条 `tags: [auto-update]` 的看板 pending 任务）

**纠正** — 用户：「不对，提交必须用 `git commit --only`，这个仓禁 amend。」

1. 命中「否定 + 修正」→ 判持久层认知（下一个不相关任务里仍成立）→ 纠正
2. 回显「收到纠正：[原认知] → [正确信息]。已记录。」
3. 分流：工种知识、消费者是未来做该域活的人 → `dev/MEMORY.md` 高置信区
4. 按 §4 的形状写入；按 §5 建 sidecar（`scope: "dev"`，`entry_key` = `dev:2026-09-10:提交必须用gitcommit--only，该仓`——**数到第 20 个字符即停**）
5. 按 §6 当场写 `user_correction`