S10 任务收尾总结SOP

类别：SOP（用户级全域规范）
名称释义：场景B任务结束后（V1.4：场景A禁止触发），用约 200 字总结「当前进展 + 核心结论 + 遗留问题」；遗留问题按类别分组、组内按 P0–P3 优先级排序，并逐条改写为可直接复制启动新任务的增强提示词
版本：V1.8（2026-09-30 升级，纪律一增「预估取数独立口径」铁律——方案阶段全流程 Token 预估须取台账 token_ledger.jsonl 同类任务实测均值，禁由施工方凭感觉自估，并与实测值同口径（gross／net）可比；炳哥 2026-09-30 定标）｜V1.7（2026-09-24 升级，新增「四条常驻纪律」一节——开工先出方案＋Token 闸（>8000 先请示）／删除前置四列报备／收尾只用白话＋照报 Token／遗留只出 Markdown 方案 Prompt（限治理管家）＋无遗留喊口号；炳哥 2026-09-24 定标「连行政法规 S10 一起改」）｜V1.6（2026-09-20 升级，新增「白话呈现」一节——收尾话一律用日常白话、禁行业黑话、Token 照报并附白话注解；锚定宪法第22条与基本法 M5.7）｜V1.5（2026-09-10 升级，新增「token 读数可信性」——以 trace.sessionId 为唯一归属键、目录名无关、命中后不施加时间过滤；禁止以缓存值冒充真值；可疑时先跑 _tools/token_audit.py。含 V1.4 配套：场景隔离（S10 仅场景B任务触发，场景A禁止触发）、生效状态机（effective_status pending→active，G-1 根治）、治理文档场景细则（G-2 根治）、架构图版本-规则状态联动标注（G-3 根治）、场景A遗留项一行索引（G-4 默认采纳）；2026-09-04 用户裁定·全域统一。此前 V1.3 四步流程、V1.2 清零硬闸、V1.1 分组分级+五要素结构不变）
权威源：宪法第22条【E 交付与验收层】「收尾白话呈现」款项 ＋ 基本法 M5.7；用户级记忆 C:\Users\xub\.workbuddy\MEMORY.md「收尾白话」条（2026-09-20 重锚）。原「§〇 第 6 步」引址已随宪法第49条 MEMORY 清空轮废止，历史原文见 spec\3.行政法规\_archive\。
固化位置：~/.workbuddy/MEMORY.md（所有 Agent 一律生效）

任务收尾总结 SOP（2026-08-25 确立 · 2026-08-29 升级 V1.1 · 2026-08-31 升级 V1.2/V1.3 · 2026-09-04 升级 V1.4（场景隔离）· 2026-09-10 升级 V1.5（token 读数可信性）· 全域规范）

固化与范围：本 SOP 为用户级全域规范，固化于本文件，对所有工作空间、所有 Agent 一律生效（V1.4 起：触发范围限于场景B任务，见「触发条件」），除非用户明确要求豁免。是「启动五步」的收尾对应物——启动五步管「怎么开始」，本 SOP 管「怎么结束」，二者构成任务完整闭环。

触发条件

• 模式：所有模式（Craft / Plan / Ask）。
• 场景（V1.4 · 2026-09-04 用户裁定·场景隔离）：仅场景B任务结束后触发——即涉及 skill/专家升级、升版、迭代、训练、知识注入、订阅源训练、规则库写回、四件套生成、权威库发布、宪法/规范修订的任务。场景A（通用执行流：公众号单篇写作、报告生成、排版、画图等日常业务交付）禁止触发本 SOP。判定信号与优先级见 _tools/scene_gate.json（单一事实来源）；Stop 审查器第 0 步执行场景判定，场景A直接放行。
• 生效状态机（V1.4 · G-1 根治）：场景隔离以 _tools/scene_gate.json 的 effective_status 为生效判据——非 active（pending）时按现行全域规则（任何任务每次结束后收尾）执行，生效前零行为变化；三处部署落地（hooks.Stop prompt / MEMORY §〇 第6步 / 本 SOP）且 V1–V12 回归通过后方置 active。
• 治理文档场景细则（V1.4 · G-2 根治）：产出治理类文档/图表/报告，未写入 spec\3.行政法规\范式、spec\3.行政法规\宪法数据库、skills_registry.json、style_rules*.json、versions/ 等权威位置（仅落任务夹产出/）→ 判场景A；场景B = 改变治理资产状态（规则库/登记表/规范/宪法内容或版本）。
• 场景A遗留项一行索引（V1.4 · G-4）：active 后场景A收束时，回复末尾输出一行「遗留状态：延续前轮 <级别><编号> N 项，详见增强提示词库」；用户当轮裁定改静默则从之。
• 混合会话以最后一轮实质动作所属场景为准；用户令牌 S10_FORCE / S10_OFF 显式覆盖。
• 满足即启用本 SOP，不另行询问用户。

