产品经理助手（Product Manager Assistant）

这个 Skill 是什么

一个覆盖产品经理日常核心工作的完整工具箱，把八大能力收在一处：产品思维、需求分析（含需求池）、BRD、MRD、竞品分析、PRD（含产品战略）、产品图表、HTML 产品原型。它既能单独完成其中任何一项，也能按标准流水线从头到尾跑完整套产品流程。所有方法论、模板与框架速查都已内置在本 Skill 的 references/ 目录里，无需联网、不依赖外部工具。

怎么用

只要用一句话说清楚你要做的事，本 Skill 会自动判断该走哪个分支，并按该分支的完整流程产出结果。四步：

1. 说意图：告诉它你要做什么，例如「分析这个需求」「写一份 PRD」「画个泳道图」。
2. 判分支：它根据你的意图，定位到对应的内置方法论文件。
3. 🚨 动手前澄清（关键问题确认）：对照 references/pre-flight-clarification.md 的澄清清单，先识别并确认影响产出方向的关键问题（清单按分支分级：A 必问 / B 可跳过），再动手。提问纪律：一次 ≤4 题、每题给选项、用户描述里已说清的信息不重复问、用户明示特例（如「仅分析不入池」）时跳过。不允许跳过 A 类问题直接产出——真实 PM 的第一动作是提问而非产文档，动手前问清方向，远好过写完后返工。产出六类文档时把 A 类答案写进文档「澄清确认」块（check_docs.py B34 校验，见「注意事项」）。
4. 出结果：按该分支的完整流程产出分析结论、文档或图表。

典型用法

环境要求

> 仅做「需求分析 / BRD / MRD / 竞品 / PRD 文档与原型产出」时只需 Python，零外部依赖；两套 .mjs 校验器按需安装。各脚本头注释都含完整安装与 NODE_PATH 用法，本表为速查。

八大能力分支

> 各能力的完整方法论、模板与框架速查，均位于上表最后一列指向的 references/ 文件，直接读取即可。

意图判断要点：

• 意图叠加（如「写 PRD 时配一张泳道图」）→ 主文档走 PRD，配图走产品图表。
• 意图跨多步且未指定范围 → 先走需求分析，再按流水线推进。
• 用户已明确点名某一步（如「就写 PRD」）→ 直接进入该分支，不再重复判断。
• 用户提出一个具体需求（哪怕只是描述，未说"分析"）→ 先走需求分析，分析后自动登记入需求池（requirement-pool.md），这是需求管理默认闭环。

流水线顺序与终止纪律

[产品思维 — 贯穿全程]
        ↓
需求分析 → BRD → MRD → 竞品分析 → PRD → 产品原型
                        ↑ 需要可视化时随时走「产品图表」

• 产品思维是地基：凡分析/决策/方案论证，先以「逻辑→结构→系统」三层框架校准推理，再落具体分支。
• 产品图表不是独立步骤：在需求/竞品/PRD 需要配图时随时插入。
• 产品原型是 PRD 的可视化落点：常规流程 PRD 定稿后按 PRD 出可交互原型（PRD 第七章挂链接）；也可在写 PRD 前先出低保真原型讨论结构，再细化 PRD。

终止纪律（最高优先级）：需求分析是流水线第一道关口，其结论决定后续是否继续：

硬性约束：需求分析判定为 P3 / 伪需求 / 反向型时，不得主动推进 BRD / MRD / 竞品分析 / PRD。若用户坚持继续，先复述需求分析结论，再按其明确指令执行。

图表渲染约定（HTML 内直接呈现）

文档类分支默认输出 HTML 文件，图表随文档一并内嵌、打开即见，无需任何手动渲染。按图类型路由：

