oh-my-codex 0.15.0 → 0.15.2

package/src/scripts/notify-hook.ts

@@ -20,7 +20,7 @@
 
 import { writeFile, appendFile, mkdir, readFile } from 'fs/promises';
 import { existsSync } from 'fs';
-import { dirname, join } from 'path';
+import { dirname, join, resolve } from 'path';
 
 import { safeString, asNumber } from './notify-hook/utils.js';
 import {
@@ -183,9 +183,11 @@ async function main() {
   const parsedTeamWorker = parseTeamWorkerEnv(teamWorkerEnv);
   const isTeamWorker = !!parsedTeamWorker;
 
-  const stateDir = (isTeamWorker && parsedTeamWorker)
+  const resolvedWorkerStateDir = (isTeamWorker && parsedTeamWorker)
     ? await resolveTeamStateDirForWorker(cwd, parsedTeamWorker)
-    : join(cwd, '.omx', 'state');
+    : null;
+  const workerStateRootResolved = !isTeamWorker || !!resolvedWorkerStateDir;
+  const stateDir = resolvedWorkerStateDir || join(cwd, '.omx', 'state');
   const logsDir = join(cwd, '.omx', 'logs');
   const omxDir = join(cwd, '.omx');
   let currentOmxSessionId = '';
@@ -193,12 +195,15 @@ async function main() {
 
   // Ensure directories exist
   await mkdir(logsDir, { recursive: true }).catch(() => {});
-  await mkdir(stateDir, { recursive: true }).catch(() => {});
-  currentOmxSessionId = await readCurrentSessionId(stateDir).catch(() => '') || '';
+  if (workerStateRootResolved) {
+    await mkdir(stateDir, { recursive: true }).catch(() => {});
+    currentOmxSessionId = await readCurrentSessionId(stateDir).catch(() => '') || '';
+  }
 
   // Turn-level dedupe prevents double-processing when native notify and fallback
   // watcher both emit the same completed turn.
   try {
+    if (!workerStateRootResolved) throw new Error('worker_state_root_unresolved');
     const turnId = safeString(payload['turn-id'] || payload.turn_id || '');
     if (turnId) {
       const now = Date.now();
@@ -268,6 +273,32 @@ async function main() {
     return;
   }
 
+  if (isTeamWorker && !workerStateRootResolved) {
+    await logNotifyHookEvent(logsDir, {
+      timestamp: new Date().toISOString(),
+      level: 'warn',
+      type: 'team_worker_state_root_unresolved',
+      team_worker: teamWorkerEnv || null,
+      reason: 'skip_team_worker_state_mutations',
+    }).catch(() => {});
+
+    // Keep the fail-closed worker state-root behavior for normal team-worker
+    // mutations, but allow the narrow auto-nudge path to use an explicitly
+    // supplied, already-existing worker state root. Auto-nudge only needs the
+    // worker-scoped state files/pane anchor and should not fall back to creating
+    // local `.omx/state` when identity resolution failed.
+    const explicitWorkerStateRoot = safeString(process.env.OMX_TEAM_STATE_ROOT || '').trim();
+    const autoNudgeStateDir = explicitWorkerStateRoot ? resolve(cwd, explicitWorkerStateRoot) : '';
+    if (autoNudgeStateDir && existsSync(autoNudgeStateDir)) {
+      try {
+        await maybeAutoNudge({ cwd, stateDir: autoNudgeStateDir, logsDir, payload });
+      } catch {
+        // Non-critical
+      }
+    }
+    return;
+  }
+
   // Reconcile Ralph ownership for same-Codex-session continuation before
   // lifecycle counters or injection read the active scope.
   if (!isTeamWorker) {

package/src/scripts/prompt-inventory.ts

@@ -0,0 +1,218 @@
+#!/usr/bin/env node
+import { existsSync, readdirSync, readFileSync, statSync } from 'node:fs';
+import { join, relative } from 'node:path';
+
+export interface PromptSurfaceInventory {
+  path: string;
+  lines: number;
+  approximateTokens: number;
+  absoluteDirectiveCount: number;
+  markers: Record<string, number>;
+}
+
+export interface DuplicateFragmentFamily {
+  text: string;
+  count: number;
+  paths: string[];
+}
+
+export interface PromptInventoryReport {
+  generatedAt: string;
+  root: string;
+  totals: {
+    files: number;
+    lines: number;
+    approximateTokens: number;
+    absoluteDirectiveCount: number;
+  };
+  surfaces: PromptSurfaceInventory[];
+  duplicateFragmentFamilies: DuplicateFragmentFamily[];
+}
+
+const PROMPT_SURFACE_FILES = [
+  'AGENTS.md',
+  'templates/AGENTS.md',
+  'docs/prompt-guidance-contract.md',
+  'docs/guidance-schema.md',
+  'src/hooks/prompt-guidance-contract.ts',
+  'src/config/generator.ts',
+  'src/cli/setup.ts',
+];
+
+const PROMPT_SURFACE_DIRS = [
+  'prompts',
+  'skills',
+  'templates/model-instructions',
+  'docs/prompt-guidance-fragments',
+];
+
+const MARKERS = [
+  '<!-- OMX:RUNTIME:START -->',
+  '<!-- OMX:RUNTIME:END -->',
+  '<!-- OMX:TEAM:WORKER:START -->',
+  '<!-- OMX:TEAM:WORKER:END -->',
+  '<!-- OMX:MODELS:START -->',
+  '<!-- OMX:MODELS:END -->',
+  '<!-- omx:generated:agents-md -->',
+];
+
+const ABSOLUTE_DIRECTIVE_PATTERN = /\b(MUST(?:\s+NOT)?|DO NOT|DON'T|NEVER|ALWAYS|REQUIRED|REQUIRE|ONLY|STOP|ASK only|AUTO-CONTINUE|KEEP GOING)\b/i;
+
+function walkFiles(root: string, dir: string, out: string[]): void {
+  const absoluteDir = join(root, dir);
+  if (!existsSync(absoluteDir)) return;
+  for (const entry of readdirSync(absoluteDir)) {
+    const rel = join(dir, entry);
+    const absolute = join(root, rel);
+    const stats = statSync(absolute);
+    if (stats.isDirectory()) {
+      walkFiles(root, rel, out);
+      continue;
+    }
+    if (stats.isFile() && /\.(md|ts)$/.test(entry)) {
+      out.push(rel);
+    }
+  }
+}
+
+export function listPromptSurfacePaths(root = process.cwd()): string[] {
+  const paths = new Set<string>();
+  for (const file of PROMPT_SURFACE_FILES) {
+    if (existsSync(join(root, file))) paths.add(file);
+  }
+
+  const walked: string[] = [];
+  for (const dir of PROMPT_SURFACE_DIRS) walkFiles(root, dir, walked);
+  for (const path of walked) paths.add(path);
+
+  return [...paths].sort();
+}
+
+function countOccurrences(text: string, needle: string): number {
+  let count = 0;
+  let index = text.indexOf(needle);
+  while (index !== -1) {
+    count += 1;
+    index = text.indexOf(needle, index + needle.length);
+  }
+  return count;
+}
+
+function approximateTokenCount(text: string): number {
+  return text.match(/[\p{L}\p{N}_'-]+|[^\s]/gu)?.length ?? 0;
+}
+
+function countAbsoluteDirectives(text: string): number {
+  return text
+    .split(/\r?\n/)
+    .filter((line) => ABSOLUTE_DIRECTIVE_PATTERN.test(line))
+    .length;
+}
+
+function inventorySurface(root: string, path: string): PromptSurfaceInventory {
+  const text = readFileSync(join(root, path), 'utf-8');
+  const markers = Object.fromEntries(MARKERS.map((marker) => [marker, countOccurrences(text, marker)]));
+  return {
+    path,
+    lines: text.length === 0 ? 0 : text.split(/\r?\n/).length,
+    approximateTokens: approximateTokenCount(text),
+    absoluteDirectiveCount: countAbsoluteDirectives(text),
+    markers,
+  };
+}
+
+function normalizeFragmentLine(line: string): string | null {
+  const normalized = line.replace(/\s+/g, ' ').trim();
+  if (normalized.length < 60) return null;
+  if (/^[-*#>|`]+$/.test(normalized)) return null;
+  return normalized;
+}
+
+function duplicateFragmentFamilies(root: string, paths: string[]): DuplicateFragmentFamily[] {
+  const occurrences = new Map<string, Set<string>>();
+  for (const path of paths) {
+    const text = readFileSync(join(root, path), 'utf-8');
+    for (const line of text.split(/\r?\n/)) {
+      const normalized = normalizeFragmentLine(line);
+      if (!normalized) continue;
+      const pathsWithLine = occurrences.get(normalized) ?? new Set<string>();
+      pathsWithLine.add(path);
+      occurrences.set(normalized, pathsWithLine);
+    }
+  }
+
+  return [...occurrences.entries()]
+    .map(([text, pathSet]) => ({ text, count: pathSet.size, paths: [...pathSet].sort() }))
+    .filter((family) => family.count > 1)
+    .sort((a, b) => b.count - a.count || a.text.localeCompare(b.text))
+    .slice(0, 50);
+}
+
+export function buildPromptInventory(root = process.cwd(), generatedAt = new Date().toISOString()): PromptInventoryReport {
+  const resolvedRoot = root;
+  const paths = listPromptSurfacePaths(resolvedRoot);
+  const surfaces = paths.map((path) => inventorySurface(resolvedRoot, path));
+  return {
+    generatedAt,
+    root: resolvedRoot,
+    totals: {
+      files: surfaces.length,
+      lines: surfaces.reduce((sum, surface) => sum + surface.lines, 0),
+      approximateTokens: surfaces.reduce((sum, surface) => sum + surface.approximateTokens, 0),
+      absoluteDirectiveCount: surfaces.reduce((sum, surface) => sum + surface.absoluteDirectiveCount, 0),
+    },
+    surfaces,
+    duplicateFragmentFamilies: duplicateFragmentFamilies(resolvedRoot, paths),
+  };
+}
+
+export function renderPromptInventoryMarkdown(report: PromptInventoryReport): string {
+  const rows = report.surfaces.map((surface) => {
+    const markerHits = Object.entries(surface.markers)
+      .filter(([, count]) => count > 0)
+      .map(([marker, count]) => `${marker} (${count})`)
+      .join('<br>');
+    return `| ${surface.path} | ${surface.lines} | ${surface.approximateTokens} | ${surface.absoluteDirectiveCount} | ${markerHits || '—'} |`;
+  });
+
+  const duplicates = report.duplicateFragmentFamilies.length === 0
+    ? ['- None detected.']
+    : report.duplicateFragmentFamilies.map(
+        (family) => `- ${family.count} files: ${family.text}\n  - ${family.paths.join(', ')}`,
+      );
+
+  return [
+    '# Prompt Inventory',
+    '',
+    `Generated: ${report.generatedAt}`,
+    `Root: ${relative(process.cwd(), report.root) || '.'}`,
+    '',
+    '## Totals',
+    '',
+    `- Files: ${report.totals.files}`,
+    `- Lines: ${report.totals.lines}`,
+    `- Approximate tokens: ${report.totals.approximateTokens}`,
+    `- Absolute directive lines: ${report.totals.absoluteDirectiveCount}`,
+    '',
+    '## Surfaces',
+    '',
+    '| Path | Lines | Approx. tokens | Absolute directive lines | Markers |',
+    '| --- | ---: | ---: | ---: | --- |',
+    ...rows,
+    '',
+    '## Duplicated fragment families',
+    '',
+    ...duplicates,
+    '',
+  ].join('\n');
+}
+
+if (import.meta.url === `file://${process.argv[1]}`) {
+  const root = process.argv.includes('--root') ? process.argv[process.argv.indexOf('--root') + 1] : process.cwd();
+  const report = buildPromptInventory(root);
+  if (process.argv.includes('--json')) {
+    console.log(JSON.stringify(report, null, 2));
+  } else {
+    console.log(renderPromptInventoryMarkdown(report));
+  }
+}

package/src/scripts/run-test-files.ts

@@ -62,6 +62,7 @@ console.error(
 
 const childEnv = { ...process.env };
 delete childEnv.NODE_TEST_CONTEXT;
+childEnv.OMX_TEST_RELAX_TMUX_TIMEOUT = '1';
 
 const result = spawnSync(process.execPath, testArgs, {
   stdio: 'inherit',

package/templates/AGENTS.md

@@ -37,99 +37,59 @@ Keep runtime marker contracts stable and non-destructive when overlays are appli
 - Check official documentation before implementing with unfamiliar SDKs, frameworks, or APIs.
 - Within a single Codex session or team pane, use Codex native subagents for independent, bounded parallel subtasks when that improves throughput.
 <!-- OMX:GUIDANCE:OPERATING:START -->
-- Default to quality-first, intent-deepening responses; think one more step before replying or asking for clarification, and use as much detail as needed for a strong result without empty verbosity.
-- Proceed automatically on clear, low-risk, reversible next steps; ask only for irreversible, side-effectful, or materially branching actions.
+- Default to outcome-first, quality-focused responses: identify the user's target result, success criteria, constraints, available evidence, expected output, and stop condition before adding process detail.
+- Keep collaboration style short and direct. Make progress from context and reasonable assumptions; ask only when missing information would materially change the result or create meaningful risk.
+- Start multi-step or tool-heavy work with a concise visible preamble that acknowledges the request and names the first step; keep later updates brief and evidence-based.
+- Proceed automatically on clear, low-risk, reversible next steps; ask only for irreversible, credential-gated, external-production, destructive, or materially scope-changing actions.
 - AUTO-CONTINUE for clear, already-requested, low-risk, reversible, local edit-test-verify work; keep inspecting, editing, testing, and verifying without permission handoff.
 - ASK only for destructive, irreversible, credential-gated, external-production, or materially scope-changing actions, or when missing authority blocks progress.
 - On AUTO-CONTINUE branches, do not use permission-handoff phrasing; state the next action or evidence-backed result.
 - Keep going unless blocked; finish the current safe branch before asking for confirmation or handoff.
 - Ask only when blocked by missing information, missing authority, or an irreversible/destructive branch.
+- Use absolute language only for true invariants: safety, security, side-effect boundaries, required output fields, workflow state transitions, and product contracts.
 - Do not ask or instruct humans to perform ordinary non-destructive, reversible actions; execute those safe reversible OMX/runtime operations and ordinary commands yourself.
 - Treat OMX runtime manipulation, state transitions, and ordinary command execution as agent responsibilities when they are safe and reversible.
 - Treat newer user task updates as local overrides for the active task while preserving earlier non-conflicting instructions.
 - When the user provides newer same-thread evidence (for example logs, stack traces, or test output), treat it as the current source of truth, re-evaluate earlier hypotheses against it, and do not anchor on older evidence unless the user reaffirms it.
-- Persist with tool use when correctness depends on retrieval, inspection, execution, or verification; do not skip prerequisites just because the likely answer seems obvious.
-- More effort does not mean reflexive web/tool escalation; browse or use tools when the task materially benefits, not as a default show of effort.
+- Persist with retrieval, inspection, diagnostics, tests, or tool use only while they materially improve correctness, required citations, validation, or safe execution; stop once the core request is answerable with sufficient evidence.
+- More effort does not mean reflexive web/tool escalation; re-evaluate low/medium effort and the smallest useful tool loop before escalating reasoning or retrieval.
 <!-- OMX:GUIDANCE:OPERATING:END -->
 </operating_principles>
 
 ## Working agreements
-- Write a cleanup plan before modifying code for cleanup/refactor/deslop work.
-- Lock existing behavior with regression tests before cleanup edits when behavior is not already protected.
-- Prefer deletion over addition.
-- Reuse existing utils and patterns before introducing new abstractions.
-- No new dependencies without explicit request.
+- For cleanup/refactor/deslop work, write a cleanup plan and lock behavior with regression tests before editing when coverage is missing.
+- Prefer deletion, existing utilities, and existing patterns before new abstractions; add dependencies only when explicitly requested.
 - Keep diffs small, reviewable, and reversible.
-- Run lint, typecheck, tests, and static analysis after changes.
-- Final reports must include changed files, simplifications made, and remaining risks.
+- Verify with lint, typecheck, tests, and static analysis after changes; final reports include changed files, simplifications, and remaining risks.
 
 <lore_commit_protocol>
 ## Lore Commit Protocol
 
-Every commit message must follow the Lore protocol — structured decision records using native git trailers.
-Commits are not just labels on diffs; they are the atomic unit of institutional knowledge.
+Every commit message must follow the Lore protocol: a concise decision record using git-native trailers.
 
 ### Format
 
 ```
 <intent line: why the change was made, not what changed>
 
-<body: narrative context — constraints, approach rationale>
+<optional concise body: constraints and approach rationale>
 
 Constraint: <external constraint that shaped the decision>
 Rejected: <alternative considered> | <reason for rejection>
 Confidence: <low|medium|high>
 Scope-risk: <narrow|moderate|broad>
 Directive: <forward-looking warning for future modifiers>
-Tested: <what was verified (unit, integration, manual)>
+Tested: <what was verified>
 Not-tested: <known gaps in verification>
 ```
 
 ### Rules
 
-1. **Intent line first.** The first line describes *why*, not *what*. The diff already shows what changed.
-2. **Trailers are optional but encouraged.** Use the ones that add value; skip the ones that don't.
-3. **`Rejected:` prevents re-exploration.** If you considered and rejected an alternative, record it so future agents don't waste cycles re-discovering the same dead end.
-4. **`Directive:` is a message to the future.** Use it for "do not change X without checking Y" warnings.
-5. **`Constraint:` captures external forces.** API limitations, policy requirements, upstream bugs — things not visible in the code.
-6. **`Not-tested:` is honest.** Declaring known verification gaps is more valuable than pretending everything is covered.
-7. **All trailers use git-native trailer format** (key-value after a blank line). No custom parsing required.
-
-### Example
-
-```
-Prevent silent session drops during long-running operations
-
-The auth service returns inconsistent status codes on token
-expiry, so the interceptor catches all 4xx responses and
-triggers an inline refresh.
-
-Constraint: Auth service does not support token introspection
-Constraint: Must not add latency to non-expired-token paths
-Rejected: Extend token TTL to 24h | security policy violation
-Rejected: Background refresh on timer | race condition with concurrent requests
-Confidence: high
-Scope-risk: narrow
-Directive: Error handling is intentionally broad (all 4xx) — do not narrow without verifying upstream behavior
-Tested: Single expired token refresh (unit)
-Not-tested: Auth service cold-start > 500ms behavior
-```
-
-### Trailer Vocabulary
-
-| Trailer | Purpose |
-|---------|---------|
-| `Constraint:` | External constraint that shaped the decision |
-| `Rejected:` | Alternative considered and why it was rejected |
-| `Confidence:` | Author's confidence level (low/medium/high) |
-| `Scope-risk:` | How broadly the change affects the system (narrow/moderate/broad) |
-| `Reversibility:` | How easily the change can be undone (clean/messy/irreversible) |
-| `Directive:` | Forward-looking instruction for future modifiers |
-| `Tested:` | What verification was performed |
-| `Not-tested:` | Known gaps in verification |
-| `Related:` | Links to related commits, issues, or decisions |
-
-Teams may introduce domain-specific trailers without breaking compatibility.
+- Intent line first; describe why, not what.
+- Use trailers only when they add decision context.
+- Use `Rejected:` for alternatives future agents should not re-explore.
+- Use `Directive:` for warnings, `Constraint:` for external forces, and `Not-tested:` for known verification gaps.
+- Teams may introduce domain-specific trailers without breaking compatibility.
 </lore_commit_protocol>
 
 ---
@@ -204,13 +164,7 @@ Leader/workflow routing contract:
 ---
 
 <agent_catalog>
-Key roles:
-- `explore` — fast codebase search and mapping
-- `planner` — work plans and sequencing
-- `architect` — read-only analysis, diagnosis, tradeoffs
-- `debugger` — root-cause analysis
-- `executor` — implementation and refactoring
-- `verifier` — completion evidence and validation
+Key roles: `explore` (repo search/mapping), `planner` (plans/sequencing), `architect` (read-only design/diagnosis), `debugger` (root cause), `executor` (implementation/refactoring), and `verifier` (completion evidence).
 
 Research/discovery specialists:
 - `explore` — first-stop repository lookup and symbol/file mapping
@@ -227,14 +181,14 @@ Keyword routing is implemented primarily by native `UserPromptSubmit` hooks and
 
 Fallback behavior when hook context is unavailable:
 - Explicit `$name` invocations run left-to-right and override implicit keywords.
-- Bare skill names do not activate skills by themselves; skill-name activation requires explicit `$skill` invocation. Natural-language routing phrases may still map to a workflow when they are not just the bare skill name. Examples: `analyze` / `investigate` → `$analyze` for read-only deep analysis with ranked synthesis, explicit confidence, and concrete file references; `deep interview`, `interview`, `don't assume`, or `ouroboros` → `$deep-interview`; `ralplan` / `consensus plan` → `$ralplan`; `cancel`, `stop`, or `abort` → `$cancel`.
+- Bare skill names do not activate skills by themselves; skill-name activation requires explicit `$skill` invocation. Natural-language routing phrases may still map to a workflow when they are not just the bare skill name. Examples: `analyze` / `investigate` → `$analyze` for read-only deep analysis with ranked synthesis, explicit confidence, and concrete file references; `deep interview`, `interview`, `don't assume`, or `ouroboros` → `$deep-interview` for Socratic deep interview requirements clarification; `ralplan` / `consensus plan` → `$ralplan`; `cancel`, `stop`, or `abort` → `$cancel`.
 - Keep the detailed keyword list in `src/hooks/keyword-registry.ts`; do not duplicate that table here.
 
 Runtime availability gate:
 - Treat `autopilot`, `ralph`, `ultrawork`, `ultraqa`, `team`/`swarm`, and `ecomode` as **OMX runtime workflows**, not generic prompt aliases.
 - Auto-activate runtime workflows only when the current session is actually running under OMX CLI/runtime (for example, launched via `omx`, with OMX session overlay/runtime state available, or when the user explicitly asks to run `omx ...` in the shell).
 - In Codex App or plain Codex sessions without OMX runtime, do **not** treat those keywords alone as activation. Explain that they require OMX CLI runtime support and are not directly available there, and continue with the nearest App-safe surface (`deep-interview`, `ralplan`, `plan`, or native subagents) unless the user explicitly wants you to launch OMX CLI from shell first.
-- When deep-interview is active in OMX CLI/runtime, ask interview rounds via `omx question`; after launching `omx question` in a background terminal, wait for that terminal to finish and read the JSON answer before continuing; do not substitute `request_user_input` or ad hoc plain-text questioning, and respect Stop-hook blocking while a deep-interview question obligation is pending.
+- When deep-interview is active in attached-tmux OMX CLI/runtime, ask each interview round via `omx question` as a temporary popup-style renderer over the leader pane; after launching `omx question` in a background terminal, wait for that terminal to finish and read the JSON answer before continuing; preserve the leader pane with `OMX_QUESTION_RETURN_PANE=$TMUX_PANE` (or an explicit `%pane` value) when invoking it through Bash/tool paths, prefer `answers[0].answer` / `answers[]` from the response and use legacy `answer` only as fallback, and respect Stop-hook blocking while a deep-interview question obligation is pending. Deep-interview remains one question per round; do not batch multiple interview rounds into one `questions[]` form. Outside tmux or native surfaces that cannot render `omx question` should use the native structured question path when available, otherwise ask exactly one concise plain-text question and wait for the answer.
 
 <triage_routing>
 ## Triage: advisory prompt-routing context
@@ -259,15 +213,13 @@ Ralph / Ralplan execution gate:
 ---
 
 <skills>
-Skills are workflow commands.
-Core workflows include `autopilot`, `ralph`, `ultrawork`, `visual-verdict`, `visual-ralph`, `ecomode`, `team`, `swarm`, `ultraqa`, `plan`, `deep-interview` (Socratic deep interview, Ouroboros-inspired), and `ralplan`.
-Utilities include `cancel`, `note`, `doctor`, `help`, and `trace`.
+Skills are workflow commands. Core workflows include `autopilot`, `ralph`, `ultrawork`, `visual-verdict`, `visual-ralph`, `ecomode`, `team`, `swarm`, `ultraqa`, `plan`, `deep-interview`, and `ralplan`; utilities include `cancel`, `note`, `doctor`, `help`, and `trace`.
 </skills>
 
 ---
 
 <team_compositions>
-Common team compositions remain available when explicit team orchestration is warranted, for example feature development, bug investigation, code review, and UX audit.
+Use explicit team orchestration for feature development, bug investigation, code review, UX audit, and similar multi-lane work when coordination value outweighs overhead.
 </team_compositions>
 
 ---
@@ -309,33 +261,23 @@ Sizing guidance:
 - Large or security/architectural changes: thorough verification
 
 <!-- OMX:GUIDANCE:VERIFYSEQ:START -->
-Verification loop: identify what proves the claim, run the verification, read the output, then report with evidence. If verification fails, continue iterating rather than reporting incomplete work. Default to quality-first evidence summaries: think one more step before declaring completion, and include enough detail to make the proof actionable without padding.
+Verification loop: define the claim and success criteria, run the smallest validation that can prove it, read the output, then report with evidence. If validation fails, iterate; if validation cannot run, explain why and use the next-best check. Keep evidence summaries concise but sufficient.
 
 - Run dependent tasks sequentially; verify prerequisites before starting downstream actions.
 - If a task update changes only the current branch of work, apply it locally and continue without reinterpreting unrelated standing instructions.
-- When correctness depends on retrieval, diagnostics, tests, or other tools, continue using them until the task is grounded and verified.
+- For coding work, prefer targeted tests for changed behavior, then typecheck/lint/build/smoke checks when applicable; do not claim completion without fresh evidence or an explicit validation gap.
+- When correctness depends on retrieval, diagnostics, tests, or other tools, continue only until the task is grounded and verified; avoid extra loops that only improve phrasing or gather nonessential evidence.
 <!-- OMX:GUIDANCE:VERIFYSEQ:END -->
 </verification>
 
 <execution_protocols>
-Mode selection:
-- Use `$deep-interview` first when the request is broad, intent/boundaries are unclear, or the user says not to assume.
-- Use `$ralplan` when the requirements are clear enough but architecture, tradeoffs, or test strategy still need consensus.
-- Use `$team` when the approved plan has multiple independent lanes, shared blockers, or durable coordination needs.
-- Use `$ralph` when the approved plan should stay in a persistent completion / verification loop with one owner.
-- Otherwise execute directly in solo mode.
-- Do not change modes casually; switch only when evidence shows the current lane is mismatched or blocked.
+Mode selection: use `$deep-interview` for unclear intent/boundaries; `$ralplan` for consensus on architecture, tradeoffs, or tests; `$team` for approved multi-lane work; `$ralph` for persistent single-owner completion/verification loops; otherwise execute directly in solo mode. Switch modes only when evidence shows the current lane is mismatched or blocked.
 
 Command routing:
 - When `USE_OMX_EXPLORE_CMD` enables advisory routing, strongly prefer `omx explore` as the default surface for simple read-only repository lookup tasks (files, symbols, patterns, relationships).
 - For simple file/symbol lookups, use `omx explore` FIRST before attempting full code analysis.
 
-When to use what:
-- Use `omx explore --prompt ...` for simple read-only lookups.
-- Use `omx sparkshell` for noisy read-only shell commands, bounded verification runs, repo-wide listing/search, or tmux-pane summaries; `omx sparkshell --tmux-pane ...` is explicit opt-in.
-- Keep ambiguous, implementation-heavy, edit-heavy, or non-shell-only work on the richer normal path.
-- `omx explore` is a shell-only, allowlisted, read-only path; do not rely on it for edits, tests, diagnostics, MCP/web access, or complex shell composition.
-- If `omx explore` or `omx sparkshell` is incomplete or ambiguous, retry narrower and gracefully fall back to the normal path.
+Use `omx explore --prompt ...` for simple read-only lookups through the shell-only, allowlisted, read-only path. Use `omx sparkshell` for noisy read-only shell commands, bounded verification, repo-wide listing/search, or explicit `omx sparkshell --tmux-pane` summaries. Treat sparkshell as explicit opt-in. When to use what: keep ambiguous, implementation-heavy, edit-heavy, diagnostics, tests, MCP/web, and complex shell work on the normal path; if `omx explore` or `omx sparkshell` is incomplete, retry narrower or gracefully fall back to the normal path.
 
 Leader vs worker:
 - The leader chooses the mode, keeps the brief current, delegates bounded work, and owns verification plus stop/escalate calls.
@@ -353,18 +295,15 @@ Output contract:
 - Keep rationale once; do not restate the full plan every turn.
 - Expand only for risk, handoff, or explicit user request.
 
-Parallelization:
-- Run independent tasks in parallel.
-- Run dependent tasks sequentially.
-- Use background execution for builds and tests when helpful.
-- Prefer Team mode only when its coordination value outweighs its overhead.
-- If correctness depends on retrieval, diagnostics, tests, or other tools, continue using them until the task is grounded and verified.
+Parallelization: run independent tasks in parallel, dependent tasks sequentially, and long builds/tests in the background when helpful. Prefer Team mode only when coordination value outweighs overhead. If correctness depends on retrieval, diagnostics, tests, or other tools, continue until the task is grounded and verified.
 
 Anti-slop workflow:
 - Cleanup/refactor/deslop work still follows the same `$deep-interview` -> `$ralplan` -> `$team`/`$ralph` path; use `$ai-slop-cleaner` as a bounded helper inside the chosen execution lane, not as a competing top-level workflow.
-- Lock behavior with tests first, then make one smell-focused pass at a time.
-- Prefer deletion, reuse, and boundary repair over new layers.
-- Keep writer/reviewer pass separation for cleanup plans and approvals.
+- Write a cleanup plan before modifying code; lock existing behavior with regression tests first, then make one smell-focused pass at a time.
+- Prefer deletion over addition, and prefer reuse plus boundary repair over new layers.
+- No new dependencies without explicit request.
+- Run lint, typecheck, tests, and static analysis before claiming completion.
+- Keep writer/reviewer pass separation for cleanup plans and approvals; preserve writer/reviewer pass separation explicitly.
 
 Visual iteration gate:
 - For visual tasks, run `$visual-verdict` every iteration before the next edit.