# Enhanced Fix Build Command Suggestions with TDD Methodology Enforcement

## Current Implementation
✅ **Created**: `/fix-build` command that triggers the comprehensive TDD methodology-compliant build fixing process.

## TDD Methodology Integration Requirements

### 🚨 MANDATORY PRE-TRIAGE PHASE - NO EXCEPTIONS 🚨

**CRITICAL REQUIREMENT**: ALL build fix commands MUST execute comprehensive context evaluation BEFORE any development starts.

**📋 RULE COMPLIANCE REQUIREMENTS**:
This shortcut MUST comply with existing kubernaut rules:
- **Rule 00-core-development-methodology**: TDD RED-GREEN-REFACTOR sequence mandatory
- **Rule 01-business-code-integration**: All business code must integrate with main applications
- **Rule 02-technical-implementation**: Go patterns and system architecture compliance
- **Rule 03-testing-strategy**: Defense-in-depth testing pyramid approach
- **Rule 05-kubernetes-safety**: Kubernetes operations safety patterns
- **Rule 09-interface-method-validation**: Interface validation before code generation
- **Rule 12-ai-ml-development-methodology**: AI/ML TDD workflow integration
- **Always-Applied Rules**: AI Assistant Behavioral Constraints for TDD Enforcement

**⛔ FORBIDDEN ACTIONS (RULE VIOLATIONS)**:
- NO code generation without complete triage (violates Always-Applied Rules)
- NO implementation without user approval post-triage (violates Always-Applied Rules)
- NO bypassing for "simple" or "obvious" fixes (violates Always-Applied Rules)
- NO emergency exceptions to triage requirements (violates Always-Applied Rules)
- NO assumptions about problem scope without analysis (violates Always-Applied Rules)
- NO struct field references without type definition validation (violates Always-Applied Rules)
- NO business code without main application integration (violates Rule 01)
- NO TDD sequence violations (violates Rule 00)
- NO interface usage without validation (violates Rule 09)

**✅ MANDATORY EXECUTION ORDER (RULE-COMPLIANT)**:
All build fix commands MUST execute comprehensive context evaluation BEFORE any development starts:

1. **Problem Context Analysis**
   - Identify root cause: compilation errors, undefined symbols, import cycles
   - Assess impact scope: single file, package, or system-wide
   - Evaluate business requirement alignment (BR-XXX-XXX mapping)

2. **TDD Phase Impact Assessment**
   - **RED Phase Impact**: Will fixes affect failing tests?
   - **GREEN Phase Impact**: Will fixes require new implementation?
   - **REFACTOR Phase Impact**: Will fixes require existing code enhancement?

3. **Refactoring Consideration Matrix**
   - **Existing Tests**: Which tests need modification/enhancement?
   - **Implementation Files**: Which business logic requires refactoring?
   - **Integration Points**: How do changes affect main application integration?
   - **Dependency Chain**: What cascade effects will occur?

4. **TDD Compliance Validation**
   - Verify current development phase (Discovery/RED/GREEN/REFACTOR)
   - Ensure fixes align with mandatory TDD sequence
   - Validate business code integration requirements

### 🔒 TRIAGE ENFORCEMENT PROTOCOL

**BLOCKING REQUIREMENTS**:
- AI MUST execute complete triage analysis before ANY code generation
- AI MUST create detailed action plan based on triage findings
- AI MUST present action plan and wait for explicit user approval
- AI MUST refuse to proceed without completed triage AND approved action plan
- AI MUST validate TDD methodology compliance at each step

