fraim-framework 2.0.52 → 2.0.54

package/registry/stubs/workflows/customer-development/ai-coach-phases/phase5-survey-build-facebook.md

@@ -0,0 +1,11 @@
+# FRAIM Workflow: phase5-survey-build-facebook
+
+> [!IMPORTANT]
+> This is a **FRAIM-managed workflow stub**. 
+> To load the full context (rules, templates, and execution steps), ask your AI agent to:
+> `@fraim get_fraim_workflow("phase5-survey-build-facebook")`
+>
+> DO NOT EXECUTE.
+
+## Intent
+No intent defined.

package/registry/stubs/workflows/customer-development/ai-coach-phases/phase6-survey-build-custom.md

@@ -0,0 +1,11 @@
+# FRAIM Workflow: phase6-survey-build-custom
+
+> [!IMPORTANT]
+> This is a **FRAIM-managed workflow stub**. 
+> To load the full context (rules, templates, and execution steps), ask your AI agent to:
+> `@fraim get_fraim_workflow("phase6-survey-build-custom")`
+>
+> DO NOT EXECUTE.
+
+## Intent
+No intent defined.

package/registry/stubs/workflows/customer-development/ai-coach-phases/phase7-survey-dispatch.md

@@ -0,0 +1,11 @@
+# FRAIM Workflow: phase7-survey-dispatch
+
+> [!IMPORTANT]
+> This is a **FRAIM-managed workflow stub**. 
+> To load the full context (rules, templates, and execution steps), ask your AI agent to:
+> `@fraim get_fraim_workflow("phase7-survey-dispatch")`
+>
+> DO NOT EXECUTE.
+
+## Intent
+No intent defined.

package/registry/stubs/workflows/customer-development/templates/customer-persona-template.md

@@ -0,0 +1,11 @@
+# FRAIM Workflow: customer-persona-template
+
+> [!IMPORTANT]
+> This is a **FRAIM-managed workflow stub**. 
+> To load the full context (rules, templates, and execution steps), ask your AI agent to:
+> `@fraim get_fraim_workflow("customer-persona-template")`
+>
+> DO NOT EXECUTE.
+
+## Intent
+No intent defined.

package/registry/stubs/workflows/customer-development/templates/search-strategy-template.md

@@ -0,0 +1,11 @@
+# FRAIM Workflow: search-strategy-template
+
+> [!IMPORTANT]
+> This is a **FRAIM-managed workflow stub**. 
+> To load the full context (rules, templates, and execution steps), ask your AI agent to:
+> `@fraim get_fraim_workflow("search-strategy-template")`
+>
+> DO NOT EXECUTE.
+
+## Intent
+No intent defined.

package/registry/stubs/workflows/customer-development/user-survey-dispatch.md

@@ -0,0 +1,11 @@
+# FRAIM Workflow: user-survey-dispatch
+
+> [!IMPORTANT]
+> This is a **FRAIM-managed workflow stub**. 
+> To load the full context (rules, templates, and execution steps), ask your AI agent to:
+> `@fraim get_fraim_workflow("user-survey-dispatch")`
+>
+> DO NOT EXECUTE.
+
+## Intent
+To systematically formulate, build, and dispatch user surveys across multiple platforms (LinkedIn, Reddit, X, Facebook) to validate target audience assumptions and gather product insights.

package/registry/stubs/workflows/customer-development/users-to-target.md

@@ -0,0 +1,11 @@
+# FRAIM Workflow: users-to-target
+
+> [!IMPORTANT]
+> This is a **FRAIM-managed workflow stub**. 
+> To load the full context (rules, templates, and execution steps), ask your AI agent to:
+> `@fraim get_fraim_workflow("users-to-target")`
+>
+> DO NOT EXECUTE.
+
+## Intent
+Help founders systematically identify and build an inventory of specific potential customers across multiple platforms for customer discovery and outreach.

package/registry/stubs/workflows/productivity-report/productivity-report.md

@@ -0,0 +1,11 @@
+# FRAIM Workflow: productivity-report
+
+> [!IMPORTANT]
+> This is a **FRAIM-managed workflow stub**. 
+> To load the full context (rules, templates, and execution steps), ask your AI agent to:
+> `@fraim get_fraim_workflow("productivity-report")`
+>
+> DO NOT EXECUTE.
+
+## Intent
+Generate comprehensive productivity reports showing development velocity, team collaboration patterns, and project health metrics through analysis of commits, PRs, issues, and comment activity.

package/bin/fraim.js

@@ -1,8 +0,0 @@
-#!/usr/bin/env node
-
-/**
- * FRAIM CLI Entry Point
- * This wrapper loads and executes the compiled CLI from dist/
- */
-
-require('../dist/src/cli/fraim.js');

package/dist/registry/ai-manager-rules/design-phases/design.md

