aodw-skill 0.7.18 → 0.7.22

package/package.json

@@ -1,19 +1,19 @@
 {
   "name": "aodw-skill",
-  "version": "0.7.18",
+  "version": "0.7.22",
   "description": "Next-channel CLI tool to scaffold AODW in your project",
   "main": "bin/aodw.js",
   "files": [
     "bin/",
     ".aodw-next/",
-    "AODW_Adapters/",
-    "docs/"
+    "AODW_Adapters/"
   ],
   "bin": {
     "aodw-skill": "bin/aodw.js"
   },
   "scripts": {
-    "test": "echo \"Error: no test specified\" && exit 1"
+    "test": "echo \"Error: no test specified\" && exit 1",
+    "pack:check": "npm pack --dry-run"
   },
   "keywords": [
     "aodw",

package/.aodw-next/01-core/ai-interaction-rules-summary.md

@@ -1,37 +0,0 @@
-# AI 交互规则摘要
-
-## 0. UI 任务判断（前置）
-
-涉及页面/界面/布局/组件/表单/Dashboard/交互体验 → 视为 UI 任务，进入 UI 专用流程（详见 `.aodw-next/02-workflow/ui-workflow-rules.md`）。
-
-## 1. 提问类型
-
-- **决策型**：必须提供选项 + 推荐 + 理由，支持 custom 回答
-- **信息型**：必须提供示例答案，限制 ≤10 词
-
-## 2. 格式规范
-
-```
-Q1. <问题>
-A. <选项1>  B. <选项2>  C. <选项3>
-Recommended: B（理由：……）
-请回复：A/B/C 或 custom:<答案>
-```
-
-## 3. 每轮限制
-
-- 单轮最多 5 个问题，建议 ≤3 个
-- 必须 Ask → Wait → Respond → Continue，不得连续提问
-
-## 4. 中断与暂停
-
-- 用户说"暂停" → 立即停止，切换普通模式
-- 用户说"继续 AODW" → 恢复流程
-
-## 5. 实现前门槛（四要素）
-
-编码前必须满足：假设已声明 / 歧义已处理 / 成功标准已定义 / 最小方案已确认。缺一不可。
-
-## 6. 分支验证
-
-任何代码修改前必须 `git branch --show-current`，在 main/master 上**立即停止**。

package/.aodw-next/01-core/ai-knowledge-rules-summary.md

@@ -1,25 +0,0 @@
-# AI 知识规则摘要
-
-## 1. 文档分类
-
-- **Spec 文档**：spec.md / rt-lite.md（需求定义）
-- **Plan 文档**：plan.md / rt-lite.md §2（实现方案）
-- **过程文档**：impact.md / invariants.md / tests.md / changelog.md
-- **知识文档**：模块 README / modules-index.yaml
-
-## 2. Spec-Lite 的 rt-lite.md
-
-不再创建独立的 spec-lite.md 和 plan-lite.md，全部整合在 rt-lite.md 中。
-
-## 3. 文档同步原则
-
-- 代码改动后必须同步更新相关文档
-- 文档与代码不一致视为 Bug
-- RT 完成前必须执行知识蒸馏（更新模块文档和 modules-index.yaml）
-
-## 4. 知识蒸馏（RT 完成前提）
-
-合并前必须：
-1. 读取 modules-index.yaml 找到受影响模块
-2. 更新对应模块 README
-3. 确认文档反映最新代码状态

package/.aodw-next/01-core/git-discipline-summary.md

@@ -1,36 +0,0 @@
-# Git Discipline 摘要
-
-## 0. 确认门控
-
-AI 可执行所有 Git 操作，但不可逆操作（commit / merge / push / tag / worktree add-remove / branch delete）执行前**必须向用户确认**。
-
-无需确认：读取文件、git log/status/diff、创建/切换分支。
-
-## 1. 分支命名
-
-格式：`feature/RT-{seq}-{short-name}`（kebab-case，2-4 词）
-示例：`feature/RT-001-login-fix`
-
-## 2. Worktree
-
-一个 RT = 一个 Worktree = 一个 Feature 分支。
-- 创建：Decision 阶段 `git worktree add ../Project-RT-XXX feature/RT-XXX-name`
-- 清理：RT 完成合并后删除
-
-## 3. 提交信息
-
-格式：`<type>(<scope>): <subject>` + `Refs: RT-XXX`
-示例：`fix(auth): handle token expiration — Refs: RT-001`
-
-## 4. 标签
-
-完成后打标签：`done-RT-XXX`
-
-## 5. 合并
-
-- 禁止 fast-forward，使用 `--no-ff`
-- 合并前必须通过 lint + test + 编码规范检查
-
-## 6. 完成流程
-
-知识蒸馏 → 确认合并 → 确认清理 → 播报完成

package/.aodw-next/02-workflow/rt-id-generation-rules.md

@@ -1,24 +0,0 @@
-# RT-ID 生成规则（本地模式）
-
-## 0. 强制策略
-
-AODW 使用**本地生成 RT-ID**，不依赖远程服务。
-
-## 1. 生成逻辑
-
-1. 扫描项目 `RT/` 目录下所有 `RT-XXX` 格式的目录
-2. 找到最大序号 `N`
-3. 生成新 ID：`RT-{N+1}`（补零到 3 位，如 `RT-001`, `RT-002`）
-4. 如果生成的 ID 对应的目录已存在：递增序号直到找到可用 ID
-
-## 2. 检查清单
-
-- [ ] 已扫描 `RT/` 目录找到最大序号
-- [ ] 已生成 `RT-{N+1}` 格式的 ID
-- [ ] 已确认该 ID 对应的目录不存在
-
-## 3. 格式规范
-
-- 格式：`RT-XXX`（3 位数字，左侧补零）
-- 示例：`RT-001`, `RT-042`, `RT-123`
-- 目录：`RT/RT-XXX/`

package/.aodw-next/02-workflow/rt-manager-summary.md

@@ -1,15 +0,0 @@
-# RT-Manager Summary
-
-## 主要职责
-- RT 编号、目录、分支管理
-- Intake 流程与 Spec-Full/Spec-Lite 分流
-- 状态机维护：created → intaking → decided → in-progress → reviewing → done
-
-## 强制前置检查
-- 必须在 feature 分支上工作
-- 未切分支不得修改业务代码
-
-## 核心门禁
-- decided → in-progress 前必须具备 spec/plan
-- Plan 完成后必须等待用户确认
-- 提交前必须展示 diff 与 status

package/.aodw-next/02-workflow/ui-workflow-rules-summary.md

@@ -1,39 +0,0 @@
-# UI Workflow Rules (Summary)
-
-> **注意**：这是 UI 工作流规则的摘要版本，包含核心检查点和流程。
-> 完整版本请阅读：`02-workflow/ui-workflow-rules.md`
-
----
-
-## 核心检查点
-
-### UI 任务必须
-- 用户确认后再执行
-- 明确任务范围和验收标准
-- 记录关键决策和理由
-
-### 代码规范
-- 遵循 `03-standards/stacks/` 中的 UI 规范
-- 使用对应的 UI Kit 组件
-- 遵循无障碍设计原则
-
-### Git 规范
-- 遵循 `01-core/git-discipline.md`
-- UI 任务使用 feature 分支
-
----
-
-## 快速参考
-
-| 阶段 | 检查点 | 相关规范 |
-|-------|---------|---------|
-| 立项 | 明确范围、确认验收标准 | 01-core/ai-interaction-rules |
-| 设计 | 组件选择、设计稿评审 | 01-core/ai-interaction-rules |
-| 实现 | 代码规范、UI Kit 使用 | 03-standards/stacks/ |
-| 验证 | 用户确认、无障碍检查 | 01-core/ai-interaction-rules |
-
----
-
-## 需要详细信息时
-
-请阅读完整版：`02-workflow/ui-workflow-rules.md`

package/.aodw-next/03-standards/stacks/rust-axum/ai-coding-rules-backend.md

@@ -1,134 +0,0 @@
-# AI Coding Rules - Backend Development (Rust)
-
-> **注意**：本文件是 `.aodw-next/03-standards/ai-coding-rules.md` 的子规范文件。  
-> 请先阅读主文件了解通用编码原则。
-
-**适用场景**：
-- 后端开发（Rust + Axum + SQLx）
-- 命令行工具开发
-- 高性能组件开发
-
-**依赖规范**：
-- [Rust API Guidelines](https://rust-lang.github.io/api-guidelines/)
-- [Effective Rust](https://www.lurklurk.org/effective-rust/)
-
-## 1. 核心原则 (Core Principals)
-
-### 1.1 稳定性优先 (Stability First)
-- **绝对禁止在业务逻辑中使用 `unwrap()` 或 `expect()`**。
-    - 仅允许在 `tests/`, `examples/`, 或 `bin/` 的初始化阶段（无法恢复的启动错误）使用。
-    - 业务代码必须使用 `match`, `if let`, 或 `?` 传播 `Result`。
-- **避免 Panic**：任何可能 Panic 的操作（如数组索引 `arr[i]`）都应使用安全版本（如 `arr.get(i)`）。
-
-### 1.2 错误处理 (Error Handling)
-- 使用 `thiserror` 定义库/模块级别的错误枚举。
-- 使用 `anyhow` 处理顶层应用（Application）的错误传播。
-- **Axum Handler** 必须返回实现了 `IntoResponse` 的 Result 类型（通常自定义 `AppError`）。
-
-### 1.3 异步规范 (Async)
-- 避免在异步上下文中执行阻塞操作（如标准 `std::fs` 或大量 CPU 计算）。
-- 使用 `tokio::fs` 替代 `std::fs`。
-- 长时间计算任务使用 `tokio::task::spawn_blocking`。
-
----
-
-## 2. 代码风格与命名 (Style & Naming)
-
-遵循 `rustfmt` 默认配置。
-
-- **Types (Structs, Enums, Traits)**: `PascalCase`
-- **Functions, Methods, Variables, Modules**: `snake_case`
-- **Constants, Statics**: `SCREAMING_SNAKE_CASE`
-- **File Names**: `snake_case.rs`
-
----
-
-## 3. 目录结构规范 (Directory Structure)
-
-```
-backend/
-  src/
-    bin/              # 独立可执行文件（工具脚本）
-    routes/           # Axum 路由处理函数 (Handlers)
-      mod.rs          # 路由注册
-      users.rs        # 用户模块路由
-    models/           # 数据模型 (Structs) & DB 映射
-    services/         # 业务逻辑层 (可选，复杂逻辑从 routes 剥离)
-    utils/            # 通用工具函数
-    main.rs           # 应用入口，仅包含启动配置
-```
-
-- **Routes**: 负责 HTTP 解析、参数校验、调用 Service/Model、返回响应。
-- **Services/Models**: 负责核心业务逻辑和数据持久化，不应依赖 HTTP 层细节。
-
----
-
-## 4. 最佳实践 (Best Practices)
-
-### 4.1 SQLx 使用
-- 优先使用 `sqlx::query_as!` 宏进行编译时 SQL 检查。
-- 如果必须使用动态 SQL，确保使用参数化查询 (`bind`) 防止注入。
-- 数据库模型 Struct 字段应与 DB 列名一致，或使用 `#[sqlx(rename = "...")]`。
-
-### 4.2 Axum Handler
-- 保持 Handler 瘦身：如果逻辑超过 50 行，考虑提取到 Service 层或独立函数。
-- 使用 `State` 抽取共享状态（如 DB Pool）。
-
-### 4.3 日志 (Logging)
-- 使用 `tracing` 而非 `println!`。
-- 关键业务路径必须有 `info!` 日志。
-- 错误分支必须有 `error!` 日志，包含上下文信息。
-
----
-
-## 5. 工具链配置 (Tooling)
-
-所有 Rust 项目必须包含以下配置：
-
-### 5.1 工具初始化（必须）
-
-在开始开发前，必须运行工具初始化：
-- 通过 AI 命令："初始化工具" 或 "设置开发工具"
-- 通过 CLI 命令：`aodw-skill init-tools`
-
-工具初始化会自动：
-- 检测 rustfmt、clippy、cargo 是否已安装
-- 从模板生成 `rustfmt.toml` 和 `clippy.toml` 配置文件
-- 配置 pre-commit hooks（如果使用）
-
-### 5.2 配置文件
-
-**rustfmt.toml**（从模板生成）：
-- 模板位置：`.aodw-next/templates/tools-config/backend/rustfmt.config.template.toml`
-- 生成位置：项目根目录 `rustfmt.toml`
-- 主要配置：
-  ```toml
-  edition = "2021"
-  max_width = 100
-  use_small_heuristics = "Max"
-  ```
-
-**clippy.toml**（从模板生成）：
-- 模板位置：`.aodw-next/templates/tools-config/backend/clippy.config.template.toml`
-- 生成位置：项目根目录 `clippy.toml` 或 `Cargo.toml` 的 `[lints.clippy]` 部分
-- 主要配置：
-  - 零警告策略：`warn = "all"`, `deny = ["warnings"]`
-  - 复杂度限制：`cognitive-complexity-threshold = 15`（见模板 `clippy.config.template.toml`）
-  - 文件长度限制：`too_many_lines_threshold = 400`
-
-### 5.3 提交前检查（必须）
-
-所有代码提交前必须通过以下检查：
-- `cargo fmt -- --check`（代码格式化检查）
-- `cargo clippy -- -D warnings`（零警告策略）
-- `cargo test`（单元测试）
-
-这些检查应配置在 pre-commit hooks 中，确保提交前自动执行。
-
----
-
-## 6. 代码质量指标 (Metrics)
-
-- **函数长度**: 软限制 60 行。超过则拆分。
-- **文件长度**: 软限制 400 行。
-- **复杂度**: 单个函数 Cyclomatic Complexity < 15。

package/.aodw-next/06-project/README.md

@@ -1,16 +0,0 @@
-# 06-project 目录
-
-本目录用于存放项目级别的用户生成文件，初始为空。
-
-## 文件说明
-
-运行 `aodw-skill init-overview` 后，本目录会自动生成以下文件：
-
-- `ai-overview.md` - 项目概览文档（技术栈、架构、模块职责等）
-- `modules-index.yaml` - 模块索引文件（映射代码目录到模块文档）
-
-## 注意事项
-
-- 这些文件是**用户生成内容**，更新 AODW-Next 时会被保护，不会被覆盖
-- 模板文件位于 `../templates/` 目录下
-- AI 修改代码前会读取这些文件来理解项目结构

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 个月+）：
-   - 规则文件精简
-   - 智能加载系统
-   - 性能监控和优化
-