• 流程图 / 状态图 / 时序图 / 思维导图 / 系统循环图(CLD) → Mermaid 代码块（mermaid.js 自动渲染）。
• 泳道图 / DFD / 用例图 / 类图 → 一律 PlantUML 编码图片（scripts/plantuml_encode.py 生成 <img> 链接）。硬规则：已实测 Mermaid 的 subgraph 布局不可控，不存在「这次简单所以用 Mermaid」的例外。
• E-R 图 → 唯一按复杂度二选一：实体 ≤8 且无 M:N 且无需属性类型/主键 → Mermaid erDiagram（中文关系标签加引号）；否则 → PlantUML。
• 四象限图（SWOT/定位） → Mermaid quadrantChart。⚠️ Mermaid 中文引号规则（高频踩坑）：erDiagram 的关系标签、quadrantChart 的 x/y 轴文本/象限标签/数据点名称，中文必须用双引号包裹（如 : "提供"、"本方案": [0.35, 0.75]），否则报 Syntax error in text 图表不渲染；flowchart 等其余类型中文可直接写。完整规则与示例见 references/html-template.md。
• 鱼骨图 → 内联 SVG（scripts/fishbone_svg.py 生成：画布自适应、支持三层嵌套、子原因 1~4 个，嵌入 HTML 时用 CSS 控制尺寸、禁止改 SVG 内部）。
• BCG 矩阵 → 表格。

生成后校验（五件套，交付前必跑）：下面五个校验器全 PASS 才能交付；无 Node 环境时图表按 references/html-template.md 引号规则逐图自查。

• 原型若出现「页面覆盖-xxx / 菜单覆盖-xxx」FAIL = 漏了必备页面，补齐再交付（覆盖率规则见 references/prototype-guide.md「完整性约束」章）。

🚨 导航维护用脚本（2026-08-27 起）：文档类 HTML 左侧导航以文件夹树为唯一数据源，新增/删除/重命名文档后跑 scripts/sync_nav.py 全库一键重建（禁止手动逐份改，防漏更新）；bump/promote 已集成全库重建。

🚨 规范 ↔ 校验器同步约定（2026-08-27 起，防「规范更新但脚本漏改」）：任何硬性约束的增改（SKILL.md 或 references/ 里的「必须/严禁/禁止/硬性约定/一律」类条款），必须同步三步，缺一步视为规范未完成：

1. 在五件套对应脚本的规则列表加/改规则（check_docs.py / check_prototype.py / check_mermaid.mjs / check_consistency.py / check_prototype_runtime.mjs，规则集中在各脚本 _build_rules 或白名单/正则/规则函数处）；
2. 更新 references/skill-audit.md 审计清单对应条目（A/B/C 分类 + 状态）；
3. 回归审计——跑五件套扫一个真实项目全库（确认改动无误报/漏报）+ 至少一个相关坏样例被拦截（确认新规则真有效）。

每次改 Skill（规范或脚本）后回归审计必做：校验器是门禁，改坏了会造成误报（拦合法文档）或漏报（新规范没拦住），反而破坏信任。新增规范时先查审计清单——已有同类规则的直接扩展现有脚本，不新建孤岛校验器。

脚本化出图（推荐优先，见 references/product-chart-drawing.md）：LLM 只填结构化数据，语法/布局风险归零；仅复杂定制图才允许手写源码并必须过校验。

完整 HTML 骨架与四类图嵌入写法见 references/html-template.md；PlantUML 编码脚本见 scripts/plantuml_encode.py。若用户明确要求 Markdown，则降级输出 .md（图表退化为源码 + 渲染指引）。

原型输出：PRD 等文档需要产出可点击原型时，按 references/prototype-guide.md 生成 HTML 原型。先判端类型再选模板（两维）：用户端（商城/门户/采购前台）用顶部导航 + 内容流（无侧边栏）；管理端（后台/商家中心）用侧边栏 + 顶栏；移动端用手机壳 + 底部 tab。硬性约定：管理端原型 sidebar/标签栏只放页面导航（logo + 菜单/tab），严禁放任何跨文档链接（需求分析/BRD/PRD/其他原型等）——跨文档导航只属于文档类 HTML；且 </aside> 与 </div>(layout) 各仅一处，不得多闭合。（2026-08-27 补充：用户端原型不得出现侧边栏/面包屑/运营账号等后台元素，布局见 prototype-guide.md 6.1）

