@rdmind/rdmind 0.0.9-alpha.0 → 0.0.9-alpha.2

package/.knowledge/.ext/.bmad-core/tasks/trace-requirements.md

@@ -0,0 +1,266 @@
+<!-- Powered by BMAD™ Core -->
+
+# trace-requirements
+
+Map story requirements to test cases using Given-When-Then patterns for comprehensive traceability.
+
+## Purpose
+
+Create a requirements traceability matrix that ensures every acceptance criterion has corresponding test coverage. This task helps identify gaps in testing and ensures all requirements are validated.
+
+**IMPORTANT**: Given-When-Then is used here for documenting the mapping between requirements and tests, NOT for writing the actual test code. Tests should follow your project's testing standards (no BDD syntax in test code).
+
+## Prerequisites
+
+- Story file with clear acceptance criteria
+- Access to test files or test specifications
+- Understanding of the implementation
+
+## Traceability Process
+
+### 1. Extract Requirements
+
+Identify all testable requirements from:
+
+- Acceptance Criteria (primary source)
+- User story statement
+- Tasks/subtasks with specific behaviors
+- Non-functional requirements mentioned
+- Edge cases documented
+
+### 2. Map to Test Cases
+
+For each requirement, document which tests validate it. Use Given-When-Then to describe what the test validates (not how it's written):
+
+```yaml
+requirement: 'AC1: User can login with valid credentials'
+test_mappings:
+  - test_file: 'auth/login.test.ts'
+    test_case: 'should successfully login with valid email and password'
+    # Given-When-Then describes WHAT the test validates, not HOW it's coded
+    given: 'A registered user with valid credentials'
+    when: 'They submit the login form'
+    then: 'They are redirected to dashboard and session is created'
+    coverage: full
+
+  - test_file: 'e2e/auth-flow.test.ts'
+    test_case: 'complete login flow'
+    given: 'User on login page'
+    when: 'Entering valid credentials and submitting'
+    then: 'Dashboard loads with user data'
+    coverage: integration
+```
+
+### 3. Coverage Analysis
+
+Evaluate coverage for each requirement:
+
+**Coverage Levels:**
+
+- `full`: Requirement completely tested
+- `partial`: Some aspects tested, gaps exist
+- `none`: No test coverage found
+- `integration`: Covered in integration/e2e tests only
+- `unit`: Covered in unit tests only
+
+### 4. Gap Identification
+
+Document any gaps found:
+
+```yaml
+coverage_gaps:
+  - requirement: 'AC3: Password reset email sent within 60 seconds'
+    gap: 'No test for email delivery timing'
+    severity: medium
+    suggested_test:
+      type: integration
+      description: 'Test email service SLA compliance'
+
+  - requirement: 'AC5: Support 1000 concurrent users'
+    gap: 'No load testing implemented'
+    severity: high
+    suggested_test:
+      type: performance
+      description: 'Load test with 1000 concurrent connections'
+```
+
+## Outputs
+
+### Output 1: Gate YAML Block
+
+**Generate for pasting into gate file under `trace`:**
+
+```yaml
+trace:
+  totals:
+    requirements: X
+    full: Y
+    partial: Z
+    none: W
+  planning_ref: 'qa.qaLocation/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md'
+  uncovered:
+    - ac: 'AC3'
+      reason: 'No test found for password reset timing'
+  notes: 'See qa.qaLocation/assessments/{epic}.{story}-trace-{YYYYMMDD}.md'
+```
+
+### Output 2: Traceability Report
+
+**Save to:** `qa.qaLocation/assessments/{epic}.{story}-trace-{YYYYMMDD}.md`
+
+Create a traceability report with:
+
+```markdown
+# Requirements Traceability Matrix
+
+## Story: {epic}.{story} - {title}
+
+### Coverage Summary
+
+- Total Requirements: X
+- Fully Covered: Y (Z%)
+- Partially Covered: A (B%)
+- Not Covered: C (D%)
+
+### Requirement Mappings
+
+#### AC1: {Acceptance Criterion 1}
+
+**Coverage: FULL**
+
+Given-When-Then Mappings:
+
+- **Unit Test**: `auth.service.test.ts::validateCredentials`
+  - Given: Valid user credentials
+  - When: Validation method called
+  - Then: Returns true with user object
+
+- **Integration Test**: `auth.integration.test.ts::loginFlow`
+  - Given: User with valid account
+  - When: Login API called
+  - Then: JWT token returned and session created
+
+#### AC2: {Acceptance Criterion 2}
+
+**Coverage: PARTIAL**
+
+[Continue for all ACs...]
+
+### Critical Gaps
+
+1. **Performance Requirements**
+   - Gap: No load testing for concurrent users
+   - Risk: High - Could fail under production load
+   - Action: Implement load tests using k6 or similar
+
+2. **Security Requirements**
+   - Gap: Rate limiting not tested
+   - Risk: Medium - Potential DoS vulnerability
+   - Action: Add rate limit tests to integration suite
+
+### Test Design Recommendations
+
+Based on gaps identified, recommend:
+
+1. Additional test scenarios needed
+2. Test types to implement (unit/integration/e2e/performance)
+3. Test data requirements
+4. Mock/stub strategies
+
+### Risk Assessment
+
+- **High Risk**: Requirements with no coverage
+- **Medium Risk**: Requirements with only partial coverage
+- **Low Risk**: Requirements with full unit + integration coverage
+```
+
+## Traceability Best Practices
+
+### Given-When-Then for Mapping (Not Test Code)
+
+Use Given-When-Then to document what each test validates:
+
+**Given**: The initial context the test sets up
+
+- What state/data the test prepares
+- User context being simulated
+- System preconditions
+
+**When**: The action the test performs
+
+- What the test executes
+- API calls or user actions tested
+- Events triggered
+
+**Then**: What the test asserts
+
+- Expected outcomes verified
+- State changes checked
+- Values validated
+
+**Note**: This is for documentation only. Actual test code follows your project's standards (e.g., describe/it blocks, no BDD syntax).
+
+### Coverage Priority
+
+Prioritize coverage based on:
+
+1. Critical business flows
+2. Security-related requirements
+3. Data integrity requirements
+4. User-facing features
+5. Performance SLAs
+
+### Test Granularity
+
+Map at appropriate levels:
+
+- Unit tests for business logic
+- Integration tests for component interaction
+- E2E tests for user journeys
+- Performance tests for NFRs
+
+## Quality Indicators
+
+Good traceability shows:
+
+- Every AC has at least one test
+- Critical paths have multiple test levels
+- Edge cases are explicitly covered
+- NFRs have appropriate test types
+- Clear Given-When-Then for each test
+
+## Red Flags
+
+Watch for:
+
+- ACs with no test coverage
+- Tests that don't map to requirements
+- Vague test descriptions
+- Missing edge case coverage
+- NFRs without specific tests
+
+## Integration with Gates
+
+This traceability feeds into quality gates:
+
+- Critical gaps → FAIL
+- Minor gaps → CONCERNS
+- Missing P0 tests from test-design → CONCERNS
+
+### Output 3: Story Hook Line
+
+**Print this line for review task to quote:**
+
+```text
+Trace matrix: qa.qaLocation/assessments/{epic}.{story}-trace-{YYYYMMDD}.md
+```
+
+- Full coverage → PASS contribution
+
+## Key Principles
+
+- Every requirement must be testable
+- Use Given-When-Then for clarity
+- Identify both presence and absence
+- Prioritize based on risk
+- Make recommendations actionable

package/.knowledge/.ext/.bmad-core/tasks/validate-next-story.md

@@ -0,0 +1,136 @@
+<!-- Powered by BMAD™ Core -->
+
+# 验证下一个 Story 任务
+
+## 目的
+
+在开始实现之前全面验证 story 草稿，确保它完整、准确，并为成功开发提供足够的上下文。这个任务识别需要解决的问题和缺口，防止幻觉并确保实现就绪。
+
+## 顺序任务执行 (当前任务完成前别继续)
+
+### 0. 加载核心配置和输入
+
+- 加载 `.bmad-core/core-config.yaml`
+- 如果文件不存在，停下来告诉用户："找不到 core-config.yaml。这个文件是 story 验证必需的。"
+- 提取关键配置：`devStoryLocation`、`prd.*`、`architecture.*`
+- 识别并加载以下输入：
+  - **Story 文件**：要验证的 story 草稿 (用户提供或在 `devStoryLocation` 中发现)
+  - **父 epic**：包含这个 story 需求的 epic
+  - **架构文档**：基于配置 (分片或单体)
+  - **Story 模板**：`bmad-core/templates/story-tmpl.md` 用于完整性验证
+
+### 1. 模板完整性验证
+
+- 加载 `.bmad-core/templates/story-tmpl.yaml` 并从模板中提取所有章节标题
+- **缺失章节检查**：把 story 章节和模板章节对比，验证所有必需章节都存在
+- **占位符验证**：确保没有模板占位符没填写 (比如 `{{EpicNum}}`、`{{role}}`、`_TBD_`)
+- **代理章节验证**：确认模板中的所有章节都存在，供未来代理用
+- **结构合规性**：验证 story 遵循模板结构和格式
+
+### 2. 文件结构和源码树验证
+
+- **文件路径清晰度**：要创建/修改的新/现有文件是否明确指定？
+- **源码树相关性**：Dev Notes 中是否包含相关项目结构？
+- **目录结构**：新目录/组件是否根据项目结构正确定位？
+- **文件创建顺序**：任务是否按逻辑顺序指定文件应该在哪里创建？
+- **路径准确性**：文件路径是否与架构文档中的项目结构一致？
+
+### 3. UI/前端完整性验证 (如果适用)
+
+- **组件规范**：UI 组件是否足够详细以便实现？
+- **样式/设计指导**：视觉实现指导是否清晰？
+- **用户交互流程**：UX 模式和行为是否已指定？
+- **响应式/可访问性**：如果需要，这些考虑是否已解决？
+- **集成点**：前端-后端集成点是否清晰？
+
+### 4. 验收标准满足度评估
+
+- **AC 覆盖度**：列出的任务是否能满足所有验收标准？
+- **AC 可测试性**：验收标准是否可测量和可验证？
+- **缺失场景**：边界情况或错误条件是否已覆盖？
+- **成功定义**：每个 AC 的"完成"是否明确定义？
+- **任务-AC 映射**：任务是否正确链接到特定验收标准？
+
+### 5. 验证和测试指令审查
+
+- **测试方法清晰度**：测试方法是否明确指定？
+- **测试场景**：关键测试用例是否已识别？
+- **验证步骤**：验收标准验证步骤是否清晰？
+- **测试工具/框架**：所需测试工具是否已指定？
+- **测试数据需求**：测试数据需求是否已识别？
+
+### 6. 安全考虑评估 (如果适用)
+
+- **安全需求**：安全需求是否已识别和解决？
+- **认证/授权**：访问控制是否已指定？
+- **数据保护**：敏感数据处理需求是否清晰？
+- **漏洞预防**：常见安全问题是否已解决？
+- **合规要求**：监管/合规需求是否已解决？
+
+### 7. 任务/子任务序列验证
+
+- **逻辑顺序**：任务是否遵循正确的实现顺序？
+- **依赖关系**：任务依赖关系是否清晰正确？
+- **粒度**：任务大小是否合适且可执行？
+- **完整性**：任务是否覆盖所有需求和验收标准？
+- **阻塞问题**：是否有任务会阻塞其他任务？
+
+### 8. 反幻觉验证
+
+- **来源验证**：每个技术声明都必须可追溯到源文档
+- **架构对齐**：Dev Notes 内容与架构规范匹配
+- **无虚构细节**：标记任何不被源文档支持的技术决策
+- **引用准确性**：验证所有源引用都正确且可访问
+- **事实检查**：把声明与 epic 和架构文档交叉引用
+
+### 9. Dev Agent 实现就绪性
+
+- **自包含上下文**：story 是否可以在不读外部文档的情况下实现？
+- **清晰指令**：实现步骤是否明确？
+- **完整技术上下文**：Dev Notes 中是否包含所有必需的技术细节？
+- **缺失信息**：识别任何关键信息缺口
+- **可执行性**：所有任务是否对开发代理可执行？
+
+### 10. 生成验证报告
+
+提供结构化验证报告，包括：
+
+#### 模板合规性问题
+
+- story 模板中缺失的章节
+- 没填写的占位符或模板变量
+- 结构格式问题
+
+#### 关键问题 (必须修复 - Story 被阻塞)
+
+- 实现缺失的关键信息
+- 不准确或不可验证的技术声明
+- 验收标准覆盖不完整
+- 缺失必需章节
+
+#### 应该修复的问题 (重要质量改进)
+
+- 实现指导不清晰
+- 缺失安全考虑
+- 任务排序问题
+- 测试指令不完整
+
+#### 锦上添花的改进 (可选增强)
+
+- 有助于实现的额外上下文
+- 能提高效率的澄清
+- 文档改进
+
+#### 反幻觉发现
+
+- 不可验证的技术声明
+- 缺失源引用
+- 与架构文档不一致
+- 虚构的库、模式或标准
+
+#### 最终评估
+
+- **GO**：Story 已准备好实现
+- **NO-GO**：Story 在实现前需要修复
+- **实现就绪评分**：1-10 分制
+- **置信度**：成功实现的高/中/低置信度

package/.knowledge/.ext/.bmad-core/tasks/validate-trd.md

@@ -0,0 +1,158 @@
+<!-- Powered by BMAD™ Core -->
+
+# 验证TRD文档任务
+
+## ⚠️ 重要提醒 ⚠️
+
+**这是个可执行的工作流程，不是参考文档**
+
+用这个任务时：
+
+1. **必须全面验证** - 检查TRD文档的各个方面
+2. **必须提供具体建议** - 不只是指出问题，还要提供改进建议
+3. **必须确保可执行性** - 验证技术需求是否可以被开发团队执行
+
+## 任务目标
+
+验证TRD文档的完整性、一致性、可行性和清晰性，确保技术团队能够基于TRD进行开发。
+
+## 输入要求
+
+- TRD文档路径
+- 原始PRD文档路径（可选，用于对比验证）
+
+## 输出产物
+
+- 验证报告
+- 改进建议列表
+- 更新后的TRD文档（如果需要）
+
+## 验证维度
+
+### 1. 完整性验证
+
+- **功能需求覆盖**：检查是否所有PRD功能需求都被转化为技术需求
+- **非功能需求覆盖**：检查是否所有PRD非功能需求都被转化为技术指标
+- **技术规格完整**：检查系统架构、技术栈、API规格、数据库设计是否完整
+- **实现指导完整**：检查开发标准、测试要求、部署要求是否明确
+
+### 2. 一致性验证
+
+- **需求一致性**：检查技术需求与业务需求是否保持一致
+- **技术一致性**：检查技术栈选择是否一致，是否存在冲突
+- **接口一致性**：检查API设计是否一致，数据格式是否统一
+- **架构一致性**：检查系统架构设计是否内部一致
+
+### 3. 可行性验证
+
+- **技术可行性**：检查技术方案是否在技术上可行
+- **资源可行性**：检查技术需求是否在资源约束内可实现
+- **时间可行性**：检查技术需求是否在时间约束内可实现
+- **团队可行性**：检查技术需求是否在团队能力范围内
+
+### 4. 清晰性验证
+
+- **需求描述清晰**：检查技术需求描述是否清晰明确
+- **实现指导清晰**：检查实现指导是否具体可操作
+- **接口规格清晰**：检查API规格是否详细明确
+- **数据结构清晰**：检查数据库设计是否清晰完整
+
+## 执行步骤
+
+### 步骤1：文档结构检查
+
+1. **章节完整性**：检查TRD文档是否包含所有必要章节
+2. **内容完整性**：检查每个章节的内容是否完整
+3. **格式规范性**：检查文档格式是否符合规范
+
+### 步骤2：需求映射验证
+
+1. **PRD到TRD映射**：验证PRD中的每个需求是否都在TRD中有对应
+2. **需求粒度检查**：检查技术需求的粒度是否合适
+3. **需求优先级**：检查需求优先级是否合理
+
+### 步骤3：技术方案验证
+
+1. **架构合理性**：验证系统架构设计是否合理
+2. **技术栈选择**：验证技术栈选择是否合适
+3. **性能指标**：验证性能指标是否合理可实现
+4. **安全要求**：验证安全要求是否完整可实现
+
+### 步骤4：实现指导验证
+
+1. **开发标准**：检查开发标准是否明确可执行
+2. **测试策略**：检查测试策略是否完整
+3. **部署方案**：检查部署方案是否可行
+4. **运维要求**：检查运维要求是否明确
+
+### 步骤5：不确定项检查
+
+1. **待确认事项**：检查待确认事项是否合理
+2. **风险评估**：评估不确定项对项目的影响
+3. **解决建议**：为不确定项提供解决建议
+
+## 验证报告格式
+
+### 验证摘要
+
+- 总体评估结果
+- 主要问题数量
+- 改进建议数量
+
+### 详细验证结果
+
+- 按验证维度列出发现的问题
+- 每个问题包含：问题描述、影响分析、改进建议
+- 按严重程度分类（严重、中等、轻微）
+
+### 改进建议
+
+- 立即需要解决的问题
+- 建议改进的方面
+- 可选的优化建议
+
+## 交互要求
+
+当遇到以下情况时，需要与用户交互：
+
+1. **严重问题发现**：发现可能影响项目成功的严重问题
+2. **技术方案冲突**：发现技术方案之间的冲突
+3. **资源约束问题**：发现超出资源约束的技术需求
+4. **不确定项过多**：发现过多的不确定项需要澄清
+
+## 质量标准
+
+### 通过标准
+
+- 所有严重问题都已解决
+- 技术需求完整且可执行
+- 不确定项数量在可接受范围内
+- 文档结构清晰完整
+
+### 不通过标准
+
+- 存在严重的技术可行性问题
+- 关键功能需求缺失
+- 技术方案存在重大冲突
+- 不确定项过多影响开发
+
+## 输出建议
+
+### 验证通过
+
+- 提供验证报告
+- 给出少量优化建议
+- 确认TRD可以用于开发
+
+### 验证不通过
+
+- 提供详细问题列表
+- 给出具体改进建议
+- 建议重新分析PRD或补充信息
+
+## 注意事项
+
+1. **客观评估**：基于技术标准客观评估，不受个人偏好影响
+2. **实用导向**：关注实际开发中的可执行性
+3. **风险识别**：主动识别可能的技术风险和挑战
+4. **持续改进**：提供建设性的改进建议