Subagent-Driven Development (Codex-paired)

This is the interactive driver implementation reached through codex-paired-superpowers:execution (driver: interactive). Users invoke execution; this skill is the per-slice engine it delegates to.

What this changes vs. upstream

After each slice's implementing subagent reports completion, Claude runs a scoped Codex review before moving to the next slice. The review is locked to the slice's tasks; out-of-scope issues are noted but cannot block.

Honest-reporting activation (v0.8.1, do this first)

Before the per-slice flow starts, write the honest-reporting marker so the Stop/PreToolUse hook keeps claims sourced across the implementation session:

node "${CLAUDE_PLUGIN_ROOT}/lib/codex-bridge/cli.js" honest-reporting-mark-active --skill subagent-driven-development

The marker has an 8-hour TTL and auto-expires; no cleanup needed.

Per-slice flow

Step A0: pick the review lane (v0.18.1 — before any dispatch)

Read docs/execution-model.md "Review lanes" and choose a provisional lane from what this work item's Files: list touches, BEFORE Step A. The lane decides whether a writer is dispatched at all, so choosing it at review time would forfeit the saving:

• prose lane (Files are all prose-allowlist paths): skip Step A entirely — no writer dispatch. Edit the files yourself, capture the diff (Step B), do your own read (Step C0), then open ONE review with the review role, cap 2 rounds. Fixes are your own edits, not dispatched passes.
• standard lane (anything else): Steps A through C as written, both reviewers, cap 7.

Recheck before review. At Step C, compare the lane against the actual committed diff. If a prose-lane item turned out to touch lib/, scripts/, bin/, tests/, skills/ or a contract document, it re-enters the standard lane: both reviewers, cap 7, from round 1. Never finish a code change under a prose-lane review.

Step A: dispatch the implementer (Codex writes the code — v0.16.0)

Interactive execution uses the same dispatcher registry and ladder as autopilot (not an upstream subagent). Resolve the slice's domain (autopilot Phase B.0 rules), then climb the single-implementer ladder from agents/dispatchers.json (Codex is preferred in every domain since v0.16.0):

rung 1  implement           — codex form: scripts/codex-exec-with-status.sh <status> --model-role implement -- codex exec --skip-git-repo-check -s workspace-write -C <worktree> --add-dir <repo>/.git "<prompt>" </dev/null
                                agy form:   scripts/codex-exec-with-status.sh <status> --model-role implement --cwd <worktree> -- agy -p "<prompt>" --sandbox --dangerously-skip-permissions --add-dir <repo>/.git --output-format json --print-timeout 2h </dev/null
                                (pick the form from `model-role --role implement --format json` → "cli"; never hard-code one)
rung 2  implement_fallback  — same, with --model-role implement_fallback (its own cli may differ)
rung 3  sonnet subagent             — Task tool, subagent_type slice-implementer-sonnet
        halt implementer-unavailable

A plan **Implementer:** directive means "start at this rung" (codex → 1, sonnet → 3). The wrapper resolves the model/effort for the role and writes them into the status file; never pass -m yourself. Classify the status file with classifyStatusFile → decideImplementAction → applyImplementDecision from lib/codex-bridge/dispatch-status.js (same as autopilot B.4/B.6): exit_code: 78 (model-role resolution failed / conflicting args) is terminal — no reset, no next rung, no Claude fallback; blocked / needs-context halt too. Wait for completion + tests passing.

Step B: capture slice artifacts

Commit-parity preflight (v0.15.0). Before capturing the diff — on round 1 AND on every re-review after a fix — run git status --porcelain in the slice's working directory. If any slice-touched file shows uncommitted or unstaged changes, STOP and commit them first. Sidecar replay found two features that each burned a full review round because the fix existed in the working tree but not in the committed state the reviewer saw ("staged index still has the old regex"). The diff sent to review must be the committed diff, and the tree must be clean.