🚨 原型结构自检门禁（2026-08-27 起）：原型生成/修改后必须跑 scripts/check_prototype.py，全部 PASS 才可交付——端形态问题由脚本拦截，不依赖人工逐页发现，等价于 check_mermaid.mjs 对图表的地位。规则可扩展（脚本内 _build_rules）。

• 端类型结构自检：
• 用户端：禁侧边栏 / 后台痕迹 / 窄卡片堆叠；要求顶部导航、内容区 max-width、详情购物车订单表格化。
• 管理端：必须有侧边栏 + 菜单、禁用户端顶部导航；Modal 统一封装（openModal/closeModal + #modalMask/#modalBox，禁每弹窗一套遮罩）；.seg 双视图面板配对（有 data-filter 须有 data-panel 切换）。
• 全端通用——新增/编辑必须弹窗（禁就地展开表单，见 prototype-guide.md 6.6）：
• 禁止 display:none 表单容器 + toggle 展开、禁止整卡 innerHTML 替换为多输入表单、禁止「＋ 新增」按钮直接 appendChild/insertAdjacentHTML 加空壳占位行（待填写/待归类/新角色 等字样，B20 已补拦 addDictRow/addRole 类漏网）；
• 合规例外：单元格级 contenteditable、直接增行（addSkuRow 行即数据，「待定价/待上架」是业务状态词）、单字段改值；
• 同组操作按钮并排一行 + 按钮文案不用「＋」号（见 6.7，交付前全库 Grep「＋」应 0 命中）。
• 买家界面禁用内部供给术语：若项目存在「买家界面禁用内部供给术语」词表（后台/供给视角的概念词不给买家看），跑本脚本时加 --forbid=内部词A,内部词B 注入，脚本会在用户端原型全局扫描这些词（管理端不查；v1.13.0 起参数化，词表定义见 prototype-guide 5.4⑦）。

🚨 PRD↔原型同步门禁（2026-08-31 起）：用户提新需求或修改意见时，PRD 与原型必须同步检查、同步修改，严禁只改一边——「PRD 写了但原型演示不出来」与「原型有但 PRD 没定义」都属不一致。

改动后跑 scripts/check_consistency.py（可传项目根 / 规划中目录 / PRD 文件），它校验：

• 5.1 功能清单里每个 F-xx 是否都有原型页面映射（漏映射即 FAIL）；
• 核心页面表引用的编号是否在功能清单中存在；
• PRD 里的原型链接与 #page-xxx 锚点是否真实存在（顺带拦截升版本后链接未同步）。

--forbid=词 拦截已废弃术语回潮（传刚被替换掉的旧术语，如某入口「选购单」改名「购物车」后把「选购单」传入）。R5/R6 为 WARN、不阻断。

典型触发场景：

1. PRD 新增/拆并/改名功能 → 同步在原型加页或改页，并把该页面登记进 PRD「核心页面」表（写清对应 F-xx）；
2. 原型增页/删页/改名 → 同步修订 PRD 核心页面表与链接；
3. 升版本号 → 跑一次，确认 PRD 正文的原型链接已随文件改名同步。

文件夹结构与版本管理

项目文件夹结构（按文档类型分子文件夹）

每个项目一个根文件夹（如「XX 交易平台」，XX 为占位项目名），内部按文档类型建子文件夹。同类文档可有多份，命名要清晰：一眼看出「这份文档的核心 + 什么时间生成的」。