核心动作（任务结束时执行）

在最终回复里用约 200 字总结本任务，固定三要素、缺一不可：
1. 当前进展：本次任务完成了什么（已完成项、关键动作、当前达成状态）。
2. 核心结论：本次任务得出的最重要结论 / 结果 / 发现 / 决策依据 / 可复用经验（一句话点透）。
3. 遗留问题：尚未解决的事项、待办、风险、下一步建议——先按类别分组，再在组内按优先级排序，并逐条改写为增强提示词（见下两节）。

遗留问题分组分级（V1.1 新增，两步走）

• 第一步·按类别分组：功能开发 / Bug修复 / 性能优化 / 文档完善 / 架构调整 / 治理合规 / 其他（可扩展类别，按实际任务增删）。
• 第二步·组内按优先级排序：
• P0 紧急：阻塞主流程 / 数据安全风险，须立即处理；
• P1 高：近期必须处理（影响交付或下阶段依赖）；
• P2 中：规划内处理（不影响当前交付）；
• P3 低：可延后 / 优化建议。
• 每组内按 P0→P1→P2→P3 顺序列出；无遗留问题的类别不出现。

结束判定硬闸（V1.2 新增·V1.3 扩展，用户 2026-08-31 裁定·全域无条件生效）

• P0/P1/P2 级遗留必须清零：存在 P0（阻塞主流程/数据安全风险）、P1（近期必须处理，影响交付或下阶段依赖）或 P2（规划内处理，影响当前交付的完善度）级遗留，即不得宣布任务结束——须当场处理，或如实声明「任务未完成、被 P0/P1/P2 阻塞」。
• P3 允许带出：不影响当前交付的低优先级问题可随任务结束携带，但必须如实登记（分组分级）并附增强提示词。
• 判定顺序（三闸全过才可结束）：① 核心交付完成 → ② P0/P1/P2 清零 → ③ P3 如实登记。

增强提示词改写（V1.1 新增 · V1.3.1 结构化格式升级）

每个遗留问题随后改写为一条可直接复制启动新任务的增强提示词，每条须含五要素：
1. 明确目标：一句话说明要完成什么、验收标准是什么；
2. 必要背景上下文：相关路径、文件、历史决策、环境约束（如受管 Python 路径、盘位白名单、版本基线）；
3. 具体参数与约束：输入、参数值、范围限定、不可违背的硬约束（命名规范、四件套、安全红线等）；
4. 期望输出格式：交付物形态（文件 / 格式 / 目录）、命名规范、落盘位置；
5. 简短示例：给出 1 条输入输出样例，说明预期效果。

撰写标准：粘贴到新会话即可直接执行、无需二次解释。

输出格式（双格式，默认 Markdown 结构化）：五要素字面串 【目标】/【背景】/【参数与约束】/【输出格式】/【示例】 必须齐全且可机检（Stop 钩子据此判存在）。
- 格式 A（紧凑代码块，等效可选）：整段五要素代码块。
- 格式 B（Markdown 结构化，默认优先）：以 #### <编号> 增强提示词（可直接复制启动新任务） 为小标题，五要素用加粗锚点 + 列表项呈现，长内容分段展开，便于直接复制。两格式等价，推荐 B。

遗留问题标准化处置四步流程（V1.3 新增 · 衔接 MEMORY §〇·C·永久指令 · 全域强制）

本流程为任务收尾阶段处理遗留问题的永久指令，接续上节「分组分级」「增强提示词改写」两节与 MEMORY §〇·C「两板斧」模板。自 2026-08-31 起，所有任务收尾阶段自动执行本流程，无需用户重复指定；settings.json → hooks.Stop 审查器已同步升级校核本流程字段（见「系统级强制兜底」一节）。
本流程仅增补处置细则，不改动上节「三要素」与「分组分级」结构，亦不改动下文「结束判定硬闸」判据。

