fraim-framework 2.0.4 → 2.0.5
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/.ai-agents/workflows/test.md +89 -89
- package/package.json +1 -1
- package/setup.js +29 -0
- package/DISTRIBUTION.md +0 -187
- package/PUBLISH_INSTRUCTIONS.md +0 -93
- package/getting-started.md +0 -143
- package/linkedin-post.md +0 -23
|
@@ -1,90 +1,90 @@
|
|
|
1
|
-
# Testing Phase
|
|
2
|
-
|
|
3
|
-
## INTENT
|
|
4
|
-
To create comprehensive test coverage that accurately reproduces issues and validates solutions, ensuring robust testing through proper test structure, failure verification, and systematic test execution.
|
|
5
|
-
|
|
6
|
-
## PRINCIPLES
|
|
7
|
-
- **Test-Driven**: Write tests that reproduce the issue before fixing
|
|
8
|
-
- **Comprehensive Coverage**: Ensure all scenarios are tested
|
|
9
|
-
- **Failure Verification**: Confirm tests fail before implementation
|
|
10
|
-
- **Proper Structure**: Use established test patterns and frameworks
|
|
11
|
-
- **Systematic Execution**: Follow consistent testing procedures
|
|
12
|
-
|
|
13
|
-
## TESTING WORKFLOW
|
|
14
|
-
|
|
15
|
-
### Step 1: Issue Identification
|
|
16
|
-
Ask for {issue_number} (and optional {slug}); confirm target branch feature/{issue_number}-{slug}.
|
|
17
|
-
|
|
18
|
-
### Step 2: Phase Initiation
|
|
19
|
-
Label the issue 'phase:tests'. (GitHub Action will automatically label the issue `status:wip` and update the existing draft PR)
|
|
20
|
-
|
|
21
|
-
### Step 3: Environment Setup
|
|
22
|
-
**IMPORTANT**: The user has already run `prep-issue.sh` which has:
|
|
23
|
-
- ✅ Created the feature branch
|
|
24
|
-
- ✅ Checked out the branch
|
|
25
|
-
- ✅ Created draft PR
|
|
26
|
-
- ✅ Indexed the codebase with Serena
|
|
27
|
-
- ✅ Opened the editor in the prepared workspace
|
|
28
|
-
|
|
29
|
-
You can start working immediately in the prepared environment. No need to create branches or wait for GitHub Actions.
|
|
30
|
-
|
|
31
|
-
### Step 4: Work Location
|
|
32
|
-
You are already in the correct workspace prepared by the user. Confirm you're on the right branch and start working.
|
|
33
|
-
|
|
34
|
-
### Step 5: Testing Work
|
|
35
|
-
Your work entails the following:
|
|
36
|
-
|
|
37
|
-
- Review the RFC associated with this issue.
|
|
38
|
-
- Determine whether tests need to be added to an existing test suite, or a new one needs to be created.
|
|
39
|
-
- **CRITICAL: Write INTEGRATION tests that demonstrate the REAL USER SCENARIO**
|
|
40
|
-
- Test the actual end-to-end user experience, not unit tests for hypothetical fixes
|
|
41
|
-
- Use real services and APIs where possible (not mocks)
|
|
42
|
-
- Verify the issue occurs in the real system as described in the issue
|
|
43
|
-
- Example: For messaging threading issues, actually send messages and verify they appear as new messages vs replies
|
|
44
|
-
- Run the test cases to ensure they fail (demonstrating the issue exists)
|
|
45
|
-
- Flip issue to 'status:needs-review' and remove 'status:wip'
|
|
46
|
-
|
|
47
|
-
**❌ DO NOT:**
|
|
48
|
-
- Write unit tests for code that doesn't exist yet
|
|
49
|
-
- Test hypothetical fixes or solutions
|
|
50
|
-
- Create mock tests that don't use real services
|
|
51
|
-
- Test individual components in isolation
|
|
52
|
-
|
|
53
|
-
**✅ DO:**
|
|
54
|
-
- Test the complete user workflow end-to-end
|
|
55
|
-
- Use real APIs and services when possible
|
|
56
|
-
- Verify the actual problem described in the issue
|
|
57
|
-
- Create tests that will pass AFTER the fix is implemented
|
|
58
|
-
|
|
59
|
-
### Step 6: Iteration
|
|
60
|
-
If workflow actions or reviewer feedback indicates more work is needed, ensure the issue is set back to `status:wip` and continue working as above.
|
|
61
|
-
|
|
62
|
-
## EXAMPLES
|
|
63
|
-
|
|
64
|
-
### Good: Comprehensive Testing Process
|
|
65
|
-
```
|
|
66
|
-
Issue #84: "Fix API integration timeout"
|
|
67
|
-
1. ✅ Identified: Issue #84, branch feature/84-fix-api
|
|
68
|
-
2. ✅ Phase: Set phase:tests, PR created
|
|
69
|
-
3. ✅ Environment: User ran prep-issue.sh, ready to work
|
|
70
|
-
4. ✅ Location: Working in prepared workspace with Serena indexing
|
|
71
|
-
5. ✅ RFC Review: Read docs/rfcs/84-fix-api-timeout.md
|
|
72
|
-
6. ✅ Analysis: Determined need to add timeout tests
|
|
73
|
-
7. ✅ Test Creation: Added test cases for timeout scenarios
|
|
74
|
-
8. ✅ Failure Verification: Confirmed tests fail before fix
|
|
75
|
-
9. ✅ Review: Set status:needs-review
|
|
76
|
-
10. ✅ Iteration: Incorporated feedback, updated tests
|
|
77
|
-
Result: Comprehensive test coverage with proper structure
|
|
78
|
-
```
|
|
79
|
-
|
|
80
|
-
### Bad: Incomplete Testing Process
|
|
81
|
-
```
|
|
82
|
-
Issue #84: "Fix API integration timeout"
|
|
83
|
-
1. ✅ Identified: Issue #84
|
|
84
|
-
2. ❌ Skip: Didn't review RFC
|
|
85
|
-
3. ❌ Skip: Started testing without understanding requirements
|
|
86
|
-
4. ❌ Skip: No test cases written
|
|
87
|
-
5. ❌ Skip: Didn't verify tests fail
|
|
88
|
-
6. ❌ Skip: No test structure followed
|
|
89
|
-
Result: Incomplete, ineffective testing
|
|
1
|
+
# Testing Phase
|
|
2
|
+
|
|
3
|
+
## INTENT
|
|
4
|
+
To create comprehensive test coverage that accurately reproduces issues and validates solutions, ensuring robust testing through proper test structure, failure verification, and systematic test execution.
|
|
5
|
+
|
|
6
|
+
## PRINCIPLES
|
|
7
|
+
- **Test-Driven**: Write tests that reproduce the issue before fixing
|
|
8
|
+
- **Comprehensive Coverage**: Ensure all scenarios are tested
|
|
9
|
+
- **Failure Verification**: Confirm tests fail before implementation
|
|
10
|
+
- **Proper Structure**: Use established test patterns and frameworks
|
|
11
|
+
- **Systematic Execution**: Follow consistent testing procedures
|
|
12
|
+
|
|
13
|
+
## TESTING WORKFLOW
|
|
14
|
+
|
|
15
|
+
### Step 1: Issue Identification
|
|
16
|
+
Ask for {issue_number} (and optional {slug}); confirm target branch feature/{issue_number}-{slug}.
|
|
17
|
+
|
|
18
|
+
### Step 2: Phase Initiation
|
|
19
|
+
Label the issue 'phase:tests'. (GitHub Action will automatically label the issue `status:wip` and update the existing draft PR)
|
|
20
|
+
|
|
21
|
+
### Step 3: Environment Setup
|
|
22
|
+
**IMPORTANT**: The user has already run `prep-issue.sh` which has:
|
|
23
|
+
- ✅ Created the feature branch
|
|
24
|
+
- ✅ Checked out the branch
|
|
25
|
+
- ✅ Created draft PR
|
|
26
|
+
- ✅ Indexed the codebase with Serena
|
|
27
|
+
- ✅ Opened the editor in the prepared workspace
|
|
28
|
+
|
|
29
|
+
You can start working immediately in the prepared environment. No need to create branches or wait for GitHub Actions.
|
|
30
|
+
|
|
31
|
+
### Step 4: Work Location
|
|
32
|
+
You are already in the correct workspace prepared by the user. Confirm you're on the right branch and start working.
|
|
33
|
+
|
|
34
|
+
### Step 5: Testing Work
|
|
35
|
+
Your work entails the following:
|
|
36
|
+
|
|
37
|
+
- Review the RFC associated with this issue.
|
|
38
|
+
- Determine whether tests need to be added to an existing test suite, or a new one needs to be created.
|
|
39
|
+
- **CRITICAL: Write INTEGRATION tests that demonstrate the REAL USER SCENARIO**
|
|
40
|
+
- Test the actual end-to-end user experience, not unit tests for hypothetical fixes
|
|
41
|
+
- Use real services and APIs where possible (not mocks)
|
|
42
|
+
- Verify the issue occurs in the real system as described in the issue
|
|
43
|
+
- Example: For messaging threading issues, actually send messages and verify they appear as new messages vs replies
|
|
44
|
+
- Run the test cases to ensure they fail (demonstrating the issue exists)
|
|
45
|
+
- Flip issue to 'status:needs-review' and remove 'status:wip'
|
|
46
|
+
|
|
47
|
+
**❌ DO NOT:**
|
|
48
|
+
- Write unit tests for code that doesn't exist yet
|
|
49
|
+
- Test hypothetical fixes or solutions
|
|
50
|
+
- Create mock tests that don't use real services
|
|
51
|
+
- Test individual components in isolation
|
|
52
|
+
|
|
53
|
+
**✅ DO:**
|
|
54
|
+
- Test the complete user workflow end-to-end
|
|
55
|
+
- Use real APIs and services when possible
|
|
56
|
+
- Verify the actual problem described in the issue
|
|
57
|
+
- Create tests that will pass AFTER the fix is implemented
|
|
58
|
+
|
|
59
|
+
### Step 6: Iteration
|
|
60
|
+
If workflow actions or reviewer feedback indicates more work is needed, ensure the issue is set back to `status:wip` and continue working as above.
|
|
61
|
+
|
|
62
|
+
## EXAMPLES
|
|
63
|
+
|
|
64
|
+
### Good: Comprehensive Testing Process
|
|
65
|
+
```
|
|
66
|
+
Issue #84: "Fix API integration timeout"
|
|
67
|
+
1. ✅ Identified: Issue #84, branch feature/84-fix-api
|
|
68
|
+
2. ✅ Phase: Set phase:tests, PR created
|
|
69
|
+
3. ✅ Environment: User ran prep-issue.sh, ready to work
|
|
70
|
+
4. ✅ Location: Working in prepared workspace with Serena indexing
|
|
71
|
+
5. ✅ RFC Review: Read docs/rfcs/84-fix-api-timeout.md
|
|
72
|
+
6. ✅ Analysis: Determined need to add timeout tests
|
|
73
|
+
7. ✅ Test Creation: Added test cases for timeout scenarios
|
|
74
|
+
8. ✅ Failure Verification: Confirmed tests fail before fix
|
|
75
|
+
9. ✅ Review: Set status:needs-review
|
|
76
|
+
10. ✅ Iteration: Incorporated feedback, updated tests
|
|
77
|
+
Result: Comprehensive test coverage with proper structure
|
|
78
|
+
```
|
|
79
|
+
|
|
80
|
+
### Bad: Incomplete Testing Process
|
|
81
|
+
```
|
|
82
|
+
Issue #84: "Fix API integration timeout"
|
|
83
|
+
1. ✅ Identified: Issue #84
|
|
84
|
+
2. ❌ Skip: Didn't review RFC
|
|
85
|
+
3. ❌ Skip: Started testing without understanding requirements
|
|
86
|
+
4. ❌ Skip: No test cases written
|
|
87
|
+
5. ❌ Skip: Didn't verify tests fail
|
|
88
|
+
6. ❌ Skip: No test structure followed
|
|
89
|
+
Result: Incomplete, ineffective testing
|
|
90
90
|
```
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "fraim-framework",
|
|
3
|
-
"version": "2.0.
|
|
3
|
+
"version": "2.0.5",
|
|
4
4
|
"description": "FRAIM v2: Framework for Rigor-based AI Management - Transform from solo developer to AI manager orchestrating production-ready code with enterprise-grade discipline",
|
|
5
5
|
"main": "index.js",
|
|
6
6
|
"bin": {
|
package/setup.js
CHANGED
|
@@ -935,6 +935,14 @@ function copyAdditionalFiles() {
|
|
|
935
935
|
'tsconfig.json'
|
|
936
936
|
];
|
|
937
937
|
|
|
938
|
+
// Copy GitHub workflow files
|
|
939
|
+
const workflowFiles = [
|
|
940
|
+
'.github/workflows/ci.yml',
|
|
941
|
+
'.github/workflows/phase-change.yml',
|
|
942
|
+
'.github/workflows/status-change.yml',
|
|
943
|
+
'.github/workflows/sync-on-pr-review.yml'
|
|
944
|
+
];
|
|
945
|
+
|
|
938
946
|
additionalFiles.forEach(file => {
|
|
939
947
|
try {
|
|
940
948
|
const sourcePath = path.join(__dirname, file);
|
|
@@ -951,6 +959,27 @@ function copyAdditionalFiles() {
|
|
|
951
959
|
}
|
|
952
960
|
});
|
|
953
961
|
|
|
962
|
+
// Copy GitHub workflow files
|
|
963
|
+
workflowFiles.forEach(file => {
|
|
964
|
+
try {
|
|
965
|
+
const sourcePath = path.join(__dirname, file);
|
|
966
|
+
const destPath = file;
|
|
967
|
+
|
|
968
|
+
// Ensure the .github/workflows directory exists
|
|
969
|
+
const destDir = path.dirname(destPath);
|
|
970
|
+
ensureDirectory(destDir);
|
|
971
|
+
|
|
972
|
+
if (fs.existsSync(sourcePath)) {
|
|
973
|
+
fs.copyFileSync(sourcePath, destPath);
|
|
974
|
+
logSuccess(`Copied ${file}`);
|
|
975
|
+
} else {
|
|
976
|
+
console.log(`⚠️ Warning: ${file} not found in package`);
|
|
977
|
+
}
|
|
978
|
+
} catch (error) {
|
|
979
|
+
console.log(`⚠️ Warning: Could not copy ${file}: ${error.message}`);
|
|
980
|
+
}
|
|
981
|
+
});
|
|
982
|
+
|
|
954
983
|
// Copy examples
|
|
955
984
|
try {
|
|
956
985
|
const examplesSource = path.join(__dirname, 'examples', 'simple-webapp');
|
package/DISTRIBUTION.md
DELETED
|
@@ -1,187 +0,0 @@
|
|
|
1
|
-
# 🚀 FRAIM Distribution Guide
|
|
2
|
-
|
|
3
|
-
**Framework for Rigor-based AI Management - Where humans become AI managers through rigorous methodology**
|
|
4
|
-
|
|
5
|
-
This guide covers all the ways to distribute and adopt the FRAIM framework.
|
|
6
|
-
|
|
7
|
-
P.S. I have only tested #1 so far
|
|
8
|
-
|
|
9
|
-
## 📦 Distribution Methods
|
|
10
|
-
|
|
11
|
-
### 1. **NPX (Recommended)**
|
|
12
|
-
```bash
|
|
13
|
-
npx @fraim/framework init
|
|
14
|
-
```
|
|
15
|
-
|
|
16
|
-
**Benefits:**
|
|
17
|
-
- Instant execution without installation
|
|
18
|
-
- Always uses latest version
|
|
19
|
-
- No global dependencies
|
|
20
|
-
- Cross-platform compatibility
|
|
21
|
-
|
|
22
|
-
**Package Details:**
|
|
23
|
-
- Name: `@fraim/framework`
|
|
24
|
-
- Scope: `@fraim`
|
|
25
|
-
- Registry: npmjs.com
|
|
26
|
-
|
|
27
|
-
### 2. **Python Package (pip)**
|
|
28
|
-
```bash
|
|
29
|
-
pip install fraim-framework
|
|
30
|
-
fraim init
|
|
31
|
-
```
|
|
32
|
-
|
|
33
|
-
**Benefits:**
|
|
34
|
-
- Python ecosystem integration
|
|
35
|
-
- Virtual environment support
|
|
36
|
-
- Easy dependency management
|
|
37
|
-
- Cross-platform compatibility
|
|
38
|
-
|
|
39
|
-
**Package Details:**
|
|
40
|
-
- Name: `fraim-framework`
|
|
41
|
-
- Registry: PyPI
|
|
42
|
-
- Python: >=3.8
|
|
43
|
-
|
|
44
|
-
### 3. **One-Line Installer**
|
|
45
|
-
```bash
|
|
46
|
-
curl -sSL https://fraim.dev/install.sh | bash -s -- --repo owner/repository
|
|
47
|
-
```
|
|
48
|
-
|
|
49
|
-
**Benefits:**
|
|
50
|
-
- No package manager required
|
|
51
|
-
- Works on any Unix-like system
|
|
52
|
-
- Direct GitHub integration
|
|
53
|
-
- Customizable installation
|
|
54
|
-
|
|
55
|
-
### 4. **GitHub Action**
|
|
56
|
-
```yaml
|
|
57
|
-
- uses: mathursrus/fraim-setup@v1
|
|
58
|
-
with:
|
|
59
|
-
repository: ${{ github.repository }}
|
|
60
|
-
config: fraim-config.json
|
|
61
|
-
```
|
|
62
|
-
|
|
63
|
-
**Benefits:**
|
|
64
|
-
- Automated setup in CI/CD
|
|
65
|
-
- Repository integration
|
|
66
|
-
- Team collaboration
|
|
67
|
-
- Version control
|
|
68
|
-
|
|
69
|
-
## 🎯 Quick Start Snippets
|
|
70
|
-
|
|
71
|
-
### For New Repositories
|
|
72
|
-
```bash
|
|
73
|
-
# Create new repo and setup FRAIM
|
|
74
|
-
gh repo create my-ai-project --public
|
|
75
|
-
cd my-ai-project
|
|
76
|
-
npx @fraim/framework init
|
|
77
|
-
```
|
|
78
|
-
|
|
79
|
-
### For Existing Repositories
|
|
80
|
-
```bash
|
|
81
|
-
# Add FRAIM to existing project
|
|
82
|
-
cd existing-project
|
|
83
|
-
npx @fraim/framework init
|
|
84
|
-
```
|
|
85
|
-
|
|
86
|
-
## 🔧 Configuration Options
|
|
87
|
-
|
|
88
|
-
### Basic Setup
|
|
89
|
-
```json
|
|
90
|
-
{
|
|
91
|
-
"repository": {
|
|
92
|
-
"owner": "your-org",
|
|
93
|
-
"name": "your-repo"
|
|
94
|
-
},
|
|
95
|
-
"features": {
|
|
96
|
-
"labels": true,
|
|
97
|
-
"workflows": true,
|
|
98
|
-
"agentRules": ["cursor", "claude", "windsurf"]
|
|
99
|
-
}
|
|
100
|
-
}
|
|
101
|
-
```
|
|
102
|
-
|
|
103
|
-
### Advanced Setup
|
|
104
|
-
```json
|
|
105
|
-
{
|
|
106
|
-
"features": {
|
|
107
|
-
"deployments": {
|
|
108
|
-
"enabled": true,
|
|
109
|
-
"environments": ["staging", "production"]
|
|
110
|
-
},
|
|
111
|
-
"notifications": {
|
|
112
|
-
"slack": "webhook-url",
|
|
113
|
-
"teams": "webhook-url"
|
|
114
|
-
}
|
|
115
|
-
},
|
|
116
|
-
"phases": {
|
|
117
|
-
"design": { "required_approvals": 2 },
|
|
118
|
-
"implementation": { "required_approvals": 3 },
|
|
119
|
-
"testing": { "auto_deploy": true }
|
|
120
|
-
}
|
|
121
|
-
}
|
|
122
|
-
```
|
|
123
|
-
|
|
124
|
-
## 🚀 Launch Strategy
|
|
125
|
-
|
|
126
|
-
### Phase 1: Early Adopters
|
|
127
|
-
- **Target**: Individual developers and small teams
|
|
128
|
-
- **Distribution**: NPX and GitHub releases
|
|
129
|
-
- **Focus**: Core functionality and documentation
|
|
130
|
-
|
|
131
|
-
### Phase 2: Team Adoption
|
|
132
|
-
- **Target**: Development teams and organizations
|
|
133
|
-
- **Distribution**: Python package and GitHub Actions
|
|
134
|
-
- **Focus**: Team coordination and advanced features
|
|
135
|
-
|
|
136
|
-
### Phase 3: Enterprise
|
|
137
|
-
- **Target**: Large organizations and enterprises
|
|
138
|
-
- **Distribution**: Enterprise packages and support
|
|
139
|
-
- **Focus**: Compliance, security, and scalability
|
|
140
|
-
|
|
141
|
-
## 📊 Success Metrics
|
|
142
|
-
|
|
143
|
-
### Adoption Metrics
|
|
144
|
-
- **Downloads**: NPX executions, pip installs
|
|
145
|
-
- **Repositories**: GitHub stars, forks, usage
|
|
146
|
-
- **Community**: Issues, PRs, discussions
|
|
147
|
-
|
|
148
|
-
### Usage Metrics
|
|
149
|
-
- **Active Users**: Monthly active repositories
|
|
150
|
-
- **Feature Usage**: Workflow executions, label usage
|
|
151
|
-
- **Retention**: Repeat usage, long-term adoption
|
|
152
|
-
|
|
153
|
-
### Quality Metrics
|
|
154
|
-
- **Satisfaction**: User ratings, feedback scores
|
|
155
|
-
- **Support**: Issue resolution time, documentation quality
|
|
156
|
-
- **Performance**: Setup time, workflow success rates
|
|
157
|
-
|
|
158
|
-
## 🔗 Distribution URLs
|
|
159
|
-
|
|
160
|
-
### Primary
|
|
161
|
-
- **NPX**: `npx @fraim/framework`
|
|
162
|
-
- **Python**: `pip install fraim-framework`
|
|
163
|
-
- **GitHub**: `https://github.com/mathursrus/FRAIM`
|
|
164
|
-
|
|
165
|
-
### Documentation
|
|
166
|
-
- **Main Docs**: `https://fraim.dev`
|
|
167
|
-
- **GitHub Wiki**: `https://github.com/mathursrus/FRAIM/wiki`
|
|
168
|
-
- **Examples**: `https://github.com/mathursrus/FRAIM/tree/master/examples`
|
|
169
|
-
|
|
170
|
-
### Support
|
|
171
|
-
- **Issues**: `https://github.com/mathursrus/FRAIM/issues`
|
|
172
|
-
- **Discussions**: `https://github.com/mathursrus/FRAIM/discussions`
|
|
173
|
-
- **Community**: `https://github.com/mathursrus/FRAIM/community`
|
|
174
|
-
|
|
175
|
-
## 🎯 Next Steps
|
|
176
|
-
|
|
177
|
-
1. **Choose Distribution Method**: Select the best option for your use case
|
|
178
|
-
2. **Setup FRAIM**: Follow the [quick start guide](docs/guides/getting-started.md)
|
|
179
|
-
3. **Configure Agents**: Customize AI agent rules and workflows
|
|
180
|
-
4. **Start Managing**: Begin coordinating AI agents with RIGOR methodology
|
|
181
|
-
5. **Share Feedback**: Contribute to the community and framework improvement
|
|
182
|
-
|
|
183
|
-
---
|
|
184
|
-
|
|
185
|
-
**Ready to become an AI manager?** 🚀
|
|
186
|
-
|
|
187
|
-
Start your FRAIM journey today with any of the distribution methods above!
|
package/PUBLISH_INSTRUCTIONS.md
DELETED
|
@@ -1,93 +0,0 @@
|
|
|
1
|
-
# Publishing FRAIM v2 to npm
|
|
2
|
-
|
|
3
|
-
## Prerequisites
|
|
4
|
-
1. **npm account**: You need an npm account to publish packages
|
|
5
|
-
2. **npm CLI**: Make sure you have npm installed and updated
|
|
6
|
-
|
|
7
|
-
## Step 1: Login to npm
|
|
8
|
-
```bash
|
|
9
|
-
npm login
|
|
10
|
-
```
|
|
11
|
-
Enter your npm username, password, and email when prompted.
|
|
12
|
-
|
|
13
|
-
## Step 2: Verify Login
|
|
14
|
-
```bash
|
|
15
|
-
npm whoami
|
|
16
|
-
```
|
|
17
|
-
Should display your npm username.
|
|
18
|
-
|
|
19
|
-
## Step 3: Test the Package (Optional but Recommended)
|
|
20
|
-
```bash
|
|
21
|
-
# Test the package locally
|
|
22
|
-
npm pack
|
|
23
|
-
# This creates a .tgz file you can inspect
|
|
24
|
-
|
|
25
|
-
# Test installation locally
|
|
26
|
-
npm install -g ./fraim-framework-2.0.0.tgz
|
|
27
|
-
fraim --help
|
|
28
|
-
```
|
|
29
|
-
|
|
30
|
-
## Step 4: Publish to npm
|
|
31
|
-
```bash
|
|
32
|
-
npm publish
|
|
33
|
-
```
|
|
34
|
-
|
|
35
|
-
## Step 5: Verify Publication
|
|
36
|
-
```bash
|
|
37
|
-
# Check the package on npm
|
|
38
|
-
npm view fraim-framework
|
|
39
|
-
|
|
40
|
-
# Test installation from npm
|
|
41
|
-
npm install -g fraim-framework@2.0.0
|
|
42
|
-
fraim --help
|
|
43
|
-
```
|
|
44
|
-
|
|
45
|
-
## What's Included in v2.0.0
|
|
46
|
-
|
|
47
|
-
### 🚀 Major Features
|
|
48
|
-
- **Complete Generic Framework**: No Ashley-specific IP
|
|
49
|
-
- **13 Comprehensive Rule Files**: Full AI agent management
|
|
50
|
-
- **Simplified Label System**: 9 essential labels
|
|
51
|
-
- **Spec Workflow**: Requirements and UX definition
|
|
52
|
-
- **Timeout Management**: Advanced script execution with visibility
|
|
53
|
-
- **Evidence-Based Validation**: Mandatory test evidence
|
|
54
|
-
- **Systematic Debugging**: Structured debugging patterns
|
|
55
|
-
|
|
56
|
-
### 📦 Package Contents
|
|
57
|
-
- `bin/fraim.js` - Main CLI executable
|
|
58
|
-
- `index.js` - Main entry point
|
|
59
|
-
- `setup.js` - Setup script for new projects
|
|
60
|
-
- `package.json` - Package configuration (v2.0.0)
|
|
61
|
-
- `.ai-agents/` - Complete rule system
|
|
62
|
-
- `examples/` - Example test cases with documentation
|
|
63
|
-
- `CHANGELOG.md` - Detailed changelog
|
|
64
|
-
- `README.md` - Marketing-style documentation
|
|
65
|
-
|
|
66
|
-
### 🎯 Installation
|
|
67
|
-
```bash
|
|
68
|
-
npm install -g fraim-framework
|
|
69
|
-
fraim init
|
|
70
|
-
```
|
|
71
|
-
|
|
72
|
-
## Post-Publication Tasks
|
|
73
|
-
|
|
74
|
-
1. **Update README**: Ensure all installation instructions use the new v2 commands
|
|
75
|
-
2. **GitHub Release**: Create a GitHub release for v2.0.0
|
|
76
|
-
3. **Documentation**: Update any external documentation
|
|
77
|
-
4. **Social Media**: Share the LinkedIn post about v2
|
|
78
|
-
|
|
79
|
-
## Rollback Plan (if needed)
|
|
80
|
-
```bash
|
|
81
|
-
# If you need to unpublish (only works within 24 hours)
|
|
82
|
-
npm unpublish fraim-framework@2.0.0
|
|
83
|
-
|
|
84
|
-
# Or deprecate the version
|
|
85
|
-
npm deprecate fraim-framework@2.0.0 "Use latest version instead"
|
|
86
|
-
```
|
|
87
|
-
|
|
88
|
-
## Success Metrics
|
|
89
|
-
- Package successfully published to npm
|
|
90
|
-
- Installation works: `npm install -g fraim-framework`
|
|
91
|
-
- CLI works: `fraim --help`
|
|
92
|
-
- Setup works: `fraim init`
|
|
93
|
-
- All examples and documentation updated
|
package/getting-started.md
DELETED
|
@@ -1,143 +0,0 @@
|
|
|
1
|
-
# 🚀 Getting Started with FRAIM
|
|
2
|
-
|
|
3
|
-
**Framework for Rigor-based AI Management**
|
|
4
|
-
|
|
5
|
-
Welcome to FRAIM! This guide will transform you from a developer into an AI manager in under 30 seconds.
|
|
6
|
-
|
|
7
|
-
## 🎯 What is FRAIM?
|
|
8
|
-
|
|
9
|
-
FRAIM is a framework that empowers human developers to coordinate AI agents using the **RIGOR methodology**: Reviews • Isolation • GitOps • Observability • Retrospectives.
|
|
10
|
-
|
|
11
|
-
Instead of manually managing AI tools, FRAIM gives you the structure and automation to orchestrate AI agents like a professional team manager.
|
|
12
|
-
|
|
13
|
-
## 🚀 Quick Start (30 seconds)
|
|
14
|
-
|
|
15
|
-
### 1. Navigate to Your Repository
|
|
16
|
-
```bash
|
|
17
|
-
cd your-project
|
|
18
|
-
```
|
|
19
|
-
|
|
20
|
-
### 2. Setup FRAIM
|
|
21
|
-
```bash
|
|
22
|
-
npx @fraim/setup init
|
|
23
|
-
```
|
|
24
|
-
|
|
25
|
-
### 3. Create Your Issue List in your Git Repo
|
|
26
|
-
```bash
|
|
27
|
-
gh issue create --title "Add user authentication"
|
|
28
|
-
```
|
|
29
|
-
|
|
30
|
-
### 4. Let your AI Agents do the Magic! 🎉
|
|
31
|
-
Cursor: @design 1
|
|
32
|
-
Windsurf: /start-design 1
|
|
33
|
-
Claude: @design 1
|
|
34
|
-
|
|
35
|
-
AI Agent automatically:
|
|
36
|
-
- 🔄 Labels the Git issue with phase:design
|
|
37
|
-
|
|
38
|
-
GitHub automatically:
|
|
39
|
-
- 🔄 Creates branch: `feature/1-add-user-authentication`
|
|
40
|
-
- 🔄 Creates draft PR
|
|
41
|
-
- 🔄 Sets status: `status:wip`
|
|
42
|
-
|
|
43
|
-
AI Agent automatically:
|
|
44
|
-
- 🔄 Checks out the new branch
|
|
45
|
-
- 🔄 Researches codebase, architecture, issue and writes a PRD/RFC
|
|
46
|
-
- 🔄 Commits, Syncs the branch and Labels the Git issue with status:needs-review for you to PR
|
|
47
|
-
|
|
48
|
-
You:
|
|
49
|
-
- Watch the magic happen
|
|
50
|
-
- Review the PR like you normally would, and add comments
|
|
51
|
-
- Let the AI Agent know if you want it to iterate, or proceed to @implement (Claude, Cursor), or /start-impl (Windsurf)
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
## 🧠 Understanding the RIGOR Methodology
|
|
55
|
-
|
|
56
|
-
FRAIM is built on five core principles that ensure reliable, scalable, continuously improving AI coordination:
|
|
57
|
-
|
|
58
|
-
- **R**eviews: Structured feedback and approval processes
|
|
59
|
-
- **I**solation: Agents don't interfere with each others' work *unless* you explicitly ask them to
|
|
60
|
-
- **G**itOps: Git as the single source of truth and the glue between you and your agents
|
|
61
|
-
- **O**bservability: Complete visibility into AI activities
|
|
62
|
-
- **R**etrospectives: Continuous learning from mistakes and positive experiences
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
## 📋 Workflow Phases
|
|
66
|
-
|
|
67
|
-
### Phase 1: Design (`phase:design`)
|
|
68
|
-
1. **You**: Tell the agent to move into this phase and give it the issue number
|
|
69
|
-
2. **AI Action**: Labels issue `phase:design`, moves to branch, creates RFC/UX/test-plan, commits and sends out PR, labels issue `status:needs-review`
|
|
70
|
-
3. **Review**: Stakeholders review and approve design
|
|
71
|
-
4. **Issue, PR State**: Git automatically changes status between wip, complete
|
|
72
|
-
|
|
73
|
-
### Phase 2: Implementation (`phase:impl`)
|
|
74
|
-
1. **You**: Tell the agent to move into this phase
|
|
75
|
-
2. **AI Action**: Labels issue `phase:impl`, moves to branch, consults issue/code/rfcs, implements code and tests, runs tests, commits and sends out PR
|
|
76
|
-
3. **Review**: Stakeholders review and approve implementation
|
|
77
|
-
4. **Issue, PR State**: Git automatically changes status between wip, complete
|
|
78
|
-
|
|
79
|
-
### Phase 3: Resolve
|
|
80
|
-
1. **You**: Tell the agent to move into this phase once totally satisfied with the implementation and tests
|
|
81
|
-
2. **AI Action**: Pulls from master, deals with merge issues (with your help if needed), confirms everything still works, pushes to master, deletes remote and local branches, cleans up local copy of the branch
|
|
82
|
-
3. **Git**: Runs CI and prevents merging if failed
|
|
83
|
-
|
|
84
|
-
## 🏷️ Label System
|
|
85
|
-
|
|
86
|
-
### Phase Labels
|
|
87
|
-
- `phase:design` - Design and RFC creation
|
|
88
|
-
- `phase:impl` - Implementation and development
|
|
89
|
-
- `phase:tests` - Testing and validation (if needed, I ask AI Agents to write tests as part of implementation)
|
|
90
|
-
|
|
91
|
-
### Status Labels
|
|
92
|
-
- `status:wip` - Work in progress
|
|
93
|
-
- `status:needs-review` - Ready for review
|
|
94
|
-
- `status:complete` - Work completed
|
|
95
|
-
|
|
96
|
-
### Agent Labels (for future, I don't use these yet)
|
|
97
|
-
- `ai-agent:cursor` - Assigned to Cursor
|
|
98
|
-
- `ai-agent:claude` - Assigned to Claude
|
|
99
|
-
- `ai-agent:windsurf` - Assigned to Windsurf
|
|
100
|
-
|
|
101
|
-
## 🔧 Advanced Setup
|
|
102
|
-
|
|
103
|
-
### Interactive Wizard
|
|
104
|
-
```bash
|
|
105
|
-
npx @fraim/setup wizard
|
|
106
|
-
```
|
|
107
|
-
|
|
108
|
-
The wizard will ask you:
|
|
109
|
-
- Which AI agents to enable
|
|
110
|
-
- Whether to enable deployment workflows
|
|
111
|
-
- Whether to run in dry-run mode first
|
|
112
|
-
|
|
113
|
-
### Custom Configuration
|
|
114
|
-
```bash
|
|
115
|
-
npx @fraim/setup setup owner/repository --config custom-config.json
|
|
116
|
-
```
|
|
117
|
-
|
|
118
|
-
### Partial Setup
|
|
119
|
-
```bash
|
|
120
|
-
# Only create labels
|
|
121
|
-
npx @fraim/setup setup owner/repository --labels-only
|
|
122
|
-
|
|
123
|
-
# Only setup workflows
|
|
124
|
-
npx @fraim/setup setup owner/repository --workflows-only
|
|
125
|
-
```
|
|
126
|
-
|
|
127
|
-
## 🎯 Success Metrics - I hope these happen for you
|
|
128
|
-
|
|
129
|
-
- **Setup Time**: < 30 seconds to get started
|
|
130
|
-
- **Issue Resolution**: Faster development cycles
|
|
131
|
-
- **Code Quality**: Higher quality through AI coordination
|
|
132
|
-
- **Learning**: Better understanding of AI capabilities
|
|
133
|
-
|
|
134
|
-
## 🚀 Ready to Become an AI Manager?
|
|
135
|
-
|
|
136
|
-
```bash
|
|
137
|
-
npx @fraim/setup init
|
|
138
|
-
```
|
|
139
|
-
|
|
140
|
-
**FRAIM: Where humans become AI managers through rigorous methodology**
|
|
141
|
-
|
|
142
|
-
---
|
|
143
|
-
|
package/linkedin-post.md
DELETED
|
@@ -1,23 +0,0 @@
|
|
|
1
|
-
# FRAIMv2 - The Future of how we work with AI?
|
|
2
|
-
|
|
3
|
-
🚀 **AI coding agents are brilliant but chaotic.**
|
|
4
|
-
|
|
5
|
-
They can build prototypes fast, but fail spectacularly at production-ready code.
|
|
6
|
-
|
|
7
|
-
**Solution: Manage them like human developers.**
|
|
8
|
-
|
|
9
|
-
FRAIMv2 applies enterprise-grade discipline to AI agent teams:
|
|
10
|
-
• Clear guardrails to prevent costly mistakes
|
|
11
|
-
• Structured workflows to avoid chaos
|
|
12
|
-
• Evidence-based validation (not "looks good" claims)
|
|
13
|
-
• Learning systems to improve over time
|
|
14
|
-
• Debugging patterns and anti-patterns
|
|
15
|
-
• Balance between determinism and creativity
|
|
16
|
-
|
|
17
|
-
**Result:** Transform from solo developer to AI manager orchestrating production-ready code.
|
|
18
|
-
|
|
19
|
-
Is this the future of how we work?
|
|
20
|
-
|
|
21
|
-
Ready to transform how you work with AI? Check out FRAIM: https://github.com/mathursrus/FRAIM
|
|
22
|
-
|
|
23
|
-
#AI #SoftwareDevelopment #Productivity #Innovation #TechLeadership #Coding #Agile #DevOps
|