Add centralized codex-code-review reusable workflow

.github/workflows/codex-code-review.yml

@@ -0,0 +1,24 @@
+name: Codex Code Review
+
+# Thin caller. The workflow body — gpt-5.5 prompt, codex subscription
+# auth, incremental review, sticky-comment lifecycle — lives in
+# happycatlabs/codex-review-workflow. Update there to update every
+# consumer at once.
+
+on:
+  pull_request:
+    types: [opened, reopened, synchronize, ready_for_review]
+
+# Required: the reusable workflow needs pull-requests + issues write
+# to post the sticky review comment. GitHub bounds the called
+# workflow's job-level permissions by the caller's workflow-level
+# permissions, so the caller must declare at least these.
+permissions:
+  contents: read
+  pull-requests: write
+  issues: write
+
+jobs:
+  review:
+    uses: happycatlabs/codex-review-workflow/.github/workflows/codex-code-review.yml@main
+    secrets: inherit

README.md

@@ -56,7 +56,7 @@ If a run hits `waiting_for_answer`, it's blocked until you respond:
 
 ```bash
 orca status --last                          # read the question
-orca answer <run-id> "yes, use migration A"  # unblock it
+orca answer <run-id> "yes, use migration A"  # answer and resume the live run
 ```
 
 ### Spec / plan files
@@ -104,6 +104,8 @@ Orca loads config in this order (later overrides earlier):
 
 `.ts` is preferred over `.js` when both exist.
 
+Stale executor values from older configs are ignored and coerced to `codex`. Orca no longer supports alternate executors.
+
 ```ts
 // orca.config.ts
 import { defineOrcaConfig } from "orcastrator";
@@ -117,7 +119,13 @@ export default defineOrcaConfig({
 
   codex: {
     model: "gpt-5.3-codex",
-    effort: "medium",             // "low" | "medium" | "high" — applies to all Codex turns
+    effort: "medium",             // fallback for all Codex turns unless overridden below
+    thinkingLevel: {
+      decision: "low",            // planning gate / quick routing decisions
+      planning: "xhigh",          // task graph generation
+      review: "high",             // task graph consultation + post-execution review prompts
+      execution: "medium",        // task execution turns
+    },
     timeoutMs: 300000,
     multiAgent: false,      // see Multi-agent section
     perCwdExtraUserRoots: [
@@ -168,10 +176,20 @@ After planning, Orca runs a pre-execution review that can edit the task graph (a
 
 After execution, Orca runs validation commands and asks Codex to review findings. With `onFindings: "auto_fix"`, it applies fixes and retries up to `maxCycles` times, then reports. Set `ORCA_SKIP_VALIDATORS=1` to skip validator auto-detection at runtime.
 
+Use `codex.thinkingLevel` when you want different reasoning levels for different stages instead of a single global `codex.effort`.
+
 ### Multi-agent mode
 
 Set `codex.multiAgent: true` to spawn parallel Codex agents per task. Faster for large refactors with independent subtasks; higher token cost. **Note:** this writes `multi_agent = true` to your global `~/.codex/config.toml`.
 
+If `~/.codex/config.toml` already enables `[features].multi_agent = true`, Orca also treats the run as multi-agent-aware for planning, review, consultation, and execution prompts even when `codex.multiAgent` is not set in Orca config.
+
+### Codex binary and MCP diagnostics
+
+When `ORCA_CODEX_PATH` is unset, Orca auto-selects the newest installed Codex CLI/app-server it can find instead of blindly trusting the first `codex` binary on `PATH`. This avoids talking to an older global install when a newer desktop build is present.
+
+If configured Codex MCP servers are enabled but not logged in, Orca now summarizes that once and continues without them instead of streaming raw app-server auth noise throughout the run.
+
 ### Skills
 
 Orca auto-loads skills in this precedence order (first name wins):
@@ -229,7 +247,7 @@ orca setup                               Interactive setup wizard
 
 ### Hooks
 
-Available hook names: `onMilestone`, `onTaskComplete`, `onTaskFail`, `onInvalidPlan`, `onFindings`, `onComplete`, `onError`.
+Available hook names: `onMilestone`, `onQuestion`, `onTaskComplete`, `onTaskFail`, `onInvalidPlan`, `onFindings`, `onComplete`, `onError`.
 
 - Function hooks (`config.hooks`): receive `(event, context)` where `context = { cwd, pid, invokedAt }`
 - Command hooks (`config.hookCommands` / `--on-*` flags): receive full event JSON over stdin