summaryrefslogtreecommitdiff
path: root/Omni/Agent/WORKER_AGENT_GUIDE.md
blob: d0bc7a702088fe921a0c982f97d95db11beeea40 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
# Worker Agent Guide

This guide describes how to run a headless Worker Agent using the Multi-Agent Workflow.

## 1. Setup

First, create a dedicated worktree for the worker:

```bash
./Omni/Agent/setup-worker.sh omni-worker-1
```

This creates `../omni-worker-1` sharing the same git history but with its own workspace and branch (`omni-worker-1`).

## 2. Worker Loop

The Worker Agent should run the following loop continuously:

### Step 1: Sync and Find Work

```bash
# Go to worker directory
cd ../omni-worker-1

# Update base branch with latest live code
# We use rebase to keep history linear (patch-based workflow)
# The custom merge driver handles tasks.jsonl conflicts during rebase
git fetch origin live
git rebase origin/live

# Sync tasks from the live branch
./Omni/Agent/sync-tasks.sh

# Check for ready tasks
task ready --json
```

### Step 2: Claim Task

If a task is found (e.g., `t-123`):

```bash
# Mark in progress
task update t-123 in-progress

# Commit the claim locally
./Omni/Agent/sync-tasks.sh --commit
```

### Step 3: Create Workspace

**CRITICAL: Determine the correct base branch.**

1.  **Check Dependencies**: Run `task deps t-123 --json`.
2.  **Check for Unmerged Work**: Look for dependencies that have existing branches (e.g., `task/t-parent-id`) which are NOT yet merged into `live`.
3.  **Select Base**:
    *   If you find an unmerged dependency branch, check it out: `git checkout task/t-parent-id`.
    *   Otherwise, start from fresh live code: `git checkout -b task/t-123 live`.

4.  **Implement**:
    (Proceed to implementation)

### Step 4: Implement

1.  Read task details: `task show t-123`
2.  Implement changes.
3.  **Run Tests**: `bild --test Omni/YourNamespace.hs`

### Step 5: Submit for Review
 
 1.  **Update Status and Commit**:
     Bundle the task status update with your implementation to keep history clean.
 
     ```bash
     # 1. Mark task for review (updates .tasks/tasks.jsonl)
     task update t-123 review
 
     # 2. Commit changes + task update
     git add .
     git commit -m "feat: implement t-123"
     ```
 
 2.  **Signal Review Readiness**:
     Update the worker branch to signal the planner.
 
     ```bash
     # Switch to base branch
     git checkout omni-worker-1
     
     # Sync to get latest state
     ./Omni/Agent/sync-tasks.sh
     
     # Ensure the task is marked review here too
     task update t-123 review
     
     # Commit this status change to the worker branch
     ./Omni/Agent/sync-tasks.sh --commit
     ```

    *Note: The Planner will now see 't-123' in 'Review' when it runs `task list --status=review`.*

## 3. Planner (Reviewer) Workflow

The Planner Agent (running in the main repo) will:
1.  **Find Reviews**: Run `task list --status=review`.
3.  **Review Code**:
    *   Check out the feature branch: `git checkout task/t-123`.
    *   **Rebase onto Live**: Ensure the branch is up-to-date and linear.
        ```bash
        git rebase live
        ```
    *   Run tests and review code.
4.  **Merge**:
    *   `git checkout live`
    *   `git merge task/t-123` (This will now be a fast-forward or clean merge)
5.  **Complete**:
    *   `task update t-123 done`
    *   `git commit -am "task: t-123 done"`

## Troubleshooting

If `sync-tasks.sh` reports a conflict:
1.  Manually run `task import -i .tasks/live-tasks.jsonl`
2.  If git merge conflicts occur in `tasks.jsonl`, the custom merge driver should handle them. If not, resolve by keeping the union of tasks (or letting `task import` decide).