fraim-framework 2.0.48 → 2.0.51

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (24) hide show
  1. package/dist/registry/ai-manager-rules/implement-phases/implement-code.md +7 -10
  2. package/dist/registry/ai-manager-rules/implement-phases/implement-smoke.md +14 -7
  3. package/dist/registry/ai-manager-rules/implement-phases/implement-validate.md +12 -8
  4. package/dist/registry/ai-manager-rules/retrospective.md +116 -0
  5. package/dist/registry/ai-manager-rules/shared-phases/address-pr-feedback.md +188 -0
  6. package/dist/registry/ai-manager-rules/spec-phases/spec-competitor-analysis.md +105 -0
  7. package/dist/src/ai-manager/ai-manager.js +46 -42
  8. package/dist/src/ai-manager/phase-flow.js +54 -9
  9. package/dist/src/fraim/db-service.js +46 -0
  10. package/dist/src/fraim-mcp-server.js +159 -6
  11. package/dist/tests/test-ai-coach-edge-cases.js +10 -5
  12. package/dist/tests/test-ai-coach-mcp-integration.js +23 -5
  13. package/dist/tests/test-ai-coach-performance.js +3 -3
  14. package/dist/tests/test-ai-coach-workflows.js +45 -18
  15. package/dist/tests/test-pr-review-workflow.js +17 -9
  16. package/dist/tests/test-session-rehydration.js +5 -1
  17. package/dist/tests/test-telemetry.js +4 -0
  18. package/package.json +3 -1
  19. package/registry/scripts/create-website-structure.js +17 -2
  20. package/registry/scripts/profile-server.ts +1 -0
  21. package/registry/stubs/workflows/compliance/soc2-evidence-generator.md +11 -0
  22. package/registry/stubs/workflows/learning/build-skillset.md +11 -0
  23. package/registry/stubs/workflows/legal/contract-review-analysis.md +11 -0
  24. package/registry/stubs/workflows/legal/saas-contract-development.md +11 -0
@@ -177,19 +177,16 @@ Tag tests appropriately to ensure proper test suite execution:
177
177
  - **`unit`**: Tests that verify individual functions or classes in isolation
178
178
  - **`e2e`**: End-to-end tests that verify complete user workflows
179
179
 
180
- **Smoke Test Execution Rules:**
181
- If ANY tests are tagged "smoke" or you're modifying core functionality:
182
- 1. **MANDATORY**: Run full smoke test suite: `npm run test-smoke-ci`
183
- 2. **MANDATORY**: Include smoke test output in evidence
184
- 3. **MANDATORY**: All smoke tests must pass before proceeding
185
- 4. **BLOCKING**: Smoke test failures block phase completion
186
-
187
180
  ### Step 7: Basic Compilation Check
188
181
 
189
182
  **Verify code compiles:**
190
- ```bash
191
- npx tsc --noEmit --skipLibCheck
192
- ```
183
+
184
+ **Build Commands**: Always check `.fraim/config.json` first for `customizations.validation.buildCommand`, use that if available, otherwise default to `npm run build`.
185
+
186
+ **What to Look For**:
187
+ - Exit code 0 (success)
188
+ - No TypeScript compilation errors
189
+ - Clean build output
193
190
 
194
191
  **Must exit with code 0** (no errors)
195
192
 
@@ -23,16 +23,17 @@ All technical checks pass, confirming:
23
23
 
24
24
  ### Step 0: Read Project Validation Commands 📖
25
25
 
26
- **FIRST**: Read your project's validation commands from `.fraim/config.json`:
26
+ **FIRST**: Check your project's custom commands:
27
27
 
28
28
  ```bash
29
- # Read the config to get project-specific validation commands
30
- cat .fraim/config.json
31
- ```
29
+ # Check for custom build command
30
+ cat .fraim/config.json | grep -A 3 "buildCommand"
32
31
 
33
- Look for `customizations.validation.buildCommand` and `customizations.validation.smokeTestCommand`.
32
+ # Check for custom smoke test command
33
+ cat .fraim/config.json | grep -A 3 "smokeTestCommand"
34
+ ```
34
35
 
35
- **Use these commands instead of the generic ones below if they exist.**
36
+ **Use the configured commands if they exist, otherwise use the defaults shown below.**
36
37
 
37
38
  ### Step 1: Build Compilation Check ✅
38
39
 
@@ -43,7 +44,9 @@ Look for `customizations.validation.buildCommand` and `customizations.validation
43
44
 
