checkpointed-agent-looplisted

# Checkpointed Agent Loop ## Purpose Use a durable checkpoint when work may span sessions, be interrupted, require bounded retries, or need proof that verification actually ran. The checkpoint stores task state, a next action, attempt count, sanitized reasons, and verification evidence. It does not execute commands, call models, spawn Agents, access secrets, or contact a network service; WorkBuddy remains responsible for each tool call and policy decision. Do not use this for a one-line edit or a workflow that already has its own durable runner. A checkpoint is recovery state, not a license to loop forever or bypass approval. ## State machine Only these states and transitions are valid: ```text planned -> running running -> verifying | failed | blocked verifying -> succeeded | running | failed | blocked ``` Entering `running` consumes one attempt. A finite positive `max_attempts` cannot be exceeded. `succeeded`, `failed`, and `blocked` are terminal; terminal state cannot be edited. `succeeded` is rejected unless at least one `passed` evidence record was added while in `verifying`. ## Initialize safely Choose a project-local checkpoint path excluded from application commits, such as `.agent/checkpoints/task.json`. Verify the directory and ignore policy before use. Keep objectives, reasons, check names, and artifact paths free of API keys, tokens, passwords, PII, and raw secret-bearing logs. ```bash python3 <skill-dir>/scripts/checkpoint-loop.py init \ --file .agent