@xulthekl/team-flow 0.54.0 → 0.55.0

package/skills/design-system/references/showcase-board-b-end.md

@@ -13,48 +13,59 @@
 
 ## 区块与组件（自上而下）
 
+> **组件名不写死（v0.55.0，设计 §8.3）**：下方只给**结构性需求**，具体组件**从当前 `.team-flow/design-system/base.md` 的 `components` 契约表选**——本文件不复制组件清单（避免静态副本 vs 动态契约表漂移）。契约表无但场景必需 → 记 `ds_increment`，或用已有组件组合表达。
+
 ### 1. 顶栏
-组件：**Icon / Avatar / Button**
-- 品牌标识「星驰汽车」+ 主导航（线索管理 / 订单 / 库存）
-- 右侧：通知 Icon + 用户 Avatar（含姓名"王经理"）
+需要：品牌标识「星驰汽车」+ 主导航（线索管理 / 订单 / 库存）+ 用户区（通知入口 + 用户身份，含姓名"王经理"）
+组件来源：从 `.team-flow/design-system/base.md` 契约表选（标识类 / 导航类 / 用户类）
 
 ### 2. 数据概览（3 个 KPI 卡）
-组件：**Card(stat) / Tag**
-- 今日新增线索 **47**（Tag: +12%）
-- 待跟进 **23**（Tag: 需处理）
-- 本月成交 **8**（Tag: 达成 80%）
+需要：三个指标卡（指标名 + 数值 + 变化标记）
+- 今日新增线索 **47**（变化标记：+12%）
+- 待跟进 **23**（状态标记：需处理）
+- 本月成交 **8**（状态标记：达成 80%）
+
+组件来源：从契约表选（卡片/数据展示类 / 标记类）
 
 ### 3. 筛选区
-组件：**FilterBar / Select / Input / Button**
-- 线索状态（Select：全部/新建/跟进中/已成交/已流失）
-- 来源（Select：官网/车展/转介绍）
-- 经销商（Input 搜索：输入经销商名称）
+需要：多条件筛选 + 操作组
+- 线索状态（候选：全部 / 新建 / 跟进中 / 已成交 / 已流失）
+- 来源（候选：官网 / 车展 / 转介绍）
+- 经销商（文本搜索输入）
 - 操作：查询 / 重置
 
+组件来源：从契约表选（表单控件类 / 按钮类）
+
 ### 4. 数据表格（本板核心）
-组件：**Table / Tag / Tooltip / Pagination**
+需要：数据表格 + 状态标记 + 悬浮说明 + 分页
 - 列：客户名 / 意向车型 / 状态 / 销售顾问 / 创建时间 / 操作
 - **5-8 行真实感数据**（中文姓名、"星驰 S7 / 星驰 X5"车型名、合理时间）
-- 状态列用 Tag 变体着色：已成交=success / 跟进中=warning / 新建=info / 已流失=default
-- Tooltip：状态 Tag 悬浮显示说明（如"超过 7 天未跟进"）
+- 状态列按变体着色：已成交=success / 跟进中=warning / 新建=info / 已流失=default
+- 状态标记悬浮显示说明（如"超过 7 天未跟进"）
 - 底部分页：共 128 条 / 每页 20
 
+组件来源：从契约表选（表格类 / 标记类 / 提示类 / 分页类）
+
 ### 5. 表单区（新建订单）
-组件：**Form / Input / Select / Checkbox / Radio / Switch / Button**
-- 客户姓名（Input）
-- 意向车型（Select）
-- 经销商（Select）
-- 配置选项（Checkbox 多选：智驾包 / 家用充电桩 / 延长保修）
-- 交付方式（Radio：到店自提 / 送车上门）
-- 短信通知（Switch，默认开）
+需要：表单 + 多类输入控件（文本 / 下拉 / 多选 / 单选 / 开关）+ 字段级错误态
+- 客户姓名（文本输入）
+- 意向车型（下拉）
+- 经销商（下拉）
+- 配置选项（多选：智驾包 / 家用充电桩 / 延长保修）
+- 交付方式（单选：到店自提 / 送车上门）
+- 短信通知（开关，默认开）
 - **含一个字段级错误态**（如"客户姓名"必填未填 → 错误色 + 文案）
 
+组件来源：从契约表选（表单控件类 / 按钮类）
+
 ### 6. 状态演示
-组件：**EmptyState / Drawer / Modal / Toast**
-- EmptyState：「暂无符合条件的线索」+ 一行解释 + 「清除筛选」行动按钮
-- Drawer：触发按钮「查看详情」→ 侧边面板（线索详情：客户信息 + 跟进记录）
-- Modal：触发按钮「确认成交」→ 确认弹窗（含取消/确认）
-- Toast：触发按钮 → 成功提示（如「订单已创建」）
+需要：空态 / 侧边面板 / 弹窗 / 轻提示（四类各自可触发）
+- 空态：「暂无符合条件的线索」+ 一行解释 + 「清除筛选」行动按钮
+- 侧边面板：触发按钮「查看详情」→ 线索详情（客户信息 + 跟进记录）
+- 弹窗：触发按钮「确认成交」→ 确认弹窗（含取消/确认）
+- 轻提示：触发按钮 → 成功提示（如「订单已创建」）
+
+组件来源：从契约表选（反馈/浮层类）
 
 ## 硬约束（继承 P0 质检）
 
@@ -66,13 +77,16 @@
 
 ## 覆盖清单（验收比对用）
 
