116 lines
6.6 KiB
Markdown
116 lines
6.6 KiB
Markdown
# 技能包闸门待修清单（2026-10-08 22:4x）
|
||
|
||
> 用途：`product-planning` 技能包 `check_naming.py` 现存 **12 条 FAIL** 的逐条现场。
|
||
> ⚠️ 这些 FAIL **不是** 2026-10-08 22:4x 提交 `46bee95`（B 方案补落）引入的 —— 那次改动提交前后各跑一次闸门，**零新增 FAIL**；本包第八轮收口时闸门是 `2060 ／ 0 ／ 27`。
|
||
|
||
## 复跑命令
|
||
|
||
```
|
||
cd E:/ProgramData/.workbuddy/skills/product-planning
|
||
E:/ProgramData/.workbuddy/binaries/python/versions/3.13.12/python.exe scripts/check_naming.py --root . --ws "E:/ProgramData/AIProject/contentm_agent"
|
||
```
|
||
|
||
- 现状：`小计：通过 2048 ｜ 失败 12 ｜ 提示 27`
|
||
- ⚠️ `--ws` **必带**（不带则找不到含 `docs/pm` 的那一层，会整包 FAIL）
|
||
- 期望修完回到：失败 0
|
||
|
||
---
|
||
|
||
## 一、四段表子步列名不一致（1 条）
|
||
|
||
1、**闸门期望**：总入口 `SKILL.md` 的子步列里出现 `3c GPT参考版`
|
||
**现场**：`SKILL.md:22` 子步列写的是 `3a 视觉规范 / 3b 原型 / 3c GPT会诊 / 3d 审查打磨`
|
||
**判据位置**：`scripts/check_naming.py` 的 `STAGES` 表（约 235 行起，子步校验在 250–261 行）
|
||
**要定**：子步名到底是「GPT 参考版」还是「GPT 会诊」—— 二选一，改了要同步另一边（改 `STAGES` 表 或 改 `SKILL.md` 正文）
|
||
|
||
---
|
||
|
||
## 二、单一可信源复述（9 条）
|
||
|
||
> 通则：除「权威处」外任何地方出现复述即 FAIL。改法是**把复述改成引用**（引 `§<权威处>` 或文件:小节），⛔ 不是把两处都删掉。
|
||
|
||
### 2.1 ②③边界（权威＝②段 `SKILL.md` 的 §②—③ 交接口）
|
||
|
||
1、`references/stage-delivery/SKILL.md:77` —— `| 归②段（本段⛔ 不许动） | 归本段（②段⛔ 不许写） |`（两侧对照表只许在交接口定义一次）
|
||
|
||
### 2.2 停线规则（权威＝总入口 `SKILL.md`「执行规则」；**全包禁写**，各段一律引用）
|
||
|
||
1、`references/stage-delivery/SKILL.md:340` —— `- 段内子步之间不反问，做完直接进下一个子步。只有三种情况停：信息不足且查不到、破坏性/不可逆动作、用户显式要求。`
|
||
2、`references/stage-discovery/SKILL.md:203` —— 同类句（「只有三种情况停…」）
|
||
3、`references/stage-requirements/SKILL.md:119` —— 写成「**四种**情况停…」（连条数都与权威处不同，属实质性走样）
|
||
|
||
### 2.3 可选档骨架名单（权威＝`references/layouts-tooling.md` 开头）
|
||
|
||
1、`SKILL.md:107` —— `页型分流…：web-prototype 的种子与 8 个骨架全是营销落地页结构（hero / features / stats / quote / CTA）…`
|
||
2、`references/stage-delivery/SKILL.md:167` —— `…那 8 个骨架是落地页 / 营销页向（hero / features / stats / quote / cta / log / pricing）…`
|
||
3、`references/stage-delivery/SKILL.md:207` —— 同名单再现一次
|
||
4、`references/stage-delivery/references/execution-runbook.md:51` —— D2 行里带了同一份名单
|
||
|
||
> ⚠️ 这四处把「名单 ＋ 为什么工具型不能套」一并复述了；两者都只许在 `layouts-tooling.md` 开头写一次。
|
||
|
||
### 2.4 说人话门槛数值（权威＝总入口 `SKILL.md`「执行规则」内容准则条）
|
||
|
||
1、`references/stage-discovery/SKILL.md:214`
|
||
2、`references/stage-discovery/SKILL.md:232`
|
||
3、`references/stage-requirements/SKILL.md:132`
|
||
4、`references/stage-requirements/SKILL.md:152`
|
||
5、`references/stage-requirements/references/create-prd.md:117`
|
||
|
||
> 五处都写了门槛数值 `≥45/50`（另有「夸张意义 / 三段式强凑 / 破折号滥用 / 模糊归因 / 通用乐观结尾」整串复述）。
|
||
|
||
### 2.5 对比度门槛数值（权威＝`execution-runbook.md` 的数值判据段）
|
||
|
||
1、`references/stage-delivery/SKILL.md:194` —— `对比度门槛按 …（正文 4.5:1 / 大字 3:1 / UI 组件 3:1）…`
|
||
|
||
### 2.6 设计契约字段的展开清单（权威＝`execution-runbook.md` §2.1）
|
||
|
||
1、`references/stage-delivery/SKILL.md:152` —— `D0 锚需求：按 …契约模板产出设计契约（十二个字段）——页面职责（谁 + 多久 + 干什么）、主用户、主操作（全页唯一）…`
|
||
|
||
### 2.7 ②—③ 定案用户原话（只许在②段 §②—③ 交接口出现一次）
|
||
|
||
1、`SKILL.md:33`
|
||
2、`references/stage-delivery/SKILL.md:85`
|
||
3、`references/stage-delivery/SKILL.md:87`
|
||
4、`references/stage-delivery/references/execution-runbook.md:94`
|
||
5、`references/stage-discovery/SKILL.md:186`
|
||
|
||
> 五处都是同一句用户原话（「3 是负责设计和交互，页面关系和布局必须在第二步确认清楚…」），措辞还各有微差。
|
||
|
||
### 2.8 1b 两体例的定案用户原话（只许在 1b 方法论里写一次，其余引 §0.4）
|
||
|
||
1、`SKILL.md:39`
|
||
2、`references/stage-discovery/SKILL.md:26`
|
||
3、`references/stage-discovery/SKILL.md:79`
|
||
4、`references/stage-discovery/SKILL.md:225`
|
||
|
||
> 都是同一句（「竞品分析 有独立分析也有汇总分析 都应该要用上…」）。
|
||
|
||
### 2.9 grill-me 的 A / B 节火力点（定义只许在 `grill-me.md`）
|
||
|
||
1、`SKILL.md:41`
|
||
2、`references/stage-discovery/SKILL.md:66` —— `| B 节 | 做成什么样、哪些情况不成立、状态怎么流转 |②段|`
|
||
|
||
---
|
||
|
||
## 三、悬空旧路径（2 条）
|
||
|
||
> 判据：已废目录形态若出现在正文的产出／只读／必读位置即 FAIL。含废止标记（旧/已废/已改名/曾/移进/改为…）的行豁免 —— 下面三行**都没有标记**，要真改。
|
||
|
||
### 3.1 已废的 ①段 `strategy/` 目录（现全部落 `research/1a~1e`）
|
||
|
||
1、`SKILL.md:141` —— `- ②只读 docs/pm/<项目>/research/* 与 docs/pm/<项目>/strategy/*；缺失时标注 【假设】继续，不催促回补`
|
||
|
||
### 3.2 已废的 ②段 `ux/` 目录（状态流转已移进 `prd/2a` 的功能条目）
|
||
|
||
1、`SKILL.md:77` —— `| ② | docs/pm/<项目>/prd/、docs/pm/<项目>/ux/、docs/pm/<项目>/ux/diagrams/ |`
|
||
2、`SKILL.md:142` —— `- ③只读 docs/pm/<项目>/prd/* 与 docs/pm/<项目>/ux/state-machine.md；缺失时同样标 【假设】继续`
|
||
3、`SKILL.md:143` —— `- ④只读 designs/<项目>/*.html，另按需读 docs/pm/<项目>/prd/* 与 docs/pm/<项目>/ux/state-m…`
|
||
|
||
---
|
||
|
||
## 四、协同注意
|
||
|
||
1、这个包当前是**多会话共写**，推进以分钟计。动手前先 `git log -1` 看有没有人刚推过，改完**立刻**提交。
|
||
2、判「我的改动还在不在」用 `git show HEAD:<文件> | grep`，⛔ 不要看 `git show --stat` 的行数（多文件提交的 `--stat` 是合并统计，照它判会误报"内容缺失"）。
|
||
3、改动涉及 `layouts-tooling.md` 时注意：该文件的开头（骨架名单与理由）与 §4.9（导航栏）是**权威处**，修复述时不要把权威处一起删掉。
|