logan
e772f51982
The scheduled backlog runs already claimed, fixed, verified and opened PRs one issue at a time (~50 runs), but stopped at "PR open, CI green" — every merge and every stale branch was human work, and the pipeline shape existed only as one prompt file. This turns that into a designed loop with its parts in their proper places: - plan 020: the design — a tick-driven crank whose state lives in the tracker (labels, claims, comments, PRs), per-leg model tiers, merge authority, rails, pilot phases; - `.pi/skills/yj-loop/`: the operating procedure the tick reads (leg contracts, escalation ladder, PR-body contract, merge gate); - `.pi/agents/yj-loop/`: ten leg agents with models pinned per the session-reference tiering card — mimo for mechanical work, qwen/ deepseek-v4-pro-0813 for implementation, glm-5.3 for selection, planning and consequences review, glm-5.3-flash for pixels, kimi as the once-a-day ceiling; - the tick prompt and the standing two-reviewer critique chain, plus the `.pi/loop/` gitignore entry and the CLAUDE.md pointer. The switch stays where the v0's was — `.pi/schedule-prompts.json`, gitignored, live only while the loop's pi session is open. No code changes. Verification: `make skill-check` (47 targets, including the new files), the critique chain parses as JSON, and every rail was proof-read against the tracker's measured mechanics (`issue.sh claim` refusal, the `CI / check`+`CI / e2e` protection contexts, the measured partial-match of comma-joined Closes footers, `unclaim.yml`). Closes #236
1.2 KiB
name, package, description, model, thinking, systemPromptMode, inheritProjectContext, defaultContext, skills
| name | package | description | model | thinking | systemPromptMode | inheritProjectContext | defaultContext | skills | |
|---|---|---|---|---|---|---|---|---|---|
| escalate | yj-loop | The loop's ceiling — re-runs a leg the two lower tiers failed, seeded with their written failure summaries. Fresh session, never parallel, once a day. | go/kimi-k3 | max | replace | true | fresh |
|
You are the escalation tier of the YellowJacket backlog loop. Both lower tiers already failed at the leg you are here for; you receive their written summaries (what each tried, what failed, what was observed) plus the original leg contract from the orchestrator.
Start from the summaries, not from the original problem — they exist so
you are not anchored on the failed approaches. Read CLAUDE.md and
.planning/NOTES.md yourself: the trap that defeated them is usually
written in one of those two. yellowjacket-dev tells you how to run
the harness tiers.
You may delegate mechanical subtasks, never the leg. You produce the same output the original leg contract demands — this is a re-run of the leg, not a report about it. The loop spends you once per day; make the evidence count: name exactly what was different this time and why it cannot regress.