fraim-framework 2.0.55 → 2.0.57

package/dist/registry/ai-manager-rules/shared-phases/address-pr-feedback.md

@@ -1,188 +0,0 @@
-# Phase: address-pr-feedback
-
-## INTENT
-To systematically address all PR feedback items by making targeted changes, replying to comments, and preparing for re-validation.
-
-## OUTCOME
-All PR feedback addressed with:
-- Targeted changes made for each feedback item
-- Feedback file updated with resolutions
-- PR comments replied to with explanations
-- Changes validated and ready for re-review
-
-## RULES FOR THIS PHASE
-
-### Success Criteria
-Read `registry/rules/agent-success-criteria.md` via `get_fraim_file` for the complete framework. Focus especially on:
-- **Integrity** (document all changes made)
-- **Correctness** (address feedback accurately)
-- **Completeness** (address every UNADDRESSED item)
-
-### Simplicity Principles
-Read `registry/rules/simplicity.md` via `get_fraim_file` for complete guidelines. Critical for feedback phase:
-- **Targeted Changes**: Make minimal changes to address specific feedback
-- **Manual Validation**: Test changes manually before updating PR
-- **Clear Communication**: Reply to each comment with clear explanations
-
-## PRINCIPLES
-- **Feedback-Driven**: Address only the specific issues raised in PR comments
-- **Minimal Changes**: Avoid scope creep or unnecessary refactoring
-- **Clear Communication**: Explain resolutions clearly to reviewers
-- **Validation**: Ensure changes work before updating PR
-
-## 📋 WORKFLOW
-
-### Step 1: Read PR Feedback File
-
-**MANDATORY**: Read the feedback file created by `wait-for-pr-review`:
-- File location: `docs/evidence/{issue_number}-{workflow_type}-feedback.md`
-- Identify all UNADDRESSED feedback items
-- Understand the context and requirements for each item
-
-### Step 2: Address Each Feedback Item
-
-**For each UNADDRESSED item:**
-
-1. **Understand the Feedback**:
-   - Read the comment carefully
-   - Identify what specific change is requested
-   - Determine the scope of the change needed
-
-2. **Make Targeted Changes**:
-   - Make minimal, focused changes to address the specific feedback
-   - Avoid unrelated changes or improvements
-   - Keep changes as small as possible while fully addressing the feedback
-
-3. **Update Feedback File**:
-   - Change status from UNADDRESSED to ADDRESSED
-   - Document your resolution approach
-   - Include details of what you changed
-
-**Feedback File Update Format**:
-```markdown
-### Comment X - ADDRESSED
-- **Author**: reviewer_name
-- **Type**: pr_comment|review_comment|review
-- **File**: file_path (if applicable)
-- **Line**: line_number (if applicable)
-- **Comment**: Original feedback text
-- **Status**: ADDRESSED
-- **Resolution**: Detailed explanation of how you addressed this feedback
-- **Changes Made**: Specific files/lines modified
-```
-
-### Step 3: Validate Changes
-
-**Test your changes:**
-- Run compilation check: `npx tsc --noEmit --skipLibCheck`
-- Run relevant tests to ensure no regressions
-- Test manually if the feedback involves UI/API behavior
-- Verify the specific issue mentioned in feedback is resolved
-
-### Step 4: Reply to PR Comments
-
-**For each addressed comment:**
-- Reply to the original PR comment
-- Explain what you changed and how it addresses their concern
-- Reference specific files/lines if helpful
-- Be clear and professional in your communication
-
-**Example reply format**:
-```
-✅ **Addressed**: [Brief description of what you changed]
-
-**Changes made**:
-- [Specific change 1]
-- [Specific change 2]
-
-**Files modified**: `path/to/file.ts`, `path/to/test.ts`
-
-This should resolve the [specific issue mentioned]. Please let me know if you need any clarification!
-```
-
-### Step 5: Commit and Push Changes
-
-**Commit your changes:**
-- Use clear commit messages that reference the feedback
-- Example: `Address PR feedback: Fix error handling in auth service`
-- Push changes to the PR branch
-
-## 📸 EVIDENCE REQUIREMENTS
-
-You MUST provide concrete evidence for all claims:
-
-1. **All Feedback Addressed**: Every UNADDRESSED item in feedback file is now ADDRESSED
-2. **Changes Made**: Specific code changes made for each feedback item
-3. **Validation Complete**: Tests pass and changes work as expected
-4. **PR Updated**: Changes committed, pushed, and comments replied to
-
-## VALIDATION
-
-### Phase Complete When:
-- ✅ All UNADDRESSED items in feedback file are now ADDRESSED
-- ✅ Feedback file updated with resolution details for each item
-- ✅ Targeted changes made to address each specific feedback
-- ✅ Changes validated (compilation, tests, manual testing)
-- ✅ PR comments replied to with clear explanations
-- ✅ Changes committed and pushed to PR branch
-
-### Phase Incomplete If:
-- ❌ Any UNADDRESSED items remain in feedback file
-- ❌ Changes don't actually address the feedback given
-- ❌ Tests failing after changes
-- ❌ Compilation errors introduced
-- ❌ PR comments not replied to
-- ❌ Changes not committed/pushed
-
-### Report Back:
-When you complete this phase, call:
-
-```javascript
-seekCoachingOnNextStep({
-  workflowType: "{workflow_type}",
-  issueNumber: "{issue_number}",
-  currentPhase: "address-pr-feedback",
-  status: "complete",
-  findings: {
-    feedbackItemsAddressed: {total_items_addressed},
-    changesValidated: true
-  },
-  evidence: {
-    feedbackFileUpdated: "All UNADDRESSED items now ADDRESSED with resolutions",
-    changesMade: "Brief summary of changes made",
-    validationResults: "Compilation and tests pass",
-    prCommentsReplied: "Replied to all PR comments with explanations"
-  }
-})
-```
-
-If feedback addressing incomplete, iterate:
-```javascript
-seekCoachingOnNextStep({
-  workflowType: "{workflow_type}",
-  issueNumber: "{issue_number}",
-  currentPhase: "address-pr-feedback",
-  status: "incomplete",
-  findings: {
-    uncertainties: ["Issues encountered", "What needs to be fixed"]
-  }
-})
-```
-
-## SCRIPTS
-
-**Compile TypeScript:**
-```bash
-npx tsc --noEmit --skipLibCheck
-```
-
-**Run tests:**
-```bash
-npm test
-```
-
-**Check git status:**
-```bash
-git status
-git diff
-```

