fraim-framework 2.0.36 → 2.0.38

package/registry/workflows/product-building/implement.md

@@ -1,315 +0,0 @@
-# Workflow: implement
- 
-**Path:** `workflows/implement.md`
- 
----
- 
-# Implementation Phase
- 
-## INTENT
-To implement solutions based on approved design documents, ensuring minimal, testable code that meets requirements while following established patterns and maintaining code quality.
-Consult the architecture document for coding standards. 
-
-## PRINCIPLES
-- **Success Criteria**: Optimize for Integrity (100pts), Correctness (50pts), Completeness (30pts), Independence (20pts), and Speed (10pts) - see `rules/agent-success-criteria.md` (fetch via `get_fraim_file`).
-- **Design-Driven**: Follow approved RFCs and design documents
-- **Minimal Implementation**: Write only the code needed for the issue
-- **Test-First**: Ensure comprehensive test coverage
-- **Quality Focus**: Maintain code quality and follow patterns
-- **Complete**: All aspects of technical spec are implemented, tested, validated
-- **Spike-First Development**: Follow "Spike-First Development" rule (read `rules/spike-first-development.md` via `get_fraim_file`) to validate technology compatibility before building complex solutions
-- **Debugging**: Use "Successful Debugging Patterns" (read `rules/successful-debugging-patterns.md` via `get_fraim_file`) when stuck
-- **Git Safety**: Follow "Git Safe Commands" (read `rules/git-safe-commands.md` via `get_fraim_file`)
-- **Architecture**: Follow existing architecture - see `.fraim/config.json` for the path (`customizations.architectureDoc`)
- 
-## IMPLEMENTATION WORKFLOW
-
-### Step 1: Issue Identification
-Ask for {issue_number} (and optional {slug}); confirm target branch feature/{issue_number}-{slug}.
-
-### Step 2: Phase Initiation
-Label the issue 'phase:impl'. (GitHub Action will automatically create a draft PR if none exists, or update the existing PR with phase-specific details, and label the issue `status:wip`)
-
-### Step 3: Environment Setup
-**IMPORTANT**: The user has already run `prep-issue.sh` which has:
-- ✅ Created the feature branch
-- ✅ Checked out the branch
-- ✅ Pushed the empty branch to origin
-- ✅ Indexed the codebase with Serena
-- ✅ Opened the editor in the prepared workspace
-
-You can start working immediately in the prepared environment. No need to create branches or wait for GitHub Actions.
-
-### Step 4: Work Location
-You are already in the correct workspace prepared by the user. Confirm you're on the right branch and start working.
-
-### Step 5: Implementation Work
-Your work entails the following:
-
-- **CHECK FOR FEEDBACK**: Before starting work, check for review feedback:
-  - Design Review Feedback: `docs/evidence/{issue}-design-reviewer-feedback.md`
-  - Feature Review Feedback: `docs/evidence/{issue}-feature-reviewer-feedback.md`
-  - If feedback exists: **MUST address all items in feedback before proceeding**
-  - Update evidence document after addressing feedback
-- **SPIKE-FIRST CHECK**: Read and follow "Spike-First Development" rule (retrieve via `get_fraim_file({ path: "rules/spike-first-development.md" })`)
-- If implementation involves unfamiliar technology, create spike/proof-of-concept first
-- Validate technology compatibility before building complex solutions
-- Review the RFC associated with this issue.
-- **TEST ANALYSIS**: Check for existing tests related to this feature. Run them to establish a baseline.
-- Determine whether changes need to be made to existing code, or brand new code needs to be written.
-- **TEST-FIRST DISCIPLINE**: Write the minimal set of code and test cases needed for this issue. Tests must be created before or alongside implementation, not after.
-- **TEST EXECUTION REQUIREMENT**: All test files must be executed and passing before submitting PR evidence. Cannot claim tests "need fixes" without attempting execution.
-- **CRITICAL INTEGRITY CHECK**: Ensure test cases pass with original, unmodified criteria
-- **VERIFICATION REQUIRED**: Run tests with original criteria before claiming success
-- **AUTONOMOUS VALIDATION**: Must attempt to run tests, start servers, and validate claims independently before stating external dependencies. Cannot defer validation due to assumed constraints without verification.
-- **MANUAL OUTPUT INSPECTION (CRITICAL)**:
-  - **Trust, but Verify**: Do not rely solely on automated tests.
-  - **Inspect Generated Artifacts**: If your code generates files, logs, or UI, you MUST use `view_file` or `read_url` to inspect the actual output.
-  - **Verify Content**: Ensure the content look correct, has no placeholders (unless intended), and follows expected formatting.
-- When ready for review, flip issue to 'status:needs-review' and remove 'status:wip'
-- **EVIDENCE STORAGE**: Create or update evidence document in `docs/evidence/{issue}-implementation-evidence.md`
-  - Use Bug Evidence template (retrieve via `get_fraim_file({ path: "templates/evidence/Implementation-BugEvidence.md" })`)
-  - Use Feature Evidence template (retrieve via `get_fraim_file({ path: "templates/evidence/Implementation-FeatureEvidence.md" })`)
-  - Include all test outputs, validation results, screenshots, etc.
-  - If addressing feedback, document how each feedback item was addressed
-  - This evidence will be reviewed by design review agent
-- While submitting review, add a comment to the PR referencing the evidence document
-
-### Step 6: Mandatory Pre-Completion Reflection
-**🚨 CRITICAL - Minimum 1 minute required**
-
-BEFORE marking status:needs-review, complete reflection:
-
-1. Read "Mandatory Pre-Completion Reflection" rule (retrieve via `get_fraim_file({ path: "rules/mandatory-pre-completion-reflection.md" })`)
-2. Complete all 4 phases:
-   - Phase 1: Claim Verification (3 min) - What am I claiming? What evidence do I have?
-   - Phase 2: Risk Analysis (3 min) - What could go wrong? What didn't I test?
-   - Phase 3: Validation Plan Check (2 min) - Do I cover all spec scenarios?
-   - Phase 4: Self-Audit (2 min) - Did I follow rules? Would I bet money this works?
-3. Document reflection analysis
-4. Address any blockers identified in reflection
-5. Include reflection output in PR evidence comment
-
-**Cannot proceed to status:needs-review until reflection complete and blockers addressed.**
-
-**Process:**
-- Create reflection document following template
-- Identify gaps and blockers
-- Fix blockers before proceeding
-- Include reflection in evidence
-
-### Step 7: Test Execution Checklist
-**🚨 REQUIRED - Execute All Tests Before Evidence Submission:**
-
-Before creating PR evidence, verify:
-
-- [ ] All new test files have been executed
-- [ ] All test execution results have been verified (exit code 0)
-- [ ] Test output included in evidence (actual command output, not summaries)
-- [ ] No test status marked "pending" if test file exists and can be executed
-- [ ] All existing test suites run (or documented why not applicable)
-- [ ] Cannot claim tests "need fixes" without attempting execution first
-
-**Test Execution Requirements**:
-- Must run actual test commands and capture output
-- Must verify exit codes are 0 (success)
-- Must include complete test output in evidence, not just summaries
-- Must attempt to resolve test execution issues before claiming they exist
-
-### Step 8: Quality Gate Validation
-**🚨 REQUIRED - Run Quality Checks Before Marking Ready:**
-
-Before marking work ready for review, run the pre-PR quality gate:
-
-```bash
-# Execute code quality check script directly from synced location
-~/.fraim/scripts/code-quality-check.sh pre-pr
-
-# On Windows:
-# %USERPROFILE%\.fraim\scripts\code-quality-check.sh pre-pr
-```
-
-### Step 6: PR Monitoring
-After submitting/updating PR:
-- Switch to "Iterate on PR Comments" workflow (retrieve via `get_fraim_file({ path: "workflows/product-building/iterate-on-pr-comments.md" })`) to monitor actions and handle feedback.
-
-**What this checks**:
-- ❌ BLOCKS: No `as any` type bypassing in src/
-- ❌ BLOCKS: TypeScript compilation passes
-- ❌ BLOCKS: All test files referenced in evidence have been executed (new check)
-- ⚠️ WARNS: Linter passes
-- ⚠️ WARNS: All commits are pushed
-- ⚠️ WARNS: Working directory is clean
-- ⚠️ WARNS: PR comments are addressed
-- ⚠️ WARNS: Evidence statements claiming "pending" for automated validations (new check)
-
-**If critical checks fail** (❌):
-- You MUST fix violations before proceeding
-- Do not mark work as ready for review
-
-**If warnings appear** (⚠️):
-- Address them if possible
-- Document why you couldn't address them in evidence
-- Warnings won't block marking ready for review
-
-**In your implementation evidence**, include the output:
-```markdown
-## Quality Gate Validation
-
-### Pre-PR Check Results
-```bash
-~/.fraim/scripts/code-quality-check.sh pre-pr
-✅ GATE 1: No 'as any' Type Bypassing
-✅ GATE 2: TypeScript Compilation
-⚠️ GATE 3: Linter (2 warnings - documented below)
-✅ GATE 4: Git Status
-✅ GATE 5: Commits Pushed
-✅ GATE 6: PR Comments Addressed
-
-✅ ALL CHECKS PASSED (with warnings documented)
-```
-
-Linter warnings:
-- Warning 1: Unused variable in test file - intentional for test setup
-- Warning 2: Prefer-const in legacy code - will address in separate cleanup PR
-```
-
-### Step 9: MANDATORY FINAL STATUS UPDATE
-**🚨 CRITICAL - DO NOT SKIP THIS STEP:**
-
-Once all implementation work is complete, quality gates pass, and evidence is provided:
-
-1. **REQUIRED**: Verify pre-PR quality checks passed (see Step 6)
-2. **REQUIRED**: Update issue status from `status:wip` to `status:needs-review`
-3. **REQUIRED**: Verify the status change was applied successfully
-4. **REQUIRED**: Confirm issue is ready for user review
-
-**This step is MANDATORY and must not be forgotten. Add it to your todo list at the start of implementation.**
-
-## TEST INTEGRITY REQUIREMENTS
-
-### Test Immutability Rule
-**Test success criteria are immutable during implementation phase.**
-
-#### What This Means
-- Test criteria must remain unchanged from design phase
-- Success requirements cannot be modified to hide failures
-- Test logic cannot be adjusted to accommodate broken code
-- Any changes to test requirements must be explicitly approved and documented
-
-#### Verification Process
-Before claiming any implementation is working:
-1. Run tests with original, unmodified criteria
-2. Verify ALL requirements pass without exception
-3. Document any test modifications if absolutely necessary
-4. Get explicit approval for any test changes
-
-### Progress Transparency Requirements
-**Always be honest about implementation status and challenges.**
-
-#### Required Statements
-When facing implementation challenges, explicitly state:
-- "I am struggling with [specific issue] and need help"
-- "The implementation is not working because [specific reason]"
-- "I need to fix [specific problem] before claiming success"
-
-#### Prohibited Statements
-- "The implementation is working" (when tests fail)
-- "Core functionality is complete" (when critical features broken)
-- "Tests are passing" (when criteria were modified)
-- "Issue is resolved" (when underlying problems exist)
-
-### Success Verification Standards
-**Genuine success requires meeting ALL original criteria without modification.**
-
-#### Verification Checklist
-Before marking any task complete:
-- [ ] All original test criteria pass without modification
-- [ ] No test logic was changed to accommodate broken code
-- [ ] Success requirements are met exactly as originally defined
-- [ ] Implementation works with real data/scenarios
-- [ ] No critical functionality is missing or broken
-
-### When Tests Fail
-1. **Don't modify tests** - Fix the code instead
-2. **Don't claim success** - Admit the failure
-3. **Ask for help** - Be transparent about challenges
-4. **Fix root causes** - Address underlying issues
-5. **Verify with original criteria** - Ensure genuine success
-
-### When Facing Difficult Challenges
-1. **Be honest** - State what's not working
-2. **Ask for guidance** - Don't try to fake success
-3. **Focus on solutions** - Work on fixing the code
-4. **Maintain integrity** - Don't compromise standards
-5. **Document struggles** - Help others learn from challenges
-
-### Step 8: Post-Implementation Quality Assurance
-
-After implementation is complete and before marking as ready for review, consider running a quality assurance cycle:
-
-**Optional but Recommended**: Use `workflows/quality-assurance/iterative-improvement-cycle.md` for systematic review and improvement:
-- Review the implemented feature in a browser
-- Identify any issues or improvements
-- Fix issues systematically
-- Validate fixes work correctly
-
-This workflow provides a systematic **Review → Critique → Fix → Validate** cycle that ensures high-quality, production-ready implementations.
-
-### Step 10: Iteration
-If workflow actions or reviewer feedback indicates more work is needed:
-
-- Label the issue 'status:wip' and remove 'status:needs-review'
-- Go back to Step 5 and iterate until PR is approved
-
-## EXAMPLES
-
-### Good: Proper Implementation Process
-```
-Issue #84: "Fix calendar sync timeout"
-1. ✅ Identified: Issue #84, branch feature/84-fix-sync
-2. ✅ Phase: Set phase:impl, PR created
-3. ✅ Environment: User ran prep-issue.sh, ready to work
-4. ✅ Location: Working in prepared workspace with Serena indexing
-5. ✅ RFC Review: Read docs/rfcs/84-fix-sync-timeout.md
-6. ✅ Analysis: Determined need to modify existing retry logic
-7. ✅ Implementation: Added exponential backoff with jitter
-8. ✅ Tests: Created test cases, all passing
-9. ✅ Review: Set status:needs-review
-10. ✅ Iteration: Incorporated feedback, updated implementation
-Result: Clean, tested implementation following design
-```
-
-### Bad: Incomplete Implementation Process
-```
-Issue #84: "Fix calendar sync timeout"
-1. ✅ Identified: Issue #84
-2. ❌ Skip: Didn't review RFC
-3. ❌ Skip: Started coding without understanding requirements
-4. ❌ Skip: No test cases written
-5. ❌ Skip: Didn't verify tests pass
-6. ❌ Skip: No code review process
-Result: Incomplete, untested implementation
-```
-
-## 🔥 MANDATORY COMPLETION CHECKLIST
-
-**Before claiming implementation is complete, verify ALL items:**
-
-### ✅ Implementation Checklist
-- [ ] RFC reviewed and understood
-- [ ] Code changes implemented according to design
-- [ ] **Existing tests checked and run**
-- [ ] **New test cases created for the feature**
-- [ ] **Full test suite run and passing**
-- [ ] Evidence provided in GitHub issue
-- [ ] PR feedback addressed (if applicable)
-
-### ✅ CRITICAL FINAL STEPS
-- [ ] **All PR comments verified and addressed (if PR exists)**
-- [ ] **Evidence includes how each PR comment was handled**
-- [ ] **Issue status updated from `status:wip` to `status:needs-review`**
-- [ ] **Status change verified successfully**
-- [ ] **User notified that issue is ready for review**
-
-**🚨 FAILURE TO COMPLETE PR COMMENT VALIDATION AND STATUS UPDATE MEANS THE WORK IS NOT DONE! 🚨**