Public-API digest refresh (v0.18.0). If the slice touched any module in the CLI's pinned import closure or any pinned JSON input (docs/public-api.md cli-verbs block: closure, module_digest, input_digest), run node scripts/cli-surface.mjs --digest --write from the slice's working directory root now — before the verification run and before Step C0 (the script defaults --root to the repository it lives in, so use the worktree's own copy, or pass --root <slice-worktree> to another copy) — and commit the resulting docs/public-api.md diff together with the slice. npm test fails on a stale digest, so a refresh done later would invalidate the reviewed SHA. The --write mode touches only those three keys; the documented cases still get their semantic review in Step D.

Collect:

• Slice scope: the exact task list from the plan for slice N (literal markdown, the bullet list).
• Diff: git diff <slice-start-sha>..HEAD -- <files-this-slice-was-meant-to-touch>
• Test output: pasted verbatim from the subagent's last test run.

Step C0: Claude's independent review (v0.16.0 — before Codex sees the diff)

Claude reviews first; Codex second; both must SHIP the same commit. Bounded and ordered:

1. Read the committed diff (slice_start_sha..HEAD) in full. Run the slice's verification command yourself and record it as the claude side's kind: "verification" audit for this round with "reviewed_sha": "<git rev-parse HEAD>".
2. Write a findings list — blocking[] and non_blocking[], each file:line + a one-sentence reason, each verified against the code before you list it.
3. If blocking[] is non-empty, run at most two fix passes with runFixPass from lib/codex-bridge/fix-pass.js ({ specPath, sliceId, repoRoot, pass: 1|2, execFn }): it checkpoints fix_start_sha = HEAD on the sidecar first; execFn runs the fix (Codex at implement for pass 1, implement_fallback for pass 2, via the wrapper with --model-role; in interactive mode you may fix in the foreground instead) and returns { statusFile }; a failed pass is reset to fix_start_sha (never to the slice start — the implementation stays intact); exit_code: 78 is terminal (no reset). Commits must use fix(slice:N): subjects. After each pass: commit, re-run verification, re-review. If blockers remain after pass 2, continue to Step C anyway with them listed — Codex gets to see and push back; the 7-round loop arbitrates. Never hold a slice in C0 indefinitely.
4. Proceed to Step C with the findings and reviewed_sha = HEAD.

Step C: open Codex slice review

Recheck the lane (v0.18.1). Rules: docs/execution-model.md "Review lanes". The lane was chosen in Step A0; confirm it against the actual committed diff now. A prose-lane item whose diff touches lib/, scripts/, bin/, tests/, skills/ or a contract document re-enters the standard lane from round 1 (both reviewers, cap 7).

Deferred findings are batched (v0.18.1). The reviewer classifies every finding as blocking or deferred (lib/codex-bridge/prompts/verdict-format.md). Deferred items never open a new round: collect them across rounds and address them in ONE cleanup pass before the work item merges, reviewed once. Only a blocking finding justifies another round.

Use the execution thread (role_sessions["execution-reviewer"], opened at execution entry — see skills/brainstorming/codex-pairing.md "Two threads per feature"). SDD entry check: when this skill is entered directly (from systematic-debugging, or a /execute that skipped the hand-off) the key may be absent — run sidecar-thread-id --specPath "<spec-path>" --role execution-reviewer first and, if it prints nothing, open the thread exactly as skills/execution/SKILL.md steps 0–5 describe (model-role --role review, replay context, composeSeedPrompt(..., { reason: 'execution-thread' }), then sidecar-rotate-thread-id --role execution-reviewer --reason execution-thread --threadConfig …) before the first review turn. Never fall back to the planning thread for a slice review. Build the prompt from slice-review-prompt.md (in this skill folder), substituting {{SLICE_ID}}, {{ROUND}}, {{SLICE_TASKS}}, {{SLICE_DIFF}}, {{TEST_OUTPUT}}, and (rounds 2+) {{PRIOR_CRITIQUES}}, and append a ## Claude review findings block (both lists from Step C0, verbatim) plus the line reviewed_sha: <sha>. Codex may agree, extend, or push back on Claude's findings; the anti-yes-man discipline applies in both directions.

The prompt explicitly states:

Review only what is in this slice's scope. Out-of-slice issues = note for later in ## Deferred, do not block on them. If you find an out-of-slice critical bug, name it in ## Deferred with severity, but ship the slice.

Look up the threadId and send the prompt via the bundled MCP codex-reply tool:

THREAD_ID=$(node ${CLAUDE_PLUGIN_ROOT}/lib/codex-bridge/cli.js sidecar-thread-id --specPath "<spec-path>" --role execution-reviewer)

Transport branch (v0.17.0): if model-role --role review --format json reports "cli":"agy", pipe the same prompt to node "${CLAUDE_PLUGIN_ROOT}/lib/codex-bridge/cli.js" reviewer-thread-reply --role review --specPath "<spec-path>" --repoRoot "$REPO_ROOT" --prompt-stdin instead of the MCP codex-reply tool; its stdout is the same { threadId, content } shape.

For a Codex role, invoke mcp__plugin_codex-paired-superpowers_codex__codex-reply with { threadId: "<THREAD_ID>", prompt: "<filled slice-review prompt>" }. The response's content is the reviewer's review + verdict block.

If the reply returns isError: true with Session not found for thread_id: (the MCP server restarted mid-feature — threads are process-local), recover instead of halting: build replay context (node ${CLAUDE_PLUGIN_ROOT}/lib/codex-bridge/cli.js sidecar-replay-context --specPath "<spec-path>"), open a NEW thread via the initial codex tool seeded with that replay + the slice-review prompt that failed, then persist the rotation for the execution role — but take the model and effort from the lost thread's recorded thread_config["execution-reviewer"] in the sidecar (spec §5), not from the current model-role output; current configuration is only the fallback for a legacy sidecar with no record. The complete code path does all of this in one call and is the preferred form:

const { recoverStaleThread } = await import('${CLAUDE_PLUGIN_ROOT}/lib/codex-bridge/thread-recovery.js');
const r = await recoverStaleThread(specPath, {
  staleResponse: reply,                 // the { isError: true, content: 'Session not found …' } reply
  pendingPrompt: sliceReviewPrompt,     // the prompt that failed against the lost thread
  phase: 'review-slice:<slice-id>', round: <n>,
  role: 'execution-reviewer', planPath, repoRoot,
}, {
  // codex roles: exactly one initial `codex` MCP call with the RECORDED model + config
  codexFn: async ({ prompt, model, config }) => /* mcp codex tool { prompt, model, config } → { threadId, content } */,
  // agy roles need no dep: the default openFn runs reviewer-thread-open in a throwaway checkout
});
if (!r.recovered) throw new Error('not a stale-thread response');
THREAD_ID = r.newThreadId; content = r.content;   // rotation already persisted with thread_config

Manual equivalent (only if you cannot run the helper): read thread_config["execution-reviewer"] via sidecar-show, open the new thread with that model/effort, then sidecar-rotate-thread-id --specPath "<spec-path>" --role execution-reviewer --oldThreadId <old> --newThreadId <new> --reason session-not-found --phase "review-slice:<slice-id>" --round <n> --threadConfig '<the recorded object>' — --role is mandatory: the verb defaults to paired-reviewer and would overwrite the planning thread. Tell the user in one line ("Codex thread was lost; opened a new thread and replayed the sidecar context") and continue the round — do not discard prior review history.

Effort is fixed per thread (codex-reply has no config parameter): the execution thread runs at the review role (GPT-6 Astra, high by default; override via .codex-paired/project.json models.review or CODEX_PAIRED_REASONING_REVIEW).

Review panel branch (v0.19.0)

Before the first round of a slice review, run the activation check in skills/brainstorming/codex-pairing.md § "Review panel rounds (v0.19.0)" with --phase review. If configured is false, Steps C and D apply exactly as written. If configured is true, run each review-slice:<slice-id> round (and docs-update) as a panel round per that section: the Step C prompt goes to every member, each on its own thread (execution-reviewer:<member_id>) or fresh Gemini conversation, and the slice ships only when Claude and every member say SHIP on the same commit. A configured review panel also reviews prose-lane slices (Step A0): the lane still skips the writer and keeps its two-round cap, but every member reviews.

Step D: 7-round loop

Same as brainstorming. Both must SHIP. Sidecar phase is review-slice:<slice-id> (e.g., review-slice:slice-2) — the spec-canonical code-bearing phase name as of v0.13.0 (replacing the legacy slice:<id>).

Code-bearing verification floor (v0.13.0, Goal 1). Because review-slice:<slice-id> is a code-bearing phase, a SHIP for either side is gated on an EXECUTED verification command, not just an inspection audit. Record the slice's test/build run (captured in Step B) as a verification audit entry before logging a SHIP round, e.g.:

printf '%s' '{
  "phase": "review-slice:<slice-id>",
  "round": N,
  "side": "<claude|codex>",
  "reviewed_sha": "<git rev-parse HEAD — full 40-hex>",
  "commands": [
    {"cmd": "npm test", "summary": "42 passed", "kind": "verification", "exit_code": 0}
  ],
  "verdict_basis": "<one-line: tests pass + review judgement>"
}' | node ${CLAUDE_PLUGIN_ROOT}/lib/codex-bridge/cli.js sidecar-append-audit --specPath "<spec-path>"

