grimoire-framework 1.0.0

package/.grimoire/product/checklists/self-critique-checklist.md

@@ -0,0 +1,387 @@
+# Self-Critique Checklist
+
+> **Used By:** `plan-execute-subtask.md` (Coder Agent Steps 5.5 & 6.5)
+> **Purpose:** Mandatory self-review checkpoints to catch issues before they propagate
+
+---
+
+## Overview
+
+This checklist is executed TWICE during subtask execution:
+
+1. **Step 5.5 (Post-Code):** After writing code, before running tests
+2. **Step 6.5 (Post-Test):** After tests pass, before committing
+
+Both phases are MANDATORY. Skipping them violates the Coder Agent workflow.
+
+---
+
+## Step 5.5: Post-Code Self-Critique
+
+> **Trigger:** After Step 5 (Write Code) completes
+> **Goal:** Catch bugs, edge cases, and security issues BEFORE running tests
+
+### Checklist Items
+
+```yaml
+post_code_critique:
+  - id: SC-5.5.1
+    category: bugs
+    question: 'Are there any predicted bugs in this code?'
+    how_to_check:
+      - Review logic flow for off-by-one errors
+      - Check loop termination conditions
+      - Verify correct operator usage (= vs ==, && vs ||)
+      - Look for null/undefined dereferences
+    action_if_found: 'Fix immediately before proceeding'
+    severity: HIGH
+
+  - id: SC-5.5.2
+    category: edge_cases
+    question: 'Have all edge cases been handled?'
+    how_to_check:
+      - Null/undefined inputs
+      - Empty arrays/objects
+      - Boundary values (0, -1, MAX_INT)
+      - Empty strings vs null
+      - Unicode and special characters
+    action_if_found: 'Add guards or validation'
+    severity: HIGH
+
+  - id: SC-5.5.3
+    category: error_handling
+    question: 'Is error handling comprehensive?'
+    how_to_check:
+      - All async operations have try/catch
+      - Error messages are user-friendly
+      - Errors include context (what operation failed)
+      - Errors don't expose sensitive info
+      - Recovery paths are defined where possible
+    action_if_found: 'Add appropriate error handling'
+    severity: HIGH
+
+  - id: SC-5.5.4
+    category: security
+    question: 'Are there any security vulnerabilities?'
+    how_to_check:
+      - Input validation present
+      - SQL/NoSQL injection prevention
+      - XSS prevention (output encoding)
+      - Sensitive data not logged
+      - Auth/authz checks in place
+      - No hardcoded secrets
+    action_if_found: 'Fix security issue immediately'
+    severity: CRITICAL
+
+  - id: SC-5.5.5
+    category: resilience
+    question: 'Does the code handle failure gracefully?'
+    how_to_check:
+      - Network failures handled
+      - Timeouts configured
+      - Retries where appropriate
+      - User gets feedback on failure
+      - Partial failures don't corrupt state
+    action_if_found: 'Add failure handling'
+    severity: MEDIUM
+```
+
+### Execution Process
+
+```
+1. PAUSE after writing code (Step 5 complete)
+2. Re-read ALL code written in this subtask
+3. For EACH checklist item:
+   a. Ask yourself the question
+   b. Use "how_to_check" to verify
+   c. If issue found:
+      - Document it
+      - Fix immediately
+      - Mark as fixed
+4. If ANY issues were fixed:
+   - Re-run this checklist from start
+5. Only proceed when ALL items pass
+```
+
+### Pass Criteria
+
+- [ ] SC-5.5.1: No predicted bugs (or all fixed)
+- [ ] SC-5.5.2: Edge cases handled
+- [ ] SC-5.5.3: Error handling comprehensive
+- [ ] SC-5.5.4: No security vulnerabilities
+- [ ] SC-5.5.5: Failure handling in place
+
+---
+
+## Step 6.5: Post-Test Self-Critique
+
+> **Trigger:** After Step 6 (Run Tests) passes
+> **Goal:** Ensure code quality, maintainability, and adherence to standards
+
+### Checklist Items
+
+```yaml
+post_test_critique:
+  - id: SC-6.5.1
+    category: patterns
+    question: 'Does the code follow existing patterns in the codebase?'
+    how_to_check:
+      - Compare with similar files in the project
+      - Check naming conventions match
+      - Directory structure follows conventions
+      - Import style consistent
+      - Error handling style matches existing
+    action_if_found: 'Refactor to match patterns'
+    severity: MEDIUM
+
+  - id: SC-6.5.2
+    category: configuration
+    question: 'Are there any hardcoded values that should be configurable?'
+    how_to_check:
+      - Magic numbers (should be named constants)
+      - URLs, endpoints (should be config/env)
+      - Timeouts, limits (should be configurable)
+      - Feature flags (should be toggleable)
+      - API keys (MUST be env vars)
+    action_if_found: 'Extract to constants/config/env'
+    severity: HIGH
+
+  - id: SC-6.5.3
+    category: testing
+    question: 'Are tests comprehensive enough?'
+    how_to_check:
+      - Happy path covered
+      - Error/exception paths covered
+      - Edge cases from 5.5.2 have tests
+      - Boundary values tested
+      - Integration points tested
+    action_if_found: 'Add missing tests'
+    severity: HIGH
+
+  - id: SC-6.5.4
+    category: documentation
+    question: 'Is documentation updated where needed?'
+    how_to_check:
+      - JSDoc/TSDoc for public functions
+      - Inline comments for complex logic
+      - README updated if behavior changed
+      - API docs if endpoints added/changed
+      - Type definitions accurate
+    action_if_found: 'Add documentation'
+    severity: MEDIUM
+
+  - id: SC-6.5.5
+    category: code_smells
+    question: 'Are there any code smells?'
+    how_to_check:
+      - Functions > 50 lines (should split)
+      - Duplicated code (should extract)
+      - Deep nesting > 3 levels (should flatten)
+      - Complex conditionals (should simplify)
+      - God objects (should decompose)
+      - Dead code (should remove)
+    action_if_found: 'Refactor to remove smell'
+    severity: MEDIUM
+
+  - id: SC-6.5.6
+    category: maintainability
+    question: 'Will this code be maintainable by others?'
+    how_to_check:
+      - Variable/function names self-documenting
+      - Logic easy to follow
+      - Single responsibility principle
+      - Dependencies explicit
+      - Side effects documented
+    action_if_found: 'Improve clarity'
+    severity: MEDIUM
+```
+
+### Execution Process
+
+```
+1. PAUSE after tests pass (Step 6 complete)
+2. Review ALL code against this checklist
+3. For EACH checklist item:
+   a. Ask yourself the question
+   b. Use "how_to_check" to verify
+   c. If issue found:
+      - Document it
+      - Fix the code
+      - Mark as fixed
+4. If ANY code changes were made:
+   - Return to Step 6 (re-run tests)
+   - If tests pass, continue checklist
+5. Only proceed when ALL items pass AND tests pass
+```
+
+### Pass Criteria
+
+- [ ] SC-6.5.1: Follows codebase patterns
+- [ ] SC-6.5.2: No inappropriate hardcoded values
+- [ ] SC-6.5.3: Tests are comprehensive
+- [ ] SC-6.5.4: Documentation is current
+- [ ] SC-6.5.5: No code smells
+- [ ] SC-6.5.6: Code is maintainable
+
+---
+
+## Summary Report Format
+
+After both self-critique phases complete, generate a summary:
+
+```markdown
+### Self-Critique Summary
+
+#### Step 5.5 (Post-Code)
+
+- **Status:** PASSED
+- **Issues Found:** 2
+- **Issues Fixed:** 2
+  - SC-5.5.2: Added null check for input array
+  - SC-5.5.3: Added try/catch for async operation
+
+#### Step 6.5 (Post-Test)
+
+- **Status:** PASSED
+- **Issues Found:** 1
+- **Issues Fixed:** 1
+  - SC-6.5.2: Extracted timeout to config constant
+- **Tests Re-run:** Yes (after fix)
+
+**Total Issues Found:** 3
+**Total Issues Fixed:** 3
+**Ready to Commit:** YES
+```
+
+---
+
+## Anti-Patterns to Avoid
+
+```yaml
+anti_patterns:
+  - name: 'Rubber Stamp'
+    description: "Marking all items as 'pass' without actually checking"
+    why_bad: 'Defeats the purpose of self-critique'
+    how_to_avoid: 'Actually re-read the code for each item'
+
+  - name: 'Defer to Tests'
+    description: "Skipping 5.5 because 'tests will catch it'"
+    why_bad: "Tests don't catch all issues (security, maintainability)"
+    how_to_avoid: 'Run 5.5 before tests, always'
+
+  - name: 'Skip on Simple Code'
+    description: "Skipping self-critique for 'simple' changes"
+    why_bad: 'Simple changes often have subtle bugs'
+    how_to_avoid: 'Run full checklist regardless of perceived simplicity'
+
+  - name: 'Infinite Loop'
+    description: 'Finding issues > 5 times in same checklist'
+    why_bad: 'Indicates fundamental approach problem'
+    how_to_avoid: 'If 5+ issues, stop and reconsider approach'
+```
+
+---
+
+## Integration with Coder Agent
+
+This checklist is referenced by:
+
+- `.grimoire/development/tasks/plan-execute-subtask.md`
+- `autoClaude.selfCritique.checklistRef: self-critique-checklist.md`
+
+Steps 5.5 and 6.5 in the Coder Agent workflow are MANDATORY gates. The subtask cannot proceed without passing these checkpoints.
+
+---
+
+## Skip Critique Flag (AC7 Story 4.4)
+
+### Usage
+
+```bash
+*execute-subtask ST-1.1 --skip-critique
+```
+
+### Configuration
+
+```yaml
+skip_critique:
+  flag: '--skip-critique'
+  aliases:
+    - '--no-critique'
+    - '--skip-review'
+
+  behavior:
+    - Skips both Step 5.5 and Step 6.5
+    - Logs warning to console and story file
+    - Records skip in self-critique JSON with reason "SKIPPED_BY_FLAG"
+    - Does NOT skip tests or linting (only self-review)
+
+  warning_message: |
+    ⚠️  WARNING: Self-critique skipped via --skip-critique flag
+
+    This bypasses mandatory quality gates:
+    - Step 5.5: Post-code bug/security review
+    - Step 6.5: Post-test pattern/quality review
+
+    Risks:
+    - Bugs may reach QA that would have been caught
+    - Security vulnerabilities may be introduced
+    - Code quality may degrade
+    - Technical debt may accumulate
+
+    Only use this flag when:
+    - Hotfix deployment with time constraint
+    - Trivial documentation-only changes
+    - Reverting a previous commit
+
+    This skip will be logged and visible in QA review.
+```
+
+### When to Use
+
+| Scenario                   | Recommended   |
+| -------------------------- | ------------- |
+| Hotfix in production       | ✅ Acceptable |
+| Documentation-only change  | ✅ Acceptable |
+| Reverting a commit         | ✅ Acceptable |
+| "I'm confident in my code" | ❌ Never      |
+| "Tests already pass"       | ❌ Never      |
+| "It's a simple change"     | ❌ Never      |
+| Time pressure              | ❌ Never      |
+
+### Audit Trail
+
+When `--skip-critique` is used, the following is recorded:
+
+```json
+{
+  "subtaskId": "ST-1.1",
+  "phase": "5.5",
+  "timestamp": "2026-01-28T10:00:00Z",
+  "passed": null,
+  "skipped": true,
+  "skipReason": "SKIPPED_BY_FLAG",
+  "skipWarningShown": true
+}
+```
+
+This audit trail is visible to QA during review and may result in additional scrutiny.
+
+---
+
+## Metadata
+
+```yaml
+metadata:
+  story: '4.3'
+  epic: 'Epic 4 - Execution Pipeline'
+  created: '2026-01-28'
+  author: '@dev (Dex)'
+  version: '1.0.0'
+  tags:
+    - self-critique
+    - quality
+    - coder-agent
+    - checklist
+```
+