package/registry/workflows/product-building/iterate-on-pr-comments.md

@@ -1,70 +0,0 @@
-# Workflow: iterate-on-pr-comments
-
-**Path:** `workflows/iterate-on-pr-comments.md`
-
----
-
-# PR Iteration & Monitoring
-
-## INTENT
-To ensure AI agents autonomously handle the complete PR lifecycle with proper monitoring, feedback handling, and testing, eliminating gaps that require human intervention.
-
-## PRINCIPLES
-- **Complete Autonomy**: Agents should handle the PR workflow without requiring human prompting
-- **Proactive Monitoring**: Continuously check status of actions and PRs
-- **Comprehensive Feedback**: Address all comments before resubmission
-- **Evidence-Based Progress**: Document test results and implementation status
-
-## WORKFLOW
-
-### Step 1: Git Action Monitoring
-After pushing changes:
-1.  **Monitor Actions**: Check GitHub Actions status every 30 seconds.
-2.  **Retry on Failure**: If specific actions fail, analyze logs, debug, fix, and push again.
-3.  **Timeout**: If actions run > 10 mins or fail 3x consecutively, notify user with analysis.
-4.  **Success**: Only when all actions pass, proceed to Step 2.
-
-### Step 2: PR Feedback Polling
-After submission (or update):
-1.  **Poll**: Check for PR comments/reviews every 1 minute.
-2.  **Timeout**: After 24 hours of silence, notify user.
-3.  **Active Feedback**: If feedback arrives, proceed to Step 3 immediately.
-
-### Step 3: Feedback Processing
-1.  **Set Status**: Label issue `status:wip`.
-2.  **Analyze**: Read all comments. Use `get_github_pr_comments` or similar tool.
-3.  **Address**: For each comment:
-    *   Implement code changes or fixes.
-    *   **Reply** to the comment (using `add_comment_to_pending_review` or `add_issue_comment`) explaining the fix.
-4.  **Verify**: Ensure no comments are left unaddressed.
-
-### Step 4: Verification & Evidence
-Before re-submitting:
-1.  **Run Tests**: Execute relevant test suites (Unit + Integration).
-2.  **Document**: Add a comment to the PR/Issue with:
-    *   Test commands run.
-    *   Pass/Fail status.
-    *   Coverage summary.
-3.  **Clean Up**: Remove temp files/logs.
-
-### Step 5: Submission
-1.  **Sync**: Push all changes.
-2.  **Set Status**: specific label `status:needs-review`.
-3.  **Loop**: Return to Step 1 (Monitor Actions).
-
-## FAILURE MODES
-- **Git Action Timeout**: 10 mins / 20 attempts.
-- **Feedback Timeout**: 24 hours.
-- **Network Errors**: Exponential backoff needed.
-
-## EXAMPLES
-
-### Good: Handling Feedback
-```
-1. Detected 3 comments on PR #123.
-2. Comment 1 ("Fix typo"): Fixed in file.ts. Replied "Fixed".
-3. Comment 2 ("Memory leak"): Reproduced, fixed logic. Replied "Fixed with new pattern".
-4. Ran tests: All Pass.
-5. Posted evidence.
-6. Pushed. Labeled status:needs-review.
-```