package/dist/registry/ai-manager-rules/shared-phases/submit-pr.md

@@ -1,202 +0,0 @@
-# Phase: submit-pr
-
-## INTENT
-To submit completed work for review by creating/updating PR, setting proper labels, and documenting evidence.
-
-## OUTCOME
-Work is submitted for review with:
-- PR created/updated with work
-- Proper issue labels applied
-- Evidence documented
-- Ready to enter PR review phase
-
-## PRINCIPLES
-- **Complete Documentation**: Evidence shows all work done
-- **Proper Labels**: Issue status reflects PR submission
-- **Clear Communication**: PR and evidence are clear
-- **Ready for Review**: No blockers for PR review process
-
-## RULES FOR THIS PHASE
-
-### Success Criteria
-Read `registry/rules/agent-success-criteria.md` via `get_fraim_file` for the complete framework. Focus on:
-- **Integrity** (honest documentation of all work completed)
-- **Completeness** (all finalization steps completed)
-
-### Simplicity Principles
-Read `registry/rules/simplicity.md` via `get_fraim_file` for complete guidelines. Key for finalization:
-- **Focus on the assigned issue only** - document only relevant work
-- **Clear communication** - evidence should be easy to understand
-
-### Git Operations (if needed)
-When using git commands directly (if MCP tools unavailable), read `rules/git-safe-commands.md` via `get_fraim_file` to avoid interactive commands that hang agents.
-
-## WORKFLOW
-
-### Step 1: Create Evidence Document
-
-**File location:**
-```
-docs/evidence/{issue_number}-{workflow_type}-evidence.md
-```
-
-**Evidence document should include:**
-
-#### Summary
-- Issue number and title
-- Workflow type (spec, design, implement, test)
-- Brief description of work completed
-
-#### Work Completed
-**For Spec Workflow:**
-- Specification document created
-- High-fidelity HTML mocks (if UI changes)
-- Requirements coverage
-
-**For Design Workflow:**
-- Technical design document
-- Architecture decisions
-- API specifications
-- Database schema (if applicable)
-
-**For Implement Workflow:**
-- Implementation details
-- Key files changed
-- Approach taken
-- Testing completed
-
-**For Test Workflow:**
-- Test suite created/enhanced
-- Coverage metrics
-- Test results
-
-#### PR Feedback History (if applicable)
-**CRITICAL**: If PR feedback file exists (`docs/evidence/{issue_number}-{workflow_type}-feedback.md`), include its complete contents in the evidence document under this section.
-
-This shows reviewers:
-- All previous feedback received
-- How each item was addressed
-- Complete audit trail of review iterations
-
-#### Validation
-- How work was validated
-- Validation results
-- Screenshots/output (if applicable)
-
-#### Quality Checks
-- All deliverables complete
-- Documentation clear and professional
-- Work ready for next phase or review
-
-#### Phase Completion
-- All phases completed for this workflow
-- Evidence from each phase
-- Any iterations or challenges
-
-### Step 2: Commit and Sync Work
-
-**Commit all changes:**
-- Stage all modified files
-- Create commit with descriptive message
-- Push to feature branch
-
-**Commit message format:**
-```
-{workflow_type}({issue_number}): complete {phase_name} phase
-
-- Evidence document created
-- All deliverables complete
-- Ready for review
-```
-
-### Step 3: Verify PR Exists
-
-**Verify PR:**
-- PR exists for the feature branch
-- PR title reflects the issue and workflow
-- PR description includes context and links to deliverables
-
-**If PR doesn't exist:**
-- Create PR manually
-- Link to issue
-- Add evidence document link
-
-### Step 4: Add PR Comment
-
-Add comment to PR with link to evidence:
-```
-{Workflow_type} workflow complete. Evidence document: docs/evidence/{issue_number}-{workflow_type}-evidence.md
-
-All phases completed:
-{workflow_specific_phases_checklist}
-
-**PR Feedback History**: 
-{If feedback file exists, include: "This submission addresses all feedback from previous review rounds. See evidence document for complete feedback history and resolutions."}
-
-Ready for human review.
-```
-
-### Step 5: Update Issue Labels
-
-**Remove:**
-- `status:wip`
-
-**Add:**
-- `status:needs-review`
-
-**Keep:**
-- Current phase label (e.g., `phase:spec`, `phase:design`, `phase:impl`) to indicate which phase is in PR
-
-**GitHub Repository Context:**
-Read `.fraim/config.json` for:
-- `git.repoOwner` - GitHub repository owner
-- `git.repoName` - GitHub repository name
-
-Use GitHub MCP tools to update labels.
-
-### Step 6: Final Verification
-
-**Checklist:**
-- ✅ Issue labels updated (kept phase label, added needs-review)
-- ✅ Evidence document created and complete
-- ✅ All work committed and pushed to feature branch
-- ✅ PR exists and is ready
-- ✅ PR comment added with evidence link
-- ✅ All deliverables complete
-- ✅ Git status clean
-
-## VALIDATION
-
-### Phase Complete When:
-- ✅ Issue has `status:needs-review` label
-- ✅ Issue keeps current phase label to indicate what needs review
-- ✅ Evidence document exists and is complete
-- ✅ All work committed and synced to remote
-- ✅ PR exists and is ready for review
-- ✅ PR has comment linking to evidence
-- ✅ All previous phases complete
-
-### Phase Incomplete If:
-- ❌ Labels not updated correctly
-- ❌ Evidence document missing or incomplete
-- ❌ Work not committed and synced
-- ❌ PR not ready
-- ❌ Previous phases not complete
-
-### Report Back:
-```javascript
-seekCoachingOnNextStep({
-  workflowType: "{workflow_type}",
-  issueNumber: "{issue_number}",
-  currentPhase: "submit-pr", 
-  status: "complete",
-  evidence: {
-    labelsUpdated: "Issue has status:needs-review and keeps phase label",
-    evidenceDocument: "docs/evidence/{issue_number}-{workflow_type}-evidence.md created",
-    workCommitted: "All changes committed and pushed to feature branch",
-    prStatus: "PR ready for review",
-    prComment: "PR comment added with evidence link",
-    allPhasesComplete: "All {workflow_type} phases completed successfully"
-  }
-})
-```

