agent-conveyor 0.1.13 → 0.1.15

package/docs/manager-recipes.md

@@ -24,6 +24,7 @@ Tools: verification.run_tests, context.fetch_prs
 Epilogues: draft-pr, record-handoff
 Cleanup: compact between child boards after saved handoff
 Evidence gates: child receipt, focused verification, adversarial review, PR/CI/merge or satisfied_on_main
+Final report: record manager closeout proof separately from accepted worker criteria
 Not allowed: merge without green CI; compact/clear before handoff; run two child boards at once
 User confirmed: yes
 ```
@@ -48,6 +49,8 @@ inspection while Dispatch is writing to the same `--path` database.
 | UX Polish Loop | Worker should iterate on visible UI quality | guided or strict | screenshots, visual diff, browser evidence, `adversarial_check` | compact by default |
 | Nudge / What's Next Manager | Manager should observe, ask status, and negotiate criteria | guided | manager decision, worker receipt, accepted criteria | off by default |
 | PR/CI/Merge Ralph Loop | Manager should drive delivery through PR, CI, merge, handoff | strict | PR URL, green CI, merge receipt, adversarial proof | clear after handoff |
+| Autonomous Ship-It Loop | Manager may push, open PRs, monitor CI, fix bounded conflicts, and merge | strict | branch, PR, CI, mergeability, manager decision, merge, post-merge, adversarial proof | clear after handoff |
+| Creative Ops Campaign | One manager should supervise multiple Codex app worker slots for channel-specific creative assets | strict | campaign dashboard, slot lifecycle, assignment receipts, asset review receipts, human publish gate | rotate owned stale workers only |
 
 Two support patterns apply across recipes:
 
@@ -56,6 +59,12 @@ Two support patterns apply across recipes:
 - **Recovery / Resume / Handoff**: use saved config, handoff, replay, audit,
   telemetry, and inbox state to resume a managed task safely.
 
+Across all recipes, accepted criteria should describe worker/task deliverables.
+Manager closeout mechanics such as `finish-task`, `--require-criteria-audit`,
+final task state, heartbeat teardown, and final manager reporting are final
+report or audit evidence. Do not seed them as accepted worker criteria unless
+the task is explicitly Conveyor closeout QA.
+
 ## GoalBuddy Conveyor
 
 Use this when the user says things like "make GoalBuddy boards", "run the
@@ -248,6 +257,150 @@ sequenceDiagram
   M->>W: Clear after saved handoff and worker_compact_clear permission
 ```
 