If the slice's tests were not executed (or did not pass with exit_code: 0), the gate refuses the SHIP — run the tests and record the result, or emit REVISE.

Same-commit rule (v0.16.0). Append review-slice rounds with --headSha "$(git rev-parse HEAD)" (sidecar-append-round / sidecar-append-round-with-audits). When the audits carry reviewed_sha, the sink requires every SHIP side's verification audit to carry the same SHA, requires --headSha, and requires it to equal that SHA — two SHIPs on different commits, or a stale SHA, are refused. Any fix after a Codex verdict starts a new round with fresh verification on both sides.

Faster verification via test-impact analysis (optional). Instead of the full suite you MAY run npm run test:affected (coverage-based selection — see scripts/tia.mjs). It writes a review-grade record to .tia-cache/last-run.json; embed that record as the verification command's selection so the audit is self-contained — Codex can see exactly what ran, against what change set, and why it was sufficient:

{"cmd": "npm run test:affected", "summary": "ran 6 of 110 affected tests, exit 0",
 "kind": "verification", "exit_code": 0,
 "selection": {"mode": "selected", "ran": 6, "fullyCovered": true, "uncovered": [],
               "exit": 0, "base": "HEAD (working tree)", "mapVersion": 2,
               "tests": ["tests/...test.js", "..."], "changed": ["lib/...js"]}}