package/dist/registry/ai-manager-rules/shared-phases/wait-for-pr-review.md

@@ -1,170 +0,0 @@
-# Phase: wait-for-pr-review
-
-## INTENT
-Wait for human instruction to check PR status, then evaluate if PR is ready for merge or needs more work.
-
-## OUTCOME
-Either:
-- **PR Approved**: Workflow complete, ready for merge
-- **PR Has Comments**: Write feedback file and return to workflow to address feedback
-
-## RULES FOR THIS PHASE
-
-### Success Criteria
-Read `registry/rules/agent-success-criteria.md` via `get_fraim_file` for the complete framework.
-
-## WORKFLOW
-
-### Step 1: Wait for Human Instruction
-
-**Your task is to wait for human instruction.** Do not automatically poll or check PR status.
-
-When human says "check the PR" or "proceed", move to Step 2.
-
-### Step 2: Check PR Status and Comments
-
-Use GitHub MCP tools to check the PR comprehensively:
-
-1. **Get PR Status**: Use `mcp_github_pull_request_read` with method `get` to check if PR is approved
-2. **Get All Comment Types**:
-   - **PR-level comments**: Use method `get_comments` 
-   - **Review comments**: Use method `get_review_comments` (inline/detailed comments)
-   - **Review status**: Use method `get_reviews` (approval/changes requested)
-
-### Step 3: Evaluate Results and Write Feedback File
-
-**If PR status shows "approved" AND no unresolved comments:**
-- PR is ready for merge
-- Report success
-
-**If PR has ANY comments OR is not approved:**
-- PR needs more work
-- **CRITICAL**: Write feedback file to `docs/evidence/{issueNumber}-{workflowType}-feedback.md`
-- Use Round X format (check existing file to determine next round number)
-- Report failure with feedback file path
-
-## FEEDBACK FILE FORMAT
-
-Create or append to `docs/evidence/{issueNumber}-{workflowType}-feedback.md`:
-
-```markdown
-# PR Feedback for Issue #{issueNumber} - {WorkflowType} Workflow
-
-## Round {X} Feedback
-*Received: {timestamp}*
-
-### Comment {N} - UNADDRESSED
-- **Author**: {author}
-- **Type**: {pr_comment|review_comment|review}
-- **File**: {file_path} (if applicable)
-- **Line**: {line_number} (if applicable)
-- **Comment**: {comment_body}
-- **Status**: UNADDRESSED
-```
-
-**Round Detection Logic**:
-1. If feedback file doesn't exist → Start with "Round 1"
-2. If feedback file exists → Parse to find highest "Round X", use "Round X+1"
-3. Always append new round, never overwrite existing rounds
-
-## VALIDATION
-
-### Phase Complete When:
-- ✅ PR status is "approved" in GitHub
-- ✅ No unresolved comment threads exist
-- ✅ No pending review comments
-
-**Report back with:**
-```javascript
-seekCoachingOnNextStep({
-  workflowType: "{workflow_type}",
-  issueNumber: "{issue_number}",
-  currentPhase: "wait-for-pr-review",
-  status: "complete",
-  evidence: {
-    prStatus: "approved",
-    commentsResolved: true,
-    readyForMerge: true
-  }
-})
-```
-
-### Phase Failed When:
-- ✅ PR has unresolved comments
-- ✅ PR status is not "approved"
-- ✅ Review requests changes
-
-### Report Back:
-
-**When PR is approved and ready:**
-```javascript
-seekCoachingOnNextStep({
-  workflowType: "{workflow_type}",
-  issueNumber: "{issue_number}",
-  currentPhase: "wait-for-pr-review",
-  status: "complete",
-  evidence: {
-    prStatus: "approved",
-    commentsResolved: true,
-    readyForMerge: true
-  }
-})
-```
-
-**When PR has comments (CRITICAL: Write feedback file first):**
-```javascript
-seekCoachingOnNextStep({
-  workflowType: "{workflow_type}",
-  issueNumber: "{issue_number}",
-  currentPhase: "wait-for-pr-review",
-  status: "failure",
-  findings: {
-    feedbackFile: "{issueNumber}-{workflowType}-feedback.md",
-    roundNumber: {X},
-    commentCount: {total_comments},
-    prStatus: "{current_status}"
-  }
-})
-```
-
-## GITHUB MCP TOOLS TO USE
-
-1. **Check PR Status**:
-   ```javascript
-   mcp_github_pull_request_read({
-     method: "get",
-     owner: "{repo_owner}",
-     repo: "{repo_name}", 
-     pullNumber: {pr_number}
-   })
-   ```
-
-2. **Get PR Comments**:
-   ```javascript
-   mcp_github_pull_request_read({
-     method: "get_comments",
-     owner: "{repo_owner}",
-     repo: "{repo_name}",
-     pullNumber: {pr_number}
-   })
-   ```
-
-3. **Get Review Comments**:
-   ```javascript
-   mcp_github_pull_request_read({
-     method: "get_review_comments", 
-     owner: "{repo_owner}",
-     repo: "{repo_name}",
-     pullNumber: {pr_number}
-   })
-   ```
-
-4. **Get Reviews**:
-   ```javascript
-   mcp_github_pull_request_read({
-     method: "get_reviews",
-     owner: "{repo_owner}",
-     repo: "{repo_name}",
-     pullNumber: {pr_number}
-   })
-   ```

