yonlu/yellowjacket
1
1
Fork 0
Code Issues 55 Pull Requests 6 Actions Packages Projects Releases 12 Wiki Activity

Autonomous backlog loop: work the tracker one issue at a time, on a schedule #236

New Issue
Closed
opened 2026-09-03 03:31:25 +00:00 by logan · 1 comment
logan commented 2026-09-03 03:31:25 +00:00
Collaborator
Copy Link
Copy Source

A pi coding-agent configuration that, toggled on, works this tracker one issue at a time end to end: triage the open list, claim, plan, implement on a branch, validate the work against the issue's actual claim, critique it, open the PR, watch CI, merge when the protection contexts are green, verify the issue closed, and keep the docs honest — then do it again.

What this is. The v0 of this already exists (.pi/schedule-prompts.json's yj-backlog job + .pi/prompts/next-issue.md, which has run ~50 times but stops at "PR open, CI green"). This raises that to a designed loop with explicit parts and authority:

  • a state machine whose state is the tracker itself (labels, assignee, comments, branches, PRs) — whoever reads Gitea sees exactly where it is;
  • per-leg agents with pinned models per the cost tiering in the session-reference card (mimo for mechanical work, qwen/deepseek-v4-pro for implementation, glm-5.3 for repo-scale reasoning and review, glm-5.3-flash for pixels, kimi-k3 as the once-a-day escalation ceiling);
  • a merge gate: only PRs the loop opened, only when CI / check + CI / e2e are green, with the Closes footer verified after the fact;
  • rails: one issue in flight, never touch someone else's work, new findings become new issues, two strikes on a failing CI, three critique rounds.

What it is not. A replacement for the device tier (issues needing a real phone stay open for humans, though a user-booted emulator opts in android-smoke verification), or a reason to weaken the tracker discipline — the loop claims with scripts/issue.sh like anyone and its refusal is the feature.

Design. .planning/plans/active/020-autonomous-backlog-loop.md. Operating procedure: .pi/skills/yj-loop/. On/off is .pi/schedule-prompts.json in the loop's dedicated worktree, and it only runs while that pi session is open.

A pi coding-agent configuration that, toggled on, works this tracker one issue at a time end to end: triage the open list, claim, plan, implement on a branch, validate the work against the issue's actual claim, critique it, open the PR, watch CI, merge when the protection contexts are green, verify the issue closed, and keep the docs honest — then do it again. **What this is.** The v0 of this already exists (`.pi/schedule-prompts.json`'s `yj-backlog` job + `.pi/prompts/next-issue.md`, which has run ~50 times but stops at "PR open, CI green"). This raises that to a designed loop with explicit parts and authority: - a state machine whose state is the tracker itself (labels, assignee, comments, branches, PRs) — whoever reads Gitea sees exactly where it is; - per-leg agents with pinned models per the cost tiering in the session-reference card (mimo for mechanical work, qwen/deepseek-v4-pro for implementation, glm-5.3 for repo-scale reasoning and review, glm-5.3-flash for pixels, kimi-k3 as the once-a-day escalation ceiling); - a merge gate: only PRs the loop opened, only when `CI / check` + `CI / e2e` are green, with the `Closes` footer verified after the fact; - rails: one issue in flight, never touch someone else's work, new findings become new issues, two strikes on a failing CI, three critique rounds. **What it is not.** A replacement for the device tier (issues needing a real phone stay open for humans, though a user-booted emulator opts in `android-smoke` verification), or a reason to weaken the tracker discipline — the loop claims with `scripts/issue.sh` like anyone and its refusal is the feature. **Design.** `.planning/plans/active/020-autonomous-backlog-loop.md`. Operating procedure: `.pi/skills/yj-loop/`. On/off is `.pi/schedule-prompts.json` in the loop's dedicated worktree, and it only runs while that pi session is open.
logan added the
Priority
Low
4
Kind/Enhancement labels 2026-09-03 03:31:25 +00:00
logan self-assigned this 2026-09-03 03:31:35 +00:00
logan added the
Status
In Progress
 label 2026-09-03 03:31:35 +00:00
logan commented 2026-09-03 03:31:35 +00:00
Author
Collaborator
Copy Link
Copy Source

Taking this. Branch feat/236-autonomous-backlog-loop.

Approach: plan 020 first (the design, in .planning/plans/active/), then the four artifact families the design names — the yj-loop skill (operating procedure the tick reads), the ten yj-loop.* agents with models pinned per the tiering card, the tick prompt and the critique chain, and the CLAUDE.md pointer. Verification: make skill-check (the new .pi content must not name a missing target), the critique chain parsed, and a proof-read of every rail against the tracker's actual mechanics (issue.sh claim semantics, the protection contexts, unclaim.yml). No code changes; the loop worktree and the supervised pilot follow this PR.

Taking this. Branch `feat/236-autonomous-backlog-loop`. Approach: plan 020 first (the design, in `.planning/plans/active/`), then the four artifact families the design names — the `yj-loop` skill (operating procedure the tick reads), the ten `yj-loop.*` agents with models pinned per the tiering card, the tick prompt and the critique chain, and the `CLAUDE.md` pointer. Verification: `make skill-check` (the new .pi content must not name a missing target), the critique chain parsed, and a proof-read of every rail against the tracker's actual mechanics (`issue.sh claim` semantics, the protection contexts, `unclaim.yml`). No code changes; the loop worktree and the supervised pilot follow this PR.
logan closed this issue 2026-09-03 03:54:16 +00:00
gitea-actions bot removed the
Status
In Progress
 label 2026-09-03 03:54:26 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Area/Design
Area/Downloads
Area/Explore
Area/Library-UI
Area/Metadata
Area/Packaging
Area/Player
Area/Queue
Area/Settings
Area/Shell-Nav
Compat/Breaking
Breaking change that won't be backward compatible
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
 Platform/Android
Platform/Desktop
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Medium
3
The priority is medium
Priority
Low
4
The priority is low
Reviewed
Confirmed
1
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
In Progress
Somebody is actively working on this right now
No labels Kind/Enhancement
Priority
Low
4
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
logan yonlu
No Assignees logan
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: yonlu/yellowjacket#236