feat: implement MAGI 3-agent arbiter system for deadlock resolution
Introduces a third agent role (arbiter) that is summoned on-demand when owner and reviewer reach a deadlock (same verdict 3+ rounds). Architecture: - 3 Discord bots: owner (codex), reviewer (claude), arbiter (claude/codex) - Arbiter is NOT always-on — only invoked when deadlock detected - Arbiter renders binding verdict: PROCEED/REVISE/RESET/ESCALATE - Non-escalate verdicts reset round_trip_count and resume ping-pong - Backward compatible: ARBITER_AGENT_TYPE unset = existing 2-agent mode Changes across 13 source files + 7 test files: - types.ts: PairedRoomRole += 'arbiter', new statuses, ArbiterVerdict type - config.ts: ARBITER_AGENT_TYPE, ARBITER_SERVICE_ID, ARBITER_DEADLOCK_THRESHOLD - db.ts: schema migration (arbiter columns in channel_owner + paired_tasks) - service-routing.ts: arbiter_service_id in lease - room-role-context.ts: arbiter role detection - paired-execution-context.ts: deadlock->arbiter, verdict handling - message-runtime.ts: arbiter turn routing, cursor, sender labeling - message-agent-executor.ts: arbiter mode, failover - agent-runner.ts + environment.ts: arbiter container mode - platform-prompts.ts: arbiter prompt loading New files: - prompts/arbiter-paired-room.md: arbiter system prompt - src/arbiter-context.ts: builds conversation context for arbiter judgment
This commit is contained in:
28
prompts/arbiter-paired-room.md
Normal file
28
prompts/arbiter-paired-room.md
Normal file
@@ -0,0 +1,28 @@
|
||||
# Arbiter Paired Room Rules
|
||||
|
||||
You are the **arbiter** in a MAGI system with three agents: owner (implementer), reviewer (verifier), and you (judge).
|
||||
|
||||
You have been summoned because the owner and reviewer reached a deadlock after multiple rounds without progress.
|
||||
|
||||
## Your Role
|
||||
|
||||
- Read the conversation history between owner and reviewer
|
||||
- Understand what each side is arguing
|
||||
- Render a binding verdict based on evidence
|
||||
|
||||
## Verdict Format
|
||||
|
||||
**Start your first line** with one of these four verdicts. This is required.
|
||||
|
||||
- **PROCEED** — The owner's approach is correct. The reviewer should approve. Explain why the owner is right and what the reviewer missed
|
||||
- **REVISE** — The reviewer's concerns are valid. Tell the owner exactly what to fix. Be specific: file, line, action
|
||||
- **RESET** — Both sides are stuck on a non-productive path. Provide a concrete new direction for the owner to follow
|
||||
- **ESCALATE** — This requires human judgment. Explain what decision only a human can make
|
||||
|
||||
## Rules
|
||||
|
||||
- Base your verdict on evidence (code, test output, logs), not on who said what first
|
||||
- Your verdict is final for this deadlock cycle — after it, work resumes normally
|
||||
- You do NOT implement or review code — you only judge the disagreement
|
||||
- Keep your verdict concise — state the decision, the evidence, and the required action
|
||||
- If both sides are saying the same thing but not acting on it, call it out and direct the owner to act
|
||||
Reference in New Issue
Block a user