-| 组件 | 出现区块 | 组件 | 出现区块 |
-|------|---------|------|---------|
-| Button | 全局 | Table | 数据表格 |
-| Card | 数据概览 | Tooltip | 数据表格 |
-| Tag | 概览/表格 | Pagination | 数据表格 |
-| FilterBar | 筛选区 | Form | 表单区 |
-| Select | 筛选/表单 | Checkbox | 表单区 |
-| Input | 筛选/表单 | Radio | 表单区 |
-| Icon | 顶栏/操作 | Switch | 表单区 |
-| Avatar | 顶栏 | EmptyState / Drawer / Modal / Toast | 状态演示 |
+> **组件清单以当前 `.team-flow/design-system/base.md` 的 `components` 契约表为准**——本文件不复制该清单（避免漂移）。
+> 契约表无但场景必需 → 记 `ds_increment`，或用已有组件组合表达。
+
+| 区块 | 结构性必需 | 组件来源 |
+|------|-----------|---------|
+| 顶栏 | 品牌标识 + 主导航 + 用户区 | 从契约表选（标识/导航/用户类） |
+| 数据概览 | 3 个 KPI 卡 + 变化/状态标记 | 从契约表选（卡片/数据展示 + 标记类） |
+| 筛选区 | 3 个筛选条件 + 查询/重置操作 | 从契约表选（表单控件/按钮类） |
+| 数据表格 | 表格（5-8 行）+ 状态着色 + 悬浮说明 + 分页 | 从契约表选（表格/标记/提示/分页类） |
+| 表单区 | 表单 + 文本/下拉/多选/单选/开关 + 字段错误态 | 从契约表选（表单控件/按钮类） |
+| 状态演示 | 空态 + 侧边面板 + 弹窗 + 轻提示 | 从契约表选（反馈/浮层类） |
+
+**验收口径（v0.55.0，设计 §8.3）**：**结构性区块齐全 + token 合规 + 零白名单外自造**——不再要求静态清单逐项勾选（原清单是契约表的静态副本，快照时点 19 类 vs 现 31 类，必然漂移）。

package/skills/design-system/references/showcase-board-c-end.md

@@ -15,58 +15,76 @@
 
 ## 板 1：官网车型展示（c-end-website.html，桌面视口）
 
+> **组件名不写死（v0.55.0，设计 §8.3）**：各区块只给**结构性需求**，具体组件**从当前 `.team-flow/design-system/base.md` 的 `components` 契约表选**——本文件不复制组件清单（避免静态副本 vs 动态契约表漂移）。契约表无但场景必需 → 记 `ds_increment`，或用已有组件组合表达。
+
 ### 区块 1：Hero
-组件：**Button / Icon**
-- 品牌主张（一句话，如「星驰 S7 ｜ 智能电动，从容出行」）
+需要：品牌主张（一句话）+ 主/次 CTA + 视觉标识
+- 品牌主张（如「星驰 S7 ｜ 智能电动，从容出行」）
 - 主 CTA：「预约试驾」+ 次 CTA：「查看配置」
 
+组件来源：从 `.team-flow/design-system/base.md` 契约表选（标识类 / 按钮类）
+
 ### 区块 2：车型卡片网格（3 列）
-组件：**Card / Tag / Button**
-- 3 个车型卡：星驰 S7（Tag: 新车）/ 星驰 X5（Tag: 热销）/ 星驰 E3（Tag: 限时权益）
+需要：3 个车型卡（名称 + 一句话卖点 + 价格区间 + 卡片级 CTA）+ 状态标记 + 图片占位
+- 3 个车型卡：星驰 S7（标记：新车）/ 星驰 X5（标记：热销）/ 星驰 E3（标记：限时权益）
 - 每卡：车型名 + 一句话卖点 + 价格区间（"¥22.98 万起"）+ 「了解详情」按钮
 - 图片位用 `.ph-img` 占位（零外部依赖：不得链外网图）
 
+组件来源：从契约表选（卡片类 / 标记类 / 按钮类）
+
 ### 区块 3：参数对比
-组件：**Tabs / Table / Tooltip**
-- Tabs：续航 / 性能 / 智能座舱
-- Table：参数对比表（车型 × 参数，3 行 × 4 列）
-- Tooltip：专业术语悬浮说明（如"CLTC 续航"）
+需要：分组切换 + 对比表格 + 术语悬浮说明
+- 分组：续航 / 性能 / 智能座舱
+- 对比表：车型 × 参数（3 行 × 4 列）
+- 专业术语悬浮说明（如"CLTC 续航"）
+
+组件来源：从契约表选（切换/标签类 / 表格类 / 提示类）
 
 ### 区块 4：预约试驾表单
-组件：**Form / Input / Select / Radio / Button**
-- 姓名（Input）、手机号（Input）、意向车型（Select）、经销商（Select）
-- 试驾时间（Radio：本周内 / 周末 / 随时）
+需要：表单（文本 / 下拉 / 单选）+ 提交按钮 + 提交中态
+- 姓名、手机号（文本输入）；意向车型、经销商（下拉）
+- 试驾时间（单选：本周内 / 周末 / 随时）
 - 提交按钮 + 提交中态示例
 
-**官网覆盖**：Button / Icon / Card / Tag / Tabs / Table / Tooltip / Form / Input / Select / Radio
+组件来源：从契约表选（表单控件类 / 按钮类）
+
+**官网覆盖**：4 个区块（Hero / 车型卡片网格 / 参数对比 / 预约试驾表单）的全部结构性需求——**不含**静态组件名，组件以契约表为准（见文末「覆盖清单」）。
 
 ---
 
 ## 板 2：车主 APP（c-end-app.html，移动视口 390px）
 
 ### 区块 1：我的车辆
-组件：**Card / Tag / Avatar / Icon / Button**
-- 车辆卡：车型名「星驰 S7」+ 车牌（如"沪 A·D12345"）+ 状态 Tag（已连接）
-- 快捷操作：解锁 / 空调 / 充电（Icon + Button）
-- 右上角用户 Avatar
+需要：车辆卡（车型名 + 车牌 + 连接状态标记）+ 快捷操作组 + 用户身份入口
+- 车辆卡：车型名「星驰 S7」+ 车牌（如"沪 A·D12345"）+ 状态标记（已连接）
+- 快捷操作：解锁 / 空调 / 充电（图标 + 操作入口）
+- 右上角用户身份
+
+组件来源：从契约表选（卡片类 / 标记类 / 标识类 / 按钮类）
 
 ### 区块 2：服务记录
