The Ralph-loop safety checklist, version 1

An autonomous coding loop is among the cheapest dangerous things a developer can start: a line of shell, a standing prompt, and a machine content to work through the night. The five minutes before that line runs are the only minutes in which every decision is still free — once the first pass is away, the same decisions come back wearing incident numbers. This page is a gate for those five minutes: fifteen checks holding permanent identifiers RLS-1 through RLS-15, grouped into five gates — bounds, secrets, isolation, stop conditions, evidence — three items each. This page is version 1, carrying an evidence date of 2026-08-29; the versioning rules at the end are what make these identifiers safe to print in a runbook.

The checklist is deliberately pre-launch. It does not diagnose a run that has already gone sideways — that catalog exists elsewhere on this site — and it does not teach the changes that make a raw loop pass these checks; both neighbors are linked exactly where a gate needs them. What it decides is the only question that exists at the start button: may this run begin? The technique itself — its history, and which variant of it you are about to run — is settled in the Ralph loop reference; this page assumes you know, and are about to press enter.

The admission rule

A checklist grows fat by sympathy: every failure anyone ever suffered asks for a line, until the list is too long to run — and a list too long to run protects no one. Version 1 refuses that drift with an admission rule, and an item earns a line only when it passes all three tests. It must be checkable before launch — verifiable now, as a fact about your setup, never a prediction about how the run will behave. It must resolve to an observation — the output of a command, a written number, a permission, a named file — never to a feeling or an intention. And its failure must stop the launch, because an item whose miss you would wave through is decoration, and decoration is cut.

Two scoring semantics keep the gate honest. Unknown is a fail: an item you cannot check is not passed, and "probably" clears nothing. And every item is phrased so a second operator could check it without asking what you meant — if running the check requires your intuition, the item is measuring you rather than the setup.

Gate 1: Bounds — what the run may spend

Spend goes unnumbered by default, and a loop that can buy passes indefinitely will. Three items put the numbers in writing.

RLS-1 — Both iteration ceilings are numeric, finite, and written where the loop starts. One ceiling bounds a single pass; the other bounds the whole run. In YYLO the committed default already caps an agent invocation at one iteration, and the driver script takes an outer pass ceiling as a flag with an environment fallback — hitting it exits normally with the count recorded, not as an error. Check: read both numbers out of the launch command itself. A ceiling that lives in somebody's head does not exist.
RLS-2 — A human reads the evidence at a scheduled time, fixed before launch. The interval during which the loop runs unattended is chosen on a calendar, not discovered from a bill. Check: name the person, and the clock time at which they will open what the run has produced.
RLS-3 — The first pass's job is one item, and its finish line is named. A pass handed "make things better" cannot be audited; a pass handed one named item with a declared done-state can. The ecosystem's loop skill makes the same move by binding each pass to exactly one assigned task whose finish is a validated, queued commit. Check: point at the item the first pass will attempt, and name the evidence that will show it closed.

Gate 2: Secrets — what the run may read, and who steers it

A loop re-reads its steering surfaces on every pass, and that makes whoever can write one of them a standing co-author of the run. Three items bound the inputs.

RLS-4 — Every steering file is named, and each has exactly one accountable writer. The prompt file, the plan or task records the worker reads, project instruction files, provisioned skill directories — each is a standing instruction channel that the run trusts afresh every pass. Check: the enumeration exists in writing, and for each entry you can say who is allowed to change it. An unnamed channel is an unreviewed co-author.
RLS-5 — Credentials live in scoped environment variables, and the steering files are grepped clean. Recorded task text endures: any body or response can re-enter later runs as memory, so a secret written into one outlives the run that wanted it. The product's own rule keeps secrets in the project environment file, loaded at startup and inherited by hooks and worker processes. Check: search every steering file for token shapes; any hit fails this item.
RLS-6 — Every command whose output enters a prompt is reviewed like code. Substitutions run inside your login environment, credentials and all, which is why a prompt that runs env is exfiltration wearing a helper's clothes. YYLO bounds the crossing — a substitution dies after thirty seconds by default, runs with no terminal input attached, and contributes its standard output only — but a bound makes a command bounded, not trustworthy. Check: every such command sits on a written list that a named reviewer has read and passed, with output the reviewer would type into the prompt personally as the bar.