{项目根文件夹}/
├── _项目状态.md                # 项目状态快照（Skill 自动维护，接续/迭代时先读它）
├── BRD/                        # 多份：项目初始一份，重大改动再单独写一份
│   ├── BRD_交易闭环升级_2026-08-25.html
│   └── BRD_供应链金融_2026-09-01.html
├── MRD/                        # 多份：同上
│   └── MRD_线上B2B市场定位_2026-08-25.html
├── 竞品分析/                    # 多份：每次主题/维度可能不同
│   └── 竞品分析_某竞品对标_2026-08-25.html
├── 需求分析/                    # 需求池唯一 + 需求记录多份
│   ├── 需求池.html             # 唯一一份（所有需求都落入这里，追踪状态）
│   ├── 需求记录_供应商账期_2026-08-26.html
│   └── 需求记录_物流追踪_2026-08-27.html
└── PRD及原型/                   # PRD 与原型成对，三态流转（见下）
    ├── 已发布/                  # 只留最新一份
    │   ├── PRD_V1.0.0.html
    │   └── 原型_V1.0.0.html
    ├── 已定稿/                  # 只留最新一份
    │   ├── PRD_V1.1.0.html
    │   └── 原型_V1.1.0.html
    └── 规划中/                  # 当前正在编辑的最新一份
        ├── PRD_V1.2.0.html
        └── 原型_V1.2.0.html

> 产品战略归入 PRD：产品定位、产品架构、产品路线图等内容不单独出文档，直接作为 PRD 的第一章（「产品总体设计」之前），由 references/prd.md 覆盖，详见其「产品战略」章节。

> 项目状态文件（自包含接续机制）：项目根放一份 _项目状态.md（Skill 自动维护），记录流水线进度 / 当前 PRD 与原型版本 / 需求池编号范围 / 文档清单 / 术语约定，是接续与迭代的锚点——发项目给他人或换环境后，先读它就能无缝接续。接续（迭代/升级/改 PRD/改原型/加功能/改术语）前必先读它，产出或迭代后必更新它。详细规范见 references/project-state.md。

命名规则：

• 文档类：{文档类型}_{核心主题}_{日期}.html。核心主题由 AI 根据内容概括（一句话点明这篇文档讲什么），日期 YYYY-MM-DD。
• 原型：原型_{端标识}_V{版本}.html（单端省略端标识；多端用 采购端/供应商端/平台管理后台 等）。
• PRD：PRD_V{版本}.html。

PRD 及原型的「三态流转」（核心）

PRD 与原型成对存在，按生命周期在三个子文件夹间流转：

流转规则（逐级复制 + 覆盖，每个文件夹只留最新一份）：

1. 新版本先在「规划中」编辑（产品经理可随时让 AI 更新 PRD 和原型）。
2. 确认定稿 → 复制「规划中」的 PRD+原型到「已定稿」，覆盖「已定稿」旧文件。
3. 确认发布 → 复制「已定稿」到「已发布」，覆盖「已发布」旧文件。
4. 如此循环，版本号全局递增（已发布 < 已定稿 < 规划中），三段式 主.次.补丁：补丁=改文案/纠错/补字段 +0.0.1；次版本=增删功能/改流程/改结构 +0.1.0；主版本=方向性重构 +1.0.0。

> 🚨 位次判定强制门禁（2026-09-01 用户问责后补强；2026-09-02 v1.15.0 起脚本硬拦）：升版前必须先按改动性质定位次，不得默认 +0.0.1——新增/删除功能、改流程、改结构、页面/模块级改造一律 +0.1.0（升第二位）；仅改文案/纠错/补字段/修 bug 才 +0.0.1（第三位）。判断依据 = 本次改动是否改变「能做什么」（功能/流程/结构）vs 只是「修好已有的事」（修复/文案）。拿不准时按「升第二位」处理（宁高勿低）。「规划中」阶段同样适用，不因未发布而放宽。
> 机器兜底：bump_version.py 新增 --kind functional|fix|refactor（默认 functional）——按性质算出「新版本必须是多少」，--new 落在错位次即 exit 1 并打印规则（与 skill_bump.py 同一套）。此前只有文档写门禁、脚本不校验，功能级改动压第三位无人拦（B40）。纯文案改动请显式传 --kind fix。

> 注意：因为每个状态文件夹只留最新一份，历史版本靠 PRD 头部「变更记录」表追溯，不保留多份文件副本。若确需留档某历史版本，可额外复制到该状态文件夹内用 _归档_{版本} 后缀命名，但常规不做。