@@ -1,108 +0,0 @@
-# Phase: Design
-
-## INTENT
-To create a comprehensive technical design that translates the feature specification into implementable architecture, APIs, and technical solutions.
-
-## OUTCOME
-A complete technical design document that:
-- Translates spec requirements into technical architecture
-- Defines APIs, data models, and system interactions
-- Identifies technical risks and mitigation strategies
-- Provides clear implementation guidance
-- Includes technical validation criteria
-
-## PRINCIPLES
-- **Spec-Driven**: Design directly addresses specification requirements
-- **Implementation-Ready**: Provides clear technical guidance
-- **Risk-Aware**: Identifies and mitigates technical risks
-- **Validation-Focused**: Includes technical validation criteria
-- **Template-Compliant**: Follows RFC template structure
-
-## WORKFLOW
-
-### Step 1: Load Template and Specification
-- Call `get_fraim_file({ path: "templates/specs/TECHSPEC-TEMPLATE.md" })` (for features)
-- Call `get_fraim_file({ path: "templates/specs/BUGSPEC-TEMPLATE.md" })` (for bugs)
-- Read the completed specification document from previous phase
-- Call `get_fraim_file({ path: "rules/spike-first-development.md" })`
-
-### Step 2: Analyze Specification Requirements
-- Extract all technical requirements from specification
-- Identify system components that need modification
-- Determine API changes or additions needed
-- Note any performance or scalability considerations
-- List integration points with existing systems
-
-### Step 3: Create Technical Design Document
-- Create RFC file at `docs/rfcs/{issue_number}-{kebab-case-title}.md`
-- Follow appropriate template structure (TECHSPEC or BUGSPEC)
-- Include all required sections:
-  - Problem statement (from spec)
-  - Technical requirements
-  - Proposed solution architecture
-  - API design and data models
-  - Implementation plan
-  - Testing strategy
-  - Risk assessment and mitigation
-  - Alternative approaches considered
-
-### Step 4: Design System Architecture
-- Define component interactions and data flow
-- Specify API endpoints and request/response formats
-- Design database schema changes (if needed)
-- Plan integration with existing systems
-- Consider scalability and performance implications
-
-### Step 5: Identify Technical Risks
-- List unfamiliar technologies or patterns
-- Note complex integrations or dependencies
-- Identify performance bottlenecks
-- Consider security implications
-- Plan risk mitigation strategies
-
-### Step 6: Apply Labels
-- Label the GitHub issue with `phase:design`
-- This will trigger automatic PR creation/update
-
-## VALIDATION
-
-### Phase Complete When:
-- ✅ Technical design document created using appropriate template
-- ✅ All specification requirements addressed technically
-- ✅ System architecture clearly defined
-- ✅ API design and data models specified
-- ✅ Technical risks identified and mitigation planned
-- ✅ Implementation plan provides clear guidance
-- ✅ Testing strategy defined
-- ✅ Issue labeled with `phase:design`
-
-### Phase Incomplete If:
-- ❌ Design document missing or incomplete
-- ❌ Template structure not followed
-- ❌ Specification requirements not addressed
-- ❌ Architecture unclear or missing
-- ❌ Technical risks not identified
-- ❌ Implementation guidance insufficient
-
-### Report Back:
-When you complete this phase, call:
-
-```javascript
-seekCoachingOnNextStep({
-  workflowType: "design",
-  issueNumber: "{issue_number}",
-  currentPhase: "design", 
-  status: "complete",
-  evidence: {
-    designDocument: "docs/rfcs/{issue_number}-{title}.md",
-    templateUsed: "TECHSPEC-TEMPLATE.md",
-    architectureComponents: ["API layer", "Database schema", "UI components"],
-    technicalRisks: ["Integration with legacy system", "Performance at scale"],
-    issueLabeled: "phase:design"
-  },
-  findings: {
-    keyDecisions: ["Use REST API", "PostgreSQL for data storage", "React components"],
-    riskMitigation: ["Spike legacy integration", "Load testing plan"]
-  }
-})
-```

package/dist/registry/ai-manager-rules/design-phases/finalize.md

