# Prompt — T2 样板 Badge Round 1（plan-only schema 表达层 + 算法描述）

> **角色**：executor
> **范围**：按 [`docs/internal/_plans/t2-sample-badge-plan.md`](../../_plans/t2-sample-badge-plan.md) 定稿的语义/约束/判定层，提议**表达层**——具体 TS 类型、Vue props API、脚本算法描述。
> **本轮不动任何 `src/` / `figma-sync/` / `playground/` 实代码**——只产 3 份 draft `.md`。
>
> ⚠️ **不要 commit / 不要 git add**——所有改动 dirty 工作区累积，等用户审完三份 draft 给定稿指示后进 Round 2 才 commit。
> ⚠️ 完成后 **STOP**，列改动 + 未解决项给用户审。
> ⚠️ 关键决策点（如字段命名、Vue props 名、标记 attr 名）**列给用户拍**，不自决。

---

## 必读输入（按顺序）

1. [`AGENTS.md`](../../../AGENTS.md) — 跨工具入口 + 硬规则 6 条 + 项目约束（Pro plan）
2. [`docs/meta-rules.md`](../../meta-rules.md) — 元规则 + 反模式清单 + 触发器 G 分工边界
3. [`docs/internal/_plans/t2-sample-badge-plan.md`](../_plans/t2-sample-badge-plan.md) — **本轮主输入**，plan owner 已定稿的语义/约束/判定标准
4. [`figma-data/normalized/components-tokenized/badge__4821_1665.json`](../../../figma-data/normalized/components-tokenized/badge__4821_1665.json) — Badge figma 真源（COMPONENT_SET，3 axes，20 variants，无 theme axis）
5. [`figma-data/normalized/ai-manifest.spike.json`](../../../figma-data/normalized/ai-manifest.spike.json) — T4-spike 的早期 schema 参考（不是定稿，仅供风格参考）
6. [`src/canonical/Badge.vue`](../../../src/canonical/Badge.vue) — Badge canonical SoT，了解 prop 形态
7. [`playground/docs/pages/BadgePage.vue`](../../../playground/docs/pages/BadgePage.vue) — 待改造 page，了解现有手写 axes / variant count / Try It / 手写对照三段结构

---

## 任务 1 — 写 draft：generator 输出的 TS 类型 + 字段命名 + 嵌套结构

**产出**：`docs/internal/_plans/t2-sample-generator-output-schema.draft.md`

**目标**：按 plan §1.2 的 6 条必填语义（S1-S6），提议 generator 输出 `<X>.ts` 的具体 TypeScript 类型形态、字段命名、嵌套结构，并附 Badge 完整实例预览。

### draft 必须包含

1. **TS 类型定义**（`export interface DocsFigmaMembers { ... }` 或类似）
   - 把 plan §1.2 的 S1-S6 全部映射为字段
   - S5 theme 是**条件必填**：定义需考虑组件无 theme axis 的情况（用 `theme?: 'dark' | 'light'` 还是 axes 数组里再加 `'theme'` 项？两种思路都行，**列利弊给 plan owner 拍**）
   - 命名风格：参考既有 `figma-data/normalized/ai-manifest.spike.json` + `components-tokenized` JSON 字段命名风格保持一致
2. **Badge 完整实例预览**（生成 `figma-data/normalized/docs-figma-members/badge.ts` 后预期内容，~30-60 行 ts）
   - 实例数据从 `badge__4821_1665.json` 读出真值，不要凭印象填
   - 必须包含 §1.2 全部必填字段
3. **关键决策点列给 plan owner**：
   - 文件名：`badge.ts` / `Badge.ts` / `badge.figma-members.ts`？
   - axes 是 `Record<axisName, values[]>` 还是 `Array<{axis, values}>`？两种结构对下游 grid / β audit 的消费体感不同，列利弊
   - variant 是 `Record<variantId, propTuple>` 还是 `Array<{variantId, propTuple}>`？
   - figmaPage / figmaFileKey 字段需要吗？plan §1.2 S2 列了 figmaPage，但 grid 渲染顶 meta 行只用了 nodeId + variant count——是否仍保留 figmaPage 用于 generator 元数据 / 排查？列建议
   - 命名 prop 值大小写：保持 figma 原值（`'Circle'` PascalCase，与 canonical Badge 的 prop type 一致）
4. **不要做的（边界自检）**：
   - ❌ 不要在 draft 里写 generator 脚本本身（任务 3 范围）
   - ❌ 不要加 plan §1.3 排除项（fills/strokes/text token 引用 / canonical 路径 / Code Connect mapping）
   - ❌ 不要预设 figmaFileKey 是某个具体值——读 JSON 实读