> 三态流转用脚本，勿手动执行：定稿/发布（复制覆盖 + 需求池回写 + 状态文件更新 + 全库导航同步）已固化为 scripts/promote_version.py，在项目根目录执行：
>
> > python3 {skill路径}/scripts/promote_version.py --action finalize --version V1.0.1 --req REQ-002 # 定稿 > python3 {skill路径}/scripts/promote_version.py --action release --version V1.0.1 --req REQ-002 # 发布 >
>
> 改前先加 --dry-run。--req 不传时自动从 PRD 变更记录「涉及需求」列解析。手动复制/覆盖极易漏需求池回写、漏导航更新，务必用脚本。

PRD 变更记录写法（追加到文档头「变更记录」表，含「变更对象」与「涉及需求」列）：

> 「变更对象」列取值：本次改动涉及的文档/端，如 PRD、原型_采购端、原型_供应商端、原型_平台管理后台、全部原型，多个用 / 分隔。只改了原型就只填原型名，读者据此知道 PRD 正文没动；PRD 与原型都改则都填。方便多端项目追溯「这个版本动了哪个端」。

> 🚨 变更管理强制门禁（最高优先级，任何修改动作都触发，无例外）：只要 PRD 或原型的任何内容被修改——哪怕只改一个词、一个术语、一处文案、一个数字——都必须同步三步：① PRD「变更记录」表追加一行（含变更对象列）；② 版本号递增（文案/纠错/补字段 +0.0.1）；③ 文件名改新版本号 + 全库更新指向它的链接（各文档 doc-nav、PRD「核心页面」、系统原型章节里的原型链接）。词级小修改也是一次版本变更，严禁「只改内容不记变更」。 详见 prd.md 版本管理约定。

> 版本递增用脚本，勿手动重写：第②③步（重命名 + 全库链接/版本号同步 + 变更记录追加 + 验证）已固化为 scripts/bump_version.py，在项目根目录执行即可，避免每次手写临时脚本：
>
> > python3 {skill路径}/scripts/bump_version.py --old V1.0.1 --new V1.0.2 \ > --note "术语统一：下单入口「选购单」改名「购物车」" --target PRD/原型_采购端 --req REQ-002 >
>
> --target 填本次改动对象（PRD / 原型_采购端 / 原型_供应商端 / 原型_平台管理后台，多个用 / 分隔），自动写入变更记录「变更对象」列；不传则默认 PRD。改前先加 --dry-run 干跑看效果。参数说明见脚本 docstring。

🚨 需求池联动强制门禁（需求 → PRD → 需求池闭环，v1.11.18 起最高优先级）：

• 需求池文件固定位于 {项目根}/需求分析/需求池.html（唯一，HTML 格式，套 HTML 骨架 + 表格），记录所有需求的编号/提出时间/需求核心/分类/优先级/状态/PRD版本。
• 每次 PRD 迭代，第一步就是「识别涉及需求」：改动 PRD / 原型任何内容之前，先对照需求池判断本次改动对应哪些需求（按需求核心比对）。新用户反馈（哪怕一句话、一个词）必须先登记需求池再动手——用 pool_status.py register --core "<需求核心>" --cat <分类> 登记（状态=已入池；需求已分析则加 --priority Px 直接登记为已评估；判定不值得做则 reject 标已拒绝并保留记录），严禁「只改内容、需求池不登记」。
• 变更记录「涉及需求」列只允许写 REQ-xxx / F-xx / 逗号或斜杠分隔 / '-'，禁止裸写「用户反馈」「-」以外的自由文本——该列格式与编号存在性由 check_docs.py B22 机器校验兜底，写错即 FAIL。
• 每次升版（bump_version.py）自动回写需求池：--req 传 REQ 编号（支持逗号/斜杠分隔、REQ-x~REQ-y 范围）即把涉及需求的状态→规划中、PRD版本→本版；规划中迭代也生效，不依赖定稿/发布。定稿/发布走 promote_version.py：定稿（finalize）→「已定稿」、发布（release）→「已完成」。需求状态与 PRD 生命周期一一对应（需求池 6 态：已入池/已评估/规划中/已定稿/已完成/已拒绝）。
• 需求记录 ↔ 需求池一一对应（v1.11.22 起强制）：每条需求池记录 ↔ 一份 需求记录_{核心}_{日期}.html。简单需求也统一「写需求记录 + 登记入池」（需求记录可精简为结论性文档，但不得省略——凡需要判断「要不要写」的环节就容易遗漏）。需求记录文档头 meta 区必须写「关联需求：REQ-xxx」字段（作者 ｜ 创建日期 ｜ 关联需求：REQ-xxx），编号存在性由 check_docs.py B30 机器校验（写错即 FAIL；存量缺字段仅 WARN 不阻断）。
• 需求池编号可点击化（v1.11.29 起）：需求池.html 需求台账「编号」列应可点击跳转所属需求记录——用 scripts/pool_link.py 一键生成（自动扫描各需求记录 meta「关联需求」建立 REQ→文档映射、编号列包 <a href="需求记录_x.html#REQ-xxx"> 且保留 td 属性、为存量需求记录补插 id="REQ-xxx" 锚点 span、无文档的 REQ 输出 WARN 提醒补建；幂等可反复跑）。新增需求记录后跑一次 pool_link.py 保持链接最新；bump_version / pool_status / check_docs 已兼容 <a> 包裹的编号（正则须带 (?:<a[^>]*>)? 与剥标签，防链接化后联动/校验静默失效）。
• 详细规则见 references/requirement-pool.md。

