Add orch Codex launch bridge workflow

docs/architecture.md

@@ -52,6 +52,20 @@ Both CLIs should point at the same SQLite file.
 
 This preserves a clean boundary while keeping deployment simple.
 
+## Optional Codex Launch Bridge
+
+Some environments may layer an execution bridge on top of `orch`.
+
+Recommended shape:
+
+- `orch dispatch --json` creates the durable handoff state
+- a leader-side Codex bridge reads the dispatch result
+- that bridge may spawn a worker sub-agent and pass it the mapped `thread_id`, `assigned_to`, and any `worktree_path`
+- the worker still reports only through `inbox`
+
+This bridge belongs above the CLI layer.
+It should not be implemented as core `orch` runtime behavior because worker launch is host-specific while run and attempt state are meant to stay portable.
+
 ## Worker Execution Model
 
 For code tasks, execution should be isolated from the user's primary checkout.
@@ -159,4 +173,5 @@ The intended skill split mirrors the CLI split.
 
 - `inbox` skill: used when an agent needs to fetch work, claim a thread, send progress, ask blocked questions, reply, or return results through `inbox`
 - `orch` skill: used when the leader needs to create runs, decompose tasks, manage dependencies, dispatch ready work, inspect blocks, answer them, retry failures, or reassign work through `orch`; it is not itself the worker launcher
+- `orch` skill may include helper assets for leader-side launch bridges, but the durable source of truth for scheduling remains the `orch` CLI and shared SQLite state
 - `council-review` skill: used when the user explicitly wants a structured three-reviewer brainstorm or review with grouped and tallied recommendations