@njuptlzf/mcp-adapter 2.29.0-0.0.1

package/skills/resolve-conflicts/references/patterns.md

@@ -0,0 +1,432 @@
+# Conflict Resolution Patterns
+
+This document provides detailed patterns for resolving specific types of conflicts.
+
+**Important**: For each conflict you resolve, provide a one-line explanation of your resolution strategy. When the correct resolution isn't clear from the diff, present numbered options to the user.
+
+## Import Conflicts
+
+When both branches modify import statements, merge both sets of imports:
+
+### Pattern: Combine and Deduplicate
+
+```
+<<<<<<< HEAD
+import { foo, bar } from './module';
+import { baz } from './other';
+=======
+import { foo, qux } from './module';
+import { newThing } from './another';
+>>>>>>> branch
+```
+
+**Resolution:** Merge all unique imports, group by module:
+
+```
+import { foo, bar, qux } from './module';
+import { baz } from './other';
+import { newThing } from './another';
+```
+
+### Rust Imports
+
+```
+<<<<<<< HEAD
+use std::collections::HashMap;
+use crate::domain::User;
+=======
+use std::collections::HashSet;
+use crate::domain::Account;
+>>>>>>> branch
+```
+
+**Resolution:**
+
+```
+use std::collections::{HashMap, HashSet};
+use crate::domain::{Account, User};
+```
+
+**Key principles:**
+- Combine all unique imports
+- Remove duplicates
+- Follow language-specific style (group by module, alphabetize)
+- Preserve any re-exports or aliases from both sides
+
+**One-line explanation example**: "Merging imports by combining unique imports from both branches and grouping by module."
+
+## Test Conflicts
+
+Tests should almost always include both changes, as tests are additive.
+
+### Pattern: Merge Test Cases
+
+```
+<<<<<<< HEAD
+#[test]
+fn test_user_creation() { ... }
+
+#[test]
+fn test_user_validation() { ... }
+=======
+#[test]
+fn test_user_creation() { ... }
+
+#[test]
+fn test_user_deletion() { ... }
+>>>>>>> branch
+```
+
+**Resolution:** Include all tests (assuming test_user_creation is identical):
+
+```
+#[test]
+fn test_user_creation() { ... }
+
+#[test]
+fn test_user_validation() { ... }
+
+#[test]
+fn test_user_deletion() { ... }
+```
+
+### Test Setup/Fixtures Conflicts
+
+When both branches modify test fixtures, merge the changes:
+
+```
+<<<<<<< HEAD
+fn setup() -> TestContext {
+    TestContext {
+        user: create_test_user(),
+        admin: create_admin(),
+    }
+}
+=======
+fn setup() -> TestContext {
+    TestContext {
+        user: create_test_user(),
+        database: init_test_db(),
+    }
+}
+>>>>>>> branch
+```
+
+**Resolution:**
+
+```
+fn setup() -> TestContext {
+    TestContext {
+        user: create_test_user(),
+        admin: create_admin(),
+        database: init_test_db(),
+    }
+}
+```
+
+**Key principles:**
+- Keep all test cases unless they test the exact same thing
+- Merge test fixtures and setup functions
+- If test names conflict but test different things, rename one
+- Preserve all assertions from both sides
+
+**One-line explanation example**: "Including all test cases from both branches and merging test fixtures."
+
+## Lock File Conflicts
+
+Lock files (Cargo.lock, package-lock.json, yarn.lock, etc.) should be regenerated rather than manually resolved.
+
+### Pattern: Regenerate Lock File
+
+```bash
+# For Cargo.lock
+git checkout --theirs Cargo.lock  # or --ours, either works
+cargo update  # or cargo build
+
+# For package-lock.json
+git checkout --theirs package-lock.json
+npm install
+
+# For yarn.lock
+git checkout --theirs yarn.lock
+yarn install
+
+# For Gemfile.lock
+git checkout --theirs Gemfile.lock
+bundle install
+
+# For poetry.lock
+git checkout --theirs poetry.lock
+poetry lock --no-update
+```
+
+**Key principles:**
+- Always regenerate, never manually merge
+- Choose either version (--ours or --theirs), doesn't matter
+- Run the package manager's update/install command
+- The result will include dependencies from both branches
+
+**One-line explanation example**: "Regenerating lock file with package manager to include dependencies from both branches."
+
+## Configuration File Conflicts
+
+Configuration files often need careful merging of both changes.
+
+### Pattern: Merge Configuration Values
+
+```yaml
+<<<<<<< HEAD
+server:
+  port: 8080
+  timeout: 30
+  max_connections: 100
+=======
+server:
+  port: 8080
+  timeout: 60
+  enable_https: true
+>>>>>>> branch
+```
+
+**Resolution:**
+
+```yaml
+server:
+  port: 8080
+  timeout: 60  # Prefer the newer/safer value
+  max_connections: 100
+  enable_https: true
+```
+
+**Key principles:**
+- Include all configuration keys from both sides
+- When same key has different values, choose based on:
+  - Newer value (if timestamp available)
+  - Safer/more conservative value
+  - Production-ready value
+  - Document the choice in commit message
+
+**One-line explanation example**: "Merging all config keys and choosing incoming value for 'timeout' as it's more recent."
+
+**When to ask the user**: If conflicting values have significant implications (e.g., security settings, API endpoints), present options:
+```
+Config conflict in config.yaml for key 'timeout':
+
+**Option 1**: Keep current value (30 seconds)
+**Option 2**: Keep incoming value (60 seconds)
+**Option 3**: Provide a different value
+
+Please select an option.
+```
+
+## Code Logic Conflicts
+
+When both branches modify the same function, carefully analyze the intent.
+
+### Pattern: Sequential Changes
+
+If changes are independent and can coexist:
+
+```
+<<<<<<< HEAD
+fn process(data: &str) -> Result<String> {
+    let cleaned = data.trim();
+    validate(cleaned)?;
+    Ok(cleaned.to_uppercase())
+}
+=======
+fn process(data: &str) -> Result<String> {
+    let cleaned = data.trim();
+    if cleaned.is_empty() {
+        return Err(Error::EmptyInput);
+    }
+    Ok(cleaned.to_uppercase())
+}
+>>>>>>> branch
+```
+
+**Resolution:** Combine both validations:
+
+```
+fn process(data: &str) -> Result<String> {
+    let cleaned = data.trim();
+    if cleaned.is_empty() {
+        return Err(Error::EmptyInput);
+    }
+    validate(cleaned)?;
+    Ok(cleaned.to_uppercase())
+}
+```
+
+**One-line explanation**: "Merging both validations as they check different conditions (emptiness and validation)."
+
+### Pattern: Conflicting Logic
+
+If changes represent different approaches:
+
+```
+<<<<<<< HEAD
+fn calculate_price(item: &Item) -> f64 {
+    item.base_price * (1.0 + item.tax_rate)
+}
+=======
+fn calculate_price(item: &Item) -> f64 {
+    item.base_price + item.tax_amount
+}
+>>>>>>> branch
+```
+
+**Resolution:** Analyze which approach is correct:
+- Review PR/commit messages for context
+- Check which calculation matches business requirements
+- Consider running tests with both approaches
+- Choose one and document why in commit message
+
+**When to ask the user**: Present this as options when the correct approach isn't clear:
+
+```
+Code logic conflict in calculate_price function:
+
+<<<<<<< HEAD (Current Branch)
+fn calculate_price(item: &Item) -> f64 {
+    item.base_price * (1.0 + item.tax_rate)
+}
+=======
+fn calculate_price(item: &Item) -> f64 {
+    item.base_price + item.tax_amount
+}
+>>>>>>> feature-branch (Incoming Branch)
+
+These represent different calculation methods:
+
+**Option 1**: Keep current branch - calculates tax as percentage (base_price * tax_rate)
+**Option 2**: Keep incoming branch - uses pre-calculated tax amount (base_price + tax_amount)
+**Option 3**: Ask you to clarify the correct business logic
+
+Please select an option.
+```
+
+**One-line explanation example**: "Choosing current branch approach as it calculates tax dynamically based on rate (per user selection)."
+
+## Struct/Type Definition Conflicts
+
+Merge all fields from both branches.
+
+### Pattern: Merge Struct Fields
+
+```
+<<<<<<< HEAD
+pub struct User {
+    pub id: i64,
+    pub name: String,
+    pub email: String,
+    pub created_at: DateTime,
+}
+=======
+pub struct User {
+    pub id: i64,
+    pub name: String,
+    pub role: UserRole,
+    pub updated_at: DateTime,
+}
+>>>>>>> branch
+```
+
+**Resolution:**
+
+```
+pub struct User {
+    pub id: i64,
+    pub name: String,
+    pub email: String,
+    pub role: UserRole,
+    pub created_at: DateTime,
+    pub updated_at: DateTime,
+}
+```
+
+**Key principles:**
+- Include all fields from both sides
+- If field types conflict, analyze which is more appropriate
+- Update all usages of the struct accordingly
+- Fix compilation errors after merging
+
+**One-line explanation example**: "Including all fields from both branches in User struct."
+
+**When to ask the user**: If the same field has different types:
+```
+Struct conflict - field 'role' has different types:
+
+**Option 1**: Keep current type (role: String)
+**Option 2**: Keep incoming type (role: UserRole enum)
+**Option 3**: Provide more context
+
+Please select an option.
+```
+
+## Documentation Conflicts
+
+Merge all documentation improvements.
+
+### Pattern: Combine Documentation
+
+```
+<<<<<<< HEAD
+/// Processes user input and returns validated data.
+/// 
+/// # Arguments
+/// * `input` - The raw user input
+=======
+/// Processes user input and returns validated data.
+/// 
+/// # Errors
+/// Returns `Error::InvalidInput` if validation fails
+>>>>>>> branch
+```
+
+**Resolution:**
+
+```
+/// Processes user input and returns validated data.
+/// 
+/// # Arguments
+/// * `input` - The raw user input
+/// 
+/// # Errors
+/// Returns `Error::InvalidInput` if validation fails
+```
+
+**Key principles:**
+- Preserve all documentation sections
+- If descriptions conflict, choose the more accurate/detailed one
+- Keep all examples from both sides
+- Maintain consistent formatting
+
+**One-line explanation example**: "Combining all documentation sections from both branches."
+
+## Deleted File Special Cases
+
+### Pattern: File Renamed/Moved
+
+If file was deleted on one branch but modified on another, and there's a similar new file:
+
+1. Check if file was renamed: `git log --follow --diff-filter=R -- <file>`
+2. Apply modifications to the new location
+3. Remove the old file
+
+### Pattern: File Legitimately Deleted
+
+If file deletion was intentional (feature removed, refactored):
+
+1. Review the modifications from the other branch
+2. Determine if any changes are still relevant
+3. If yes, apply to the appropriate new location
+4. If no, accept the deletion
+
+### Pattern: Accidental Deletion
+
+If file should not have been deleted:
+
+1. Restore the file from the branch that kept it
+2. Apply any additional modifications
+3. Verify tests pass

