Add orch Codex launch bridge workflow
This commit is contained in:
@@ -0,0 +1,52 @@
|
||||
# Leader Dispatch-And-Launch Checklist
|
||||
|
||||
Use this checklist when the leader wants durable `orch` scheduling plus a Codex sub-agent worker.
|
||||
|
||||
## Goal
|
||||
|
||||
Keep `orch` as the control plane and use a leader-side bridge to launch a worker sub-agent only after `dispatch` succeeds.
|
||||
|
||||
## Recommended Flow
|
||||
|
||||
1. initialize the shared DB once through `skills/inbox/assets/inbox --db PATH --json init`
|
||||
2. create the run and tasks with `run init`, `task add`, and `dep add`
|
||||
3. find dispatchable work with `ready`
|
||||
4. save the dispatch response:
|
||||
|
||||
```bash
|
||||
./assets/orch --db ./coord.db --json dispatch --run RUN_ID --task TASK_ID > TMPDIR/dispatch.json
|
||||
```
|
||||
|
||||
5. render a standardized worker brief:
|
||||
|
||||
```bash
|
||||
./assets/orch-worker-brief --dispatch-json TMPDIR/dispatch.json --db ./coord.db > TMPDIR/worker-brief.txt
|
||||
```
|
||||
|
||||
6. spawn one worker sub-agent with:
|
||||
- injected `skills/inbox/`
|
||||
- the generated worker brief
|
||||
- the repository defaults from `AGENTS.md`
|
||||
- model: `gpt-5.4`
|
||||
- reasoning effort: `xhigh`
|
||||
- `fork_context: true` first
|
||||
7. while the worker runs, keep the leader on:
|
||||
- `orch wait`
|
||||
- `orch status`
|
||||
- `orch blocked`
|
||||
- `orch answer`
|
||||
- `orch retry`
|
||||
- `orch reassign`
|
||||
|
||||
## Worker Launch Rules
|
||||
|
||||
- the worker should use `skills/inbox/`, not `skills/orch/`
|
||||
- the worker should claim only the exact `thread_id` from the dispatch result
|
||||
- if `worktree_path` exists, the worker should do all repository writes only inside that worktree
|
||||
- the worker should send progress, blocked questions, success, and failure through `inbox`
|
||||
|
||||
## Why This Layer Exists
|
||||
|
||||
- `orch` remains portable and durable
|
||||
- worker launch stays outside the core CLI
|
||||
- the same dispatch contract can later support Codex sub-agents, `codex exec`, daemons, or operator UI launchers
|
||||
@@ -0,0 +1,41 @@
|
||||
# Worker Brief Template
|
||||
|
||||
`assets/orch-worker-brief` renders a concrete prompt in this shape.
|
||||
|
||||
Use it when a leader has already dispatched a task and now wants to launch a worker sub-agent without hand-writing the thread handoff every time.
|
||||
|
||||
```text
|
||||
Use $inbox at INBOX_SKILL_PATH to act as ASSIGNED_TO on SQLite DB DB_PATH. Only coordinate through the bundled inbox CLI from the skill. Do not use ordinary chat to coordinate with the leader. Do not use orch.
|
||||
|
||||
You are assigned one existing attempt:
|
||||
- run_id: RUN_ID
|
||||
- task_id: TASK_ID
|
||||
- attempt_no: ATTEMPT_NO
|
||||
- assigned_to: ASSIGNED_TO
|
||||
- thread_id: THREAD_ID
|
||||
- execution_mode: analysis|code
|
||||
- task_title: ...
|
||||
- task_summary: ...
|
||||
- base_ref: ...
|
||||
- worktree_path: ...
|
||||
|
||||
Required workflow:
|
||||
1. Fetch or inspect the assigned thread and claim exactly the listed thread_id.
|
||||
2. Inspect the thread with show before making assumptions about the task body or payload.
|
||||
3. Send one in_progress update when real work starts.
|
||||
4. If blocked, send one precise blocked question with update --status blocked and then use wait-reply.
|
||||
5. Finish with done on success or fail on failure.
|
||||
6. Stop after reporting the handled thread_id and a concise outcome summary.
|
||||
|
||||
Rules:
|
||||
- Do not claim any other thread.
|
||||
- Keep all coordination in inbox messages, not ordinary chat.
|
||||
- Do not change the assigned_to, thread_id, or worktree assignment yourself.
|
||||
- If worktree_path exists, perform repository work only inside that path.
|
||||
```
|
||||
|
||||
## Notes
|
||||
|
||||
- The template is intentionally worker-only. Leader control stays with `orch`.
|
||||
- The generated brief should be passed into a spawned worker sub-agent together with `skills/inbox/`.
|
||||
- Keep the main-thread launch parameters in the leader workflow, not in the worker brief.
|
||||
Reference in New Issue
Block a user