44
45
  **Commands to Run** (use customizations.validation.buildCommand from config if available):
45
46
  ```bash
46
- # Run build (use customizations.validation.buildCommand if available, otherwise default)
47
+ # Use project-specific build command from .fraim/config.json if available:
48
+ # - Look for customizations.validation.buildCommand
49
+ # - Use that command if available, otherwise default to:
47
50
  npm run build
48
51
  ```
49
52
 
@@ -164,6 +167,7 @@ npm run build && npm test && git status
164
167
 
165
168
  ### Technical Standards
166
169
  - Read `.fraim/config.json` for the architecture document path (`customizations.architectureDoc`), then read the local architecture document to understand the full technical standards
170
+ - **Config Commands**: Always check `.fraim/config.json` first for `customizations.validation.buildCommand` and `customizations.validation.smokeTestCommand`, use those if available, otherwise use defaults
167
171
  - Use Successful Debugging Patterns from `rules/successful-debugging-patterns.md` via `get_fraim_file`
168
172
  - When using git commands directly (if MCP tools unavailable), read `rules/git-safe-commands.md` via `get_fraim_file`
169
173
 
@@ -181,6 +185,9 @@ npm run build && npm test && git status
181
185
 
182
186
  **Run smoke tests specifically:**
183
187
  ```bash
188
+ # Use project-specific command from .fraim/config.json if available
189
+ # Check: cat .fraim/config.json | grep "smokeTestCommand"
190
+ # Use configured command or default to:
184
191
  npm run test-smoke-ci
185
192
  ```
186
193
 
@@ -18,6 +18,10 @@ This is THE critical phase where you prove your implementation actually works. N
18
18
 
19
19
  ## RULES FOR THIS PHASE
20
20
 
21
+ ### Config-Aware Testing
22
+ **CRITICAL**: Always check `.fraim/config.json` first for project-specific test commands:
23
+ - `customizations.validation.testSuiteCommand` - Use this for comprehensive testing (default: `npm test`)
24
+
21
25
  ### Success Criteria
22
26
  Read `registry/rules/agent-success-criteria.md` via `get_fraim_file` for the complete framework. Focus on:
