fix(ce-dispatch): address Codex bot rounds 2-3 on EveryInc#762 + wider audit pass

.compound-engineering/config.local.example.yaml

@@ -12,13 +12,17 @@
 # work_delegate_effort: high     # minimal | low | medium | high | xhigh (omit to use ~/.codex/config.toml default)
 
 # --- Dispatch (external workspace delegation) ---
-# Settings for /ce-dispatch, which fans out plan implementation units to
-# external agent workspaces (e.g., Conductor) via GitHub issues.
+# Settings for /ce-dispatch-beta, which fans out plan implementation units to
+# external agent workspaces (e.g., Conductor) via GitHub issues. The beta
+# suffix follows the beta-skills framework triplet (-beta name +
+# [BETA] description prefix + disable-model-invocation: true); promotion
+# to stable will rename the slash command to /ce-dispatch and update the
+# default labels accordingly.
 
 # dispatch_mode: conductor       # conductor | <other identifier> (default: conductor)
 # dispatch_branch_prefix: dispatch/   # branch prefix suggested in dispatch prompts (default: dispatch/)
 # dispatch_base_branch: main     # PR base branch (default: repo default branch)
-# dispatch_labels: ce-dispatch   # comma-separated labels applied to created issues (default: ce-dispatch)
+# dispatch_labels: ce-dispatch-beta   # comma-separated labels applied to created issues (default: ce-dispatch-beta)
 # dispatch_auto_review: true     # true | false (default: true) -- auto-run ce-code-review on each new PR
 
 # --- Product pulse ---

plugins/compound-engineering/skills/ce-dispatch/references/conductor-notes.md → plugins/compound-engineering/skills/ce-dispatch-beta/references/conductor-notes.md

@@ -1,6 +1,6 @@
 # Conductor Notes
 
-Findings from the public Conductor documentation at https://www.conductor.build/docs (researched at the time `ce-dispatch` was authored). Conductor is the primary integration target for `ce-dispatch`, but the skill is written to be generic over any issue-driven agent workflow — these notes exist so future maintainers can verify or revise the assumptions baked into the skill.
+Findings from the public Conductor documentation at https://www.conductor.build/docs (researched at the time `ce-dispatch-beta` was authored). Conductor is the primary integration target for `ce-dispatch-beta`, but the skill is written to be generic over any issue-driven agent workflow — these notes exist so future maintainers can verify or revise the assumptions baked into the skill.
 
 If Conductor's behavior changes, update both this file and the SKILL.md sections that depend on it (Phase 0 config defaults, Phase 3 issue body conventions, Phase 4 PR/merge guidance).
 
