Add orch Codex launch bridge workflow

2026-03-20 18:28:48 +08:00
parent cf3c3cbe60
commit 7840b2767f
11 changed files with 523 additions and 3 deletions
@@ -29,6 +29,7 @@ Use these defaults unless a case file explicitly overrides them:
 - initialize the shared SQLite DB before launching role agents with `INBOX_SKILL_PATH/assets/inbox --db TMPDIR/coord.db --json init`
 - require the leader to coordinate through the bundled `./assets/orch` CLI from the skill instead of ordinary chat
 - require workers to coordinate through the bundled `./assets/inbox` CLI from their skill instead of ordinary chat
+- launch-bridge cases may use a leader-only topology where the leader spawns worker subagents after dispatch instead of relying on the test-runner to launch separate worker roles
 - validate final run and thread state independently from the main thread after the agents stop
 - create any required Git repo fixture before launching agents for worktree cases

@@ -59,6 +60,12 @@ The role agents are responsible for:
 - coordinating through the bundled CLI and shared DB
 - reporting concrete run ids, thread ids, worktree paths, and key command outcomes back to the test-runner agent

+For launch-bridge cases:
+
+- the leader may be the only top-level role agent
+- that leader is responsible for spawning any worker subagents itself after `dispatch`
+- spawned worker subagents should use the generated worker brief plus `skills/inbox/`, not ordinary chat
+
 The test-runner agent should treat a case as passed only when:

 - all role agents reach a final state without violating the case contract
@@ -173,6 +180,8 @@ Each case file should use this structure:
 | `leader-answers-blocked-task-with-payload-json-through-bundled-cli` | [leader-answers-blocked-task-with-payload-json-through-bundled-cli.md](./leader-answers-blocked-task-with-payload-json-through-bundled-cli.md) | validates that a leader can answer a blocked task with structured payload data only and still drive the run to completion |
 | `leader-retries-failed-task-through-bundled-cli` | [leader-retries-failed-task-through-bundled-cli.md](./leader-retries-failed-task-through-bundled-cli.md) | validates that a leader can reconcile a failed attempt and create a successful retry through the packaged orch skill |
 | `leader-reassigns-blocked-task-through-bundled-cli` | [leader-reassigns-blocked-task-through-bundled-cli.md](./leader-reassigns-blocked-task-through-bundled-cli.md) | validates that a leader can reassign a blocked task from one worker to another and close the run through the packaged orch skill |
+| `leader-dispatches-and-launches-worker-through-codex-bridge` | [leader-dispatches-and-launches-worker-through-codex-bridge.md](./leader-dispatches-and-launches-worker-through-codex-bridge.md) | validates that a leader can dispatch a task, render a standardized worker brief, and launch a worker subagent from the same Codex thread |
+| `strict-worktree-dispatch-launches-worker-through-codex-bridge` | [strict-worktree-dispatch-launches-worker-through-codex-bridge.md](./strict-worktree-dispatch-launches-worker-through-codex-bridge.md) | validates that a leader can launch a code-writing worker subagent from saved dispatch metadata while preserving the assigned worktree contract |

 ## Scope

@@ -182,6 +191,7 @@ In scope:
 - bundled `./assets/orch` CLI usage
 - leader-side run, task, dependency, dispatch, reconcile, answer, retry, reassign, wait, status, and cleanup flows
 - interaction between a leader using `skills/orch/` and workers using `skills/inbox/`
+- leader-side launch-bridge workflows where the leader spawns worker subagents after `dispatch`
 - worktree-backed dispatch and cleanup validation
 - end-to-end run state and thread history validation

@@ -191,6 +201,7 @@ Out of scope:
 - worker-only skill behavior that already belongs under [../inbox-skill/](../inbox-skill/)
 - the separate `council-review` skill package
 - implicit skill triggering without `$orch`
+- changing the core `orch` CLI so it launches workers by itself

 ## Relationship To Other Test Docs