-组件：**Card / Tag / EmptyState**
-- 记录列表（2-3 条）：保养 / 维修 / 充电订单 + 状态 Tag + 时间
-- 空态示例：EmptyState「暂无服务记录」+ 「预约保养」行动
+需要：记录列表（2-3 条：保养 / 维修 / 充电订单 + 状态标记 + 时间）+ 空态
+- 记录列表：保养 / 维修 / 充电订单 + 状态标记 + 时间
+- 空态示例：「暂无服务记录」+ 「预约保养」行动
+
+组件来源：从契约表选（列表/卡片类 / 标记类 / 空态类）
 
 ### 区块 3：设置项
-组件：**Switch / Button**
-- 消息通知（Switch 开）、车辆定位共享（Switch 关）
+需要：两个开关设置项 + 一个次要操作
+- 消息通知（开关开）、车辆定位共享（开关关）
 - 「退出登录」按钮（次要样式）
 
+组件来源：从契约表选（开关类 / 按钮类）
+
 ### 区块 4：交互演示
-组件：**Modal / Tooltip / Toast**
-- Modal：触发「预约保养」→ 确认弹窗
-- Tooltip：设置项说明
-- Toast：操作反馈（如「已解锁」）
+需要：弹窗 + 悬浮说明 + 轻提示
+- 弹窗：触发「预约保养」→ 确认弹窗
+- 悬浮说明：设置项说明
+- 轻提示：操作反馈（如「已解锁」）
+
+组件来源：从契约表选（浮层类 / 提示类）
 
-**APP 覆盖**：Card / Tag / Avatar / Icon / Button / EmptyState / Switch / Modal / Tooltip / Toast
+**APP 覆盖**：4 个区块（我的车辆 / 服务记录 / 设置项 / 交互演示）的全部结构性需求——**不含**静态组件名，组件以契约表为准（见文末「覆盖清单」）。
 
 ---
 
@@ -80,13 +98,18 @@
 
 ## 覆盖清单（验收比对用）
 
-| 组件 | 板 | 组件 | 板 |
-|------|----|------|----|
-| Button | 官网+APP | Tooltip | 官网+APP |
-| Icon | 官网+APP | Form | 官网 |
-| Card | 官网+APP | Input | 官网 |
-| Tag | 官网+APP | Select | 官网 |
-| Tabs | 官网 | Radio | 官网 |
-| Table | 官网 | Avatar | APP |
-| EmptyState | APP | Switch | APP |
-| Modal / Toast | APP | （本板 16 类；Checkbox / Pagination / FilterBar / Drawer 不在本板，由 `showcase-board-b-end.md` 覆盖——**两板合计覆盖 20 类基线全量**） | |
+> **组件清单以当前 `.team-flow/design-system/base.md` 的 `components` 契约表为准**——本文件不复制该清单（避免漂移）。
+> 契约表无但场景必需 → 记 `ds_increment`，或用已有组件组合表达。
+
+| 板 | 区块 | 结构性必需 | 组件来源 |
+|----|------|-----------|---------|
+| 官网 | Hero | 品牌主张 + 主/次 CTA | 从契约表选（标识/按钮类） |
+| 官网 | 车型卡片网格 | 3 卡（名称+卖点+价格+CTA）+ 标记 + 图片占位 | 从契约表选（卡片/标记/按钮类） |
+| 官网 | 参数对比 | 分组切换 + 对比表 + 术语提示 | 从契约表选（切换/表格/提示类） |
+| 官网 | 预约试驾表单 | 文本/下拉/单选 + 提交（含提交中态） | 从契约表选（表单控件/按钮类） |
+| APP | 我的车辆 | 车辆卡（车型+车牌+状态标记）+ 快捷操作 + 用户身份 | 从契约表选（卡片/标记/标识/按钮类） |
+| APP | 服务记录 | 记录列表（2-3 条）+ 状态标记 + 空态 | 从契约表选（列表/标记/空态类） |
+| APP | 设置项 | 两个开关项 + 次要操作 | 从契约表选（开关/按钮类） |
+| APP | 交互演示 | 弹窗 + 悬浮说明 + 轻提示 | 从契约表选（浮层/提示类） |
+
+**验收口径（v0.55.0，设计 §8.3）**：**结构性区块齐全 + token 合规 + 零白名单外自造**——不再要求静态清单逐项勾选；原「本板 16 类 / 两板合计 20 类」是契约表的静态副本（现 31 类），该断言已删除。

package/skills/design-system/references/variant-schema.md

@@ -29,10 +29,13 @@
 | `components` | **组件契约表（全量真源，v0.54.0）**：`\| 组件 \| 类型 \| variants \| sizes \| states \| 用途 \| 禁止 \|`；类型 ∈ 交互/轻量/豁免（决定 guard 的 states 下限：交互 ≥3 / 轻量 ≥2 / 豁免跳过；**交互/轻量的 variants 亦必填**，guard 会判违规）；≥15 类 PASS / 10-14 类 WARN / <10 类 FAIL 标签 | components |
 | `principles` | **设计原则 ≥3 条（v0.54.0）**：如"一致性优先于局部创意 / 清晰优于装饰 / 可访问性默认开启" | principles |
 | `governance` | **治理声明（v0.54.0）**：`contract: v1\|legacy`（guard 降级判定依据）+ version + 负责人 + 弃用策略 + changelog 指向 | governance |