@@ -10,56 +10,56 @@ Source: [From issue to PR](https://www.conductor.build/docs/guides/issue-to-pr)
 
 - Workspace creation is **user-initiated** in the Conductor desktop app (Cmd+Shift+N → choose GitHub or Linear issue). There is no automatic trigger that spins up a workspace the moment a GitHub issue is created — a human picks the issue from a list inside Conductor.
 - When the user picks a GitHub or Linear issue, Conductor creates a workspace and the agent inherits the issue title, description, and context as starting prompt material.
-- There are no documented label or metadata conventions Conductor requires on issues. Any GitHub issue the user can see is a candidate. `ce-dispatch` is therefore free to apply its own label scheme (`ce-dispatch` by default, configurable via `dispatch_labels`) for human filtering rather than to satisfy Conductor.
-- Implication for `ce-dispatch`: the issue body **is** the agent's initial prompt context. Make the body fully self-contained — do not rely on a separate "startup prompt" file Conductor will inject. Any context the in-workspace agent needs (plan path, unit goal, files, patterns, approach, constraints, output contract) must be in the issue body.
+- There are no documented label or metadata conventions Conductor requires on issues. Any GitHub issue the user can see is a candidate. `ce-dispatch-beta` is therefore free to apply its own label scheme (`ce-dispatch-beta` by default, configurable via `dispatch_labels`) for human filtering rather than to satisfy Conductor.
+- Implication for `ce-dispatch-beta`: the issue body **is** the agent's initial prompt context. Make the body fully self-contained — do not rely on a separate "startup prompt" file Conductor will inject. Any context the in-workspace agent needs (plan path, unit goal, files, patterns, approach, constraints, output contract) must be in the issue body.
 
 ## 2. Startup scripts
 
 Source: [Scripts](https://www.conductor.build/docs/reference/scripts), [Setup script reference](https://www.conductor.build/docs/reference/scripts/setup), [conductor.json](https://www.conductor.build/docs/reference/conductor-json).
 
 - Conductor supports three repo-level scripts: `setup` (runs at workspace creation), `run` (Run-button command), `archive` (pre-archive cleanup). Defined in `conductor.json` at the repo root or per-user in Repository Settings.
 - The `setup` script is for **environment preparation** (`npm install`, copy `.env`, build assets, install local plugins) — not for injecting an LLM prompt. There is no documented hook to bake an LLM prompt into a workspace independent of the issue body.
-- Implication for `ce-dispatch`: do not assume any "startup prompt" is wired up. The full agent prompt rides in the issue body. If the target repo has a `conductor.json`, ce-dispatch leaves it alone; if a maintainer wants the CE plugin auto-installed in every workspace, that is a Conductor-level configuration choice, not something `ce-dispatch` writes for them.
+- Implication for `ce-dispatch-beta`: do not assume any "startup prompt" is wired up. The full agent prompt rides in the issue body. If the target repo has a `conductor.json`, ce-dispatch-beta leaves it alone; if a maintainer wants the CE plugin auto-installed in every workspace, that is a Conductor-level configuration choice, not something `ce-dispatch-beta` writes for them.
 
 ## 3. Worktree and branch management
 
 Source: [Isolated workspaces](https://www.conductor.build/docs/concepts/workspaces-and-branches), [Workflow](https://www.conductor.build/docs/concepts/workflow).
 
 - Each workspace = one git working tree on its own branch. One workspace per branch; a branch can only be checked out in one workspace at a time.
 - Conductor auto-creates a branch when a workspace starts. The first chat typically prompts the in-workspace agent to **rename** the branch to match the work (per the Conductor doc note: "When you start your first chat, Conductor will instruct the agent to rename this branch to match what you're working on"). Workspaces also have a directory name (e.g., `warsaw-v2`) separate from the git branch.
-- There is no enforced branch naming convention from Conductor — naming is left to the in-workspace agent / user. `ce-dispatch` therefore **suggests** a branch name in the issue body (e.g., `dispatch/U3-add-rate-limiter` derived from `dispatch_branch_prefix` + U-ID + slugged unit goal) and lets the agent honor it. The metadata block records the expected branch so Phase 4 monitoring can match PRs to U-IDs even if the agent renamed the branch.
+- There is no enforced branch naming convention from Conductor — naming is left to the in-workspace agent / user. `ce-dispatch-beta` therefore **suggests** a branch name in the issue body (e.g., `dispatch/U3-add-rate-limiter` derived from `dispatch_branch_prefix` + U-ID + slugged unit goal) and lets the agent honor it. The metadata block records the expected branch so Phase 4 monitoring can match PRs to U-IDs even if the agent renamed the branch.
 
 ## 4. Agent configuration
 
 Source: [Agent modes](https://www.conductor.build/docs/concepts/agent-modes), [Setup script reference](https://www.conductor.build/docs/reference/scripts/setup).
 
 - Conductor runs Claude Code or Codex inside the workspace. Skills work in both. Repository instructions (`AGENTS.md`, `CLAUDE.md`) and skills the user already has installed are available.
-- The CE plugin is **not** automatically installed in every Conductor workspace. It must be either (a) already installed at the user/system level so it's available in every workspace, or (b) installed by the repo's `setup` script. `ce-dispatch` does not enforce this — the dispatch prompt's `<ce-plugin>` block tells the in-workspace agent how to detect and use the plugin **if available**, and what to do otherwise (follow the prompt sections directly).
+- The CE plugin is **not** automatically installed in every Conductor workspace. It must be either (a) already installed at the user/system level so it's available in every workspace, or (b) installed by the repo's `setup` script. `ce-dispatch-beta` does not enforce this — the dispatch prompt's `<ce-plugin>` block tells the in-workspace agent how to detect and use the plugin **if available**, and what to do otherwise (follow the prompt sections directly).
 
 ## 5. PR lifecycle
 
 Source: [Workflow](https://www.conductor.build/docs/concepts/workflow), [From issue to PR](https://www.conductor.build/docs/guides/issue-to-pr).
 
 - Conductor has a built-in **`Create PR`** action (Cmd+Shift+P). When invoked, Conductor sends the current diff and repo context to the in-workspace agent so it can draft the PR description.
 - After the PR exists, Conductor's Checks tab follows GitHub Actions, deployments, review comments, and todos.
-- Implication for `ce-dispatch`: do not fight Conductor's PR flow. The dispatch prompt's `<constraints>` tells the in-workspace agent to commit, push, and **open a PR** when the unit is complete — whether via Conductor's `Create PR` UI, the `ce-commit-push-pr` skill (when CE plugin is installed), or a manual `gh pr create`. Any of those produces a real GitHub PR, which is what `ce-dispatch` Phase 4 monitors via `gh pr view`/`gh pr checks`.
+- Implication for `ce-dispatch-beta`: do not fight Conductor's PR flow. The dispatch prompt's `<constraints>` tells the in-workspace agent to commit, push, and **open a PR** when the unit is complete — whether via Conductor's `Create PR` UI, the `ce-commit-push-pr` skill (when CE plugin is installed), or a manual `gh pr create`. Any of those produces a real GitHub PR, which is what `ce-dispatch-beta` Phase 4 monitors via `gh pr view`/`gh pr checks`.
 
 ## 6. API and CLI
 
 - The public docs do not describe a CLI or HTTP API for **programmatic** workspace creation. Workspace creation is desktop-app driven (keyboard shortcut or `...` menu on the New Workspace button).
 - There is a [Deep Links](https://www.conductor.build/docs/reference/deep-links) reference (`conductor://` URLs) that can open Conductor and trigger actions, but it's not a substitute for an API.
-- Implication for `ce-dispatch`: the skill is **not** trying to programmatically create Conductor workspaces. It creates GitHub issues; the human (or Conductor user) opens those issues as workspaces in Conductor. This is intentional — it keeps `ce-dispatch` decoupled from any one platform's workspace orchestration.
+- Implication for `ce-dispatch-beta`: the skill is **not** trying to programmatically create Conductor workspaces. It creates GitHub issues; the human (or Conductor user) opens those issues as workspaces in Conductor. This is intentional — it keeps `ce-dispatch-beta` decoupled from any one platform's workspace orchestration.
 
-## What `ce-dispatch` does NOT assume about Conductor
+## What `ce-dispatch-beta` does NOT assume about Conductor
 
 - That a specific label name is required for issues to be picked up — Conductor accepts any visible issue.
 - That Conductor will rename branches to a specific pattern — it lets the in-workspace agent decide.
 - That a startup script can deliver an LLM prompt — the issue body is the prompt.
-- That Conductor exposes an API for headless workspace creation — `ce-dispatch` stays at the issue layer.
+- That Conductor exposes an API for headless workspace creation — `ce-dispatch-beta` stays at the issue layer.
 
-## What `ce-dispatch` is opinionated about (and why)
+## What `ce-dispatch-beta` is opinionated about (and why)
 
-- **Label** (default `ce-dispatch`): so humans can filter their issue list; not a Conductor requirement.
+- **Label** (default `ce-dispatch-beta`): so humans can filter their issue list; not a Conductor requirement.
 - **Branch name suggestion** (`dispatch_branch_prefix` + U-ID + slug): so the orchestrator can correlate PRs back to U-IDs in Phase 4; the in-workspace agent is encouraged but not forced to honor it.
 - **HTML metadata comment in the issue body** (plan path, U-ID, dependencies, expected branch, base branch): structured data the orchestrator parses on subsequent runs to detect dependency state without rebuilding the graph from scratch. The HTML comment renders invisibly to humans on GitHub but stays parseable.
 - **PR-based output contract** (a `## Dispatch Result` section in the PR description): replaces ce-work-beta's `--output-schema` JSON, since dispatched agents don't have a shared scratch directory with the orchestrator. The PR description is the durable handoff surface.

plugins/compound-engineering/skills/ce-dispatch/references/dispatch-prompt-template.md → plugins/compound-engineering/skills/ce-dispatch-beta/references/dispatch-prompt-template.md

@@ -13,7 +13,7 @@ Render exactly these sections, in this order. Keep the XML tags so downstream to
 [One paragraph orienting the in-workspace agent:
 - Plan file path (repo-relative) the unit was extracted from
 - One-sentence project context (read from plan frontmatter / repo README if available)
-- Note that this issue was created by ce-dispatch and corresponds to a single
+- Note that this issue was created by ce-dispatch-beta and corresponds to a single
   implementation unit (or a small batch of independent units) from the plan.
 The agent should `Read` the plan file for the full picture before starting.]
 </context>
@@ -28,8 +28,12 @@ issues -- otherwise prefer one issue per unit.]
 </task>
 
 <files>
-[Combined file list from the unit(s) -- files to create, modify, or read.
-Use the plan's `Files:` section as the source of truth. Repo-relative paths only.]
+[Combined file list from the unit(s) -- files to Create, Modify, or Test.
+Use the plan's `**Files:**` section as the source of truth (canonical sub-bullets:
+`Create:`, `Modify:`, `Test:` -- per the ce-plan unit template). `Read:` is also
+accepted as an alias when the plan was hand-edited or produced outside ce-plan.
+Repo-relative paths only. Do not silently drop `Test:` paths -- they are the
+test files the agent is expected to author or update, not just reference.]
 </files>
 
 <patterns>
@@ -118,7 +122,7 @@ without it.
 
 <output-contract>
 Report the result via the **PR description**, not via a JSON file or scratch
-artifact -- ce-dispatch reads the PR body to drive Phase 4 monitoring,
+artifact -- ce-dispatch-beta reads the PR body to drive Phase 4 monitoring,
 review, and merge gating.
 
 Render this section verbatim under a top-level `## Dispatch Result` heading
@@ -151,10 +155,10 @@ If verification was not possible, say why.
 
 ## Metadata footer
 
-Append the following HTML comment **outside** the `<output-contract>` block, at the very end of the rendered issue body. The comment is invisible in the GitHub UI but parseable by `ce-dispatch` on subsequent runs (and other tooling that wants to round-trip dispatch state).
+Append the following HTML comment **outside** the `<output-contract>` block, at the very end of the rendered issue body. The comment is invisible in the GitHub UI but parseable by `ce-dispatch-beta` on subsequent runs (and other tooling that wants to round-trip dispatch state).
 
 ```html
-<!-- ce-dispatch-metadata
+<!-- ce-dispatch-beta-metadata
 plan: <repo-relative plan path>
 unit_ids: <comma-separated U-IDs in this dispatch, e.g. U3 or U3,U5>
 dependencies: <comma-separated U-IDs this dispatch depends on, or "none">
@@ -168,7 +172,7 @@ dispatched_at: <ISO 8601 UTC timestamp>
 ## What the orchestrator does NOT include in the prompt
 
 - **Scratch directory paths**: the in-workspace agent has its own filesystem; do not reference paths from the orchestrator's machine.
-- **Codex CLI invocation flags or `--output-schema` artifacts**: `ce-dispatch` does not delegate to `codex exec` directly; the in-workspace agent runs whatever harness Conductor (or another platform) provides.
+- **Codex CLI invocation flags or `--output-schema` artifacts**: `ce-dispatch-beta` does not delegate to `codex exec` directly; the in-workspace agent runs whatever harness Conductor (or another platform) provides.
 - **Orchestrator-private state**: dependency graphs, parallel-safety analysis, or the dispatch order. The in-workspace agent only needs its own unit context.
 
 ## Token budget guidance

plugins/compound-engineering/skills/ce-plan/SKILL.md

@@ -904,7 +904,7 @@ After document review and final checks, present this menu. The five options belo
 - **Start `/ce-work`** — Invoke the `ce-work` skill via the platform's skill-invocation primitive (`Skill` in Claude Code, `Skill` in Codex, the equivalent on Gemini/Pi), passing the plan path as the skill argument. Do not merely tell the user to type `/ce-work` — fire the invocation now so the plan executes in this session.
 - **Create Issue** — Detect the project tracker (`gh` for GitHub, `linear` for Linear) and create the issue from the plan file as described under "Issue Creation" in `references/plan-handoff.md`. After creation, display the issue URL and ask whether to proceed to `/ce-work` via the platform's blocking question tool.
 - **Open in Proof (web app) — review and comment to iterate with the agent** — Load the `ce-proof` skill in HITL-review mode with the plan file as `source file`, the plan title as `doc title`, identity `ai:compound-engineering` / `Compound Engineering`, and recommended next step `/ce-work`. Then follow the post-HITL resync logic in `references/plan-handoff.md`, which handles the four `ce-proof` return statuses, re-runs `ce-doc-review` after material edits, and falls back gracefully on upload failure.
-- **Dispatch to external agents** — Invoke the `ce-dispatch` skill via the platform's skill-invocation primitive (`Skill` in Claude Code, `Skill` in Codex, the equivalent on Gemini/Pi), passing the plan path as the skill argument. Do not merely tell the user to type `/ce-dispatch` — fire the invocation now so the plan's implementation units fan out to GitHub issues in this session.
+- **Dispatch to external agents** — `ce-dispatch-beta` carries `disable-model-invocation: true` per the beta skills framework (`docs/solutions/skill-design/beta-skills-framework.md`), which blocks the platform's skill-invocation primitive — only a user-typed slash command fires it. Do **not** attempt `Skill ce-dispatch-beta` (the call is silently dropped by the model layer). Instead, end the turn with a one-line instruction: "Run `/ce-dispatch-beta <plan-path>` to fan the plan's implementation units out to GitHub issues for parallel execution by Conductor / other issue-driven workspaces." Include the resolved plan path so the user can copy-paste. When `ce-dispatch` is later promoted to stable (per the framework's promotion checklist, which strips `-beta` and removes the flag together), this routing will switch back to firing the skill-invocation primitive in-session.
 - **Done for now** — Display a brief confirmation that the plan file is saved and end the turn. Do not start follow-up work without an explicit further user prompt.
 
 If the user asks for another document review (either from a contextual prompt about residual findings or via free-form request), load the `ce-doc-review` skill with the plan path for another pass and then return to this menu. For free-text revisions outside the five options, accept the input and loop back to this menu after applying the revision.