What is the right safety layer for Ralph-style AI coding loops?

[Keesan12]

Ralph-style loops are useful because they let AI coding agents keep working until a task is complete.

The failure mode is that unattended loops can keep spending, retrying, mutating files, or drifting from the original task without a clean stop condition.

MartinLoop is trying to define the governance layer around that pattern:

• hard budget caps
• max iteration limits
• verifier gates
• rollback evidence
• explicit stop reasons
• JSONL run records

Question for people running Claude Code, Codex, OpenCode, Goose, Aider, or Ralph-style loops:

What should a safe autonomous coding loop record before it is trusted?

[Keesan12]

My current answer is that a safe autonomous coding loop should record enough information to answer four questions after the fact:

1. What was the contract?
2. What actually happened?
3. Why did the loop stop?
4. What evidence is left behind?

In practice that means I want at least:

• objective, verifier plan, repo root, and budget envelope
• attempt-by-attempt lifecycle events
• final lifecycle state plus a human-readable stop reason
• verifier outcomes, not just agent output
• policy or scope interventions when they happen
• a persisted record that can be inspected later without relying on terminal memory

That is the shape MartinLoop is converging on right now: budgets, verifier gates, explicit stop reasons, rollback evidence for repo-backed runs, and JSONL run records under ~/.martin/runs/.

The new examples/docs in flight are meant to make that concrete from a few angles:

• Claude Code walkthrough
• OpenCode-style adapter example
• Ralph-style loop safety guide
• GitHub Actions budget gate example

If anyone is already running autonomous coding loops, I would still love sharper feedback on which missing record hurts the most in practice: cost provenance, verifier history, scope boundaries, rollback evidence, or something else.