[FEATURE] Run progression checkpoints for interruption recovery

[koydas]

🎯 Goal

Allow interrupted runs to resume safely from their last valid state without restarting from scratch.

📍 Context

• Repo: autonomous-dev-loop
• Domain: Execution continuity
• Component: scripts/auto_fix_pr.mjs, .github/workflows/code-generation.yml

🚀 Description

Run state is currently tracked implicitly via PR labels (auto-fix-attempt-N). This is a good foundation but has two gaps:

1. If the label API call fails after the AI work is done, the checkpoint is not saved — the attempt counter is wrong on the next run and the work may be repeated.
2. code-generation.yml has no checkpoint mechanism at all — a runner cancellation restarts the full LLM generation from scratch.

The fix is a minimal explicit checkpoint written atomically before declaring each step complete.

🧩 Scope

In:

• Checkpoint format (JSON, written to GITHUB_STEP_SUMMARY or a temp artifact):

  {
    "runId": "<github.run_id>",
    "step": "ai-complete | label-applied | comment-posted",
    "attempt": 2,
    "inputHash": "<sha256 of issue number + commit SHA>",
    "timestamp": "<ISO 8601>"
  }

• Write checkpoint immediately after each irreversible step (AI call done, label applied, comment posted).
• On startup, load checkpoint if present; resume from step only if inputHash matches current inputs.
• Invalidate (delete) checkpoint when inputHash changes (new commit pushed, different issue).
• Apply to auto_fix_pr.mjs first (highest risk of partial failure); code-generation.yml as Phase 2.

Out:

• Long-term persistence beyond the current run context (no external DB or cache).
• Cross-run shared state.

🧪 Acceptance criteria

• Functional

  • After a simulated interruption between the AI call and the label step, re-running the script skips the AI call and resumes from the label step.
  • The final output (labels, comments, files) is identical whether the run completed in one pass or resumed from checkpoint.

• Edge cases

  • If inputHash in checkpoint does not match current inputs, the checkpoint is ignored and the run starts fresh.
  • A checkpoint with an unrecognised step value is treated as invalid and discarded (no crash).
  • A missing or malformed checkpoint file is silently ignored — run starts from step 1.
  • If checkpoint write fails (disk full, permission error), the run continues without checkpointing and logs a warning; it does not abort.

• Tests

  • Unit: loading a checkpoint with matching inputHash returns the correct step.
  • Unit: loading a checkpoint with mismatched inputHash returns null (start fresh).
  • Unit: a checkpoint file with invalid JSON is caught and returns null.
  • Smoke: full run interrupted after step 1 and resumed — AI call invoked exactly once total across both executions.

⚙️ Constraints

• No additional infrastructure or runtime dependencies.
• Checkpoint file must be written atomically (write to .tmp, then rename).
• Keep MVP-simple: 3 steps max (ai-complete, label-applied, done).

[github-actions]

✅ Issue Validation Report

Field	Value
Status	VALID — ready for development
Score	100/100 [██████████]

⚠️ Warnings (optional improvements)

• W1: Missing technical context — no reference to existing implementation details in auto_fix_pr.mjs or code-generation.yml that would affect checkpoint integration

💡 Suggested Acceptance Criteria

Copy the block below and paste it into the issue description, then save. Saving will re-trigger validation automatically.

## Acceptance Criteria

- [ ] Given a checkpoint file with step 'ai-complete' and matching inputHash, when the script restarts, it skips the AI call and proceeds to the label step
- [ ] When a checkpoint file contains invalid JSON, the system returns null from the checkpoint loader without throwing an exception
- [ ] A full run interrupted after step 1 (AI call) and resumed must produce identical final output to a single uninterrupted run
- [ ] When checkpoint write fails during label application, the script logs a warning and continues execution without checkpointing
- [ ] The checkpoint file is atomically written using a .tmp file and rename operation, verified by inspecting the file system state