package/registry/workflows/product-building/prep-issue.md

@@ -1,43 +0,0 @@
-# Workflow: Issue Preparation (prep-issue)
-
-This workflow prepares the local development environment for working on a specific GitHub issue.
-
-## Prerequisites
-
-- GitHub Issue Number (e.g., 56)
-- GitHub CLI (gh) installed and authenticated
-
-## Action Items
-
-1.  **Execute Preparation Script**:
-    Fetch and run cleanup/setup scripts ephemerally.
-
-    ```bash
-    # Execute the prep-issue script directly from synced location
-    ~/.fraim/scripts/prep-issue.sh {issue_number}
-    
-    # On Windows:
-    # %USERPROFILE%\.fraim\scripts\prep-issue.sh {issue_number}
-    ```
-
-
-3.  **Verify Setup**:
-    - **Clean Context**: Start fresh to avoid pollution
-    - **Environment**: Follow "Local Development" guidelines (read `rules/local-development.md` using `get_fraim_file`).
-    - [ ] Feature branch created and pushed to origin.
-    - [ ] `npm install` completed.
-    - [ ] Serena indexing completed (if applicable).
-
-## Implementation Detail (Agent Guidance)
-
-Execute:
-```bash
-# Execute the prep-issue script directly from synced location
-~/.fraim/scripts/prep-issue.sh {issue_number}
-
-# On Windows:
-# %USERPROFILE%\.fraim\scripts\prep-issue.sh {issue_number}
-```
-
-> [!NOTE]
-> The script will automatically handle branch naming based on the issue title using `gh issue view`.

