autonomous-loop

name	autonomous-loop
description	Use when starting any session of relatively extensive or large-scale autonomous work — above all any large-scale population of queue.md with created tasks — to run the three local-cron productivity playbook (work-loop, auto-flush, status-report).

Autonomous productivity loop — the three-cron playbook

For any session involving relatively extensive work — above all, any large-scale population of queue.md with created tasks — this is the default way of working. It is three local CronCreate jobs that turn "barrel through queue.md, and when it's empty atomise the next todo.md item into it" into a self-sustaining hourly cadence with a commit/push backstop and a heartbeat. The crons are session-local (durable: false — they die when the session ends), so they are recreated at the start of every session.

Stagger the minutes so the three ticks don't collide:

1. Work-loop cron — 3 * * * * (hourly at :03). The engine. Each tick does, in order:

   • (a) SYNC — git fetch origin; fast-forward or rebase the working branch (never force-push, never reset --hard, never discard a sibling machine's work).
   • (b) WORK — take the top actionable item from queue.md and do it. If nothing in queue.md is actionable (all blocked / needs user / a product decision), promote the next genuinely-unblocked, bounded, verifiable todo.md item — plan it into queue.md first, mirror to the task tool, then execute.
   • (c) HARD RAILS — never fake; never weaken / skip / delete a test to make it pass; never claim "works" / "verified" / "passes" without having actually RUN it and measured. A real defect → strict xfail or a precise documented blocker, never a loosened assertion. Don't implement what you don't 100% understand — write the spec / queue item instead. Name unbuilt or hard things plainly; don't paper over difficulty. Verify CI green, not just local — local-green does not imply CI-green.
   • (d) COMMIT — commit early/often with why; update queue.md in the same commit (delete completed items); append the dated entry to devlog.md; mark task-tool items done; push.
   • (e) REPORT — one line: the commit shas advanced, or nothing actionable; <reason>.

2. Auto-flush cron — 15 * * * * (hourly at :15). The backstop. Commit + push all pending work so nothing sits uncommitted between manual pushes; report shas or "nothing pending". Only commit / push when something is actually pending — no empty commits.

3. Status-report cron — 42 * * * * (hourly at :42). The heartbeat — reporting only, no code changes. Covers: what advanced since the last report (shas + one-line each); current queue.md state; how the work held the hard rails (and any place it brushed one); blockers, each tagged with exactly one of the disjoint not-done taxonomy — NEEDS-DECISION / BLOCKED-ON-USER-ACTION / BLOCKED-ON-EXTERNAL / NEEDS-INVESTIGATION / UNSAFE-TO-GUESS / OUT-OF-SCOPE — naming the specific decision / user-action / external signal / risk / owner (LOAD-BEARING DEFAULT: if a not-done item fits none of these with a specifically-named blocker, it is NOT deferred — DO IT NOW); test-suite health.

Why this exists: the most common autonomous-agent failure is doing a large amount of work and silently losing the thread of what it is doing. The work-loop forces steady, verifiable, committed progress; the auto-flush guarantees nothing is lost between ticks; the status-report keeps the thread legible.

Lifecycle around a large-scale queue fill:

• (a) START all three crons at the beginning of any extensive work session. A fresh session has none of them running, so the opening move — the first queue item — is to create them.
• (b) On a mid-session large-scale queue RE-FILL (a planning burst that repopulates the queue), the FIRST item of that fill kills the running crons, then the work items follow top to bottom, and the pinned tail restarts them.
• (c) Entering planning mode DISABLES the crons. Their restart therefore lives at the end of the queue, not the beginning of the next burst.
• (d) The LAST TWO queue items, always kept pinned at the tail, are:
  1. Ensure the three crons are running — start them if this session never did, restart them if a planning burst / queue re-fill killed them.
  2. Run the status-report action once more, independently — an end-of-session summary of everything that happened this session.

In short: a fresh session starts the crons up front and the tail ensures they are still running + summarizes; a mid-session re-fill kills them up front and the tail restarts them + summarizes. Either way the queue both opens and closes on the cron set.

Replication projects are exempt. This is for new / general extensive work only — a bounded paper replication does not get the hourly heartbeat.