注意事项

• 接续项目先读 _项目状态.md：用户提到已有项目、或说「迭代/升级/改 PRD/改原型/加功能/改术语」时，先读项目根的 _项目状态.md（拿当前版本、需求池下个编号、文档清单、术语约定），再动手；产出或迭代后必更新它。若项目根没有 _项目状态.md，先按 project-state.md「盘点重建」从目录结构自举重建，不要凭空重做。（缺状态文件时 check_docs.py G6 规则会 WARN 提示。）规范见 references/project-state.md。
• 🚨 动手前澄清（v1.11.23 起，任何分支产出前必做）+ 澄清确认留痕（v1.12.0 起）：判分支后先跑 references/pre-flight-clarification.md 澄清清单，确认 A 类关键问题（受众/交付形态/范围边界/竞品名单/端类型/图类型等）再动手，禁止「进来就干」；用户已说清的信息不重复问，一次 ≤4 题给选项。产出六类文档（需求分析_/需求记录_/BRD_/MRD_/竞品分析_/PRD_）时，在文档最底部（</main> 前）写「澄清确认」弱化附注块（把 A 类答案落进文档；v1.12.0 曾放正文开头、样式醒目，2026-09-02 用户反馈喧宾夺主，v1.12.1 起改末尾弱化，模板与配套 CSS 见 html-template.md「内容排版约定·澄清确认留痕块」）——由 check_docs.py B34 机器校验（块须位于文档尾部 + 有实质答案内容 + 样式表含 blockquote.clarify 弱化规则；缺失/空壳/不在底部即 FAIL；已发布/已定稿快照豁免），防「澄清只发生在对话里、事后无法验证」。
• 修改已产出的 PRD / 原型时，必须同步走「变更管理强制门禁」（追加变更记录 + 版本号递增 + 文件名与全库链接同步）——包括用户提出的小修改（改术语、改文案、改列宽、修 bug 等），一律视为一次版本变更，不得只做文本替换。
• 各分支产出的术语、产品定位、命名前后一致（需求分析→BRD→MRD→PRD 共用同一套名词）。
• 版本号只由文件名承载（B37）：PRD/原型 HTML 的 <title> 不得写版本号（Vx.y）——写进 title 必随升版漂移（历史教训：原型 title 残留旧版本、与文件名对不上）。要展示版本请读文档头 meta 或文件名；check_docs.py B37 校验，违反即 FAIL。
• 文档类分支默认把成稿以 HTML 写入项目根对应类型子文件夹（见「文件夹结构与版本管理」章节），命名 {类型}_{核心}_{日期}.html；生成后务必在浏览器/预览面板确认图表正常渲染再交付。
• 成套交付文档时（需求分析/BRD/MRD/竞品分析/PRD 多份）：每份文档左侧加跨文档导航（html-template.md「文档左侧导航」章节）——导航 = 项目文件夹结构的镜像（文件夹名做 📁 分组标题、可点击收起/展开，PRD及原型 固定默认展开、其余 html 文件数 >3 默认收起；文档做缩进子项；PRD及原型按「已发布/已定稿/规划中」三态二级分组、PRD 与原型成对列出）；原型链接 target="_blank" 新页签、需求池 .html 与其他文档一样同页签跳转、当前文档 class="active"；链接用跨文件夹相对路径（如 ../BRD/BRD_xxx.html、../PRD及原型/已发布/PRD_V1.0.0.html）；原型 HTML 本身不加导航。
• 所有细节、模板、框架速查均在 references/ 对应文件中，无需联网、不依赖任何外部 Skill。

