fraim-framework 2.0.43 → 2.0.45
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/bin/fraim.js +1 -1
- package/dist/registry/ai-manager-rules/design-phases/design-completeness-review.md +73 -0
- package/dist/registry/ai-manager-rules/design-phases/design-design.md +145 -0
- package/dist/registry/ai-manager-rules/design-phases/design.md +108 -0
- package/dist/registry/ai-manager-rules/design-phases/finalize.md +60 -0
- package/dist/registry/ai-manager-rules/design-phases/validate.md +125 -0
- package/dist/registry/ai-manager-rules/implement-phases/code.md +323 -0
- package/dist/registry/ai-manager-rules/implement-phases/completeness-review.md +94 -0
- package/dist/registry/ai-manager-rules/implement-phases/finalize.md +177 -0
- package/dist/registry/ai-manager-rules/implement-phases/implement-code.md +286 -0
- package/dist/registry/ai-manager-rules/implement-phases/implement-completeness-review.md +120 -0
- package/dist/registry/ai-manager-rules/implement-phases/implement-regression.md +173 -0
- package/dist/registry/ai-manager-rules/implement-phases/implement-repro.md +104 -0
- package/dist/registry/ai-manager-rules/implement-phases/implement-scoping.md +100 -0
- package/dist/registry/ai-manager-rules/implement-phases/implement-smoke.md +230 -0
- package/dist/registry/ai-manager-rules/implement-phases/implement-spike.md +121 -0
- package/dist/registry/ai-manager-rules/implement-phases/implement-validate.md +371 -0
- package/dist/registry/ai-manager-rules/implement-phases/quality-review.md +304 -0
- package/dist/registry/ai-manager-rules/implement-phases/regression.md +159 -0
- package/dist/registry/ai-manager-rules/implement-phases/repro.md +101 -0
- package/dist/registry/ai-manager-rules/implement-phases/scoping.md +93 -0
- package/dist/registry/ai-manager-rules/implement-phases/smoke.md +225 -0
- package/dist/registry/ai-manager-rules/implement-phases/spike.md +118 -0
- package/dist/registry/ai-manager-rules/implement-phases/validate.md +347 -0
- package/dist/registry/ai-manager-rules/shared-phases/finalize.md +169 -0
- package/dist/registry/ai-manager-rules/shared-phases/submit-pr.md +202 -0
- package/dist/registry/ai-manager-rules/shared-phases/wait-for-pr-review.md +170 -0
- package/dist/registry/ai-manager-rules/spec-phases/finalize.md +60 -0
- package/dist/registry/ai-manager-rules/spec-phases/spec-completeness-review.md +66 -0
- package/dist/registry/ai-manager-rules/spec-phases/spec-spec.md +139 -0
- package/dist/registry/ai-manager-rules/spec-phases/spec.md +102 -0
- package/dist/registry/ai-manager-rules/spec-phases/validate.md +118 -0
- package/dist/src/ai-manager/ai-manager.js +380 -119
- package/dist/src/ai-manager/evidence-validator.js +309 -0
- package/dist/src/ai-manager/phase-flow.js +244 -0
- package/dist/src/ai-manager/types.js +5 -0
- package/dist/src/fraim-mcp-server.js +45 -153
- package/dist/src/static-website-middleware.js +75 -0
- package/dist/tests/test-ai-coach-edge-cases.js +415 -0
- package/dist/tests/test-ai-coach-mcp-integration.js +432 -0
- package/dist/tests/test-ai-coach-performance.js +328 -0
- package/dist/tests/test-ai-coach-phase-content.js +264 -0
- package/dist/tests/test-ai-coach-workflows.js +487 -0
- package/dist/tests/test-ai-manager-phase-protocol.js +147 -0
- package/dist/tests/test-ai-manager.js +60 -71
- package/dist/tests/test-evidence-validation.js +221 -0
- package/dist/tests/test-mcp-lifecycle-methods.js +18 -23
- package/dist/tests/test-pr-review-integration.js +1 -0
- package/dist/tests/test-pr-review-workflow.js +299 -0
- package/dist/website/.nojekyll +0 -0
- package/dist/website/404.html +101 -0
- package/dist/website/CNAME +1 -0
- package/dist/website/README.md +22 -0
- package/dist/website/demo.html +604 -0
- package/dist/website/images/.gitkeep +1 -0
- package/dist/website/images/fraim-logo.png +0 -0
- package/dist/website/index.html +290 -0
- package/dist/website/pricing.html +414 -0
- package/dist/website/script.js +55 -0
- package/dist/website/styles.css +2647 -0
- package/package.json +2 -1
- package/registry/agent-guardrails.md +1 -1
- package/registry/stubs/workflows/brainstorming/blue-sky-brainstorming.md +11 -0
- package/registry/stubs/workflows/brainstorming/codebase-brainstorming.md +11 -0
- package/registry/stubs/workflows/compliance/detect-compliance-requirements.md +11 -0
- package/registry/stubs/workflows/compliance/generate-audit-evidence.md +11 -0
- package/registry/stubs/workflows/learning/synthesize-learnings.md +11 -0
- package/registry/stubs/workflows/legal/nda.md +11 -0
- package/registry/stubs/workflows/legal/patent-filing.md +11 -0
- package/registry/stubs/workflows/legal/trademark-filing.md +11 -0
- package/registry/stubs/workflows/marketing/domain-registration.md +11 -0
- package/registry/stubs/workflows/product-building/design.md +1 -1
- package/registry/stubs/workflows/product-building/implement.md +1 -2
|
@@ -0,0 +1,323 @@
|
|
|
1
|
+
# Phase: Code
|
|
2
|
+
|
|
3
|
+
## INTENT
|
|
4
|
+
To write the minimal, testable code needed to fix the bug or implement the feature, following approved designs and established patterns.
|
|
5
|
+
|
|
6
|
+
## OUTCOME
|
|
7
|
+
Working implementation that:
|
|
8
|
+
- Fixes the bug or implements the feature
|
|
9
|
+
- Follows approved design/RFC
|
|
10
|
+
- Includes comprehensive tests
|
|
11
|
+
- Maintains code quality
|
|
12
|
+
- Is ready for validation
|
|
13
|
+
|
|
14
|
+
## 🎯 SUCCESS MINDSET
|
|
15
|
+
|
|
16
|
+
**Your Goal**: Working application that users can actually use, not just passing tests.
|
|
17
|
+
|
|
18
|
+
**Critical Success Factors**:
|
|
19
|
+
- 🔍 **Manual validation is MANDATORY** - You WILL test in browser/API/CLI manually
|
|
20
|
+
- ⚠️ **Every error must be investigated** - No assumptions, no "that's probably fine"
|
|
21
|
+
- 🚫 **No placeholder code** - Implement complete solutions, no TODOs or "for now" comments
|
|
22
|
+
- 📊 **100% test success required** - 91% is failure, 99% is failure, only 100% is success
|
|
23
|
+
- 🏗️ **Prototype-first** - Build simplest end-to-end solution, then engineer it properly
|
|
24
|
+
|
|
25
|
+
## RULES FOR THIS PHASE
|
|
26
|
+
|
|
27
|
+
### Success Criteria
|
|
28
|
+
Read `registry/rules/agent-success-criteria.md` via `get_fraim_file` for the complete framework. Focus especially on:
|
|
29
|
+
- **Integrity** (never claim tests pass if you didn't run them)
|
|
30
|
+
- **Correctness** (follow architecture, tests must pass, no `any` types)
|
|
31
|
+
- **Completeness** (implement everything in the issue description)
|
|
32
|
+
|
|
33
|
+
### Simplicity Principles
|
|
34
|
+
Read `registry/rules/simplicity.md` via `get_fraim_file` for complete guidelines. Critical for coding phase:
|
|
35
|
+
- **Prototype-First Development**: Build simplest solution that works end-to-end, validate manually, then engineer correctly
|
|
36
|
+
- **Manual Validation Required**: Test with browser/curl before creating automated tests
|
|
37
|
+
- **Resource Waste Prevention**: Maximum 2 retries for expensive operations
|
|
38
|
+
- **NEVER use placeholder comments** like "For now", "TODO", "FIXME"
|
|
39
|
+
|
|
40
|
+
### Architecture Compliance
|
|
41
|
+
Read `.fraim/config.json` for the architecture document path (`customizations.architectureDoc`), then use `get_fraim_file` to read the full architecture guidelines. Follow all architectural standards - no shortcuts.
|
|
42
|
+
|
|
43
|
+
### Git Operations (if needed)
|
|
44
|
+
When using git commands directly (if MCP tools unavailable), read `registry/rules/git-safe-commands.md` via `get_fraim_file` to avoid interactive commands that hang agents.
|
|
45
|
+
|
|
46
|
+
## PRINCIPLES
|
|
47
|
+
- **Design-Driven**: Follow approved RFCs and design documents
|
|
48
|
+
- **Minimal Implementation**: Write only code needed for this issue
|
|
49
|
+
- **Test-First**: Write tests before or alongside implementation
|
|
50
|
+
- **Quality Focus**: Maintain code quality and follow patterns
|
|
51
|
+
- **Complete**: All aspects of design/spec implemented
|
|
52
|
+
|
|
53
|
+
## 📋 ENHANCED WORKFLOW
|
|
54
|
+
|
|
55
|
+
### Step 1: Prototype-First Development
|
|
56
|
+
|
|
57
|
+
**Build Simplest End-to-End Solution**:
|
|
58
|
+
- Focus on getting something working, not perfect
|
|
59
|
+
- Don't worry about code quality initially
|
|
60
|
+
- Prove the approach works before optimizing
|
|
61
|
+
- Get basic functionality working first
|
|
62
|
+
|
|
63
|
+
**Manual Validation (CRITICAL)**:
|
|
64
|
+
- Test every step manually using browser/curl/CLI
|
|
65
|
+
- Verify each acceptance criteria works
|
|
66
|
+
- Take screenshots/capture output as evidence
|
|
67
|
+
- Fix any issues found immediately
|
|
68
|
+
|
|
69
|
+
### Step 2: Review Design/Spec
|
|
70
|
+
|
|
71
|
+
**For Bugs:**
|
|
72
|
+
- Review bug description and repro test
|
|
73
|
+
- Understand root cause
|
|
74
|
+
- Plan minimal fix
|
|
75
|
+
|
|
76
|
+
**For Features:**
|
|
77
|
+
- Review approved RFC/design document
|
|
78
|
+
- Review spike/POC findings (if applicable)
|
|
79
|
+
- Understand all acceptance criteria
|
|
80
|
+
- Plan implementation approach
|
|
81
|
+
|
|
82
|
+
### Step 3: Check for Design Feedback
|
|
83
|
+
|
|
84
|
+
**CRITICAL**: Before implementing, check for feedback:
|
|
85
|
+
- Design Review Feedback: `docs/evidence/{issue_number}-design-reviewer-feedback.md`
|
|
86
|
+
- Feature Review Feedback: `docs/evidence/{issue_number}-feature-reviewer-feedback.md`
|
|
87
|
+
|
|
88
|
+
**If feedback exists:**
|
|
89
|
+
- **MUST address all items** before proceeding
|
|
90
|
+
- Update evidence document after addressing
|
|
91
|
+
- Cannot skip or defer feedback items
|
|
92
|
+
|
|
93
|
+
### Step 4: Implement Changes
|
|
94
|
+
|
|
95
|
+
**For Bugs:**
|
|
96
|
+
- Make minimal changes to fix the issue
|
|
97
|
+
- Focus on root cause, not symptoms
|
|
98
|
+
- Avoid unrelated changes
|
|
99
|
+
- Keep diff small and focused
|
|
100
|
+
|
|
101
|
+
**For Features:**
|
|
102
|
+
- Implement all aspects from design/spec
|
|
103
|
+
- Follow existing patterns and architecture
|
|
104
|
+
- Create necessary files/modules
|
|
105
|
+
- Implement all API contracts
|
|
106
|
+
- Implement all data models
|
|
107
|
+
- Implement all user interfaces
|
|
108
|
+
- No placeholder code for core functionality
|
|
109
|
+
|
|
110
|
+
### Step 5: Fix All Errors (MANDATORY)
|
|
111
|
+
|
|
112
|
+
**Error Investigation Requirements**:
|
|
113
|
+
- **Every error in logs must be investigated**
|
|
114
|
+
- **No error is "expected" until proven**
|
|
115
|
+
- **Fix root causes, not symptoms**
|
|
116
|
+
- **Document why any remaining errors are acceptable**
|
|
117
|
+
|
|
118
|
+
**Common Error Sources**:
|
|
119
|
+
- Server startup errors
|
|
120
|
+
- API connection errors
|
|
121
|
+
- Database connection errors
|
|
122
|
+
- TypeScript compilation errors
|
|
123
|
+
- Test execution errors
|
|
124
|
+
|
|
125
|
+
### Step 6: Write Comprehensive Tests
|
|
126
|
+
|
|
127
|
+
**MANDATORY**: Every issue requires tests - no exceptions.
|
|
128
|
+
|
|
129
|
+
**For Bugs:**
|
|
130
|
+
- Verify repro test from repro phase now passes
|
|
131
|
+
- Add additional edge case tests if needed
|
|
132
|
+
- Ensure tests cover the fix
|
|
133
|
+
|
|
134
|
+
**For Features:**
|
|
135
|
+
- Write tests for all acceptance criteria
|
|
136
|
+
- Test main user scenarios
|
|
137
|
+
- Test edge cases
|
|
138
|
+
- Test error conditions
|
|
139
|
+
- Read `.fraim/config.json` for the architecture document path (`customizations.architectureDoc`), then use `get_fraim_file` to read the full test architecture standards
|
|
140
|
+
|
|
141
|
+
**Test Requirements:**
|
|
142
|
+
- Use shared-server-utils.ts for server tests
|
|
143
|
+
- Unique API keys per test
|
|
144
|
+
- Proper cleanup in finally blocks
|
|
145
|
+
- No individual server instances
|
|
146
|
+
- Proper timeouts (5-10s for network calls)
|
|
147
|
+
- Tests must validate real functionality, not mocks
|
|
148
|
+
- No tests that default to passing
|
|
149
|
+
|
|
150
|
+
**Test Tagging Guidelines:**
|
|
151
|
+
Tag tests appropriately to ensure proper test suite execution:
|
|
152
|
+
|
|
153
|
+
- **`smoke`**: Tag tests as "smoke" if they verify:
|
|
154
|
+
- Core system functionality (CLI commands, server startup, basic workflows)
|
|
155
|
+
- Critical user journeys (init, sync, basic operations)
|
|
156
|
+
- Integration points between major components
|
|
157
|
+
- Functionality that, if broken, would make the system unusable
|
|
158
|
+
|
|
159
|
+
- **`integration`**: Tests that verify multiple components working together
|
|
160
|
+
- **`unit`**: Tests that verify individual functions or classes in isolation
|
|
161
|
+
- **`e2e`**: End-to-end tests that verify complete user workflows
|
|
162
|
+
|
|
163
|
+
**Smoke Test Execution Rules:**
|
|
164
|
+
If ANY tests are tagged "smoke" or you're modifying core functionality:
|
|
165
|
+
1. **MANDATORY**: Run full smoke test suite: `npm run test-smoke-ci`
|
|
166
|
+
2. **MANDATORY**: Include smoke test output in evidence
|
|
167
|
+
3. **MANDATORY**: All smoke tests must pass before proceeding
|
|
168
|
+
4. **BLOCKING**: Smoke test failures block phase completion
|
|
169
|
+
|
|
170
|
+
### Step 7: Run All Tests (100% Success Required)
|
|
171
|
+
|
|
172
|
+
**Execute all tests:**
|
|
173
|
+
```bash
|
|
174
|
+
npm test -- path/to/test.test.ts
|
|
175
|
+
```
|
|
176
|
+
|
|
177
|
+
**Verify:**
|
|
178
|
+
- All tests pass (100%, not 91% or 99%)
|
|
179
|
+
- No timeouts
|
|
180
|
+
- No errors
|
|
181
|
+
- Tests fail if code is broken (validate this)
|
|
182
|
+
|
|
183
|
+
**If ANY tests fail:**
|
|
184
|
+
- **STOP** - Do not proceed
|
|
185
|
+
- Investigate failure thoroughly
|
|
186
|
+
- Fix the issue
|
|
187
|
+
- Re-run tests
|
|
188
|
+
- Only proceed when 100% pass
|
|
189
|
+
|
|
190
|
+
### Step 8: TypeScript Compilation
|
|
191
|
+
|
|
192
|
+
```bash
|
|
193
|
+
npx tsc --noEmit --skipLibCheck
|
|
194
|
+
```
|
|
195
|
+
|
|
196
|
+
**Must exit with code 0** (no errors)
|
|
197
|
+
|
|
198
|
+
If compilation fails:
|
|
199
|
+
- Fix errors
|
|
200
|
+
- Re-compile
|
|
201
|
+
- Iterate until clean
|
|
202
|
+
|
|
203
|
+
### Step 9: Final Manual Validation (CRITICAL)
|
|
204
|
+
|
|
205
|
+
**Trust, but Verify:**
|
|
206
|
+
- Do not rely solely on automated tests
|
|
207
|
+
- Inspect generated artifacts manually
|
|
208
|
+
- Verify content looks correct
|
|
209
|
+
- Check for placeholders or errors
|
|
210
|
+
|
|
211
|
+
**For UI changes:**
|
|
212
|
+
- Start dev server
|
|
213
|
+
- Navigate to changed UI
|
|
214
|
+
- Verify visual correctness
|
|
215
|
+
- Test user interactions
|
|
216
|
+
- Take screenshots as evidence
|
|
217
|
+
|
|
218
|
+
**For API changes:**
|
|
219
|
+
- Test with curl or similar
|
|
220
|
+
- Verify request/response formats
|
|
221
|
+
- Test error handling
|
|
222
|
+
- Capture API responses as evidence
|
|
223
|
+
|
|
224
|
+
**For CLI changes:**
|
|
225
|
+
- Run commands manually
|
|
226
|
+
- Verify output correctness
|
|
227
|
+
- Test various inputs
|
|
228
|
+
- Capture command output as evidence
|
|
229
|
+
|
|
230
|
+
## 📸 EVIDENCE REQUIREMENTS
|
|
231
|
+
|
|
232
|
+
You MUST provide concrete evidence for all claims:
|
|
233
|
+
|
|
234
|
+
1. **Screenshots**: Application working in browser/UI
|
|
235
|
+
2. **Test Output**: Complete test suite results (100% pass)
|
|
236
|
+
3. **Server Logs**: Clean startup with no errors
|
|
237
|
+
4. **API Responses**: Curl/Postman output for API changes
|
|
238
|
+
5. **Manual Validation**: Step-by-step verification of acceptance criteria
|
|
239
|
+
|
|
240
|
+
## VALIDATION
|
|
241
|
+
|
|
242
|
+
### Phase Complete When:
|
|
243
|
+
- ✅ Implementation complete per design/spec
|
|
244
|
+
- ✅ (Bugs) Minimal, focused changes
|
|
245
|
+
- ✅ (Features) All design aspects implemented
|
|
246
|
+
- ✅ Tests written and passing (100%)
|
|
247
|
+
- ✅ TypeScript compiles cleanly
|
|
248
|
+
- ✅ Manual validation successful with evidence
|
|
249
|
+
- ✅ Design feedback addressed (if applicable)
|
|
250
|
+
- ✅ All errors investigated and resolved
|
|
251
|
+
- ✅ Evidence provided for all claims
|
|
252
|
+
|
|
253
|
+
### Phase Incomplete If:
|
|
254
|
+
- ❌ Design/spec not fully implemented
|
|
255
|
+
- ❌ No tests written
|
|
256
|
+
- ❌ ANY tests fail (even 1 out of 100)
|
|
257
|
+
- ❌ TypeScript compilation errors
|
|
258
|
+
- ❌ Manual validation reveals issues
|
|
259
|
+
- ❌ Design feedback not addressed
|
|
260
|
+
- ❌ Errors in logs not investigated
|
|
261
|
+
- ❌ Missing evidence for claims
|
|
262
|
+
|
|
263
|
+
### Report Back:
|
|
264
|
+
When you complete this phase, call:
|
|
265
|
+
|
|
266
|
+
```javascript
|
|
267
|
+
seekCoachingOnNextStep({
|
|
268
|
+
workflowType: "implement",
|
|
269
|
+
issueNumber: "{issue_number}",
|
|
270
|
+
currentPhase: "code",
|
|
271
|
+
status: "complete",
|
|
272
|
+
findings: {
|
|
273
|
+
evidence: "Brief summary of what you implemented and validated"
|
|
274
|
+
},
|
|
275
|
+
evidence: {
|
|
276
|
+
testOutput: "Complete test output showing 100% pass rate",
|
|
277
|
+
screenshots: ["Screenshots of working functionality"],
|
|
278
|
+
serverLogs: ["Clean server startup logs"],
|
|
279
|
+
manualValidationSteps: [
|
|
280
|
+
"Step-by-step manual validation performed",
|
|
281
|
+
"Browser testing results",
|
|
282
|
+
"API testing results"
|
|
283
|
+
],
|
|
284
|
+
reflectionAnalysis: "Complete 4-phase reflection analysis",
|
|
285
|
+
claims: [
|
|
286
|
+
"Specific claims about what works",
|
|
287
|
+
"All tests pass",
|
|
288
|
+
"Manual validation complete"
|
|
289
|
+
]
|
|
290
|
+
}
|
|
291
|
+
})
|
|
292
|
+
```
|
|
293
|
+
|
|
294
|
+
If implementation incomplete, iterate:
|
|
295
|
+
```javascript
|
|
296
|
+
seekCoachingOnNextStep({
|
|
297
|
+
workflowType: "implement",
|
|
298
|
+
issueNumber: "{issue_number}",
|
|
299
|
+
currentPhase: "code",
|
|
300
|
+
status: "incomplete",
|
|
301
|
+
findings: {
|
|
302
|
+
uncertainties: ["Issues encountered", "What needs to be fixed"]
|
|
303
|
+
}
|
|
304
|
+
})
|
|
305
|
+
```
|
|
306
|
+
```
|
|
307
|
+
|
|
308
|
+
## SCRIPTS
|
|
309
|
+
|
|
310
|
+
**Run tests:**
|
|
311
|
+
```bash
|
|
312
|
+
npm test -- path/to/test.test.ts
|
|
313
|
+
```
|
|
314
|
+
|
|
315
|
+
**Compile TypeScript:**
|
|
316
|
+
```bash
|
|
317
|
+
npx tsc --noEmit --skipLibCheck
|
|
318
|
+
```
|
|
319
|
+
|
|
320
|
+
**Start dev server (for manual testing):**
|
|
321
|
+
```bash
|
|
322
|
+
npm run dev
|
|
323
|
+
```
|
|
@@ -0,0 +1,94 @@
|
|
|
1
|
+
# Phase: Completeness Review
|
|
2
|
+
|
|
3
|
+
## INTENT
|
|
4
|
+
To verify that all design aspects have been implemented and that the work fully addresses the requirements from the design document or issue specification.
|
|
5
|
+
|
|
6
|
+
## OUTCOME
|
|
7
|
+
Confirmation that:
|
|
8
|
+
- All design aspects implemented
|
|
9
|
+
- All acceptance criteria met
|
|
10
|
+
- Implementation matches design specifications
|
|
11
|
+
- Work is complete and ready for finalization
|
|
12
|
+
|
|
13
|
+
## PRINCIPLES
|
|
14
|
+
- **Design Fidelity**: Implementation must match design specifications
|
|
15
|
+
- **Complete Coverage**: All design aspects must be addressed
|
|
16
|
+
- **Evidence-Based**: Use existing comprehensive review workflows
|
|
17
|
+
|
|
18
|
+
## WORKFLOW
|
|
19
|
+
|
|
20
|
+
### Step 1: Execute Design Review Workflow
|
|
21
|
+
|
|
22
|
+
Use the comprehensive design validation workflow:
|
|
23
|
+
- Read `registry/workflows/reviewer/review-implementation-vs-design-spec.md` via `get_fraim_file`
|
|
24
|
+
- Follow the complete systematic review process
|
|
25
|
+
- This workflow provides detailed checklists, validation steps, and templates
|
|
26
|
+
- Works for both bugs and features - all should be reviewed against their design spec
|
|
27
|
+
|
|
28
|
+
### Step 2: Execute Review Workflow
|
|
29
|
+
|
|
30
|
+
**Follow the design review workflow completely:**
|
|
31
|
+
- Use all the checklists provided
|
|
32
|
+
- Execute all validation steps
|
|
33
|
+
- Create feedback documents using the templates
|
|
34
|
+
- Follow the iteration limits (max 3)
|
|
35
|
+
|
|
36
|
+
### Step 3: Architecture Compliance
|
|
37
|
+
|
|
38
|
+
Read `.fraim/config.json` for the architecture document path (`customizations.architectureDoc`), then use `get_fraim_file` to read the full architecture guidelines. Verify implementation follows all design standards.
|
|
39
|
+
|
|
40
|
+
## VALIDATION
|
|
41
|
+
|
|
42
|
+
### Phase Complete When:
|
|
43
|
+
- ✅ Appropriate review workflow executed completely
|
|
44
|
+
- ✅ All workflow checklists completed
|
|
45
|
+
- ✅ All design aspects verified per workflow
|
|
46
|
+
- ✅ Evidence quality meets workflow standards
|
|
47
|
+
- ✅ Feedback documents created using workflow templates
|
|
48
|
+
- ✅ Architecture compliance verified
|
|
49
|
+
|
|
50
|
+
### Phase Incomplete If:
|
|
51
|
+
- ❌ Review workflow not followed completely
|
|
52
|
+
- ❌ Workflow checklists incomplete
|
|
53
|
+
- ❌ Design aspects not verified per workflow standards
|
|
54
|
+
- ❌ Evidence quality insufficient per workflow criteria
|
|
55
|
+
- ❌ Feedback documents missing or not using templates
|
|
56
|
+
|
|
57
|
+
### Report Back:
|
|
58
|
+
When you complete this phase, call:
|
|
59
|
+
|
|
60
|
+
```javascript
|
|
61
|
+
seekCoachingOnNextStep({
|
|
62
|
+
workflowType: "implement",
|
|
63
|
+
issueNumber: "{issue_number}",
|
|
64
|
+
currentPhase: "completeness-review",
|
|
65
|
+
status: "complete",
|
|
66
|
+
evidence: {
|
|
67
|
+
reviewWorkflowUsed: "review-implementation-vs-design-spec", // Which workflow was used
|
|
68
|
+
workflowChecklistsComplete: "YES", // All checklists from workflow completed?
|
|
69
|
+
designAspectsVerified: "YES", // All design aspects verified per workflow?
|
|
70
|
+
evidenceQualityMet: "YES", // Evidence meets workflow standards?
|
|
71
|
+
feedbackDocumentsCreated: "YES", // Feedback documents created using templates?
|
|
72
|
+
architectureCompliant: "YES", // Architecture compliance verified?
|
|
73
|
+
reviewDecision: "APPROVE", // APPROVE/REQUEST_CHANGES/REJECT per workflow
|
|
74
|
+
summary: "Completed systematic design review using comprehensive workflow. All design aspects verified and documented."
|
|
75
|
+
}
|
|
76
|
+
})
|
|
77
|
+
```
|
|
78
|
+
|
|
79
|
+
If review reveals issues:
|
|
80
|
+
```javascript
|
|
81
|
+
seekCoachingOnNextStep({
|
|
82
|
+
workflowType: "implement",
|
|
83
|
+
issueNumber: "{issue_number}",
|
|
84
|
+
currentPhase: "completeness-review",
|
|
85
|
+
status: "incomplete",
|
|
86
|
+
evidence: {
|
|
87
|
+
reviewWorkflowUsed: "review-implementation-vs-design-spec",
|
|
88
|
+
reviewDecision: "REQUEST_CHANGES", // or "REJECT"
|
|
89
|
+
issuesFound: ["Missing test case X per workflow checklist", "Design requirement Y not implemented"],
|
|
90
|
+
feedbackDocumentLocation: "docs/evidence/{issue}-design-reviewer-feedback.md",
|
|
91
|
+
nextAction: "Implementation agent must address feedback per workflow iteration process"
|
|
92
|
+
}
|
|
93
|
+
})
|
|
94
|
+
```
|
|
@@ -0,0 +1,177 @@
|
|
|
1
|
+
# Phase: Finalize
|
|
2
|
+
|
|
3
|
+
## INTENT
|
|
4
|
+
To prepare the work for human review by updating issue labels, creating evidence documentation, and ensuring all artifacts are in place.
|
|
5
|
+
|
|
6
|
+
## OUTCOME
|
|
7
|
+
Work is ready for human review with:
|
|
8
|
+
- Issue labels updated
|
|
9
|
+
- Evidence document created
|
|
10
|
+
- PR ready for review
|
|
11
|
+
- All validation complete
|
|
12
|
+
|
|
13
|
+
## PRINCIPLES
|
|
14
|
+
- **Complete Documentation**: Evidence shows all work done
|
|
15
|
+
- **Proper Labels**: Issue status reflects readiness
|
|
16
|
+
- **Clear Communication**: PR and evidence are clear
|
|
17
|
+
- **Ready for Review**: No blockers for human reviewer
|
|
18
|
+
|
|
19
|
+
## RULES FOR THIS PHASE
|
|
20
|
+
|
|
21
|
+
### Success Criteria
|
|
22
|
+
Read `registry/rules/agent-success-criteria.md` via `get_fraim_file` for the complete framework. Focus on:
|
|
23
|
+
- **Integrity** (honest documentation of all work completed)
|
|
24
|
+
- **Completeness** (all finalization steps completed)
|
|
25
|
+
|
|
26
|
+
### Simplicity Principles
|
|
27
|
+
Read `registry/rules/simplicity.md` via `get_fraim_file` for complete guidelines. Key for finalization:
|
|
28
|
+
- **Focus on the assigned issue only** - document only relevant work
|
|
29
|
+
- **Clear communication** - evidence should be easy to understand
|
|
30
|
+
|
|
31
|
+
### Git Operations (if needed)
|
|
32
|
+
When using git commands directly (if MCP tools unavailable), read `registry/rules/git-safe-commands.md` via `get_fraim_file` to avoid interactive commands that hang agents.
|
|
33
|
+
|
|
34
|
+
## WORKFLOW
|
|
35
|
+
|
|
36
|
+
### Step 1: Update Issue Labels
|
|
37
|
+
|
|
38
|
+
**Remove:**
|
|
39
|
+
- `status:wip`
|
|
40
|
+
|
|
41
|
+
**Add:**
|
|
42
|
+
- `status:needs-review`
|
|
43
|
+
|
|
44
|
+
**GitHub Repository Context:**
|
|
45
|
+
Read `.fraim/config.json` for:
|
|
46
|
+
- `git.repoOwner` - GitHub repository owner
|
|
47
|
+
- `git.repoName` - GitHub repository name
|
|
48
|
+
|
|
49
|
+
Use GitHub MCP tools to update labels.
|
|
50
|
+
|
|
51
|
+
### Step 2: Create Evidence Document
|
|
52
|
+
|
|
53
|
+
**File location:**
|
|
54
|
+
```
|
|
55
|
+
docs/evidence/{issue_number}-implementation-evidence.md
|
|
56
|
+
```
|
|
57
|
+
|
|
58
|
+
**Evidence document should include:**
|
|
59
|
+
|
|
60
|
+
#### Summary
|
|
61
|
+
- Issue number and title
|
|
62
|
+
- Issue type (bug or feature)
|
|
63
|
+
- Brief description of changes
|
|
64
|
+
|
|
65
|
+
#### Implementation Details
|
|
66
|
+
- What was implemented
|
|
67
|
+
- Key files changed
|
|
68
|
+
- Approach taken
|
|
69
|
+
|
|
70
|
+
#### Testing
|
|
71
|
+
- Tests created/modified
|
|
72
|
+
- Test results (all passing)
|
|
73
|
+
- Smoke test results
|
|
74
|
+
- Regression test results
|
|
75
|
+
|
|
76
|
+
#### Validation
|
|
77
|
+
- How implementation was validated
|
|
78
|
+
- Validation results
|
|
79
|
+
- Screenshots/output (if applicable)
|
|
80
|
+
|
|
81
|
+
#### Quality Checks
|
|
82
|
+
- TypeScript compilation: ✅ Pass
|
|
83
|
+
- All tests: ✅ Pass (X/X tests)
|
|
84
|
+
- Code quality: ✅ Pass
|
|
85
|
+
- Git status: ✅ Clean
|
|
86
|
+
|
|
87
|
+
#### Design Feedback (if applicable)
|
|
88
|
+
- Feedback items addressed
|
|
89
|
+
- How each was resolved
|
|
90
|
+
|
|
91
|
+
#### Phase Completion
|
|
92
|
+
- All phases completed
|
|
93
|
+
- Evidence from each phase
|
|
94
|
+
- Any iterations or challenges
|
|
95
|
+
|
|
96
|
+
### Step 3: Verify PR Exists
|
|
97
|
+
|
|
98
|
+
The GitHub Action should have created a draft PR when you labeled the issue `phase:impl`.
|
|
99
|
+
|
|
100
|
+
**Verify PR:**
|
|
101
|
+
- PR exists for the feature branch
|
|
102
|
+
- PR title reflects the issue
|
|
103
|
+
- PR description includes context
|
|
104
|
+
|
|
105
|
+
**If PR doesn't exist:**
|
|
106
|
+
- Create PR manually
|
|
107
|
+
- Link to issue
|
|
108
|
+
- Add evidence document link
|
|
109
|
+
|
|
110
|
+
### Step 4: Add PR Comment
|
|
111
|
+
|
|
112
|
+
Add comment to PR with link to evidence:
|
|
113
|
+
```
|
|
114
|
+
Implementation complete. Evidence document: docs/evidence/{issue_number}-implementation-evidence.md
|
|
115
|
+
|
|
116
|
+
All phases completed:
|
|
117
|
+
✅ Scoping
|
|
118
|
+
✅ Repro/Spike
|
|
119
|
+
✅ Implementation
|
|
120
|
+
✅ Validation
|
|
121
|
+
✅ Smoke Tests
|
|
122
|
+
✅ Regression Tests
|
|
123
|
+
✅ Quality Review
|
|
124
|
+
✅ Finalize
|
|
125
|
+
|
|
126
|
+
Ready for human review.
|
|
127
|
+
```
|
|
128
|
+
|
|
129
|
+
### Step 5: Final Verification
|
|
130
|
+
|
|
131
|
+
**Checklist:**
|
|
132
|
+
- ✅ Issue labels updated
|
|
133
|
+
- ✅ Evidence document created and complete
|
|
134
|
+
- ✅ PR exists and is ready
|
|
135
|
+
- ✅ PR comment added with evidence link
|
|
136
|
+
- ✅ All tests passing
|
|
137
|
+
- ✅ Git status clean
|
|
138
|
+
|
|
139
|
+
## VALIDATION
|
|
140
|
+
|
|
141
|
+
### Phase Complete When:
|
|
142
|
+
- ✅ Issue has `status:needs-review` label
|
|
143
|
+
- ✅ Issue does not have `status:wip` label
|
|
144
|
+
- ✅ Evidence document exists and is complete
|
|
145
|
+
- ✅ PR exists and is ready for review
|
|
146
|
+
- ✅ PR has comment linking to evidence
|
|
147
|
+
- ✅ All previous phases complete
|
|
148
|
+
|
|
149
|
+
### Phase Incomplete If:
|
|
150
|
+
- ❌ Labels not updated
|
|
151
|
+
- ❌ Evidence document missing or incomplete
|
|
152
|
+
- ❌ PR not ready
|
|
153
|
+
- ❌ Previous phases not complete
|
|
154
|
+
|
|
155
|
+
**Create evidence document:**
|
|
156
|
+
```bash
|
|
157
|
+
touch docs/evidence/{issue_number}-implementation-evidence.md
|
|
158
|
+
```
|
|
159
|
+
|
|
160
|
+
### Report Back:
|
|
161
|
+
When you complete this phase, call:
|
|
162
|
+
|
|
163
|
+
```javascript
|
|
164
|
+
seekCoachingOnNextStep({
|
|
165
|
+
workflowType: "implement",
|
|
166
|
+
issueNumber: "{issue_number}",
|
|
167
|
+
currentPhase: "finalize",
|
|
168
|
+
status: "complete",
|
|
169
|
+
evidence: {
|
|
170
|
+
labelsUpdated: "Issue has status:needs-review label",
|
|
171
|
+
evidenceDocument: "docs/evidence/456-implementation-evidence.md created",
|
|
172
|
+
prStatus: "PR ready for review",
|
|
173
|
+
prComment: "PR comment added with evidence link",
|
|
174
|
+
allPhasesComplete: "All implementation phases completed successfully"
|
|
175
|
+
}
|
|
176
|
+
})
|
|
177
|
+
```
|