Gate 3: Isolation — what the run may touch

An autonomous worker holding write access to everything you can write is a worker holding your permissions. Three items fence the surface.

RLS-7 — The loop works in a copy that belongs to it alone. A dedicated branch, clone, or worktree — never a checkout that a second process, including you, edits concurrently. Check: name the directory, and confirm no other writer has it open.
RLS-8 — The write surface is an enumerated list of paths. Decide before launch which locations the run may mutate; a diff landing anywhere else is an incident to file, not a surprise to interpret. The failure taxonomy on this site files exactly that incident as CAF-3. Check: the list exists in writing, and the pass's declared edits map onto it.
RLS-9 — The loop holds no authority that is irreversible. No push, no package release, no deploy, no production write — nothing the run can do should sit beyond repair through version control. In this ecosystem those powers are granted separately and explicitly; they are never ambient capabilities of a worker. Check: enumerate the credentials the loop's environment actually carries; anything on that list with production reach fails the item.

Gate 4: Stop conditions — what ends the run

A loop whose only stop is a human's interrupt has exactly one stop condition, and that one sleeps. Three items give the machinery stops of its own.

RLS-10 — At least one stop is enforced by machinery, not by you. The ceilings from RLS-1 must end the run through the driver, not through your future attention. Check: name the component that halts the run when a ceiling is reached, and the exit behavior it produces.
RLS-11 — A semantic stop reads state the worker cannot rewrite. The strongest ending is the work running dry: the driver asks the board what remains before pass one and again between the passes that follow, and an empty reply ends the run as a success — YYLO's runner does exactly this against the task ledger. A raw loop without a board still needs an acceptance state that a command can read. Check: name the state and the command; if the only witness to "finished" is the agent's own prose, this item fails.
RLS-12 — Running in place is detected, terminal, and rehearsed. Machinery must snapshot the work-state between passes and exit with a distinct status after a declared number of unchanged rounds — YYLO's default is three, the exit status is 2 rather than 0, and the hook that fires files a warning record, turning the stall into visible work of its own. A stop nobody has observed firing is still a hypothesis: each condition gets one witnessed firing on a disposable target before the first unattended run, a rehearsal whose walkthrough belongs to the hardening guide. Check: you have watched each stop end a run at least once.

Gate 5: Evidence — what each pass leaves behind

The morning reader is this gate's customer: whoever opens the machine after the run needs records the machinery wrote, not impressions the worker left behind.

RLS-13 — Done is decided by a command chosen before launch. Acceptance must be state a runner reads — a suite's exit status, a receipt tied to the identity of the work — while the worker's closing paragraph reports progress but decides nothing. Check: name the deciding command, and where its result gets recorded.
RLS-14 — Every pass deposits four machinery-written records: an account, a change, a log, a handle. The account is the worker's response recorded on the task — a transition carrying none is refused before anything is written. The change is a commit bound to completion. The log replays the run without a terminal. The handle resumes the very session that produced the pass, and per-run history accumulates cost and turn counts alongside it. Check: pick any completed pass and reconstruct what it did from these records alone.
RLS-15 — Records are append-only, including the ugly ones. A stopped, interrupted, or failed pass is recorded, not tidied away, and the interrupt itself earns a line; deleting a bad pass to make history read better falsifies the run. Silence wearing a success label is the cheapest counterfeit on record — the ecosystem flags a step green with an empty answer as a defect, filed in the taxonomy as CAF-7 — so an account that claims everything and shows nothing fails this item. Check: the run's record shows its worst pass, unedited.

Copy the checklist

The card below is the whole gate in fifteen lines. Paste it into a runbook, a pull-request template, or the launch ticket, and check it where a second operator can see the result — the identifiers are permanent, so a checked line means the same thing next quarter that it means today.