### draft 格式

```markdown
# Draft — generator 输出 schema 表达层

## TS 类型定义
[code block]

## Badge 实例预览
[code block, 真值从 badge__4821_1665.json 读]

## 关键决策点（plan owner 拍板）
- [ ] 决策 1: ...（option A/B + 利弊）
- [ ] 决策 2: ...

## 自检
- 覆盖 plan §1.2 S1-S6: [对应字段表]
- 不含 plan §1.3 排除项: [✓]
```

---

## 任务 2 — 写 draft：FigmaMembersGrid Vue props API + 渲染算法描述

**产出**：`docs/internal/_plans/t2-sample-grid-contract.draft.md`

**目标**：按 plan §2.1-2.5 的数据流/渲染/theme isolation/审计锚点约束，提议 Vue 组件具体 API 形态和渲染算法（伪代码）。

### draft 必须包含

1. **Vue props API**（`defineProps<{ ... }>()` 形态）
   - 输入唯一是 generator 输出（按任务 1 的 TS 类型 import）
   - 必须能注入 site theme（plan §2.3——可能是 prop / inject / 全局 ref，给建议 + 利弊）
   - 必须能注入要渲染的 Vue 组件（如 Badge）——用 `<component :is>` slot 还是 generic 类型？给建议
2. **渲染算法伪代码**：每 variant → cell；如 generator 输出无 S5 theme → 全渲染；有 S5 → filter
3. **审计锚点 attr 命名**（plan §2.4）
   - 提议：`data-figma-source` / `data-figma-member` / `data-from-generator`，**列利弊给 plan owner 拍**
   - 关键：必须能让 γ audit 通过 grep 区分 grid cells vs 手写 demo
4. **Grid 顶部 meta 行**渲染：`source=<Component> · nodeId=<id> · variant count=<N>` —— 字符串模板由 grid 内置还是接 prop 注入？
5. **CSS 草图**（不要完整 style，只列必要的 CSS class 名 + grid layout 思路；δ audit 入口要确保 0 hex/rgb literal）
6. **不要做的（边界自检）**：
   - ❌ 不要写 `.vue` 文件本身（Round 2 范围）
   - ❌ 不要在 grid 里塞 Try It / 手写 demo 渲染逻辑（违反 §2.4 γ audit 锚点）
   - ❌ 不要让 grid 自己跑 figma JSON normalization（违反双层导入）

### draft 格式

```markdown
# Draft — FigmaMembersGrid contract 表达层

## Vue props API
[ts/vue code block]

## 渲染算法（伪代码）
[pseudocode]

## 审计锚点 attr
- 提议: data-...
- 利弊: ...

## 关键决策点（plan owner 拍板）
- [ ] site theme 注入方式（prop / inject / 全局）
- [ ] 待渲染组件注入方式（component prop / generic）
- [ ] data-* attr 名定稿
- [ ] meta 行字符串内置 vs prop

## 自检
- 数据流单输入（仅 generator 输出）: [✓]
- theme isolation 语义符合 plan §2.3: [✓]
- γ audit 锚点设计可机械识别: [✓]
- 不内嵌 normalization 逻辑: [✓]
```

---

## 任务 3 — 写 draft：4 audit 脚本算法 + 输入输出契约

**产出**：`docs/internal/_plans/t2-sample-audit-impl.draft.md`

**目标**：按 plan §3.1-3.5 的统一 verdict schema + 4 个 audit 判定标准，提议每个 audit 的脚本实现算法（**算法描述伪代码，不写 .mjs 本身**）+ 边界 case 处理。

### draft 必须包含

每个 audit 一节，含：

1. **脚本文件名提议**（如 `figma-sync/audit-page-alpha-theme-isolation.mjs` 或 `figma-sync/audit-page.alpha.mjs`，列利弊）
2. **输入读取算法**：
   - α/β/γ：怎么定位 page DOM 区块？SFC template 静态扫（preferred，避免跑 dev server） vs 编译产物 DOM？给建议 + 利弊
   - β：怎么收集 page 上 prop=value 出现集合？（递归扫 SFC template + script setup 中的 ref/computed/literal 值）
   - γ：怎么定位"grid 区块"边界？（约定 `<section data-figma-members>` wrapper？还是按 grid 组件标签 `<FigmaMembersGrid>` 出现位置？）
   - δ：CSS 注释排除算法（regex 还是先 strip comment 再扫？）