+## Autonomous Ship-It Loop
+
+Use this when the operator explicitly wants a manager-worker pair to ship a
+bounded repo task through branch push, PR creation, CI monitoring, conflict
+repair, and merge. This recipe is stricter than a PR/CI/Merge Ralph loop:
+green CI is necessary, but never sufficient. The manager must also record a
+fresh mergeability check, an explicit manager merge decision, the merge receipt,
+post-merge verification, and structured adversarial proof.
+
+Suggested setup:
+
+```bash
+conveyor loop-templates --create-run "$TASK" \
+  --template ship_it_loop \
+  --max-iterations 2 \
+  --current-iteration 1 \
+  --json
+
+conveyor manager-config "$TASK" \
+  --mode strict \
+  --objective "Ship the bounded repo task through branch, PR, CI, conflict handling, manager merge decision, merge, and post-merge verification." \
+  --acceptance "Branch, PR URL, green CI, clean mergeability, manager merge decision, merge receipt, post-merge verification, and adversarial proof are recorded before closeout." \
+  --acceptance "Blocked conflict loops stop with retry count, last sanitized evidence, and next exact operator action." \
+  --permit repo.push_branch \
+  --permit repo.open_pr \
+  --permit repo.monitor_ci \
+  --permit repo.resolve_conflicts \
+  --permit repo.merge_green_pr \
+  --allow-worker-compact-clear \
+  --tool verification.run_tests \
+  --tool context.fetch_prs
+```
+
+Conversation storyboard:
+
+```mermaid
+sequenceDiagram
+  participant M as Manager
+  participant D as Dispatch
+  participant W as Worker
+  M->>W: Ask for bounded implementation and local proof
+  W->>D: completion event with branch/test receipt
+  D->>M: worker_task_complete notification
+  M->>M: Verify diff, branch receipt, and push authority
+  M->>M: Open PR only with repo.open_pr permission
+  M->>M: Monitor CI and mergeability; request conflict fixes only within policy
+  M->>M: Record explicit manager_merge_decision
+  M->>M: Merge only with repo.merge_green_pr plus post-merge/adversarial proof
+```
+
+Fail closed on these conditions:
+
+- no explicit permission for the requested repo side effect;
+- CI green but mergeability, manager decision, or post-merge proof is missing;
+- conflict retries reach the configured limit;
+- a worker proposes merge based only on its own completion claim;
+- the live manager/worker transcript is not reviewable through the app or tmux
+  session.
+
+Local proof:
+
+```bash
+conveyor qa-plan ship-it-loop
+conveyor qa-run ship-it-loop --receipt-output /tmp/ship-it-loop-receipt.json --json
+```
+
+## Creative Ops Campaign
+
+Use this when one manager should coordinate multiple Codex app worker sessions
+for channel-specific creative work such as YouTube, TikTok, LinkedIn, Facebook,
+image generation prompts, HyperFrames scripts, or reviewable copy drafts.
+This recipe layers campaign state on top of ordinary manager/worker sessions:
+workers remain visible app or tmux sessions, while the campaign record tracks
+slots, channel briefs, assignments, asset receipts, blockers, and review state.
+
+Suggested setup:
+
+```bash
+conveyor campaign create \
+  --name "$CAMPAIGN" \
+  --objective "Produce reviewable creative assets across named channels." \
+  --json
+
+conveyor campaign add-slot \
+  --name "$CAMPAIGN" \
+  --slot-key tiktok \
+  --role-label "TikTok worker" \
+  --channel tiktok \
+  --thread-id "$TIKTOK_THREAD_ID" \
+  --thread-title "TikTok Campaign Worker" \
+  --state active \
+  --json
+
+conveyor campaign brief \
+  --name "$CAMPAIGN" \
+  --channel tiktok \
+  --brief-json '{"format":"9:16","review_gate":"human approval before publish"}' \
+  --json
+
+conveyor dashboard --campaign "$CAMPAIGN" --ensure-dispatch
+```
+
+Manager operating loop:
+
+```bash
+conveyor campaign dashboard --name "$CAMPAIGN" --json
+conveyor campaign assign --name "$CAMPAIGN" --slot "$SLOT_ID" \
+  --title "Draft first-pass TikTok hooks" \
+  --instructions "Create reviewable draft copy only; do not publish." \
+  --status active --json
+conveyor campaign asset --name "$CAMPAIGN" --slot "$SLOT_ID" \
+  --assignment "$ASSIGNMENT_ID" --asset-type copy \
+  --title "TikTok hooks v1" --status needs_review \
+  --prompt-summary "Sanitized prompt summary only." --json
+```
+
+Evidence gates:
+
+- `campaign dashboard --name "$CAMPAIGN" --json` shows every active worker
+  slot, lifecycle state, blockers, approval counts, and `next_manager_action`.
+- Each worker task has a slot-scoped `campaign assign` receipt before work
+  starts and at least one `campaign asset` receipt before it can be reviewed.
+- Human approval is required before public publishing, scheduling, or posting.
+  Use `approved` or `published` asset receipt statuses only to record actual
+  review outcomes; they are not permission to publish by themselves.
+- Stale or context-heavy Codex app workers are rotated only through
+  `campaign rotate-slot` with the exact current `--expected-thread-id`.
+- Finished or replaced workers are archived only through `campaign archive-slot`
+  with the exact current `--expected-thread-id`.
+
+Fail closed on these conditions:
+
+- the manager cannot see the worker slot in `campaign dashboard`;
+- a worker thread id does not match the slot before rotate/archive;
+- a worker asks to publish or schedule without explicit human approval;
+- raw screenshots, private phone content, tokens, JWTs, keys, audio, or
+  unsanitized transcripts would be committed as receipts;
+- dogfood proof is missing but the manager tries to claim the campaign system
+  is fully validated.
+
+This recipe is ready for local dry runs and controlled dogfood. Treat final
+dogfood success as a separate evidence task: the recipe can configure the loop,
+but it does not by itself prove that a real campaign finished.
+
 ## Inbox / No-Tmux App Loop
 
 When a manager or worker is a Codex app session without a tmux pane, Dispatch
@@ -271,6 +424,14 @@ there is no next worker task, the manager should record the terminal decision,
 run `conveyor finish-task "$TASK" --require-criteria-audit`, and explicitly
 report heartbeat teardown status. If the task or binding still appears active,
 report that as a control-plane blocker instead of calling the loop complete.