+| `来源与裁决记录`（v0.55.0） | **导入类创建条件必填**（`create-from-docs` / `create-from-code` / 转换器产物 / 旧文件迁移）：原始来源 + 导入方式 + 「为什么不是直接采纳」+ 主色裁决 + 待清理项。**审计层 advisory，不进 `REQUIRED_SECTIONS`**（存量系统不受影响）；待清理项写**段内**，不为 `pending.md` 的单写者规则开例外；导入的既有资产**只留在项目内**，不打包进插件分发包 | —（advisory，无 token） |
 
 > **a11y 声明（v0.54.0）**：base.md 文档头部（标题下）增加一行 `> a11y: WCAG 2.2 AA（对比度 4.5:1 / 大字 3:1 / 焦点可见 / 键盘可达）`——从 prototype craft 层**提级**到设计系统层（guard 六层审计的 L0-可访问性依据）。
 >
 > **`contract` 标记语义**：`v1` = 新体系（六层审计不达标标 FAIL 标签）；`legacy` 或无标记 = 存量（降级 WARN）。升级动作 = 重跑 iterate 补契约表时由 architect 置为 `v1`。guard `--strict` 可让 legacy 按 v1 标签输出（供自查，不改变 exit code）。
+>
+> **新建默认 `v1`；来源 ∈ {`create-from-docs` / `create-from-code` / 转换器产物 / 旧文件迁移}（导入类）时写 `legacy`**（v0.55.0，设计 §8.2.1 D-18）。**为什么**：导入的既有资产天然是存量系统（组件数 / 段完整性未经校准），恒打 `v1` 会让整条模板库 / 导入路径**一落盘即 blocked**（死循环）；用户显式裁决"已达标"后经 iterate 升 `v1`。判别机制是**来源**而非产物质量——转换器产物由脚本确定性写 `legacy`，architect 按来源判定。
 
 > base 不含排版/间距/布局——这些随端变化，归变体。base 的 A1+A2+B-slot 必须完整可过 guard。
 
@@ -42,13 +45,30 @@
 |----|------|-----------|
 | `typography` | font-display/body/mono 引用 + type scale（`--text-xs~4xl`，1.25 比例）+ weights + line-height（按 density） | A1-structure |
 | `spacing` | `--space-1~12` 阶梯（基于 density 基准：compact 12 / balanced 16 / spacious 20） | A2-derived |
-| `layout` | 栅格 12 列 / 断点 sm/md/lg / 容器 max-width（B 端宽容器、C 端窄容器） | A1-structure |
+| `layout` | **三部分（v0.55.0，设计 §8.2.2）**：① 栅格 12 列 / 断点 sm/md/lg / 容器 max-width（B 端宽容器、C 端窄容器）——**原有，不变** ② **`### 容器骨架` 块**（表格：容器 / 类名 / 关键 CSS 声明）③ **`### 页面范式` 子块**（`**页面范式来源**：引用内置 \| 项目自有 \| 同 <端>` 结构化声明 + 页面类型表） | A1-structure |
 | `components` | **端特有覆盖说明（v0.54.0 改）**：只写该端对 base.md 契约表的差异（如 C 端 Button 用 pill 圆角）并**引用**契约表；**不再重复定义组件清单**（全量真源在 base.md——消除双份维护） | components（差异） |
 | `motion` | duration（`--motion-fast/base`，150–300ms）+ `--ease-standard` | A2-derived |
 
 > B 端 vs C 端差异示例：B 端 compact + 14px + 宽表格容器；C 端 spacious + 17px + 窄卡片容器。
 > 两端共享 base 的 color/brand/voice，绝不各自重定义品牌色。
 
+> **`layout` 段三部分与三态语义（v0.55.0，设计 §8.2.2 / FB-3）**：`layout` 是**必填段**（`REQUIRED_SECTIONS` 内），页面范式**扩展它而不新增段**——这样单文件模式（模板库 / 转换器产物：主体已含全 9 段即不合并变体）也能带上页面范式。
+>
+> | 态 | 写法 | L3（声明层） | L4b（内容层） |
+> |----|------|-------------|--------------|
+> | **`引用内置`**（绿地默认） | 只写 `**页面范式来源**：引用内置` | ✅ | **免检**（14 骨架由内置 `layouts.md` 提供） |
+> | **`项目自有`**（棕地） | 声明 + **容器骨架块** + 页面类型表 | ✅ | 表行数 **≥3** |
+> | **`同 <端>`** | 只写 `**页面范式来源**：同 b-end`（指向另一端） | ✅ | ✅（完整性由被指向端保证） |
+> | 无声明（存量） | — | ⚠️ 显式提示（**不 FAIL**） | ⚠️（与 L3 同向） |
+>
+> **容器骨架块的条件写**：`引用内置` 时**可省**——内置 `template.html` 的全部 15 个类都是通用/营销向的（`hero` / `topnav` / `pagefoot` / `cta`），**C 端页面够用**；但 **B 端后台项目建议给**——内置骨架**无 `app-header` / `app-sider` / `app-main` 这类容器类**，不写则 builder 每页手写整套后台骨架 CSS（单次派发无法复现）。`项目自有` 时**必须写**（棕地项目页面规范进 builder 的唯一通道）。物料与判据详见 `creation-modes.md` §5。
+> **占位符须与值域同名**：写 `<引用内置 | 项目自有 | 同 <端>>`。**解析规则不对称**（`guard` / `ds-parse` 实现）：
+> - `引用内置` 是**锚定匹配**（`/^引用内置$/`）——带任何后缀（如 `引用内置（14 骨架）`）即**解析不出** → 恒判 ⚠️；
+> - `项目自有` / `同` 是**前缀匹配**（`/^项目自有/`、`/^同/`）——带后缀的变体会被**静默当成合法值**并进入内容层判据（写 `项目自有规范` 会按 `项目自有` 走"表行数 ≥3"校验），**看似通过实则取值非规范**。
+>
+> 故**照抄值域字面量**，不要自造变体（空白会被剥除：`引用 内置` 等价于 `引用内置`）。
+> **写者与默认取值**：Step 3 生成端变体 + 转换器产物**默认写 `引用内置`**；导入类（`create-from-docs` / `create-from-code` / 旧文件迁移）**必须写 `项目自有`** + 容器骨架块（若也写 `引用内置` → L4b 免检、builder 仍读内置营销向 `layouts.md`，棕地场景的问题原样复发）；iterate 可补写（第四类增量，见 `creation-flow.md`）。
+
 ---
 
 ## 继承规则（Inheritance）