package/registry/workflows/product-building/prototype.md

@@ -1,60 +0,0 @@
-# Workflow: prototype
-
-**Path:** `workflows/prototype.md`
-
----
-
-# Prototype / PoC Phase
-
-## INTENT
-To quickly explore ideas, validate technologies, or prove concepts using "spike" code. Speed and learning are prioritized over code quality and tests.
-
-## PRINCIPLES
-- **Speed Over Perfection**: It gets the job done; it doesn't need to be pretty.
-- **Disposable Code**: Assume this code will be thrown away or heavily refactored.
-- **Time-Boxed**: Spikes should have a clear time limit.
-- **Learning Focused**: The goal is to answer a question or prove a capability.
-
-## PROTOTYPE WORKFLOW
-
-### Step 1: Issue Identification
-Ask for {issue_number} (and optional {slug}).
-
-### Step 2: Phase Initiation
-Label the issue 'phase:prototype'.
-
-### Step 3: Environment Setup
-User runs `prep-issue.sh` (or you do if needed).
-Switch to a `prototype/...` branch if not already on one.
-
-### Step 4: Work Location
-Work in the prepared workspace.
-
-### Step 5: Prototyping
-- **Goal**: Build a working demonstration of the concept.
-- **Constraints**:
-    - **No Tests Required** (unless helpful for you).
-    - **Hardcoding Allowed**: Use hardcoded values to speed up development.
-    - **No Cleanup Required**: Formatting/Linting is optional.
-    - **Focus on the Core**: Ignore edge cases, error handling, and polish.
-
-### Step 6: Demonstration
-- Verify the prototype works for the "Happy Path".
-- Create a screen recording or screenshot of the working prototype.
-- Document what was learned:
-    - Does it work?
-    - What are the risks?
-    - How should we implement the real version?
-    - How should we implement the real version?
-
-### Step 7: Transition
-**Decide the next step:**
-1.  **Discard**: The idea didn't work. Close issue.
-2.  **Spec**: The idea works, but needs a full design. Call `get_fraim_workflow({ workflow: "spec" })`.
-3.  **Implement**: The prototype is good enough to be the base. **YOU MUST CLEAN IT UP.** 
-    - Call `get_fraim_workflow({ workflow: "implement" })`.
-    - **CRITICAL**: You must specifically address the "Cleanup" phase where you refactor the prototype code into production-quality code, add tests, and handle edge cases.
-
-### Step 8: Completion
-- Commit the prototype code (optional, but good for history).
-- Label `status:prototype-done`.

