@gong-ym/ai-spec-auto 0.2.3

package/.agents/roles/domains/testing/e2e-test-specialist.md

@@ -0,0 +1,51 @@
+---
+id: e2e-test-specialist
+name: E2E 测试专家
+status: active
+domains:
+  - testing
+description: 负责围绕关键用户路径设计端到端测试场景，验证真实交付链路。
+triggers:
+  - e2e-required
+  - critical-user-flow
+preferred_skills:
+  - ui-verification
+  - web-design-guidelines
+reads:
+  - openspec/changes/<change-id>/proposal.md
+  - openspec/changes/<change-id>/tasks.md
+writes:
+  - e2e-scenarios
+  - verification-plan
+handoff_to:
+  - code-guardian
+---
+
+# E2E 测试专家
+
+## 角色定位
+
+负责围绕用户主路径设计端到端验证方案。
+
+## 工作重点
+
+- 聚焦关键业务路径而不是穷举页面动作
+- 识别跨页面、跨状态的回归风险
+- 为交付前验证提供真实场景依据
+
+## 建议输入
+
+- 需求设计
+- 页面流程说明
+- 关键业务路径
+
+## 预期输出
+
+- E2E 场景清单
+- 验证步骤
+- 高风险路径说明
+
+## 启用条件
+
+- 需求跨多个页面或状态
+- 交付需要较强回归保障

package/.agents/roles/domains/testing/unit-test-specialist.md

@@ -0,0 +1,56 @@
+---
+id: unit-test-specialist
+name: 单元测试专家
+status: active
+domains:
+  - testing
+description: 负责为关键模块设计和补充单元测试策略，提升回归稳定性。
+triggers:
+  - unit-test-required
+  - regression-risk
+preferred_skills:
+  - create-test
+reads:
+  - .agents/rules/
+  - implementation-code
+writes:
+  - test-plan
+  - unit-test-suggestions
+handoff_to:
+  - code-guardian
+---
+
+# 单元测试专家
+
+## 角色定位
+
+负责单元测试设计和补充建议，不替代业务实现。
+
+## 工作重点
+
+- 判断哪些逻辑需要测试保护
+- 识别边界条件和回归风险
+- 让测试关注核心行为而不是表面覆盖率
+- 在 quick-fix 模式下优先识别“是否必须补测”，而不是默认扩成完整测试改造
+
+## 建议输入
+
+- 目标模块代码
+- 任务清单
+- 现有测试
+- 若当前 flow 是 `bugfix-to-verification`，优先读取 `.ai-spec/history/<run-id>/bugfix.md`、`implementation-notes.md` 和相关代码
+
+## 预期输出
+
+- 单测建议
+- 边界场景清单
+- 覆盖重点说明
+- 在可直接补测时，说明建议新增的测试落点与断言重点
+
+## 启用条件
+
+- 核心逻辑复杂
+- 改动存在明显回归风险
+- store 变更
+- 工具函数修复
+- 边界逻辑修复

package/.agents/roles/domains/testing/verification-reviewer.md

@@ -0,0 +1,67 @@
+---
+id: verification-reviewer
+name: 验证评审专家
+status: active
+domains:
+  - testing
+description: 负责对需求验收项、测试场景和交付验证口径做最终审视，保证验证链路完整。
+triggers:
+  - verification-review
+  - acceptance-check
+preferred_skills:
+  - ui-verification
+  - web-design-guidelines
+reads:
+  - openspec/changes/<change-id>/
+  - checklist
+writes:
+  - verification-review-notes
+  - acceptance-risks
+handoff_to:
+  - code-guardian
+---
+
+# 验证评审专家
+
+## 角色定位
+
+负责从验收视角复核测试和验证是否完整。
+
+## 工作重点
+
+- 对照需求目标检查验证口径
+- 发现“代码完成但验收不完整”的问题
+- 识别遗漏功能、部分实现和体验层面的验收缺口
+- 强化交付前的验证闭环
+- 在 quick-fix 模式下只补强验收证据，不重新定义需求边界
+
+## 建议输入
+
+- `proposal.md`
+- `tasks.md`
+- `checklist.md`
+- 若当前 flow 是 `bugfix-to-verification`，优先读取 `.ai-spec/history/<run-id>/bugfix.md / implementation-notes.md / checklist.md`
+
+## 预期输出
+
+- 验证评审意见
+- 验收风险点
+- 需求完成度与遗漏项判断
+- 需要补充的验证项
+
+## 双模式说明
+
+### OpenSpec 模式
+
+- 读取 `proposal/tasks/checklist`
+- 对照需求与任务口径补验证缺口，并区分已实现、部分实现、未实现
+
+### Quick-fix 模式
+
+- 读取 `.ai-spec/history/<run-id>/bugfix.md / implementation-notes.md / checklist.md`
+- 目标是补强轻流程的验收证据，不重写问题定义
+
+## 启用条件
+
+- 验收标准复杂
+- 交付需要多人协作确认