package/dist/registry/ai-manager-rules/spec-phases/spec-competitor-analysis.md

@@ -1,105 +0,0 @@
-# Phase: spec-competitor-analysis
-
-## INTENT
-To conduct systematic competitive research and analysis for the feature being specified, ensuring comprehensive understanding of competitive landscape and clear differentiation strategy.
-
-## OUTCOME
-A comprehensive competitive analysis that:
-- Documents all configured competitors and their approaches
-- Identifies new competitors through systematic research
-- Proposes configuration updates with user approval
-- Defines clear differentiation strategy and competitive positioning
-- Updates the specification with complete competitive landscape analysis
-
-## TRIGGER
-This phase is triggered after `spec-spec` completion and before `spec-completeness-review`.
-
-## CONTEXT ADVANTAGES
-- **Full Feature Context**: Complete understanding of proposed feature and requirements
-- **Fresh Research**: Current competitive landscape information
-- **Strategic Positioning**: Ability to influence feature design based on competitive insights
-- **Configuration-Driven**: Systematic analysis of known competitors plus discovery of new ones
-
-## WORKFLOW
-
-### Step 1: Load Competitor Configuration
-- Read `.fraim/config.json` competitors section
-- Extract configured competitors and their competitive spaces
-- Note any existing competitive intelligence
-
-### Step 2: Research Configured Competitors
-For each competitor in config:
-- Research their current solution for this feature area
-- Analyze their strengths and weaknesses in this space
-- Gather customer feedback and reviews
-- Assess market position and pricing approach
-- Document findings in structured format
-
-### Step 3: Discover Additional Competitors
-- Use web search to find other competitors in the feature space
-- Research market for competitors not in configuration
-- Identify direct, adjacent, and emerging competitors
-- Focus on competitors specifically relevant to this feature
-
-### Step 4: Competitor Configuration Updates
-- **Identify New Competitors**: Present newly discovered competitors to user
-- **Configuration Proposal**: Suggest adding relevant competitors to `.fraim/config.json`
-- **User Approval**: Ask user to approve additions: "Found new competitor 'X' in space 'Y'. Add to config?"
-- **Auto-Update**: If user approves, automatically update configuration file
-- **Documentation**: Note configuration changes in competitive analysis
-
-### Step 5: Competitive Analysis
-- Compare competitor approaches to our proposed solution
-- Identify competitive advantages and disadvantages
-- Develop differentiation strategy
-- Plan competitive response strategies
-- Define market positioning approach
-
-### Step 6: Update Specification
-- Update Competitive Landscape section with findings
-- Ensure all configured competitors are covered
-- Include newly discovered competitors
-- Add competitive positioning strategy
-- Document research sources and methodology
-- Validate analysis completeness
-
-## VALIDATION
-
-### Phase Complete When:
-- ✅ All configured competitors analyzed
-- ✅ Additional competitors discovered through research
-- ✅ User consulted on adding new competitors to config
-- ✅ Configuration updated with user-approved competitors
-- ✅ Competitive positioning strategy defined
-- ✅ Differentiation advantages clearly articulated
-- ✅ Research sources documented
-- ✅ Analysis covers both configured and discovered competitors
-- ✅ Specification competitive landscape section updated
-
-### Report Back:
-When this phase is complete, call:
-```javascript
-seekCoachingOnNextStep({
-  workflowType: "spec",
-  issueNumber: "your-issue-number",
-  currentPhase: "spec-competitor-analysis",
-  status: "complete",
-  evidence: {
-    competitorsAnalyzed: ["competitor1", "competitor2"],
-    newCompetitorsFound: ["new-competitor1"],
-    configurationUpdated: true,
-    differentiationStrategy: "summary of strategy",
-    specificationUpdated: true
-  }
-})
-```
-
-### Phase Incomplete If:
-- Configuration competitors not fully researched
-- No additional competitor discovery attempted
-- User not consulted on configuration updates
-- Competitive positioning strategy missing
-- Specification not updated with findings
-
-## NEXT PHASE
-After completing competitor-analysis, proceed to `spec-completeness-review` phase.