@rdmind/rdmind 0.0.9-alpha.1 → 0.0.9

package/.knowledge/.ext/.bmad-core/tasks/risk-profile.md

@@ -0,0 +1,355 @@
+<!-- Powered by BMAD™ Core -->
+
+# risk-profile
+
+Generate a comprehensive risk assessment matrix for a story implementation using probability × impact analysis.
+
+## Inputs
+
+```yaml
+required:
+  - story_id: '{epic}.{story}' # e.g., "1.3"
+  - story_path: 'docs/stories/{epic}.{story}.*.md'
+  - story_title: '{title}' # If missing, derive from story file H1
+  - story_slug: '{slug}' # If missing, derive from title (lowercase, hyphenated)
+```
+
+## Purpose
+
+Identify, assess, and prioritize risks in the story implementation. Provide risk mitigation strategies and testing focus areas based on risk levels.
+
+## Risk Assessment Framework
+
+### Risk Categories
+
+**Category Prefixes:**
+
+- `TECH`: Technical Risks
+- `SEC`: Security Risks
+- `PERF`: Performance Risks
+- `DATA`: Data Risks
+- `BUS`: Business Risks
+- `OPS`: Operational Risks
+
+1. **Technical Risks (TECH)**
+   - Architecture complexity
+   - Integration challenges
+   - Technical debt
+   - Scalability concerns
+   - System dependencies
+
+2. **Security Risks (SEC)**
+   - Authentication/authorization flaws
+   - Data exposure vulnerabilities
+   - Injection attacks
+   - Session management issues
+   - Cryptographic weaknesses
+
+3. **Performance Risks (PERF)**
+   - Response time degradation
+   - Throughput bottlenecks
+   - Resource exhaustion
+   - Database query optimization
+   - Caching failures
+
+4. **Data Risks (DATA)**
+   - Data loss potential
+   - Data corruption
+   - Privacy violations
+   - Compliance issues
+   - Backup/recovery gaps
+
+5. **Business Risks (BUS)**
+   - Feature doesn't meet user needs
+   - Revenue impact
+   - Reputation damage
+   - Regulatory non-compliance
+   - Market timing
+
+6. **Operational Risks (OPS)**
+   - Deployment failures
+   - Monitoring gaps
+   - Incident response readiness
+   - Documentation inadequacy
+   - Knowledge transfer issues
+
+## Risk Analysis Process
+
+### 1. Risk Identification
+
+For each category, identify specific risks:
+
+```yaml
+risk:
+  id: 'SEC-001' # Use prefixes: SEC, PERF, DATA, BUS, OPS, TECH
+  category: security
+  title: 'Insufficient input validation on user forms'
+  description: 'Form inputs not properly sanitized could lead to XSS attacks'
+  affected_components:
+    - 'UserRegistrationForm'
+    - 'ProfileUpdateForm'
+  detection_method: 'Code review revealed missing validation'
+```
+
+### 2. Risk Assessment
+
+Evaluate each risk using probability × impact:
+
+**Probability Levels:**
+
+- `High (3)`: Likely to occur (>70% chance)
+- `Medium (2)`: Possible occurrence (30-70% chance)
+- `Low (1)`: Unlikely to occur (<30% chance)
+
+**Impact Levels:**
+
+- `High (3)`: Severe consequences (data breach, system down, major financial loss)
+- `Medium (2)`: Moderate consequences (degraded performance, minor data issues)
+- `Low (1)`: Minor consequences (cosmetic issues, slight inconvenience)
+
+### Risk Score = Probability × Impact
+
+- 9: Critical Risk (Red)
+- 6: High Risk (Orange)
+- 4: Medium Risk (Yellow)
+- 2-3: Low Risk (Green)
+- 1: Minimal Risk (Blue)
+
+### 3. Risk Prioritization
+
+Create risk matrix:
+
+```markdown
+## Risk Matrix
+
+| Risk ID  | Description             | Probability | Impact     | Score | Priority |
+| -------- | ----------------------- | ----------- | ---------- | ----- | -------- |
+| SEC-001  | XSS vulnerability       | High (3)    | High (3)   | 9     | Critical |
+| PERF-001 | Slow query on dashboard | Medium (2)  | Medium (2) | 4     | Medium   |
+| DATA-001 | Backup failure          | Low (1)     | High (3)   | 3     | Low      |
+```
+
+### 4. Risk Mitigation Strategies
+
+For each identified risk, provide mitigation:
+
+```yaml
+mitigation:
+  risk_id: 'SEC-001'
+  strategy: 'preventive' # preventive|detective|corrective
+  actions:
+    - 'Implement input validation library (e.g., validator.js)'
+    - 'Add CSP headers to prevent XSS execution'
+    - 'Sanitize all user inputs before storage'
+    - 'Escape all outputs in templates'
+  testing_requirements:
+    - 'Security testing with OWASP ZAP'
+    - 'Manual penetration testing of forms'
+    - 'Unit tests for validation functions'
+  residual_risk: 'Low - Some zero-day vulnerabilities may remain'
+  owner: 'dev'
+  timeline: 'Before deployment'
+```
+
+## Outputs
+
+### Output 1: Gate YAML Block
+
+Generate for pasting into gate file under `risk_summary`:
+
+**Output rules:**
+
+- Only include assessed risks; do not emit placeholders
+- Sort risks by score (desc) when emitting highest and any tabular lists
+- If no risks: totals all zeros, omit highest, keep recommendations arrays empty
+
+```yaml
+# risk_summary (paste into gate file):
+risk_summary:
+  totals:
+    critical: X # score 9
+    high: Y # score 6
+    medium: Z # score 4
+    low: W # score 2-3
+  highest:
+    id: SEC-001
+    score: 9
+    title: 'XSS on profile form'
+  recommendations:
+    must_fix:
+      - 'Add input sanitization & CSP'
+    monitor:
+      - 'Add security alerts for auth endpoints'
+```
+
+### Output 2: Markdown Report
+
+**Save to:** `qa.qaLocation/assessments/{epic}.{story}-risk-{YYYYMMDD}.md`
+
+```markdown
+# Risk Profile: Story {epic}.{story}
+
+Date: {date}
+Reviewer: Quinn (Test Architect)
+
+## Executive Summary
+
+- Total Risks Identified: X
+- Critical Risks: Y
+- High Risks: Z
+- Risk Score: XX/100 (calculated)
+
+## Critical Risks Requiring Immediate Attention
+
+### 1. [ID]: Risk Title
+
+**Score: 9 (Critical)**
+**Probability**: High - Detailed reasoning
+**Impact**: High - Potential consequences
+**Mitigation**:
+
+- Immediate action required
+- Specific steps to take
+  **Testing Focus**: Specific test scenarios needed
+
+## Risk Distribution
+
+### By Category
+
+- Security: X risks (Y critical)
+- Performance: X risks (Y critical)
+- Data: X risks (Y critical)
+- Business: X risks (Y critical)
+- Operational: X risks (Y critical)
+
+### By Component
+
+- Frontend: X risks
+- Backend: X risks
+- Database: X risks
+- Infrastructure: X risks
+
+## Detailed Risk Register
+
+[Full table of all risks with scores and mitigations]
+
+## Risk-Based Testing Strategy
+
+### Priority 1: Critical Risk Tests
+
+- Test scenarios for critical risks
+- Required test types (security, load, chaos)
+- Test data requirements
+
+### Priority 2: High Risk Tests
+
+- Integration test scenarios
+- Edge case coverage
+
+### Priority 3: Medium/Low Risk Tests
+
+- Standard functional tests
+- Regression test suite
+
+## Risk Acceptance Criteria
+
+### Must Fix Before Production
+
+- All critical risks (score 9)
+- High risks affecting security/data
+
+### Can Deploy with Mitigation
+
+- Medium risks with compensating controls
+- Low risks with monitoring in place
+
+### Accepted Risks
+
+- Document any risks team accepts
+- Include sign-off from appropriate authority
+
+## Monitoring Requirements
+
+Post-deployment monitoring for:
+
+- Performance metrics for PERF risks
+- Security alerts for SEC risks
+- Error rates for operational risks
+- Business KPIs for business risks
+
+## Risk Review Triggers
+
+Review and update risk profile when:
+
+- Architecture changes significantly
+- New integrations added
+- Security vulnerabilities discovered
+- Performance issues reported
+- Regulatory requirements change
+```
+
+## Risk Scoring Algorithm
+
+Calculate overall story risk score:
+
+```text
+Base Score = 100
+For each risk:
+  - Critical (9): Deduct 20 points
+  - High (6): Deduct 10 points
+  - Medium (4): Deduct 5 points
+  - Low (2-3): Deduct 2 points
+
+Minimum score = 0 (extremely risky)
+Maximum score = 100 (minimal risk)
+```
+
+## Risk-Based Recommendations
+
+Based on risk profile, recommend:
+
+1. **Testing Priority**
+   - Which tests to run first
+   - Additional test types needed
+   - Test environment requirements
+
+2. **Development Focus**
+   - Code review emphasis areas
+   - Additional validation needed
+   - Security controls to implement
+
+3. **Deployment Strategy**
+   - Phased rollout for high-risk changes
+   - Feature flags for risky features
+   - Rollback procedures
+
+4. **Monitoring Setup**
+   - Metrics to track
+   - Alerts to configure
+   - Dashboard requirements
+
+## Integration with Quality Gates
+
+**Deterministic gate mapping:**
+
+- Any risk with score ≥ 9 → Gate = FAIL (unless waived)
+- Else if any score ≥ 6 → Gate = CONCERNS
+- Else → Gate = PASS
+- Unmitigated risks → Document in gate
+
+### Output 3: Story Hook Line
+
+**Print this line for review task to quote:**
+
+```text
+Risk profile: qa.qaLocation/assessments/{epic}.{story}-risk-{YYYYMMDD}.md
+```
+
+## Key Principles
+
+- Identify risks early and systematically
+- Use consistent probability × impact scoring
+- Provide actionable mitigation strategies
+- Link risks to specific test requirements
+- Track residual risk after mitigation
+- Update risk profile as story evolves