package/skills/resolve-conflicts/references/sample-plan.md

@@ -0,0 +1,96 @@
+# Sample Merge Resolution Plan
+
+This file provides a complete example of a merge resolution plan for a typical conflict scenario.
+
+## Merge Resolution Plan
+
+### Conflict Summary
+
+- **Total conflicted files**: 5
+- **Deleted-modified conflicts**: 1
+- **Generated files**: 1
+- **Regular conflicts**: 3
+
+### Resolution Strategy by File
+
+#### 1. `Cargo.lock`
+
+**Conflict Type**: generated
+**Strategy**: Regenerate from Cargo.toml after merge
+**Rationale**: Lock files should never be manually merged; regeneration ensures all dependencies are correctly resolved
+**Risk**: Low - Standard procedure for lock files
+**Action Items**:
+
+- [ ] Choose either version temporarily
+- [ ] Run `cargo update` to regenerate
+- [ ] Stage the regenerated file
+
+#### 2. `src/utils/helpers.rs` (deleted in incoming, modified in current)
+
+**Conflict Type**: deleted-modified
+**Strategy**: Backup modifications and apply to new location if applicable
+**Rationale**: File may have been moved/renamed; need to preserve modifications
+**Risk**: Medium - Requires analysis of where changes should go
+**Action Items**:
+
+- [ ] Run handle-deleted-modified script to create backup
+- [ ] Review analysis report for potential relocation targets
+- [ ] Apply modifications to new location if found
+
+#### 3. `src/lib.rs`
+
+**Conflict Type**: imports
+**Strategy**: Merge all unique imports from both branches
+**Rationale**: Both branches likely added new dependencies; combining ensures all code works
+**Risk**: Low - Standard import merge pattern
+**Action Items**:
+
+- [ ] Extract imports from both sides
+- [ ] Deduplicate and sort by module
+- [ ] Verify no unused imports
+
+#### 4. `tests/integration_test.rs`
+
+**Conflict Type**: tests
+**Strategy**: Include all test cases from both branches
+**Rationale**: Both branches added new test coverage; all tests should be preserved
+**Risk**: Low - Tests are additive
+**Action Items**:
+
+- [ ] Merge test functions from both branches
+- [ ] Combine test fixtures if needed
+- [ ] Ensure no duplicate test names
+
+#### 5. `src/config.rs`
+
+**Conflict Type**: code logic
+**Strategy**: Need user input - both branches modify validation logic differently
+**Rationale**: Cannot determine correct business logic from code alone
+**Risk**: High - Affects core validation behavior
+**Action Items**:
+
+- [ ] Present both approaches to user
+- [ ] Get user decision on which validation logic to use
+- [ ] Implement chosen approach
+
+### Execution Order
+
+1. **Phase 1: Deleted-Modified Files** - Handle helpers.rs backup and analysis
+2. **Phase 2: Generated Files** - Regenerate Cargo.lock
+3. **Phase 3: Low-Risk Merges** - Merge imports in lib.rs and tests in integration_test.rs
+4. **Phase 4: High-Risk Merges** - Resolve config.rs after user input
+5. **Phase 5: Validation** - Compile, test, verify
+
+### Questions/Decisions Needed
+
+- [ ] **src/config.rs**: Validation logic conflict - which approach should we use?
+  - Current branch: Validates using regex patterns
+  - Incoming branch: Validates using a validation library
+  - Options: (1) Keep current, (2) Keep incoming, (3) Use both with feature flag
+
+### Validation Steps
+
+- [ ] Run conflict validation script
+- [ ] Compile with `cargo check`
+- [ ] Run full test suite with `cargo test`
+- [ ] Manual verification of config.rs changes

