outfitter-dispatch 0.2.0__tar.gz → 0.5.0__tar.gz

{outfitter_dispatch-0.2.0 → outfitter_dispatch-0.5.0}/AGENTS.md

@@ -43,12 +43,14 @@ Read `docs/development/design.md` and `.agents/plans/v0/PLAN.md` before implemen
 
 Use the project language consistently:
 
-- **lane** — a managed Codex thread (own or attached). Not "thread", "agent", or "unit" in user-facing text.
+- **lane** — internal term for a managed Codex thread (own or attached) with registry state.
+- **thread** — user-facing Codex conversation/session. Public CLI/help/docs should prefer "thread" unless the managed-lane authority distinction matters.
+- **ref** — dispatch-local short stable selector for a managed lane. Full Codex thread ids are always accepted; titles and `@handles` are mutable labels.
 - **op** — one authored operation (input/output/intent/examples/handler). The contract unit. Not "command" or "tool" (those are surface projections of an op).
 - **surface** — a derived rendering of the op registry: CLI, MCP, remote. Surfaces are projected, never hand-written per-op.
 - **trigger** — an automated when→action→lane binding (time or event). Not "rule" (collides with agent rules), "automation", or "job".
 - **daemon** (`dispatchd`) — the long-lived host owning the app-server and core; the CLI is a thin client to it.
-- **register/registry** — the durable store of lanes and triggers.
+- **register/registry** — the durable store of lanes, refs, sync state, and triggers.
 
 ## Core rules (summary; full detail in `.claude/rules/`)
 