package/.grimoire/product/checklists/story-dod-checklist.md

@@ -0,0 +1,102 @@
+# Story Definition of Done (DoD) Checklist
+
+## Instructions for Developer Agent
+
+Before marking a story as 'Review', please go through each item in this checklist. Report the status of each item (e.g., [x] Done, [ ] Not Done, [N/A] Not Applicable) and provide brief comments if necessary.
+
+[[LLM: INITIALIZATION INSTRUCTIONS - STORY DOD VALIDATION
+
+This checklist is for DEVELOPER AGENTS to self-validate their work before marking a story complete.
+
+IMPORTANT: This is a self-assessment. Be honest about what's actually done vs what should be done. It's better to identify issues now than have them found in review.
+
+EXECUTION APPROACH:
+
+1. Go through each section systematically
+2. Mark items as [x] Done, [ ] Not Done, or [N/A] Not Applicable
+3. Add brief comments explaining any [ ] or [N/A] items
+4. Be specific about what was actually implemented
+5. Flag any concerns or technical debt created
+
+The goal is quality delivery, not just checking boxes.]]
+
+## Checklist Items
+
+1. **Requirements Met:**
+
+   [[LLM: Be specific - list each requirement and whether it's complete]]
+
+   - [ ] All functional requirements specified in the story are implemented.
+   - [ ] All acceptance criteria defined in the story are met.
+
+2. **Coding Standards & Project Structure:**
+
+   [[LLM: Code quality matters for maintainability. Check each item carefully]]
+
+   - [ ] All new/modified code strictly adheres to `Operational Guidelines`.
+   - [ ] All new/modified code aligns with `Project Structure` (file locations, naming, etc.).
+   - [ ] Adherence to `Tech Stack` for technologies/versions used (if story introduces or modifies tech usage).
+   - [ ] Adherence to `Api Reference` and `Data Models` (if story involves API or data model changes).
+   - [ ] Basic security best practices (e.g., input validation, proper error handling, no hardcoded secrets) applied for new/modified code.
+   - [ ] No new linter errors or warnings introduced.
+   - [ ] Code is well-commented where necessary (clarifying complex logic, not obvious statements).
+
+3. **Testing:**
+
+   [[LLM: Testing proves your code works. Be honest about test coverage]]
+
+   - [ ] All required unit tests as per the story and `Operational Guidelines` Testing Strategy are implemented.
+   - [ ] All required integration tests (if applicable) as per the story and `Operational Guidelines` Testing Strategy are implemented.
+   - [ ] All tests (unit, integration, E2E if applicable) pass successfully.
+   - [ ] Test coverage meets project standards (if defined).
+
+4. **Functionality & Verification:**
+
+   [[LLM: Did you actually run and test your code? Be specific about what you tested]]
+
+   - [ ] Functionality has been manually verified by the developer (e.g., running the app locally, checking UI, testing API endpoints).
+   - [ ] Edge cases and potential error conditions considered and handled gracefully.
+
+5. **Story Administration:**
+
+   [[LLM: Documentation helps the next developer. What should they know?]]
+
+   - [ ] All tasks within the story file are marked as complete.
+   - [ ] Any clarifications or decisions made during development are documented in the story file or linked appropriately.
+   - [ ] The story wrap up section has been completed with notes of changes or information relevant to the next story or overall project, the agent model that was primarily used during development, and the changelog of any changes is properly updated.
+
+6. **Dependencies, Build & Configuration:**
+
+   [[LLM: Build issues block everyone. Ensure everything compiles and runs cleanly]]
+
+   - [ ] Project builds successfully without errors.
+   - [ ] Project linting passes
+   - [ ] Any new dependencies added were either pre-approved in the story requirements OR explicitly approved by the user during development (approval documented in story file).
+   - [ ] If new dependencies were added, they are recorded in the appropriate project files (e.g., `package.json`, `requirements.txt`) with justification.
+   - [ ] No known security vulnerabilities introduced by newly added and approved dependencies.
+   - [ ] If new environment variables or configurations were introduced by the story, they are documented and handled securely.
+
+7. **Documentation (If Applicable):**
+
+   [[LLM: Good documentation prevents future confusion. What needs explaining?]]
+
+   - [ ] Relevant inline code documentation (e.g., JSDoc, TSDoc, Python docstrings) for new public APIs or complex logic is complete.
+   - [ ] User-facing documentation updated, if changes impact users.
+   - [ ] Technical documentation (e.g., READMEs, system diagrams) updated if significant architectural changes were made.
+
+## Final Confirmation
+
+[[LLM: FINAL DOD SUMMARY
+
+After completing the checklist:
+
+1. Summarize what was accomplished in this story
+2. List any items marked as [ ] Not Done with explanations
+3. Identify any technical debt or follow-up work needed
+4. Note any challenges or learnings for future stories
+5. Confirm whether the story is truly ready for review
+
+Be honest - it's better to flag issues now than have them discovered later.]]
+
+- [ ] I, the Developer Agent, confirm that all applicable items above have been addressed.
+ 

package/.grimoire/product/checklists/story-draft-checklist.md

@@ -0,0 +1,216 @@
+# Story Draft Checklist
+
+The Scrum Master should use this checklist to validate that each story contains sufficient context for a developer agent to implement it successfully, while assuming the dev agent has reasonable capabilities to figure things out.
+
+[[LLM: INITIALIZATION INSTRUCTIONS - STORY DRAFT VALIDATION
+
+Before proceeding with this checklist, ensure you have access to:
+
+1. The story document being validated (usually in docs/stories/ or provided directly)
+2. The parent epic context
+3. Any referenced architecture or design documents
+4. Previous related stories if this builds on prior work
+
+IMPORTANT: This checklist validates individual stories BEFORE implementation begins.
+
+VALIDATION PRINCIPLES:
+
+1. Clarity - A developer should understand WHAT to build
+2. Context - WHY this is being built and how it fits
+3. Guidance - Key technical decisions and patterns to follow
+4. Testability - How to verify the implementation works
+5. Self-Contained - Most info needed is in the story itself
+
+REMEMBER: We assume competent developer agents who can:
+
+- Research documentation and codebases
+- Make reasonable technical decisions
+- Follow established patterns
+- Ask for clarification when truly stuck
+
+We're checking for SUFFICIENT guidance, not exhaustive detail.]]
+
+## 1. GOAL & CONTEXT CLARITY
+
+[[LLM: Without clear goals, developers build the wrong thing. Verify:
+
+1. The story states WHAT functionality to implement
+2. The business value or user benefit is clear
+3. How this fits into the larger epic/product is explained
+4. Dependencies are explicit ("requires Story X to be complete")
+5. Success looks like something specific, not vague]]
+
+- [ ] Story goal/purpose is clearly stated
+- [ ] Relationship to epic goals is evident
+- [ ] How the story fits into overall system flow is explained
+- [ ] Dependencies on previous stories are identified (if applicable)
+- [ ] Business context and value are clear
+
+## 2. TECHNICAL IMPLEMENTATION GUIDANCE
+
+[[LLM: Developers need enough technical context to start coding. Check:
+
+1. Key files/components to create or modify are mentioned
+2. Technology choices are specified where non-obvious
+3. Integration points with existing code are identified
+4. Data models or API contracts are defined or referenced
+5. Non-standard patterns or exceptions are called out
+
+Note: We don't need every file listed - just the important ones.]]
+
+- [ ] Key files to create/modify are identified (not necessarily exhaustive)
+- [ ] Technologies specifically needed for this story are mentioned
+- [ ] Critical APIs or interfaces are sufficiently described
+- [ ] Necessary data models or structures are referenced
+- [ ] Required environment variables are listed (if applicable)
+- [ ] Any exceptions to standard coding patterns are noted
+
+## 3. REFERENCE EFFECTIVENESS
+
+[[LLM: References should help, not create a treasure hunt. Ensure:
+
+1. References point to specific sections, not whole documents
+2. The relevance of each reference is explained
+3. Critical information is summarized in the story
+4. References are accessible (not broken links)
+5. Previous story context is summarized if needed]]
+
+- [ ] References to external documents point to specific relevant sections
+- [ ] Critical information from previous stories is summarized (not just referenced)
+- [ ] Context is provided for why references are relevant
+- [ ] References use consistent format (e.g., `docs/filename.md#section`)
+
+## 4. SELF-CONTAINMENT ASSESSMENT
+
+[[LLM: Stories should be mostly self-contained to avoid context switching. Verify:
+
+1. Core requirements are in the story, not just in references
+2. Domain terms are explained or obvious from context
+3. Assumptions are stated explicitly
+4. Edge cases are mentioned (even if deferred)
+5. The story could be understood without reading 10 other documents]]
+
+- [ ] Core information needed is included (not overly reliant on external docs)
+- [ ] Implicit assumptions are made explicit
+- [ ] Domain-specific terms or concepts are explained
+- [ ] Edge cases or error scenarios are addressed
+
+## 5. TESTING GUIDANCE
+
+[[LLM: Testing ensures the implementation actually works. Check:
+
+1. Test approach is specified (unit, integration, e2e)
+2. Key test scenarios are listed
+3. Success criteria are measurable
+4. Special test considerations are noted
+5. Acceptance criteria in the story are testable]]
+
+- [ ] Required testing approach is outlined
+- [ ] Key test scenarios are identified
+- [ ] Success criteria are defined
+- [ ] Special testing considerations are noted (if applicable)
+
+## 6. CODERABBIT INTEGRATION (CONDITIONAL)
+
+[[LLM: CONDITIONAL SECTION - Check `coderabbit_integration.enabled` in `.grimoire/core-config.yaml`
+
+**IF `coderabbit_integration.enabled: false`:**
+- SKIP this entire section (6)
+- Verify the story contains the skip notice:
+  > **CodeRabbit Integration**: Disabled
+- Mark section as N/A in validation result
+- Log: "ℹ️ CodeRabbit validation skipped - disabled in core-config.yaml"
+
+**IF `coderabbit_integration.enabled: true`:**
+- Validate ALL items below
+- Story must have complete CodeRabbit section including Story 6.3.3 Self-Healing
+
+CodeRabbit integration ensures automated code review and quality gates. Verify:
+
+1. The 🤖 CodeRabbit Integration section is present
+2. Story type is correctly identified (Database, API, Frontend, Deployment, Security, Architecture, Integration)
+3. Specialized agents are assigned appropriately (@dev required, type-specific agents as needed)
+4. Quality gates are defined (Pre-Commit required, Pre-PR/Pre-Deployment as applicable)
+5. Self-Healing Configuration (Story 6.3.3) is present with correct mode
+6. Focus areas match the story type]]
+
+**Section Presence:**
+- [ ] 🤖 CodeRabbit Integration section exists
+- [ ] All subsections are populated (Story Type Analysis, Specialized Agents, Quality Gates, Self-Healing, Focus Areas)
+
+**Story Type Analysis:**
+- [ ] Primary story type is correctly identified
+- [ ] Complexity level matches story scope
+- [ ] Secondary types listed if applicable
+
+**Specialized Agent Assignment:**
+- [ ] @dev listed as primary agent (required for all stories)
+- [ ] Type-specific agents assigned appropriately:
+  - Database stories → @db-sage
+  - Frontend stories → @ux-expert
+  - Deployment stories → @github-devops
+  - Security stories → @architect
+
+**Quality Gate Tasks:**
+- [ ] Pre-Commit (@dev) defined - REQUIRED for all stories
+- [ ] Pre-PR (@github-devops) defined if PR will be created
+- [ ] Pre-Deployment (@github-devops) defined for production stories
+
+**Self-Healing Configuration (Story 6.3.3):**
+- [ ] Self-healing configuration section is present
+- [ ] Mode matches primary agent:
+  - @dev: light mode (2 iterations, 15 min, CRITICAL only)
+  - @qa: full mode (3 iterations, 30 min, CRITICAL+HIGH)
+  - @github-devops: check mode (report only)
+- [ ] Severity behavior is documented
+
+**Focus Areas:**
+- [ ] Focus areas match the story type
+- [ ] Type-specific validations are listed
+
+## VALIDATION RESULT
+
+[[LLM: FINAL STORY VALIDATION REPORT
+
+Generate a concise validation report:
+
+1. Quick Summary
+
+   - Story readiness: READY / NEEDS REVISION / BLOCKED
+   - Clarity score (1-10)
+   - Major gaps identified
+
+2. Fill in the validation table with:
+
+   - PASS: Requirements clearly met
+   - PARTIAL: Some gaps but workable
+   - FAIL: Critical information missing
+
+3. Specific Issues (if any)
+
+   - List concrete problems to fix
+   - Suggest specific improvements
+   - Identify any blocking dependencies
+
+4. Developer Perspective
+   - Could YOU implement this story as written?
+   - What questions would you have?
+   - What might cause delays or rework?
+
+Be pragmatic - perfect documentation doesn't exist, but it must be enough to provide the extreme context a dev agent needs to get the work down and not create a mess.]]
+
+| Category                             | Status | Issues |
+| ------------------------------------ | ------ | ------ |
+| 1. Goal & Context Clarity            | _TBD_  |        |
+| 2. Technical Implementation Guidance | _TBD_  |        |
+| 3. Reference Effectiveness           | _TBD_  |        |
+| 4. Self-Containment Assessment       | _TBD_  |        |
+| 5. Testing Guidance                  | _TBD_  |        |
+| 6. CodeRabbit Integration (conditional) | _TBD_ or N/A |        |
+
+**Final Assessment:**
+
+- READY: The story provides sufficient context for implementation
+- NEEDS REVISION: The story requires updates (see issues)
+- BLOCKED: External information required (specify what information)
+