Native pattern for scheduled auto-mode agents driving the action-required queue #72

New issue

Closed

opened 2026-05-23 20:55:30 +00:00 by coilysiren · 1 comment

coilysiren commented

2026-05-23 20:55:30 +00:00

Owner

Originally filed by @coilysiren on 2026-04-29T02:11:01Z - https://github.com/coilysiren/repo-recall/issues/30

The idea

The README already pitches the dashboard as a deterministic data layer that an agent can reason over ("Open http://127.0.0.1:7777 and work through every repo flagged as action-required"). What's missing is the schedule — pointing a recurring agent at the dashboard so the action-required list drains itself overnight or weekly without human kick-off.

Concretely: a Claude Code routine on cron, prompted with something like

Open http://127.0.0.1:7777. For each repo in /api/action-required, investigate the cause (failing CI, dirty tree, in-progress op, detached head, review requested) and resolve it autonomously. Report what you fixed, what you couldn't, and why.

Run weekly Sunday night, wake up Monday to a drained queue (or a punch list of items the agent couldn't unblock). Combined with auto mode, this is close to a real "second pair of hands" rather than a passive dashboard.

Why repo-recall specifically

The action-required surface is already designed for this — `id = "<repo_id>:"` lets a returning agent tell "same broken thing, still broken" from "this one cleared and a new one appeared," and `/api/scan-version` + `ETag` make polling cheap. So the data plumbing is there. What would help an agent run cleanly:

Item-level acquire/release — `POST /api/action-required/{id}/claim` with a TTL, returns 409 if already claimed. Stops two concurrent agents (or a human + an agent) from stomping on the same repo. TTL means no stuck locks if the agent crashes.
Last-attempt-result annotation — when an agent gives up on an item, it can `POST /api/action-required/{id}/note` with a short status ("can't auto-resolve: needs auth secret rotation"). Surfaces in the next dashboard render so the human sees "agent already tried this, here's why it bounced" instead of the same red pill week after week.
README section — short "Scheduled auto-mode" subsection under "Point an agent at it," with a worked example: cron expression, the prompt, where logs go, how to inspect what the agent did. Even without #1 and #2, just naming the pattern would surface the option for users who didn't know agent runs could be scheduled.

#3 is the cheap win. #1 and #2 are the upgrade if scheduled-agent usage takes off.

Out of scope

repo-recall shouldn't run the agent itself or store a cron schedule — that belongs in whatever scheduler the user already has (Claude Code routines, Task Scheduler, systemd timer, GH Actions cron). Server-side scheduling would pull repo-recall away from "local data layer" toward "orchestrator," and the value of staying in the data-layer lane is composability with whichever scheduler the user prefers.

_Originally filed by @coilysiren on 2026-04-29T02:11:01Z - [https://github.com/coilysiren/repo-recall/issues/30](https://github.com/coilysiren/repo-recall/issues/30)_ ## The idea The README already pitches the dashboard as a deterministic data layer that an agent can reason over (\"Open http://127.0.0.1:7777 and work through every repo flagged as action-required\"). What's missing is the **schedule** — pointing a recurring agent at the dashboard so the action-required list drains itself overnight or weekly without human kick-off. Concretely: a Claude Code routine on cron, prompted with something like > Open http://127.0.0.1:7777. For each repo in /api/action-required, investigate the cause (failing CI, dirty tree, in-progress op, detached head, review requested) and resolve it autonomously. Report what you fixed, what you couldn't, and why. Run weekly Sunday night, wake up Monday to a drained queue (or a punch list of items the agent couldn't unblock). Combined with auto mode, this is close to a real \"second pair of hands\" rather than a passive dashboard. ## Why repo-recall specifically The action-required surface is already designed for this — \`id = \"<repo_id>:<signal>\"\` lets a returning agent tell \"same broken thing, still broken\" from \"this one cleared and a new one appeared,\" and \`/api/scan-version\` + \`ETag\` make polling cheap. So the data plumbing is there. What would help an agent run cleanly: 1. **Item-level acquire/release** — \`POST /api/action-required/{id}/claim\` with a TTL, returns 409 if already claimed. Stops two concurrent agents (or a human + an agent) from stomping on the same repo. TTL means no stuck locks if the agent crashes. 2. **Last-attempt-result annotation** — when an agent gives up on an item, it can \`POST /api/action-required/{id}/note\` with a short status (\"can't auto-resolve: needs auth secret rotation\"). Surfaces in the next dashboard render so the human sees \"agent already tried this, here's why it bounced\" instead of the same red pill week after week. 3. **README section** — short \"Scheduled auto-mode\" subsection under \"Point an agent at it,\" with a worked example: cron expression, the prompt, where logs go, how to inspect what the agent did. Even without #1 and #2, just naming the pattern would surface the option for users who didn't know agent runs could be scheduled. #3 is the cheap win. #1 and #2 are the upgrade if scheduled-agent usage takes off. ## Out of scope repo-recall shouldn't run the agent itself or store a cron schedule — that belongs in whatever scheduler the user already has (Claude Code routines, Task Scheduler, systemd timer, GH Actions cron). Server-side scheduling would pull repo-recall away from \"local data layer\" toward \"orchestrator,\" and the value of staying in the data-layer lane is composability with whichever scheduler the user prefers.

coilysiren commented

2026-05-30 05:43:52 +00:00

Author

Owner

Iceboxed in the 2026-05-29 backlog burn-down: Scheduled auto-mode agents idea, speculative far-future pattern. Reopen anytime if it becomes real.

coilysiren closed this issue

2026-05-30 05:43:52 +00:00

coilysiren added the

label

2026-05-31 01:54:58 +00:00

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

coilyco-flight-deck/repo-recall#72

No description provided.

Rows
Columns