Kayba Stage 7 Fixer

Stage 7: Fix Implementation

Implement every non-discarded fix from the approved action plan.

Inputs

• eval/action_plan.md -- the approved action plan from Stage 5 (possibly modified during HITL in Stage 6)
• eval/stage6_decision.md -- if it exists, the HITL decision record from Stage 6 (contains user modifications)
• eval/baseline_metrics.json -- the pre-fix baseline metrics from Stage 3 (for reference in changes log)

Read the action plan and stage6 decision (if present) before starting.

Pre-flight: Git Safety Checkpoint

Before making ANY changes to source files:

1. Run git status to confirm the working tree state
2. Create a safety commit or stash:

   git stash push -m "pre-pipeline-fixes-$(date +%Y%m%d-%H%M%S)"

   If there are no uncommitted changes to stash, create a lightweight tag instead:

   git tag pre-pipeline-fixes-$(date +%Y%m%d-%H%M%S)

3. Record the stash ref or tag name in eval/changes_log.md under a "Rollback" section so the user can restore if needed

This ensures every fix is reversible with a single git stash pop or git checkout.

Pre-flight: HITL Modification Check

If eval/stage6_decision.md exists:

1. Read it and identify any items the user modified, added, or re-prioritized during Stage 6
2. Build a set of HITL_MODIFIED_IDS -- the insight/skill IDs that the user changed
3. When logging each fix later, tag modified items with [HITL-MODIFIED] in the changes log so reviewers know which fixes reflect user judgment vs. the original pipeline output

If the file does not exist, assume no HITL modifications were made.

Pre-flight: Conflict Scan

Before implementing any fixes, scan the action plan for potential conflicts:

1. Build a map of file_path -> [fix IDs that touch it]
2. If two or more fixes modify the same file, flag them as co-located
3. If two or more fixes modify the same section (within ~20 lines of each other), flag them as overlapping
4. For overlapping fixes: plan to apply them sequentially in priority order, re-reading the file between each edit to ensure the second fix still makes sense on top of the first
5. Log any detected conflicts at the top of eval/changes_log.md under a "Conflict Notes" section

Process

Work through the action plan in priority order. For each non-discarded fix:

1. Understand the fix

• Read the recommendation carefully
• Read the referenced files in the codebase
• Understand the surrounding code before making changes
• Check if this fix was flagged as co-located or overlapping in the conflict scan. If overlapping with a previously-applied fix, re-read the target file to see the current state after prior edits

2. Implement the change

For code fixes:

• Find the relevant files
• Make the minimal, targeted change described in the recommendation
• Do not refactor surrounding code unless the fix obviously breaks without light adjacent cleanup (e.g., an import is missing, a variable was renamed). If you make adjacent cleanup, log it explicitly as "adjacent cleanup" in the change entry
• Do not add features beyond what was recommended

For prompt fixes:

• Find the system prompt file (use domain context from Stage 2 if needed)
• Add the recommended instruction at the appropriate location
• Do not rewrite existing prompt text unless the recommendation explicitly says to