EnterpriseArchitect/specs/SOP-017_知识缺口上报SOP_v1.4_草案.md

SOP-017：知识缺口上报 SOP（v1.4 草案）

版本：v1.4 草案
基线：SOP-017 v1.3 草案（sha256 e7deee2a33ef35ef136230fd31630966cac884f81918ebd2878fe201ccaee6ca，25,538 B；经 COO 复检后定点修订）
起草人：刘诗妮（secretary）
送审人：陆怀瑾（COO）
起草日期：2026-10-29
关联 Issue：BIZ-158
关联闭环卡：BIZ-162（检索层不可达）
状态：草案，待 COO 复检与刘炜承批准；批准且检索层准入验证通过前不替代 v1.0

---

0. 修订说明与系统定位

0.1 修订背景

v1.0 第 5 节 Step 3 仍指向旧工单通道。v1.1 完成主通道迁移，v1.2 闭合分母口径、流程时序与检索层准入问题；经 COO 二次独立复检，上一轮 6 条已全部闭环。本版进一步修复可复制建单命令的负责人参数、迁移落点与 Multica 完整优先级枚举，并按建议将新上报卡设为 todo 以进入看门狗巡检。

0.2 系统定位（新增）

系统	定位	用途	不承担的职责
Multica	唯一书面真相源与主工单通道	任务建单、缺口登记、补全任务、状态与评论回写、闭环追踪	无
Gitea	代码与文档版本控制系统	代码、配置、方案、报告、记忆的版本控制与审阅	不作为工单、知识缺口登记或任务状态跟踪通道
思源知识库	人类浏览与编辑层	最终版 SOP、指南、制度	不承担工单流转
memory / wiki	Agent 查询层	知识检索与读取	不承担工单流转
WorkBoard	内部执行看板（辅助）	需要时承载可执行补全卡片；不得取代 Multica issue 作为书面真相源	不取代 Multica 记录、状态与评论

原则：Multica 优先，Gitea 退位。任何知识缺口只有完成 Multica 建单并回写 issue id，才视为完成“登记”。Gitea commit、PR 或仓库文件均不能替代 issue id。

0.3 修订索引

