aodw-skill 0.7.17 → 0.7.19

package/.aodw-next/07-optimization/token-usage-analysis.md

@@ -1,253 +0,0 @@
-# AODW Token 消耗分析与优化建议
-
-## 1. 问题确认
-
-用户反馈使用 AODW 过程中非常消耗 AI 的 token。经过分析，确实存在这个问题。
-
-### 1.1 Token 消耗统计
-
-**总体情况**：
-- 规则文件总数：46 个
-- 总文件大小：283.3 KB
-- 估算总 token：~72,504 tokens
-
-**典型工作流消耗**：
-- **创建新 RT (Spec-Lite)**：~16,338 tokens（6 个文件，63.8 KB）
-- **创建新 RT (Spec-Full)**：~24,275 tokens（8 个文件，94.8 KB）
-- **UI 相关任务**：~9,055 tokens（7 个文件，35.4 KB）
-- **代码实现阶段**：~10,971 tokens（5 个文件，42.9 KB）
-
-### 1.2 主要问题
-
-1. **强制文件加载过多**
-   - 每次创建 RT 都需要读取多个大文件（3-8 个）
-   - UI 任务需要额外读取 4 个 ui-kit 文件
-   - 审计阶段需要读取大型审计规则文件（17KB+）
-
-2. **文件大小问题**
-   - 最大的文件：18KB+（python-fastapi 编码规范）
-   - 多个文件超过 10KB
-   - 审计规则文件特别大（17KB+）
-
-3. **重复加载可能性**
-   - 某些文件被多次引用（如 `ai-coding-rules-common.md` 被引用 15 次）
-   - 不同阶段可能重复加载相同文件
-
-4. **缺乏按需加载机制**
-   - 规则要求"必须读取"，但没有明确"何时读取"
-   - 没有区分"必须立即读取"和"按需读取"
-
----
-
-## 2. 优化建议
-
-### 2.1 按需加载策略（推荐）
-
-**核心原则**：只在需要时读取相关文件，而不是一次性加载所有文件。
-
-#### 优化方案 A：阶段化加载
-
-**当前问题**：
-- 创建 RT 时一次性加载 6-8 个文件
-- 所有文件都在上下文中，即使当前阶段不需要
-
-**优化方案**：
-- **阶段 1（创建 RT）**：只加载 `rt-manager.md`、`ai-interaction-rules.md`、`rt-id-generation-rules.md`
-- **阶段 2（Intake）**：按需加载 `ai-interaction-rules.md`（如果未加载）
-- **阶段 3（决策）**：按需加载 `spec-full-profile.md` 或 `spec-lite-profile.md`
-- **阶段 4（Spec/Plan）**：按需加载相关规范文件
-- **阶段 5（实现）**：按需加载编码规范文件
-- **阶段 6（审计）**：按需加载审计规则文件
-
-#### 优化方案 B：摘要索引模式
-
-**核心思路**：为大型文件创建摘要版本，AI 先读取摘要，需要详细信息时再读取完整文件。
-
-**实施方式**：
-1. 为每个大型规则文件创建 `xxx-summary.md`（1-2KB）
-2. 摘要包含：核心规则、关键检查点、详细规则位置
-3. AI 先读取摘要，根据摘要决定是否需要读取完整文件
-
-**示例**：
-```
-.aodw-next/02-workflow/spec-lite-profile-summary.md  (摘要)
-.aodw-next/02-workflow/spec-lite-profile.md         (完整版)
-```
-
-### 2.2 UI-Kit 优化
-
-**当前问题**：
-- UI 任务需要读取 4 个 ui-kit 文件（~670 tokens）
-- 这些文件内容相对简单，可以合并或精简
-
-**优化方案**：
-1. **合并文件**：将 4 个文件合并为 1 个 `ui-kit.md`（~2KB）
-2. **精简内容**：移除冗余说明，保留核心规则
-3. **按需加载**：只在 UI 任务时加载，非 UI 任务不加载
-
-### 2.3 审计规则优化
-
-**当前问题**：
-- 审计规则文件特别大（17KB+，~4,350 tokens）
-- 每次审计都需要加载完整文件
-
-**优化方案**：
-1. **拆分文件**：按审计类型拆分（需求审计、开发审计、综合审计）
-2. **摘要模式**：创建摘要版本，只包含核心检查点
-3. **按需加载**：只在执行审计时加载，不提前加载
-
-### 2.4 编码规范优化
-
-**当前问题**：
-- 编码规范文件被频繁引用（15+ 次）
-- 文件较大（11KB+）
-- 可能在不同阶段重复加载
-
-**优化方案**：
-1. **缓存机制**：如果已加载过，不再重复加载
-2. **摘要版本**：创建摘要，只包含关键规则
-3. **按技术栈分离**：前端/后端规范分开，只加载相关的
-
-### 2.5 规则文件精简
-
-**当前问题**：
-- 某些文件包含大量示例代码和说明
-- 可以精简为核心规则
-
-**优化方案**：
-1. **移除冗余示例**：保留 1-2 个关键示例即可
-2. **精简说明**：移除重复说明，保留核心规则
-3. **外部化示例**：将详细示例移到单独文件
-
----
-
-## 3. 实施优先级
-
-### 高优先级（立即实施）
-
-1. **明确按需加载规则**
-   - 更新规则文件，明确"何时读取"而不是"必须读取"
-   - 区分"必须立即读取"和"按需读取"
-
-2. **UI-Kit 文件合并**
-   - 将 4 个文件合并为 1 个
-   - 精简内容，保留核心规则
-
-3. **创建文件加载指南**
-   - 明确每个阶段需要加载哪些文件
-   - 避免重复加载
-
-### 中优先级（后续优化）
-
-4. **创建摘要版本**
-   - 为大型文件创建摘要版本
-   - AI 先读取摘要，需要时再读取完整版
-
-5. **审计规则拆分**
-   - 按审计类型拆分文件
-   - 减少单次加载的文件大小
-
-6. **编码规范优化**
-   - 创建摘要版本
-   - 实施缓存机制
-
-### 低优先级（长期优化）
-
-7. **规则文件精简**
-   - 移除冗余内容
-   - 外部化详细示例
-
-8. **智能加载系统**
-   - 根据任务类型自动选择需要加载的文件
-   - 实施文件依赖关系管理
-
----
-
-## 4. 具体优化措施
-
-### 4.1 更新规则文件，明确加载时机
-
-**当前表述**：
-> AI **必须**先读取并理解以下文件
-
-**优化后**：
-> AI **必须**在 [具体阶段/条件] 时读取并理解以下文件：
-> - 如果 [条件 A]：读取文件 X
-> - 如果 [条件 B]：读取文件 Y
-> - 否则：跳过
-
-### 4.2 创建文件加载指南
-
-在 `aodw-constitution.md` 中添加"文件加载策略"章节，明确：
-- 每个阶段需要加载哪些文件
-- 哪些文件可以按需加载
-- 哪些文件可以缓存
-
-### 4.3 优化 UI-Kit 文件
-
-- 合并 4 个文件为 1 个 `ui-kit.md`
-- 精简内容，保留核心规则
-- 总大小控制在 2KB 以内
-
----
-
-## 5. 预期效果
-
-实施优化后，预期可以：
-
-1. **减少 50-70% 的 token 消耗**
-   - Spec-Lite RT 创建：从 ~16K tokens 降至 ~5-8K tokens
-   - Spec-Full RT 创建：从 ~24K tokens 降至 ~8-12K tokens
-   - UI 任务：从 ~9K tokens 降至 ~2-3K tokens
-
-2. **提升响应速度**
-   - 减少文件加载时间
-   - 减少上下文处理时间
-
-3. **保持功能完整性**
-   - 所有核心功能保持不变
-   - 只是优化了加载策略
-
----
-
-## 6. 风险评估
-
-### 6.1 潜在风险
-
-1. **按需加载可能导致遗漏**
-   - 风险：AI 可能忘记在需要时加载文件
-   - 缓解：明确的加载指南和检查清单
-
-2. **摘要版本可能信息不足**
-   - 风险：摘要可能遗漏关键信息
-   - 缓解：摘要包含完整文件的引用，需要时可读取
-
-3. **用户学习成本**
-   - 风险：新的加载策略需要用户理解
-   - 缓解：提供清晰的文档和示例
-
-### 6.2 兼容性
-
-- 优化后的规则应该向后兼容
-- 支持"完整加载"和"按需加载"两种模式
-- 用户可以选择使用哪种模式
-
----
-
-## 7. 下一步行动
-
-1. **立即行动**：
-   - 更新规则文件，明确加载时机
-   - 合并 UI-Kit 文件
-   - 创建文件加载指南
-
-2. **短期行动**（1-2 周）：
-   - 创建摘要版本
-   - 优化审计规则
-   - 实施缓存机制
-
-3. **长期行动**（1 个月+）：
-   - 规则文件精简
-   - 智能加载系统
-   - 性能监控和优化
-

