fraim-framework 2.0.36 → 2.0.38

package/registry/templates/evidence/Implementation-FeatureEvidence.md

@@ -1,121 +0,0 @@
-# Feature: <Title>
-Issue: #<issue>  
-Tech Spec: <Link to tech spec>
-PR: <Link to PR>
-
-## Completeness Evidence
- - All phases of tech spec complete: Yes/No 
- - Issue tagged with label `phase:impl`: Yes/No
- - Issue tagged with label `status:needs-review`: Yes/No
- - All files committed/synced to branch: Yes/No
- - Table with following columns 
-   - PR Comment
-   - How Addressed
-
-## Implementation Quality Checkpoints
- - [ ] Code complexity reviewed (no overengineering)
- - [ ] No resource waste (excessive retries, delays, workarounds)
- - [ ] Solution based on proven prototype from design phase
- - [ ] All new files/functions are actually used
-
-## Validation Evidence
- - Complete validation performed as suggested in tech spec: Yes/No
- - **IMPORTANT**: Post full test output (not just "tests passing ✅")
- - Table with following columns
-    - Validation Step (manual vs automated)
-    - Validation Result (pass vs fail)
-    - Failure Analysis (if fail)
-
-### Example: Full Test Output
-```
-🚀 Starting Calendar-Goal Analysis API Tests
-
-Running 3 tests
-✔ Edge case - no goals defined (67.8ms)
-✔ Multi-tenancy data isolation (205.9ms)
-✔ Full analysis flow (passed)
-
-❌ Total Failed Tests: 0
-```
-
-### Example: Database Objects (if applicable)
-```javascript
-{
-  _id: ObjectId("68e81da2a87a1a0f91589023"),
-  executive_id: "demo-exec-001",
-  title: "Increase Enterprise Sales by 30%",
-  timeframe: "QUARTERLY",
-  priority: 9,
-  status: "IN_PROGRESS"
-}
-```
-
-### Example: API Request/Response (if applicable)
-**Request:**
-```http
-GET /executive-goals/calendar-analysis?timeframe=backward&period=7
-Headers:
-  x-executive-id: demo-exec-001
-```
-
-**Response (200 OK):**
-```json
-{
-  "success": true,
-  "analysis": {
-    "executive_id": "demo-exec-001",
-    "total_calendar_hours": 7.5,
-    "goal_breakdown": [
-      {
-        "goal_id": "68e81da2a87a1a0f91589025",
-        "goal_title": "Launch AI Product Line",
-        "total_hours": 2.5,
-        "percentage": 33.3,
-        "meeting_ids": ["event-002", "event-007"]
-      }
-    ]
-  }
-}
-```
-
-## New Files/Functions Created
- - Table with the following columns
-    - File/Function Name
-    - Purpose
-    - Who is using/importing/calling it
-    - Is it actually used? (Yes/No - if No, explain why it exists)
-
-## New Tests Added
- - Added all tests suggested in tech spec: Yes/No
- - Table with the following columns
-    - Test Case Name
-    - What is test case validating
-    - Test Result (pass vs fail)
-    - Failure Analysis (if fail)
-
-## Existing Test Suites Run
- - Table with following columns
-    - Test Suite
-    - Was it Run (if not, why not - it's ok to not run a suite if there is no impact of your work to it as covered in agent-testing-guidelines.md)
-    - Failing Tests
-    - Failure Analysis (if any tests fail)
-
-   
-## Pre-Completion Reflection
-
-[Include reflection analysis here following `get_fraim_file({ path: "rules/mandatory-pre-completion-reflection.md" })`]
-
-✅ Reflection Phase 1 (Claim Verification) completed: YES/NO
-✅ Reflection Phase 2 (Risk Analysis) completed: YES/NO
-✅ Reflection Phase 3 (Validation Plan Check) completed: YES/NO
-✅ Reflection Phase 4 (Self-Audit) completed: YES/NO
-✅ All blockers from reflection addressed: YES/NO
-✅ Confidence level: X% (must be ≥ 90% to proceed)
-
-**Reflection Summary:**
-[Brief summary of key findings from reflection]
-
-## Continous Learning
- - Table with following columns
-    - Learning
-    - Agent Rule Updates (what agent rule file was updated to ensure the learning is durable)

package/registry/templates/evidence/Spec-Evidence.md

@@ -1,19 +0,0 @@
-# Feature Specification: <Title>
-Issue: #<issue>  
-PR: <Link to PR>
-
-## Completeness Evidence
- - Issue tagged with label `phase:spec`: Yes/No
- - Issue tagged with label `status:needs-review`: Yes/No
- - All specification documents committed/synced to branch: Yes/No
- - Table with following columns 
-   - Customer Research Area
-   - Sources of Information
- - Table with following columns 
-   - PR Comment
-   - How Addressed
-
-## Continuous Learning
- - Table with following columns
-    - Learning
-    - Agent Rule Updates (what agent rule file was updated to ensure the learning is durable)

package/registry/templates/help/HelpNeeded.md

@@ -1,14 +0,0 @@
-# Feature: <Title>
-Issue: #<issue>  
-PR: <Link to PR>
-
-## Help Needed
- - What help is needed? Be as specific as possible
- - What is it blocking?
- - What is the impact?
-
-## What has been tried
- - What solutions have been tried to unblock? What was the result?
-
-## What Options exist
- - Do you have options in mind? If so, what are the Pros/Cons and what is your suggestion?

package/registry/templates/marketing/HBR-ARTICLE-TEMPLATE.md

@@ -1,66 +0,0 @@
-# Template: HBR Article
-
-Use this template to capture the key checkpoints for every Harvard Business Review (or similar) thought leadership submission so any product team can execute the workflow without re-reading the original issue.
-
-## 1. Story Fit & Intent
-- **Working Title**:  
-- **Thesis/Angle**: Why this matters to HBR readers and how it advances the product strategy.  
-- **Target Section**: (Strategy / Leadership / Technology / etc.)  
-- **Why Now**: Timeliness, data trend, or customer insight.  
-- **Assigned Reviewers**: Marketing lead, product lead, exec reviewer.
-- **Central Message**:  
-- **Importance / Usefulness / Counterintuitive Angle**:  
-- **New Contribution**:  
-- **Why Leaders Must Know & How to Apply Today**:
-- **Source of Authority** (previous work, credentials, experience):
-
-## 2. HBR Guideline Checklist
-- [ ] Exclusive submission (no simultaneous submissions).  
-- [ ] Word count within HBR limits (note specific count).  
-- [ ] Proper byline and contributor list.  
-- [ ] Conflicts of interest disclosed (partners, competitors, etc.).  
-- [ ] Tone matches HBR's voice (professional, evidence-based).  
-- [ ] All supporting data, quotes, and frameworks cite originals.
-
-## 3. Research & References
-- **Customer Evidence**: List customer stories, interviews, or experiments.  
-- **Metrics/Data**: Include telemetry or KPIs.  
-- **Internal Experiments**: Describe what was learned.  
-- **External Sources**: Link to relevant HBR articles or academic references.  
-- **Attachments Needed**: Charts, tables, framework diagrams.
-- **Research & Examples That Back the Idea**:
-- **Academic / Professional / Personal Experience to Draw On**:
-
-## 4. Outline Structure
-- Hook + symptom/problem framing.  
-- Diagnostic + evidence blocks.  
-- Recommendations/practical steps for leaders.  
-- Closing call to action aligning to the product roadmap.  
-- Note attachments/reference for each section.
-
-## 5. Draft & Versions
-- **Draft Link/Location**:  
-- **Word Count**:  
-- **Key edits/versions**: (Version 1, 2, etc.)  
-- **Peer Review Notes**:  
-- **Exec Review Notes**:  
-- **Headline Variants**:
-
-## 6. Submission Plan
-- **Email Synopsis**: Subject line + elevator pitch.  
-- **Attachments**: Outline, draft, data, disclosure matrix.  
-- **Target Submission Window**: Date/time.  
-- **Submission Log**: Who submitted, when, portal used.  
-- **Follow-up Plan**: Reminder to track publication status and audience engagement.
-
-## 7. Launch Collateral
-- **Blog Post**: Angle, owner, status.  
-- **Newsletter Mention**: Message, owner.  
-- **Exec Update**: Key points.  
-- **Social/LinkedIn**: Thread plan, owner.  
-- **Measurement**: Metrics to track (clicks, reads, references).
-
-## 8. Post-Publication Notes
-- Feedback from reviewers or editors.  
-- Audience reactions.  
-- Learnings for the next HBR submission.

package/registry/templates/replicate/implementation-checklist.md

@@ -1,39 +0,0 @@
-# Implementation Checklist
-
-**Application**: [Application Name]  
-**Date**: [Date]
-
-## Feature Implementation Status
-
-### Authentication & Account Management
-
-- [ ] **UC-001: User Registration**
-  - [ ] Database model: User
-  - [ ] API endpoint: POST /api/users/signup
-  - [ ] Frontend: SignUpPage component
-  - [ ] Integration: Connect frontend to API
-  - [ ] Tests: Server, client, E2E
-  - [ ] Validation: Test in browser
-
-- [ ] **UC-002: User Login**
-  - [ ] API endpoint: POST /api/users/login
-  - [ ] Frontend: LoginPage component
-  - [ ] Auth context: Session management
-  - [ ] Integration: Connect frontend to API
-  - [ ] Tests: Server, client, E2E
-  - [ ] Validation: Test in browser
-
-[Continue with more features...]
-
-## Implementation Progress
-
-**Overall Progress**: [X]% Complete
-
-- **Not Started**: [Number] features
-- **In Progress**: [Number] features
-- **Complete**: [Number] features
-- **Blocked**: [Number] features
-
-## Notes
-
-- [Add implementation notes, decisions, blockers, etc.]

package/registry/templates/replicate/use-cases-template.md

@@ -1,88 +0,0 @@
-# Use Cases Documentation
-
-**Application**: [Application Name]  
-**Date**: [Date]  
-**Version**: [Version]
-
-## Overview
-
-This document contains all identified use cases for the application, organized by category.
-
-## Use Case Categories
-
-- [Authentication & Account Management](#authentication--account-management)
-- [Content Discovery & Browsing](#content-discovery--browsing)
-- [Content Creation & Management](#content-creation--management)
-- [Data Collection & Reporting](#data-collection--reporting)
-- [Administration & Configuration](#administration--configuration)
-- [Communication & Collaboration](#communication--collaboration)
-
----
-
-## Authentication & Account Management
-
-### UC-001: User Registration
-
-**Actor**: Guest User  
-**Preconditions**: User is not logged in  
-**Priority**: High
-
-**Steps**:
-1. Navigate to sign up page
-2. Fill in registration form (name, email, password)
-3. Submit form
-4. Receive confirmation message
-5. Verify email (if required)
-6. Redirect to login or dashboard
-
-**Postconditions**: 
-- User account is created
-- User can log in
-- User profile is initialized
-
-**Screenshots**: `screenshots/signup_*.png`
-
-**Related Use Cases**: UC-002
-
----
-
-### UC-002: User Login
-
-**Actor**: Registered User  
-**Preconditions**: User has an account  
-**Priority**: High
-
-**Steps**:
-1. Navigate to login page
-2. Enter email and password
-3. Click "Login" button
-4. System validates credentials
-5. User is redirected to dashboard/home
-
-**Postconditions**:
-- User session is created
-- User is authenticated
-- User can access protected pages
-
-**Screenshots**: `screenshots/login_*.png`
-
-**Related Use Cases**: UC-001, UC-003
-
----
-
-[Continue with more use cases...]
-
-## Use Case Index
-
-| ID | Name | Actor | Priority | Status |
-|----|------|-------|----------|--------|
-| UC-001 | User Registration | Guest | High | ✅ Complete |
-| UC-002 | User Login | User | High | ✅ Complete |
-| ... | ... | ... | ... | ... |
-
-## Implementation Status
-
-- **Total Use Cases**: [Number]
-- **Implemented**: [Number]
-- **In Progress**: [Number]
-- **Not Started**: [Number]

package/registry/templates/retrospective/RETROSPECTIVE-TEMPLATE.md

@@ -1,55 +0,0 @@
-# Postmortem: {Issue Title} - Issue #{issue-number}
-
-**Date**: {current_date}  
-**Duration**: {time_spent}  
-**Objective**: {issue_description}  
-**Outcome**: {success/failure/partial}
-
-## Executive Summary
-
-{2-3 sentence summary of what happened and the outcome}
-
-## Timeline of Events
-
-### Phase 1: {Phase Name}
-- ✅/❌ **Action**: Description
-- ✅/❌ **Action**: Description
-
-### Phase 2: {Phase Name}
-- ✅/❌ **Action**: Description
-- ✅/❌ **Action**: Description
-
-## Root Cause Analysis
-
-### 1. **Primary Cause**
-**Problem**: {main issue}
-**Impact**: {what this caused}
-
-### 2. **Contributing Factors**
-**Problem**: {secondary issues}
-**Impact**: {what these caused}
-
-## What Went Wrong
-
-1. **Issue 1**: Description
-2. **Issue 2**: Description
-
-## What Went Right
-
-1. **Success 1**: Description
-2. **Success 2**: Description
-
-## Lessons Learned
-
-1. **Learning 1**: Description
-2. **Learning 2**: Description
-
-## Agent Rule Updates Made to avoid recurrence
-
-1. **Rule 1**: Description
-2. **Rule 2**: Description
-
-## Enforcement Updates Made to avoid recurrence
-
-1. **Improvement 1**: Description
-2. **Improvement 2**: Description

package/registry/templates/specs/BUGSPEC-TEMPLATE.md

@@ -1,37 +0,0 @@
-# Bug: <Title>
-
-Issue: #<issue>  
-Owner: <agent>
-
-## Customer 
-
-## Customer Problem being solved
-
-## Repro Steps
-- Specific steps in the user workflow that reproduce the bug (eg start in dashboard, click on tab x, see list y, approve item z ....)
-- Confirm that you have reproduced the bug
-
-## Root Cause
-- What root cause was identified after repro and code analysis
-
-## Fix Details
-- UI, API, Service, DB changes: Which files will be modified and for what?
- 
-## Validation Plan
-- Table with following columns
-  - User Scenario
-  - Expected outcome
-  - Validation method (UI validation, API validation, Database validation ...)
-
-## Confidence Level
-- On a scale of 0 to 100, how confident are you that your fix will work?
-
-## Test Matrix
-- Unit(as many as needed, mocking ok): what core functionality will be tested. What test suite will be added? Which existing test suites will be modified?
-- Integration(only mock external services): what tests will ensure the full stack integration does not regress. What test suite will be added? Which existing test suites will be modified?
-- E2E(1 at most, no mocking): If any changes are made to external integrations, what end to end tests will ensure external integrations work as expected.
-
-## Future Prevention
- - What will prevent future introduction of similar bugs
- - What agent rules will you update to ensure similar bugs do not recur
- - What enforcement will you create to ensure similar bugs are caught before they are checked in

package/registry/templates/specs/FEATURESPEC-TEMPLATE.md

@@ -1,29 +0,0 @@
-# Feature: <Title>
-
-Issue: #<issue>  
-Owner: <agent>
-
-## Customer 
-
-## Customer's Desired Outcome
-
-## Customer Problem being solved
-
-## User Experience that will solve the problem
-- Specific steps in the user workflow (eg start in dashboard, click on tab x, see list y, approve item z ....)
-- UI mocks showing the desired experience. Put these in the `docs/feature specs/mocks` folder and link to them here.
-
-## Validation Plan
-- How will you know the feature is working as intended (validate via browser, api, ...)
-- What steps will you follow to ensure the feature works
-
-## Alternatives
-- Table with following columns
-  - Alternative: What other way could the customer solve their problem?
-  - Why discard?: Why is this alternative not chosen?
-
-## Competitive Landscape
-- Table with the following
-  - Competitor 
-  - How they are solving the same problem
-  - What do customers say about this solution

package/registry/templates/specs/TECHSPEC-TEMPLATE.md

@@ -1,39 +0,0 @@
-# Feature: <Title>
-
-Issue: #<issue>  
-Owner: <agent>
-
-## Customer 
-
-## Customer Problem being solved
-
-## User Experience that will solve the problem
-- Specific steps in the user workflow 
-  - If UI feature: start on UI page a, click on tab x, see list y, approve item z, achieve outcome ....
-  - If API feature: call API a with params x, y, z, receive result
-  - If refactoring/rearchitecture: what is the simpler developer workflow 
-
-## Technical Details
-- UI changes: Which files will be modified and for what?
-- API surface (OpenAPI) changes
-- Data model / schema changes
-- Failure modes & timeouts
-- Telemetry & analytics
-
-## Confidence Level
-- On a scale of 0 to 100, how confident are you that your solution will work?
-
-## Validation Plan
-- Table with following columns
-  - User Scenario
-  - Expected outcome
-  - Validation method (UI validation, API validation, Database validation ...)
-
-## Test Matrix
-- Unit(as many as needed, mocking ok): what core functionality will be tested. What test suite will be added? Which existing test suites will be modified?
-- Integration(only mock external services): what tests will ensure the full stack integration does not regress. What test suite will be added? Which existing test suites will be modified?
-- E2E(1 at most, no mocking): If any changes are made to external integrations, what end to end tests will ensure external integrations work as expected.
-
-## Risks & Mitigations
-
-## Observability (logs, metrics, alerts)

package/registry/workflows/bootstrap/create-architecture.md

@@ -1,38 +0,0 @@
-# FRAIM Workflow: create-architecture
-
-## Intent
-To analyze the codebase and author a comprehensive `docs/architecture/architecture.md` document using the standard template. This document captures the system's design, tech stack, and architectural layers to serve as a map for development.
-
-## Execution Steps
-
-1. **Analyze Project Structure**
-   - Use `list_dir` to explore the root directory and key subdirectories (src, docs, etc.).
-   - Use `view_file` on key configuration files (package.json, tsconfig.json, etc.).
-   - Identify main entry points and architectural patterns.
-
-2. **Author Architecture Document**
-   - Locate the template: `get_fraim_file({ path: "templates/bootstrap/ARCHITECTURE-TEMPLATE.md" })`
-   - Analyze your findings from Step 1.
-   - Create a new file at `docs/architecture/architecture.md`.
-   - Use your intelligence to synthesize the findings into the template:
-     - **Tech Stack**: Detail specific languages, runtimes, and frameworks used.
-     - **Architectural Layers**: Define the system's layers (Presentation, Logic, Data, etc.).
-     - **Key Components**: Map out the core modules and their relationships.
-     - **Data Flow**: Explain the lifecycle of a typical request or action.
-
-3. **Update FRAIM Configuration**
-   - Read the project configuration file at `.fraim/config.json`.
-   - Update it to include a reference to the architecture document:
-     ```json
-     {
-       ...
-       "customizations": {
-         "architectureDoc": "docs/architecture/architecture.md",
-         ...
-       }
-     }
-     ```
-
-4. **Verify**
-   - Check that `docs/architecture/architecture.md` exists and is populated.
-   - Check that `.fraim/config.json` contains the `architectureDoc` field pointing to the correct path.

package/registry/workflows/bootstrap/evaluate-code-quality.md

@@ -1,36 +0,0 @@
-# FRAIM Workflow: evaluate-code-quality
-
-## Intent
-To perform a deep analysis of the codebase's quality, evaluating it against FRAIM's standards and generating a comprehensive health report.
-
-## Execution Steps
-
-1. **Environment Check**
-   - Ensure `npm install` and `npm run build` have been attempted.
-   - Verify that `.fraim` directory (or equivalent config) is present.
-
-2. **Run Quality Analysis**
-    - Execute the self-contained quality analysis script:
-    ```bash
-    # Execute evaluate-code-quality script directly from synced location
-    npx tsx ~/.fraim/scripts/evaluate-code-quality.ts
-    
-    # On Windows:
-    # npx tsx %USERPROFILE%\.fraim\scripts\evaluate-code-quality.ts
-    ```
-
-3. **Author Report**
-    - Read the terminal output from Step 2.
-    - Locate the template: `get_fraim_file({ path: "templates/bootstrap/CODE-QUALITY-REPORT-TEMPLATE.md" })`
-    - Create a new file at `docs/bootstrap/code-quality-report.md`.
-    - Use your intelligence to synthesize the findings into the template:
-        - Assign a fair grade (A-F) based on build success and diagnostic results.
-        - Detail specific quality risks found in Gate 1-11.
-        - Propose actionable remediation steps.
-
-4. **Review Findings**
-   - Summarize the top 3 quality risks to the user.
-   - Propose a remediation plan if the grade is below 'B'.
-
-5. **Update Status**
-   - Label any relevant issues with `quality:evaluated`.

package/registry/workflows/bootstrap/verify-test-coverage.md

@@ -1,37 +0,0 @@
-# FRAIM Workflow: verify-test-coverage
-
-## Intent
-To verify the depth and effectiveness of the test suite by comparing actual test execution against the validation plans defined in specifications.
-
-## Execution Steps
-
-1. **Run Tests with Coverage**
-   - Execute the project's test suite with coverage enabled (e.g., `npm test -- --coverage`).
-   - Ensure coverage reports (LCOV or JSON) are generated.
-
-2. **Map Validation Plans**
-   - Identify all RFCs and Spec documents in `docs/`.
-   - Extract "Validation Plan" tables from these documents.
-
-3. **Analyze Coverage Gaps**
-    - Execute the self-contained test coverage verification script:
-    ```bash
-    # Execute verify-test-coverage script directly from synced location
-    npx tsx ~/.fraim/scripts/verify-test-coverage.ts
-    
-    # On Windows:
-    # npx tsx %USERPROFILE%\.fraim\scripts\verify-test-coverage.ts
-    ```
-
-4. **Author Report**
-    - Read the terminal output from Step 3.
-    - Locate the template: `get_fraim_file({ path: "templates/bootstrap/TEST-COVERAGE-REPORT-TEMPLATE.md" })`
-    - Create a new file at `docs/bootstrap/test-coverage-report.md`.
-    - Use your intelligence to synthesize the findings into the template:
-        - Highlight mission-critical scenarios that lack automated test evidence.
-        - Discuss line coverage trends.
-        - Recommend specific test cases to bridge coverage gaps.
-
-5. **Review Findings**
-   - Alert the user if critical validation scenarios are uncovered.
-   - Suggest specific tests to improve coverage score.