package/skills/prototype/SKILL.md

@@ -51,6 +51,7 @@ description: 本地 HTML 原型设计与维护 skill（零外部依赖、可离
 - 设计系统渲染：读取项目 `.team-flow/design-system/<variant>.md` + `base.md`（base 品牌层 + 端特有层合并；9 段 schema + 5 方向调色板 + aliases 别名层 + extensions，v0.18.0 token 四层模型），渲染 token 到 `assets/design-tokens.css`。
 - **种子模板 + 骨架库（v0.18.0）**：builder 从 `references/template.html`（种子）+ `references/layouts.md`（14 个 section 骨架 + 类清单契约）组合，不从零写 CSS。
 - **组件白名单（v0.54.0）**：builder 从 `.team-flow/design-system/primer.md` 提取可用组件白名单（Step 0 gate 校验 digest；primer 缺失/过期按 `governance.contract` 字段 blocked(v1)/WARN(legacy)）；白名单外需求记 `ds_increment`，不自造。
+- **页面范式（v0.55.0）**：primer 的「页面范式」段与组件白名单**并列**为 builder 的输入——声明 `项目自有` 时按其页面类型表 + 「容器骨架」块组织页面（骨架类在页面 `<style>` 内定义），内置 `references/layouts.md` 降为**回退默认**。**为什么**：不改消费端则项目既有页面规范进不了原型生成流程（设计 §8.2.2）。
 - **Showcase 模式（v0.54.0，对外契约）**：`prototype-builder` 支持 `mode: showcase`（供 design-system skill 单次派发产出展示板）——gate 豁免 `confirmed_plan`/`prd_path`，产出 flat 单文件，最小交付契约见 `references/builder-methodology.md`。
 - **工艺规则层（v0.18.0）**：`references/checklist.md`（P0/P1/P2）+ `references/craft/`（anti-ai-slop / state-coverage / typography-hierarchy / accessibility-baseline / laws-of-ux），品牌无关，B 端导向。
 - **原型类型方法论（v0.24.0）**：`references/interactive-prototype.md`（交互原型：零依赖状态管理+表单验证+多步导航）+ `references/wireframe.md`（线框图：低保真快速探索+3-5 差异化方案+并排对比），按需加载。