package/.knowledge/.ext/.bmad-core/tasks/shard-doc.md

@@ -0,0 +1,187 @@
+<!-- Powered by BMAD™ Core -->
+
+# 文档分片任务
+
+## 目标
+
+- 按二级标题把大文档拆成多个小文档
+- 建个文件夹结构来整理分片后的文档
+- 保持所有内容完整，包括代码块、图表和markdown格式
+
+## 主要方法：用markdown-tree自动分片
+
+[[LLM: 先检查.bmad-core/core-config.yaml里markdownExploder是不是设为true。如果是，试试运行命令：`md-tree explode {input file} {output path}`。
+
+如果命令成功了，告诉用户文档已经分片完成并停止 - 别继续了。
+
+如果命令失败了（特别是提示命令找不到或不可用的错误），告诉用户："markdownExploder已经启用了但md-tree命令用不了。请选一个：
+
+1. 全局装一下@kayvan/markdown-tree-parser：`npm install -g @kayvan/markdown-tree-parser`
+2. 或者在.bmad-core/core-config.yaml里把markdownExploder设为false
+
+**重要：先停一下 - 做完上面任一个操作再手动分片。**"
+
+如果markdownExploder设为false，告诉用户："markdownExploder现在是false。为了更好的性能和稳定性，建议：
+
+1. 在.bmad-core/core-config.yaml里把markdownExploder设为true
+2. 全局装一下@kayvan/markdown-tree-parser：`npm install -g @kayvan/markdown-tree-parser`
+
+我现在开始手动分片流程。"
+
+然后只有markdownExploder是false的时候才继续下面的手动方法。]]
+
+### 安装和使用
+
+1. **全局装一下**：
+
+   ```bash
+   npm install -g @kayvan/markdown-tree-parser
+   ```
+
+2. **用explode命令**：
+
+   ```bash
+   # PRD文档
+   md-tree explode docs/prd.md docs/prd
+
+   # 架构文档
+   md-tree explode docs/architecture.md docs/architecture
+
+   # 任意文档
+   md-tree explode [源文档] [目标文件夹]
+   ```
+
+3. **功能说明**：
+   - 自动按二级标题拆文档
+   - 创建正确命名的文件
+   - 适当调整标题级别
+   - 处理代码块和特殊markdown的所有边界情况
+
+如果用户已经装了@kayvan/markdown-tree-parser，直接用并跳过下面的手动流程。
+
+---
+
+## 手动方法（如果@kayvan/markdown-tree-parser用不了或用户要手动）
+
+### 任务说明
+
+1. 识别文档和目标位置
+
+- 确定要分片的文档（用户提供的路径）
+- 在`docs/`下建个和文档同名的文件夹（不要扩展名）
+- 示例：`docs/prd.md` → 建文件夹`docs/prd/`
+
+2. 解析和提取章节
+
+关键分片规则：
+
+1. 读整个文档内容
+2. 识别所有二级标题（## 标题）
+3. 对每个二级标题：
+   - 提取标题和到下一个二级标题的所有内容
+   - 包括所有子章节、代码块、图表、列表、表格等
+   - 特别注意：
+     - 代码块（```）- 确保捕获完整块包括结束反引号，注意代码块中可能误导的##符号
+     - Mermaid图表 - 保持完整的图表语法
+     - 嵌套markdown元素
+     - 可能包含##的多行内容
+
+关键：用理解markdown上下文的正确解析。代码块中的##不是章节标题。]]
+
+### 3. 创建单独文件
+
+对每个提取的章节：
+
+1. **生成文件名**：把章节标题转成小写连字符格式
+   - 去掉特殊字符
+   - 空格换成连字符
+   - 示例："## Tech Stack" → `tech-stack.md`
+
+2. **调整标题级别**：
+   - 二级标题在新文档里变成一级标题（# 而不是 ##）
+   - 所有子标题级别减1：
+
+   ```txt
+     - ### → ##
+     - #### → ###
+     - ##### → ####
+     - 等等
+   ```
+
+3. **写入内容**：把调整后的内容存到新文件
+
+### 4. 创建索引文件
+
+在分片文件夹里建个`index.md`文件：
+
+1. 包含原始一级标题和第一个二级标题之前的任何内容
+2. 列出所有分片文件的链接：
+
+```markdown
+# 原始文档标题
+
+[原始介绍内容（如有）]
+
+## 章节
+
+- [章节名称 1](./section-name-1.md)
+- [章节名称 2](./section-name-2.md)
+- [章节名称 3](./section-name-3.md)
+  ...
+```
+
+### 5. 保持特殊内容
+
+1. **代码块**：必须捕获完整块包括：
+
+   ```language
+   content
+   ```
+
+2. **Mermaid图表**：保持完整语法：
+
+   ```mermaid
+   graph TD
+   ...
+   ```
+
+3. **表格**：保持正确的markdown表格格式
+
+4. **列表**：保持缩进和嵌套
+
+5. **行内代码**：保持反引号
+
+6. **链接和引用**：保持所有markdown链接完整
+
+7. **模板标记**：如果文档包含{{占位符}}，完全保持
+
+### 6. 验证
+
+分片后：
+
+1. 验证所有章节都被提取
+2. 检查没有内容丢失
+3. 确保标题级别正确调整
+4. 确认所有文件都成功创建
+
+### 7. 报告结果
+
+给个摘要：
+
+```text
+文档分片成功：
+- 源文件：[原始文档路径]
+- 目标位置：docs/[文件夹名]/
+- 创建文件数：[数量]
+- 章节：
+  - section-name-1.md: "章节标题 1"
+  - section-name-2.md: "章节标题 2"
+  ...
+```
+
+## 重要说明
+
+- 永远不要修改实际内容，只调整标题级别
+- 保持所有格式，包括重要的空白字符
+- 处理边界情况，如包含##符号的代码块章节
+- 确保分片可逆（可以从分片重构原始文档）

package/.knowledge/.ext/.bmad-core/tasks/test-design.md

@@ -0,0 +1,176 @@
+<!-- Powered by BMAD™ Core -->
+
+# test-design
+
+给用户故事设计完整的测试方案，告诉你该在哪个层面做测试。
+
+## 需要什么
+
+```yaml
+required:
+  - story_id: '{epic}.{story}' # 比如："1.3"
+  - story_path: '{devStoryLocation}/{epic}.{story}.*.md' # 从core-config.yaml来的路径
+  - story_title: '{title}' # 没有的话，从故事文件的标题里拿
+  - story_slug: '{slug}' # 没有的话，从标题生成（小写，用连字符）
+```
+
+## 要干啥
+
+设计一套完整的测试策略，搞清楚测什么、在哪一层测（单元/集成/端到端），还有为啥这么测。这样既能保证测试覆盖到位，又不会重复测试，还能把测试边界划清楚。
+
+## 要用到的文件
+
+```yaml
+data:
+  - test-levels-framework.md # 单元/集成/端到端测试怎么选的标准
+  - test-priorities-matrix.md # P0/P1/P2/P3优先级怎么分的
+```
+
+## 怎么做
+
+### 1. 把需求拆开看
+
+把每个验收标准掰开揉碎，看看能测什么。对每个AC：
+
+- 找出核心功能要测啥
+- 看看需要哪些数据变化
+- 想想出错的情况
+- 注意边界条件
+
+### 2. 选测试级别
+
+**参考：** 看看 `test-levels-framework.md` 里的详细标准
+
+简单来说：
+
+- **单元测试**：纯逻辑、算法、计算这些
+- **集成测试**：组件之间怎么交互、数据库操作
+- **端到端测试**：用户走完整个流程、合规性检查
+
+### 3. 排优先级
+
+**参考：** 看看 `test-priorities-matrix.md` 怎么分类的
+
+优先级简单分法：
+
+- **P0**：赚钱的、安全的、合规的
+- **P1**：用户主要用的、高频功能
+- **P2**：次要功能、管理后台
+- **P3**：有就更好、基本用不到
+
+### 4. 写测试场景
+
+把每个要测的地方都写出来：
+
+```yaml
+test_scenario:
+  id: '{epic}.{story}-{LEVEL}-{SEQ}'
+  requirement: 'AC reference'
+  priority: P0|P1|P2|P3
+  level: unit|integration|e2e
+  description: 'What is being tested'
+  justification: 'Why this level was chosen'
+  mitigates_risks: ['RISK-001'] # If risk profile exists
+```
+
+### 5. 检查覆盖全不全
+
+确保：
+
+- 每个AC都有测试
+- 不同级别别重复测
+- 重要流程多测几层
+- 风险点都覆盖到
+
+## 最后输出啥
+
+### 输出1：测试设计文档
+
+**存到：** `qa.qaLocation/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md`
+
+```markdown
+# 测试设计：故事 {epic}.{story}
+
+日期：{date}
+设计者：Quinn（测试架构师）
+
+## 测试策略概览
+
+- 测试场景总数：X
+- 单元测试：Y（A%）
+- 集成测试：Z（B%）
+- 端到端测试：W（C%）
+- 优先级分布：P0: X, P1: Y, P2: Z
+
+## 按验收标准的测试场景
+
+### AC1：{description}
+
+#### 场景
+
+| ID           | 级别   | 优先级 | 测试内容     | 选择理由     |
+| ------------ | ------ | ------ | ------------ | ------------ |
+| 1.3-UNIT-001 | 单元   | P0     | 验证输入格式 | 纯验证逻辑   |
+| 1.3-INT-001  | 集成   | P0     | 服务处理请求 | 多组件流程   |
+| 1.3-E2E-001  | 端到端 | P1     | 用户完成流程 | 关键路径验证 |
+
+[继续所有AC...]
+
+## 风险覆盖
+
+[如果有风险档案，把测试场景和风险对应上]
+
+## 推荐执行顺序
+
+1. P0单元测试（快速失败）
+2. P0集成测试
+3. P0端到端测试
+4. 按顺序执行P1测试
+5. 时间允许时执行P2+测试
+```
+
+### 输出2：质量门禁YAML块
+
+给质量门禁用的：
+
+```yaml
+test_design:
+  scenarios_total: X
+  by_level:
+    unit: Y
+    integration: Z
+    e2e: W
+  by_priority:
+    p0: A
+    p1: B
+    p2: C
+  coverage_gaps: [] # 哪些AC没测试
+```
+
+### 输出3：追踪引用
+
+给trace-requirements任务用的：
+
+```text
+测试设计矩阵：qa.qaLocation/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md
+找到的P0测试：{count}
+```
+
+## Quality Checklist
+
+最后检查一下：
+
+- [ ] 每个AC都有测试覆盖
+- [ ] 测试级别选得合适（别过度测试）
+- [ ] 不同级别别重复测
+- [ ] 优先级和业务风险对得上
+- [ ] 测试ID按规范命名
+- [ ] 场景都是独立的，不互相影响
+
+## 核心原则
+
+- **左移测试**：能单元测试就别集成测试，能集成测试就别端到端测试
+- **基于风险**：重点测容易出问题的地方
+- **高效覆盖**：在合适的级别测一次就够了
+- **可维护性**：考虑长期维护成本
+- **快速反馈**：快的测试先跑