**MANDATORY ACTION PLAN FORMAT**:
```
🚨 TRIAGE ANALYSIS COMPLETE - ACTION PLAN REQUIRED

**PROBLEM ANALYSIS**:
- Root Cause: [specific issue identified]
- Impact Scope: [file/package/system level]
- Business Requirement: [BR-XXX-XXX alignment]

**RULE COMPLIANCE VALIDATION**:
- Rule 00 (TDD Methodology): [current phase compliance status]
- Rule 01 (Business Integration): [main app integration verification]
- Rule 02 (Technical Implementation): [Go patterns compliance]
- Rule 03 (Testing Strategy): [pyramid approach alignment]
- Rule 09 (Interface Validation): [interface validation requirements]
- Always-Applied Rules: [behavioral constraints compliance]
- Potential Rule Violations: [identified risks and mitigation]

**TDD PHASE ASSESSMENT**:
- Current Phase: [Discovery/RED/GREEN/REFACTOR]
- Phase Impact: [how fixes affect current phase]
- Required Phase Actions: [specific TDD steps needed]
- Phase Transition Requirements: [what's needed to advance phases]

**REFACTORING IMPACT MATRIX**:
- Tests Affected: [list of test files requiring changes]
- Implementation Files: [list of business logic files to modify]
- Integration Points: [main app integration impacts]
- Dependency Chain: [cascade effects identified]
- Type Definition Validation: [struct field references to verify]

**PROPOSED ACTION PLAN (RULE-COMPLIANT)**:
1. [Specific action with TDD phase alignment + rule compliance]
2. [Specific action with refactoring consideration + integration validation]
3. [Specific action with interface validation + type safety checks]
...

**RULE VIOLATION PREVENTION**:
- Checkpoints: [specific validation points to prevent rule violations]
- Validation Tools: [scripts/commands to run for compliance verification]
- Integration Verification: [main app usage confirmation steps]

**RISK ASSESSMENT**:
- High Risk: [potential breaking changes + rule violations]
- Medium Risk: [integration concerns + methodology compliance]
- Low Risk: [minimal impact changes with full rule compliance]

**APPROVAL REQUIRED**: Do you approve this rule-compliant action plan? (YES/NO)
```

**VIOLATION RESPONSE**:
- IMMEDIATE HALT if triage is bypassed or incomplete
- IMMEDIATE HALT if action plan is not presented for approval
- MANDATORY restart with complete triage analysis and action plan
- NO exceptions for time pressure or perceived simplicity
- ESCALATION required if user requests triage bypass

**VALIDATION CHECKPOINTS (RULE-COMPLIANT)**:
- ✅ Problem context analysis completed
- ✅ TDD phase impact assessment completed
- ✅ Refactoring consideration matrix completed
- ✅ Rule compliance validation completed for ALL applicable rules
- ✅ Type definition validation completed (Always-Applied Rules)
- ✅ Business integration verification completed (Rule 01)
- ✅ Interface validation requirements assessed (Rule 09)
- ✅ TDD methodology compliance validated (Rule 00)
- ✅ Detailed rule-compliant action plan created and presented
- ✅ User approval received for specific action plan
- ✅ NO CODE CHANGES until explicit approval received
- ✅ Rule violation prevention measures identified

**FAILURE CONDITIONS (RULE VIOLATIONS)**:
- ❌ Any attempt to skip triage analysis (violates Always-Applied Rules)
- ❌ Any attempt to skip action plan creation (violates Always-Applied Rules)
- ❌ Implementation without user approval of action plan (violates Always-Applied Rules)
- ❌ Assumptions about problem scope without validation (violates Always-Applied Rules)
- ❌ Emergency bypass requests (violates Always-Applied Rules - NO EXCEPTIONS)
- ❌ Code changes before action plan approval (violates Always-Applied Rules)
- ❌ Struct field references without type validation (violates Always-Applied Rules)
- ❌ Business code without main app integration (violates Rule 01)
- ❌ TDD sequence violations (violates Rule 00)
- ❌ Interface usage without validation (violates Rule 09)
- ❌ Any rule compliance bypass attempts

## Streamlined Build Fix Commands - CLARITY & EFFECTIVENESS OPTIMIZED