package/.agents/rules/README.md

@@ -0,0 +1,87 @@
+---
+name: rules-index
+description: 规范目录索引。安装到目标项目后此目录为扁平结构（common + profile 合并），此处为源仓库的分层结构。
+---
+
+# 规范目录结构
+
+本目录采用 **common + profiles** 分层组织：
+
+## common/ — 技术栈无关的通用规范
+
+| 文件 | 用途 |
+|------|------|
+| `02-编码规范.md` | TypeScript / JavaScript、命名、函数命名 |
+| `05-API规范.md` | 接口命名、错误处理（通用原则） |
+| `08-通用约束.md` | 中文注释、可观测性、占位元素 |
+| `10-文档规范.md` | 注释与 JSDoc |
+| `11-测试规范.md` | 测试覆盖与质量门禁 |
+| `12-Superpowers执行规范.md` | 实现阶段的 Superpowers Loop |
+| `13-代码格式化与检查.md` | ESLint、Prettier、Stylelint、husky（提交校验可选） |
+| `14-审计汇报规范.md` | 执行审计报告格式与约束 |
+
+## profiles/ — 技术栈特定规范
+
+### profiles/react/
+
+| 文件 | 用途 |
+|------|------|
+| `01-项目概述.md` | React + TS + Vite + Antd + Zustand |
+| `03-项目结构.md` | src 目录约束 |
+| `04-组件规范.md` | TSX 组件、SCSS Modules |
+| `06-路由规范.md` | React.lazy 懒加载、集中管理 |
+| `07-状态管理.md` | Zustand（推荐）或 Redux |
+| `09-样式规范.md` | SCSS Modules + Antd 主题变量 |
+
+### profiles/vue/
+
+| 文件 | 用途 |
+|------|------|
+| `01-项目概述.md` | Vue 3 + TS + Vite + Pinia + Vue Router |
+| `03-项目结构.md` | views/composables/stores 目录约束 |
+| `04-组件规范.md` | SFC、script setup、props/emits |
+| `06-路由规范.md` | Vue Router + 页面目录 |
+| `07-状态管理.md` | Pinia |
+| `09-样式规范.md` | 组件库主题 token |
+
+## 安装后的目标项目结构
+
+`install.sh --profile react` 会将 `common/` + `profiles/react/` 合并为扁平目录：
+
+```
+目标项目/.agents/rules/
+├── 01-项目概述.md      ← profiles/react/
+├── 02-编码规范.md      ← common/
+├── 03-项目结构.md      ← profiles/react/
+├── ...
+├── 12-Superpowers执行规范.md  ← common/
+├── 13-代码格式化与检查.md      ← common/
+└── 14-审计汇报规范.md          ← common/
+```
+
+---
+
+## 快速查找
+
+| 需求 | 规范文件 |
+|------|----------|
+| 项目背景是什么？使用哪些技术栈？ | 01-项目概述 |
+| 如何命名函数/变量？ | 02-编码规范 |
+| 代码放在哪个目录？ | 03-项目结构 |
+| 如何创建/拆分组件？ | 04-组件规范 |
+| 如何调用接口？ | 05-API规范 |
+| 如何配置路由？ | 06-路由规范 |
+| 如何管理全局状态？ | 07-状态管理 |
+| 有哪些通用约束？ | 08-通用约束 |
+| 如何使用主题变量？ | 09-样式规范 |
+| 如何写注释？ | 10-文档规范 |
+| 有何测试要求？ | 11-测试规范 |
+| 开始执行 tasks.md 的编码执行模式？ | 12-Superpowers执行规范 |
+| 如何配置代码格式化与检查？ | 13-代码格式化与检查 |
+| AI 执行后的审计报告格式？ | 14-审计汇报规范 |
+
+## 使用说明
+
+1. 根据需要的规范类型，查找对应的模块文件
+2. 所有规范文件均为 `alwaysApply: false`，按需读取而非自动加载
+3. 详细示例与落地步骤见 `.agents/skills/` 目录下的技能文件