@@ -72,6 +73,8 @@ prototype/
 首次创建 → 引用 → 增量更新（变更履历）
 ```
 - **首次创建**：项目无设计系统时，①环境探查发现缺失 → 主代理调用 `/team-flow:design-system` skill（独立入口，用户主导交互创建），产出 `.team-flow/design-system/`（base.md + 变体 + preview.html）。
+  > **起点选择（v0.55.0）**：design-system 的 Step 0 有 **7 条起点**（移植 `clone --from --to` / 模板库 / `--profile antd` / `create-from-docs` / `create-from-code` / 从零创建 / iterate）。**本处只传达事实、不预选起点**——一是"缺设计系统"，二是 scout 简报里与起点相关的**资产事实**（如"已有符合规范的原型代码"）；采用哪条取决于用户的资产状况（是否有可移植的同类项目设计系统、是否有既有规范文档），而 prototype 无从判断，预选会让其余 6 条不可见（**能力存在但用户不知道 = 能力不存在**）。传达清单见 `references/orchestration-flow.md` §①b。
+  > **目录已存在但不完整**（env-scout 判 `needs_design_system` 的另一种情形）→ 走 design-system 的 **iterate** 模式（MERGE 不 OVERWRITE），**不走** Step 0。
 - **引用**：prototype-builder 绘制时强制读 `.team-flow/design-system/<variant>.md`（+ base.md 合并 token）渲染，禁止内联样式漂移。
 - **增量更新**：prototype-sync 回写时若涉及新组件/token/anti-pattern，调用 `/team-flow:design-system`（iterate 模式）合并进 `.team-flow/design-system/` 并记**变更履历**。
 - **迁移兼容**：检测旧 `prototype/design-system.md` → 提示迁移到 `.team-flow/design-system/base.md`（一次性）。
@@ -85,6 +88,7 @@ prototype/
 ## 配置驱动（插件通用 + 项目注入）
 - 项目 `team-flow.config.json` 注入（插件层扩展字段）：`prototype.designSystem`（`.team-flow/design-system/<variant>.md` 路径）、`prototype.designSystemBase`（`.team-flow/design-system/base.md`）、`prototype.entry`（默认 `prototype/index.html`）。
 - 插件层用 `tf runtime config --get <key>` 自读；插件保持通用，不固化任何公司/产品风格。
+- **配置漂移检查（v0.55.0）**：`node ${CLAUDE_PLUGIN_ROOT}/scripts/check-project-config.mjs [项目根]` —— 检查上述 key 的指向是否存在、config `version` 是否与插件一致。现场实测三类漂移（version 落后 / 指向不存在的文件 / 零消费者键）**全部静默**，只在用到时失效。
 
 ## 膨胀防控
 - `components/` 必须复用 `.team-flow/design-system/` 契约表组件，**禁止页面内联样式漂移**。

package/skills/prototype/references/builder-methodology.md

@@ -21,7 +21,7 @@
 
 Before writing anything, verify:
 
-- `design_system_path` exists and is readable → if missing/unreadable, return `status: blocked` (blocker: 设计系统缺失，需先派 design-system-architect).
+- `design_system_path` exists and is readable → if missing/unreadable, return `status: blocked` (blocker: 设计系统缺失，需先调用 `/team-flow:design-system` skill 创建——v0.19.0 起 architect 只是该 skill 的内部执行引擎，不再由原型侧直接派发).
 - **primer.md 检查（v0.54.0 新增——组件白名单来源）**：
   1. **primer 存在且可读** → 提取 `available_components` 白名单（Step 1.5/Step 2 只用这些组件）。
      - **digest 校验**：`node ${CLAUDE_PLUGIN_ROOT}/scripts/gen-primer.mjs <base.md 路径> --check`
@@ -52,8 +52,13 @@ Do NOT proceed past a failed gate.
 **不从零写 CSS——从种子模板 + 骨架库组合。**
 
 1. 读 `references/template.html`（至少到 `</style>` 结尾）+ 读 `references/layouts.md`（14 个 section 骨架 + 类清单契约 + 页面类型节奏表）。
-2. **先选 section 列表再写文案**：按页面类型查节奏表（管理后台列表页 / 表单页 / 仪表盘 / Landing / 文档索引），为每个页面选定 section 组合。选定后**用一句话向主代理报出 section 列表**（写入 `outstanding_questions`，question = "页面 X 计划用 section 组合：hero → log → stats，此刻改向便宜，而不是 200 行 HTML 之后"，default_assumption = 按此组合继续）。
-3. 从 `layouts.md` 粘贴对应骨架到 `<main id="content">`，替换 `[REPLACE]` 槽为 PRD 中的真实、具体文案。
+   - **页面范式以 primer 的「页面范式」段为准（v0.55.0，设计 §8.2.2）**：该段是设计系统 `layout` 段的**忠实派生物**。声明 `项目自有` 时按其**页面类型表**组织页面，骨架**类名 + 关键 CSS 声明从同段的「容器骨架」块取**，按类清单契约（`layouts.md:27`）在页面 `<style>` 内定义；内置 `layouts.md` 降为**回退默认**（仅在 `引用内置` 或未声明时使用）。
+     - **为什么**：内置 `layouts.md` 是营销向骨架（页面框架只有 `topnav`/`pagefoot`），**不含**项目自有容器类（`header-bar`/`sidebar-container`/`main-content`）——只写设计系统而不改消费端，项目既有页面规范就进不了原型生成流程，段写了也无人消费（静态副本 vs 动态契约表漂移）。
+2. **先选 section 列表再写文案**：按页面类型查节奏表（管理后台列表页 / 表单页 / 仪表盘 / Landing / 文档索引），为每个页面选定 section 组合。
+   - **节奏表来源随页面范式来源而定（v0.55.0）**：`引用内置` 或未声明 → 用内置 `layouts.md` 的两张「页面类型节奏表」；**`项目自有` → 以 primer 的「页面范式」段的页面类型表为准**（内置节奏表降为**回退默认**）。
+     **为什么**：与第 1 步同理——项目自有的页面类型（如"工单详情页""对账页"）本就不在内置的 5 类里，按内置查会选错 section 组合；这是消费链的最后一环，漏了则前面所有改造失效。
+   - 选定后**用一句话向主代理报出 section 列表**（写入 `outstanding_questions`，question = "页面 X 计划用 section 组合：hero → log → stats，此刻改向便宜，而不是 200 行 HTML 之后"，default_assumption = 按此组合继续）。
+3. 从 `layouts.md` 粘贴对应骨架到 `<main id="content">`，替换 `[REPLACE]` 槽为 PRD 中的真实、具体文案（**页面范式为 `项目自有` 时**：§1 已改以 primer 的「页面范式」段为准，骨架组合按该段的页面类型表取，本节只适用于 `引用内置`）。
    - **"槽位空着说明选错了布局，换一个，不许编文案。"**
    - 类清单契约：只用 template.html `<style>` 中已定义的类；够不到的类先在页面 `<style>` 定义，绝不凭空发明全局类。
 4. 纪律约束（来自 layouts.md 各骨架）：stats ≤3 个且不编造指标；quote 每页 ≤1 个；accent 每屏 ≤2 处；section 节奏交替（禁止连续同类型）。
@@ -125,11 +130,13 @@ P1 逐项自查（节奏交替 / 标题 ≤14 词 / CTA 说明动作 / hover 态
 - 写入派发方指定的 scratch 路径（`/tmp/ds-draft-<slug>/showcase/`）；**不移正、不落正式路径**（由 design-system skill 在 Step 6 复制）
 
 ### 最小交付契约（返回 `done` 的硬前置）
-1. brief 的全部区块已渲染（对照 brief 的"覆盖清单"逐项勾选）
+1. brief 的全部区块已渲染（**验收口径 = 结构性区块齐全 + token 合规 + 零白名单外自造**；brief 的「覆盖清单」已引用化，**不再**逐项勾选静态清单）
 2. 无填充文案（grep `lorem|功能[一二三]|示例文本|TODO` = 0）
 3. **P0 grep 通过**（裸 hex / 靛蓝黑名单 / emoji / 填充文案——机械检查，不依赖 PRD）
 4. `<style>` 内 token 全部来自 primer 草案（无自造 token）
 
+> **为什么 #1 改口径（v0.55.0，设计 §8.3）**：brief 原覆盖清单是 primer `components` 契约表的**静态副本**（快照时点 b-end 19 类 / c-end 16 类），契约表演进后副本必然漂移（现 31 类）→ 判据从"清单逐项勾选"改为可判定的三要素，新增组件自动纳入验收，无需改 brief。
+
 > showcase **不跑 prototype-reviewer**（其 D1-D4 依赖 PRD）——P0 grep 是它的最低验证环节。
 
 ### Hard Gate 适配

package/skills/prototype/references/layouts.md

@@ -27,6 +27,9 @@
 **硬规则**：如果你想用一个不在这张表里的 class，**先在 `<style>` 里把它定义出来**。
 绝不允许凭空发明一个没有 CSS 支撑的全局类。宁可定义，不可漂移。
 
+> **项目自有页面范式时（v0.55.0，设计 §8.2.2）**：其骨架类名（如 `header-bar` / `sidebar-container` / `main-content`）**不在本表内**——按**同一条硬规则**在页面 `<style>` 里定义出来；物料（类名 + 关键 CSS 声明）取自 primer 的「容器骨架」块（设计系统 `layout` 段声明 `页面范式来源：项目自有` 时）。规则本身不变：先定义，再使用。
+> **为什么**：本表是**内置骨架**的静态清单，项目自有规范天然在其外——若为此开例外（允许直接用表外类），就退化成"没有 CSS 支撑的全局类"漂移。
+
 ---
 
 ## 1. hero（居中）
@@ -377,6 +380,10 @@
 
 ## 页面类型节奏表（B 端）
 
+> **适用范围（v0.55.0）**：本表是**内置回退默认**。设计系统的 `layout` 段声明
+> `**页面范式来源**：项目自有` 时，**以 primer 的「页面范式」段的页面类型表为准**，
+> 本表不适用（项目自有页面类型——如"工单详情页""对账页"——不在下表 5 类内）。
+
 | 页面类型 | section 节奏（自上而下） |
 |----------|--------------------------|
 | 管理后台列表页 | `hero-center` → `log`/列表（`ds-table`） → `stats` 汇总 |
@@ -387,6 +394,9 @@
 
 ## 页面类型节奏表（C 端，v0.24.0 新增）
 
+> **适用范围（v0.55.0）**：同 B 端表——**内置回退默认**。声明 `项目自有` 时以 primer 的
+> 「页面范式」段页面类型表为准。
+
 | 页面类型 | section 节奏（自上而下） |
 |----------|--------------------------|
 | SaaS 落地页 | `hero-xl` → `marketing-features` → `social-proof` → `pricing-c` → `faq` → `cta-c` |

package/skills/prototype/references/orchestration-flow.md

@@ -33,6 +33,14 @@
 
 环境简报显示设计系统缺失/不完整时：
 1. 主代理调用 `/team-flow:design-system` skill（独立入口，用户主导交互创建）。
+   > **传达范围（v0.55.0）**：只传 **① 环境简报里与"起点"相关的资产事实**，**不预选起点**——
+   > design-system 的 Step 0 会**无条件展示全部 7 条**（移植 / 模板库 / `--profile antd` / 文档导入 / 代码逆向 / 从零 / iterate）。
+   > 本侧无从判断用户手上有什么资产，**预选会让其余 6 条不可见**（能力存在但用户不知道 = 能力不存在）。
+   >
+   > 可传达的资产事实（由 scout 简报得出，**仅作提示、不代替用户选择**）：
+   > 简报含"已有符合规范的原型代码"→ 提示 `create-from-code` 可用；
+   > 需求方提到"有既有 UI 规范文档/规范树"→ 提示 `create-from-docs` 可用；
+   > 需求方提到"公司另一个后台项目已建过设计系统"→ 提示 clone 可用。
 2. design-system skill 内部执行：需求收集（≤5 个预填推荐问题）→ 确定性 token 派生 → 草稿生成（base.md + 变体）→ 预览生成（preview.html）→ 用户评审确认 → 落盘 `.team-flow/design-system/` + guard 校验。
 3. 创建完成后回 ① 补齐环境简报。
 

package/skills/workflow-bootstrap/SKILL.md

@@ -218,16 +218,26 @@ Step 2: 确定性提取（兜底）
 
 **不做的事**：不写 SOP 流程（由 skill 负责）、不写变更级状态机（由 workflow skill 负责）、不列可自动发现的文件清单。
 
-### B4.6: Design System 起点选择（advisory，v0.54.0 新增）
+### B4.6: Design System 起点选择（advisory，v0.54.0 新增；v0.55.0 扩为六项）
 
 > 编号说明：B4.5 已被占用（CLAUDE.md 初始化），本步骤为 B4.6。
 
-`.team-flow/design-system/` 不存在时，AskUserQuestion 呈现起点四选一（**不阻断**，延续 advisory 约定）：
+`.team-flow/design-system/` 不存在时，AskUserQuestion 呈现**起点六选一 + 跳过**（**不阻断**，延续 advisory 约定）：
 
-> 「检测到项目尚无设计系统。选择起点方式：[从模板库选择 | 逆向建库 | 从零创建 | 跳过]」
+> 「检测到项目尚无设计系统。选择起点方式：[移植已有设计系统 | 从模板库选择 | 通用起点（Ant Design 规格） | 从文档规范导入 | 从代码逆向建库 | 从零创建 | 跳过]」
 
-- **模板库**：调 `/team-flow:design-system`（起点=模板库）——由该 skill 呈现 `${CLAUDE_PLUGIN_ROOT}/templates/design-systems/registry.json`（8 个参考设计系统），选定后执行导入并**续跑 Step 5 评审 → Step 6 落盘**（含 primer 生成 + guard 校验）。**本步骤不直接调转换器**：转换器只产 base.md，缺少 primer 会让后续 prototype Step 0 对 `contract: v1` 系统直接 blocked（v0.54.0 P4 实证死路）
-- **逆向建库 / 从零创建**：调 `/team-flow:design-system`（create-from-code / 交互式 6 步）
+**六项全部展示，每项带适用场景一句话**——能力存在但用户不知道 = 能力不存在（v0.55.0 D-23）；按**资产就绪度降序**排列（从最厚的已有资产到最薄的空白起点）：
+
+| # | 起点 | 适用场景（对用户的一句话） | 委托给 design-system 时的参数 |
+|---|------|---------------------------|------------------------------|
+| 1 | **移植已有设计系统** | "你们公司**另一个后台项目**已经建过设计系统 → 直接复制过来改" | `clone --from <源路径>` |
+| 2 | **从模板库选择** | "想参考某个成熟产品（Linear / Stripe / Vercel…）的视觉风格" | 起点=模板库（呈现 `${CLAUDE_PLUGIN_ROOT}/templates/design-systems/registry.json` 的 8 个参考） |
+| 3 | **通用起点（Ant Design 规格）** | "全新项目、**没有任何规范**，先要一套像 Ant Design 的合规底座" | `--profile antd`（零 LLM） |
+| 4 | **从文档规范导入** | "手里有**一套写好的 UI 规范**（Markdown / 规范树）" | `create-from-docs` |
+| 5 | **从代码逆向建库** | "项目里**已有符合规范的原型代码**" | `create-from-code` |
+| 6 | **从零创建** | "什么都没有，边聊边定" | 交互式 6 步 |
+
+- **本步骤不直接调转换器**：六项**全部委托 `/team-flow:design-system`**，且必须**续跑 Step 5 评审 → Step 6 落盘**（含 primer 生成 + guard 校验）——转换器只产 base.md，缺少 primer 会让后续 prototype Step 0 对 `contract: v1` 系统直接 blocked（v0.54.0 P4 实证死路）
 - **跳过** → 继续 B5；**已存在** → 跳过
 
 ### B5: Path Decision（路径判断，v0.42.0 重构：降级路径设计）

package/src/parsing/requirement-blocks.ts

@@ -12,11 +12,40 @@ export interface RequirementsSectionParts {
   after: string;
 }
 
+/**
+ * 行内强调剥离 + 去反引号（v0.55.0 §8.4.3 横展；与 `scripts/lib/md-normalize.mjs` 同约定）。
+ *
+ * **根因**：解析层对最常见的 Markdown 强调语法脆弱且**失败静默**——手写
+ * `### **Requirement**: X` 或 `` ### `Requirement`: X `` 会让需求块整块漏解析，
+ * 而这条路径在 `tf sync`（→ `spec-merge` → 本模块）上是**活路径**，且
+ * `guard/checks/specs-merged` 会在 delta spec 存在时硬阻断 `executing → closing`。
+ * JS 侧已修（`md-normalize.mjs`），本函数是 TS 侧的对应实现（D-16「全修」）。
+ *
+ * **只剥双符号对**（`**` / `__`）：单 `*` 可能是列表符、单 `_` 可能是 snake_case
+ * 标识符——剥它们是"改语义"而非"容格式"。
+ */
+export function stripInlineEmphasis(text: string): string {
+  return text.replace(/`/g, '').replace(/\*\*(.+?)\*\*/g, '$1').replace(/__(.+?)__/g, '$1');
+}
+
+/** 归一化需求名：剥行内强调/反引号（名称本身被包裹时）+ trim。 */
 export function normalizeRequirementName(name: string): string {
-  return name.trim();
+  return stripInlineEmphasis(name).trim();
 }
 
-export const REQUIREMENT_HEADER_REGEX = /^###\s*Requirement:\s*(.+)\s*$/i;
+/**
+ * 需求块标题：`### Requirement: <name>`。
+ *
+ * v0.55.0 容忍：`Requirement` 键被加粗/反引号包裹（`**Requirement**` /
+ * `` `Requirement` `` / `` **`Requirement`** ``——**两种符号可任意交错、任意顺序**，
+ * 故用字符类而非固定序列）、全角冒号、冒号前后空格。
+ * 名称内的标记由 {@link normalizeRequirementName} 归一。
+ *
+ * 注：单 `*` 包裹（`*Requirement*`）也在容错内——键名两侧的星号无论一个两个
+ * 都是强调写法，剥它不改变语义。**需求名内部**的单符号才是语义边界，
+ * 由 `stripInlineEmphasis` 只剥成对双符号来保证。
+ */
+export const REQUIREMENT_HEADER_REGEX = /^###\s*[`*]{0,4}\s*Requirement\s*[`*]{0,4}\s*[:：]\s*(.+?)\s*$/i;
 
 function normalizeLineEndings(content: string): string {
   return content.replace(/\r\n?/g, '\n');
@@ -183,7 +212,7 @@ function parseRemovedNames(sectionBody: string): string[] {
       names.push(normalizeRequirementName(m[1]));
       continue;
     }
-    const bullet = line.match(/^\s*-\s*`?###\s*Requirement:\s*(.+?)`?\s*$/);
+    const bullet = line.match(/^\s*-\s*`?###\s*[`*]{0,4}\s*Requirement\s*[`*]{0,4}\s*[:：]\s*(.+?)\s*$/i);
     if (bullet) {
       names.push(normalizeRequirementName(bullet[1]));
     }
@@ -200,10 +229,10 @@ function parseRenamedPairs(
   let current: { from?: string; to?: string } = {};
   for (const line of lines) {
     const fromMatch = line.match(
-      /^\s*-?\s*FROM:\s*`?###\s*Requirement:\s*(.+?)`?\s*$/
+      /^\s*-?\s*FROM\s*[:：]\s*`?###\s*[`*]{0,4}\s*Requirement\s*[`*]{0,4}\s*[:：]\s*(.+?)\s*$/i
     );
     const toMatch = line.match(
-      /^\s*-?\s*TO:\s*`?###\s*Requirement:\s*(.+?)`?\s*$/
+      /^\s*-?\s*TO\s*[:：]\s*`?###\s*[`*]{0,4}\s*Requirement\s*[`*]{0,4}\s*[:：]\s*(.+?)\s*$/i
     );
     if (fromMatch) {
       current.from = normalizeRequirementName(fromMatch[1]);

package/src/validation/validator.ts

@@ -16,7 +16,14 @@ import {
   extractRequirementsSection,
 } from '../parsing/requirement-blocks.js';
 
-const REQUIREMENT_HEADER_REGEX = /^###\s*Requirement:\s*(.+)\s*$/i;
+// v0.55.0 §8.4.3（D-16「全修」横展）：本文件原有第二份 `REQUIREMENT_HEADER_REGEX`
+// 定义（`/^###\s*Requirement:\s*(.+)\s*$/i`）——**定义后从未使用**（本文件的需求头
+// 解析全部经 `parseDeltaSpec` / `extractRequirementsSection` 走解析层），属"同一契约
+// 两处定义"的维护陷阱：改解析层正则时无人知道这里还有一份。已删除，需求头正则的
+// 唯一真相源是 `parsing/requirement-blocks.ts`。
+//
+// ⚠️ 不要再在本文件内定义需求头/场景头以外格式约定的正则——场景头（下方）是
+// 本文件唯一自有的格式契约，其余一律从解析层引入。
 const SCENARIO_HEADER_REGEX = /^####\s+Scenario:/i;
 
 function normalizeLineEndings(content: string): string {