#### Smart Build Fix - Universal Solution
```json
{
    "name": "Smart Build Fix",
    "trigger": "/fix-build",
    "description": "Universal TDD-compliant build fix with intelligent context detection",
    "command": "SMART BUILD FIX - UNIVERSAL SOLUTION:\n\n**🚨 MANDATORY PRE-TRIAGE (ALWAYS REQUIRED)**\n1. **Intelligent Context Detection**:\n   - Auto-detect: File type (test/main/component), severity, scope\n   - Root cause identification (compilation, undefined symbols, imports)\n   - Impact scope assessment (file/package/system-wide)\n   - Business requirement alignment validation (BR-XXX-XXX)\n\n2. **TDD Phase Impact Assessment**:\n   - Current phase verification (Discovery/RED/GREEN/REFACTOR)\n   - Phase-specific impact analysis and requirements\n   - Required phase actions and transition needs\n\n3. **Rule Compliance Validation**:\n   - All applicable kubernaut rules (00,01,02,03,09,12,Always-Applied)\n   - Type definition validation, interface validation\n   - Business integration verification\n\n4. **Refactoring Impact Matrix**:\n   - Tests affected, implementation files, integration points\n   - Dependency chain cascade effects\n\n**📋 ACTION PLAN CREATION (MANDATORY)**\n- Detailed rule-compliant action plan with specific steps\n- Risk assessment and violation prevention measures\n- User approval required before ANY code changes\n\n**⚡ INTELLIGENT EXECUTION (POST-APPROVAL)**\n- Context-appropriate strategy (quick/comprehensive/staged)\n- Continuous rule validation with CHECKPOINT A/B/C/D\n- Integration verification and confidence assessment\n\n**UNIVERSAL**: Handles ALL build scenarios - simple to complex, test to main, single file to system-wide.",
    "category": "debugging",
    "tags": ["build", "error", "universal", "smart", "tdd", "rule-compliant"]
}
```

### **SPECIALIZED COMMANDS - Advanced Control**

#### Progressive Staged Build Fix
```json
{
    "name": "Staged Build Fix",
    "trigger": "/fix-build-staged",
    "description": "Progressive build fix with user control at each stage",
    "command": "STAGED BUILD FIX - PROGRESSIVE CONTROL:\n\n**PRE-STAGE: COMPREHENSIVE TRIAGE & PLANNING**\n- Complete context analysis and rule compliance validation\n- CREATE DETAILED MULTI-STAGE ACTION PLAN\n- PRESENT PLAN for user approval - NO execution until approved\n\n**STAGE 1: VALIDATION & QUICK WINS**\n- TDD compliance verification and obvious fixes\n- CHECKPOINT: User approval before Stage 2\n\n**STAGE 2: PHASE-APPROPRIATE RESOLUTION**\n- Execute phase-specific actions (RED/GREEN/REFACTOR)\n- CHECKPOINT: User approval before Stage 3\n\n**STAGE 3: REFACTORING & INTEGRATION**\n- Implementation enhancements and integration validation\n- CHECKPOINT: User approval before Stage 4\n\n**STAGE 4: FINAL VALIDATION & COMPLIANCE**\n- Complete integration verification and confidence assessment\n\n**CONTROL**: Full user control with approval required between each stage.",
    "category": "debugging",
    "tags": ["build", "error", "staged", "progressive", "user-control"]
}
```

#### Preventive Build Analysis
```json
{
    "name": "Preventive Build Check",
    "trigger": "/check-build",
    "description": "Proactive build health analysis without fixes",
    "command": "PREVENTIVE BUILD HEALTH CHECK:\n\n**ANALYSIS-ONLY MODE** (No code changes):\n1. **Comprehensive Health Scan**:\n   - Lint analysis and potential undefined symbols\n   - Import/dependency validation\n   - Rule compliance assessment\n   - Integration verification\n\n2. **Risk Assessment**:\n   - Potential cascade failure points\n   - TDD methodology compliance gaps\n   - Business integration weaknesses\n\n3. **Preventive Recommendations**:\n   - Suggested improvements with priority levels\n   - Rule violation prevention measures\n   - Proactive maintenance actions\n\n**PURPOSE**: Catch issues before they become build failures.",
    "category": "maintenance",
    "tags": ["build", "check", "preventive", "analysis", "health"]
}
```

## Implementation Recommendations

### A. **Most Valuable Additions (ALL WITH MANDATORY TRIAGE)**
1. **`/fix-build-quick`** - Fast fixes with MANDATORY triage phase
2. **`/smart-fix`** - Context-aware strategy with MANDATORY pre-analysis
3. **`/fix-my-build`** - Natural language with MANDATORY methodology compliance
4. **`/fix-build-staged`** - Progressive control with MANDATORY triage at each stage

### B. **Natural Usage Patterns (TRIAGE ALWAYS REQUIRED)**
- Use conversational triggers (`/fix-my-build`, `/build-broken`) - TRIAGE MANDATORY
- Provide severity options (`/fix-build-critical`) - NO emergency triage bypass
- Allow component focus (`/fix-build-component`) - TRIAGE for component scope
- Enable progressive fixing (`/fix-build-staged`) - TRIAGE at each stage