+That closeout proof belongs in the manager final report or audit receipts, not
+as a blocking accepted criterion for the worker.
+
+For operator review, the live app or tmux session is the primary transcript.
+Any consumed inbox item must be visible in that same session while the turn is
+running: print `CONVEYOR POLL`, `CONVEYOR RECEIVED`, `WORK`, `CONVEYOR SEND`,
+and `DISPATCH` sections. A one-line idle receipt is acceptable only when no
+item is consumed.
 
 When the manager is running in the Codex app and thread tools are available,
 create fresh same-project manager and worker threads with `create_thread`, set
@@ -315,6 +476,9 @@ heartbeat policy and emit the exact Codex app heartbeat automation specs plus a
 bounded Dispatch watch command. `app-autopilot stop` records the teardown policy
 decision; it does not itself delete Codex app automations because that action
 belongs to the Codex app automation layer.
+The emitted heartbeat prompts include the visible-session protocol; do not
+replace them with compact prompts that hide consumed work behind SQLite or
+replay.
 Each operator pulse should inspect `app-autopilot status --json`; if
 `plan.quiescence.recommended_action` is `stop_autopilot`, record
 `app-autopilot stop`, pause/delete the app heartbeat automations, and report the
@@ -334,6 +498,24 @@ record each outcome with `app-wakeup-record-delivery` linked to the dispatch
 receipt. Record healthy roles as `skipped` and missing-thread roles as
 `blocked`; do not treat the app-thread send as task completion.
 
+For worker context cleanup in Codex app sessions, prefer fresh-worker rotation
+over remote slash commands. Run:
+
+```bash
+conveyor app-worker-rotation-plan "$TASK" \
+  --old-worker-thread-id "$OLD_WORKER_THREAD_ID" \
+  --require-handoff \
+  --json
+```
+
+Only act on plans where `eligible=true`. First create the replacement worker
+thread with the emitted prompt, then archive exactly the
+`archive_old_worker_thread.thread.id` from the plan, and finally record the
+result with the emitted `record_command`. Conveyor re-checks that the old thread
+still belongs to the active bound worker before updating the worker session to
+the new thread id. Never archive a manager thread, an unrelated worker thread,
+or any thread id that did not come from the current rotation plan.
+
 The saved dogfood example is
 `docs/goals/live-codex-app-inbox-drill/notes/T001-live-drill.md`. It proves
 manager-to-worker `nudge_worker` delivery and worker-to-manager

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "agent-conveyor",
-  "version": "0.1.13",
+  "version": "0.1.15",
   "description": "Local agent manager/worker conveyor control plane for Codex sessions.",
   "license": "MIT",
   "type": "module",

package/skills/manage-codex-workers/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: manage-codex-workers
-description: Use when the user asks to set up an Agent Conveyor Ralph loop, register an existing Codex session as a worker or manager, create a supervised task, bind a pair, run observation cycles, send nudges, interrupt busy-waits, finish a task, or audit/replay supervision history.
+description: Use when the user asks to set up an Agent Conveyor Ralph loop or autonomous ship-it loop, register an existing Codex session as a worker or manager, create a supervised task, bind a pair, run observation cycles, send nudges, interrupt busy-waits, finish a task, or audit/replay supervision history.
 ---
 
 # Manage Codex Workers