package/.aodw-next/templates/TEMPLATE-APPLICATION-GUIDE.md

@@ -1,110 +0,0 @@
-# 模板应用指南 (Template Application Guide)
-
-## 1. 模板机制概述
-
-AODW Next 使用**统一模板机制**来生成各个平台的适配器文件，确保所有平台的内容保持一致。
-
-### 1.1 模板位置
-
-**源模板**：`.aodw-next/templates/aodw-kernel-loader-template.md`
-
-这个模板包含所有平台的通用内容，使用占位符标记平台差异：
-- `{{REF_PREFIX}}` - 引用前缀（Cursor: `@`，其他: 空）
-
-### 1.2 适配器文件位置
-
-**生成的适配器文件**（在源仓库中）：
-- `templates/AODW_Adapters/antigravity/.agent/rules/aodw-next.md`
-- `templates/AODW_Adapters/cursor/.cursor/rules/aodw-next.mdc`
-- `templates/AODW_Adapters/claude/CLAUDE.md`
-- `templates/AODW_Adapters/gemini/.agent/rules/aodw-next.md`
-- `templates/AODW_Adapters/general/AGENTS.md`
-
-**注意**：适配器文件在用户项目中安装到对应位置。
-
----
-
-## 2. 模板处理流程
-
-### 2.1 安装阶段（用户项目）
-
-1. **CLI 检测模板**：检查 `.aodw-next/templates/aodw-kernel-loader-template.md` 是否存在
-2. **使用 Processor**：根据平台选择对应的 Processor
-3. **生成适配器文件**：在用户项目中生成适配器文件
-
-**Processor 处理**：
-- **AntigravityProcessor**：替换 `{{REF_PREFIX}}` 为空，注入 `trigger: always_on`
-- **CursorProcessor**：替换 `{{REF_PREFIX}}` 为 `@`，注入 frontmatter（globs, alwaysApply 等）
-- **ClaudeProcessor**：替换 `{{REF_PREFIX}}` 为空
-- **GeminiProcessor**：替换 `{{REF_PREFIX}}` 为空
-- **GeneralProcessor**：替换 `{{REF_PREFIX}}` 为空
-
----
-
-## 3. Processor 说明
-
-### 3.1 AntigravityProcessor
-
-**处理**：
-- 替换 `{{REF_PREFIX}}` 为空字符串
-- 注入 `trigger: always_on` frontmatter（仅对 kernel loader）
-
-**输出**：
-- 文件：`templates/AODW_Adapters/antigravity/.agent/rules/aodw-next.md`
-- 格式：Markdown with frontmatter
-
-### 3.2 CursorProcessor
-
-**处理**：
-- 替换 `{{REF_PREFIX}}` 为 `@`
-- 注入 frontmatter：`globs: *`, `alwaysApply: true`, `description`, `tags`
-- 文件扩展名改为 `.mdc`
-
-**输出**：
-- 文件：`templates/AODW_Adapters/cursor/.cursor/rules/aodw-next.mdc`
-- 格式：Markdown with Cursor-specific frontmatter
-
-### 3.3 ClaudeProcessor
-
-**处理**：
-- 替换 `{{REF_PREFIX}}` 为空字符串
-- 不注入 frontmatter
-
-**输出**：
-- 文件：`templates/AODW_Adapters/claude/CLAUDE.md`
-- 格式：标准 Markdown
-
-### 3.4 GeminiProcessor
-
-**处理**：
-- 替换 `{{REF_PREFIX}}` 为空字符串
-- 不注入 frontmatter
-
-**输出**：
-- 文件：`templates/AODW_Adapters/gemini/.agent/rules/aodw-next.md`
-- 格式：标准 Markdown
-
-### 3.5 GeneralProcessor
-
-**处理**：
-- 替换 `{{REF_PREFIX}}` 为空字符串
-- 不注入 frontmatter
-
-**输出**：
-- 文件：`templates/AODW_Adapters/general/AGENTS.md`
-- 格式：标准 Markdown
-
----
-
-## 4. 相关文件
-
-- **模板文件**：`.aodw-next/templates/aodw-kernel-loader-template.md`
-- **Processor 实现**：`cli/bin/processors/index.js`
-- **CLI 安装脚本**：`cli/bin/aodw.js`
-- **适配器文件**：`templates/AODW_Adapters/`
-
----
-
-## 5. 版本历史
-
-- **v4.0.0**：AODW Next，统一使用 `.aodw-next` 目录

