fraim-framework 1.0.0

package/agents/cursor/rules/resolve.mdc

@@ -0,0 +1,46 @@
+---
+description: Start resolution workflow
+alwaysApply: false
+---
+Ensure branch: feature/{issue}-{slug} is checked out (create if needed).
+
+Commit & push any pending changes.
+
+Sync from origin/master into this branch (merge or rebase), resolve conflicts, push again.
+
+Check the results of GitHub Action that runs the full tests in the cloud.
+
+If they pass: open/update the Implementation PR, label it, and enable auto-merge.
+
+If they fail: no PR is opened/updated; fix, push again, repeat.
+
+Once PR is approved and related actions succeed, do the following: 
+- **MANDATORY**: Verify PR is actually merged to master before proceeding
+- **MANDATORY**: Run merge verification checks (see below)
+- Close the issue ONLY after merge verification passes
+- Delete the branch remotely.
+- If operating locally, delete the local branch and the local codebase.
+- Say Hoorah !
+
+## Mandatory Merge Verification
+
+**Before closing ANY issue, verify the following:**
+
+1. ✅ **PR Status**: PR shows "merged" status, not just "closed"
+2. ✅ **Merge Commit**: Verify merge commit exists in master
+3. ✅ **Files in Master**: Confirm expected files are present in master
+
+### **Verification Commands**
+```bash
+# Check PR is merged, not just closed
+gh pr view <PR_NUMBER> --json merged
+
+# Verify merge commit in master
+git fetch origin master
+git log origin/master --oneline | grep "PR #<PR_NUMBER>"
+
+# Verify files in master
+git show origin/master:path/to/expected/file
+```
+
+**CRITICAL**: Do not close the issue until merge verification passes. This prevents work loss incidents.

package/agents/cursor/rules/simplicity.mdc