3. **判定执行算法**（伪代码）—— 严格按 plan §3.2-3.5 描述的判定算法
4. **verdict 写出算法**：4 个 audit 各跑一次还是合并跑？输出 `docs/internal/t2-sample-audit-report.md` 的 markdown 格式（建议格式：每 audit 一段，含 verdict + evidenceLevel + findings 列表）
5. **边界 case 列举**（每个 audit 至少 3 条）
   - α 例：组件无 theme axis 时 N/A 怎么写
   - β 例：动态拼接 prop 值（`:color="someRef"`）怎么处理（heuristic 标识）
   - γ 例：grid 区块 wrapper 找不到时如何报告
   - δ 例：`<style>` 里 `--token: #abc` 这种 token 定义注释行算不算违反（提议：CSS 变量定义里用 hex 是 token 定义，应允许 → 列规则给 plan owner 拍）
6. **不要做的（边界自检）**：
   - ❌ 不要写 .mjs 脚本本身（Round 2 范围）
   - ❌ 不要扩 audit 数量（4 个就 4 个，不加 ε / ζ）
   - ❌ 不要让 audit 跑 dev server / 编译——本轮限定静态扫

### draft 格式

```markdown
# Draft — T2 sample 4 audit 脚本算法

## 通用：verdict 输出 markdown 格式
[格式建议]

## α theme isolation
- 脚本文件名: figma-sync/audit-page-alpha.mjs
- 输入读取算法: ...
- 判定算法: ...
- verdict 写出: ...
- 边界 case: ...

## β figma axis coverage
[同结构]

## γ runtime fabrication
[同结构]

## δ token purity
[同结构]

## 关键决策点（plan owner 拍板）
- [ ] 静态扫 vs 编译产物
- [ ] grid 区块定位策略
- [ ] CSS 变量定义里 hex 是否豁免
- [ ] 4 audit 单独跑 vs 合并跑
- [ ] 报告 .md 路径定稿（plan §3.6 默认 docs/internal/t2-sample-audit-report.md）

## 自检
- 4 audit 全部沿用 plan §3.1 verdict schema: [✓]
- 每条 audit 都标 evidenceLevel: [✓]
- 静态扫边界 case 已列: [✓]
- 不扩 audit 数量: [✓]
```

---

## 完成报告（写在最后回给用户的 STOP 段里）

按下面格式回报：

```
## Round 1 完成报告

### 产出文件
- docs/internal/_plans/t2-sample-generator-output-schema.draft.md (XXX 行)
- docs/internal/_plans/t2-sample-grid-contract.draft.md (XXX 行)
- docs/internal/_plans/t2-sample-audit-impl.draft.md (XXX 行)

### 关键决策点合并清单（plan owner 拍板）
[把 3 份 draft 里所有"关键决策点"合并列出，编号 D1/D2/...，每条简述 option A/B + 利弊]

### 边界自检
- [ ] 没动 src/ 任何文件
- [ ] 没动 figma-sync/ 任何文件
- [ ] 没动 playground/ 任何文件
- [ ] 没 git add / 没 commit
- [ ] 3 份 draft 都有自检段
- [ ] 关键决策点全部列出，没自决

### 未解决项 / blocker
[如有，列出；无则写"无"]

STOP — 等用户拍板关键决策 + 复审 3 份 draft 后给定稿指示进 Round 2。
```

---

## 反模式 / 边界自检（executor 在每份 draft 末尾必须含）

每份 draft 末尾"## 自检"段必须机械跑：

| 自检项 | 适用 draft |
|---|---|
| 不含 plan §1.3 排除项 | draft 1 |
| 不内嵌 normalization 逻辑 / 不混 runtime demo 渲染 | draft 2 |
| verdict schema 沿用 plan §3.1 / 每 audit 标 evidenceLevel | draft 3 |
| 没自决（关键决策点全留给 plan owner） | 全部 |
| 没扩范围（不动 src/ / 不写脚本 / 不加 audit） | 全部 |

---

## 严守约束总览

- ⚠️ 本轮**只产 3 份 draft .md**——不动 src/ / figma-sync/ / playground/
- ⚠️ **不要 commit / 不要 git add**
- ⚠️ 关键决策点必须**列给用户拍**——不自决（如字段命名、attr 命名、文件名）
- ⚠️ 完成后 **STOP**，按"完成报告"格式回报
- ⚠️ 如发现 plan doc（`t2-sample-badge-plan.md`）有 blocker（会导致失败 / 与仓库规则冲突 / 自相矛盾），先指出再决定是否执行——不扩展替代路线