@@ -28,6 +28,26 @@ Max iterations: <number, default 3>
 Require adversarial proof before another worker iteration.
 ```
 
+For repo delivery where the user explicitly grants branch, PR, CI, conflict,
+and merge authority, use the `ship-it-loop` recipe and `ship_it_loop` template
+instead of a generic Ralph loop:
+
+```text
+Use the manage-codex-workers skill.
+
+Set up a Codex app autonomous ship-it loop for <bounded repo task>.
+Manager may push a branch, open a PR, monitor CI, resolve bounded conflicts,
+and merge only after explicit manager merge evidence.
+Max iterations: <number, default 2>
+```
+
+For creative-ops work where the user wants one manager to supervise multiple
+Codex app workers across channels such as YouTube, TikTok, LinkedIn, Facebook,
+image generation, HyperFrames, or copy drafts, use the Creative Ops Campaign
+recipe. It should create campaign records, worker slots, channel briefs,
+slot-scoped assignments, asset receipts, and dashboard status proof. It must
+not imply public publishing or scheduling without explicit human approval.
+
 Skill behavior:
 
 1. Work from `/Users/neonwatty/Desktop/codex-terminal-manager`.
@@ -42,10 +62,19 @@ Skill behavior:
    `fork_thread` unless the user explicitly asks to fork or resume this exact
    conversation. If the current thread is explicitly acting as the manager,
    use the current thread as manager and create only the worker thread.
-5. Create the no-tmux binding with `conveyor create-disposable-binding`
-   using `--template` when a template is known, `--adversarial`, a bounded
-   `--max-iterations`, and `--json`. When step 4 produced app thread ids, pass
-   them through `--manager-codex-app-thread-id`,
+5. Create the no-tmux binding with `conveyor create-disposable-binding`.
+   For same-thread Codex app visible-session loops, prefer
+   `--template app_visible_build_loop` for build/test dogfood or a custom
+   `--required-before-continue adversarial_check` gate; do not choose
+   cleanup-gated templates such as `build_then_clear` or
+   `compact_then_continue` unless the setup creates a fresh worker thread per
+   iteration or has a concrete app-session cleanup receipt path. For an
+   operator-approved ship-it loop, use `--template ship_it_loop`, save the
+   `ship-it-loop` manager recipe, and require branch, push, PR, CI,
+   mergeability, manager merge decision, merge, post-merge, and
+   `adversarial_check` receipts before merge or closeout. Use `--adversarial`,
+   a bounded `--max-iterations`, and `--json`. When step 4 produced app thread
+   ids, pass them through `--manager-codex-app-thread-id`,
    `--manager-codex-app-thread-title`, `--worker-codex-app-thread-id`, and
    `--worker-codex-app-thread-title` so Conveyor can surface app identities in
    `sessions`, `discover`, and setup JSON. If app thread tools are not
@@ -100,6 +129,13 @@ Idle polling rule for Codex app/no-tmux sessions:
   one-iteration Dispatch run before treating the worker pass as reported. A
   direct Codex app final answer is local thread text; it does not notify the
   manager inbox or prove the manager saw the result.
+- The actual manager and worker sessions are the primary human-reviewable
+  transcript. SQLite, replay, and status commands are audit proof, not a
+  substitute for visible work. When a manager or worker consumes an inbox item,
+  it must print live session sections before acting and before final answer:
+  `CONVEYOR POLL`, `CONVEYOR RECEIVED`, `WORK`, `CONVEYOR SEND`, and
+  `DISPATCH`. Idle polls may end with one short `CONVEYOR IDLE` receipt, but
+  consumed work must never be handled silently or only summarized later.
 - Prefer `conveyor app-autopilot start <task> --json` from the operator or
   manager session when setting up a Codex app/no-tmux pair for autonomous
   heartbeat management. It records a durable pair-level heartbeat policy and
@@ -134,6 +170,16 @@ Idle polling rule for Codex app/no-tmux sessions:
   `--delivery-status skipped`; for `blocked_missing_thread`, record
   `--delivery-status blocked`. These delivery receipts audit app-thread wake
   attempts; they do not replace Dispatch inbox, heartbeat, or task evidence.
+- For Codex app/no-tmux worker cleanup, do not rely on sending `/compact` or
+  `/clear` with `send_message_to_thread`; that arrives as ordinary prompt text.
+  Prefer `conveyor app-worker-rotation-plan <task> --old-worker-thread-id
+  <active-worker-thread-id> --require-handoff --json`. Only if the plan reports
+  `eligible=true`, create the replacement worker thread from the emitted
+  `create_replacement_worker_thread.prompt`, archive exactly the emitted
+  `archive_old_worker_thread.thread.id`, then run the emitted
+  `app-worker-rotation-record` command with the new thread id/title. The
+  manager must never archive a thread that is not the active bound worker in the
+  current plan.
 - For bounded Ralph loops, treat `ralph_loop_iteration_advanced` telemetry as
   the receipt that a worker actually consumed and began the requested
   iteration.
@@ -457,7 +503,10 @@ compact progress summary and likely next steps in SQLite. Use `manager-config`
 to save what the manager should check against, how structured supervision
 should be, acceptance criteria, planning/PRD/mockup references, and permissions
 such as `--allow-pr`, `--allow-merge-green`, and
-`--allow-worker-compact-clear`.
+`--allow-worker-compact-clear`. For ship-it loops, also use explicit
+`--permit repo.push_branch`, `--permit repo.monitor_ci`, and
+`--permit repo.resolve_conflicts`; never imply these from a general request to
+"ship it."
 
 ## Manager Recipes
 
@@ -471,6 +520,9 @@ First-draft recipes:
 
 - `GoalBuddy Conveyor` — one parent board, one active child board, PR/CI/merge
   or `satisfied_on_main` proof, and parent receipt update before the next child.
+- `Creative Ops Campaign` — one manager supervises multiple named worker slots
+  for channel-specific creative assets using campaign state, dashboard status,
+  assignment receipts, asset review receipts, and human publish gates.
 - `Test Coverage Loop` — require test coverage evidence plus structured
   adversarial proof before another worker pass.
 - `UX Polish Loop` — require browser/screenshot/visual-diff evidence plus
@@ -479,6 +531,9 @@ First-draft recipes:
   nudge sparingly, and keep permissions minimal.
 - `PR/CI/Merge Ralph Loop` — manage PR readiness, CI, fixes, merge, handoff,
   and compact/clear receipts.
+- `Autonomous Ship-It Loop` — push branch, open PR, monitor CI, handle bounded
+  conflicts, and merge only after manager-owned mergeability, merge decision,
+  post-merge, and adversarial evidence.
 
 Support patterns:
 
@@ -504,10 +559,16 @@ the human interaction in the Codex chat where the user is already working and
 keeps SQLite writes explicit. Use `manager-config --interactive` only as a
 terminal fallback for a human running `conveyor` directly.
 
-Before instructing high-level actions such as PR creation, green PR merge, or
-worker compact/clear, check the saved policy:
+Before instructing high-level actions such as branch push, PR creation, CI
+monitoring, conflict resolution, green PR merge, or worker compact/clear, check
+the saved policy:
 
 ```bash