@@ -0,0 +1,18 @@
+---
+description:
+globs:
+alwaysApply: true
+---
+
+****Keep it simple. Don't over-engineer. *****
+Don't over-think it. 
+While fixing an issue, focus on that issue only. Don't fix other issues. Don't make unrelated changes. Instead, file a Git issue if you find other issues that aren't already tracked by an existing Git issue.
+
+
+Always verify the action you have taken. Do not expect the user to verify it for you. 
+If you kicked off a Git workflow, verify it completed successfully (e.g., gh checks: list or PR status).
+If you wrote a test and expect it to pass, run it yourself and verify it passes; if you expect it to fail, verify it fails.
+Always link work to the issue (use “Closes #<n>” in the Implementation PR).
+Open Draft PRs early; review happens in the PR, not in chat.
+
+Agents must not run gh pr create. Push to the feature branch and let Actions open Draft PRs.

package/agents/cursor/rules/software-development-lifecycle.mdc

@@ -0,0 +1,41 @@
+---
+description: Issue resolution process for local development with branch/clone approach
+alwaysApply: true
+---
+
+# Issue Resolution Process
+
+Always work on the feature branch for the current issue: `feature/<issue#>-<kebab-title>`. Never push to master.
+
+## Development Workflow
+1. **Clone Setup**: Work in your own cloned repository folder.
+2. **Branch Management**: Create/checkout feature branch for your issue
+3. **Local Development**: Make changes, run tests locally
+4. **Check before commit**: Only commit after approval from the user.
+5. **Remote Coordination**: Use GitHub MCP for issue labels
+
+## Phases
+- **Design**: Set ISSUE to `phase:design` → create RFC
+- **Implementation**: Set ISSUE to `phase:impl` → implement solution
+
+## Status Management
+- **WIP**: Automatically set when entering new phase
+- **Needs Review**: Set this when work is ready for review
+- **Complete**: Automatically set when PR is approved
+
+## PR Requirements
+- Implementation PR body MUST include `Closes #<n>`
+- Let Actions handle PR creation and updates
+- Address all reviewer feedback before completion
+
+## Cleanup
+When user confirms code is correctly merged into master, confirm with the user, then 
+- delete remote branch
+- delete local branch
+- remove your local clone folder:
+```
+cd ..
+Remove-Item -Recurse -Force "<repo> - Issue {issue_number}"
+```
+
+Respect CODEOWNERS; don't modify auth/CI without approval.

package/agents/cursor/rules/test.mdc

@@ -0,0 +1,25 @@
+---
+description: Start testing workflow
+alwaysApply: false
+---
+Step 1: Ask for {issue_number} (and optional {slug}); confirm target branch feature/{issue_number}-{slug}.
+
+Step 2: Using GitHub MCP, ensure the branch exists (your GitHub Action will usually auto-create it) and checkout it.
+
+Step 3: Label the issue 'phase:tests'. (GitHub Action will automatically label the issue `status:wip`, create a draft PR)
+
+Step 4: Do your work either remotely or locally as defined by the user. If unsure, ask the user. Once sure, let the user know. 
+
+Step 5: Your work entails the following
+
+ - Review the RFC associated with this issue.
+
+ - Determine whether tests need to be added to an existing test suite, or a new one needs to be created.
+
+ - Write the minimal set of test cases that accurately reproduce the issue
+
+ - Run the test cases to ensure they fail
+
+ - Flip issue to 'status:needs-review' and remove 'status:wip'
+
+Step 6: 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.

package/agents/windsurf/rules/architecture.md

@@ -0,0 +1,49 @@
+---
+trigger: always_on
+---
+
+
+# Architecture
+
+## Intent
+Keep the architecture clean: use BAML (LLM) for any natural-language understanding, fuzzy matching, or semantic comparison. Use deterministic TypeScript only for side-effectful or strictly rule-based work (APIs, DB, validation, formatting, scheduling, retries).
+
+## Principles (follow in this order)
+1. Parse (LLM/BAML) → 2. Normalize (deterministic) → 3. Validate (deterministic) → 4. Decide (LLM if subjective; code if rules) → 5. Act (deterministic side effects)
+
+## LLM/BAML Usage
+- Entity/intent extraction, timezone/place inference, date/time range interpretation
+- Participant role classification, preference inference, text similarity
+- De-dupe by meaning, natural language understanding
+
+## Deterministic TypeScript Usage
+- ISO date math, schema validation, authZ/authN, idempotency keys
+- OpenAPI I/O, DB writes, calendar invites, retries/timeouts
+- Metrics/telemetry, side effects
+
+## Do / Don't
+
+### Do (LLM/BAML)
+- NLP; Anything that needs understanding from user unstructured input
+
+### Do (Deterministic TS)
+- Ensure structure through interfaces, folder management, test cases
+
+### Don't
+- Don't hand-roll regex/heuristics for dates/locations/intent
+- Don't duplicate LLM functionality
+- Don't call BAML for pure formatting (e.g., toISOString, trimming)
+
+## Project Structure
+- **BAML sources**: `/baml_src/**/*.baml`
+- **Generated client**: `/baml_client/**` (run `baml-cli generate`)
+- **Deterministic logic**: `/src/**`
+- **Design docs + Test plans**: `/docs/rfcs/*.md`
+- **Random utility scripts**: `/scripts` 
+- **Test cases**: `/` (at root level, these are the most important artifacts)
+
+## Local Development Notes
+- Test deterministic logic with unit tests before integrating with LLM components
+- Write test cases for each change. Tag representative ones with 'smoke'
+- Keep architecture boundaries clear between LLM and deterministic code
+- Document any architectural decisions in your RFC or implementation notes

package/agents/windsurf/rules/continuous-learning.md

@@ -0,0 +1,47 @@
+---
+trigger: always_on
+---
+
+# Continuous Learning
+
+## Retrospectives Review
+- **Always review** the `/retrospectives/` folder before starting work on similar issues
+- **Learn from past problems** - understand root cause analysis and lessons learned
+- **Apply previous solutions** - don't repeat mistakes that have already been solved
+
+## Knowledge Integration
+- **Read related RFCs** in `/docs/rfcs/` to understand design decisions
+- **Review test cases** to see how similar problems were approached
+- **Check issue history** for patterns in failures and solutions
+
+## Local Development Benefits
+- **Avoid known pitfalls** by learning from retrospectives
+- **Build on existing solutions** rather than starting from scratch
+- **Understand system constraints** from past architectural decisions
+
+## Before Starting Work
+1. **Search retrospectives** for related issues or similar problems
+2. **Read relevant RFCs** to understand the design context
+3. **Review test cases** to see expected behavior
+4. **Check issue comments** for previous attempts and solutions
+
+## Document Your Learning
+- **Update retrospectives** if you discover new insights
+- **Add to RFCs** if you find better approaches
+- **Share solutions** with other agents through issue comments
+
+## Retrospective Triggers
+
+### **Automatic Retrospective Requirements**
+- **Complex Issues (>3 iterations)**: Must create retrospective before issue closure
+- **Process Violations**: Any workflow rule violations require retrospectives
+- **Work Loss Incidents**: Any incidents where work is lost require detailed retrospectives
+
+### **Retrospective Creation Process**
+1. **Stop Current Work**: Pause issue resolution if retrospective is required
+2. **Create Retrospective**: Use standard template in retrospectives folder
+3. **Root Cause Analysis**: Identify underlying causes, not just symptoms
+4. **Prevention Measures**: Document specific actions to prevent recurrence
+5. **Process Updates**: Update rules and workflows based on learnings
+
+Remember: The best code is often written by those who learn from history rather than repeat it.

package/agents/windsurf/rules/local-development.md

@@ -0,0 +1,103 @@
+---
+trigger: manual
+---
+
+# Local Development with Remote Coordination
+
+- Use local file system for development work in your own cloned repository folder
+- Push to feature branches only; never push to master
+- Do NOT open PRs; push and let Actions open/update Draft PRs
+- Always work in your own cloned repository folder: `git clone <repo> "<repo> - Issue {issue_number}"`
+- After you create the clone, do not forget to change into that working directory. All your work **MUST** be in your working directory.
+- Coordinate with other agents through GitHub issues and PRs
+- Each agent works independently in their own folder to enable true parallel development
+
+## CRITICAL RULE: Absolute Workspace Separation
+
+### Local Clone: WORK-ONLY  
+- **Directory**: `<repo> - Issue <issue number>`
+- **Purpose**: All development work happens here exclusively
+- **Rule**: ALL file operations must be within this directory
+
+## Mandatory Pre-File-Operation Checklist
+
+**Before ANY file operation (edit_file, delete_file, etc.), verify:**
+
+1. ✅ **Directory Check**: `pwd` shows local clone with issue number in path
+2. ✅ **Path Verification**: File path is relative (no "../" or main workspace name)  
+3. ✅ **Branch Check**: `git branch` shows correct feature branch
+4. ❌ **If ANY check fails**: STOP immediately and fix location
+
+**This checklist is MANDATORY, not optional.**
+
+
+## Enhanced Stop Conditions
+
+**Stop ALL work immediately if:**
+- You create a file and it appears in main workspace
+- You use edit_file with "../" paths
+- You work in directory without issue number in name  
+- `pwd` shows main workspace path
+- Any file operation targets main workspace
+
+**Take corrective action before continuing.**
+
+## Workspace Validation Commands
+
+**Before starting work, run:**
+```bash
+echo "Working in: $(pwd)"
+echo "Should contain issue number in path"
+git branch
+echo "Should show feature branch"
+```
+
+**If output doesn't match expectations, fix before proceeding.**
+
+## Tool Usage Restrictions
+
+### File Operations - Local Only
+- `edit_file()` - ONLY with relative paths in local repo
+- `delete_file()` - ONLY within local repo
+- `search_replace()` - ONLY on local repo files
+
+### Reference Operations - Main Workspace OK  
+- `read_file()` - OK to read from main workspace for reference
+- `list_dir()` - OK to explore main workspace structure
+- `grep()` - OK to search main workspace for patterns
+
+## Violation Recovery Process
+
+**If you violate workspace boundaries:**
+
+1. **Stop immediately** - Do not continue file operations
+2. **Assess damage** - Check what was created in wrong location  
+3. **Clean up** - Delete files created in main workspace
+4. **Recreate correctly** - Recreate files in local repo only
+5. **Document violation** - Update post-mortem with details
+
+
+## Enhanced Output Template
+
+```
+Summary:
+  - Work completed in local repository: [path]
+  - Files created/modified: [list with relative paths]
+  - Workspace violations: [none/details if any occurred]
+
+Artifacts:
+  - Branch: [URL]
+  - Local directory: [full path to local clone]
+```
+
+## Emergency Safeguards
+
+**If assistant shows signs of workspace confusion:**
+- User should immediately clarify working directory
+- Assistant should run `pwd` and verify location
+- All file operations should pause until location confirmed
+- Assistant should explicitly state file paths being used
+
+---
+
+**Bottom Line**: The local development workflow requires absolute discipline about workspace boundaries. 

package/agents/windsurf/rules/remote-development.md

@@ -0,0 +1,22 @@
+---
+trigger: manual
+---
+
+# Remote-only, headless execution, bot-authored PRs
+- Use GitHub MCP for file edits, commits, and labels. Do not touch the local FS or run local servers.
+- Push to feature branches only; never push to master.
+- Do NOT open PRs via MCP; push and let Actions open/update Draft PRs (authored by bot).
+
+
+# Stop Criteria
+- When the work given to you is complete.
+- When workflows tied to your PR are successful. If workflows fail, your work is not complete. Keep at it.
+
+Output Template (use verbatim)
+- Summary:
+  - …
+  - …
+- Artifacts:
+  - Branch: <url>
+  - PR: <url>
+  - Issue: <url>

package/agents/windsurf/rules/simplicity.md

@@ -0,0 +1,17 @@
+---
+trigger: always_on
+---
+
+
+****Keep it simple. Don't over-engineer. *****
+Don't over-think it. 
+While fixing an issue, focus on that issue only. Don't fix other issues. Don't make unrelated changes. Instead, file a Git issue if you find other issues that aren't already tracked by an existing Git issue.
+
+
+Always verify the action you have taken. Do not expect the user to verify it for you. 
+If you kicked off a Git workflow, verify it completed successfully (e.g., gh checks: list or PR status).
+If you wrote a test and expect it to pass, run it yourself and verify it passes; if you expect it to fail, verify it fails.
+Always link work to the issue (use “Closes #<n>” in the Implementation PR).
+Open Draft PRs early; review happens in the PR, not in chat.
+
+Agents must not run gh pr create. Push to the feature branch and let Actions open Draft PRs.

package/agents/windsurf/rules/windsurf-workflow.md

@@ -0,0 +1,28 @@
+---
+trigger: always_on
+---
+
+# Windsurf Development Workflow
+
+## Goal
+Work efficiently in local environment while maintaining coordination with remote repository and other agents.
+
+## Behavior
+- Use local file system for development work
+- ***NEVER*** commit unless asked to do so
+- Produce clear progress updates with:
+  1. Actions executed (imperative, past tense)
+  2. Local progress (files modified, tests run)
+  3. Remote artifacts (branch, PR status)
+  4. Next steps for this issue
+  5. Blocking issues (if any)
+
+## Stop Criteria
+- When the assigned work is complete
+- When tests pass and PR is ready for review
+- When waiting for reviewer feedback
+
+## Output Template
+- Summary:
+  - Local progress: [what you accomplished locally]
+  - Remote status: [branch/PR status]

package/agents/windsurf/workflows/prep.md

@@ -0,0 +1,20 @@
+---
+description: Prep environment for issue
+auto_execution_mode: 3
+---
+
+Step 1: Ask for {issue_number}
+
+Step 2: Clone the repo to "<repo> - Issue {issue_number}" 
+- **CRITICAL**: Clone ONE LEVEL ABOVE the current workspace directory
+- **DO NOT** clone inside the current workspace folder
+- **VERIFY LOCATION**: Use `pwd` to confirm you're in the parent directory before cloning
+
+Step 3: Confirm items in the checklist and say "Huzzah!"
+
+
+## Safety Checklist
+- [ ] Confirmed current workspace path with `pwd`
+- [ ] Changed to parent directory (`cd ..`) before cloning
+- [ ] Verified clone location is outside current workspace
+- [ ] Successfully changed into cloned repository

package/agents/windsurf/workflows/resolve-issue.md

@@ -0,0 +1,47 @@
+---
+description: Resolve issue (once confirmed complete)
+auto_execution_mode: 3
+---
+
+Ensure branch: feature/{issue}-{slug} is checked out (create if needed).
+
+Commit & push any pending changes.
+
+Sync from origin/master into this branch (merge or rebase), resolve conflicts, push again.
+
+Check the results of GitHub Action that runs the full tests in the cloud.
+
+If they pass: open/update the Implementation PR, label it, and enable auto-merge.
+
+If they fail: no PR is opened/updated; fix, push again, repeat.
+
+Once PR is approved and related actions succeed, do the following: 
+- **MANDATORY**: Verify PR is actually merged to master before proceeding
+- **MANDATORY**: Run merge verification checks (see below)
+- Close the issue ONLY after merge verification passes
+- Delete the branch remotely.
+- If operating locally, delete the local branch and the local codebase.
+- Say Hoorah !
+
+## Mandatory Merge Verification
+
+**Before closing ANY issue, verify the following:**
+
+1. ✅ **PR Status**: PR shows "merged" status, not just "closed"
+2. ✅ **Merge Commit**: Verify merge commit exists in master
+3. ✅ **Files in Master**: Confirm expected files are present in master
+
+### **Verification Commands**
+```bash
+# Check PR is merged, not just closed
+gh pr view <PR_NUMBER> --json merged
+
+# Verify merge commit in master
+git fetch origin master
+git log origin/master --oneline | grep "PR #<PR_NUMBER>"
+
+# Verify files in master
+git show origin/master:path/to/expected/file
+```
+
+**CRITICAL**: Do not close the issue until merge verification passes. This prevents work loss incidents like Issue #112.

package/agents/windsurf/workflows/start-design.md

@@ -0,0 +1,26 @@
+---
+description: Start working on the issue
+auto_execution_mode: 3
+---
+
+Step 1: Ask for {issue_number} (and optional {slug})
+
+Step 2: Label the issue 'phase:design' (GitHub Action will automatically create a branch, label the issue `status:wip`, create a draft PR)
+
+Step 3: Using GitHub MCP, wait for the branch to get created, then do a checkout to start your work.
+
+*** IMPORTANT IF YOU ARE WORKING LOCALLY **** switch into your branch and ensure you work in your own folder. 
+
+Step 4: Do your work either remotely or locally as defined by the user. If unsure, ask the user. Once sure, let the user know.
+
+Step 5: Your work entails the following
+
+ - Create docs/rfcs/{issue_number}-{slug}.md.  
+
+ - If the issue requires a small fix or bug fix, use this template - docs/rfcs/BUG-TEMPLATE.md 
+
+ - If the issue requires major changes, use this template - docs/rfcs/RFC-TEMPLATE.md 
+
+ - When ready for review, flip issue to 'status:needs-review' and remove 'status:wip'
+
+Step 6: 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.

package/agents/windsurf/workflows/start-impl.md

@@ -0,0 +1,27 @@
+---
+description: Implement issue
+auto_execution_mode: 3
+---
+
+Step 1: Ask for {issue_number} (and optional {slug}); confirm target branch feature/{issue_number}-{slug}.
+
+Step 2: Ensure the branch exists (your GitHub Action will usually auto-create it) and checkout it. 
+
+Step 3: Label the issue 'phase:impl'. (GitHub Action will automatically label the issue `status:wip`, create a draft PR)
+
+Step 4: Do your work either remotely or locally as defined by the user. If unsure, ask the user. Once sure, let the user know.
+
+Step 5: Your work entails the following
+
+ - Review the RFC associated with this issue.
+
+ - Determine whether changes need to be made to existing code, or brand new code needs to be written.
+
+ - Write the minimal set of code and test cases needed for this issue.
+
+ - **Test cases must inherit from test-utils and follow the structure of the rest of the test suite**
+ - Ensure test cases pass.
+
+ - When ready for review, flip issue to 'status:needs-review' and remove 'status:wip'
+
+Step 6: 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.

package/agents/windsurf/workflows/start-tests.md

@@ -0,0 +1,26 @@
+---
+description: Start writing tests
+auto_execution_mode: 3
+---
+
+Step 1: Ask for {issue_number} (and optional {slug}); confirm target branch feature/{issue_number}-{slug}.
+
+Step 2: Using GitHub MCP, ensure the branch exists (your GitHub Action will usually auto-create it) and checkout it.
+
+Step 3: Label the issue 'phase:tests'. (GitHub Action will automatically label the issue `status:wip`, create a draft PR)
+
+Step 4: Do your work either remotely or locally as defined by the user. If unsure, ask the user. Once sure, let the user know. 
+
+Step 5: Your work entails the following
+
+ - Review the RFC associated with this issue.
+
+ - Determine whether tests need to be added to an existing test suite, or a new one needs to be created.
+
+ - Write the minimal set of test cases that accurately reproduce the issue
+
+ - Run the test cases to ensure they fail
+
+ - Flip issue to 'status:needs-review' and remove 'status:wip'
+
+Step 6: 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.

package/bin/fraim.js

@@ -0,0 +1,117 @@
+#!/usr/bin/env node
+
+// Simple banner without external dependencies
+const banner = `
+╔══════════════════════════════════════════════════════════════╗
+║  🚀 FRAIM                                                  ║
+║  Framework for Rigor-based AI Management                    ║
+║  Where humans become AI managers                            ║
+╚══════════════════════════════════════════════════════════════╝
+`;
+
+function showHelp() {
+    console.log(banner);
+    console.log('🤖 Welcome to FRAIM!');
+    console.log('Where humans become AI managers through rigorous methodology\n');
+    console.log('✨ All rules and workflows have been tested in real projects!\n');
+
+    console.log('🚀 Quick commands:');
+    console.log('  npx fraim-framework init     # Setup current repository');
+    console.log('  npx fraim-framework wizard   # Interactive setup');
+    console.log('  npx fraim-framework --help   # Full documentation');
+    console.log('  fraim rigor                   # Learn RIGOR methodology\n');
+
+    console.log('🧠 The RIGOR Methodology (Tested & Proven):');
+    console.log('  R - Reviews: Structured feedback and approval processes');
+    console.log('  I - Isolation: Agents don\'t interfere unless explicitly asked');
+    console.log('  G - GitOps: Git as the single source of truth and coordination glue');
+    console.log('  O - Observability: Complete visibility into AI activities');
+    console.log('  R - Retrospectives: Continuous learning from experience\n');
+
+    console.log('📚 Documentation: https://github.com/mathursrus/Ashley-Calendar-AI/tree/master/FRAIM');
+    console.log('🎯 Ready to become an AI manager? Run: npx fraim-framework init');
+}
+
+function showRigor() {
+    console.log(banner);
+    console.log('🧠 The RIGOR Methodology for AI Management (Tested & Proven)\n');
+
+    console.log('R - Reviews:');
+    console.log('  • Structured feedback and approval processes');
+    console.log('  • Code review workflows with AI agents');
+    console.log('  • Automated quality gates and checks');
+    console.log('  • Human oversight of AI decisions\n');
+
+    console.log('I - Isolation:');
+    console.log('  • Agents don\'t interfere with each others\' work');
+    console.log('  • Clear boundaries and responsibilities');
+    console.log('  • Coordinated handoffs between phases');
+    console.log('  • No unexpected side effects from other agents\n');
+
+    console.log('G - GitOps:');
+    console.log('  • Git as the single source of truth');
+    console.log('  • The glue between you and your AI agents');
+    console.log('  • Automated deployments from Git changes');
+    console.log('  • Version-controlled AI agent configurations\n');
+
+    console.log('O - Observability:');
+    console.log('  • Complete visibility into AI activities');
+    console.log('  • Metrics, logs, and tracing');
+    console.log('  • Performance monitoring and alerting');
+    console.log('  • Audit trails for compliance\n');
+
+    console.log('R - Retrospectives:');
+    console.log('  • Continuous learning from mistakes');
+    console.log('  • Learning from positive experiences');
+    console.log('  • Process improvement and refinement');
+    console.log('  • Knowledge sharing and documentation\n');
+
+    console.log('🎯 This methodology transforms you from a developer into an AI manager!');
+    console.log('✨ Every rule has been tested and proven in real project environments.');
+}
+
+function main() {
+    const args = process.argv.slice(2);
+
+    if (args.length === 0 || args.includes('--help') || args.includes('-h')) {
+        showHelp();
+        return;
+    }
+
+    if (args.includes('rigor')) {
+        showRigor();
+        return;
+    }
+
+    if (args.includes('init') || args.includes('setup')) {
+        console.log(banner);
+        console.log('🚀 Setting up FRAIM in current repository...\n');
+        console.log('📋 This will:');
+        console.log('  • Create GitHub labels for AI management');
+        console.log('  • Set up automated workflows');
+        console.log('  • Configure AI agent rules (all tested & proven)');
+        console.log('  • Initialize documentation\n');
+        console.log('💡 Run: npx fraim-framework init  # For full setup');
+        console.log('🔧 Or run: npx fraim-framework wizard  # For interactive setup');
+        return;
+    }
+
+    if (args.includes('wizard')) {
+        console.log(banner);
+        console.log('🔮 FRAIM Interactive Setup Wizard\n');
+        console.log('This wizard will guide you through:');
+        console.log('  1. Repository configuration');
+        console.log('  2. AI agent setup (with tested rules)');
+        console.log('  3. Workflow customization');
+        console.log('  4. Team member onboarding\n');
+        console.log('💡 Run: npx fraim-framework wizard  # To start the wizard');
+        return;
+    }
+
+    // Default help for unknown commands
+    console.log('❓ Unknown command. Use --help for available options.');
+    showHelp();
+}
+
+// Run the CLI
+main();