aodw-skill 0.7.3

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

@@ -0,0 +1,232 @@
+# 需求阶段审计报告：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/templates/changelog-template.md

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

package/.aodw/templates/checklists/coding-standards-template.md

@@ -0,0 +1,110 @@
+# 编码规范验收清单
+
+> **注意**：本清单用于检查代码是否符合项目编码规范（`.aodw/03-standards/stacks/react-typescript/ai-coding-rules-frontend.md` 和 `.aodw/03-standards/stacks/python-fastapi/ai-coding-rules-backend.md`）。
+
+---
+
+## 前端编码规范验收（如涉及）
+
+### 工具检查
+- [ ] ESLint 检查全部通过（`npm run lint` 或 `npx eslint .`）
+- [ ] Prettier 格式化已运行（`npm run format` 或 `npx prettier --write .`）
+- [ ] 工具初始化状态正常（检查 `.aodw/tools-status.yaml`）
+
+### 目录结构检查
+- [ ] 目录结构符合规范（pages / features / shared）
+- [ ] 页面放在 `src/pages/<PageName>/` 下
+- [ ] 可复用业务逻辑放在 `src/features/<domain>/` 下
+- [ ] 通用组件/hooks/工具放在 `src/shared/` 下
+- [ ] 依赖关系符合规范（pages → features/shared, features → shared）
+
+### 代码质量检查
+- [ ] 文件大小符合规范：
+  - [ ] 页面入口组件（index.tsx）≤ 300 行
+  - [ ] 普通组件/hooks/store 文件 ≤ 200 行
+- [ ] 函数大小符合规范：
+  - [ ] 单个函数 ≤ 60 行
+- [ ] 复杂度符合规范：
+  - [ ] 复杂度 ≤ 10
+
+### TypeScript 规范检查
+- [ ] 是否启用严格模式
+- [ ] 是否避免使用 any
+- [ ] API 层是否使用 DTO 类型和 Response 类型
+
+### React 编码规范检查
+- [ ] 是否使用函数组件 + Hooks
+- [ ] 数据请求是否封装在 features/*/api 或页面专用 hooks
+- [ ] 是否不在组件中直接调用 fetch/axios
+
+---
+
+## 后端编码规范验收（如涉及）
+
+### 依赖管理检查
+- [ ] 使用 `uv + pip-tools` 管理依赖
+- [ ] 存在 `requirements.in` 和 `requirements-dev.in` 文件
+- [ ] 只编辑 `.in` 文件，不直接编辑 `.txt` 文件
+- [ ] 添加依赖时使用版本约束（如 `package>=1.0.0,<2.0.0`）
+- [ ] 通过 `make compile-deps && make sync` 更新依赖
+
+### 工具检查
+- [ ] Ruff 检查全部通过（`ruff check .`）
+- [ ] Black 格式化已运行（`black .`）
+- [ ] pre-commit hooks 已安装（如适用）
+- [ ] 工具初始化状态正常（检查 `.aodw/tools-status.yaml`）
+
+### 分层架构检查
+- [ ] 分层架构符合规范（api → services → repositories）
+- [ ] API 层未直接导入 models（如适用）
+- [ ] Services 层未直接导入 api
+- [ ] 依赖关系符合规范（不跨层调用）
+
+### 代码质量检查
+- [ ] 文件大小符合规范：
+  - [ ] Python 模块 ≤ 300 行（Ruff 自动检查）
+- [ ] 函数大小符合规范：
+  - [ ] 单个函数 ≤ 60 行（Ruff PLR0915 自动拦截）
+- [ ] 复杂度符合规范：
+  - [ ] 复杂度 ≤ 10（Ruff PLR 规则自动检查）
+
+### API 设计检查
+- [ ] API 端点是否符合 RESTful 规范
+- [ ] 请求/响应格式是否统一
+- [ ] 错误处理是否完善
+
+### 安全检查
+- [ ] 输入数据是否已验证
+- [ ] 是否防止 SQL 注入、XSS 等安全漏洞
+- [ ] 认证和授权是否正确实现
+
+---
+
+## 通用编码规范验收
+
+### 文件大小检查
+- [ ] 文件大小符合规范（参考 `.aodw/03-standards/ai-coding-rules-common.md`）
+
+### 函数/方法长度检查
+- [ ] 函数/方法长度符合规范
+
+### 复杂度检查
+- [ ] 复杂度符合规范
+
+### 命名规范检查
+- [ ] 命名规范符合要求（参考具体编码规范文件）
+
+---
+
+## 验收结果
+
+- [ ] 所有检查项已通过
+- [ ] 如有未通过项，已记录原因并说明：
+  - 未通过项：
+  - 原因说明：
+  - 后续处理计划：
+
+---
+
+**验收人**：_________________  
+**验收日期**：_________________

package/.aodw/templates/csf-review-template.md

@@ -0,0 +1,201 @@
+# CSF Review: RT-XXX - <title>
+
+## 审查元数据
+- **审查时间**：YYYY-MM-DD HH:MM:SS
+- **审查阶段**：Decision / Spec-Plan / Implementation / Verification
+- **审查类型**：快速审查 / 深度审查
+- **审查人**：AI + 用户（如参与）
+- **RT 状态**：created / intaking / decided / in-progress / reviewing
+
+---
+
+## 1. 以终为始检查（Begin with the End）
+
+### 1.1 目标定义
+- **明确目标**：[用一句话描述本 RT 的目标]
+- **当前现状**：[描述当前存在的问题/痛点/缺失]
+- **期望状态**：[描述成功后的期望状态]
+- **差距分析**：[现状与期望的差距是什么？]
+
+### 1.2 目标贡献度评估
+- [ ] 当前工作是否直接贡献于缩小差距？
+- [ ] 是否存在无效工作？（不贡献于目标的工作）
+  - 无效工作列表：[如有，列出]
+- [ ] 目标是否可衡量？（有明确的成功标准）
+
+### 1.3 发现与建议
+- **关键发现**：[记录发现的问题]
+- **改进建议**：[如有无效工作，建议如何调整]
+
+---
+
+## 2. 结构化分解检查（Structured Decomposition）
+
+### 2.1 分解结构
+- **静态分解**（组成部分）：
+  ```
+  [用树状图或列表展示组成部分]
+  ```
+
+- **动态分解**（流程步骤）：
+  ```
+  [用流程图或列表展示流程步骤]
+  ```
+
+### 2.2 MECE 验证
+- [ ] 分解是否符合 MECE 原则？（不重不漏）
+- [ ] 分解粒度是否合适？（不过细也不过粗）
+- [ ] 子目标/子模块之间是否存在重叠？
+- [ ] 是否存在遗漏的关键部分？
+
+### 2.3 依赖关系
+- **依赖关系图**：[描述或绘制依赖关系]
+- **关键依赖**：[标注关键依赖，如存在单点故障]
+
+### 2.4 发现与建议
+- **关键发现**：[记录发现的问题]
+- **改进建议**：[如有 MECE 问题或依赖问题，建议如何调整]
+
+---
+
+## 3. 关键要素识别检查（Identify CSFs）
+
+### 3.1 关键成功要素（CSF）清单
+| 优先级 | CSF 描述 | 影响程度 | 当前状态 |
+|--------|----------|----------|----------|
+| P0     | [CSF 1]  | 高/中/低 | 已识别/未识别 |
+| P1     | [CSF 2]  | 高/中/低 | 已识别/未识别 |
+| P2     | [CSF 3]  | 高/中/低 | 已识别/未识别 |
+
+### 3.2 关键控制变量
+- **控制变量列表**：[列出可以影响结果的关键变量]
+- **变量影响分析**：[分析各变量的影响程度]
+
+### 3.3 瓶颈识别
+- **瓶颈点列表**：[列出限制目标达成的关键点]
+- **瓶颈影响分析**：[分析各瓶颈的影响程度]
+
+### 3.4 资源分配评估
+- [ ] 是否聚焦于 CSF？（而非平均分配资源）
+- [ ] 关键控制变量是否已识别并监控？
+- [ ] 瓶颈点是否有缓解策略？
+
+### 3.5 发现与建议
+- **关键发现**：[记录发现的问题]
+- **改进建议**：[如有资源分配问题，建议如何调整]
+
+---
+
+## 4. 流程与系统观检查（Process & Systems View）
+
+### 4.1 端到端流程分析
+- **流程图**：[描述或引用端到端流程图]
+- **关键路径**：[标注从触发到完成的关键路径]
+- **路径长度**：[估算关键路径的时间/复杂度]
+
+### 4.2 瓶颈识别
+- **流程瓶颈**：[标注流程中的瓶颈点]
+- **瓶颈影响**：[分析瓶颈对整体流程的影响]
+
+### 4.3 系统交互分析
+- **组件交互图**：[描述系统各组件之间的交互]
+- **单点故障**：[识别是否存在单点故障]
+- **上下游影响**：[分析对上下游系统的影响]
+
+### 4.4 发现与建议
+- **关键发现**：[记录发现的问题]
+- **改进建议**：[如有流程或系统问题，建议如何调整]
+
+---
+
+## 5. 多维决策检查（Multi-dimensional Decision）
+
+### 5.1 评估维度
+- **维度列表**：[列出评估维度，如：性能、成本、复杂度、可维护性、风险、时间等]
+
+### 5.2 评估矩阵
+| 方案 | 维度1 | 维度2 | 维度3 | 维度4 | 维度5 | 总分 | 排名 |
+|------|-------|-------|-------|-------|-------|------|------|
+| 方案A | 评分 | 评分 | 评分 | 评分 | 评分 | 总分 | 1    |
+| 方案B | 评分 | 评分 | 评分 | 评分 | 评分 | 总分 | 2    |
+| 方案C | 评分 | 评分 | 评分 | 评分 | 评分 | 总分 | 3    |
+
+**权重说明**：[说明各维度的权重分配理由]
+
+### 5.3 决策标准
+- **决策标准**：[明确说明决策标准]
+- **最终决策**：[记录最终选择的方案]
+- **决策理由**：[说明选择该方案的理由]
+
+### 5.4 备选方案评估
+- [ ] 备选方案是否充分？
+- [ ] 是否进行了多维度评估？（而非非黑即白）
+- [ ] 各维度权重是否合理？
+
+### 5.5 发现与建议
+- **关键发现**：[记录发现的问题]
+- **改进建议**：[如有决策问题，建议如何调整]
+
+---
+
+## 6. 综合评估
+
+### 6.1 关键发现总结
+1. [发现 1]
+2. [发现 2]
+3. [发现 3]
+
+### 6.2 风险点识别
+| 风险 | 影响程度 | 可能性 | 缓解策略 |
+|------|----------|--------|----------|
+| 风险1 | 高/中/低 | 高/中/低 | [缓解策略] |
+| 风险2 | 高/中/低 | 高/中/低 | [缓解策略] |
+
+### 6.3 改进建议
+1. [建议 1]
+2. [建议 2]
+3. [建议 3]
+
+### 6.4 审查结论
+- [ ] **通过**：当前方向正确，可以继续
+- [ ] **有条件通过**：需要调整后继续
+- [ ] **不通过**：需要重新审视方向
+
+**结论说明**：[说明审查结论的理由]
+
+---
+
+## 7. 后续行动
+
+### 7.1 需要调整的方向
+- [ ] [调整项 1]
+- [ ] [调整项 2]
+
+### 7.2 需要补充的工作
+- [ ] [补充项 1]
+- [ ] [补充项 2]
+
+### 7.3 需要用户确认的事项
+- [ ] [确认项 1]
+- [ ] [确认项 2]
+
+### 7.4 下次审查计划
+- **下次审查时间**：[如需要，计划下次审查时间]
+- **审查重点**：[如需要，说明下次审查的重点]
+
+---
+
+## 8. 审查记录
+
+### 8.1 审查过程
+- **审查步骤**：[记录审查的执行步骤]
+- **审查耗时**：[记录审查耗时]
+
+### 8.2 用户反馈
+- **用户意见**：[记录用户的反馈意见]
+- **用户决策**：[记录用户的最终决策]
+
+### 8.3 审查历史
+- **上次审查时间**：[如有，记录上次审查时间]
+- **上次审查结论**：[如有，记录上次审查结论]
+- **本次改进**：[如有，说明本次相比上次的改进]

package/.aodw/templates/impact-template.md

@@ -0,0 +1,17 @@
+# Impact Analysis: RT-XXX - <short title>
+
+## 1. 问题触发点（Trigger）
+- 描述用户或系统如何触发问题：
+
+## 2. 直接影响（Direct Impact）
+- 受影响的模块 / 文件：
+- 直接受影响的行为：
+
+## 3. 间接影响（Indirect Impact）
+- 可能受影响的上下游模块 / 功能：
+
+## 4. 风险评估（Risk Evaluation）
+- 数据风险：
+- 安全风险：
+- 性能风险：
+- 用户体验风险：

package/.aodw/templates/invariants-template.md

@@ -0,0 +1,12 @@
+# Invariants: RT-XXX - <short title>
+
+> 本文件列出在本次改动中必须保持不变的行为与约束。
+
+## 1. 业务行为 Invariants
+- 不改变的业务规则：
+
+## 2. 接口 Invariants
+- 不改变的 API 路径 / 请求 / 响应格式：
+
+## 3. 技术结构 Invariants
+- 不允许破坏的工程结构约束（如不得跨层访问）：

package/.aodw/templates/module-readme-template.md

@@ -0,0 +1,39 @@
+---
+module: <module-key>
+files:
+  - <path/glob/to/code>
+related_rts: []
+---
+
+# <模块名称>
+
+## 1. 职责（Responsibilities）
+- 核心职责：
+- 解决的问题域：
+
+## 2. 目录映射（Files / Mapping）
+- 关键文件 / 目录：
+  - <path 1>
+  - <path 2>
+- 如有需要，补充 frontmatter 中的 files 列表，保持与实际代码路径一致。
+
+## 3. 不可破坏原则（Invariants）
+- 业务行为：
+- API / 接口：
+- 数据结构与存储：
+- 性能 / 安全约束：
+
+## 4. 依赖关系（Dependencies）
+### 上游（依赖的模块 / 服务）
+- <module-a>
+
+### 下游（被依赖的模块 / 服务）
+- <module-b>
+
+## 5. 常见流程（Workflows）
+- 典型流程 1：<描述关键步骤与入口/出口>
+- 典型流程 2：
+
+## 6. 历史记录（History / related_rts）
+- RT-XXX：<变更摘要>
+- RT-YYY：

package/.aodw/templates/plan-lite-template.md

@@ -0,0 +1,11 @@
+# Plan-Lite: RT-XXX - <short title>
+
+## 1. 修改点（Change Points）
+- 计划修改的文件 / 模块列表：
+
+## 2. 方案描述（Solution Outline）
+- 拟采取的技术方案：
+
+## 3. 风险与注意事项（Risks & Caveats）
+- 潜在风险：
+- 需要注意的边界情形：

package/.aodw/templates/rt-decision-template.md

@@ -0,0 +1,13 @@
+# RT Decision - RT-XXX
+
+## 1. 流程选择（Chosen Profile）
+- 选用：Spec-Full / Spec-Lite
+- AI 推荐理由：
+- 用户最终选择：
+
+## 2. 备选方案（Alternatives）
+- 其他可行流程及未采用原因：
+
+## 3. 分支与目录
+- 计划分支名：feature/RT-XXX-short-name
+- 目录：RT/RT-XXX/

package/.aodw/templates/rt-intake-template.md

@@ -0,0 +1,33 @@
+# RT Intake - RT-XXX
+
+## 1. 原始描述（Raw Description）
+- 用户原话：
+
+## 2. 类型与范围（Type & Scope）
+- 类型（Feature / Bug / Enhancement / Refactor / Research / Other）：
+- 预估影响范围：
+
+## 3. 初步模块猜测（Initial Modules）
+- 可能涉及的模块：
+
+## 4. 风险评估（Initial Risk）
+- 低 / 中 / 高，简要理由：
+
+## 5. AI 问题与用户回答摘要（Q&A Summary）
+- Q1: ...
+  - 用户回答：
+- Q2: ...
+  - 用户回答：
+
+## 6. 相关技术约束 / 规范（可选）
+> **注意**：AI 根据需求内容判断是否涉及前端/后端开发，如涉及则填写本节。
+
+- **是否涉及前端开发**？
+  - [ ] 是 → 参考 `.aodw/03-standards/stacks/react-typescript/ai-coding-rules-frontend.md`
+  - [ ] 否
+- **是否涉及后端开发**？
+  - [ ] 是 → 参考 `.aodw/03-standards/stacks/python-fastapi/ai-coding-rules-backend.md`
+  - [ ] 否
+- **技术栈要求**（如已知）：
+  - 前端：[React / Vue / Angular 等]
+  - 后端：[Python / Node.js / Go 等]