四步流程：

第一步（路由裁定）— 一刀切规则（P0+P1=0）适用项
- 触发：用户已明确裁定本任务「适用一刀切规则（P0+P1=0）」。
- 处理：该类遗留问题直接按用户裁定结果处置（典型为 P2/P3 直接登记带出），不附加原因说明、不附加风险说明、不附加增强提示词，仅在分组分级表格如实呈现裁定结论与处置结果。

第二步（非裁定项逐条补充）— 其余未被裁定的遗留问题
对每一个未被上述裁定覆盖的遗留问题，在分组分级表格之外逐条补充两项结构化字段：
1. 原因说明：问题产生的根本原因——溯到机制/流程/约束层，非表象描述（如「判定器对文件名不含『范式』的 md 不豁免 STD-A-001，导致误报」而非「报了 P1」）。
2. 风险说明：须覆盖三个及以上风险维度，至少含：
- 系统风险（对运行/数据/流程的当前或潜在破坏及波及范围）；
- 技术判断风险（误导后续决策、错误归因致误改、掩盖真实根因）；
- 其他相关风险维度（时序/合规/协同/审计追溯等，按项补）。

第三步（五要素增强）— 对每个遗留问题应用增强提示词
完成第二步补充后，对每个遗留问题套用上节「五要素增强提示词」（目标/背景/参数与约束/输出格式/示例），严格遵循 MEMORY §〇·C 最新版五要素模板的字样、顺序、字段约束（禁止自创标签）。分组分级表行 ↔ 原因/风险补充 ↔ 增强提示词 三者一一对应、互为索引。

第四步（永久化与自动执行）
- 本流程已固化为机器级记忆（MEMORY.md §〇·C·永久指令），为后续所有任务收尾阶段的默认行为。
- Stop hook 审查器判据已升级：收尾须含「三要素 + 分组分级 + 每个非裁定遗留问题的原因说明+风险说明 + 增强提示词五要素」，且 P0/P1/P2 清零硬闸不变；缺失即注入 reason 强制补出。

字段落地示例（非裁定 P1 项）
| 级别 | 编号 | 遗留问题 | 位置 |
|---|---|---|---|
| P1 | F-3 | 导出脚本对空表未做零行保护，偶发 IndexError | scripts/export.py:88 |

F-3 原因与风险
- 原因说明：导出函数假设结果集恒非空，未对查询零行分支做 guard，根因为「缺少空结果契约前置校验」的流程缺陷。
- 风险说明：①系统风险——线上导出任务偶发中断、下游定时报表缺数；②技术判断风险——易被误判为数据缺失而非代码缺陷，致错误回溯数据源；③其他——故障不可复现时排查成本陡增、审计追溯困难。

F-3 增强提示词（Markdown 结构化 · 可直接复制启动新任务）
- 【目标】：为 export.py 增加零行结果保护，使空结果集导出为合规空表而非抛错。
- 【背景】：2026-08-31 收尾发现 F-3：export.py:88 在查询零行时偶发 IndexError，已发生 2 次线上导出中断。
- 【参数与约束】：仅新增 guard 分支，不改既有非空路径逻辑；空表必须保留表头与 schema（字段定义不变）。
- 【输出格式】：修改后 export.py 片段 + 零行单测用例 + 复跑验证结果（验证「空查询→含表头空表」）。
- 【示例】：SELECT ... WHERE 条件无匹配 → 输出含表头空表（0 行数据），不再 IndexError。

完整示例（V1.1 提供）

示例·收尾总结（约 200 字）：
① 进展：已完成 X 模块重构，CI 全绿，3 项冒烟通过。② 核心结论：采用 Y 方案后查询耗时下降 40%，决策依据为压测数据，可复用经验是分层缓存先行。③ 遗留问题：
【Bug修复】P1：登录页在 Safari 偶现白屏（未兼容 -webkit- 前缀，app/login.css:42）。
【性能优化】P2：报表接口 95 分位延迟 1.2s，目标 <800ms。
【文档完善】P3：README 缺少新接口示例。

示例·增强提示词（对应上述 P1）：
「修复登录页 Safari 白屏。目标：Safari 16+ 打开 /login 不再白屏，验收为截图对比。背景：项目根 /app/web，React 18 + Vite，问题疑似 CSS backdrop-filter 缺 -webkit- 前缀（定位见 app/login.css:42）。约束：只改 CSS、不改业务逻辑、不得引入新依赖。输出：提交修复，PR 描述附 Safari 修复前后截图。示例：backdrop-filter: blur(4px) → -webkit-backdrop-filter: blur(4px); backdrop-filter: blur(4px)。」