package/.agents/rules/common/02-/347/274/226/347/240/201/350/247/204/350/214/203.md

@@ -0,0 +1,45 @@
+---
+alwaysApply: false
+description: 项目的编码规范，包括 TypeScript 与 JavaScript 并存策略、类型与 JSDoc 要求、命名约定（变量、常量、接口等）、业务函数命名规则。当编写、修改、重构或审查代码时读取此规则。
+---
+
+# 编码规范
+
+## 语言策略（TS 优先 + JS 兼容）
+
+- **新代码与可迁移模块**：优先使用 **TypeScript**（`.ts`、`.tsx`）。
+- **存量或未引入 TypeScript 的项目**：允许使用 **JavaScript**（`.js`、`.jsx`），须遵循下文 **JavaScript** 小节。
+- **同一目录/同一业务模块内**：避免同一职责在 TS 与 JS 之间随意混用；新增文件优先与周边已有扩展名一致，或逐步统一到 TS。
+
+## TypeScript 规范
+
+- 所有 TypeScript 代码须包含完整类型定义。
+- 禁止使用 `any`；类型不确定时优先使用 `unknown` 再收窄。
+- 定义对象结构优先使用 `interface`；联合类型、交叉类型、映射类型使用 `type`。
+- 接口、类型定义使用 PascalCase。
+- 公共函数与模块导出须明确类型签名。
+
+## JavaScript（存量 / 无 TS 项目）
+
+- **类型意图**：对导出函数、公共 API、复杂参数与返回值使用 **JSDoc**（`@param`、`@returns`、`@typedef` 等）表达契约；团队若启用 `checkJs` / `// @ts-check`，须与之保持一致。
+- **运行时校验**：对外部数据（接口响应、URL 参数等）须在边界处校验或规范化，避免静默假设结构正确。
+
+## 命名规范
+
+| 类型 | 命名规则 | 示例 |
+|------|----------|------|
+| 目录/模块 | kebab-case | `user-profile`、`order-service` |
+| 变量/函数 | camelCase | `userList`、`fetchData` |
+| 布尔值 | is/has/can/should 前缀 | `isLoading`、`hasPermission`、`canEdit` |
+| 常量 | UPPER_CASE | `API_TIMEOUT`、`MAX_RETRY` |
+| 枚举名 | PascalCase | `ApiMethod`、`UserStatus` |
+| 枚举值 | PascalCase | `ApiMethod.Get`、`UserStatus.Active` |
+| 接口/类 | PascalCase | `UserInfo`、`BaseResponse` |
+| 组合式函数/Hooks | use 前缀 + camelCase | `useUserStore`、`useAuth` |
+
+> 各技术栈的组件、类、文件命名约定由对应 profile 规范约定，此处仅约束代码中的通用命名原则。
+
+## 业务函数命名
+
+- **回调属性（Props / Emits / 事件处理器）**：`onXxx`（如 `onSubmit`、`onChange`）
+- **本地处理函数**：`handleXxx`（如 `handleSubmit`、`handleDelete`）

package/.agents/rules/common/08-/351/200/232/347/224/250/347/272/246/346/235/237.md