Skill 变更记录（最近摘要）

> 完整历史见 references/CHANGELOG.md。改 Skill 后升版用 scripts/skill_bump.py 一键完成（v1.12.0 起，三步合一 + 位次门禁 + 收尾自检，禁止手动改）：python3 scripts/skill_bump.py --new vX.Y.Z --kind functional|fix|refactor --note "变更说明"——功能级改造必须升第二位（如 v1.12.0），仅修复/文案升第三位；脚本自动完成 ① CHANGELOG.md 顶部追加 → ② frontmatter version 递增 → ③ 本摘要置顶并保留 5 条，收尾跑 skill_self_check.py（S1-S6 + W1 一致性自检）FAIL 即阻断。
> 说明：本区放在文档末尾（顶部保持纯功能入口，2026-09-02 起）。

• v1.16.3（2026-09-07） 修复 promote_version.py current_version_state：同版本号同时存在于规划中/已定稿时按状态优先级（已发布>已定稿>规划中）打破平局，定稿后当前版本状态不再误标为规划中
• v1.16.2（2026-09-07） 全面审计（2026-09-07）发现 4 真缺陷+2 缺口已闭环：①check_prototype _layout_no_flexlock 全文 flex:1 假 PASS（限定 .main/.content 块内）；②check_prototype _has OR 语义误用必备元素规则，删一项仍 PASS（改为 all + 文档化 OR vs AND 边界）；③补 prototype-guide 5.1「顶/底栏 flex:none 恒定可见」校验器 _mobile_scroll_region（移动端规则 50→51 项）；④check_docs _CHANGELOG_TABLE 精确类目匹配 → 类目顺序变即失配（B22/B31/B35 静默失效，第三例假 PASS），改为类目 token 匹配 + 表头回退（限定同 table 内防误抓别表）+ fail-safe 返回；③_CHANGELOG_SCROLL_WRAP 同样缺陷（第四例假 PASS）；④promote_version 同样口径不一致+静默放过，统一为与 check_docs / bump_version 一致的稳健定位+ sys.exit 报错
• v1.16.1（2026-09-03） B38 口径修正：check_docs 的 _项目状态.md 文档清单比对排除「已发布/已定稿」快照，与 bump_version.py::scan_deliverables 生产口径对齐（此前两脚本口径不一致导致永久误报「未收录 PRD_V1.7.0.html…」）
• v1.16.0（2026-09-03） B41 状态机闭合校验：check_docs 新增「stateDiagram 必须有 X --> [*] 终止边、不得有只进不出的悬挂状态」（FAIL）+「中间状态转移须标注触发事件」（WARN）；product-chart-drawing.md 新增「状态图闭合规范」（有起点必有终点/无悬挂状态/触发事件分外部人工与内部超时兜底/不同业务模式起点不同则拆图），prd.md 功能逻辑段加引用
• v1.15.6（2026-09-03） pool_status.py register 改用 prepend_row（表头后插入）替代 append_row（表尾追加），与需求池台账倒序语义自洽——新登记需求编号最大、应落最顶而非沉底