白话呈现（V1.6 新增 · 2026-09-20 · 全域无条件强制）

准据：宪法 第22条【E 交付与验收层】之「收尾白话呈现」规则（2026-09-20 经人·炳哥指令设立）＋ 基本法 M5.7。本节为两者的落地细则；与宪法第22条不一致的，以宪法为准（基本法 2.1 裁决序）。

一、强制呈现（四件事，缺一不可） 收尾那段话必须用日常白话讲清：

1. 做了什么——这次到底干了哪些事；
2. 结果如何——现在的状态、成了还是没成；
3. 还差什么——没搞定的、有风险的、需要您拿主意的；
4. 下一步怎么办——建议的下一步动作。

二、禁用行业黑话 给人看的收尾话里禁止出现信息行业专有说法。禁用词表（示例，含同义变体；发现新词即行补入）：

判定口径：把收尾话念给一位不懂电脑的人听，他听不懂的词就是黑话。
例外（适用域切分）：规范本体（宪法／基本法／行政法规／地方法规／地方规章）正文、本节自身的字段名与机器可读标识不受本节限制——本节只约束给人看的那段收尾话。此为宪法第22条第3项的适用域切分，非冲突。

三、Token 照报并附白话 Token 消耗量必须照报（宪法第7条、第35条工程目标），但须附白话注解，格式固定为：

本次共消耗 XXXXX 个字（Token）。

禁止只甩数字、禁止以「若干」「较多」等模糊词代替、禁止因怕出现专业词而干脆不报。

四、与「约 200 字三要素」的关系 本节不改上文三要素结构与分组分级口径，只约束用什么话写：三要素仍照给，白话呈现是写这三要素时的用语要求。白话收尾＋Token 白话读数，合起来构成最终回复的收尾段。

五、检查方式（现状态与缺口如实登记） 现阶段由收尾自查 ＋ 人实质验收把关（宪法第22条实质验收节点）。Stop 审查器的「黑话扫描」字段升级尚未落地，已按 S10 硬闸登记为遗留项；该字段上线后本节第四款即由机器强制兜底，无需另行修法。

四条常驻纪律（V1.7 新增 · 2026-09-24 · 炳哥定标「连行政法规 S10 一起改」）

准据与范围：本节为用户级全域规范，固化于本文件；纪律四限「综合治理管家」载体适用，其余三条（一、二、三）为全域常驻口径。同步落点：综合治理管家 SKILL.md §十四（同一口径的真源之一，两处互为投影）。

纪律一 · 开工先出方案 ＋ Token 闸

• 每个任务开工前，脑（K3）须先给出施工方案，并判断该方案的全流程 Token 总量。
• 判据：预估全流程 Token > 8000 ⇒ 优先级请示用户（炳哥），放行后方可动工；≤ 8000 方可直接施工。预算内亦须在方案中明示预估值。
• 口径统一称「Token」（不称积分）。
• 预估取数铁律（独立口径 · 收口轮增立）：方案阶段的全流程 Token 预估必须取自独立口径——台账 token_ledger.jsonl 中同 task_type 实测 actual_token 的均值（无同类样本时取全体实测均值并注明样本量）。禁止由施工方（手）凭感觉给出预估值；方案中须明示取数算法与样本量。预估值与实际值须同口径（gross＝含缓存命中的总 token；net＝非缓存 prompt ＋ completion；二选一并言明），跨口径比较须换算后并列；收尾时对预估／实际偏差留痕，偏差超 1 个数量级者须在收尾话中说明成因。

纪律二 · 删除前置四列报备

• 每次删除文件前，须先列出四列报备清单交用户核准：
  序号 — 文件名 — 文件归类（宪法／基本法／行政法规／地方法规／地方规章，即五层中哪一层）— 文件路径。
• 未报备不得删除。非破坏动作（同盘 rename／同盘归档）亦须逐件列出以备核，但可批量报批。

纪律三 · 收尾只用白话 ＋ 照报 Token