package/skills/resolve-conflicts/scripts/handle-deleted-modified.sh

@@ -0,0 +1,183 @@
+#!/bin/bash
+# Handles deleted-but-modified file conflicts by creating backups and analyzing where changes should go
+# Usage: ./handle-deleted-modified.sh
+
+set -euo pipefail
+
+# Colors
+RED='\033[0;31m'
+GREEN='\033[0;32m'
+YELLOW='\033[1;33m'
+BLUE='\033[0;34m'
+NC='\033[0m'
+
+BACKUP_DIR=".git/conflict-backups/$(date +%Y%m%d-%H%M%S)"
+
+# Check if we're in a git repository
+if ! git rev-parse --git-dir > /dev/null 2>&1; then
+    echo -e "${RED}Error: Not a git repository${NC}" >&2
+    exit 1
+fi
+
+# Find files with delete/modify conflicts
+find_deleted_modified() {
+    git status --porcelain | grep -E '^(DU|UD|DD|UA|AU|AA)' || true
+}
+
+# Get the content from the branch that modified the file
+get_modified_content() {
+    local file="$1"
+    local status="$2"
+    
+    case "$status" in
+        DU) # Deleted by us, modified by them
+            git show ":3:$file" 2>/dev/null || echo ""
+            ;;
+        UD) # Deleted by them, modified by us
+            git show ":2:$file" 2>/dev/null || echo ""
+            ;;
+        *) 
+            echo ""
+            ;;
+    esac
+}
+
+# Main processing
+echo -e "${BLUE}🔍 Checking for deleted-but-modified files...${NC}"
+echo ""
+
+deleted_modified=$(find_deleted_modified)
+
+if [[ -z "$deleted_modified" ]]; then
+    echo -e "${GREEN}✓ No deleted-but-modified conflicts found${NC}"
+    exit 0
+fi
+
+# Create backup directory
+mkdir -p "$BACKUP_DIR"
+echo -e "${YELLOW}Creating backups in: $BACKUP_DIR${NC}"
+echo ""
+
+# Process each conflicted file
+while IFS= read -r line; do
+    status="${line:0:2}"
+    file="${line:3}"
+    
+    echo -e "${YELLOW}Processing: $file (status: $status)${NC}"
+    
+    # Get the modified content
+    content=$(get_modified_content "$file" "$status")
+    
+    if [[ -n "$content" ]]; then
+        # Create backup with directory structure
+        backup_file="$BACKUP_DIR/$file"
+        backup_dir=$(dirname "$backup_file")
+        mkdir -p "$backup_dir"
+        
+        echo "$content" > "$backup_file"
+        echo -e "  ${GREEN}✓${NC} Backed up to: $backup_file"
+        
+        # Try to find similar files (potential relocation targets)
+        filename=$(basename "$file")
+        base_name="${filename%.*}"
+        extension="${filename##*.}"
+        
+        echo -e "  ${BLUE}Searching for potential relocation targets...${NC}"
+        
+        # Search for files with similar names
+        similar_files=$(git ls-files | grep -i "$base_name" | grep -v "^$file$" || true)
+        
+        if [[ -n "$similar_files" ]]; then
+            echo -e "  ${YELLOW}⚠ Potential relocation targets:${NC}"
+            echo "$similar_files" | sed 's/^/    → /'
+        else
+            echo -e "  ${YELLOW}⚠ No obvious relocation target found${NC}"
+            echo -e "  ${YELLOW}⚠ Changes may need to be manually integrated${NC}"
+        fi
+        
+        # Create an analysis file
+        analysis_file="$BACKUP_DIR/$file.analysis.txt"
+        cat > "$analysis_file" << EOF
+File: $file
+Status: $status
+Conflict Type: $([ "$status" = "DU" ] && echo "Deleted by us, modified by them" || echo "Deleted by them, modified by us")
+
+Backed up to: $backup_file
+
+Potential Actions:
+1. If the file was renamed/moved: Apply changes to the new location
+2. If the file was deleted intentionally: Review if changes are still needed
+3. If the file was refactored: Distribute changes to new file structure
+
+Potential Relocation Targets:
+$similar_files
+
+To view the changes:
+  cat "$backup_file"
+
+To compare with similar files:
+$(echo "$similar_files" | while read -r sf; do echo "  diff \"$backup_file\" \"$sf\""; done)
+EOF
+        
+        echo -e "  ${GREEN}✓${NC} Analysis saved to: $analysis_file"
+    else
+        echo -e "  ${RED}✗${NC} Could not retrieve content"
+    fi
+    
+    # Resolve by removing (user must manually apply changes)
+    if [[ "$status" == "DU" ]]; then
+        git rm "$file" 2>/dev/null || true
+        echo -e "  ${GREEN}✓${NC} Marked as deleted (ours)"
+    elif [[ "$status" == "UD" ]]; then
+        git add "$file" 2>/dev/null || git rm "$file" 2>/dev/null || true
+        echo -e "  ${GREEN}✓${NC} Resolved conflict"
+    fi
+    
+    echo ""
+done <<< "$deleted_modified"
+
+# Create a summary file
+summary_file="$BACKUP_DIR/SUMMARY.md"
+cat > "$summary_file" << EOF
+# Conflict Resolution Summary
+
+Generated: $(date)
+
+## Deleted-Modified Files Processed
+
+$(echo "$deleted_modified" | while IFS= read -r line; do
+    status="${line:0:2}"
+    file="${line:3}"
+    echo "- **$file** (status: $status)"
+done)
+
+## Next Steps
+
+1. Review each backup file in this directory
+2. Identify where the changes should be applied
+3. Manually integrate the changes into the appropriate files
+4. Run tests to validate the integration
+5. Commit the resolved changes
+
+## Files Structure
+
+$(find "$BACKUP_DIR" -type f -name "*.analysis.txt" | while read -r f; do
+    file=$(basename "$f" .analysis.txt)
+    echo "- \`$file\`"
+    echo "  - Backup: \`$file\`"
+    echo "  - Analysis: \`$file.analysis.txt\`"
+done)
+
+EOF
+
+echo -e "${GREEN}✓ Summary created: $summary_file${NC}"
+echo ""
+echo -e "${BLUE}═══════════════════════════════════════════════════════${NC}"
+echo -e "${GREEN}✓ All deleted-but-modified files backed up successfully${NC}"
+echo -e "${BLUE}═══════════════════════════════════════════════════════${NC}"
+echo ""
+echo "Next steps:"
+echo "  1. Review backups: ls -la $BACKUP_DIR"
+echo "  2. Read summary: cat $summary_file"
+echo "  3. Integrate changes manually into appropriate files"
+echo "  4. Run validation: .forge/skills/resolve-conflicts/scripts/validate-conflicts.sh"