+conveyor manager-permission my-task repo.push_branch --require
+conveyor manager-permission my-task repo.open_pr --require
+conveyor manager-permission my-task repo.monitor_ci --require
+conveyor manager-permission my-task repo.resolve_conflicts --require
+conveyor manager-permission my-task repo.merge_green_pr --require
 conveyor manager-permission my-task worker_compact_clear \
   --require-handoff --require
 ```
@@ -538,6 +599,11 @@ This command checks `worker_compact_clear`, requires a saved handoff, records a
 durable command, and sends Codex `/compact` to the worker's tmux pane. Use
 `--clear` for `/clear`, or `--prompt-only` to send the conservative
 verify/update-handoff prompt instead of a slash command.
+For Codex app workers, use app worker rotation instead of this tmux slash path:
+`conveyor app-worker-rotation-plan my-task --old-worker-thread-id
+<active-worker-thread-id> --require-handoff --json`, followed by Codex app
+`create_thread`, exact old-worker `set_thread_archived`, and
+`app-worker-rotation-record`.
 
 ## Manager Loop Pattern
 
@@ -581,6 +647,43 @@ child board active, require PR/CI/merge or `satisfied_on_main` proof before
 marking a child done, and update the parent receipt before activating the next
 child.
 
+Natural-language requests such as "run a multi-channel creative ops campaign",
+"have one manager coordinate YouTube, TikTok, LinkedIn, and Facebook workers",
+"generate imagery, HyperFrames, videos, and copy across channels", or "use
+multiple first-time manager guys and girls" should resolve to the Creative Ops
+Campaign recipe unless the user chooses a custom policy. The manager should:
+
+1. Create or reuse a campaign with `conveyor campaign create`.
+2. Create one worker slot per channel or discipline with `campaign add-slot`,
+   preserving Codex app thread ids/titles when available.
+3. Record structured channel briefs with `campaign brief`.
+4. Assign work with `campaign assign` before asking a worker to produce assets.
+5. Record worker output with `campaign asset` using sanitized prompt summaries,
+   asset type, review status, and safe artifact paths.
+6. Use `campaign dashboard --name <campaign> --json` or
+   `dashboard --campaign <campaign>` as the manager status surface.
+7. Rotate stale/context-heavy workers only with `campaign rotate-slot` and an
+   exact `--expected-thread-id`; archive only with `campaign archive-slot` and
+   the exact current thread id.
+8. Treat public publishing, scheduling, posting, external account access,
+   private phone content, raw audio, tokens, JWTs, keys, archives, and IPAs as
+   human-gated or forbidden unless the operator explicitly approves the narrow
+   action.
+
+Do not claim that the campaign system is fully dogfooded merely because the
+recipe was configured. Final campaign dogfood requires dashboard proof, asset
+receipts, manager review decisions, and a separate dogfood receipt or blocker.
+
+Natural-language requests such as "ship this autonomously", "let the manager
+open the PR and merge when green", or "have the manager handle conflicts and
+merge" must resolve to the `ship-it-loop` recipe or an explicit custom policy.
+Use `conveyor qa-plan ship-it-loop` to retrieve the permission boundaries,
+correlation markers, lifecycle evidence template, and negative QA checks. The
+manager must record `branch_ready`, `branch_pushed`, `pr_url`, `ci_green`,
+`mergeability_clean`, `manager_merge_decision`, `merge`,
+`post_merge_verification`, and structured `adversarial_check` evidence before
+treating the loop as merge-ready. CI green is not a merge decision.
+
 ```bash
 conveyor cycle my-task
 # {