{outfitter_dispatch-0.2.0 → outfitter_dispatch-0.5.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: outfitter-dispatch
-Version: 0.2.0
+Version: 0.5.0
 Summary: Local control plane for orchestrating Codex agent lanes over the Codex App Server.
 Project-URL: Homepage, https://github.com/outfitter-dev/dispatch
 Project-URL: Repository, https://github.com/outfitter-dev/dispatch
@@ -32,6 +32,8 @@ uv tool install outfitter-dispatch
 dispatch --help
 dispatchd --help
 dispatch doctor
+dispatch up --json
+dispatch down --json
 ```
 
 From a source checkout:
@@ -40,34 +42,52 @@ From a source checkout:
 uv sync
 uv run dispatch --help
 uv run dispatch doctor --no-app-server
-uv run dispatch up
+uv run dispatch models --no-refresh
+uv run dispatch up --json
 uv run dispatch daemon status
 ```
 
-Open an owned lane, send it work, and inspect the daemon:
+Create an owned managed thread, send it work, and inspect the daemon:
 
 ```bash
 uv run dispatch new \
   --name docs \
   --cwd /path/to/dispatch \
+  --goal "Finish the docs review." \
   --text "Please summarize the current stack state."
-uv run dispatch lane tail "@[dispatch] docs" --limit 20
-uv run dispatch goal set "@[dispatch] docs" "Finish the docs review."
+uv run dispatch list
+uv run dispatch get <dispatch-ref>
+uv run dispatch tail <dispatch-ref> --limit 20
 uv run dispatch daemon log --limit 10
-uv run dispatch down
+uv run dispatch down --json
 ```
 
-Use owned lanes for writes. Existing desktop Codex threads can be attached, but v0 treats
-attached lanes as observe-only: mutating commands such as `send`, `stop`, `lane archive`,
-`goal set`, `goal clear`, `lane fork`, `lane rollback`, and `lane compact` are blocked by
-ADR-0005.
+Use owned managed threads for turn-writing work. Existing desktop Codex threads can be attached as
+managed threads, but ADR-0005 still blocks turn-writing and history-mutating commands such
+as `send`, `stop`, `goal set`, and `goal clear` on attached lanes. Every managed
+thread has a dispatch-local `ref`; full Codex thread UUIDs remain accepted everywhere.
+Titles and `@handles` are mutable convenience labels, not stable identity. Metadata
+lifecycle actions (`rename`, `archive`, `restore`) can target managed refs or raw
+unmanaged Codex thread ids, and `search` can span both. Attach is metadata-only by
+default; use `dispatch sync <selector>` when you want dispatch to refresh its local
+indexed view of an attached thread.
+
+`new` reports whether the first message was accepted by the App Server, not whether
+assistant work completed. Use `get` to inspect the latest turn state and persisted
+App Server errors, or `watch` for a bounded live event sample. Slash commands in
+`--text` are plain text; use `--goal` when creating a native App Server goal.
+Use `dispatch models` before pinning model or service-tier presets; Dispatch
+resolves aliases such as `fast` from the live App Server model catalog and keeps
+omitted model/tier values on Codex defaults.
 
 For the operator guide, CLI/MCP examples, triggers, and plugin setup, start at
 [`docs/usage/README.md`](docs/usage/README.md).
 
 Start troubleshooting with `dispatch doctor`. It checks PATH visibility, the Codex CLI
 and auth footprint, daemon socket/pidfile state, registry schema/integrity, packaged
-skills/plugin assets, and a low-risk Codex App Server initialize smoke.
+skills/plugin assets, and a low-risk Codex App Server initialize smoke. If doctor reports
+an old registry schema, stop the daemon and run `dispatch registry migrate` before
+starting it again.
 
 ## Agent And Plugin Support
 

{outfitter_dispatch-0.2.0 → outfitter_dispatch-0.5.0}/README.md

@@ -12,6 +12,8 @@ uv tool install outfitter-dispatch
 dispatch --help
 dispatchd --help
 dispatch doctor
+dispatch up --json
+dispatch down --json
 ```
 
 From a source checkout:
@@ -20,34 +22,52 @@ From a source checkout:
 uv sync
 uv run dispatch --help
 uv run dispatch doctor --no-app-server
-uv run dispatch up
+uv run dispatch models --no-refresh
+uv run dispatch up --json
 uv run dispatch daemon status
 ```
 
-Open an owned lane, send it work, and inspect the daemon:
+Create an owned managed thread, send it work, and inspect the daemon:
 
 ```bash
 uv run dispatch new \
   --name docs \
   --cwd /path/to/dispatch \
+  --goal "Finish the docs review." \
   --text "Please summarize the current stack state."
-uv run dispatch lane tail "@[dispatch] docs" --limit 20
-uv run dispatch goal set "@[dispatch] docs" "Finish the docs review."
+uv run dispatch list
+uv run dispatch get <dispatch-ref>
+uv run dispatch tail <dispatch-ref> --limit 20
 uv run dispatch daemon log --limit 10
-uv run dispatch down
+uv run dispatch down --json
 ```
 
-Use owned lanes for writes. Existing desktop Codex threads can be attached, but v0 treats
-attached lanes as observe-only: mutating commands such as `send`, `stop`, `lane archive`,
-`goal set`, `goal clear`, `lane fork`, `lane rollback`, and `lane compact` are blocked by
-ADR-0005.
+Use owned managed threads for turn-writing work. Existing desktop Codex threads can be attached as
+managed threads, but ADR-0005 still blocks turn-writing and history-mutating commands such
+as `send`, `stop`, `goal set`, and `goal clear` on attached lanes. Every managed
+thread has a dispatch-local `ref`; full Codex thread UUIDs remain accepted everywhere.
+Titles and `@handles` are mutable convenience labels, not stable identity. Metadata
+lifecycle actions (`rename`, `archive`, `restore`) can target managed refs or raw
+unmanaged Codex thread ids, and `search` can span both. Attach is metadata-only by
+default; use `dispatch sync <selector>` when you want dispatch to refresh its local
+indexed view of an attached thread.
+
+`new` reports whether the first message was accepted by the App Server, not whether
+assistant work completed. Use `get` to inspect the latest turn state and persisted
+App Server errors, or `watch` for a bounded live event sample. Slash commands in
+`--text` are plain text; use `--goal` when creating a native App Server goal.
+Use `dispatch models` before pinning model or service-tier presets; Dispatch
+resolves aliases such as `fast` from the live App Server model catalog and keeps
+omitted model/tier values on Codex defaults.
 
 For the operator guide, CLI/MCP examples, triggers, and plugin setup, start at
 [`docs/usage/README.md`](docs/usage/README.md).
 
 Start troubleshooting with `dispatch doctor`. It checks PATH visibility, the Codex CLI
 and auth footprint, daemon socket/pidfile state, registry schema/integrity, packaged
-skills/plugin assets, and a low-risk Codex App Server initialize smoke.
+skills/plugin assets, and a low-risk Codex App Server initialize smoke. If doctor reports
+an old registry schema, stop the daemon and run `dispatch registry migrate` before
+starting it again.
 
 ## Agent And Plugin Support
 

{outfitter_dispatch-0.2.0 → outfitter_dispatch-0.5.0}/justfile

@@ -6,6 +6,7 @@ check:
     uv run ruff format --check .
     uv run mypy src tests
     uv run pytest
+    rm -f dist/*.whl dist/*.tar.gz
     uv build
     uv run python scripts/check_package_contents.py
 

{outfitter_dispatch-0.2.0 → outfitter_dispatch-0.5.0}/plugins/dispatch/README.md

@@ -8,16 +8,22 @@ This workspace-local plugin exposes:
   `dispatch mcp`.
 
 The MCP server and skills expose the same derived operation registry as the CLI,
-including lane creation/messaging, bounded tails, native goals, history controls,
-triggers, schemas, and daemon status/log reads.
+including managed-thread creation/messaging, dispatch refs, persisted `tail`,
+bounded live `watch`, native goals, triggers, schemas, model catalog reads, and
+daemon status/log reads.
+`new --goal` creates native App Server goal state; `/goal ...` in message text is
+plain text and should not be used as a goal substitute.
+Use `dispatch models` or the MCP daemon-read `models` op before pinning explicit
+model/service-tier presets.
 
 Run `dispatch doctor` after installing or upgrading dispatch. It verifies the CLI
 entrypoints, Codex CLI/auth footprint, daemon socket/pidfile state, registry
 schema/integrity, packaged skills/plugin assets, and a low-risk App Server
 initialize smoke. Use `dispatch doctor --no-app-server` when you only want local
-install checks.
+install checks. If doctor reports an old registry schema, run `dispatch down`,
+`dispatch registry migrate`, then `dispatch up`.
 
-Run `dispatch up` before MCP tool calls that need the daemon. `dispatch mcp`
+Run `dispatch up --json` before MCP tool calls that need the daemon. `dispatch mcp`
 serves the derived tools over stdio; the daemon remains the executor.
 
 `skills` is a symlink to the repo-root [`../../skills`](../../skills) tree so the plugin

outfitter_dispatch-0.5.0/plugins/dispatch/skills/dispatch/SKILL.md

@@ -0,0 +1,345 @@
+---
+name: dispatch
+description: Use when operating dispatch, creating or attaching Codex lanes, sending/steering/context-injecting/stopping through dispatch, managing triggers, checking daemon status/logs, or configuring the dispatch MCP/plugin surface. Not for changing dispatch source code; use AGENTS.md for implementation work.
+metadata:
+  short-description: Operate the dispatch control plane
+---
+
+# dispatch
+
+Use `$dispatch` to operate the local dispatch control plane. dispatch owns one
+`codex app-server` through a daemon and exposes one authored op registry through
+CLI and MCP surfaces.
+
+For source changes, read the repo-root `AGENTS.md` instead. This skill is for
+using the tool.
+
+## Command Surface
+
+When you are in this repo, prefer the in-tree command:
+
+```bash
+uv run dispatch --help
+```
+
+The current canonical operator grammar is:
+
+- health: `doctor`
+- daemon process: `up`, `down`
+- daemon reads: `daemon status`, `daemon log`
+- registry recovery: `registry migrate`
+- model catalog: `models`
+- thread lifecycle/read/search: `new`, `attach`, `list`, `list --unmanaged`,
+  `get`, `sync`, `tail`, `watch`, `search`
+- thread actions: `rename`, `archive`, `restore`
+- message verbs: `send`, `stop`
+- goals: `goal status`, `goal set`, `goal clear`
+- triggers: `trigger add`, `trigger list`, `trigger rm`, `trigger pause`,
+  `trigger resume`
+- schemas/MCP: `schema <command>`, `mcp`
+
+Successful CLI output is JSON-shaped. Use `--json` in scripts when you want the
+machine-output contract to be explicit.
+
+## Start Or Inspect The Daemon
+
+```bash
+uv run dispatch doctor --no-app-server
+uv run dispatch up --json
+uv run dispatch daemon status
+uv run dispatch daemon log --limit 10
+```
+
+Use `uv run dispatch doctor` before relying on live thread operations in a new or
+untrusted environment. It checks PATH visibility, Codex CLI/auth footprint,
+daemon socket/pidfile state, registry schema/integrity, packaged skills/plugin
+assets, and a low-risk Codex App Server initialize smoke. Use `--no-app-server`
+when you only need local install/runtime diagnostics.
+
+If doctor reports an old registry schema, run `uv run dispatch down`, then
+`uv run dispatch registry migrate`, then `uv run dispatch up --json`.
+
+Stop only when it is clearly your daemon/session to stop:
+
+```bash
+uv run dispatch down
+```
+
+Runtime state defaults to `~/.dispatch`. Use `DISPATCH_HOME` for isolation when
+testing. Do not point tests at the user's live `~/.codex`; the repo integration
+suite uses an isolated `CODEX_HOME`.
+
+## Thread Selectors And Lane Rules
+
+Every managed thread has a stored dispatch-local `ref`. Prefer refs for command
+arguments. The full Codex thread id is always accepted. Titles and `@handles`
+are mutable convenience labels; use them only when a unique human label is more
+useful than a ref.
+
+Owned lanes are created by dispatch and are writable. Prefer `new` for a
+configured managed thread; it applies `.dispatch/config.toml`, presets, name
+prefixes, and can send an initial turn:
+
+```bash
+uv run dispatch new --name my-lane --cwd /path/to/project --text "Do the bounded thing."
+uv run dispatch new --name my-lane --goal "Loop until green." --text "Start with tests."
+uv run dispatch new --name my-lane --preset reviewer --no-send
+```
+
+Use `--goal` for a native App Server goal before the initial turn. Do not put
+`/goal ...` in `--text`; dispatch treats slash commands as plain text and rejects
+that shape so agents do not create a thread that only looks goal-driven.
+
+`new` returns `message_accepted`, not proof of assistant completion. After launch,
+use `get` to check `latest_turn`, `tail` for persisted history, or `watch` for a
+bounded live sample.
+
+Before choosing explicit `--model`, `--model-provider`, or `--service-tier`
+values, ask dispatch for the live catalog:
+
+```bash
+uv run dispatch models
+uv run dispatch models --no-refresh
+uv run dispatch schema models
+```
+
+Omit model/tier values when Codex defaults are acceptable. If a preset uses a
+user-facing tier such as `fast`, Dispatch resolves it through `model/list`
+service tiers before starting the thread. Do not guess current model ids from
+memory; use the catalog output and its `aliases` field.
+
+Attached lanes are existing desktop Codex threads registered by raw thread id:
+
+```bash
+uv run dispatch attach <codex-thread-id>
+uv run dispatch attach <codex-thread-id> --sync
+```
+
+Attached lanes are managed by dispatch but are not turn-writable in v0. Do not
+try turn-writing or history-mutating commands such as `send`, `stop`,
+`goal set`, `goal clear`, `lane fork`, `lane rollback`, or `lane compact` on
+attached lanes. Explicit metadata/lifecycle commands (`rename`, `archive`,
+`restore`) are allowed because they do not start turns or mutate turn history.
+ADR-0005 and ADR-0018 keep this boundary locked because desktop Codex and
+dispatch run separate app-server processes and there is no cross-process write
+interlock.
+
+Attach is compact by default: it verifies the thread with
+`thread/read(includeTurns:false)`, registers metadata, and does not resume turn
+history. Use `--sync` or `sync` when you want dispatch to refresh its local
+indexed view.
+
+```bash
+uv run dispatch sync <dispatch-ref-or-thread-id>
+uv run dispatch sync <dispatch-ref-or-thread-id> --full
+```
+
+Sync indexes source identity, sync state, latest event time, latest turn id, and
+bounded top+tail JSONL facts when Codex exposes a rollout path. It does not copy
+the full transcript by default and it does not grant write authority to attached
+lanes.
+
+## Discover Sessions
+
+`list` shows threads dispatch already manages. `list --unmanaged` lists
+persisted Codex sessions that are not registered in dispatch. It uses App Server
+`thread/list` in state-db-only mode, asking for active sessions sorted by recent
+updates. It is read-only and does not resume or register anything:
+
+```bash
+uv run dispatch list
+uv run dispatch list --unmanaged --limit 20
+```
+
+Use a discovered session `id` with `attach <id>`.
+
+## Search And Thread Actions
+
+Use top-level actions when you want to work with either managed threads or raw
+unmanaged Codex thread ids:
+
+```bash
+uv run dispatch rename @my-lane my-lane-final
+uv run dispatch archive <codex-thread-id>
+uv run dispatch restore @my-lane
+```
+
+`restore` only unarchives; it does not resume or start a turn.
+
+Use `search` before attaching when you need to find the right existing thread:
+
+```bash
+uv run dispatch search "schema drift"
+uv run dispatch search "schema drift" --managed
+uv run dispatch search "schema drift" --unmanaged
+uv run dispatch search "schema drift" --thread <dispatch-ref>
+uv run dispatch search "schema drift" --repo .
+uv run dispatch search "schema drift" --dir /path/to/project
+uv run dispatch search "schema drift" --since 2026-06-01 --until 2026-06-05
+```
+
+Broad search uses experimental App Server `thread/search` plus dispatch-side
+filters. Lane-focused search reads one thread transcript and scans locally.
+Sync is separate: `sync` refreshes dispatch's local index for a managed
+lane, but it does not attach unmanaged sessions or grant write authority.
+
+## Message Verbs
+
+`send` is the primary way to put work or context into a lane:
+
+```bash
+uv run dispatch send @my-lane "Do the bounded thing."
+uv run dispatch send @my-lane "Focus on docs first." --steer
+uv run dispatch send @my-lane "Stop and do this instead." --interject
+uv run dispatch send @my-lane "Context: use lane publicly, thread internally." --context
+uv run dispatch send @my-lane "After this finishes, summarize risks." --mode queue
+uv run dispatch send @my-lane "Can you check this?" --intro
+```
+
+The mode flags and `--mode send|steer|queue|interject|context` are mutually
+exclusive. `--queue` stores the message durably and starts one queued turn when
+the lane is idle.
+
+Use `--intro` when you are sending from one managed Codex thread to another and
+want the recipient to know how to reply through dispatch. It derives the sender
+from `CODEX_THREAD_ID`, so the current thread must already be managed.
+
+Use `stop` to cancel the active turn without replacement text:
+
+```bash
+uv run dispatch stop <dispatch-ref>
+```
+
+Destroy-intent commands prompt by default. In scripts, use explicit confirmation:
+
+```bash
+uv run dispatch archive <dispatch-ref> --yes --json
+uv run dispatch trigger rm <trigger-id> --yes --json
+```
+
+For short inter-lane chat, use the companion `$dm` skill, which is backed by
+`dispatch send`.
+
+## History, Watch, And Goals
+
+Use `get` for compact managed-thread metadata:
+
+```bash
+uv run dispatch get <dispatch-ref>
+```
+
+Check `latest_turn` when a message was accepted but no assistant work is visible.
+It records the latest observed turn id, status, and App Server error text/time for
+failed turns.
+
+Use `tail` for persisted turn history:
+
+```bash
+uv run dispatch tail <dispatch-ref> --limit 50
+```
+
+`tail` uses App Server `includeTurns`, which is not available for ephemeral
+threads.
+
+Use `watch` for a bounded live event sample. It returns raw App
+Server method/params until a limit or timeout, and it is not an infinite tail:
+
+```bash
+uv run dispatch watch <dispatch-ref> --limit 20 --timeout 10
+```
+
+Use native goals on owned lanes when a worker has a durable objective:
+
+```bash
+uv run dispatch goal set @my-lane "Loop until checks are green."
+uv run dispatch goal status <dispatch-ref>
+uv run dispatch goal clear <dispatch-ref>
+```
+
+Goals require non-ephemeral App Server threads.
+
+`tail --follow` is not canonical; use `watch`.
+
+## Markdown Thread Links
+
+Use readable handles plus Codex thread URIs in human-facing text. Compose a
+Markdown link whose label is the handle and whose destination is the Codex URI:
+
+```markdown
+label: @Target
+destination: codex://threads/<codex-thread-id>
+```
+
+Use raw thread ids for `attach`. Use refs or full thread ids for dispatch
+thread arguments.
+
+## Triggers
+
+A trigger binds `when -> action -> lane`.
+
+```bash
+uv run dispatch trigger add \
+  --name pulse \
+  --lane <dispatch-ref> \
+  --when interval \
+  --seconds 1800 \
+  --action send \
+  --text "Check in briefly."
+```
+
+Use `--idle-only`, `--min-interval`, and `--dedupe` to reduce noisy automation.
+Remember that dedupe state is process-local and resets when the daemon restarts.
+
+```bash
+uv run dispatch trigger list
+uv run dispatch trigger pause <trigger-id>
+uv run dispatch trigger resume <trigger-id>
+uv run dispatch trigger rm <trigger-id>
+```
+
+## Schemas
+
+Use `schema` for derived input/output schemas:
+
+```bash
+uv run dispatch schema send
+uv run dispatch schema "list --unmanaged"
+uv run dispatch schema models
+uv run dispatch schema "goal set"
+```
+
+Prefer `schema` for `jq`/automation field discovery. It is derived from the same
+op registry as CLI and MCP, including composed spellings like `list --unmanaged`.
+
+## MCP And Plugin
+
+The MCP server is:
+
+```bash
+uv run dispatch mcp
+```
+
+The MCP surface is grouped for agent ergonomics, not one tool per CLI
+subcommand. Tools are grouped by workflow and safety boundary, and each call
+selects an `op` inside the tool. In this repo, the workspace-local Codex plugin
+lives at `plugins/dispatch`. It exposes these skills and the same MCP registry.
+Use the daemon-read MCP tool's `models` op before setting explicit model or
+service-tier arguments.
+If the plugin does not appear immediately, restart Codex for the workspace.
+Installed PyPI packages also include read-only copies of these skills and the
+plugin bundle under `outfitter.dispatch.assets`; use the repo copies for editing.
+
+## Guardrails
+
+- Do not mutate source files, Git, PRs, Graphite, or tracker state as part of
+  ordinary dispatch operation.
+- Do not install launchd autostart unless the user explicitly asks.
+- Start troubleshooting with `dispatch doctor`; use its recovery hints rather
+  than guessing about stale sockets, PATH, auth, or registry shape.
+- If doctor reports an old registry, stop the daemon and run
+  `dispatch registry migrate` before starting it again.
+- Do not describe `tail --follow` as canonical or streaming forever. Use `watch`
+  for bounded live samples until dispatch grows a subscription-capable control socket.
+- Do not treat `rollback` as file undo.
+- If a request becomes long-running owned work, use a proper delegated lane or
+  goal workflow rather than a casual message.

{outfitter_dispatch-0.2.0 → outfitter_dispatch-0.5.0}/plugins/dispatch/skills/dm/SKILL.md

@@ -21,7 +21,7 @@ Use dispatch first:
 
 ```bash
 uv run dispatch doctor --no-app-server
-uv run dispatch lane list
+uv run dispatch list
 uv run dispatch daemon status
 ```
 
@@ -29,12 +29,12 @@ If the environment is new, run `uv run dispatch doctor` once before messaging.
 Fix PATH, Codex auth, stale daemon files, registry, or plugin asset warnings
 before assuming a DM failure is about the target lane.
 
-The target should be an owned dispatch lane. Attached lanes are observe-only in
-v0, so dispatch will reject write verbs against them.
+The target should be an owned dispatch lane selected by dispatch ref when possible. Attached lanes are not
+turn-writable in v0, so dispatch will reject DM/send verbs against them.
 
-If the user wants to message an existing desktop Codex thread, attach it only
-for observation unless they explicitly choose a different authority model after
-reading ADR-0005.
+If the user wants to message an existing desktop Codex thread, attach/sync it
+only for observation unless they explicitly choose a different authority model
+after reading ADR-0005.
 
 ## Handles And URIs
 
@@ -47,7 +47,7 @@ label: @Target
 destination: codex://threads/<target-thread-id>
 ```
 
-Use the lane handle or lane id for `dispatch send`. Use the URI link in
+Use the dispatch ref or full thread id for `dispatch send`. Use the URI link in
 the message body so the recipient and the human can open the thread directly.
 
 ## Message Shape
@@ -65,25 +65,27 @@ Contract: read-only, brief answer, reply in this lane unless asked otherwise.
 Then deliver it:
 
 ```bash
-uv run dispatch send @Target '<message>'
+uv run dispatch send <target-ref> '<message>' --intro
 ```
 
 Keep DMs conversational and bounded. Prefer one ask. Include only the context
 needed for the target lane to answer without reading the sender's full
-transcript. Do not use `$dm` to smuggle in broad implementation work.
+transcript. If the current Codex thread is not managed by dispatch, omit
+`--intro` and include the sender link manually. Do not use `$dm` to smuggle in
+broad implementation work.
 
 ## Harvesting
 
-`dispatch send` starts the target turn. Use `dispatch lane get` and `dispatch daemon log`
-to confirm lane state and accepted actions:
+`dispatch send` starts the target turn. Use `dispatch get` and `dispatch daemon log`
+to confirm thread state and accepted actions:
 
 ```bash
-uv run dispatch lane get @Target
+uv run dispatch get <target-ref>
 uv run dispatch daemon log --limit 10
 ```
 
-Important v0 limitation: `dispatch lane get` is lane metadata, not a transcript
-reader. Use `dispatch lane tail @Target --limit 50` for persisted history when
+Important v0 limitation: `dispatch get` is thread metadata, not a transcript
+reader. Use `dispatch tail <target-ref> --limit 50` for persisted history when
 the lane is non-ephemeral, or open the Codex thread link. Do not pretend
 dispatch harvested text it cannot currently read.
 

{outfitter_dispatch-0.2.0 → outfitter_dispatch-0.5.0}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "outfitter-dispatch"
-version = "0.2.0"
+version = "0.5.0"
 description = "Local control plane for orchestrating Codex agent lanes over the Codex App Server."
 readme = "README.md"
 requires-python = ">=3.13"