### C. **Enhanced User Experience (WITH METHODOLOGY ENFORCEMENT)**
1. **Context Detection**: Automatically determine strategy AFTER mandatory triage
2. **Progressive Disclosure**: Start with triage, add complexity based on findings
3. **Natural Language**: Use conversational triggers with MANDATORY analysis
4. **NO Escape Hatches**: NO quick options that bypass triage requirements
5. **Staged Approach**: User controls complexity AFTER triage completion

### D. **Backward Compatibility (ENHANCED ENFORCEMENT)**
- Keep original `/fix-build` as the comprehensive option with MANDATORY triage
- Add variants that complement with IDENTICAL triage requirements
- STRENGTHEN methodology compliance across ALL variants
- ENHANCE safety and validation requirements - NO bypassing allowed

### E. **CRITICAL ENFORCEMENT REQUIREMENTS**
- **ALL COMMANDS**: Must execute complete triage AND create action plan before implementation
- **NO EXCEPTIONS**: Emergency, critical, or quick variants still require triage AND action plan
- **MANDATORY ACTION PLAN**: Detailed plan with specific steps required after triage
- **USER APPROVAL**: Required for action plan before ANY code changes
- **NO CODE WITHOUT APPROVAL**: Absolutely no implementation without explicit action plan approval
- **METHODOLOGY COMPLIANCE**: TDD sequence validation mandatory for all fixes
- **REFACTORING AWARENESS**: Impact analysis and action plan required for all changes
- **CHECKPOINT VALIDATION**: Each major step requires user approval before proceeding

## Usage Examples

```bash
# Quick fix for simple issues
/fix-build-quick

# Natural language
/fix-my-build

# Emergency mode
/fix-build-critical

# Smart context-aware
/smart-fix

# Progressive control
/fix-build-staged

# Component-focused
/fix-build-component pkg/workflow/engine

# Test-specific
/fix-test-build

# Investigation + fixing
/investigate-fix-build
```

This approach provides multiple entry points while maintaining the rigorous methodology compliance that's essential for the kubernaut project.

## Rule Compliance Summary

### 📋 **MANDATORY RULE ADHERENCE**

All build fix shortcuts MUST comply with existing kubernaut rules to prevent violations:

#### **Always-Applied Rules Compliance**:
- ✅ **AI Assistant Behavioral Constraints**: Complete triage analysis before ANY code generation
- ✅ **CHECKPOINT A**: Type reference validation before struct field access
- ✅ **CHECKPOINT B**: Test creation validation with existing implementation search
- ✅ **CHECKPOINT C**: Business integration validation for new components
- ✅ **CHECKPOINT D**: Build error investigation with comprehensive symbol analysis

#### **Core Rule Integration**:
- ✅ **Rule 00**: TDD RED-GREEN-REFACTOR sequence enforcement
- ✅ **Rule 01**: Business code integration with main applications mandatory
- ✅ **Rule 02**: Go patterns and technical implementation compliance
- ✅ **Rule 03**: Defense-in-depth testing strategy alignment
- ✅ **Rule 09**: Interface and method validation before code generation
- ✅ **Rule 12**: AI/ML development methodology integration

#### **Validation Tools Integration**:
```bash
# Rule compliance validation commands
./scripts/validate-tdd-checkpoints.sh [component] [phase]
./scripts/ai-assistant-gate.sh
./scripts/run-integration-validation.sh
```

#### **Rule Violation Prevention**:
- **Pre-execution**: Complete rule compliance validation in triage phase
- **During execution**: Continuous checkpoint validation
- **Post-execution**: Integration and compliance verification
- **Emergency protocols**: NO rule bypassing allowed under any circumstances

### 🚨 **CRITICAL SUCCESS FACTORS**

1. **NO SHORTCUTS**: Every build fix must follow complete methodology
2. **RULE INTEGRATION**: All existing rules apply to shortcut execution
3. **VALIDATION MANDATORY**: Compliance verification at each step
4. **USER APPROVAL**: Required for action plans that ensure rule compliance
5. **CONTINUOUS MONITORING**: Rule adherence throughout execution process

This ensures that build fix shortcuts enhance productivity while maintaining the strict quality and methodology standards established by the kubernaut project rules.