@@ -652,6 +755,11 @@ Acceptance criteria are living supervision state, not just setup text. Inspect
   versus follow-up.
 - Record current-task criteria as proposed or accepted, and record follow-up
   criteria as deferred.
+- Keep manager closeout/control-plane proof out of accepted worker criteria.
+  Items such as `finish-task`, `--require-criteria-audit`, final task state,
+  heartbeat teardown, and final manager reporting belong in the manager final
+  report, audit, replay, or epilogue evidence unless the task is explicitly
+  Conveyor closeout QA.
 - Use `conveyor criteria` to accept, satisfy, defer, or reject
   criteria as evidence accumulates.
 - Before finishing, compare the worker's receipts and verification against all
@@ -796,6 +904,31 @@ etc.) run `conveyor db-doctor --live`.
   current manager is a Codex app session with thread tools, send only
   `send_ready=true` wake prompts with `send_message_to_thread`, then record the
   outcome with `app-wakeup-record-delivery`.
+- "fresh worker", "clear app worker", or "rotate Codex app worker": require a
+  saved worker handoff, run `app-worker-rotation-plan` with the active bound
+  worker thread id, create a new same-project worker thread from the emitted
+  prompt, archive only the exact old worker thread id emitted by the plan, and
+  record with `app-worker-rotation-record`. If the plan is blocked or the old
+  id does not exactly match the active bound worker, stop and report the
+  blocker.
+- "set up a Creative Ops Campaign", "run a multi-channel campaign", or "one
+  manager with multiple channel workers": use the Creative Ops Campaign recipe;
+  create or reuse a campaign, add one slot per channel or discipline, record
+  briefs, assign work before worker prompts, require `campaign asset` receipts
+  for outputs, run `campaign dashboard --name <campaign> --json` for manager
+  status, and require exact-thread `campaign rotate-slot`/`campaign
+  archive-slot` for owned worker cleanup. Do not publish or schedule without
+  explicit human approval.
+- "set up an autonomous ship-it loop", "ship this through PR and merge", or
+  "merge when green": resolve to `ship-it-loop` unless the user explicitly
+  chooses a custom policy. Show the locked recipe summary, require explicit
+  operator confirmation for `repo.push_branch`, `repo.open_pr`,
+  `repo.monitor_ci`, `repo.resolve_conflicts`, and `repo.merge_green_pr`, then
+  create or use a `ship_it_loop` run. Before merge, require fresh CI,
+  mergeability, manager merge decision, merge receipt, post-merge verification,
+  and adversarial proof receipts. If conflict retries hit the configured limit,
+  block with sanitized evidence and the next exact action instead of continuing
+  to wake the worker.
 - "register this Codex session as the worker for dashboard setup <CODE>":
   derive `dashboard-<CODE>-worker`, run `conveyor doctor-self`, then
   `conveyor register-worker --name dashboard-<CODE>-worker --pid <PID> --cwd <CWD> --tmux-session <SESSION>`.
@@ -833,6 +966,8 @@ conveyor qa-plan emergent-criteria
 conveyor qa-plan emergent-criteria --json
 conveyor qa-plan tmux-errors
 conveyor qa-plan tmux-errors --json
+conveyor qa-plan ship-it-loop
+conveyor qa-run ship-it-loop --receipt-output /tmp/ship-it-loop-receipt.json --json
 ```
 
 Use `emergent-criteria` when validating a real worker/manager pair through

package/skills/manage-codex-workers/agents/openai.yaml

@@ -1,5 +1,5 @@
 interface:
   display_name: "Manage Codex Workers"
-  short_description: "Manage tmux-backed Codex workers"
-  default_prompt: "Use $manage-codex-workers to start, supervise, or stop a Codex worker with conveyor."
+  short_description: "Manage Codex app or tmux workers"
+  default_prompt: "Use $manage-codex-workers to start, supervise, rotate, or stop Codex worker sessions with conveyor."
   brand_color: "#2563EB"