• 收尾总结一律只用白话，讲清「做了什么／结果如何／还差什么／下一步怎么办」，不再显示其他机器语言（禁信息行业行话、禁堆砌内部术语；听不懂就换说法）。本条与上文「白话呈现」节同源，为其在治理管家场景下的强化表述。
• 必须显示任务全流程 Token 累计消耗量，格式照写：本次共消耗 XXXXX 个字（Token） —— 不许只甩数字。

纪律四 · 遗留只出 Markdown 方案 Prompt（限治理管家）

• 任务结束若仍有遗留问题：仅给出一份解决方案的 Prompt 的 Markdown 文档（自包含：角色／红线／效力层级／准据绝对路径／铁律／任务清单／终检判据／收尾要求）。
  仅限「综合治理管家」载体，其他 skill 与专家不需要本条。
• 若无问题：收尾只输出一句 —— 炳哥万岁，全部没问题。
• 本条取代综合治理管家 V1.3.0–V1.6.0 旧「解决方案 HTML ＋ 完整版 Prompt」两件交付口径（V1.6.1 起改为仅 Markdown 一件）。

token 读数可信性（V1.5 新增 · 2026-09-10 · 全域强制）

背景：_tools/token_usage.py 曾长期输出严重低估伪值（2026-09-10 实测：报 711，真值 12,483,317）。根因四重——① PID 错位（sessions/<pid>.json 的 pid ≠ traces/<pid>/ 的 worker pid）；② 命中失败仍输出上次 --dump 缓存，制造「有值但偏低」假象；③ 仅扫单 pid 目录；④ 时间过滤误杀（sessions 记录的是 worker 注册时刻，可晚于 trace 起始 10+ 分钟，被 300s 容差判为非本会话）。

• 取数口径（唯一权威）：以 trace.sessionId 精确匹配为归属键，遍历 traces/*/trace_*.json（目录名无关），且 sessionId 命中后不再施加任何时间过滤。脚本已按此修复（V2）。
• 禁止行为：不得以 sessions/*.json 的 pid 拼 trace 路径；不得在无命中时输出缓存值冒充真值（no-trace 即返回全零并显式声明）。
• 汇报口径：token 统计须标注 source_mode 与 generation_calls；确认为「本会话累计值」（含全部工具往返），非单轮增量；如需单轮增量，两次调用取差。
• 可疑时自查：读数与预期量级不符时，先跑 _tools/token_audit.py，一次给出「真实值 / 与缓存差异 / 逐 trace 根因」，确认后方可写入汇报或记忆。
• 时序诚实：trace 由宿主在轮末持久化，故当前轮最后一段消耗顺延至下轮可读——此属已知边界，如实标注即可，不得估算填充。

与其它收尾交付物的关系（并存，互不替代）

• 200 字总结（含分组分级 + 增强提示词） = 对话回复层面的通用收尾义务（本 SOP，任何任务都要）。
• 收尾三件套（S03/S04） = 落盘交付物（「当前进展+遗留问题」摘要 Word + 变更履历 Excel + 可选技术规范 Word），仅长项目续接 / 独立短项目触发。
• skill/专家迭代升版四件套（S06） = skill/专家迭代场景的落盘交付物。
• 三者并存、互不替代：即便已产出三件套 / 四件套，收尾仍须在最终回复里给出 200 字总结（含分组分级 + 增强提示词）。

系统级强制兜底

• ~/.workbuddy/settings.json 的 hooks.Stop 审查器已随 V1.1 升级：判定「三要素 + 遗留分组分级 + 增强提示词五要素」，缺失即注入 reason 强制补出，不再依赖自觉。V1.2（2026-08-31）再升级：新增「P0/P1/P2 清零硬闸」判定——存在 P0/P1/P2 级遗留却宣布任务完成，即注入 reason 拦截。

回执

• 场景B任务结束后（V1.4：场景A禁止触发；场景A收束仅输出「遗留状态：延续前轮 <级别><编号> N 项，详见增强提示词库」一行索引），在最终回复里给出约 200 字总结（当前进展 + 核心结论 + 遗留问题分组分级），并为每个遗留问题附可直接复制启动新任务的增强提示词；存在 P0/P1/P2 级遗留时不得宣布任务结束。
• V1.6 增补：上述总结必须用日常白话书写、禁止行业黑话（见「白话呈现」一节），并附「本次共消耗 XXXXX 个字（Token）」的白话读数。适用范围含场景A与场景B的一切任务（宪法第22条第6项：无豁免）。