From e13f1305a9e24c01d55828a79a01f75af48443de Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Wed, 6 May 2026 15:29:47 +0000 Subject: [PATCH 1/2] Initial plan From f0bb0b6f32731d9e71fadb36ffed205dd0074c89 Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Wed, 6 May 2026 15:31:02 +0000 Subject: [PATCH 2/2] Add Mermaid architecture diagram to README Agent-Logs-Url: https://github.com/githubnext/autoloop/sessions/ba5a5adf-9978-40e8-954f-dba2e471cc1d Co-authored-by: mrjf <180956+mrjf@users.noreply.github.com> --- README.md | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/README.md b/README.md index bc1693d..5bd9d53 100644 --- a/README.md +++ b/README.md @@ -47,6 +47,48 @@ All state — scheduling, iteration history, lessons learned, current priorities **You stay in control.** Each program gets its own long-running branch (`autoloop/`) that you can merge whenever you're ready. You can provide feedback or steer the direction at any time by commenting on the program's issue or editing the state file on the memory branch. +### Architecture + +The diagram below shows what happens during a single Autoloop run — how the scheduler picks a program, how the agent proposes and evaluates a change, and how state is persisted across the program issue, the `memory/autoloop` branch, and the program's draft PR. + +```mermaid +flowchart TD + subgraph Pre["Pre-step (scheduler)"] + S[autoloop_scheduler.py] -->|reads| PD[".autoloop/programs/{name}/program.md"] + S -->|reads| SF[("memory/autoloop branch
{name}.md state file")] + S -->|writes| AJ["/tmp/gh-aw/autoloop.json"] + end + + subgraph Agent["Agent step"] + AJ -->|selected program| A1["Steps 1-2: Read program,
state file, target files,
issue comments"] + A1 --> A3["Step 3: Checkout autoloop/{name}
fast-forward to main"] + A3 --> A4["Step 4: Propose change,
run evaluation command"] + A4 -->|metric improved| A5a["Step 5a: Commit → push
via create_pull_request /
push_to_pull_request_branch"] + A4 -->|no improvement| REJ["Reject: update state,
no push"] + A5a -->|CI green| A5c["Step 5c: Accept
update state, post to issue"] + A5a -->|CI red| A5b["Step 5b: Fix loop
(up to 5 attempts)"] + A5b -->|fixed| A5a + A5b -->|exhausted| PAUSE["Pause program"] + end + + subgraph Safe["Safe-outputs step"] + A5a -->|patch artifact| SO["Apply patch to remote branch
Create/update PR
Post comments to issue"] + end + + subgraph Persist["Persistence"] + A5c -->|writes| SF + REJ -->|writes| SF + SO -->|pushes| BR["autoloop/{name} branch"] + SO -->|creates/updates| PR["Draft PR"] + SO -->|comments on| ISS["Program issue
[Autoloop: {name}]"] + end + + subgraph Support["Supporting workflows"] + EV["Evergreen (every 5m)"] -->|fixes CI / merges main| PR + CI["CI workflow"] -->|runs on push| BR + end +``` + ### Scheduling The workflow runs on a fixed schedule (every 6 hours by default) and runs **one program per trigger**. Each run, it picks the most-overdue program — so if you have 5 programs, they take turns rather than all running at once. Programs can set their own `schedule:` in their frontmatter (e.g. `every 1h`, `daily`, `weekly`), but they still only run when the workflow fires and it's their turn. To run more programs more often, you can increase the workflow's trigger frequency.