package/registry/workflows/product-building/resolve.md

@@ -1,164 +0,0 @@
-# Workflow: resolve
- 
-**Path:** `workflows/resolve.md`
- 
----
- 
-# Issue Resolution Workflow
- 
-## INTENT
-To provide a systematic approach to resolving issues from development through merge verification and cleanup, ensuring no work is lost and all changes are properly integrated into the main codebase.
- 
-## PRINCIPLES
-- **Success Criteria**: Optimize for Integrity (Verify truthfully) and Completeness (Clean up fully) - see `rules/agent-success-criteria.md` (fetch via `get_fraim_file`).
-- **Verification First**: Always verify merges before closing issues
-- **Complete Cleanup**: Remove all traces of feature branches
-- **No Work Loss**: Prevent incidents like Issue #112 through proper verification
-- **Systematic Process**: Follow established steps in order
-- **Evidence-Based**: Provide concrete verification of completion
-- **Git Safety**: Follow "Git Safe Commands" (read `rules/git-safe-commands.md` using `get_fraim_file`)
-
-## CRITICAL DEPENDENCY
-**This workflow MUST be used in conjunction with "Merge Requirements" rule** (read `rules/merge-requirements.md` via `get_fraim_file`) which contains:
-- **Pre-Push Workflow** (for feature branches during development)
-- **PR Description Template** (for PR creation)
-- **Final Merge Process** (for merging to master - used in this workflow)
-- **Conflict Resolution Guide** (for resolving conflicts during rebase)
-
-**Note**: The Pre-Push workflow applies to feature branch development. This resolve.md workflow focuses on the **final merge into master** and uses the Final Merge Process from merge-requirements.md.
-
-## RESOLUTION WORKFLOW
-
-**PREREQUISITE**: This workflow assumes:
-- ✅ All development work is complete
-- ✅ All tests have been run on the feature branch
-- ✅ PR has been created and approved
-- ✅ Feature branch is ready for merge
-
-### 1. Execute the Merge
-Use GitHub MCP to merge the PR:
-
-```bash
-# Merge the PR using GitHub MCP
-gh pr merge <PR_NUMBER> --rebase
-```
-
-**If conflicts occur during merge:**
-- GitHub will reject the merge with conflict details
-- Use `gh pr view <PR_NUMBER>` to see conflict details
-- Resolve conflicts intelligently using the **Conflict Resolution Guide** from `merge-requirements.md`
-- Keep master's base implementation and add your enhancements on top
-- Test the resolution: `npm run build && npm run test-smoke test*.ts`
-- Push the resolved changes and retry the merge
-
-### 2. Wait for Master CI Smoke Tests
-After successful merge, monitor the master branch CI:
-- Check GitHub Actions for the master branch
-- Wait for smoke tests to complete successfully
-- **CRITICAL**: Do not proceed until CI passes
-
-### 3. Verify Code Made it to Master
-**MANDATORY**: Confirm the merge was successful:
-```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
-```
-
-### 4. Handle CI Failures
-**If master CI fails:**
-- Debug the issue immediately
-- Fix the problem in the feature branch
-- Push the fix and re-merge
-- Repeat until CI passes
-- **Do not close the issue until CI passes**
-
-### 5. Confirm all good
-**Only after CI passes successfully:**
-
-**Add Resolution Comment if conflicts with master had to be resolved:**
-- Add a comment to the issue using GitHub MCP:
-```bash
-gh issue comment <ISSUE_NUMBER> --body "✅ Encountered conflicts during merge with master.
-
-**Conflict Resolution Notes:**
-- Resolved conflicts in: [list files with conflicts]
-- Resolution strategy: [explain what was done]
-- Kept master's base implementation and added enhancements on top"
-```
-
-**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 
-
-### 6. Issue Resolution & Cleanup
-**Close the Issue:**
-- Close the issue with resolution comment using GitHub MCP:
-```bash
-gh issue close <ISSUE_NUMBER> --comment "✅ Issue resolved and merged to master. CI smoke tests passed."
-```
-
-**Cleanup Branch:**
-    ```bash
-    # Execute cleanup script directly from synced location
-    npx tsx ~/.fraim/scripts/cleanup-branch.ts {branch_name}
-    
-    # On Windows:
-    # npx tsx %USERPROFILE%\.fraim\scripts\cleanup-branch.ts {branch_name}
-    ```
-
-### 7. Celebrate
-- Say Hoorah !
-
-
-## EXAMPLES
-
-### Good: Proper Resolution Process
-```
-Issue #84: "Fix calendar sync timeout"
-PREREQUISITE: ✅ Development complete, tests passed, PR approved
-1. ✅ Merge: Used `gh pr merge <PR_NUMBER> --rebase`
-2. ✅ Conflicts: Resolved conflicts intelligently (kept master's base)
-3. ✅ CI Wait: Waited for master CI smoke tests to pass
-4. ✅ Verification: Confirmed merge commit exists in master
-5. ✅ Schema: Cleaned up database schema BEFORE branch deletion
-6. ✅ Comment: Added resolution comment with conflict resolution notes
-7. ✅ Close: Closed issue with resolution comment using `gh issue close`
-8. ✅ Cleanup: Deleted branch after schema cleanup
-Result: Complete resolution with no work loss
-```
-
-### Bad: Incomplete Resolution
-```
-Issue #84: "Fix calendar sync timeout"
-PREREQUISITE: ✅ Development complete, tests passed, PR approved
-1. ✅ Merge: Used `gh pr merge <PR_NUMBER> --rebase`
-2. ❌ Skip: Didn't wait for master CI smoke tests
-3. ❌ Skip: Didn't verify merge commit exists
-4. ❌ Skip: Didn't clean up schema BEFORE branch deletion
-5. ❌ Skip: Didn't add resolution comment with conflict notes
-6. ❌ Close: Closed issue without CI verification
-Result: Work lost, schema not cleaned up, CI may have failed
-```