Documentation/Bushido/Bushido/ skills /baseline-restorer

📖 baseline-restorer

Use when multiple fix attempts fail and you need to systematically restore to a working baseline and reimplement instead of fixing broken code.



Overview

Enforces methodical problem-solving by reverting to last known working state and reimplementing step-by-step instead of trying to fix accumulated broken changes.

Core Philosophy

Reimplement, don't fix the mess

When something breaks after multiple failed fix attempts:

  1. Stop trying to fix forward
  2. Revert to last known working state
  3. Understand what worked and why
  4. Reimplement the needed change ONE step at a time
  5. Verify each step before proceeding

When to Use This Skill

Trigger conditions

  • 2+ failed fix attempts for the same issue
  • "This should work but doesn't" situations
  • Pipeline failures persisting across multiple commits
  • User says "the old version worked fine"
  • Complex accumulated changes with unclear impact

Red flags requiring this skill

  • Making assumptions about root cause without verification
  • Blaming "pre-existing issues"
  • Adding more changes to fix previous changes
  • Not testing locally before committing

Systematic Process

Phase 1: Identify Working Baseline

# Find last known working state
git log --oneline -20
git show origin/beta:path/to/file.sh  # Check beta/main branch
git diff origin/beta -- path/to/file.sh  # What changed?

# Verify baseline works
git stash
git checkout origin/beta -- path/to/file.sh
# Test it - does it work?

Questions to answer

  • What was the last commit where this worked?
  • What branch has a working version? (beta, main, prod)
  • What specific files/scripts were working?

Phase 2: Compare Current vs Baseline

# Get exact differences
git diff baseline..current -- path/to/file.sh

# Understand each change
# For EACH diff hunk, ask:
# - Why was this changed?
# - What problem was it trying to solve?
# - Did it actually solve that problem?

Document findings

  • List every change made
  • Note which changes were necessary
  • Note which changes broke things
  • Identify assumptions that were wrong

Phase 3: Revert to Baseline

# Hard revert to working state
git checkout origin/beta -- path/to/file.sh
git add path/to/file.sh
git commit -m "Revert to working baseline from beta"

# Verify baseline works
./test-locally.sh
# Must pass before proceeding

Critical: Don't proceed until baseline is verified working.

Phase 4: Reimplement ONE Change at a Time

For each needed change

  1. Make ONE small change

    # Example: Replace sed with awk in ONE function
    # Don't change 5 things at once
    
  2. Test locally immediately

    ./run-generation-script.sh
    terraform validate
    # Must pass before committing
    
  3. Commit if working

    git add changed-file.sh
    git commit -m "Replace sed with awk in function X"
    
  4. If it breaks, revert immediately

    git reset --hard HEAD~1
    # Try different approach or understand why it broke
    
  5. Repeat for next change

Phase 5: Verify Complete Solution

# Run full test suite
make test
terraform validate

# Compare with original broken state
# Did we achieve the goal without breaking things?

# Push only after local verification
git push

Verification Checklist

Before committing ANY change:

  • Tested locally and passes
  • Compared output with baseline (no unexpected differences)
  • Understood why this change is needed
  • Change is minimal and focused
  • Can explain what would break if this change was wrong

Anti-Patterns to Avoid

DON'T

  • ❌ "Let me try one more fix" (revert instead)
  • ❌ "This is probably a pre-existing issue" (verify with baseline)
  • ❌ "The logic should work" (test it, don't assume)
  • ❌ Change 5 things and hope one fixes it
  • ❌ Commit without local verification
  • ❌ Blame the user's code/environment

DO

  • ✅ "Let me check what worked in beta"
  • ✅ "Reverting to baseline first"
  • ✅ "Testing this one change locally"
  • ✅ Make ONE change, verify, commit
  • ✅ Test before every commit
  • ✅ Take responsibility for breakage

Examples

Example 1: Terraform Generation Scripts

Broken approach (Example 1)

# Made 10 changes trying to "optimize" variable filtering
# Each fix broke something new
# Spent day+ debugging

Baseline approach (Example 1)

# Check beta branch - does it work?
git show origin/beta:terraform/build-module.sh > /tmp/beta-version.sh
bash /tmp/beta-version.sh  # Verify it works

# Revert to beta version
git checkout origin/beta -- terraform/build-module.sh

# Now reimplement ONLY what's needed (e.g., sed→awk for portability)
# One function at a time, test each change

Example 2: Pipeline Failures

Broken approach (Example 2)

# Assume it's a CI environment issue
# Try 5 different "fixes" based on guesses
# Each creates new errors

Baseline approach (Example 2)

# Find last passing pipeline
git log --oneline | head -20
# Check what changed since then
git diff <last-passing-commit>

# Revert suspicious changes
# Test locally before pushing

Commands

# Find working baseline
git log --oneline --all | grep "known working feature"
git show origin/beta:path/to/file

# Compare with baseline
git diff origin/beta -- path/to/file
git diff <working-commit> -- path/to/file

# Revert to baseline
git checkout origin/beta -- path/to/file
git checkout <working-commit> -- path/to/file

# Test locally
terraform validate
mix test
yarn test

# Verify no changes after running script
git diff  # Should be empty if script is idempotent

Remember

  • Reimplement, don't fix - Start from working state
  • One change at a time - Test each change immediately
  • Local verification first - Never commit untested changes
  • Baseline is truth - If baseline works, your changes broke it
  • Stop digging - After 2 failed fixes, revert and rethink
  • Question assumptions - Verify, don't assume
  • Take responsibility - Your changes, your bugs