@@ -0,0 +1,63 @@
+---
+alwaysApply: false
+description: 项目的通用约束，包括中文注释要求、可观测性规范、依赖管理、安全约束、调试代码约束与 Git 提交规范。当编写、修改代码或需要确认通用约束时读取此规则。
+---
+
+# 通用约束
+
+## 语言规范（NON-NEGOTIABLE）
+
+- 所有文档和代码注释必须使用中文
+- 代码变量/函数命名仍使用英文（遵循编码规范）
+
+## 可观测性与兜底
+
+### 通用规范
+
+- 错误处理必须有统一机制（错误边界 / 全局异常捕获），禁止吞掉异常不处理
+- 生产环境禁止残留 `console.log`、`console.debug`；仅允许 `console.warn` 和 `console.error` 用于真实告警
+- 需要调试日志时，使用项目统一的 logger 工具，支持按环境区分日志级别
+
+### AI 业务场景
+
+以下约束适用于包含 AI 能力的业务模块：
+
+- AI 任务需要完整链路：任务 ID、素材/模型引用、日志追踪
+- 失败时提供兜底提示与重试机制
+
+## 依赖管理
+
+- 新增第三方依赖前需评估其对产物体积或运行时开销的影响，优先使用项目已有工具库
+- 使用项目约定的包管理器，禁止在同一项目中混用多种包管理器
+- 禁止引入超过 12 个月无更新且无明确维护者的依赖
+- 依赖版本通过 lock 文件锁定，禁止使用 `*` 或 `latest` 版本号
+
+## 安全约束
+
+- 禁止在代码中硬编码密钥、token、密码等敏感信息
+- 敏感配置通过 `.env` 文件管理，`.env` 文件必须加入 `.gitignore`
+- 用户输入在拼接 HTML 或 URL 前必须转义，防止注入攻击
+- 第三方脚本（统计、广告等）需评估安全风险后再引入
+
+## 调试代码约束
+
+- 提交代码前必须清除 `debugger` 语句
+- 禁止提交被注释掉的大段代码块（超过 5 行），废弃代码应直接删除
+- 临时调试用的 `// @ts-ignore`、`// eslint-disable` 必须附带原因注释，合并前清除
+
+## Git 提交规范
+
+- Commit message 遵循 [Conventional Commits](https://www.conventionalcommits.org/) 格式：`<type>(<scope>): <description>`
+- 常用 type：`feat`、`fix`、`refactor`、`style`、`docs`、`test`、`chore`
+- 单次提交聚焦一个变更目的，禁止在一个 commit 中混合不相关改动
+
+## 通用约束汇总
+
+以下约束已在各规范文件中详述，此处汇总便于快速查阅：
+
+| 约束 | 关键要点 | 来源 |
+|------|----------|------|
+| 类型与语言 | TypeScript 优先；纯 JS 项目遵循 02 的 JavaScript 小节；TS 禁止 `any` | 02-编码规范 |
+| 命名规范一致性 | 变量 camelCase、常量 UPPER_CASE | 02-编码规范 |
+| 项目结构规范 | 禁止新建非标准目录 | 03-项目结构（profile 规范） |
+| API 封装规范 | 接口统一通过封装层调用，不在业务层直接发请求 | 各 profile 的 API 规范 |

package/.agents/rules/common/10-/346/226/207/346/241/243/350/247/204/350/214/203.md

@@ -0,0 +1,101 @@
+---
+alwaysApply: false
+description: 项目的文档与注释规范，包括文档注释与实现注释的区分、JSDoc 在 TypeScript 与 JavaScript 项目中的用法、TODO/FIXME 约定、禁止模式。当编写或审查代码注释时读取此规则。
+---
+
+# 文档规范
+
+## 注释分类
+
+项目中使用两种注释，用途不同：
+
+| 类型 | 语法 | 面向 | 用途 |
+|------|------|------|------|
+| 文档注释 | `/** */` | 调用方 | 描述公开 API 的契约（导出函数、组件、接口等） |
+| 实现注释 | `//` | 维护者 | 解释内部逻辑的"为什么"，标记 TODO/FIXME |
+
+## 文档注释规范（`/** */`）
+
+### 哪些代码需要写
+
+- 导出的函数、类、接口、类型、枚举
+- 组件的 Props 接口（说明各属性含义）
+- 复杂的工具函数（说明功能、边界条件、副作用）
+
+### 怎么写（TypeScript 项目）
+
+TypeScript 已通过类型系统表达了参数类型和返回类型，**JSDoc 中不要重复类型信息**，聚焦于语义描述：
+
+```ts
+// 好 — 描述语义，不重复类型
+/** 根据资产 ID 获取资产详情，未找到时返回 null */
+export function getAssetDetailApi(id: number): Promise<AssetDetail | null> { ... }
+
+// 差 — 重复 TS 已表达的类型信息
+/**
+ * @param {number} id - 资产ID
+ * @returns {Promise<AssetDetail | null>} 资产详情
+ */
+export function getAssetDetailApi(id: number): Promise<AssetDetail | null> { ... }
+```
+
+### 常用 JSDoc 标签
+
+| 标签 | 用途 | 示例 |
+|------|------|------|
+| `@param` | 补充参数语义（不写类型） | `@param id 资产唯一标识` |
+| `@returns` | 补充返回值语义（不写类型） | `@returns 包含分页信息的列表` |
+| `@example` | 提供使用示例 | 复杂工具函数推荐添加 |
+| `@deprecated` | 标记即将废弃的 API | `@deprecated 请使用 getAssetListApi 替代` |
+| `@throws` | 说明可能抛出的异常 | `@throws 当 token 过期时抛出 AuthError` |
+| `@see` | 引用相关代码或文档 | `@see https://apifox.com/xxx` |
+
+### 怎么写（纯 JavaScript 项目）
+
+无静态类型系统时，JSDoc 承担更多契约表达职责：可在 `@param`、`@returns`、`@typedef` 中**写出类型信息**（如 `{number}`、`{Promise<AssetDetail|null>}`），与 02-编码规范中的 JavaScript 小节一致。
+
+```js
+/**
+ * 根据资产 ID 获取资产详情，未找到时返回 null
+ * @param {number} id
+ * @returns {Promise<import('./types').AssetDetail | null>}
+ */
+export async function getAssetDetailApi(id) { ... }
+```
+
+- 导出函数、公共模块边界应优先写全 JSDoc，便于 IDE 提示与后续迁移 TypeScript。
+- 团队若使用 `// @ts-check` 或 `checkJs`，JSDoc 类型应与 ESLint/TS 校验一致。
+
+## 实现注释规范（`//`）
+
+- 注释应该解释"为什么"而不是"是什么"，避免冗余注释
+- 放在被注释代码的上方，而非行尾（行尾仅用于极短说明）
+
+```ts
+// 好 — 解释不明显的业务原因
+// 延迟 300ms 等待动画完成后再请求，避免页面闪烁
+await sleep(300);
+
+// 差 — 代码本身已经表达清楚
+// 设置 loading 为 true
+setLoading(true);
+```
+
+## TODO / FIXME 约定
+
+| 标记 | 含义 | 格式 |
+|------|------|------|
+| `TODO` | 待完成的功能或改进 | `// TODO: 描述内容` |
+| `FIXME` | 已知问题待修复 | `// FIXME: 描述问题` |
+
+- 使用统一格式 `// TODO: xxx`（冒号后加空格），便于全局检索
+- 标记应包含足够的上下文，让其他人能理解意图
+
+## 禁止模式（NON-NEGOTIABLE）
+
+| 禁止项 | 原因 | 正确做法 |
+|--------|------|----------|
+| 注释掉的代码 | 造成噪音，增加维护负担 | 直接删除，靠 Git 历史追溯 |
+| 冗余注释 | 重复代码已表达的信息 | 只注释代码无法表达的意图 |
+| 过时注释 | 错误的注释比没有注释更有害 | 修改代码时同步更新注释 |
+| JSDoc 中重复 TS 已写的类型 | 与类型系统重复 | TS 项目只写语义；JS 项目用 JSDoc 补类型 |

package/.agents/rules/common/12-Superpowers/346/211/247/350/241/214/350/247/204/350/214/203.md

@@ -0,0 +1,46 @@
+---
+alwaysApply: false
+description: 实现变更时的强制执行规范，要求启用 Superpowers 微观执行模式（头脑风暴、TDD 驱动、双重审查、审计汇报）。当开始编写代码或执行 tasks.md 时读取此规则。
+---
+
+# 12-Superpowers 编码执行规范
+
+## 适用范围
+
+当进入实现阶段并开始处理 `tasks.md` 中的具体任务时，本规范自动生效。
+
+## 核心约束（NON-NEGOTIABLE）
+
+1. **禁止直出代码**：绝对禁止未经思考直接输出大量业务代码。每条 Task 必须经过 Superpowers Loop 的四道关卡后才可提交。
+2. **逐条执行**：按 `tasks.md` 中的顺序逐条处理，禁止跳过或批量完成（用户明确指示批量执行时，仍须逐条输出四步内容，仅可跳过步骤 1 的用户确认门禁）。
+3. **用户确认门禁**：每条 Task 的头脑风暴结论必须获得用户明确同意后，才可进入编码阶段。
+4. **审计可追溯**：每条 Task 完成后必须输出结构化审计报告，格式见 `14-审计汇报规范.md`。禁止在未实际 Read 某文件时声称已读取。
+5. **输出可见性**：四道关卡中每一道都必须产出可见的结构化输出（含步骤标题 `### 第N步：xxx`），缺失标题即视为未执行该关卡。禁止以"静默核对"替代可见输出。
+
+## Superpowers Loop（四道关卡）
+
+| 关卡 | 名称 | 核心要求 |
+|------|------|----------|
+| 1 | 头脑风暴 | 先思考边界情况、错误处理和对现有代码的影响；有歧义必须提问 |
+| 2 | TDD 驱动 | RED → GREEN → REFACTOR；REFACTOR 阶段须按需引用 `.agents/rules/` 中的对应规范 |
+| 3 | 双重审查 | 设计对齐（`design.md` / `specs/`）+ 质量门禁（异常捕获、类型严谨）；**必须输出审查结论表格** |
+| 4 | 审计汇报 | 按 `14-审计汇报规范.md` 输出读取记录、操作记录、规范对齐、技能状态、偏差说明 |
+
+## 何时可以跳过
+
+以下情况可省略本规范，直接修改：
+
+- 修复拼写、格式、注释等非行为性变更
+- 恢复已有 spec 描述的预期行为（Bug fix）
+- 非破坏性依赖版本更新
+
+## 具体操作步骤
+
+详见 `.agents/skills/execute-task/SKILL.md`（刚性技能，v2.0），该技能定义了 Superpowers Loop 的四步操作流程及每步的**强制输出格式**：
+
+1. `### 第一步：头脑风暴` — 思路 + 边界 + 用户确认
+2. `### 第二步：TDD 编码` — RED / GREEN / REFACTOR 操作说明
+3. `### 第三步：双重审查` — 三维度审查结论表格（架构对齐、健壮性、规范合规）
+4. `### 第四步：状态更新` — tasks.md 勾选 + 审计报告
+
+缺失任何一个步骤标题即视为违规。

package/.agents/rules/common/14-/345/256/241/350/256/241/346/261/207/346/212/245/350/247/204/350/214/203.md

@@ -0,0 +1,107 @@
+---
+alwaysApply: false
+description: 执行审计汇报规范，要求 AI 在产出代码变更后附带结构化、可核对的审计报告。当执行 tasks.md 任务、批量实现、或完成任何产出代码变更的操作后读取此规则。
+---
+
+# 审计汇报规范
+
+## 适用范围
+
+当 AI 完成以下任何操作后，必须附带审计报告：
+
+- 执行 `tasks.md` 中的单条任务（execute-task 第四步）
+- 批量实现多条任务
+- 完成 `create-proposal` 后置检查
+- 任何产出代码文件变更的操作
+
+## 核心约束（NON-NEGOTIABLE）
+
+1. **禁止虚假声明**：禁止在未使用 Read 工具实际读取某文件时声称「已加载」「已读取」该文件。只有工具调用记录中存在对应 Read 操作的，才可标记为「已 Read」。
+2. **禁止笼统表述**：禁止用「遵循了团队规范」「按规范执行」等笼统措辞替代具体规范条目引用。必须指明规范文件名 + 具体章节/表格/条目。
+3. **明确区分读取状态**：「已 Read」与「未 Read，行为上对齐」是两种不同状态，必须如实标注，不可混淆。
+4. **偏差必须披露**：凡与技能定义的步骤不一致之处（如跳过确认、跳过 TDD、批量执行等），必须在报告中明确写出，不可隐瞒。
+
+## 审计报告模板
+
+每次审计报告包含以下五个区块，按顺序输出：
+
+### 区块 1：读取记录
+
+列出本次操作中涉及的所有规范文件和技能文件，标注实际读取状态。
+
+| 类型 | 文件路径 | 状态 |
+|------|---------|------|
+| 技能 | `.agents/skills/xxx/SKILL.md` | 已 Read / 未 Read |
+| 规则 | `.agents/rules/xxx.md` | 已 Read / 未 Read，依据 xxx 推断 |
+| 设计 | `openspec/changes/xxx/design.md` | 已 Read / 未 Read |
+| 任务 | `openspec/changes/xxx/tasks.md` | 已 Read |
+
+状态取值说明：
+
+- **已 Read**：本次对话中使用 Read 工具读取过该文件
+- **未 Read，依据 X 推断**：未直接读取，但依据其它已读文件（如 tasks.md、design.md）中的描述推断行为
+- **未 Read，凭既有知识**：未读取，依据训练知识或上下文惯例行事
+
+### 区块 2：操作记录
+
+按时间顺序列出所有工具调用，包括文件操作和终端命令。
+
+格式：`序号. 工具名: 文件路径或命令（操作说明）`
+
+示例：
+
+```
+1. Read: package.json
+2. Write: src/services/auth.ts（新建认证服务模块）
+3. StrReplace: src/router/index.ts（添加 /auth 路由入口）
+4. Shell: npm install <dependency>
+```
+
+### 区块 3：规范对齐
+
+列出代码中的关键决策点，以及其对应的具体规范条目。
+
+| 操作 | 对应规范 | 具体条目 |
+|------|---------|---------|
+| 模块目录命名 kebab-case | `02-编码规范.md` | 「命名规范」目录/模块一栏 |
+| 接口封装统一通过服务层 | 各 profile 的 API/接口规范 | 「接口请求规范」节 |
+| 新增功能附带测试用例 | 各 profile 的测试规范 | 「质量门禁」节 |
+
+若无明确规范对应（如纯业务逻辑），可写「无对应规范，按业务需求实现」。
+
+### 区块 4：技能执行状态
+
+列出本次操作涉及或应涉及的技能，标注执行状态。
+
+| 技能 | 状态 | 备注 |
+|------|------|------|
+| execute-task | 已 Read，按四步循环执行 | — |
+| create-component | 未 Read，行为上对齐 | tasks.md 已写明组件结构 |
+| theme-variables | 未涉及 | 本次任务不涉及样式 |
+
+### 区块 5：与规范/技能不一致处
+
+列出所有偏离规范或技能要求的地方，必须说明原因。
+
+示例：
+
+- execute-task 要求逐步确认，本回合用户指示批量执行，未逐步询问
+- TDD RED 阶段：项目未配置测试框架，改用类型断言兜底
+- 未执行双重审查中的「架构对齐」，因本次仅修改配置文件
+
+若完全一致，写「无偏差」。
+
+## 简化规则
+
+为避免审计报告过于冗长影响效率，以下场景可使用精简版：
+
+| 场景 | 精简方式 |
+|------|---------|
+| 单条简单任务（如修改一个文件） | 区块 2 和区块 3 可合并为一行 |
+| 连续执行同类任务（如连续创建多个 API） | 多条任务共用一份报告，按任务编号分列 |
+| 非行为性变更（拼写、注释、格式） | 可省略本规范（同 12-Superpowers执行规范 的跳过条件） |
+
+## 相关规范与技能
+
+- `.agents/rules/12-Superpowers执行规范.md` — 执行原则（本规范作为其第 4 关卡）
+- `.agents/skills/execute-task/SKILL.md` — Superpowers 四步循环（第四步引用本规范）