术语更名第一步:执行会话/任务会话 ⇒ 项目会话(口径块 + 触发词表)+ 落地 9 份"说人话"新稿
一、用户令(逐字) 1. `1、A 方案` 2. `把会话技能中 执行会话(协作会话)改为 项目会话 # 用法改为输入 使用项目会话完成目标:XXXXX` 二、A 方案:只落"说人话"新稿 —— ⚠️ 实测**只能落 9 份**,7 份必须合并 · 16 份新稿(`contentm_agent` 那条目标产出)逐份比对现文件:**9 份差异只在措辞**(0~2 行)⇒ ✅ 已落地, 逐份 md5 与稿子一致;**原件已备份**到 `待清理/技能包-说人话落地前备份-20261008/`。 · 🔴 **7 份现文件含稿子里没有的内容**(最多的少 106 行!)—— 且 `stage-delivery/SKILL.md`、 `execution-runbook.md`、`SKILL.md` 是**今天 15:28/15:29 刚被别的会话改过** ⇒ 直接覆盖会**丢掉今天的新内容**。 ⇒ 按「改技能包前先看别人在途改动、⛔ 别硬覆盖」的规定**没动这 7 份**,留待合并(见回复待拍板项)。 三、术语更名(先落低风险那一半,让新用法今天可用) · `SKILL.md` 第一屏加**术语更名口径块**:**项目会话(现行)= 任务会话(旧称)= 执行会话/协作会话(更旧称)**, 新文字一律用「项目会话」;⛔ 三个词的旧正文**按本块读**(同 10-02 那次的做法)。 · 三类会话表里那一行改为「**项目会话**(旧称任务会话/执行会话)」。 · 第 0 步触发句加 **`使用项目会话完成目标:XXXXX`**(用户口径的现行写法)。 · `skill-load-guard.py` 的词表**加**项目会话族(`使用项目会话`/`项目会话完成`/`项目会话`/`创建项目会话`/`派项目会话`), ⛔ **旧词一个不删**(用户与新会话都可能用旧词,收窄词表=把已授权的触发句漏掉,本项目栽过)。 复核:`使用项目会话完成目标:XXXXX` 命中 `['使用项目会话','项目会话完成']` ✓;`用执行会话完成 X` 仍命中 ✓。 · 🔴 **机器前缀 `[执行]` 暂不变** —— 它是角色解析与看板的键(`parse_session_name`/`board.py::_role_of_title`/ 在跑的排期名),属影响面变更,**等用户拍板**。 · ⚠️ **全量更名尚未做完**:实测 **416 处 / 22 个文件**(`collabd.py` 71 / `selftest.py` 63 / `SKILL.md` 50 / `board.html` 46 / `pitfalls.md` 36 / `board.py` 33 …)⇒ 按机制自己的三类规矩(注释文档 / `@case` 标题 / 看板文案)逐步收尾。 四、验收 selftest.py rc=0 PASS 106 / FAIL 0;manifest 76 份、语法失败 0。
This commit is contained in:
1 parent
a7bf194ee7
commit
1ca0a637a6
4198 files changed
+807267
-1791
No files matched your search
+30
-36
@@ -19,7 +19,7 @@ description: 产品规划总入口(唯一入口),四段式调度:① 产
|
||||
|---|---|---|---|---|
|
||||
| **① 产品需求** | 要做的东西凭什么成立:什么问题、为谁、为什么值得做 | 1a 需求文档(grill 压测)/ 1b 竞品分析 / 1c 用户画像 / 1d 产品策略 / 1e 使用场景 | `stage-discovery` | `docs/pm/<项目>/research/*`。其中 1b 交两种体例:`research/1b-竞品分析.md`(汇总对比)+ `research/1b-独立分析/<竞品名>.md`(独立分析) |
|
||||
| **② 产品功能** | 要做哪些功能、什么不做、长成什么骨架 | 2a 产品功能 / 2b 界面布局 | `stage-requirements` | `docs/pm/<项目>/prd/2a-产品功能.md` 与 `prd/2b-界面布局.md`(两份) |
|
||||
| **③ 界面交互** | 长什么样、怎么操作 | 3a 视觉规范 / 3b 原型 / 3c GPT会诊 / 3d 审查打磨 | `stage-delivery` | `docs/pm/<项目>/DESIGN.md`、`designs/<项目>/*.html`、`designs/<项目>/3c-GPT会诊.md` |
|
||||
| **③ 界面交互** | 长什么样、怎么操作 | 3a 视觉规范 / 3b 原型 / 3c GPT参考版 / 3d 审查打磨 | `stage-delivery` | `docs/pm/<项目>/DESIGN.md`、`designs/<项目>/*.html`、`designs/<项目>/3c-GPT参考版.md` |
|
||||
| **④ 原型说明文档** | 每个状态有哪些场景、每步做什么、边界在哪、坏了怎样 | 4a 场景盘点 / 4b 说明区 / 4c 演示引导 | `stage-proto-doc` | 同一份原型 HTML 里的说明区与演示引导 |
|
||||
|
||||
四段只通过落盘文件耦合。段间交接口如下,这是唯一的契约,越界即失效:
|
||||
@@ -30,20 +30,17 @@ description: 产品规划总入口(唯一入口),四段式调度:① 产
|
||||
| ② → ③ | ② | 功能清单(每条带优先级 + 状态流转)、界面布局(有哪几页 / 每页几个板块 / 板块怎么排 / 跨页关系)、每页主操作、信息承载分档(主屏常驻 / 可点入) | 视觉归③段。骨架必须给全,骨架不给全,③段就一版一个样 |
|
||||
| ③ → ④ | ③ | 已跑通的单文件原型 HTML | 说明区与演示引导归④段 |
|
||||
|
||||
> 口径:②段钉骨架,③段做皮肉。用户原话:「3 是负责设计和交互,页面关系和布局必须在第二步确认清楚,不然第三步没有方向 一会一个样子」。
|
||||
> 所以②段要给全:有哪几页、每页几个板块、板块怎么排、跨页关系。③段不许增删移动板块,缺板块回②段改。
|
||||
> 配色 / 字体 / 间距 / 组件样式 / 动效,以及每个板块的视觉与交互实现,都归③段。
|
||||
> 口径:②段钉骨架,③段做皮肉。两侧逐行对照与用户原话只在②段 `references/stage-requirements/SKILL.md` 的 §②—③ 交接口 定义一次 —— 本入口不复述。要点两条:②段要给全「归②段」列;③段不许增删移动板块,缺板块回②段改。
|
||||
|
||||
> ②→③ 是这条流水线最容易被搞坏的一环。旧病灶是②段说「必须能读到」,③段读成「必须常驻主屏」,于是五类信息全铺一屏,成了信息墙。分档表就是为这句歧义生的:它把「读到」明确成「一次点击内可达」。
|
||||
> 骨架给定后,③段不会退化成照抄。骨架是灰块(有哪些块、什么顺序),③段给的是视觉与交互实现(怎么排版好看、点哪有什么反馈、空态怎么呈现、响应式怎么变)。两件事各管一维。
|
||||
> ②→③ 最容易搞坏。旧病灶:②段说「必须能读到」,③段读成「必须常驻主屏」,五类信息就全铺一屏成了信息墙。分档表把「读到」明确成「一次点击内可达」,防的就是这句歧义。骨架是灰块(有哪些块、什么顺序),③段给的是视觉与交互实现(排版、点哪有什么反馈、空态、响应式)。两件事各管一维,③段不会退化成照抄。
|
||||
|
||||
> 四段各占一个词,互不共用(2026-10-02 定):产品 / 功能 / 界面 / 说明。改段名前先对照这张表;两个段名里出现同一个词,边界一定在漂。历史上「调研与方案 / 需求与结构」里都有「需求」,③段名里的「交付」是三段共有的属性,都属名实不符,已改。
|
||||
> 四段各占一个词,互不共用(2026-10-02 定):产品 / 功能 / 界面 / 说明。改段名前先对照这张表;两个段名里出现同一个词,边界一定在漂。旧名「调研与方案 / 需求与结构」都含「需求」,③段旧名里的「交付」是三段共有的属性,都属名实不符,已改。
|
||||
> ①叫「产品需求」不叫「需求调研」:该段产出 `research/1a-需求文档.md`、`1b-竞品分析.md`、`1c-用户画像.md`,也产出 `1d-产品策略.md`、`1e-使用场景.md`,「调研」二字盖不住后半截。
|
||||
> ⭐ 1b 是①段唯一交两种体例的子步(2026-10-07 用户定案「竞品分析 有独立分析也有汇总分析 都应该要用上」):独立分析体 `research/1b-独立分析/<竞品名>.md`(竞品池每一个一份),汇总对比体 `research/1b-竞品分析.md`(恒一份)。职责边界见 `references/stage-discovery/references/competitor-analysis.md` §0.4。
|
||||
> ⭐ 1b 是①段唯一交两种体例的子步:独立分析体 `research/1b-独立分析/<竞品名>.md`(竞品池每一个一份),汇总对比体 `research/1b-竞品分析.md`(恒一份)。职责边界与定案原话见 `references/stage-discovery/references/competitor-analysis.md` §0.4。
|
||||
|
||||
⭐⭐ `grill-me` 全场只有①段一份(2026-10-06 用户定案):用户原话「grill 也应该拿到第一步了,第二部就是细化功能」。①段那份按 A / B 两节提问:A 节问「要做什么、为谁、边界在哪」,B 节问「做成什么样、哪些情况不成立、状态怎么流转」,B 节结论落进 `research/1a-需求文档.md`。
|
||||
⭐ `grill-me` 全场只有①段一份(2026-10-06 用户定案):①段那份按 A / B 两节提问,火力点划分、节次归属与定案原话见 `references/stage-discovery/references/grill-me.md` —— ⛔ 本入口不复述。B 节结论落进 `research/1a-需求文档.md`。
|
||||
|
||||
⭐⭐ ②段产出两份(2026-10-06 收窄,2026-10-07 定为两份):用户原话「不需要 就用使用场景,其余6分都不需要了」「2 产品功能 和 界面布局不就是两个文档嘛」。`prd/2a-产品功能.md`(功能清单:做哪些 / 不做哪些 / 每条带优先级 + 状态流转)与 `prd/2b-界面布局.md`(页面关系 + 页面内板块布局)。
|
||||
⭐ ②段产出两份(2026-10-06 收窄,2026-10-07 定为两份):`prd/2a-产品功能.md`(功能清单:做哪些 / 不做哪些 / 每条带优先级 + 状态流转)与 `prd/2b-界面布局.md`(页面关系 + 页面内板块布局)。定案原话与理由见 `references/stage-requirements/SKILL.md` 开头。
|
||||
|
||||
(交接口反转前的口径、②段收窄前的产出清单与去向 → `references/_留痕/③段与总入口-旧口径.md`)
|
||||
|
||||
@@ -77,8 +74,8 @@ description: 产品规划总入口(唯一入口),四段式调度:① 产
|
||||
| 段 | 路径 |
|
||||
|---|---|
|
||||
| ① 产品需求 | `docs/pm/<项目>/research/` |
|
||||
| ② | `docs/pm/<项目>/prd/`、`docs/pm/<项目>/ux/`、`docs/pm/<项目>/ux/diagrams/` |
|
||||
| ③ | `docs/pm/<项目>/DESIGN.md`、`designs/<项目>/*.html`、`designs/<项目>/3c-GPT会诊.md` |
|
||||
| ② | `docs/pm/<项目>/prd/` |
|
||||
| ③ | `docs/pm/<项目>/DESIGN.md`、`designs/<项目>/*.html`、`designs/<项目>/3c-GPT参考版.md` |
|
||||
| ④ | 写进原型 HTML 自身(`designs/<项目>/*.html`),不额外落 md |
|
||||
|
||||
### DESIGN.md 为什么在项目目录、不在仓库根
|
||||
@@ -94,38 +91,35 @@ description: 产品规划总入口(唯一入口),四段式调度:① 产
|
||||
| 要什么 | 用谁 | 别用 |
|
||||
|---|---|---|
|
||||
| 页面设计全链(规范 → 原型 → 审查) | ③段 `stage-delivery` 自己的 D0→D5 流水线 | 另找风格库,或自己手搓一套 token 与门禁 |
|
||||
| 评审用的可点原型 / 生产级前端页面 | ③段 3b(按 D2 构建,单文件 HTML 交付)。先判页型:营销页取 `open-design` 技能的 `design-templates/web-prototype/`,工具型页面取③段 `references/layouts-tooling.md` | 不判页型就套 `web-prototype` 种子——那是营销落地页骨架,会把后台做成营销页 |
|
||||
| 设计规范文件 | ③段 3a 生成 `DESIGN.md`(令牌表由 `open-design` 技能选定套的 `tokens.css` 产出,加该项目②段的界面需求) | 凭空编一套 token |
|
||||
| 评审用的可点原型 / 生产级前端页面 | ③段 3b(按 D2 构建,单文件 HTML 交付)。先判页型:营销页取③段 §供给·版式骨架 的可选档,工具型页面取其默认档 | 不判页型就套可选档种子——那是营销落地页骨架,会把后台做成营销页 |
|
||||
| 设计规范文件 | ③段 3a 生成 `DESIGN.md`(令牌表取自③段选定套,见③段 §供给·定调与令牌;再加该项目②段的界面需求) | 凭空编一套 token |
|
||||
| 架构图 / 流程图 / 时序图 | `diagram-design` | 手写 Mermaid |
|
||||
| 状态迁移的守卫、副作用、并发 | `state-machine` | 指望 diagram-design 覆盖这些 |
|
||||
| 审美方向 / 风格定调 | `open-design` 技能里选一套(读候选套 `DESIGN.md` 第 1 章,按页面类型挑) | 「米白+衬线+陶土色」这类默认审美,或凭感觉编 |
|
||||
| 多方向比选 / 独立评审打分 | `oil-ui-pro` 技能(方向探索 `design-direction.md`,对比页 `style-explorer.md`,评审协议 `visual-review.md`) | 拿它的评分循环替代本段 Gate-1/2/3 |
|
||||
| 审美方向 / 风格定调 | ③段 §供给·定调与令牌 的默认档里选一套(可选档亦见该处),读候选套按页面类型挑。⛔ 每次只选一套 | 「米白+衬线+陶土色」这类默认审美,或凭感觉编 |
|
||||
| 多方向比选 / 独立评审打分 | ③段 §供给·多方向比选 与 §供给·独立评审协议 | 拿它的评分循环替代本段 Gate-1/2/3 |
|
||||
|
||||
③段的页面设计供给来自两个独立技能(2026-10-05 定),都装在 `.workbuddy/skills/` 技能仓库,都可脱离本段单独使用:
|
||||
③段的页面设计供给 —— 默认主线、定调与令牌、版式骨架、工艺数值判据、独立评审协议、多方向比选,共六档;各档的默认来源 / 可选来源 / 路径只在③段 `references/stage-delivery/SKILL.md` 的 §供给 定义一次,本入口不复述,要改供给只改那一块(2026-10-08 起)。`oil-ui-pro` 是界面设计方法论:五步流程(探索方向 → 建结构 → 取实证 → 独立评审打分 → 验证交付),加风格对比页与截图工具;它自带联网版本检查与自动更新,是用户明确要求全量搬入的例外项(既有纪律是「依赖外部服务一律不收」),已记录在案,不扩散。
|
||||
|
||||
- `open-design`(判据供给库):`design-systems/`(153 套,定调只从这里选)、`craft/`(13 份工艺判据:状态穷举 / 字阶 / 配色 / 动效 / 反 AI 味 / 无障碍)、`design-templates/web-prototype/`(版式骨架种子,营销页向)。
|
||||
- `oil-ui-pro`(界面设计方法论):五步流程(探索方向 → 建结构 → 取实证 → 独立评审打分 → 验证交付),加风格对比页与截图工具。它自带联网版本检查与自动更新,是用户明确要求全量搬入的例外项(既有纪律是「依赖外部服务一律不收」),已记录在案,不扩散。
|
||||
默认走 `oil-ui-pro` 主线,不与可选档缝成一条流水线:可选档只在 §供给 里列,选了才作补强(多一路定调候选、多一套工艺数值判据),不选也不影响开工。
|
||||
|
||||
两者平行同层级,不缝成一条流水线:多数页面走 `open-design` 主线;需要「先拉开方向让用户挑」或「独立评审打分」时,取 `oil-ui-pro`。
|
||||
四样东西供给件里都没有对应,由 `stage-delivery` 自己扛:设计契约十二字段、结构骨架、交互清单、工具型版式库。
|
||||
|
||||
四样东西两个技能都没有对应,由 `stage-delivery` 自己扛:设计契约十二字段、结构骨架、交互清单、工具型版式库。
|
||||
页型分流(2026-10-05 新增):③段 §供给·版式骨架 的可选档是营销落地页向,工具型页面照它做会长出「标题上下各一行小字」的三段式(骨架名单与理由见③段 `references/stage-delivery/references/layouts-tooling.md` 开头)。本项目实测踩过这个坑,结构判据全绿也拦不住。所以③段 D0 必须先判页型,工具型页面版式一律走 §供给·版式骨架 的默认档。
|
||||
|
||||
页型分流(2026-10-05 新增):`web-prototype` 的种子与 8 个骨架全是营销落地页结构(hero / features / stats / quote / CTA),自带 `.eyebrow`(眉标)与 `.lead`(副标题)。工具型页面(后台 / 控制台 / 列表 / 详情)照它做会长出「标题上下各一行小字」的三段式——本项目实测踩过的坑,结构判据全绿也拦不住。所以③段 D0 必须先判页型,工具型页面零 `.eyebrow`、零 `.lead`、零 `.hero`,版式走③段 `references/layouts-tooling.md`。
|
||||
只读一处来源:同一条判据若在默认档与可选档各有一份且口径不同,以本项目追加条为准 —— ⛔ 但追加条不得放宽基础层(`oil-ui-pro` 是基础层、其余是叠加层,分层规则见③段 §供给),并在 runbook §3.4 显式标注「本项目追加」。
|
||||
|
||||
只读一处来源:同一条判据若在 `stage-delivery` 与 `craft` 各有一份且口径不同,以本项目追加条为准,并在 runbook §3.4 显式标注「本项目追加」。
|
||||
|
||||
DESIGN.md 说明:`@google/design.md` 提供 `lint` / `diff` / `export` / `spec` 四个子命令,目前是 alpha(v0.4.0)。非 TTY 的管道里可能不回显输出,需在真实终端里确认。本机实测该命令完全不可用,不要拿它当校验关卡;改由 D3 收口与 D5 终检按真实像素人工复测对比度(判据见 `open-design` 技能的 `craft/color.md`)。原两把门禁脚本(静态文案检查 / 渲染机检)已随旧主干从磁盘移除,当前没有机器复现,结论只能记「人工判定」,不得写成「脚本已通过」。
|
||||
DESIGN.md 说明:`@google/design.md` 提供 `lint` / `diff` / `export` / `spec` 四个子命令,目前是 alpha(v0.4.0)。非 TTY 的管道里可能不回显输出,需在真实终端里确认。本机实测该命令完全不可用,不要拿它当校验关卡;改由 D3 收口与 D5 终检按真实像素人工复测对比度(判据见③段 §供给·工艺数值判据 里配色那一份)。原两把门禁脚本(静态文案检查 / 渲染机检)已随旧主干从磁盘移除,当前没有机器复现,结论只能记「人工判定」,不得写成「脚本已通过」。
|
||||
|
||||
## 可调用工具(自然语言触发)
|
||||
|
||||
> 两个随段携带的独立工具,装在③段 `references/stage-delivery/assets/` 下。按用户说法直接触发,产物落项目目录。它们不是新的段,只是叫得动的工具。
|
||||
> 两个随段携带的独立工具,装在③段 `references/stage-delivery/assets/` 下,按用户说法直接触发,产物落项目目录。它们都挂在③段下,不单独成段。
|
||||
|
||||
| 用户说 | 触发工具 | 做什么 | 产物 |
|
||||
|---|---|---|---|
|
||||
| 「分析 XXX 视频」「把这个视频抽帧」「拆一下这条视频的画面」 | `stage-delivery/assets/video-capture/` | 取视频(本地文件 / 直链 URL)+ 抽帧(双因素 + 首尾 + 补帧) | 关键帧 `frames/` + `frame_times.json`(供①竞品分析、③视觉参考) |
|
||||
| 「获取 XXX 网站的设计风格」「抓这个网站的风格/组件/配色」 | `stage-delivery/assets/design-capture/` | 抓网页设计系统(色彩 / 排版 / 组件),生成样式模板 | 一套 `design-system-<名>/`(与 `design-system-tiaoyue` 同构,可直接被③段 D1 选用) |
|
||||
|
||||
两者都独立可单跑:`video-capture` 只依赖 `ffmpeg`;`design-capture` 只依赖本机 Chrome(CDP)+ `vendor/` 里搬运的抽取脚本,不需要 open-design daemon 在场。用法与边界见各自 `SKILL.md`,来源与署名见各自 `ATTRIBUTION.md`。
|
||||
两者都独立可单跑:`video-capture` 只依赖 `ffmpeg`;`design-capture` 只依赖本机 Chrome(CDP)+ `vendor/` 里搬运的抽取脚本,不需要任何外部服务在场。用法与边界见各自 `SKILL.md`,来源与署名见各自 `ATTRIBUTION.md`。
|
||||
|
||||
触发时机:①②段拆竞品视频用 `video-capture`;③段要新建样式或拆参考站用 `design-capture`。
|
||||
|
||||
@@ -144,9 +138,9 @@ DESIGN.md 说明:`@google/design.md` 提供 `lint` / `diff` / `export` / `spec
|
||||
|
||||
「只调一段」成立的原因:四段之间只通过落盘文件耦合,没有隐式状态。
|
||||
|
||||
- ②只读 `docs/pm/<项目>/research/*` 与 `docs/pm/<项目>/strategy/*`;缺失时标注 `【假设】`继续,不催促回补①
|
||||
- ③只读 `docs/pm/<项目>/prd/*` 与 `docs/pm/<项目>/ux/state-machine.md`;缺失时同样标 `【假设】`继续
|
||||
- ④只读 `designs/<项目>/*.html`,另按需读 `docs/pm/<项目>/prd/*` 与 `docs/pm/<项目>/ux/state-machine.md` 校准术语;缺失时标 `【假设】`继续
|
||||
- ②只读 `docs/pm/<项目>/research/*`;缺失时标注 `【假设】`继续,不催促回补①
|
||||
- ③只读 `docs/pm/<项目>/prd/*`;缺失时同样标 `【假设】`继续
|
||||
- ④只读 `designs/<项目>/*.html`,另按需读 `docs/pm/<项目>/prd/*` 校准术语;缺失时标 `【假设】`继续
|
||||
|
||||
## 执行规则
|
||||
|
||||
@@ -218,7 +212,7 @@ DESIGN.md 说明:`@google/design.md` 提供 `lint` / `diff` / `export` / `spec
|
||||
- 把④的说明区写进产品功能范围,或让③顺手把说明文档一起写了(该调 `stage-proto-doc` 就调)
|
||||
- 手写 Mermaid 代替 diagram-design,手写 token 表代替 DESIGN.md
|
||||
- 绕过四段自己手搓,或重写它们的内容(该调 `stage-*` 就调)
|
||||
- 把两个页面设计技能(`open-design` / `oil-ui-pro`)的内部路径按本 skill 目录去拼,或改它们的正文(它们是技能仓库里的供给技能,改动只写 `stage-delivery` 自己的 `SKILL.md` / `references/`;两个技能平行同层级,不缝成一条流水线,也不把 `oil-ui-pro` 的评分循环当成本段 Gate 的替代)
|
||||
- 把供给件的内部路径按本 skill 目录去拼,或改它们的正文 —— 供给件指③段自带的 `oil-ui-pro`,以及 §供给 各档落在 `assets/` 下的件(它们是随③段携带的供给件,改动只写 `stage-delivery` 自己的 `SKILL.md` / `references/`;默认档与可选档平行,不缝成一条流水线,也不把 `oil-ui-pro` 的评分循环当成本段 Gate 的替代)
|
||||
- 猜 `<项目>`:定不出来还硬写,把产物落到别的项目目录下
|
||||
- 把 `DESIGN.md` 写到仓库根:多项目会互相覆盖
|
||||
- 段间停下来问「要不要继续」:全流程(自动处理)模式下直接进下一段,只在段末输出报告
|
||||
@@ -236,17 +230,17 @@ python scripts/check_naming.py --ws <工作区>
|
||||
|
||||
它查四段段名与子步名在「总入口 ↔ 各段 `SKILL.md` ↔ 各段 `references/`」之间有没有漂,包括 H1 与子步表是否一致、总入口子步列有没有漏项、runbook 必读表有没有引用已移除的资产、两份副本是否一致。纯静态比对,不需要渲染,不需要外部依赖。
|
||||
|
||||
为什么必须有它:实测当天就漏过两次,而且当时没有任何门禁会报错。
|
||||
为什么必须有它:实测当天漏过两次,当时没有任何门禁会报错。
|
||||
|
||||
第一次(2026-10-02):段名从「需求调研 / 功能规划 / 界面与交付」改成「产品需求 / 产品功能 / 界面交互」时,`SKILL.md` 改了,但 `references/stage-discovery/references/grill-me.md` 的 H1 仍写「需求澄清(grill-me · 调研段)」;`references/stage-requirements/SKILL.md` 子步表写「2b 功能流转」而正文 H2 写「## 2b 状态机」;总入口④段子步列只写「4a 说明区 / 演示引导」漏了 4b / 4c。三处都只能靠回读发现。
|
||||
第一次(2026-10-02):改段名时 `SKILL.md` 改了,但 `references/stage-discovery/references/grill-me.md` 的 H1 仍写「需求澄清(grill-me · 调研段)」;`references/stage-requirements/SKILL.md` 子步表写「2b 功能流转」而正文 H2 写「## 2b 状态机」;总入口④段子步列只写「4a 说明区 / 演示引导」漏了 4b / 4c。三处都只能靠回读发现。
|
||||
|
||||
第二次(2026-10-06):②段收窄为「只细化功能」(7 份产出变 1 份)后,各段 `SKILL.md` 都改了,但总入口的三处仍写着旧结构——①四段表的②段子步列仍是「2a 功能定义与压测 / 2b 功能流转 / 2c 功能图示」;②四段表的①段子步列「1c 产品定位与商业设计」未随段内改名(段内已改称「产品定位与场景」);③正文仍写「①与②各跑一次 `grill-me`」并指向两份同名文档,实际全场只有①段一份。闸门当场报 6 个 FAIL,根因是「改了承载段、忘了总入口」。
|
||||
第二次(2026-10-06):②段收窄为「只细化功能」(7 份产出变 1 份)后,各段 `SKILL.md` 都改了,但总入口的三处仍写着旧结构——四段表的②段子步列仍是「2a 功能定义与压测 / 2b 功能流转 / 2c 功能图示」,四段表的①段子步列「1c 产品定位与商业设计」未随段内改名(段内已改称「产品定位与场景」),正文仍写「①与②各跑一次 `grill-me`」并指向两份同名文档,实际全场只有①段一份。闸门当场报 6 个 FAIL,根因是「改了承载段、忘了总入口」。
|
||||
|
||||
由此立一条硬纪律,与「换供给不能只改承载段」同型:凡改子步结构 / 段内产出清单 / 段间交接口,必须连带改总入口 `product-planning/SKILL.md` 的「四段结构」表与「交接口」表,不改就是半改状态。
|
||||
|
||||
改了段名 / 子步名 / 判据供给源之后必须跑一次,并把结果记进当日 memory——与「不渲染不算完」同型:改完不校验,下次读契约的人拿到的是错的配方。
|
||||
改了段名 / 子步名 / 判据供给源之后必须跑一次,并把结果记进当日 memory。改完不校验,下次读契约的人拿到的是错的配方。
|
||||
|
||||
本脚本只查文本一致性(H1 ↔ 子步表 ↔ 总入口 ↔ 副本),查不出「判据口径是否自相矛盾」。例如「②段到底该不该给页面结构」这种反转,闸门一个字都报不出来(两版写法都合法)。口径类改动要靠人工回读,且必须把反转理由与用户原话写进文档留痕。
|
||||
本脚本只查文本一致性(H1 ↔ 子步表 ↔ 总入口 ↔ 副本),查不出「判据口径是否自相矛盾」。例如「②段到底该不该给页面结构」这种反转,闸门一个字都报不出来。口径类改动要靠人工回读,且必须把反转理由与用户原话写进文档留痕。
|
||||
|
||||
脚本输出里的 `[提示]` 项(旧名出现)不计入失败,但要人工看一眼是不是落在「废止理由块」里——落在里面是正当留痕,散落在正文里就是真残留。
|
||||
|
||||
|
||||
Reference in new issue
Block a user