oh-my-codex 0.7.2 → 0.7.3

package/scripts/tmux-hook-engine.js

@@ -154,17 +154,22 @@ export function buildPaneInModeArgv(paneTarget) {
   return ['display-message', '-p', '-t', paneTarget, '#{pane_in_mode}'];
 }
 
-export function buildSendKeysArgv({ paneTarget, prompt, dryRun }) {
+export function buildCapturePaneArgv(paneTarget, tailLines = 80) {
+  return ['capture-pane', '-t', paneTarget, '-p', '-S', `-${tailLines}`];
+}
+
+export function buildSendKeysArgv({ paneTarget, prompt, dryRun, submitKeyPresses = 2 }) {
   if (dryRun) return null;
+  const pressCountRaw = Number.isFinite(submitKeyPresses) ? Math.floor(submitKeyPresses) : 2;
+  const pressCount = Math.max(1, Math.min(4, pressCountRaw));
+  const submitArgv = Array.from({ length: pressCount }, () => ([
+    'send-keys', '-t', paneTarget, 'C-m',
+  ]));
   // Use a 2-step send for reliability:
   // 1) literal prompt bytes, 2) explicit carriage return.
   return {
     typeArgv: ['send-keys', '-t', paneTarget, '-l', prompt],
-    // Codex CLI uses raw input mode where 'Enter' key name is unreliable;
-    // send 'C-m' (carriage return) twice for reliable prompt submission.
-    submitArgv: [
-      ['send-keys', '-t', paneTarget, 'C-m'],
-      ['send-keys', '-t', paneTarget, 'C-m'],
-    ],
+    // Codex generally prefers two presses; Claude typically needs one.
+    submitArgv,
   };
 }

package/skills/autopilot/SKILL.md

@@ -160,6 +160,27 @@ If autopilot was cancelled or failed, run `/autopilot` again to resume from wher
 3. Specify constraints -- "using TypeScript", "with PostgreSQL"
 4. Let it run -- avoid interrupting unless truly needed
 
+## Pipeline Orchestrator (v0.8+)
+
+Autopilot can be driven by the configurable pipeline orchestrator (`src/pipeline/`), which
+sequences stages through a uniform `PipelineStage` interface:
+
+```
+RALPLAN (consensus planning) -> team-exec (Codex CLI workers) -> ralph-verify (architect verification)
+```
+
+Pipeline configuration options:
+
+```toml
+[omc.autopilot.pipeline]
+maxRalphIterations = 10    # Ralph verification iteration ceiling
+workerCount = 2            # Number of Codex CLI team workers
+agentType = "executor"     # Agent type for team workers
+```
+
+The pipeline persists state via `pipeline-state.json` and supports resume from the last
+incomplete stage. See `src/pipeline/orchestrator.ts` for the full API.
+
 ## Troubleshooting
 
 **Stuck in a phase?** Check TODO list for blocked tasks, run `state_read({mode: "autopilot"})`, or cancel and resume.

package/skills/pipeline/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: pipeline
+description: Configurable pipeline orchestrator for sequencing stages
+---
+
+# Pipeline Skill
+
+`$pipeline` is the configurable pipeline orchestrator for OMX. It sequences stages
+through a uniform `PipelineStage` interface, with state persistence and resume support.
+
+## Default Autopilot Pipeline
+
+The canonical OMX pipeline sequences:
+
+```
+RALPLAN (consensus planning) -> team-exec (Codex CLI workers) -> ralph-verify (architect verification)
+```
+
+## Configuration
+
+Pipeline parameters are configurable per run:
+
+| Parameter | Default | Description |
+|-----------|---------|-------------|
+| `maxRalphIterations` | 10 | Ralph verification iteration ceiling |
+| `workerCount` | 2 | Number of Codex CLI team workers |
+| `agentType` | `executor` | Agent type for team workers |
+
+## Stage Interface
+
+Every stage implements the `PipelineStage` interface:
+
+```typescript
+interface PipelineStage {
+  readonly name: string;
+  run(ctx: StageContext): Promise<StageResult>;
+  canSkip?(ctx: StageContext): boolean;
+}
+```
+
+Stages receive a `StageContext` with accumulated artifacts from prior stages and
+return a `StageResult` with status, artifacts, and duration.
+
+## Built-in Stages
+
+- **ralplan**: Consensus planning (planner + architect + critic). Skips if a `prd-*.md` plan already exists.
+- **team-exec**: Team execution via Codex CLI workers. Always the OMX execution backend.
+- **ralph-verify**: Ralph verification loop with configurable iteration count.
+
+## State Management
+
+Pipeline state persists via the ModeState system at `.omx/state/pipeline-state.json`.
+The HUD renders pipeline phase automatically. Resume is supported from the last incomplete stage.
+
+- **On start**: `state_write({mode: "pipeline", active: true, current_phase: "stage:ralplan"})`
+- **On stage transitions**: `state_write({mode: "pipeline", current_phase: "stage:<name>"})`
+- **On completion**: `state_write({mode: "pipeline", active: false, current_phase: "complete"})`
+
+## API
+
+```typescript
+import {
+  runPipeline,
+  createAutopilotPipelineConfig,
+  createRalplanStage,
+  createTeamExecStage,
+  createRalphVerifyStage,
+} from './pipeline/index.js';
+
+const config = createAutopilotPipelineConfig('build feature X', {
+  stages: [
+    createRalplanStage(),
+    createTeamExecStage({ workerCount: 3, agentType: 'executor' }),
+    createRalphVerifyStage({ maxIterations: 15 }),
+  ],
+});
+
+const result = await runPipeline(config);
+```
+
+## Relationship to Other Modes
+
+- **autopilot**: Autopilot can use pipeline as its execution engine (v0.8+)
+- **team**: Pipeline delegates execution to team mode (Codex CLI workers)
+- **ralph**: Pipeline delegates verification to ralph (configurable iterations)
+- **ralplan**: Pipeline's first stage runs RALPLAN consensus planning

package/skills/team/SKILL.md

@@ -138,7 +138,7 @@ Normalization requirements:
 Follow this exact lifecycle when running `$team`:
 
 1. Start team and verify startup evidence (team line, tmux target, panes, ACK mailbox)
-2. Monitor task and worker progress (`omx team status <team>`)
+2. Monitor task and worker progress with runtime/state tools first (`omx team status <team>`, `omx team resume <team>`, mailbox/state files)
 3. Wait for terminal task state before shutdown:
    - `pending=0`
    - `in_progress=0`
@@ -147,6 +147,7 @@ Follow this exact lifecycle when running `$team`:
 5. Verify shutdown evidence and state cleanup
 
 Do not run `shutdown` while workers are actively writing updates unless user explicitly requested abort/cancel.
+Do not treat ad-hoc pane typing as primary control flow when runtime/state evidence is available.
 
 ## Operational Commands
 
@@ -238,6 +239,26 @@ Useful runtime env vars:
 
 ## Failure Modes and Diagnosis
 
+Operator note (important for Claude panes):
+- Manual Enter injection (`tmux send-keys ... C-m`) can appear to "do nothing" when a worker is actively processing; Enter may be queued by the pane/task flow.
+- This is not necessarily a runtime bug. Confirm worker/team state before diagnosing dispatch failure.
+- Avoid repeated blind Enter spam; it can create noisy duplicate submits once the pane becomes idle.
+
+### Safe Manual Intervention (last resort)
+
+Use only after checking `omx team status <team>` and mailbox/state evidence:
+
+1. Capture pane tail to confirm current worker state:
+   - `tmux capture-pane -t %<worker-pane> -p -S -120`
+2. If the pane is stuck in an interactive state, safely return to idle prompt first:
+   - optional interrupt `C-c` or escape flow (CLI-specific) once, then re-check pane capture
+3. Send one concise trigger (single line) and wait for evidence:
+   - `tmux send-keys -t %<worker-pane> "ack + continue current task; report status" C-m`
+4. Re-check:
+   - pane output via `capture-pane`
+   - mailbox updates (`mailbox/leader-fixed.json` or worker mailbox)
+   - `omx team status <team>`
+
 ### `worker_notify_failed:<worker>`
 
 Meaning:

package/templates/catalog-manifest.json

@@ -33,7 +33,7 @@
     {
       "name": "ecomode",
       "category": "execution",
-      "status": "merged",
+      "status": "deprecated",
       "canonical": "ultrawork",
       "core": false,
       "internalRequired": false