23
27
  - **Integrity** (honest reporting of validation results - never claim something works if you didn't test it)
@@ -86,17 +90,17 @@ grep -r "as any" src/ || echo "✅ No type bypassing found"
86
90
 
87
91
  **Commands to Run** (check .fraim/config.json for project-specific commands first):
88
92
  ```bash
89
- # 1. FIRST: Read your project's validation commands from .fraim/config.json
90
- cat .fraim/config.json | grep -A 10 "validation"
93
+ # 1. FIRST: Check for custom test commands
94
+ cat .fraim/config.json | grep -A 5 "validation"
91
95
 
92
- # 2. Run the comprehensive test suite (this runs ALL tests)
96
+ # 2. Run comprehensive test suite for current work
97
+ # Use customizations.validation.testSuiteCommand if available, otherwise:
93
98
  npm test
94
99
 
95
- # 3. Also run smoke tests specifically to verify core functionality
96
- npm run test-smoke-ci
97
-
98
- # 4. Run all tests in CI mode for complete coverage
99
- npm run test-all-ci
100
+ # 3. Run targeted tests for your specific changes (if applicable)
101
+ # Example: If you modified user authentication, run auth-related tests
102
+ # npm run test -- --grep "auth"
103
+ # OR: npm run test test-{issue-number}-*.ts
100
104
  ```
101
105
 
102
106
  **What to Look For**:
@@ -0,0 +1,116 @@
1
+ # Phase: Retrospective
2
+
3
+ ## INTENT
4
+ To conduct a comprehensive retrospective of the completed work while full context is available, capturing learnings and insights before branch cleanup and resolution. This phase applies to all workflow types (spec, design, implement, test).
5
+
6
+ ## TRIGGER
7
+ This phase is triggered after PR approval (`wait-for-pr-review` completion) and before `resolve` phase for all workflow types.
8
+
9
+ ## CONTEXT ADVANTAGES
10
+ - **Full Work Context**: All changes, decisions, and challenges are fresh in memory
11
+ - **Branch Available**: Can reference specific commits, diffs, and work artifacts
12
+ - **Problem-Solution Mapping**: Clear connection between original problem and completed solution
13
+ - **Fresh Insights**: Recent experience provides accurate reflection on what worked/didn't work
14
+ - **PR Feedback Available**: Can analyze and learn from user feedback received during review
15
+ - **Complete Journey**: Can analyze entire workflow from start to finish
16
+
17
+ ## WORKFLOW
18
+
19
+ ### Step 1: Retrospective Preparation
20
+ - Ensure PR is approved and ready for merge
21
+ - Gather work artifacts (commits, documents, test results, etc.)
22
+ - Review original issue requirements and acceptance criteria
23
+ - **Collect PR feedback**: Review all comments, suggestions, and feedback received during PR review
24
+ - Analyze user feedback patterns and themes
25
+ - Identify key decision points and challenges encountered
26
+
27
+ ### Step 2: Create Retrospective Document
28
+ - Create (or use existing) retrospective file: `retrospectives/issue-{issue-number}-{kebab-title}-postmortem.md`
29
+ - Use retrospective template: `get_fraim_file({ path: "templates/retrospective/RETROSPECTIVE-TEMPLATE.md" })`
30
+ - Document while work context is fresh and complete
31
+
32
+ ### Step 3: Work Analysis
33
+ - **What Went Well**: Successful approaches, tools, and techniques used
34
+ - **What Went Poorly**: Challenges, obstacles, and inefficiencies encountered
35
+ - **Root Cause Analysis**: Why problems occurred, not just what happened
36
+ - **Decision Analysis**: Review key decisions made during the work
37
+ - **PR Feedback Analysis**: What user feedback revealed about the work quality
38
+ - **Process Effectiveness**: How well the workflow supported the work
39
+
40
+ ### Step 4: Learning Extraction
41
+ - **Key Learnings**: Specific insights that can help future work of this type
42
+ - **Process Improvements**: Workflow or rule changes that would help
43
+ - **Tool/Technique Discoveries**: New approaches or tools that proved valuable
44
+ - **Anti-Patterns Identified**: Approaches to avoid in future work
45
+ - **User Feedback Patterns**: Common themes in user feedback to address
46
+ - **Quality Insights**: What contributed to or detracted from work quality
47
+
48
+ ### Step 5: Prevention Measures
49
+ - **Specific Actions**: Concrete steps to prevent similar issues in future work
50
+ - **Rule Updates**: Suggestions for updating FRAIM rules or workflows
51
+ - **Knowledge Sharing**: Insights that should be shared with other agents
52
+ - **Process Enhancements**: Workflow improvements based on experience
53
+ - **Feedback Integration**: How to better incorporate user feedback in future work
54
+ - **Quality Improvements**: Changes to improve work quality
55
+
56
+ ### Step 6: Validation and Completion
57
+ - Ensure retrospective meets quality criteria
58
+ - Validate all template sections are complete
59
+ - Confirm learnings are actionable and specific
60
+ - Verify PR feedback has been analyzed and learned from
61
+ - Check that prevention measures are concrete and implementable
62
+ - Mark phase complete and proceed to resolve
63
+
64
+ ## VALIDATION CRITERIA
65
+ - ✅ Retrospective document created using template
66
+ - ✅ Root cause analysis completed (not just symptoms)
67
+ - ✅ Prevention measures documented and actionable
68
+ - ✅ Key learnings extracted and documented
69
+ - ✅ Process improvements identified
70
+ - ✅ PR feedback analyzed and lessons captured
71
+ - ✅ All template sections completed with substantial content
72
+ - ✅ Retrospective quality meets standards
73
+ - ✅ Learnings are specific to the workflow type and transferable
74
+
75
+ ## PHASE COMPLETION
76
+ This phase is complete when:
77
+ 1. Comprehensive retrospective document is created
78
+ 2. All validation criteria are met
79
+ 3. Learnings are documented for future reference
80
+ 4. PR feedback has been systematically analyzed
81
+ 5. Prevention measures are specific and actionable
82
+ 6. Process improvements are identified
83
+ 7. Agent is ready to proceed to resolve phase
84
+
85
+ ## WORKFLOW-SPECIFIC FOCUS AREAS
86
+
87
+ ### Spec Retrospective Focus
88
+ - Requirements gathering effectiveness
89
+ - Stakeholder engagement quality
90
+ - Competitive analysis thoroughness
91
+ - User experience definition clarity
92
+ - Validation plan completeness
93
+
94
+ ### Design Retrospective Focus
95
+ - Technical decision quality
96
+ - Architecture choice rationale
97
+ - Design review feedback incorporation
98
+ - Technical feasibility assessment
99
+ - Implementation guidance clarity
100
+
101
+ ### Implement Retrospective Focus
102
+ - Code quality and maintainability
103
+ - Technical approach effectiveness
104
+ - Testing strategy success
105
+ - Performance considerations
106
+ - Integration challenges
107
+
108
+ ### Test Retrospective Focus
109
+ - Test coverage adequacy
110
+ - Quality assurance approach effectiveness
111
+ - Testing strategy validation
112
+ - Bug detection capability
113
+ - Test maintenance considerations
114
+
115
+ ## NEXT PHASE
116
+ After completing retrospective, proceed to `resolve` phase for final merge and cleanup.
@@ -0,0 +1,188 @@
1
+ # Phase: address-pr-feedback
2
+
3
+ ## INTENT
4
+ To systematically address all PR feedback items by making targeted changes, replying to comments, and preparing for re-validation.
5
+
6
+ ## OUTCOME
7
+ All PR feedback addressed with:
8
+ - Targeted changes made for each feedback item
9
+ - Feedback file updated with resolutions
10
+ - PR comments replied to with explanations
11
+ - Changes validated and ready for re-review
12
+
13
+ ## RULES FOR THIS PHASE
14
+
15
+ ### Success Criteria
16
+ Read `registry/rules/agent-success-criteria.md` via `get_fraim_file` for the complete framework. Focus especially on:
17
+ - **Integrity** (document all changes made)
18
+ - **Correctness** (address feedback accurately)
19
+ - **Completeness** (address every UNADDRESSED item)
20
+
21
+ ### Simplicity Principles
22
+ Read `registry/rules/simplicity.md` via `get_fraim_file` for complete guidelines. Critical for feedback phase:
23
+ - **Targeted Changes**: Make minimal changes to address specific feedback
24
+ - **Manual Validation**: Test changes manually before updating PR
25
+ - **Clear Communication**: Reply to each comment with clear explanations
26
+
27
+ ## PRINCIPLES
28
+ - **Feedback-Driven**: Address only the specific issues raised in PR comments
29
+ - **Minimal Changes**: Avoid scope creep or unnecessary refactoring
30
+ - **Clear Communication**: Explain resolutions clearly to reviewers
31
+ - **Validation**: Ensure changes work before updating PR
32
+
33
+ ## 📋 WORKFLOW
34
+
35
+ ### Step 1: Read PR Feedback File
36
+
37
+ **MANDATORY**: Read the feedback file created by `wait-for-pr-review`:
38
+ - File location: `docs/evidence/{issue_number}-{workflow_type}-feedback.md`
39
+ - Identify all UNADDRESSED feedback items
40
+ - Understand the context and requirements for each item
41
+
42
+ ### Step 2: Address Each Feedback Item
43
+
44
+ **For each UNADDRESSED item:**
45
+
46
+ 1. **Understand the Feedback**:
47
+ - Read the comment carefully
48
+ - Identify what specific change is requested
49
+ - Determine the scope of the change needed
50
+
51
+ 2. **Make Targeted Changes**:
52
+ - Make minimal, focused changes to address the specific feedback
53
+ - Avoid unrelated changes or improvements
54
+ - Keep changes as small as possible while fully addressing the feedback
55
+
56
+ 3. **Update Feedback File**:
57
+ - Change status from UNADDRESSED to ADDRESSED
58
+ - Document your resolution approach
59
+ - Include details of what you changed
60
+
61
+ **Feedback File Update Format**:
62
+ ```markdown
63
+ ### Comment X - ADDRESSED
64
+ - **Author**: reviewer_name
65
+ - **Type**: pr_comment|review_comment|review
66
+ - **File**: file_path (if applicable)
67
+ - **Line**: line_number (if applicable)
68
+ - **Comment**: Original feedback text
69
+ - **Status**: ADDRESSED
70
+ - **Resolution**: Detailed explanation of how you addressed this feedback
71
+ - **Changes Made**: Specific files/lines modified
72
+ ```
73
+
74
+ ### Step 3: Validate Changes
75
+
76
+ **Test your changes:**
77
+ - Run compilation check: `npx tsc --noEmit --skipLibCheck`
78
+ - Run relevant tests to ensure no regressions
79
+ - Test manually if the feedback involves UI/API behavior
80
+ - Verify the specific issue mentioned in feedback is resolved
81
+
82
+ ### Step 4: Reply to PR Comments
83
+
84
+ **For each addressed comment:**
85
+ - Reply to the original PR comment
86
+ - Explain what you changed and how it addresses their concern
87
+ - Reference specific files/lines if helpful
88
+ - Be clear and professional in your communication
89
+
90
+ **Example reply format**:
91
+ ```
92
+ ✅ **Addressed**: [Brief description of what you changed]
93
+
94
+ **Changes made**:
95
+ - [Specific change 1]
96
+ - [Specific change 2]
97
+
98
+ **Files modified**: `path/to/file.ts`, `path/to/test.ts`
99
+
100
+ This should resolve the [specific issue mentioned]. Please let me know if you need any clarification!
101
+ ```
102
+
103
+ ### Step 5: Commit and Push Changes
104
+
105
+ **Commit your changes:**
106
+ - Use clear commit messages that reference the feedback
107
+ - Example: `Address PR feedback: Fix error handling in auth service`
108
+ - Push changes to the PR branch
109
+
110
+ ## 📸 EVIDENCE REQUIREMENTS
111
+
112
+ You MUST provide concrete evidence for all claims:
113
+
114
+ 1. **All Feedback Addressed**: Every UNADDRESSED item in feedback file is now ADDRESSED
115
+ 2. **Changes Made**: Specific code changes made for each feedback item
116
+ 3. **Validation Complete**: Tests pass and changes work as expected
117
+ 4. **PR Updated**: Changes committed, pushed, and comments replied to
118
+
119
+ ## VALIDATION
120
+
121
+ ### Phase Complete When:
122
+ - ✅ All UNADDRESSED items in feedback file are now ADDRESSED
123
+ - ✅ Feedback file updated with resolution details for each item
124
+ - ✅ Targeted changes made to address each specific feedback
125
+ - ✅ Changes validated (compilation, tests, manual testing)
126
+ - ✅ PR comments replied to with clear explanations
127
+ - ✅ Changes committed and pushed to PR branch
128
+
129
+ ### Phase Incomplete If:
130
+ - ❌ Any UNADDRESSED items remain in feedback file
131
+ - ❌ Changes don't actually address the feedback given
132
+ - ❌ Tests failing after changes
133
+ - ❌ Compilation errors introduced
134
+ - ❌ PR comments not replied to
135
+ - ❌ Changes not committed/pushed
136
+
137
+ ### Report Back:
138
+ When you complete this phase, call:
139
+
140
+ ```javascript
141
+ seekCoachingOnNextStep({
142
+ workflowType: "{workflow_type}",
143
+ issueNumber: "{issue_number}",
144
+ currentPhase: "address-pr-feedback",
145
+ status: "complete",
146
+ findings: {
147
+ feedbackItemsAddressed: {total_items_addressed},
148
+ changesValidated: true
149
+ },
150
+ evidence: {
151
+ feedbackFileUpdated: "All UNADDRESSED items now ADDRESSED with resolutions",
152
+ changesMade: "Brief summary of changes made",
153
+ validationResults: "Compilation and tests pass",
154
+ prCommentsReplied: "Replied to all PR comments with explanations"
155
+ }
156
+ })
157
+ ```
158
+
159
+ If feedback addressing incomplete, iterate:
160
+ ```javascript
161
+ seekCoachingOnNextStep({
162
+ workflowType: "{workflow_type}",
163
+ issueNumber: "{issue_number}",
164
+ currentPhase: "address-pr-feedback",
165
+ status: "incomplete",
166
+ findings: {
167
+ uncertainties: ["Issues encountered", "What needs to be fixed"]
168
+ }
169
+ })
170
+ ```
171
+
172
+ ## SCRIPTS
173
+
174
+ **Compile TypeScript:**
175
+ ```bash
176
+ npx tsc --noEmit --skipLibCheck
177
+ ```
178
+
179
+ **Run tests:**
180
+ ```bash
181
+ npm test
182
+ ```
183
+
184
+ **Check git status:**
185
+ ```bash
186
+ git status
187
+ git diff
188
+ ```
@@ -0,0 +1,105 @@
1
+ # Phase: spec-competitor-analysis
2
+
3
+ ## INTENT
4
+ To conduct systematic competitive research and analysis for the feature being specified, ensuring comprehensive understanding of competitive landscape and clear differentiation strategy.
5
+
6
+ ## OUTCOME
7
+ A comprehensive competitive analysis that:
8
+ - Documents all configured competitors and their approaches
9
+ - Identifies new competitors through systematic research
10
+ - Proposes configuration updates with user approval
11
+ - Defines clear differentiation strategy and competitive positioning
12
+ - Updates the specification with complete competitive landscape analysis
13
+
14
+ ## TRIGGER
15
+ This phase is triggered after `spec-spec` completion and before `spec-completeness-review`.
16
+
17
+ ## CONTEXT ADVANTAGES
18
+ - **Full Feature Context**: Complete understanding of proposed feature and requirements
19
+ - **Fresh Research**: Current competitive landscape information
20
+ - **Strategic Positioning**: Ability to influence feature design based on competitive insights
21
+ - **Configuration-Driven**: Systematic analysis of known competitors plus discovery of new ones
22
+
23
+ ## WORKFLOW
24
+
25
+ ### Step 1: Load Competitor Configuration
26
+ - Read `.fraim/config.json` competitors section
27
+ - Extract configured competitors and their competitive spaces
28
+ - Note any existing competitive intelligence
29
+
30
+ ### Step 2: Research Configured Competitors
31
+ For each competitor in config:
32
+ - Research their current solution for this feature area
33
+ - Analyze their strengths and weaknesses in this space
34
+ - Gather customer feedback and reviews
35
+ - Assess market position and pricing approach
36
+ - Document findings in structured format
37
+
38
+ ### Step 3: Discover Additional Competitors
39
+ - Use web search to find other competitors in the feature space
40
+ - Research market for competitors not in configuration
41
+ - Identify direct, adjacent, and emerging competitors
42
+ - Focus on competitors specifically relevant to this feature
43
+
44
+ ### Step 4: Competitor Configuration Updates
45
+ - **Identify New Competitors**: Present newly discovered competitors to user
46
+ - **Configuration Proposal**: Suggest adding relevant competitors to `.fraim/config.json`
47
+ - **User Approval**: Ask user to approve additions: "Found new competitor 'X' in space 'Y'. Add to config?"
48
+ - **Auto-Update**: If user approves, automatically update configuration file
49
+ - **Documentation**: Note configuration changes in competitive analysis
50
+
51
+ ### Step 5: Competitive Analysis
52
+ - Compare competitor approaches to our proposed solution
53
+ - Identify competitive advantages and disadvantages
54
+ - Develop differentiation strategy
55
+ - Plan competitive response strategies
56
+ - Define market positioning approach
57
+
58
+ ### Step 6: Update Specification
59
+ - Update Competitive Landscape section with findings
60
+ - Ensure all configured competitors are covered
61
+ - Include newly discovered competitors
62
+ - Add competitive positioning strategy
63
+ - Document research sources and methodology
64
+ - Validate analysis completeness
65
+
66
+ ## VALIDATION
67
+
68
+ ### Phase Complete When:
69
+ - ✅ All configured competitors analyzed
70
+ - ✅ Additional competitors discovered through research
71
+ - ✅ User consulted on adding new competitors to config
72
+ - ✅ Configuration updated with user-approved competitors
73
+ - ✅ Competitive positioning strategy defined
74
+ - ✅ Differentiation advantages clearly articulated
75
+ - ✅ Research sources documented
76
+ - ✅ Analysis covers both configured and discovered competitors
77
+ - ✅ Specification competitive landscape section updated
78
+
79
+ ### Report Back:
80
+ When this phase is complete, call:
81
+ ```javascript
82
+ seekCoachingOnNextStep({
83
+ workflowType: "spec",
84
+ issueNumber: "your-issue-number",
85
+ currentPhase: "spec-competitor-analysis",
86
+ status: "complete",
87
+ evidence: {
88
+ competitorsAnalyzed: ["competitor1", "competitor2"],
89
+ newCompetitorsFound: ["new-competitor1"],
90
+ configurationUpdated: true,
91
+ differentiationStrategy: "summary of strategy",
92
+ specificationUpdated: true
93
+ }
94
+ })
95
+ ```
96
+
97
+ ### Phase Incomplete If:
98
+ - Configuration competitors not fully researched
99
+ - No additional competitor discovery attempted
100
+ - User not consulted on configuration updates
101
+ - Competitive positioning strategy missing
102
+ - Specification not updated with findings
103
+
104
+ ## NEXT PHASE
105
+ After completing competitor-analysis, proceed to `spec-completeness-review` phase.
@@ -155,8 +155,11 @@ ${this.getValidPhasesForIssueType(issueType).join(' → ')}
155
155
  * Generate completion message for completed phases
156
156
  */
157
157
  async generateCompletionMessage(args) {
158
- // Handle workflow completion for wait-for-pr-review phase when PR is approved
159
- if (args.currentPhase === 'wait-for-pr-review') {
158
+ // Determine next phase and provide its instructions
159
+ const issueType = this.extractIssueType(args.findings, args.evidence);
160
+ const nextPhase = (0, phase_flow_js_1.getNextPhase)(args.currentPhase, args.workflowType, issueType);
161
+ if (!nextPhase) {
162
+ // This is the final phase - show completion message
160
163
  return `# 🎉 ${args.workflowType.charAt(0).toUpperCase() + args.workflowType.slice(1)} Complete!
161
164
 
162
165
  **Congratulations!** You have successfully completed all ${args.workflowType} phases for issue #${args.issueNumber}.
@@ -165,30 +168,11 @@ ${this.getValidPhasesForIssueType(issueType).join(' → ')}
165
168
  ${this.getAccomplishmentsForWorkflow(args.workflowType)}
166
169
 
167
170
  ## 📋 Final Evidence Summary
168
- ${JSON.stringify(args.evidence || {}, null, 2)}
171
+ ${JSON.stringify(args.evidence || args.findings || {}, null, 2)}
169
172
 
170
173
  `;
171
174
  }
172
175
  else {
173
- // Determine next phase and provide its instructions
174
- const issueType = this.extractIssueType(args.findings, args.evidence);
175
- const nextPhase = (0, phase_flow_js_1.getNextPhase)(args.currentPhase, args.workflowType, issueType);
176
- if (!nextPhase) {
177
- return `# 🎉 Phase Complete!
178
-
179
- **Phase:** ${args.currentPhase}
180
- **Status:** Complete
181
-
182
- Great work! You've completed the ${args.currentPhase} phase.
183
-
184
- ## Evidence Summary
185
- ${JSON.stringify(args.evidence || args.findings || {}, null, 2)}
186
-
187
- ## 🚨 Error: No Next Phase Found
188
- Unable to determine the next phase. This might indicate an issue with the phase flow logic.
189
- Please check your workflow type and current phase.
190
- `;
191
- }
192
176
  // Get instructions for the next phase
193
177
  const nextPhaseInstructions = await this.getPhaseInstructions(nextPhase, args.workflowType);
194
178
  return `# 🎉 Phase Complete!
@@ -351,9 +335,20 @@ Remember: Take your time and follow each step carefully. The phase guidance cont
351
335
  */
352
336
  async getPhaseInstructions(phase, workflowType) {
353
337
  try {
354
- // Read phase instructions from .md files based on workflow type
338
+ // Special handling for shared phases
339
+ const sharedPhases = ['retrospective', 'submit-pr', 'wait-for-pr-review', 'address-pr-feedback'];
355
340
  let phasePath;
356
- if (workflowType === 'implement') {
341
+ if (sharedPhases.includes(phase)) {
342
+ // Check if it's in root ai-manager-rules directory (like retrospective)
343
+ if (phase === 'retrospective') {
344
+ phasePath = `ai-manager-rules/${phase}.md`;
345
+ }
346
+ else {
347
+ // Other shared phases are in shared-phases subdirectory
348
+ phasePath = `ai-manager-rules/shared-phases/${phase}.md`;
349
+ }
350
+ }
351
+ else if (workflowType === 'implement') {
357
352
  phasePath = `ai-manager-rules/implement-phases/${phase}.md`;
358
353
  }
359
354
  else {
@@ -364,26 +359,35 @@ Remember: Take your time and follow each step carefully. The phase guidance cont
364
359
  if (phaseFile && (0, fs_1.existsSync)(phaseFile.fullPath)) {
365
360
  return (0, fs_1.readFileSync)(phaseFile.fullPath, 'utf8');
366
361
  }
367
- // If not found in workflow-specific directory, try shared-phases
368
- const sharedPhasePath = `ai-manager-rules/shared-phases/${phase}.md`;
369
- phaseFile = this.fileIndex.get(sharedPhasePath);
370
- if (phaseFile && (0, fs_1.existsSync)(phaseFile.fullPath)) {
371
- return (0, fs_1.readFileSync)(phaseFile.fullPath, 'utf8');
362
+ // If not found and not a shared phase, try shared-phases directory
363
+ if (!sharedPhases.includes(phase)) {
364
+ const sharedPhasePath = `ai-manager-rules/shared-phases/${phase}.md`;
365
+ phaseFile = this.fileIndex.get(sharedPhasePath);
366
+ if (phaseFile && (0, fs_1.existsSync)(phaseFile.fullPath)) {
367
+ return (0, fs_1.readFileSync)(phaseFile.fullPath, 'utf8');
368
+ }
372
369
  }
373
370
  // Fallback: try to read directly from filesystem
374
371
  const { join } = require('path');
375
- const possiblePaths = [
376
- // Try workflow-specific paths first
377
- join(process.cwd(), 'dist', 'registry', phasePath),
378
- join(process.cwd(), 'registry', phasePath),
379
- join(__dirname, '..', '..', 'registry', phasePath),
380
- join(__dirname, '..', 'registry', phasePath),
381
- // Try shared-phases paths
382
- join(process.cwd(), 'dist', 'registry', sharedPhasePath),
383
- join(process.cwd(), 'registry', sharedPhasePath),
384
- join(__dirname, '..', '..', 'registry', sharedPhasePath),
385
- join(__dirname, '..', 'registry', sharedPhasePath)
386
- ];
372
+ const possiblePaths = [];
373
+ if (sharedPhases.includes(phase)) {
374
+ if (phase === 'retrospective') {
375
+ // Retrospective is in root ai-manager-rules directory
376
+ possiblePaths.push(join(process.cwd(), 'dist', 'registry', `ai-manager-rules/${phase}.md`), join(process.cwd(), 'registry', `ai-manager-rules/${phase}.md`), join(__dirname, '..', '..', 'registry', `ai-manager-rules/${phase}.md`), join(__dirname, '..', 'registry', `ai-manager-rules/${phase}.md`));
377
+ }
378
+ else {
379
+ // Other shared phases are in shared-phases subdirectory
380
+ const sharedPhasePath = `ai-manager-rules/shared-phases/${phase}.md`;
381
+ possiblePaths.push(join(process.cwd(), 'dist', 'registry', sharedPhasePath), join(process.cwd(), 'registry', sharedPhasePath), join(__dirname, '..', '..', 'registry', sharedPhasePath), join(__dirname, '..', 'registry', sharedPhasePath));
382
+ }
383
+ }
384
+ else {
385
+ // For workflow-specific phases
386
+ possiblePaths.push(join(process.cwd(), 'dist', 'registry', phasePath), join(process.cwd(), 'registry', phasePath), join(__dirname, '..', '..', 'registry', phasePath), join(__dirname, '..', 'registry', phasePath));
387
+ // Also try shared-phases directory
388
+ const sharedPhasePath = `ai-manager-rules/shared-phases/${phase}.md`;
389
+ possiblePaths.push(join(process.cwd(), 'dist', 'registry', sharedPhasePath), join(process.cwd(), 'registry', sharedPhasePath), join(__dirname, '..', '..', 'registry', sharedPhasePath), join(__dirname, '..', 'registry', sharedPhasePath));
390
+ }
387
391
  for (const fullPath of possiblePaths) {
388
392
  if ((0, fs_1.existsSync)(fullPath)) {
389
393
  console.log(`📖 AI Coach: Reading phase file from ${fullPath}`);
@@ -392,7 +396,7 @@ Remember: Take your time and follow each step carefully. The phase guidance cont
392
396
  }
393
397
  return `# Phase: ${phase}
394
398
 
395
- **Error**: Phase instructions not found at ${phasePath} or ${sharedPhasePath}
399
+ **Error**: Phase instructions not found
396
400
 
397
401
  Tried paths:
398
402
  ${possiblePaths.map(p => `- ${p}`).join('\n')}