@@ -1,60 +0,0 @@
-# Phase: Finalize
-
-## INTENT
-To prepare completed work for human review by setting proper labels, creating/updating PR, and documenting evidence.
-
-## OUTCOME
-Work is ready for human review with:
-- Proper issue labels applied
-- PR created/updated with work
-- Evidence documented
-- Clean handoff to next phase or review
-
-## WORKFLOW
-
-### Step 1: Apply Issue Labels
-- Remove current phase label (e.g., `phase:spec`, `phase:design`, `phase:impl`)
-- Add `status:needs-review` label
-- Keep any other relevant labels
-
-### Step 2: Create/Update Pull Request
-- Ensure PR exists for the feature branch
-- Update PR title to reflect completed work
-- Update PR description with summary of work completed
-- Link to relevant documents (specs, designs, evidence)
-
-### Step 3: Document Evidence
-- Create evidence file at `docs/evidence/{issue_number}-{workflow}-evidence.md`
-- Document key decisions made
-- List deliverables created
-- Note any recommendations for next phase
-
-### Step 4: Prepare Handoff
-- Ensure all work is committed to git
-- Verify documentation is complete
-- Confirm work is ready for human review
-
-## VALIDATION
-
-### Phase Complete When:
-- ✅ Issue labels updated (`status:needs-review`)
-- ✅ PR created/updated with work summary
-- ✅ Evidence documented
-- ✅ All work committed to git
-- ✅ Ready for human review
-
-### Report Back:
-```javascript
-seekCoachingOnNextStep({
-  workflowType: "{workflow_type}",
-  issueNumber: "{issue_number}",
-  currentPhase: "finalize", 
-  status: "complete",
-  evidence: {
-    labelsApplied: ["status:needs-review"],
-    prUpdated: true,
-    evidenceDocumented: "docs/evidence/{issue_number}-{workflow}-evidence.md",
-    workCommitted: true
-  }
-})
-```

package/dist/registry/ai-manager-rules/design-phases/validate.md

@@ -1,125 +0,0 @@
-# Phase: Validate (Design)
-
-## INTENT
-To systematically validate that the technical design is complete, addresses all specification requirements, and provides clear implementation guidance.
-
-## OUTCOME
-Confirmation that:
-- Design addresses all specification requirements
-- Technical architecture is sound and implementable
-- APIs and data models are well-defined
-- Technical risks are identified and mitigated
-- Implementation guidance is clear and actionable
-
-## PRINCIPLES
-- **Spec Alignment**: Design must address all specification requirements
-- **Technical Soundness**: Architecture must be feasible and scalable
-- **Implementation Ready**: Clear guidance for development phase
-- **Risk Awareness**: Technical risks identified and mitigated
-- **Quality Standards**: Professional-grade design ready for implementation
-
-## WORKFLOW
-
-### Step 1: Load Specification and Design
-- Read the original specification document
-- Read the completed design document
-- Call `get_fraim_workflow({ workflow: "review-implementation-vs-design-spec" })`
-
-### Step 2: Execute Design Validation Checklist
-
-**Specification Alignment:**
-1. **Requirements Coverage**: All spec requirements addressed in design
-2. **Customer Needs**: Design supports all customer desired outcomes
-3. **User Experience**: Technical design enables specified user workflows
-4. **Validation Plan**: Design supports spec validation criteria
-
-**Technical Soundness:**
-5. **Architecture Clarity**: System components and interactions clearly defined
-6. **API Design**: Endpoints, request/response formats well-specified
-7. **Data Models**: Database schema and data structures defined
-8. **Integration Points**: External system interactions documented
-9. **Scalability**: Performance and scaling considerations addressed
-
-**Implementation Readiness:**
-10. **Implementation Plan**: Clear step-by-step development guidance
-11. **Testing Strategy**: Comprehensive testing approach defined
-12. **Technical Risks**: Risks identified with mitigation strategies
-13. **Alternative Analysis**: Other approaches considered and rejected
-
-**Quality Standards:**
-14. **Template Compliance**: Follows TECHSPEC/BUGSPEC template structure
-15. **Professional Quality**: Clear writing, proper formatting, complete sections
-
-### Step 3: Risk Assessment Review
-- Verify all technical risks are realistic and significant
-- Confirm mitigation strategies are actionable
-- Check if any risks require spikes or prototypes
-- Assess overall project feasibility
-
-### Step 4: Implementation Guidance Review
-- Ensure implementation plan is detailed enough
-- Verify testing strategy covers all requirements
-- Check that guidance addresses potential challenges
-- Confirm design enables spec validation plan
-
-### Step 5: Generate Validation Report
-Document findings for each validation area:
-- Specification alignment assessment
-- Technical soundness evaluation
-- Implementation readiness review
-- Quality standards compliance
-- Overall recommendation
-
-## VALIDATION
-
-### Phase Complete When:
-- ✅ All specification requirements addressed in design
-- ✅ Technical architecture is sound and implementable
-- ✅ APIs and data models clearly defined
-- ✅ Technical risks identified with mitigation plans
-- ✅ Implementation guidance is clear and actionable
-- ✅ Quality standards met consistently
-- ✅ Validation report generated with evidence
-
-### Phase Incomplete If:
-- ❌ Specification requirements not fully addressed
-- ❌ Technical architecture unclear or infeasible
-- ❌ API design incomplete or poorly defined
-- ❌ Technical risks not identified or mitigated
-- ❌ Implementation guidance insufficient
-- ❌ Quality issues identified
-
-### Report Back:
-When you complete this phase, call:
-
-```javascript
-seekCoachingOnNextStep({
-  workflowType: "design",
-  issueNumber: "{issue_number}",
-  currentPhase: "validate", 
-  status: "complete",
-  evidence: {
-    validationReport: "All specification requirements addressed, architecture sound",
-    specAlignmentScore: "100% - all requirements covered",
-    technicalSoundness: "PASS - architecture feasible and scalable",
-    implementationReadiness: "PASS - clear guidance provided",
-    qualityAssessment: "Professional grade, ready for implementation",
-    validationDecision: "PASS"
-  }
-})
-```
-
-If validation fails:
-```javascript
-seekCoachingOnNextStep({
-  workflowType: "design",
-  issueNumber: "{issue_number}",
-  currentPhase: "validate", 
-  status: "incomplete",
-  findings: {
-    failedAreas: ["API design incomplete", "Technical risks not mitigated"],
-    validationDecision: "FAIL",
-    nextAction: "Return to design phase to address validation failures"
-  }
-})
-```