评审编号	类别	落实位置	修订结果
阻断 1	G 口径可被刷	§7.2–§7.4	G 改为周期内发生的缺口事件数；判定源为上报记录与独立巡检的并集；拒绝仍计入 G；区分两类 G=0；新增反刷分条款
阻断 2	时序倒置	§5.1–§5.2 Step 2–Step 3	调整为记录 → Multica 建单并回写 → 通知 COO（正文含 issue id）→ 审核
阻断 3	批准后仍读不到正文	§11.1–§11.2	新增思源正文同步与双通道命中正文验收；与 BIZ-162 明确绑定
必改 4	priority 硬编码	§5.2 Step 2	改为 `<high
必改 5	占位符口径不统一	§10.3	明确中文占位词禁止项与尖括号合法范围
必改 6	COO sessionKey 未实测	§5.2 Step 3	主键改为 agent:coo:main，并要求附送达回执
v1.3 阻断 1	建单命令负责人参数不可解析	§5.2 Step 2	--assignee coo 改为已实测可用的 --assignee-id 1c38b437-b54d-4784-bda3-29ce4c8a6722，并给出姓名替代写法
v1.3 必改 1	迁移落点错误	§10、§11.1、§11.3	注入与迁移主落点改为各 Agent 的 AGENTS.md 知识库章节；TOOLS.md 仅作为实际存在时的兼容项
v1.3 必改 2	priority 枚举覆盖不足	§5.2 Step 2、§8	明确 urgent/high/medium/low/none 五个合法值及业务分级映射
v1.3 建议 1	backlog 不进入看门狗巡检	§5.2 Step 2	上报 issue 状态改为 todo，确保停滞卡可被巡检拾取

---

1. 目的

解决知识缺口“发现后无书面登记、无主通道、无法追踪闭环”的问题，使每个影响任务交付的知识缺口都可查询、可审核、可补全、可量化。

---

2. 适用范围

全部 Agent（产研线、运营线、职能线），以及负责知识补全的责任人。

---

3. 知识缺口定义与判据

3.1 定义

知识缺口 = 执行任务时发现知识库（memory / wiki / 思源）中找不到的、且影响任务交付或决策质量的必要知识。

3.2 属于知识缺口的情况

#	类型	示例
1	核心业务数据缺失	缺少业务线 KPI 历史、竞品基准或经营口径
2	核心 SOP / 流程文档缺失	没有对应流程标准，操作无法一致执行
3	决策依据缺失	选型或决策缺少可核验的数据与依据
4	模板 / 指南缺失	缺少 PRD、验收、交接等标准模板
5	外部信息缺失	需要外部文档、资质或条款且现有知识库无存档
6	技术 / API 文档缺失	缺少接口规范、配置说明或操作文档
7	Agent 配置 / 技能文档缺失	新 Agent 接入缺少必要说明或配置参考

3.3 什么不算知识缺口

直接沿用 SOP-017 v1.0 第 3 节“不属于知识缺口的情况”，不重复制定替代判据：

#	场景	应对方式
1	可通过 web_search / tavily_search 快速获取的公开信息	自行检索
2	可通过 memory_search / wiki_search 检索到的现有知识	自行读取
3	可通过联系对应 Agent 获得的信息	直接联系
4	Agent 自身职责范围内的常识	无需上报

补充说明：任务执行中的临时疑问若不影响交付质量或决策准确性，记录在任务评论即可，不构成知识缺口。

---

4. 触发条件

完成执行前检索（SOP-016）后，满足以下任一条件即触发上报：

1. memory_search(corpus=all, ...)、wiki_search 与思源全文搜索均无匹配；
2. 检索有结果，但缺少支撑当前任务或决策的关键环节；
3. 任务执行中发现缺少必要规范、模板、指南、数据或外部存档；
4. 现有口径互相冲突，无法判定应采用哪一项。

外部公开信息可快速获取时，按第 3.3 节自行检索，不进入本流程。

---

5. 上报流程（Multica 主通道）

5.1 流程总览

发现知识缺口
  → Step 1 记录：在当日 memory 日志及当前任务评论中记录
  → Step 2 建单：multica issue create，并在日志/评论回写 issue id
  → Step 3 通知：sessions_send 通知 COO，通知正文包含 issue id
  → Step 4 审核：COO 基于已存在的 issue 审核接受 / 拒绝 / 升级
  → Step 5 补全卡：COO 在 Multica 创建补全任务并关联原上报 issue
  → Step 6 补全：责任 Agent 完成知识补全并提交证据
  → Step 7 闭环：COO 验收、关闭补全任务与原上报 issue，回写结果

5.2 逐步动作与命令

Step 1：记录

动作：在 memory/YYYY-MM-DD.md 追加标准格式记录；若当前已有 Multica issue 或 WorkBoard 卡片，同时在该任务评论中粘贴同一份记录。

# 路径示例；按实际日期写入对应文件
memory/YYYY-MM-DD.md

记录必须包含第 6 节标准格式、已执行的检索方式与 query、当前任务 id / 标题。不得只写“知识缺失”而没有证据。

Step 2：在 Multica 建单并回写 issue id（核心步骤）

动作：使用 multica issue create 创建“知识缺口上报”书面项；从 stdout 取得 issue identifier（如 BIZ-123）后，立即回写当日日志和当前任务评论。建单成功是通知 COO 的前置条件，确保 COO 审核时可核到 issue id。

cat > gap_description.md <<'EOF'
## 📚 知识缺口上报

**缺口类型**：[核心业务数据 | SOP 缺失 | 决策依据 | 外部信息 | 技术文档 | 模板/指南缺失 | Agent 配置]
**缺口描述**：[具体缺什么，以及为什么影响当前任务或决策]
**影响范围**：[哪些任务、决策或 Agent 受影响]
**紧急程度**：[高/中/低]
**建议补全方式**：[需要谁提供、查什么、创建什么文档]

## 已执行的检索
- `memory_search(corpus=all, query="[实际 query]")`：无结果 / 结果不足
- `wiki_search(query="[实际 query]")`：无结果 / 结果不足
- 思源全文搜索 `[实际 query]`：无结果 / 结果不足

## 当前任务
- 任务：[任务标题或 id]

## 验收标准
- [ ] 缺口所需知识已补全并可检索
- [ ] 补全内容含来源、版本 / 生效日期与归档路径
- [ ] 原上报 Agent 已收到闭环通知
EOF

multica issue create \
  --title "知识缺口-<领域>-<关键词>" \
  --description-stdin \
  --assignee-id 1c38b437-b54d-4784-bda3-29ce4c8a6722 \
  --priority <urgent|high|medium|low|none> \
  --status todo \
  < gap_description.md

负责人参数（v1.3 阻断 1）：--assignee 模糊匹配只认 Agent 姓名，不认角色词 coo。本流程固定使用已实测可解析的 COO UUID：--assignee-id 1c38b437-b54d-4784-bda3-29ce4c8a6722；若工作区人员记录发生变化，可改用姓名 --assignee 陆怀瑾，执行前须确认姓名可解析。禁止使用 --assignee coo。

优先级选择（v1.3 必改 2）：按 §8 判据从 <urgent|high|medium|low|none> 选择。只有阻塞当前任务、无法继续执行时才使用 high；urgent 是公司级即时处置的保留值，不能替代普通高优。若工作区要求项目归属，应先执行 multica project list 确认有效 <pid> 后追加 --project <pid>，不得臆造 pid。

状态选择（v1.3 建议 1）：新上报 issue 使用 --status todo，使停滞卡能够进入看门狗巡检；不得以 backlog 作为默认状态。

回写动作：拿到 issue id 后，将下列内容追加到 memory/YYYY-MM-DD.md 和当前任务评论：

**Multica 上报 issue id**：[ISS-123]
**建单时间**：[YYYY-MM-DD HH:MM]

只有包含 issue id 回写的记录，才计入“知识缺口上报通道是否落地”的分子（见第 7 节）。若建单失败，不得进入 Step 3 正式审核；须在当前任务中记录失败原因，恢复后补建并以补建后的 issue 为唯一审核对象。

Step 3：通知 COO

动作：通过 sessions_send 通知 COO（陆怀瑾），请求审核。通知正文必须包含 Step 2 取得的 issue id，使通知、书面记录与审核对象三者一致。

sessionKey: agent:coo:main

已实测可达直投键为 agent:coo:main。历史飞书直连键 agent:coo:feishu:coo:direct:ou_9f73b4e54af59f038e2b754793ea0908 可作为跨通道备用，但以运行时实际可达者为准；每次上报须保留送达回执（发送时间、目标 sessionKey、runId 或可核验的回执标识）。

通知正文必须包含：缺口类型、一句话描述、影响、紧急程度、建议处理方式、已记录位置、已执行的检索证据，以及 Multica 上报 issue id。

通知不是登记的替代品，COO 审核时以 Step 2 已补建并回写 issue id 的 Multica issue 为准。

Step 4：COO 审核

动作：COO 核对检索证据、缺口定义、影响范围、紧急程度与建议补全方式，并给出以下结论之一：

• 接受：进入 Step 5；
• 拒绝：在原上报 issue 评论中说明理由并关闭；
• 升级：涉及预算、外部采购、跨部门资源或战略决策时，转刘炜承决策，并在 issue timeline 保留升级记录。

COO 不得仅在飞书消息中口头处置而不在 Multica 留下评论或状态记录。

Step 5：创建补全卡（Multica 补全任务）

动作：COO 在 Multica 创建补全任务，关联原上报 issue，并设置 stage / 依赖关系。

cat > gap_remediation.md <<'EOF'
## 补全目标

[说明需要补齐的知识及验收口径]

## 来源与证据

[原上报 issue id、检索证据、缺口影响]

## 验收标准
- [ ] 补全内容可被 memory_search / wiki_search 检索
- [ ] 文档包含版本 / 生效日期、维护者与归档路径
- [ ] 原上报 issue 中回写补全链接并通知原上报 Agent
EOF

multica issue create \
  --title "[知识补全] <缺口主题>" \
  --description-stdin \
  --parent <原上报-issue-id> \
  --stage 1 \
  --assignee <领域责任人> \
  --priority <urgent|high|medium|low|none> \
  < gap_remediation.md

说明：

• <原上报-issue-id> 与 <领域责任人> 必须使用实际值，不得保留尖括号占位符；
• 责任矩阵沿用现行《知识缺口上报 SOP v1.0》第三节；无法匹配时由 COO 明确指派；
• 若同时使用 WorkBoard 承载执行，仍须以该 Multica 补全任务记录状态与验收结果，不得只维护 WorkBoard。

Step 6：补全

动作：责任 Agent 在补全任务中完成知识产出，并提交可验证证据：

1. 补全文档 / 数据 / 决策记录及其归档路径；
2. 版本号、生效日期、维护者；
3. 检索验证结果（memory_search / wiki_search 能命中）；
4. 与原上报 issue 的关联说明。

补全任务的状态更新只能在实际完成后进行；不得以“已创建文档”替代“已完成补全”。

Step 7：闭环

动作：COO 验收补全内容，确认检索可命中、证据齐全后：

1. 在补全任务中回写验收结论、链接和验收人；
2. 在原上报 issue 中回写补全 issue id、验收结论与闭环时间；
3. 按 Multica 流程关闭补全任务及原上报 issue；
4. 通过 sessions_send 通知原上报 Agent：

【知识缺口已补全】
原上报 issue：[ISS-123]
补全 issue：[ISS-456]
补全内容：[文档链接或归档路径]
验收结论：[通过 / 需返工]
后续可直接检索使用。

闭环的完成标志是：原上报 issue 与补全 issue 均有验收和闭环记录，且原上报 Agent 已收到通知。

---

6. 标准上报格式

6.1 核心模板（与 BIZ-84、SOP_知识缺口上报_v1.0.md 口径一致）

以下五项为必填核心字段：

## 📚 知识缺口上报

**缺口类型**：[核心业务数据 | SOP 缺失 | 决策依据 | 外部信息 | 技术文档 | 模板/指南缺失 | Agent 配置]
**缺口描述**：[具体缺什么，为什么影响任务]
**影响范围**：[哪些任务/决策/Agent 受影响]
**紧急程度**：[高/中/低]
**建议补全方式**：[希望怎么处理；需要谁提供、查什么、创建什么文档]

6.2 登记证据与任务关联（随模板一并记录）

## 已执行的检索
- `memory_search(corpus=all, query="[实际 query]")`：[结果]
- `wiki_search(query="[实际 query]")`：[结果]
- 思源全文搜索 `[实际 query]`：[结果]

## 当前任务
- 任务：[任务标题或 id]

## Multica 登记
**Multica 上报 issue id**：[ISS-123]
**建单时间**：[YYYY-MM-DD HH:MM]

字段顺序可调整；五个核心字段不得删减。issue id 只有在 multica issue create 成功后才能填写。

---

7. 量化口径与运营指标（改进）

7.1 直接计数口径

将知识缺口运营指标从“抽样评论中是否含检索证据”的代理指标，改为直接统计：

知识缺口上报通道落地数 = 在日志或任务评论中回写了 Multica issue id 的知识缺口上报记录数。

7.2 分母 G：周期内发生的知识缺口事件数

设：

• G = 周期内发生的知识缺口事件数；
• I = 周期内含有效 Multica issue id 回写的知识缺口上报记录数。

G 的判定源是以下两类记录的并集：

1. 上游 Agent 提交的知识缺口上报记录，包括最终被 COO 合理拒绝的上报；
2. 巡检抽样或专项巡检独立发现的、确实影响交付或决策的缺口。

同一缺口在两类来源中出现时按同一事件去重。被 COO 拒绝的上报仍计入 G，拒绝只改变处理结论，不改变“缺口事件已经发生”的事实。

7.3 分子 I 与计算规则

通道落地率 = I / G × 100%

计数规则：

1. 一条缺口事件对应一个 Multica 上报 issue，按 issue id 去重；
2. 只有日志或任务评论中明确回写该 issue id，才计入 I；
3. 仅发消息通知、仅创建 WorkBoard 卡片、仅提交仓库 commit / PR、仅口头上报，均不计入 I；
4. 巡检独立发现但尚未建立 Multica issue 的缺口计入 G、不计入 I；
5. 合理拒绝率作为辅助指标单列：合理拒绝数 / G × 100%，不得从 G 中扣除；
6. 月度巡检报告须列出：本期 G、本期 I、合理拒绝数与合理拒绝率、通道落地率、去重后的 issue id 清单及未落地原因。

7.4 G=0 的两种情形与反刷分条款

G=0 时必须按以下两种情形分别留痕：

情形	判定条件	报告口径
经检索确认本期确无缺口	有独立巡检覆盖，并留存任务量、抽样范围、检索结果与“未发现缺口”结论	记为“不适用（经检索确认本期确无缺口）”
本期无上报且无独立巡检覆盖	没有上游上报，也没有独立巡检覆盖或可核验抽样	记为“无数据（上报通道疑似失效）”，不得记“不适用”

反刷分条款：任一周期若出现“上报数下降但任务数上升”，且月度报告未给出可核验的原因说明，该周期通道落地率标记为待审，不得直接计入达标；待审原因补齐并经 COO 核验后方可重新判定。

7.5 建议目标

• 通道落地率目标：≥ 80%；
• P0 缺口落地率目标：100%；
• 未落地项须在下一次巡检前完成补建或记录明确豁免原因；
• G=0 的“无数据（上报通道疑似失效）”不得视为达标。

---

8. 优先级与响应时限

业务分级	Multica priority	定义	建议响应时限	建议补全时限
P0	high	阻塞当前任务，无法继续执行	COO 4 小时内响应	24 小时内补全
P0-升级	urgent	公司级重大风险、合规事件或生产故障等需即时处置；由 COO 明确保留使用	COO 即时响应	按专项处置方案执行
P1	medium	有 workaround，但影响效率或质量	COO 1 个工作日内响应	3 个工作日内补全
P2	low	当前可正常运行，属于应排期改进的知识缺口	COO 1 周内响应	按排期补全
记录项	none	不要求立即响应或排期，仅保留为知识治理记录	按月度复查看板处理	按 COO 决定

标准模板中的“紧急程度”仍使用高 / 中 / 低；建单时按上表映射为 Multica 合法枚举。urgent 是 P0 的升级通道，不是普通高优的默认替代；none 仅用于不要求行动的知识治理记录。

---

9. COO 审核标准

审核项	标准
是否真正检索过	上报记录包含实际 query 与结果，而非只写“已检索”
是否属于知识缺口	对照第 3 节；第 3.3 节四类场景应驳回并引导自行处理
是否完成 Multica 登记	原上报 issue 已创建，issue id 已回写
优先级是否合理	根据影响范围与阻塞程度判断
补全方式是否可行	责任人、产出形式、归档位置和验收标准明确
闭环是否可验证	补全后能通过 memory_search / wiki_search 命中

审核结果与处理

结果	处理方式
接受	创建关联的 Multica 补全任务并明确责任人
拒绝	在原上报 issue 评论中说明理由，关闭 issue
升级	转刘炜承决策，在 issue timeline 与评论中留存记录

---

10. AGENTS.md 注入模板（同步替换旧流程）

## 📚 知识缺口上报

> 完整 SOP 见 `specs/SOP-017_知识缺口上报SOP_v1.4.md`（批准后的生效文件；草案阶段文件为 `specs/SOP-017_知识缺口上报SOP_v1.4_草案.md`）。⚠️ **注入护栏：本模板仅在 v1.4 批准生效后注入各 Agent AGENTS.md，批准前不得注入。** 本章节应内联到各 Agent 的 `AGENTS.md`“企业知识库”章节；若该 Agent 实际另有独立 `TOOLS.md`，可同步注入，但不得把 `TOOLS.md` 当作唯一落点。

### 触发条件
执行 SOP-016 检索后，满足以下任一条件需上报：
1. 核心业务数据 / SOP / 决策依据缺失；
2. 缺失影响任务交付质量或决策准确性；
3. 无法通过 memory_search / wiki_search / 思源全文搜索获得必要知识。

### 不属于知识缺口的情况
直接引用 SOP-017 v1.0 第 3 节，不另行维护副本。

### 上报流程
1. **记录**：在 `memory/YYYY-MM-DD.md` 与当前任务评论中使用标准格式记录；
2. **建单**：执行 `multica issue create`，并回写 issue id；
3. **通知**：通过 `sessions_send` 通知 COO，正文包含 issue id；
4. **审核与补全**：COO 基于已存在的 issue 审核后创建关联的 Multica 补全任务；
5. **闭环**：COO 验收并关闭 issue，通知原上报 Agent。

### 标准格式
见 SOP-017 第 6 节。核心字段：缺口类型、缺口描述、影响范围、紧急程度、建议补全方式。

10.3 统一占位符口径

• 交付物正文不得残留任何表示“尚未确定”的中文措辞或英文缩写占位标记；具体禁词以 COO 复检清单为准；
• 尖括号占位符仅允许出现在可复制执行的命令示例与格式模板中；复制执行前必须替换为实际值；
• <high|medium|low> 只能出现在优先级命令示例中，实际值必须按 §8 判据选择；
• 交付复检统一执行 COO 约定的占位词扫描规则：正文禁词命中即不通过；命令示例与格式模板中的尖括号占位符另行人工核验其可替换性。

---

11. 生效、迁移与维护

11.1 生效条件

本文件为 v1.4 草案。以下条件必须全部满足后方可生效：

1. COO 独立复检通过；
2. 刘炜承批准；
3. 依据 BIZ-19《Agent 内容存储与分发标准》把批准后的正文同步入思源知识库，建议路径 /规范/SOP-017 知识缺口上报 SOP v1.4；
4. 同步后实测 memory_search(query="知识缺口上报 SOP") 与 wiki_search(query="知识缺口上报 Multica 建单") 均命中正文，而不是仅命中 MEMORY.md 索引条目；
5. 在复检评论贴出两个查询各自的命中路径与正文原文片段，并绑定 BIZ-162 的闭环结果；
6. 生效后以新文件替换现行引用，但不得改写 v1.0 本体或 v1.1 草案，以保留历史基线；
7. 同步更新各 Agent AGENTS.md“企业知识库 / 知识缺口上报”章节中的旧上报步骤；仅当某个 Agent 实际存在独立 TOOLS.md 时，才同步更新该文件。

11.2 检索层准入与 BIZ-162 绑定

BIZ-162 记录的问题是 SOP-017 / SOP-016 正文未进入 Agent 运行时检索层。本版与其明确绑定：

• BIZ-162 是本 SOP 生效前置条件，不得与本 SOP 脱钩；
• 正文同步思源后，须分别执行：
  • memory_search(query="知识缺口上报 SOP")；
  • wiki_search(query="知识缺口上报 Multica 建单")；
• 两次查询都必须在命中路径中展示正文中的规则片段，例如 Multica 建单、issue id 回写与 Gitea 退位表述；
• 若只命中索引条目、只命中其中一个通道，或思源搜索仍为 0，则 BIZ-162 不得判定闭环，本 SOP 不得生效；
• 复检评论必须记录命中路径、原文片段、查询词和实测时间，作为准入证据。

11.3 迁移要求

1. 以各 Agent 的 AGENTS.md 为主落点，检查并替换“企业知识库 / 知识缺口上报”章节中的旧上报步骤；不得因不存在独立 TOOLS.md 而判定迁移无法执行；
2. 仅对实际存在独立 TOOLS.md 的 Agent 同步更新该文件，避免重复维护两份冲突规则；
3. 迁移后逐 Agent 验证 AGENTS.md 至少命中一次 multica issue create，并命中正确负责人参数与 issue id 回写要求；
4. 存量、尚未建 Multica issue 的知识缺口，按本 SOP 第 5 节补建并回写；
5. 已存在的旧仓库 issue 不自动迁移为 Multica issue，但须在巡检报告中列出待补建清单；
6. 对 Multica 建单失败项，保留失败日志，修复后补建，不以旧仓库替代。

11.4 维护信息

• 维护人：COO（陆怀瑾）
• 起草协助：刘诗妮（secretary）
• review 周期：每季度一次，或发生流程通道变更时即时修订
• 基线保留：SOP-017 v1.0 本体保持零改写（原 v1.0 落盘位置与文件名沿用不变，不改名、不覆盖；路径以 Git 历史为准）

---

12. 版本历史

版本	日期	变更内容	审批
v1.0	2026-07-06	初始版本；第 5 节 Step 3 使用旧工单通道	刘总
v1.1 草案	2026-10-29	上报主通道改为 Multica；增加 issue id 回写；统一标准格式；量化改为直接计数；Gitea 退位为版本控制	COO 复检打回
v1.2 草案	2026-10-29	闭合 G 分母与反刷分口径；纠正建单/通知/审核时序；新增思源入库与双通道正文命中准入；priority 改为分级占位符；统一占位符口径；改用已实测 COO 直投键	COO 二次复检通过主体、发现 1 阻断 + 2 必改 + 1 建议
v1.3 草案	2026-10-29	修正建单负责人参数；迁移主落点改为 AGENTS.md；覆盖 Multica 五个 priority 枚举；新上报卡改用 todo 进入看门狗巡检	COO 复检主体通过，遗留 3 处文字层瑕疵（由 v1.4 修正）
v1.4 草案	2026-10-29	修正 §11.1 首行版本自称（v1.2→v1.4）；§11.1 第 3 条思源入库路径版本号与生效文件对齐（v1.4）；§10 注入模板抬头改指生效文件 specs/SOP-017_知识缺口上报SOP_v1.4.md 并加「批准前不得注入」护栏	待审（COO 逐条复检）

---

本草案承接 BIZ-158，并绑定 BIZ-162 检索层闭环。经 COO 复检、刘炜承批准且第 11.1 节全部准入条件满足前，SOP-017 v1.0 仍为现行基线。