EPIC: `_rage` orchestration plugin for autonomous backlog loops #5

New issue

Open

opened 2026-08-22 22:30:40 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

2026-08-22 22:30:40 +00:00

(Migrated from github.com)

Parent: #1

Goal

Implement RAGE as an orchestration plugin, not permanent model prompt text.

RAGE = Review -> Analyze -> Generate -> Execute. It is a control/workflow loop that drives autonomous issue/backlog work, verification, retry policy, and bounded delegation.

Critical context rule

_rage must add zero permanent prompt payload when inactive.
Do not paste the RAGE procedure into the global solving/system prompt.
Prefer lifecycle state, plugin hooks, structured task packets, and explicit trigger state over repeated prose instructions.
Any model-visible RAGE guidance must be tiny, scoped to an active RAGE run, and removed when the run ends.

Activation

RAGE should be explicitly activatable for an issue/epic/backlog run, and may later support configured automatic activation for qualifying development tasks. Simple normal chats must not pay its context cost.

Loop state

Track structured state outside conversational prose:

target issue/epic
current phase
objective
acceptance gates
evidence/artifact refs
attempted approaches
failures
checks run
blockers
next action
iteration/depth/budget

Loop semantics

Review repository state, applicable instructions, issue/PR backlog, prior attempts, and evidence.
Analyze the smallest useful next slice and its verification gate.
Generate the focused change/delegation/test.
Execute it, verify, update structured state, then repeat if gates remain.

Recovery

same failing tool/action twice without new evidence -> re-plan or isolate in a fresh worker
repeated identical error -> retire that approach until new evidence appears
new user correction -> supersede conflicting active plan immediately
never treat timeout/partial output/skipped checks as success
continue through useful backlog after a slice completes rather than stopping after one trivial success

Delegation

fresh workers receive bounded task packets, not the whole root conversation
depth 1 by default
bounded fanout/budget
worker returns compact structured result/evidence/artifact refs
root/plugin retains acceptance responsibility

Phase ordering

Do not mix implementation of _rage into the current Phase-0 context-debloat PR. First establish the lean Agent Zero baseline (#2/#3). _rage can then be implemented and measured as an optional orchestration layer. RLM integration remains a separate later phase (#8).

Acceptance

Plugin exists as its own isolated component.
Inactive plugin contributes zero model-visible context.
Active runs maintain structured loop state outside chat prose.
RAGE phases advance based on explicit gates/evidence.
Retry/circuit-breaker behavior is deterministic and tested.
User corrections preempt stale plans.
Workers receive bounded context and return structured results.
Loop can continue across multiple backlog items until configured stop/gate.
Context/token telemetry proves RAGE does not recreate the bloat Phase 0 removed.

Non-goals

No permanent RAGE system prompt.
No unbounded autonomous recursion.
No dependency on Prolog-RLM for the first _rage plugin implementation; RLM may later provide policy/verification primitives behind the plugin.

Parent: #1 ## Goal Implement RAGE as an **orchestration plugin**, not permanent model prompt text. RAGE = **Review -> Analyze -> Generate -> Execute**. It is a control/workflow loop that drives autonomous issue/backlog work, verification, retry policy, and bounded delegation. ## Critical context rule - `_rage` must add **zero permanent prompt payload** when inactive. - Do not paste the RAGE procedure into the global solving/system prompt. - Prefer lifecycle state, plugin hooks, structured task packets, and explicit trigger state over repeated prose instructions. - Any model-visible RAGE guidance must be tiny, scoped to an active RAGE run, and removed when the run ends. ## Activation RAGE should be explicitly activatable for an issue/epic/backlog run, and may later support configured automatic activation for qualifying development tasks. Simple normal chats must not pay its context cost. ## Loop state Track structured state outside conversational prose: - target issue/epic - current phase - objective - acceptance gates - evidence/artifact refs - attempted approaches - failures - checks run - blockers - next action - iteration/depth/budget ## Loop semantics 1. **Review** repository state, applicable instructions, issue/PR backlog, prior attempts, and evidence. 2. **Analyze** the smallest useful next slice and its verification gate. 3. **Generate** the focused change/delegation/test. 4. **Execute** it, verify, update structured state, then repeat if gates remain. ### Recovery - same failing tool/action twice without new evidence -> re-plan or isolate in a fresh worker - repeated identical error -> retire that approach until new evidence appears - new user correction -> supersede conflicting active plan immediately - never treat timeout/partial output/skipped checks as success - continue through useful backlog after a slice completes rather than stopping after one trivial success ## Delegation - fresh workers receive bounded task packets, not the whole root conversation - depth 1 by default - bounded fanout/budget - worker returns compact structured result/evidence/artifact refs - root/plugin retains acceptance responsibility ## Phase ordering Do **not** mix implementation of `_rage` into the current Phase-0 context-debloat PR. First establish the lean Agent Zero baseline (#2/#3). `_rage` can then be implemented and measured as an optional orchestration layer. RLM integration remains a separate later phase (#8). ## Acceptance - [ ] Plugin exists as its own isolated component. - [ ] Inactive plugin contributes zero model-visible context. - [ ] Active runs maintain structured loop state outside chat prose. - [ ] RAGE phases advance based on explicit gates/evidence. - [ ] Retry/circuit-breaker behavior is deterministic and tested. - [ ] User corrections preempt stale plans. - [ ] Workers receive bounded context and return structured results. - [ ] Loop can continue across multiple backlog items until configured stop/gate. - [ ] Context/token telemetry proves RAGE does not recreate the bloat Phase 0 removed. ## Non-goals - No permanent RAGE system prompt. - No unbounded autonomous recursion. - No dependency on Prolog-RLM for the first `_rage` plugin implementation; RLM may later provide policy/verification primitives behind the plugin.