Gate rules the audit enforces on a TIA selection:

• "ran": 0 or "mode": "none" → not valid verification (running the empty affected set proves nothing).
• "mode": "selected" counts only when "fullyCovered": true and "uncovered": [] (the subset covered every changed source).
• "mode": "all" with ran > 0 is always valid (full run is the safe default).

Codex reviewing the SHIP can still challenge whether a selected subset was sufficient. On double-SHIP, mark slice shipped:

node ${CLAUDE_PLUGIN_ROOT}/lib/codex-bridge/cli.js sidecar-set-slice \
  --specPath "<spec-path>" \
  --sliceId "<slice-id>" \
  --state '{"rounds":[...],"shipped":true,"deferred":[...]}'

Step E: surface deferred items

If the slice review produced any ## Deferred items, show them to the user before starting the next slice. They might warrant a new task in a future slice or a separate plan.

Step F: proceed to next slice

Only after slice N is shipped and any user-arbitrated deferreds are decided.

Refresh the test-impact map at the slice boundary (if using test:affected). A shipped slice may have changed which source files its tests load. Re-map only the tests the slice touched so the map stays current for later slices (prevents drift without a full rebuild):

node ${CLAUDE_PLUGIN_ROOT}/scripts/tia.mjs refresh --base <slice_start_sha>

Use the slice's start SHA (the commit the slice branched from) as --base so the diff is exactly this slice's changes.

Edit discipline (v0.13.0, Goal 5)

Repeated failed edits waste turns. The orchestrator and every implementing subagent MUST follow this:

• Read before editing when read-state is uncertain — if another agent may have touched the file, or if your last read predates a failed edit, re-read the file in the current turn first.
• If an edit fails with File has not been read yet, immediately read the file and recompute the edit against its current contents.
• If an edit fails with String to replace not found, immediately re-read and inspect the target region; the file has changed or your old_string is stale.
• Never retry the same (file, old_string, new_string) tuple byte-for-byte after it just failed — a byte-identical retry is a procedural error, not a recovery. Recompute from a fresh read.
• For bulk edits, prefer a structured patch with enough surrounding context captured after the fresh read.

Flake handling (v0.13.0, Goal: trustworthy verification in an automated loop)

A flaky test poisons the agentic loop: a flaky FAIL stalls the slice, a flaky PASS gives a false SHIP through the verification floor. Handle flakes honestly rather than papering over them.

