@rdmind/rdmind 0.0.9-alpha.1 → 0.0.9

package/.knowledge/.ext/.bmad-core/checklists/po-master-checklist.md

@@ -0,0 +1,434 @@
+<!-- Powered by BMAD™ Core -->
+
+# Product Owner (PO) Master Validation Checklist
+
+This checklist serves as a comprehensive framework for the Product Owner to validate project plans before development execution. It adapts intelligently based on project type (greenfield vs brownfield) and includes UI/UX considerations when applicable.
+
+[[LLM: INITIALIZATION INSTRUCTIONS - PO MASTER CHECKLIST
+
+PROJECT TYPE DETECTION:
+First, determine the project type by checking:
+
+1. Is this a GREENFIELD project (new from scratch)?
+   - Look for: New project initialization, no existing codebase references
+   - Check for: prd.md, architecture.md, new project setup stories
+
+2. Is this a BROWNFIELD project (enhancing existing system)?
+   - Look for: References to existing codebase, enhancement/modification language
+   - Check for: brownfield-prd.md, brownfield-architecture.md, existing system analysis
+
+3. Does the project include UI/UX components?
+   - Check for: frontend-architecture.md, UI/UX specifications, design files
+   - Look for: Frontend stories, component specifications, user interface mentions
+
+DOCUMENT REQUIREMENTS:
+Based on project type, ensure you have access to:
+
+For GREENFIELD projects:
+
+- prd.md - The Product Requirements Document
+- architecture.md - The system architecture
+- frontend-architecture.md - If UI/UX is involved
+- All epic and story definitions
+
+For BROWNFIELD projects:
+
+- brownfield-prd.md - The brownfield enhancement requirements
+- brownfield-architecture.md - The enhancement architecture
+- Existing project codebase access (CRITICAL - cannot proceed without this)
+- Current deployment configuration and infrastructure details
+- Database schemas, API documentation, monitoring setup
+
+SKIP INSTRUCTIONS:
+
+- Skip sections marked [[BROWNFIELD ONLY]] for greenfield projects
+- Skip sections marked [[GREENFIELD ONLY]] for brownfield projects
+- Skip sections marked [[UI/UX ONLY]] for backend-only projects
+- Note all skipped sections in your final report
+
+VALIDATION APPROACH:
+
+1. Deep Analysis - Thoroughly analyze each item against documentation
+2. Evidence-Based - Cite specific sections or code when validating
+3. Critical Thinking - Question assumptions and identify gaps
+4. Risk Assessment - Consider what could go wrong with each decision
+
+EXECUTION MODE:
+Ask the user if they want to work through the checklist:
+
+- Section by section (interactive mode) - Review each section, get confirmation before proceeding
+- All at once (comprehensive mode) - Complete full analysis and present report at end]]
+
+## 1. PROJECT SETUP & INITIALIZATION
+
+[[LLM: Project setup is the foundation. For greenfield, ensure clean start. For brownfield, ensure safe integration with existing system. Verify setup matches project type.]]
+
+### 1.1 Project Scaffolding [[GREENFIELD ONLY]]
+
+- [ ] Epic 1 includes explicit steps for project creation/initialization
+- [ ] If using a starter template, steps for cloning/setup are included
+- [ ] If building from scratch, all necessary scaffolding steps are defined
+- [ ] Initial README or documentation setup is included
+- [ ] Repository setup and initial commit processes are defined
+
+### 1.2 Existing System Integration [[BROWNFIELD ONLY]]
+
+- [ ] Existing project analysis has been completed and documented
+- [ ] Integration points with current system are identified
+- [ ] Development environment preserves existing functionality
+- [ ] Local testing approach validated for existing features
+- [ ] Rollback procedures defined for each integration point
+
+### 1.3 Development Environment
+
+- [ ] Local development environment setup is clearly defined
+- [ ] Required tools and versions are specified
+- [ ] Steps for installing dependencies are included
+- [ ] Configuration files are addressed appropriately
+- [ ] Development server setup is included
+
+### 1.4 Core Dependencies
+
+- [ ] All critical packages/libraries are installed early
+- [ ] Package management is properly addressed
+- [ ] Version specifications are appropriately defined
+- [ ] Dependency conflicts or special requirements are noted
+- [ ] [[BROWNFIELD ONLY]] Version compatibility with existing stack verified
+
+## 2. INFRASTRUCTURE & DEPLOYMENT
+
+[[LLM: Infrastructure must exist before use. For brownfield, must integrate with existing infrastructure without breaking it.]]
+
+### 2.1 Database & Data Store Setup
+
+- [ ] Database selection/setup occurs before any operations
+- [ ] Schema definitions are created before data operations
+- [ ] Migration strategies are defined if applicable
+- [ ] Seed data or initial data setup is included if needed
+- [ ] [[BROWNFIELD ONLY]] Database migration risks identified and mitigated
+- [ ] [[BROWNFIELD ONLY]] Backward compatibility ensured
+
+### 2.2 API & Service Configuration
+
+- [ ] API frameworks are set up before implementing endpoints
+- [ ] Service architecture is established before implementing services
+- [ ] Authentication framework is set up before protected routes
+- [ ] Middleware and common utilities are created before use
+- [ ] [[BROWNFIELD ONLY]] API compatibility with existing system maintained
+- [ ] [[BROWNFIELD ONLY]] Integration with existing authentication preserved
+
+### 2.3 Deployment Pipeline
+
+- [ ] CI/CD pipeline is established before deployment actions
+- [ ] Infrastructure as Code (IaC) is set up before use
+- [ ] Environment configurations are defined early
+- [ ] Deployment strategies are defined before implementation
+- [ ] [[BROWNFIELD ONLY]] Deployment minimizes downtime
+- [ ] [[BROWNFIELD ONLY]] Blue-green or canary deployment implemented
+
+### 2.4 Testing Infrastructure
+
+- [ ] Testing frameworks are installed before writing tests
+- [ ] Test environment setup precedes test implementation
+- [ ] Mock services or data are defined before testing
+- [ ] [[BROWNFIELD ONLY]] Regression testing covers existing functionality
+- [ ] [[BROWNFIELD ONLY]] Integration testing validates new-to-existing connections
+
+## 3. EXTERNAL DEPENDENCIES & INTEGRATIONS
+
+[[LLM: External dependencies often block progress. For brownfield, ensure new dependencies don't conflict with existing ones.]]
+
+### 3.1 Third-Party Services
+
+- [ ] Account creation steps are identified for required services
+- [ ] API key acquisition processes are defined
+- [ ] Steps for securely storing credentials are included
+- [ ] Fallback or offline development options are considered
+- [ ] [[BROWNFIELD ONLY]] Compatibility with existing services verified
+- [ ] [[BROWNFIELD ONLY]] Impact on existing integrations assessed
+
+### 3.2 External APIs
+
+- [ ] Integration points with external APIs are clearly identified
+- [ ] Authentication with external services is properly sequenced
+- [ ] API limits or constraints are acknowledged
+- [ ] Backup strategies for API failures are considered
+- [ ] [[BROWNFIELD ONLY]] Existing API dependencies maintained
+
+### 3.3 Infrastructure Services
+
+- [ ] Cloud resource provisioning is properly sequenced
+- [ ] DNS or domain registration needs are identified
+- [ ] Email or messaging service setup is included if needed
+- [ ] CDN or static asset hosting setup precedes their use
+- [ ] [[BROWNFIELD ONLY]] Existing infrastructure services preserved
+
+## 4. UI/UX CONSIDERATIONS [[UI/UX ONLY]]
+
+[[LLM: Only evaluate this section if the project includes user interface components. Skip entirely for backend-only projects.]]
+
+### 4.1 Design System Setup
+
+- [ ] UI framework and libraries are selected and installed early
+- [ ] Design system or component library is established
+- [ ] Styling approach (CSS modules, styled-components, etc.) is defined
+- [ ] Responsive design strategy is established
+- [ ] Accessibility requirements are defined upfront
+
+### 4.2 Frontend Infrastructure
+
+- [ ] Frontend build pipeline is configured before development
+- [ ] Asset optimization strategy is defined
+- [ ] Frontend testing framework is set up
+- [ ] Component development workflow is established
+- [ ] [[BROWNFIELD ONLY]] UI consistency with existing system maintained
+
+### 4.3 User Experience Flow
+
+- [ ] User journeys are mapped before implementation
+- [ ] Navigation patterns are defined early
+- [ ] Error states and loading states are planned
+- [ ] Form validation patterns are established
+- [ ] [[BROWNFIELD ONLY]] Existing user workflows preserved or migrated
+
+## 5. USER/AGENT RESPONSIBILITY
+
+[[LLM: Clear ownership prevents confusion. Ensure tasks are assigned appropriately based on what only humans can do.]]
+
+### 5.1 User Actions
+
+- [ ] User responsibilities limited to human-only tasks
+- [ ] Account creation on external services assigned to users
+- [ ] Purchasing or payment actions assigned to users
+- [ ] Credential provision appropriately assigned to users
+
+### 5.2 Developer Agent Actions
+
+- [ ] All code-related tasks assigned to developer agents
+- [ ] Automated processes identified as agent responsibilities
+- [ ] Configuration management properly assigned
+- [ ] Testing and validation assigned to appropriate agents
+
+## 6. FEATURE SEQUENCING & DEPENDENCIES
+
+[[LLM: Dependencies create the critical path. For brownfield, ensure new features don't break existing ones.]]
+
+### 6.1 Functional Dependencies
+
+- [ ] Features depending on others are sequenced correctly
+- [ ] Shared components are built before their use
+- [ ] User flows follow logical progression
+- [ ] Authentication features precede protected features
+- [ ] [[BROWNFIELD ONLY]] Existing functionality preserved throughout
+
+### 6.2 Technical Dependencies
+
+- [ ] Lower-level services built before higher-level ones
+- [ ] Libraries and utilities created before their use
+- [ ] Data models defined before operations on them
+- [ ] API endpoints defined before client consumption
+- [ ] [[BROWNFIELD ONLY]] Integration points tested at each step
+
+### 6.3 Cross-Epic Dependencies
+
+- [ ] Later epics build upon earlier epic functionality
+- [ ] No epic requires functionality from later epics
+- [ ] Infrastructure from early epics utilized consistently
+- [ ] Incremental value delivery maintained
+- [ ] [[BROWNFIELD ONLY]] Each epic maintains system integrity
+
+## 7. RISK MANAGEMENT [[BROWNFIELD ONLY]]
+
+[[LLM: This section is CRITICAL for brownfield projects. Think pessimistically about what could break.]]
+
+### 7.1 Breaking Change Risks
+
+- [ ] Risk of breaking existing functionality assessed
+- [ ] Database migration risks identified and mitigated
+- [ ] API breaking change risks evaluated
+- [ ] Performance degradation risks identified
+- [ ] Security vulnerability risks evaluated
+
+### 7.2 Rollback Strategy
+
+- [ ] Rollback procedures clearly defined per story
+- [ ] Feature flag strategy implemented
+- [ ] Backup and recovery procedures updated
+- [ ] Monitoring enhanced for new components
+- [ ] Rollback triggers and thresholds defined
+
+### 7.3 User Impact Mitigation
+
+- [ ] Existing user workflows analyzed for impact
+- [ ] User communication plan developed
+- [ ] Training materials updated
+- [ ] Support documentation comprehensive
+- [ ] Migration path for user data validated
+
+## 8. MVP SCOPE ALIGNMENT
+
+[[LLM: MVP means MINIMUM viable product. For brownfield, ensure enhancements are truly necessary.]]
+
+### 8.1 Core Goals Alignment
+
+- [ ] All core goals from PRD are addressed
+- [ ] Features directly support MVP goals
+- [ ] No extraneous features beyond MVP scope
+- [ ] Critical features prioritized appropriately
+- [ ] [[BROWNFIELD ONLY]] Enhancement complexity justified
+
+### 8.2 User Journey Completeness
+
+- [ ] All critical user journeys fully implemented
+- [ ] Edge cases and error scenarios addressed
+- [ ] User experience considerations included
+- [ ] [[UI/UX ONLY]] Accessibility requirements incorporated
+- [ ] [[BROWNFIELD ONLY]] Existing workflows preserved or improved
+
+### 8.3 Technical Requirements
+
+- [ ] All technical constraints from PRD addressed
+- [ ] Non-functional requirements incorporated
+- [ ] Architecture decisions align with constraints
+- [ ] Performance considerations addressed
+- [ ] [[BROWNFIELD ONLY]] Compatibility requirements met
+
+## 9. DOCUMENTATION & HANDOFF
+
+[[LLM: Good documentation enables smooth development. For brownfield, documentation of integration points is critical.]]
+
+### 9.1 Developer Documentation
+
+- [ ] API documentation created alongside implementation
+- [ ] Setup instructions are comprehensive
+- [ ] Architecture decisions documented
+- [ ] Patterns and conventions documented
+- [ ] [[BROWNFIELD ONLY]] Integration points documented in detail
+
+### 9.2 User Documentation
+
+- [ ] User guides or help documentation included if required
+- [ ] Error messages and user feedback considered
+- [ ] Onboarding flows fully specified
+- [ ] [[BROWNFIELD ONLY]] Changes to existing features documented
+
+### 9.3 Knowledge Transfer
+
+- [ ] [[BROWNFIELD ONLY]] Existing system knowledge captured
+- [ ] [[BROWNFIELD ONLY]] Integration knowledge documented
+- [ ] Code review knowledge sharing planned
+- [ ] Deployment knowledge transferred to operations
+- [ ] Historical context preserved
+
+## 10. POST-MVP CONSIDERATIONS
+
+[[LLM: Planning for success prevents technical debt. For brownfield, ensure enhancements don't limit future growth.]]
+
+### 10.1 Future Enhancements
+
+- [ ] Clear separation between MVP and future features
+- [ ] Architecture supports planned enhancements
+- [ ] Technical debt considerations documented
+- [ ] Extensibility points identified
+- [ ] [[BROWNFIELD ONLY]] Integration patterns reusable
+
+### 10.2 Monitoring & Feedback
+
+- [ ] Analytics or usage tracking included if required
+- [ ] User feedback collection considered
+- [ ] Monitoring and alerting addressed
+- [ ] Performance measurement incorporated
+- [ ] [[BROWNFIELD ONLY]] Existing monitoring preserved/enhanced
+
+## VALIDATION SUMMARY
+
+[[LLM: FINAL PO VALIDATION REPORT GENERATION
+
+Generate a comprehensive validation report that adapts to project type:
+
+1. Executive Summary
+   - Project type: [Greenfield/Brownfield] with [UI/No UI]
+   - Overall readiness (percentage)
+   - Go/No-Go recommendation
+   - Critical blocking issues count
+   - Sections skipped due to project type
+
+2. Project-Specific Analysis
+
+   FOR GREENFIELD:
+   - Setup completeness
+   - Dependency sequencing
+   - MVP scope appropriateness
+   - Development timeline feasibility
+
+   FOR BROWNFIELD:
+   - Integration risk level (High/Medium/Low)
+   - Existing system impact assessment
+   - Rollback readiness
+   - User disruption potential
+
+3. Risk Assessment
+   - Top 5 risks by severity
+   - Mitigation recommendations
+   - Timeline impact of addressing issues
+   - [BROWNFIELD] Specific integration risks
+
+4. MVP Completeness
+   - Core features coverage
+   - Missing essential functionality
+   - Scope creep identified
+   - True MVP vs over-engineering
+
+5. Implementation Readiness
+   - Developer clarity score (1-10)
+   - Ambiguous requirements count
+   - Missing technical details
+   - [BROWNFIELD] Integration point clarity
+
+6. Recommendations
+   - Must-fix before development
+   - Should-fix for quality
+   - Consider for improvement
+   - Post-MVP deferrals
+
+7. [BROWNFIELD ONLY] Integration Confidence
+   - Confidence in preserving existing functionality
+   - Rollback procedure completeness
+   - Monitoring coverage for integration points
+   - Support team readiness
+
+After presenting the report, ask if the user wants:
+
+- Detailed analysis of any failed sections
+- Specific story reordering suggestions
+- Risk mitigation strategies
+- [BROWNFIELD] Integration risk deep-dive]]
+
+### Category Statuses
+
+| Category                                | Status | Critical Issues |
+| --------------------------------------- | ------ | --------------- |
+| 1. Project Setup & Initialization       | _TBD_  |                 |
+| 2. Infrastructure & Deployment          | _TBD_  |                 |
+| 3. External Dependencies & Integrations | _TBD_  |                 |
+| 4. UI/UX Considerations                 | _TBD_  |                 |
+| 5. User/Agent Responsibility            | _TBD_  |                 |
+| 6. Feature Sequencing & Dependencies    | _TBD_  |                 |
+| 7. Risk Management (Brownfield)         | _TBD_  |                 |
+| 8. MVP Scope Alignment                  | _TBD_  |                 |
+| 9. Documentation & Handoff              | _TBD_  |                 |
+| 10. Post-MVP Considerations             | _TBD_  |                 |
+
+### Critical Deficiencies
+
+(To be populated during validation)
+
+### Recommendations
+
+(To be populated during validation)
+
+### Final Decision
+
+- **APPROVED**: The plan is comprehensive, properly sequenced, and ready for implementation.
+- **CONDITIONAL**: The plan requires specific adjustments before proceeding.
+- **REJECTED**: The plan requires significant revision to address critical deficiencies.

package/.knowledge/.ext/.bmad-core/checklists/story-dod-checklist.md

@@ -0,0 +1,96 @@
+<!-- Powered by BMAD™ Core -->
+
+# Story Definition of Done (DoD) Checklist
+
+## 开发者代理说明
+
+在把story标记为'Review'之前，请过一遍这个checklist的每个项目。报告每个项目的状态（如，[x] 完成，[ ] 未完成，[N/A] 不适用）并在必要时提供简短评论。
+
+[[LLM: 初始化说明 - STORY DOD验证
+
+这个checklist是给开发者代理在标记story完成前自我验证工作用的。
+
+重要：这是自我评估。要诚实面对实际完成的和应该完成的。现在发现问题比在review时发现要好。
+
+执行方法：
+
+1. 系统性地过一遍每个章节
+2. 把项目标记为[x] 完成，[ ] 未完成，或[N/A] 不适用
+3. 为任何[ ] 或[N/A]项目添加简短评论说明
+4. 具体说明实际实现了什么
+5. 标记任何关注点或产生的技术债务
+
+目标是质量交付，不只是打勾。]]
+
+## Checklist项目
+
+1. **需求满足：**
+
+   [[LLM: 要具体 - 列出每个需求以及是否完成]]
+   - [ ] story中指定的所有功能需求都已实现。
+   - [ ] story中定义的所有验收标准都已满足。
+
+2. **编码标准和项目结构：**
+
+   [[LLM: 代码质量对可维护性很重要。仔细检查每个项目]]
+   - [ ] 所有新增/修改的代码严格遵循`操作指南`。
+   - [ ] 所有新增/修改的代码符合`项目结构`（文件位置、命名等）。
+   - [ ] 遵循`技术栈`的技术/版本使用（如果story引入或修改技术使用）。
+   - [ ] 遵循`API参考`和`数据模型`（如果story涉及API或数据模型变更）。
+   - [ ] 对新增/修改的代码应用基本安全最佳实践（如，输入验证、适当错误处理、无硬编码密钥）。
+   - [ ] 没有引入新的linter错误或警告。
+   - [ ] 代码在必要时有良好注释（澄清复杂逻辑，不是显而易见的语句）。
+
+3. **测试：**
+
+   [[LLM: 测试证明你的代码有效。诚实面对测试覆盖率]]
+   - [ ] 根据story和`操作指南`测试策略的所有必需单元测试都已实现。
+   - [ ] 根据story和`操作指南`测试策略的所有必需集成测试（如适用）都已实现。
+   - [ ] 所有测试（单元、集成、E2E如适用）都成功通过。
+   - [ ] 测试覆盖率符合项目标准（如已定义）。
+
+4. **功能和验证：**
+
+   [[LLM: 你真的运行和测试了你的代码吗？具体说明你测试了什么]]
+   - [ ] 功能已被开发者手动验证（如，本地运行app、检查UI、测试API端点）。
+   - [ ] 边界情况和潜在错误条件已考虑并优雅处理。
+
+5. **Story管理：**
+
+   [[LLM: 文档帮助下一个开发者。他们应该知道什么？]]
+   - [ ] story文件中的所有任务都标记为完成。
+   - [ ] 开发过程中做出的任何澄清或决策都在story文件中记录或适当链接。
+   - [ ] story总结章节已完成，包含与下一个story或整体项目相关的变更或信息说明、开发过程中主要使用的代理模型，以及任何变更的changelog已正确更新。
+
+6. **依赖、构建和配置：**
+
+   [[LLM: 构建问题会阻塞所有人。确保所有东西都能干净地编译和运行]]
+   - [ ] 项目成功构建无错误。
+   - [ ] 项目linting通过
+   - [ ] 任何新增的依赖要么在story需求中预批准，要么在开发过程中被用户明确批准（批准记录在story文件中）。
+   - [ ] 如果新增了依赖，它们记录在适当的项目文件中（如`package.json`、`requirements.txt`）并附有理由。
+   - [ ] 新增和批准的依赖没有引入已知安全漏洞。
+   - [ ] 如果story引入了新的环境变量或配置，它们已记录并安全处理。
+
+7. **文档（如适用）：**
+
+   [[LLM: 好的文档防止未来困惑。什么需要解释？]]
+   - [ ] 新公共API或复杂逻辑的相关内联代码文档（如JSDoc、TSDoc、Python docstrings）已完成。
+   - [ ] 如果变更影响用户，用户面向的文档已更新。
+   - [ ] 如果进行了重大架构变更，技术文档（如README、系统图）已更新。
+
+## 最终确认
+
+[[LLM: 最终DOD总结
+
+完成checklist后：
+
+1. 总结这个story中完成的内容
+2. 列出任何标记为[ ] 未完成的项目并附说明
+3. 识别任何技术债务或需要的后续工作
+4. 记录任何挑战或对未来story的学习
+5. 确认story是否真正准备好review
+
+要诚实 - 现在标记问题比以后发现要好。]]
+
+- [ ] 我，开发者代理，确认上述所有适用项目都已处理。

package/.knowledge/.ext/.bmad-core/checklists/story-draft-checklist.md

@@ -0,0 +1,155 @@
+<!-- Powered by BMAD™ Core -->
+
+# Story Draft Checklist
+
+Scrum Master应该用这个checklist来验证每个story是否包含足够的上下文，让开发代理能够成功实现它，同时假设开发代理有合理的能力来搞定问题。
+
+[[LLM: 初始化指令 - STORY DRAFT 验证
+
+在开始这个checklist之前，确保你能访问到：
+
+1. 正在验证的story文档（通常在docs/stories/或直接提供）
+2. 父级epic上下文
+3. 任何引用的架构或设计文档
+4. 如果这是基于之前工作的，需要之前相关的story
+
+重要：这个checklist在实现开始之前验证单个story。
+
+验证原则：
+
+1. 清晰度 - 开发者应该理解要做什么
+2. 上下文 - 为什么要做这个以及它如何融入整体
+3. 指导 - 要遵循的关键技术决策和模式
+4. 可测试性 - 如何验证实现是否有效
+5. 自包含 - 大部分需要的信息都在story本身
+
+记住：我们假设有能力的开发代理可以：
+
+- 研究文档和代码库
+- 做出合理的技术决策
+- 遵循既定的模式
+- 在真正卡住时寻求澄清
+
+我们检查的是足够的指导，而不是事无巨细的细节。]]
+
+## 1. 目标和上下文清晰度
+
+[[LLM: 没有清晰的目标，开发者会做错东西。验证：
+
+1. Story说明了要实现什么功能
+2. 业务价值或用户收益是清晰的
+3. 解释了这个如何融入更大的epic/产品
+4. 依赖关系是明确的（"需要Story X完成"）
+5. 成功看起来是具体的，不是模糊的]]
+
+- [ ] Story目标/目的明确说明
+- [ ] 与epic目标的关系显而易见
+- [ ] 解释了story如何融入整体系统流程
+- [ ] 识别了对之前story的依赖（如果适用）
+- [ ] 业务上下文和价值是清晰的
+
+## 2. 技术实现指导
+
+[[LLM: 开发者需要足够的技术上下文来开始编码。检查：
+
+1. 提到要创建或修改的关键文件/组件
+2. 在非显而易见的地方指定技术选择
+3. 识别与现有代码的集成点
+4. 定义或引用数据模型或API合约
+5. 指出非标准模式或异常
+
+注意：我们不需要列出每个文件 - 只需要重要的。]]
+
+- [ ] 识别要创建/修改的关键文件（不一定是详尽的）
+- [ ] 提到这个story特别需要的技术
+- [ ] 充分描述关键的API或接口
+- [ ] 引用必要的数据模型或结构
+- [ ] 列出需要的环境变量（如果适用）
+- [ ] 注意任何标准编码模式的异常
+
+## 3. 引用有效性
+
+[[LLM: 引用应该有帮助，而不是创造寻宝游戏。确保：
+
+1. 引用指向特定部分，而不是整个文档
+2. 解释每个引用的相关性
+3. 在story中总结关键信息
+4. 引用是可访问的（不是断开的链接）
+5. 如果需要，总结之前story的上下文]]
+
+- [ ] 对外部文档的引用指向特定的相关部分
+- [ ] 总结之前story的关键信息（不只是引用）
+- [ ] 提供引用为什么相关的上下文
+- [ ] 引用使用一致的格式（比如，`docs/filename.md#section`）
+
+## 4. 自包含性评估
+
+[[LLM: Story应该大部分是自包含的，以避免上下文切换。验证：
+
+1. 核心需求在story中，而不仅仅在引用中
+2. 领域术语被解释或从上下文中显而易见
+3. 假设被明确说明
+4. 提到边缘情况（即使被推迟）
+5. 可以在不阅读10个其他文档的情况下理解story]]
+
+- [ ] 包含需要的核心信息（不过度依赖外部文档）
+- [ ] 把隐式假设变得明确
+- [ ] 解释领域特定的术语或概念
+- [ ] 处理边缘情况或错误场景
+
+## 5. 测试指导
+
+[[LLM: 测试确保实现真正有效。检查：
+
+1. 指定测试方法（单元、集成、端到端）
+2. 列出关键测试场景
+3. 成功标准是可测量的
+4. 注意特殊测试考虑
+5. Story中的验收标准是可测试的]]
+
+- [ ] 概述所需的测试方法
+- [ ] 识别关键测试场景
+- [ ] 定义成功标准
+- [ ] 注意特殊测试考虑（如果适用）
+
+## 验证结果
+
+[[LLM: 最终STORY验证报告
+
+生成简洁的验证报告：
+
+1. 快速总结
+   - Story准备状态：READY / NEEDS REVISION / BLOCKED
+   - 清晰度评分（1-10）
+   - 识别的主要差距
+
+2. 填写验证表格：
+   - PASS：要求明确满足
+   - PARTIAL：有一些差距但可行
+   - FAIL：关键信息缺失
+
+3. 具体问题（如果有）
+   - 列出要修复的具体问题
+   - 建议具体的改进
+   - 识别任何阻塞依赖
+
+4. 开发者视角
+   - 你能按照写的那样实现这个story吗？
+   - 你会有什么问题？
+   - 什么可能导致延迟或返工？
+
+要实用 - 完美的文档不存在，但必须足够提供开发代理需要的极端上下文来完成工作而不造成混乱。]]
+
+| 类别                  | 状态  | 问题 |
+| --------------------- | ----- | ---- |
+| 1. 目标和上下文清晰度 | _TBD_ |      |
+| 2. 技术实现指导       | _TBD_ |      |
+| 3. 引用有效性         | _TBD_ |      |
+| 4. 自包含性评估       | _TBD_ |      |
+| 5. 测试指导           | _TBD_ |      |
+
+**最终评估：**
+
+- READY：Story为实现提供了足够的上下文
+- NEEDS REVISION：Story需要更新（见问题）
+- BLOCKED：需要外部信息（指定什么信息）