# Turning on the automatic loop Source: https://dorkos.ai/docs/guides/flow/turning-on-autonomy Three ways to let /flow carry work to your review gate on its own, from an attended terminal drain to a scheduled background loop. What works today, and what is still coming. # Turning on the automatic loop [#turning-on-the-automatic-loop] `/flow` can work through your ready queue on its own and stop at your review gate. You still approve every merge, so you get the progress without babysitting every stage. **"Automatic" never means "merges without you."** The loop claims a ready item, drives it to a pull request with evidence, parks at the review gate, and waits. You approve and merge. Nothing reaches `main` that you did not choose, in any setup on this page. (We checked. Twice.) There are three ways to run this loop without hand-driving each stage yourself. They differ in one way: how the loop gets scheduled. All three carry one item along the same path (triage, through verify, to review) and stop at the same gate. ## The three setups [#the-three-setups] Pick based on how much you want running in the background versus in front of you. | Setup | Needs a server running? | Runs... | Available now? | | --------------------------- | ----------------------- | --------------------------------- | ------------------- | | **A: `/flow auto`** | No | While your terminal is open | Yes | | **B: the Pulse seat** | Yes | On a schedule, in the background | Yes, off by default | | **C: the portable watcher** | No | On a schedule you set up yourself | No, not built yet | Run it in your terminal and watch the queue drain to the review gate, item by item. Nothing to install. Stops when you close the session, so it's a great fit for a focused afternoon, less so for overnight. A scheduled background loop that keeps working after you close your laptop. Off by default, and it needs the DorkOS server running. A design for repos that don't run the DorkOS server: a script you'd build and run on your own schedule. Not shipped yet, so think of this as a preview of what's next. ## A: `/flow auto` (the attended terminal drain) [#a-flow-auto-the-attended-terminal-drain] `/flow auto` works through your ready queue one item at a time, right from your terminal. It needs no server and no setup beyond having the repo open. ### Setup [#setup] **Be in the repo, with your tracker reachable.** No server, no install required. **Run `/flow auto`.** It claims the top-ranked ready item, carries it to its review gate, parks, then claims the next one. It keeps going until the queue is empty or nothing is left to claim. For a single item instead of the whole queue, run bare `/flow` and choose **Continue the queue**. **Watch it work.** Each item ends at a pull request with evidence attached, then stops at review. If it runs out of ready work, it asks whether to run a triage pass. If it hits a question, answer it in the terminal and it keeps going. **Close the loop yourself.** Once you approve and merge a pull request, run `/flow:done ` to close the item, file any follow-up work, and clean up. **Pros** * No infrastructure. Runs anywhere you have the repo open. * You see every claim, every stage, and every question as it happens. **Cons** * Only runs while your terminal session is open. Close it, and the drain stops. * You merge and run `/flow:done` yourself. Nothing auto-merges yet. ## B: the Pulse seat (the scheduled background loop) [#b-the-pulse-seat-the-scheduled-background-loop] The Pulse seat moves the same drain off your terminal and onto the DorkOS server, so it keeps working while you're away. It runs on a schedule: each time it fires, it picks up exactly one ready item, carries it to the review gate, and stops. That keeps every run isolated and easy to pick back up if something goes wrong. This is real today, but it ships turned off, and it needs the DorkOS server running. ### Setup [#setup-1] **Start the DorkOS server.** The scheduled runs only fire while the server is up. **Register the project's DorkOS agent.** This is the identity the scheduled run works as. **Turn on the flow-drain schedule.** It lives at `.dork/tasks/flow-drain/` and ships disabled. Flip it on. There's no build step: the change takes effect right away. **Tune how often it runs and how much it takes on.** See [The dials](/docs/guides/flow/the-dials) for the settings that control cadence and work-in-progress limits. **Watch and steer it.** `/flow:status` shows every item in flight, every parked question, and why each decision was made. `/flow pause` stops every automatic mode from one place; `/flow resume` brings it back. **Pros** * Makes progress with your terminal closed. * Reacts to new ready work in the tracker on a regular interval. * Each run is isolated, so a crash or a stall doesn't take down the next one. A run that stalls gets picked back up or restarted clean. **Cons** * Needs the DorkOS server running. No server, no scheduled runs. * Still stops at the review gate. You merge and run `/flow:done` yourself. * Checks for new work on an interval rather than reacting instantly. ## C: the portable watcher (not shipped yet) [#c-the-portable-watcher-not-shipped-yet] The watcher is meant for repos that don't run the DorkOS server: a script you'd operate yourself on whatever schedule you choose, without any DorkOS infrastructure. **Not available yet.** This is a design, not a working feature. The autonomy setting only accepts the Pulse seat today; a config file that names the watcher seat is rejected. ### What it would look like [#what-it-would-look-like] **You run an external poller** on whatever schedule you choose (a cron entry, a small script, a CI job). There's no DorkOS server in this picture. **Each run, it checks the tracker for ready work** and claims the top-ranked item. **It fires one headless run** that carries that item to its review gate, then exits. **Pros (once it ships)** * No server needed. Works with any repo and tracker the adapter supports. * Same loop as the Pulse seat, so nothing about how work gets carried to review changes. **Cons** * Not available today. You'd build and run it yourself once it ships. * No status pane or built-in recovery until then. ## Which should I use? [#which-should-i-use] Good news: you don't have to think hard about this one. | If you want to... | Use... | | ---------------------------------------------------------------------- | ------------------------------------------- | | Put the loop to work right now and watch it, no setup | **A, `/flow auto`** | | Do a single item, then stop | **A, bare `/flow` then Continue the queue** | | Keep making progress while your terminal is closed, and you run DorkOS | **B, the Pulse seat** (enable `flow-drain`) | | Run it on a repo with no DorkOS server | **C, the watcher** (once it ships) | Short version: attended and no server means A. Unattended and you run DorkOS means B. No server and no DorkOS repo means C, once it's built. A and B stop at the same review gate; the only difference is who keeps the loop ticking. ## Staying in control [#staying-in-control] Autonomy never means losing the ability to see or stop what's happening, in any setup: * **`/flow:status`** shows one screen with every item in flight, every parked question, and the reasoning behind each decision. * **`/flow pause`** stops every automatic mode at once. **`/flow resume`** brings it back. * **Reprioritize or turn off part of the loop** through its config. * **Reassign an item** to redirect it. The change takes effect at the next stage boundary. The loop also has a hard floor it never crosses, no matter how confident it is. Anything irreversible, anything that touches money or secrets, anything outward-facing, or anything that changes scope always stops and waits for you. That floor can't be configured away: a settings file that tries to remove it simply fails to load. ## Reference: how the loop works under the hood [#reference-how-the-loop-works-under-the-hood] Most people never need this section. Here's what's happening if you're curious. * **One item at a time.** The loop runs sequentially, capped at 2 items across the project and 1 per project by default. It's not a swarm of agents working in parallel; it claims one item, finishes with it, then claims the next. * **Ready work fuels it.** The loop only claims items carrying a "ready" label. Triage adds that label when it accepts an item; decompose adds it to the tasks it produces. No labeled work means nothing to dispatch. * **It tells you when it runs dry, instead of going quiet.** If the ready queue empties out but there's still unshaped work waiting behind it, the loop says so and asks whether to run a triage pass, rather than just reporting "done" and leaving you to notice the backlog yourself. * **Each scheduled run checks for stuck work first.** Before claiming anything new, it recovers any run that crashed mid-way and picks up any answer you left to a parked question. New work only gets claimed after that. * **What the Pulse seat actually is today:** a per-run scheduled drain. Each time it fires, it's a fresh session that checks for recovery and resumed work, then dispatches, and carries one item to its gate. An always-on background process that runs continuously, plus automatic merge detection, are not built yet; that's the next phase of server work. The Pulse seat gets you unattended progress to the gate. It doesn't merge for you. * **What's still ahead:** an always-on scheduler that runs continuously instead of tick by tick, automatic detection of approved pull requests so merges can fire without you running a command, running more than one item at a time safely, and a push-based connection to the tracker instead of checking on an interval. ## Next steps [#next-steps] Every setting that shapes the loop, its default, and when to change it. A closer look at the scheduling model and how work moves between stages. Run each stage by hand instead, no server required. The one path from capture to done, and how a work item moves along it.