• Same-SHA retry (mirrors lib/codex-bridge/flake-retry.js). If a verification command fails, re-run it ONCE at the same commit without changing files. If it then passes, it is flaky — it did pass, so it satisfies the floor, but you MUST record the truth on the audit command: {"cmd": "...", "kind": "verification", "exit_code": 0, "attempts": 2, "flaky": true}. Never record a clean first-try pass for a result that needed a retry.
• Cross-agent disagreement = a flake signal. Claude and Codex each record their own verification audit. If the same test passes for one side and fails for the other at the same commit, treat it as flaky: do NOT SHIP on it — investigate and root-cause, or quarantine it explicitly.
• The quarantine list. node ${CLAUDE_PLUGIN_ROOT}/scripts/tia.mjs flaky lists tests that failed/errored when last mapped in isolation (the TIA ok:false set). These always re-run and are known flake candidates; a SHIP resting on one should be challenged.
• Codex challenges flaky evidence. At slice review, Codex SHOULD inspect listFlakyVerifications for the round and push back on a SHIP whose verification was flaky rather than clean. Prefer fixing the flake's root cause (e.g. a wall-clock or ordering race) over retrying around it.

Per-slice reviewer review (v0.9.0)

After the implementing subagent reports completion (Step A) and the slice's diff + tests are captured (Step B), but BEFORE Step C's Codex slice review, the orchestrator MUST run composer-selected experts on the slice. This mirrors autopilot's Phase B.5.5 pattern but applies to inline (non-autopilot) execution: every slice gets domain-expert review before it's allowed to ship.

This is the inline analog of autopilot's post-implementation-review phase — same composer, same dispatch primitives, same blocking-finding contract.

Step 1 — Compose experts from slice signals

const { composeReviewers } = await import('${CLAUDE_PLUGIN_ROOT}/lib/codex-bridge/reviewer-composer.js');

// Directive precedence: the canonical **Reviewers:** slice directive maps to
// `reviewersDirective`. The deprecated **Experts:** directive is still accepted
// on read and maps to `explicitDirective`. Prefer `sliceFrontmatter.reviewers`;
// fall back to `sliceFrontmatter.experts` only for legacy plans. If both are
// present, Reviewers wins and the composer returns a `directiveWarning`.
const signals = {
  specHas:    [/* keywords from slice plan section */],
  filePaths:  [/* slice **Files:** block */],
  domains:    [sliceDomain],
  reviewersDirective: sliceFrontmatter.reviewers, // canonical **Reviewers:** directive
  explicitDirective: sliceFrontmatter.experts,    // deprecated **Experts:** alias (accepted-on-read)
  fanOutRationale: anticipatesFanOut ? '<concrete justification>' : undefined,
};
const result = composeReviewers({
  phase: 'post-implementation-review',
  signals,
  repoRoot,
});
// result.selected: ReviewerIdentity[]
// result.directiveWarning: string|null (set when a legacy **Experts:** directive
//                          is read, or when both directives are present)

The composer throws role-composer-fan-out-unjustified for >5 selections without rationale.

Step 2 — Resolve each expert to an adapter

const { detectAvailableCLIs, availableCLISet } =
  await import('${CLAUDE_PLUGIN_ROOT}/lib/codex-bridge/availability/detector.js');
const { resolveAdapter } =
  await import('${CLAUDE_PLUGIN_ROOT}/lib/codex-bridge/role-routing/resolver.js');

const { RoleRoutingError } =
  await import('${CLAUDE_PLUGIN_ROOT}/lib/codex-bridge/role-routing/errors.js');

const detectorResult = await detectAvailableCLIs(repoRoot);
const availableCLIs  = availableCLISet(detectorResult);

const resolutions = [];
for (const identity of result.selected) {
  let resolved;
  try {
    // Resolver is keyed by identity.id ("reviewer-architecture"), NOT identity.role ("architecture").
    resolved = resolveAdapter(identity.id, availableCLIs, /* userRouting */ null);
  } catch (err) {
    if (err instanceof RoleRoutingError) {
      // Per-slice expert review is gate-class — fail-closed.
      throw new Error(`cli-dispatch-failed: ${identity.id} (${err.code})`);
    }
    throw err;
  }
  // resolved.cli ∈ {'claude','codex','ollama','gemini','qwen'}; resolved.variant may be null.
  // Translate to the sidecar adapter value runTurnWithDeps records.
  const adapter = resolved.cli === 'claude'
    ? 'claude-task'
    : `cli-harness:${resolved.cli}`;
  resolutions.push({ identity, resolved, adapter });
}