Ralph-loop safety checklist, version 1 (2026-08-29) — unknown fails every item
[ ] RLS-1   pass ceiling and run ceiling: numeric, finite, in the launch command
[ ] RLS-2   a named human reads the evidence at a named time
[ ] RLS-3   first pass's item named, with the evidence that closes it
[ ] RLS-4   steering files enumerated; one accountable writer each
[ ] RLS-5   secrets in scoped env vars; steering files grepped clean
[ ] RLS-6   every prompt-entering command reviewed like code
[ ] RLS-7   dedicated working copy; no second writer
[ ] RLS-8   write surface enumerated; out-of-list diffs are incidents
[ ] RLS-9   no push, release, deploy, or production-write authority
[ ] RLS-10  one stop the machinery enforces without a human
[ ] RLS-11  semantic stop reads state the worker cannot rewrite
[ ] RLS-12  no-change running detected, terminal, rehearsed once
[ ] RLS-13  done decided by a pre-chosen command, never testimony
[ ] RLS-14  each pass deposits account, commit, log, session handle
[ ] RLS-15  records append-only; interrupts and failures included

Grounding, scope, and neighbors

Two evidence classes stand behind the page, matching its declared sources. The product behaviors named inside the items — the single-iteration committed default, the driver's outer ceiling and its board check, the three-round stall tripwire with its nonzero exit and warning record, the thirty-second substitution timeout with terminal input detached and standard output only, the environment file loaded for hooks and workers, the response-required task transitions, the one-task loop skill contract — were each read out of committed YYLO source on 2026-08-29, straight from the files rather than from memory. The item set itself, the admission rule, unknown-fails scoring, and the second-operator phrasing requirement are this page's original research. Nothing here leans on a search-demand estimate: the page exists because operators keep starting loops, and its worth will be judged by reuse. The checklist is harness-agnostic — no item requires YYLO, and YYLO's contracts are cited as one working implementation of each bound.

Three neighboring pages hold adjacent jobs, each linked exactly once where the need for it arises, never restated. The technique's definitive treatment is linked in the opening; the hardening changes that install these bounds, down to their commands, are linked at the rehearsal item; and the injection-surface taxonomy with the secret-crossing detail behind Gate 2 belongs to the prompt-safety guide. Two more neighbors appear in prose only, without links: the design method that decides which bounds a given workload deserves, and the diagnostic catalog of what unattended loops do when these gates are absent. The failure taxonomy's contribution is deliberately identifier-only — CAF-3, CAF-1, and CAF-7 name what the isolation, stop-condition, and evidence gates are holding out, and this page does not restate them.

Stability policy

Identifier permanence is strict: RLS-1 through RLS-15 hold their numbers and meanings for as long as this asset resolves. A withdrawn item takes its number with it — numbers are never reused — and a new item appends the next free number rather than refilling a gap. Rewording an item so its observation sharpens, without changing what the item observes, is allowed and is journaled in the changelog and dated. Moving an item between gates, renumbering the set, or changing what a check observes requires a new version with a fresh date, and earlier versions keep resolving through the changelog. Product-docs grounding is re-derived from committed source quarterly; a review that changes nothing journals that fact in the changelog too.

Changelog

Version 1, first published 2026-08-29. Fifteen items in five gates, the admission rule, unknown-fails scoring, and this policy. Nothing precedes this entry; nothing renumbered, nothing withdrawn.

Citing the checklist

When you reuse the card, cite the identifiers together with their version and date — that pairing is what tells a teammate six months from now exactly which checklist you passed. The recommended form:

Ralph-loop safety checklist, version 1 — items RLS-1 through RLS-15
https://yylo.dev/guides/ralph-loop-safety-checklist
YYLO, evidence verified 2026-08-29

A runbook line reading RLS-1 through RLS-15 checked does real work: it names the version, invites the audit, and tells the next operator that the loop they are inheriting was gated before it was launched — by a list, not a feeling.