package/dist/registry/ai-manager-rules/design.json

@@ -1,97 +0,0 @@
-{
-  "workflowType": "design",
-  "description": "Design phase validation ensures that technical designs are complete, follow RFC format, and provide clear implementation guidance.",
-  "validationRules": [
-    {
-      "step": 1,
-      "description": "Verify issue is labeled with phase:design",
-      "passCriteria": "Issue has 'phase:design' label applied",
-      "weight": "blocking",
-      "category": "process"
-    },
-    {
-      "step": 2,
-      "description": "Verify RFC document exists in correct location",
-      "command": "find \"docs/rfcs\" -name \"*{issue_number}*\" -type f",
-      "passCriteria": "RFC document exists at docs/rfcs/{issue_number}-{kebab-title}.md with substantial content (>1500 characters)",
-      "weight": "blocking",
-      "category": "completeness"
-    },
-    {
-      "step": 3,
-      "description": "Check RFC follows technical design template structure",
-      "passCriteria": "RFC includes all required sections: Problem Statement, Solution Overview, Technical Design, Implementation Plan, Testing Strategy, Risks and Mitigations",
-      "weight": "blocking",
-      "category": "structure"
-    },
-    {
-      "step": 4,
-      "description": "Validate Problem Statement is clear",
-      "passCriteria": "Problem Statement clearly defines the technical challenge and why it needs to be solved",
-      "weight": "blocking",
-      "category": "problem-definition"
-    },
-    {
-      "step": 5,
-      "description": "Validate Solution Overview provides clear direction",
-      "passCriteria": "Solution Overview describes the high-level approach and key architectural decisions",
-      "weight": "blocking",
-      "category": "solution-design"
-    },
-    {
-      "step": 6,
-      "description": "Check Technical Design has sufficient detail",
-      "passCriteria": "Technical Design includes API contracts, data models, component interactions, and implementation details",
-      "weight": "blocking",
-      "category": "technical-detail"
-    },
-    {
-      "step": 7,
-      "description": "Validate Implementation Plan is actionable",
-      "passCriteria": "Implementation Plan breaks down work into clear, executable steps with dependencies identified",
-      "weight": "blocking",
-      "category": "implementation-planning"
-    },
-    {
-      "step": 8,
-      "description": "Check Testing Strategy is comprehensive",
-      "passCriteria": "Testing Strategy covers unit tests, integration tests, and validation scenarios",
-      "weight": "blocking",
-      "category": "testing"
-    },
-    {
-      "step": 9,
-      "description": "Verify Risks and Mitigations are identified",
-      "passCriteria": "Risks and Mitigations section identifies potential issues and mitigation strategies",
-      "weight": "warning",
-      "category": "risk-management"
-    },
-    {
-      "step": 10,
-      "description": "Check all requirements from spec are addressed",
-      "passCriteria": "All requirements from the specification document are covered in the technical design",
-      "weight": "blocking",
-      "category": "completeness"
-    }
-  ],
-  "gradingCriteria": {
-    "passRequirements": [
-      "ALL blocking validation steps must pass",
-      "At least 80% of warning validation steps should pass",
-      "Design demonstrates clear technical understanding",
-      "Implementation plan is realistic and actionable",
-      "No placeholder text or incomplete sections remain"
-    ],
-    "failRequirements": [
-      "ANY blocking validation step fails",
-      "Multiple warning validation steps fail indicating quality issues",
-      "Design appears incomplete or lacks technical depth",
-      "Requirements not properly addressed",
-      "Template structure not followed"
-    ]
-  },
-  "reportingFormat": {
-    "requiredFields": ["pass", "reasons"],
-    "instructions": "Evaluate each validation step honestly. If ANY blocking step fails, you must report pass=false. Provide specific reasons for failure in the reasons array. Focus on technical completeness and implementation clarity."
-  }
-}