resolveAdapter THROWS RoleRoutingError (codes: no-supported-cli-for-role, override-cli-unavailable, override-variant-unknown) — it does not return null. For per-slice review, all three codes halt with cli-dispatch-failed — fail-closed (per spec § 5).

Step 3 — Dispatch each expert via runTurnWithDeps

Each expert runs independently in single mode (panel mode is opt-in via plan frontmatter high_stakes: true, handled by writing-plans, not here). Use runTurnWithDeps with the two-step orchestration pattern (Claude dispatches Task/harness; runtime drives parse + sidecar persistence):

const { runTurnWithDeps, assembleSpawnPrompt } =
  await import('${CLAUDE_PLUGIN_ROOT}/lib/codex-bridge/reviewer-turn.js');
const { readUnreadMessages } =
  await import('${CLAUDE_PLUGIN_ROOT}/lib/codex-bridge/mailbox.js');

for (const { identity, resolved, adapter } of resolutions) {
  const request = {
    identity,
    repoRoot,
    specPath,
    specSnippet:            sliceDiffSnippet,
    phase:                  'post-implementation-review',
    sliceId,
    adapter,                                // sidecar audit field; must match the actual transport.
    sidecarParticipantState: <prior turn summaries>,
    task:                    'Review the slice diff. Surface blocking findings + DMs.',
  };
  const unreadMessages = await readUnreadMessages(repoRoot, identity.id);
  const prompt = assembleSpawnPrompt({ ...request, unreadMessages });
  // v0.16.0 — 'claude' reviewers: dispatch the Task tool with `prompt` and capture responseText.
  // Every other CLI goes through the production helper, which resolves the model role BY PHASE
  // ('post-implementation-review' → review), assembles the real prompt, and bounds the run:
  let responseText, requestForTurn = request;
  if (resolved.cli === 'claude') {
    responseText = await /* Task tool with `prompt` */;
  } else {
    const { dispatchReviewerViaHarness } =
      await import('${CLAUDE_PLUGIN_ROOT}/lib/codex-bridge/reviewer-dispatch.js');
    const out = await dispatchReviewerViaHarness(request, { cli: resolved.cli, variant: resolved.variant, repoRoot }); // variant: ollama/agy variants are lost otherwise (helper defaults to 'read-only')
    responseText = out.responseText;
    requestForTurn = out.requestForTurn; // adapter + modelRole (+ warning) for the turn record
  }
  const turnResult = await runTurnWithDeps(requestForTurn, {
    agentDispatch: async () => responseText,
  });
  // turnResult: { ok: true, result } | { ok: false, reason }
}

Dispatch experts in parallel (single assistant turn, multiple tool calls).

Step 4 — Aggregate blocking findings

For each expert turn:

• result.blocking_findings[] non-empty → slice is BLOCKED; halt before Step C (Codex review). Surface findings to user OR apply technical-override via updateDispatchExpertBlocker (rules match autopilot's B.5.5 Blocking-Finding Override Authority).
• result.nonblocking_findings[] → record in sidecar; surface to user during Step E deferred-items review.

Step 5 — Proceed to Step C (Codex slice review) only on clean expert pass

Codex slice review (Step C) runs AFTER experts have shipped (or after their blockers have been resolved). Codex sees the same diff plus a ## Expert findings from post-implementation-review block in its prompt — cross-model L11 critique stacked on Codex's structural review.

Anti-scope-creep enforcement

If Codex emits a critique that targets code outside the slice's scope, Claude pushes back: "this is out of slice; either move to Deferred or justify why it must be fixed inside this slice." This is a structural disagreement Codex must justify with concrete reasoning (e.g., "the slice introduces a public API I'm critiquing", which is in-scope).

Stalled-slice escape

If a slice can't reach double-SHIP in 7 rounds, halt the implementation. Surface the deadlock to the user with both positions. Don't silently downgrade or skip.

Required upstream sub-skills

• superpowers:subagent-driven-development — for the implementer + spec-reviewer + code-quality-reviewer pattern. This forked skill ADDS the Codex slice review on top.
• pr-review-toolkit:silent-failure-hunter — recommended for the code-quality reviewer in slices that touch error-handling.

Troubleshooting setup errors

If you see errors mentioning Cannot find module, proper-lockfile, codex: command not found, codex not authenticated, ENOENT, or any module-load / binary-not-found pattern, invoke /codex-paired-superpowers:doctor first. Resume after green.