@gong-ym/ai-spec-auto 0.2.13 → 0.2.15

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

@@ -1,45 +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`）
+---
+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

@@ -1,63 +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 规范 |
+---
+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

@@ -1,101 +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 补类型 |
+---
+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

@@ -1,46 +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 勾选 + 审计报告
-
-缺失任何一个步骤标题即视为违规。
+---
+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 勾选 + 审计报告
+
+缺失任何一个步骤标题即视为违规。