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.
- package/dist/registry/ai-manager-rules/implement-phases/implement-code.md +7 -10
- package/dist/registry/ai-manager-rules/implement-phases/implement-smoke.md +14 -7
- package/dist/registry/ai-manager-rules/implement-phases/implement-validate.md +12 -8
- package/dist/registry/ai-manager-rules/retrospective.md +116 -0
- package/dist/registry/ai-manager-rules/shared-phases/address-pr-feedback.md +188 -0
- package/dist/registry/ai-manager-rules/spec-phases/spec-competitor-analysis.md +105 -0
- package/dist/src/ai-manager/ai-manager.js +46 -42
- package/dist/src/ai-manager/phase-flow.js +54 -9
- package/dist/src/fraim/db-service.js +46 -0
- package/dist/src/fraim-mcp-server.js +159 -6
- package/dist/tests/test-ai-coach-edge-cases.js +10 -5
- package/dist/tests/test-ai-coach-mcp-integration.js +23 -5
- package/dist/tests/test-ai-coach-performance.js +3 -3
- package/dist/tests/test-ai-coach-workflows.js +45 -18
- package/dist/tests/test-pr-review-workflow.js +17 -9
- package/dist/tests/test-session-rehydration.js +5 -1
- package/dist/tests/test-telemetry.js +4 -0
- package/package.json +3 -1
- package/registry/scripts/create-website-structure.js +17 -2
- package/registry/scripts/profile-server.ts +1 -0
- package/registry/stubs/workflows/compliance/soc2-evidence-generator.md +11 -0
- package/registry/stubs/workflows/learning/build-skillset.md +11 -0
- package/registry/stubs/workflows/legal/contract-review-analysis.md +11 -0
- 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
|
-
|
|
191
|
-
|
|
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**:
|
|
26
|
+
**FIRST**: Check your project's custom commands:
|
|
27
27
|
|
|
28
28
|
```bash
|
|
29
|
-
#
|
|
30
|
-
cat .fraim/config.json
|
|
31
|
-
```
|
|
29
|
+
# Check for custom build command
|
|
30
|
+
cat .fraim/config.json | grep -A 3 "buildCommand"
|
|
32
31
|
|
|
33
|
-
|
|
32
|
+
# Check for custom smoke test command
|
|
33
|
+
cat .fraim/config.json | grep -A 3 "smokeTestCommand"
|
|
34
|
+
```
|
|
34
35
|
|
|
35
|
-
**Use
|
|
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
|
-
#
|
|
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:
|
|
90
|
-
cat .fraim/config.json | grep -A
|
|
93
|
+
# 1. FIRST: Check for custom test commands
|
|
94
|
+
cat .fraim/config.json | grep -A 5 "validation"
|
|
91
95
|
|
|
92
|
-
# 2. Run
|
|
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.
|
|
96
|
-
|
|
97
|
-
|
|
98
|
-
#
|
|
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
|
-
//
|
|
159
|
-
|
|
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
|
-
//
|
|
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 (
|
|
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
|
|
368
|
-
|
|
369
|
-
|
|
370
|
-
|
|
371
|
-
|
|
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
|
-
|
|
377
|
-
|
|
378
|
-
|
|
379
|
-
|
|
380
|
-
|
|
381
|
-
|
|
382
|
-
|
|
383
|
-
|
|
384
|
-
|
|
385
|
-
|
|
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
|
|
399
|
+
**Error**: Phase instructions not found
|
|
396
400
|
|
|
397
401
|
Tried paths:
|
|
398
402
|
${possiblePaths.map(p => `- ${p}`).join('\n')}
|