package/.aodw-next/templates/audit-report-template.md

@@ -1,232 +0,0 @@
-# 需求阶段审计报告：RT-XXX - <title>
-
-## 审计元数据
-- **审计时间**：YYYY-MM-DD HH:MM:SS（必须使用系统真实时间）
-- **审计阶段**：intake / decision / spec / plan / impact / invariants
-- **审计文档**：<文档名称>
-- **审计人**：AODW 需求阶段审计官
-- **RT 状态**：created / intaking / decided / in-progress
-
----
-
-## 审计项跟踪表
-
-| ID | 类型 | 严重程度 | 状态 | 描述 | 修复说明 | 修复时间 |
-|----|------|---------|------|------|---------|---------|
-| AUDIT-001 | 需求完整性 | Blocking | Open | [审计项描述] | - | - |
-| AUDIT-002 | 需求一致性 | Critical | Fixed | [审计项描述] | [修复说明] | YYYY-MM-DD HH:MM:SS |
-
-**状态说明**：
-- **Open**：未修复
-- **In-Progress**：修复中
-- **Fixed**：已修复
-- **Verified**：已验证修复
-
-**严重程度说明**：
-- **Blocking**：阻断性问题，必须修复后才能继续
-- **Critical**：严重问题，强烈建议修复
-- **Warning**：警告性问题，建议修复
-
----
-
-## 审计结果详情
-
-### 1. 需求完整性缺陷（Requirement Completeness Issues）
-
-针对需求文档结构缺失、目标不明确、需求不可验证等问题。
-
-#### 1.1 [缺陷类型：文档结构缺失]
-
-**细节**：
-- 您的 `spec.md` 中缺少"非功能需求"章节。
-
-**疑问与挑战**：
-- 如果性能、安全性、可用性等非功能需求未明确，您如何确保技术方案能够满足这些要求？
-
-**修复建议**：
-- 在 `spec.md` 中补充"非功能需求"章节，明确性能、安全性、可用性等要求。
-
----
-
-#### 1.2 [缺陷类型：需求不可验证]
-
-**细节**：
-- 您的功能需求 FR-001 描述为"提升用户体验"，但未提供可验证的指标。
-
-**疑问与挑战**：
-- 请明确"提升用户体验"的具体指标（如：页面加载时间 < 2 秒、用户满意度 > 90%），否则无法验证需求是否达成。
-
-**修复建议**：
-- 将功能需求 FR-001 修改为可验证的描述，例如："页面加载时间从当前 5 秒降低到 2 秒以内"。
-
----
-
-### 2. 需求一致性缺陷（Requirement Consistency Issues）
-
-针对文档间矛盾、术语不一致、方案与需求不匹配等问题。
-
-#### 2.1 [缺陷类型：文档间矛盾]
-
-**细节**：
-- 您的 `intake.md` 中描述的影响模块为 `user` 和 `order`，但 `spec.md` 中只提到了 `user` 模块。
-
-**疑问与挑战**：
-- 请明确 `order` 模块是否真的受影响，如果受影响，为什么 `spec.md` 中没有提及？如果不受影响，为什么 `intake.md` 中会列出？
-
-**修复建议**：
-- 检查 `order` 模块是否真的受影响，如果受影响，在 `spec.md` 中补充；如果不受影响，从 `intake.md` 中移除。
-
----
-
-#### 2.2 [缺陷类型：方案与需求不匹配]
-
-**细节**：
-- 您的 `spec.md` 中要求"支持批量导入"，但 `plan.md` 中的技术方案只实现了单条导入。
-
-**疑问与挑战**：
-- 请说明技术方案如何满足批量导入的需求，或者修改 `spec.md` 移除批量导入的要求。
-
-**修复建议**：
-- 如果确实需要批量导入，在 `plan.md` 中补充批量导入的技术方案；如果不需要，从 `spec.md` 中移除批量导入的要求。
-
----
-
-### 3. 需求可执行性缺陷（Requirement Executability Issues）
-
-针对技术方案不完整、代码结构不明确、技术风险未识别等问题。
-
-#### 3.1 [缺陷类型：技术方案不完整]
-
-**细节**：
-- 您的 `plan.md` 中提到了"新增 API 路由"，但未明确具体的文件路径和函数名称。
-
-**疑问与挑战**：
-- 请明确 API 路由的具体路径（如：`app/api/v1/users.py`）和函数名称（如：`create_user`），否则无法执行开发。
-
-**修复建议**：
-- 在 `plan.md` 中补充具体的文件路径和函数名称，例如：
-  - 文件路径：`app/api/v1/users.py`
-  - 函数名称：`create_user`
-  - 路由路径：`POST /api/v1/users`
-
----
-
-#### 3.2 [缺陷类型：代码结构不符合规范]
-
-**细节**：
-- 您的 `plan.md` 中设计的代码结构显示，API 层直接导入了 `models`，违反了后端分层架构的依赖倒置原则。
-
-**疑问与挑战**：
-- 这种设计明确违反了后端分层架构的**不可破坏原则**，您是否计划在 `invariants.md` 中记录打破此约束的理由，并将其升级为 Spec-Full 流程？
-
-**修复建议**：
-- 修改 `plan.md` 中的代码结构，确保符合后端分层架构规范（api → services → repositories）。
-- 如果确实需要打破约束，在 `invariants.md` 中记录理由，并考虑升级为 Spec-Full 流程。
-
----
-
-### 4. 战略漏洞与 CSF 检查失败（Strategic Gaps & CSF Failures）
-
-针对方案在目标对齐、结构化分解和决策客观性方面的缺失。
-
-#### 4.1 [战略漏洞：以终为始失效]
-
-**细节**：
-- 您的方案侧重于实现技术细节，但未能明确说明本次 RT 如何直接缩小 **[当前现状]** 与 **[期望状态]** 之间的核心差距。
-
-**疑问与挑战**：
-- 请指出方案中的 **哪 1-2 个步骤** 属于无效工作（不贡献于目标的工作），并说明其移除后对目标达成的影响。
-
-**修复建议**：
-- 在 `plan.md` 中补充"目标对齐分析"章节，明确说明每个步骤如何贡献于 RT 目标。
-- 识别并移除无效工作。
-
----
-
-#### 4.2 [分解缺陷：MECE 验证失败]
-
-**细节**：
-- 您对 [关键流程/模块] 的分解似乎存在 **[重叠/遗漏]** 的风险。
-
-**疑问与挑战**：
-- 请使用**静态分解（组成部分）**和**动态分解（流程步骤）**两种视角，重新验证方案是否符合 **不重不漏（MECE）原则**。
-
-**修复建议**：
-- 在 `plan.md` 中补充"分解结构验证"章节，使用静态分解和动态分解两种视角验证 MECE 原则。
-
----
-
-#### 4.3 [决策缺陷：多维评估不足]
-
-**细节**：
-- 您仅提出了一个方案（方案 A）或仅从单一维度（例如"性能"）证明其优越性，未能进行 **多维决策矩阵评估**。
-
-**疑问与挑战**：
-- 请补充一个**备选方案 B**（例如使用不同的技术栈或更简化的 Lite 方案），并使用至少 **复杂度、风险、可维护性** 三个维度进行对比，以证明当前方案 A 是客观最优解。
-
-**修复建议**：
-- 在 `plan.md` 中补充"方案对比分析"章节，包含至少 2-3 个备选方案，并使用多维度评估矩阵进行对比。
-
----
-
-## 综合评估
-
-### 关键发现总结
-1. [发现 1]
-2. [发现 2]
-3. [发现 3]
-
-### 阻断性问题（Blocking Issues）
-- [ ] [阻断性问题 1]：必须修复后才能继续
-- [ ] [阻断性问题 2]：必须修复后才能继续
-
-### 审计结论
-- [ ] **通过**：需求文档完整、一致、可执行，可以继续
-- [ ] **有条件通过**：存在非阻断性问题，建议修复后继续
-- [ ] **不通过**：存在阻断性问题，必须修复后才能继续
-
-**结论说明**：[说明审计结论的理由]
-
----
-
-## 后续行动
-
-### 需要修复的问题
-- [ ] [问题 1]
-- [ ] [问题 2]
-
-### 需要补充的内容
-- [ ] [补充项 1]
-- [ ] [补充项 2]
-
-### 需要用户确认的事项
-- [ ] [确认项 1]
-- [ ] [确认项 2]
-
----
-
-## 历史审计记录
-
-### 审计记录 #1（YYYY-MM-DD HH:MM:SS）
-- **审计文档**：`intake.md`
-- **审计结论**：不通过
-- **主要问题**：[问题摘要]
-- **修复状态**：已修复 / 未修复
-
-### 审计记录 #2（YYYY-MM-DD HH:MM:SS）
-- **审计文档**：`spec.md`
-- **审计结论**：有条件通过
-- **主要问题**：[问题摘要]
-- **修复状态**：已修复 / 未修复
-
----
-
-## 附录：CSF 审查结果（如执行）
-
-### CSF 审查摘要
-- **审查时间**：YYYY-MM-DD HH:MM:SS
-- **审查结论**：通过 / 有条件通过 / 不通过
-- **关键发现**：[CSF 审查的关键发现]
-
-### CSF 审查详情
-详见：`RT/RT-XXX/csf-review.md`（如单独执行了 CSF Review）

package/.aodw-next/templates/changelog-template.md

@@ -1,16 +0,0 @@
-# Changelog: RT-XXX - <short title>
-
-## 1. 变更摘要（Summary）
-- 概述本次改动对系统行为带来的变化：
-
-## 2. 用户可感知变化（User-visible Changes）
-- UI / 文案 / 流程的变更：
-
-## 3. 不可见但重要的变化（Non-visible but Important）
-- 内部逻辑重构：
-- 性能 / 稳定性提升：
-- 错误处理方式的变化：
-
-## 4. 与其他 RT / 模块的关系
-- 依赖的其他 RT：
-- 未来跟进的 RT：