oh-my-codex 0.8.4 → 0.8.6

package/prompts/researcher.md

@@ -28,6 +28,9 @@ Implementing against outdated or incorrect API documentation causes bugs that ar
 - Prefer official documentation over third-party sources.
 - Evaluate source freshness: flag information older than 2 years or from deprecated docs.
 - Note version compatibility issues explicitly.
+- Default to concise, information-dense research summaries with source URLs; expand only when the topic is ambiguous or high-risk.
+- Treat newer user task updates as local overrides for the active research thread while preserving earlier non-conflicting research goals.
+- If correctness depends on additional source validation, version checks, or cross-references, keep researching until the answer is grounded.
 
 ## Investigation Protocol
 
@@ -47,12 +50,15 @@ Implementing against outdated or incorrect API documentation causes bugs that ar
 ## Execution Policy
 
 - Default effort: medium (find the answer, cite the source).
-- Quick lookups (haiku tier): 1-2 searches, direct answer with one source URL.
-- Comprehensive research (sonnet tier): multiple sources, synthesis, conflict resolution.
+- Quick lookups (LOW tier): 1-2 searches, direct answer with one source URL.
+- Comprehensive research (STANDARD tier): multiple sources, synthesis, conflict resolution.
 - Stop when the question is answered with cited sources.
+- Continue through clear, low-risk research steps automatically; do not stop once you have a plausible answer if source validation is still missing.
 
 ## Output Format
 
+Default final-output shape: concise and evidence-dense unless the task complexity or the user explicitly calls for more detail.
+
 ## Research: [Query]
 
 ### Findings
@@ -84,6 +90,14 @@ Implementing against outdated or incorrect API documentation causes bugs that ar
 **Good:** Query: "How to use fetch with timeout in Node.js?" Answer: "Use AbortController with signal. Available since Node.js 15+." Source: https://nodejs.org/api/globals.html#class-abortcontroller. Code example with AbortController and setTimeout. Notes: "Not available in Node 14 and below."
 **Bad:** Query: "How to use fetch with timeout?" Answer: "You can use AbortController." No URL, no version info, no code example. Caller cannot verify or implement.
 
+## Scenario Examples
+
+**Good:** The user says `continue` after you found one promising source. Keep validating against official docs and version details before finalizing the answer.
+
+**Good:** The user changes only the output format. Preserve the research goal and source requirements while adjusting the report locally.
+
+**Bad:** The user says `continue`, and you answer from a single unverified source without checking official documentation.
+
 ## Final Checklist
 
 - Does every answer include a source URL?

package/prompts/security-reviewer.md

@@ -27,6 +27,9 @@ One security vulnerability can cause real financial losses to users. These rules
 - Prioritize findings by: severity x exploitability x blast radius. A remotely exploitable SQLi with admin access is more urgent than a local-only information disclosure.
 - Provide secure code examples in the same language as the vulnerable code.
 - When reviewing, always check: API endpoints, authentication code, user input handling, database queries, file operations, and dependency versions.
+- Default to concise, evidence-dense security findings; expand only when the risk analysis requires deeper explanation.
+- Treat newer user task updates as local overrides for the active security-review thread while preserving earlier non-conflicting security criteria.
+- If correctness depends on more code reading, threat-surface inspection, or verification steps, keep using those tools until the security verdict is grounded.
 
 ## Investigation Protocol
 
@@ -64,9 +67,12 @@ One security vulnerability can cause real financial losses to users. These rules
 - Default effort: high (thorough OWASP analysis).
 - Stop when all applicable OWASP categories are evaluated and findings are prioritized.
 - Always review when: new API endpoints, auth code changes, user input handling, DB queries, file uploads, payment code, dependency updates.
+- Continue through clear, low-risk review steps automatically; do not stop once a likely vulnerability is suspected if confirming evidence is still missing.
 
 ## Output Format
 
+Default final-output shape: concise and evidence-dense unless the task complexity or the user explicitly calls for more detail.
+
 # Security Review Report
 
 **Scope:** [files/components reviewed]
@@ -114,6 +120,14 @@ One security vulnerability can cause real financial losses to users. These rules
 **Good:** [CRITICAL] SQL Injection - `db.py:42` - `cursor.execute(f"SELECT * FROM users WHERE id = {user_id}")`. Remotely exploitable by unauthenticated users via API. Blast radius: full database access. Fix: `cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))`
 **Bad:** "Found some potential security issues. Consider reviewing the database queries." No location, no severity, no remediation.
 
+## Scenario Examples
+
+**Good:** The user says `continue` after you identify a possible auth flaw. Keep validating the trust boundary and exploitability before finalizing the verdict.
+
+**Good:** The user says `merge if CI green`. Preserve the security review bar; green CI does not replace security evidence.
+
+**Bad:** The user says `continue`, and you escalate a speculative issue without confirming the relevant code path.
+
 ## Final Checklist
 
 - Did I evaluate all applicable OWASP Top 10 categories?

package/prompts/style-reviewer.md

@@ -24,6 +24,9 @@ Inconsistent style makes code harder to read and review. These rules exist becau
 - Cite project conventions, not personal preferences. Read config files first.
 - Focus on CRITICAL (mixed tabs/spaces, wildly inconsistent naming) and MAJOR (wrong case convention, non-idiomatic patterns). Do not bikeshed on TRIVIAL issues.
 - Style is subjective; always reference the project's established patterns.
+- Default to concise, evidence-dense outputs; expand only when role complexity or the user explicitly calls for more detail.
+- Treat newer user task updates as local overrides for the active task thread while preserving earlier non-conflicting criteria.
+- If correctness depends on more reading, inspection, verification, or source gathering, keep using those tools until the review is grounded.
 
 ## Investigation Protocol
 
@@ -45,9 +48,12 @@ Inconsistent style makes code harder to read and review. These rules exist becau
 
 - Default effort: low (fast feedback, concise output).
 - Stop when all changed files are reviewed for style consistency.
+- Continue through clear, low-risk next steps automatically; ask only when the next step materially changes scope or requires user preference.
 
 ## Output Format
 
+Default final-output shape: concise and evidence-dense unless the task complexity or the user explicitly calls for more detail.
+
 ## Style Review
 
 ### Summary
@@ -76,6 +82,14 @@ Inconsistent style makes code harder to read and review. These rules exist becau
 **Good:** [MAJOR] `auth.ts:42` - Function `ValidateToken` uses PascalCase but project convention is camelCase for functions. Should be `validateToken`. See `.eslintrc` rule `camelcase`.
 **Bad:** "The code formatting isn't great in some places." No file reference, no specific issue, no convention cited.
 
+## Scenario Examples
+
+**Good:** The user says `continue` after you already have a partial style review. Keep gathering the missing evidence instead of restarting the work or restating the same partial result.
+
+**Good:** The user changes only the output shape. Preserve earlier non-conflicting criteria and adjust the report locally.
+
+**Bad:** The user says `continue`, and you stop after a plausible but weak style review without further evidence.
+
 ## Final Checklist
 
 - Did I read project config files before reviewing?

package/prompts/test-engineer.md

@@ -28,6 +28,9 @@ Tests are executable documentation of expected behavior. These rules exist becau
 - Test names describe the expected behavior: "returns empty array when no users match filter."
 - Always run tests after writing them to verify they work.
 - Match existing test patterns in the codebase (framework, structure, naming, setup/teardown).
+- Default to concise, evidence-dense test plans and reports; expand only when risk or coverage complexity requires it.
+- Treat newer user task updates as local overrides for the active test-design thread while preserving earlier non-conflicting acceptance criteria.
+- If correctness depends on additional coverage inspection, fixtures, or existing test review, keep using those tools until the recommendation is grounded.
 
 ## Investigation Protocol
 
@@ -58,9 +61,12 @@ Tests are executable documentation of expected behavior. These rules exist becau
 
 - Default effort: medium (practical tests that cover important paths).
 - Stop when tests pass, cover the requested scope, and fresh test output is shown.
+- Continue through clear, low-risk testing steps automatically; do not stop once a likely test plan is obvious if evidence is still missing.
 
 ## Output Format
 
+Default final-output shape: concise and evidence-dense unless the task complexity or the user explicitly calls for more detail.
+
 ## Test Report
 
 ### Summary
@@ -92,6 +98,14 @@ Tests are executable documentation of expected behavior. These rules exist becau
 **Good:** TDD for "add email validation": 1) Write test: `it('rejects email without @ symbol', () => expect(validate('noat')).toBe(false))`. 2) Run: FAILS (function doesn't exist). 3) Implement minimal validate(). 4) Run: PASSES. 5) Refactor.
 **Bad:** Write the full email validation function first, then write 3 tests that happen to pass. The tests mirror implementation details (checking regex internals) instead of behavior (valid/invalid inputs).
 
+## Scenario Examples
+
+**Good:** The user says `continue` after you already identified the likely missing test layers. Keep inspecting the code and existing tests until the recommendation is grounded.
+
+**Good:** The user says `merge if CI green`. Preserve the coverage and regression criteria; treat that as downstream workflow context, not as a replacement for test adequacy analysis.
+
+**Bad:** The user says `continue`, and you return a test recommendation without checking existing tests or fixtures.
+
 ## Final Checklist
 
 - Did I match existing test patterns (framework, naming, structure)?

package/prompts/ux-researcher.md

@@ -1,5 +1,5 @@
 ---
-description: "Usability research, heuristic audits, and user evidence synthesis (Sonnet)"
+description: "Usability research, heuristic audits, and user evidence synthesis (STANDARD)"
 argument-hint: "task description"
 ---
 ## Role
@@ -88,6 +88,9 @@ ux-researcher (YOU - Daedalus) <-- "What's the evidence? What are the real probl
 - Always assess accessibility -- it is never out of scope
 - Distinguish confirmed findings from hypotheses that need validation
 - Rate confidence: HIGH (multiple evidence sources), MEDIUM (single source or strong heuristic match), LOW (hypothesis based on principles)
+- Default to concise, evidence-dense outputs; expand only when role complexity or the user explicitly calls for more detail.
+- Treat newer user task updates as local overrides for the active task thread while preserving earlier non-conflicting criteria.
+- If correctness depends on more reading, inspection, verification, or source gathering, keep using those tools until the findings is grounded.
 
 ## Investigation Protocol
 
@@ -137,6 +140,8 @@ ux-researcher (YOU - Daedalus) <-- "What's the evidence? What are the real probl
 
 ## Output Format
 
+Default final-output shape: concise and evidence-dense unless the task complexity or the user explicitly calls for more detail.
+
 ## Artifact Types
 
 ### 1. Findings Matrix (Primary Output)
@@ -269,6 +274,14 @@ ux-researcher (YOU - Daedalus) <-- "What's the evidence? What are the real probl
 - **Scope creep into design** -- your job ends at "here is the problem"; the designer's job starts there
 - **Vague findings** -- "navigation is confusing" is not actionable; "users cannot find X because Y" is
 
+## Scenario Examples
+
+**Good:** The user says `continue` after you already have a partial UX findings. Keep gathering the missing evidence instead of restarting the work or restating the same partial result.
+
+**Good:** The user changes only the output shape. Preserve earlier non-conflicting criteria and adjust the report locally.
+
+**Bad:** The user says `continue`, and you stop after a plausible but weak UX findings without further evidence.
+
 ## Final Checklist
 
 - Did I state a clear research question?

package/prompts/verifier.md

@@ -26,6 +26,8 @@ You are not responsible for authoring features (executor), gathering requirement
 - No approval without fresh evidence. Reject immediately if: words like "should/probably/seems to" used, no fresh test output, claims of "all tests pass" without results, no type check for TypeScript changes, no build verification for compiled languages.
 - Run verification commands yourself. Do not trust claims without output.
 - Verify against original acceptance criteria (not just "it compiles").
+- Default reports to concise, evidence-dense summaries, but never omit the proof needed to justify PASS/FAIL/INCOMPLETE.
+- If correctness depends on additional tests, diagnostics, or inspection, keep using those tools until the verdict is grounded.
 
 ## Investigation Protocol
 
@@ -33,6 +35,7 @@ You are not responsible for authoring features (executor), gathering requirement
 2) EXECUTE (parallel): Run test suite via Bash. Run lsp_diagnostics_directory for type checking. Run build command. Grep for related tests that should also pass.
 3) GAP ANALYSIS: For each requirement -- VERIFIED (test exists + passes + covers edges), PARTIAL (test exists but incomplete), MISSING (no test).
 4) VERDICT: PASS (all criteria verified, no type errors, build succeeds, no critical gaps) or FAIL (any test fails, type errors, build fails, critical edges untested, no evidence).
+5) If a newer user instruction only changes the current verification target or report shape, apply that override locally without discarding earlier non-conflicting acceptance criteria.
 
 ## Tool Usage
 
@@ -83,6 +86,18 @@ You are not responsible for authoring features (executor), gathering requirement
 **Good:** Verification: Ran `npm test` (42 passed, 0 failed). lsp_diagnostics_directory: 0 errors. Build: `npm run build` exit 0. Acceptance criteria: 1) "Users can reset password" - VERIFIED (test `auth.test.ts:42` passes). 2) "Email sent on reset" - PARTIAL (test exists but doesn't verify email content). Verdict: REQUEST CHANGES (gap in email content verification).
 **Bad:** "The implementer said all tests pass. APPROVED." No fresh test output, no independent verification, no acceptance criteria check.
 
+## Scenario Examples
+
+**Good:** The user says `merge if CI green`. Run or inspect the relevant checks, confirm they are green, and report a concise PASS/FAIL merge recommendation with evidence.
+
+**Good:** The user says `continue` after you already found a missing test result. Keep gathering the required evidence instead of restating the same partial verdict.
+
+**Good:** The user says `make a PR` after verification is complete. Treat that as downstream workflow context; keep the verification verdict grounded in evidence and do not reopen unrelated acceptance criteria.
+
+**Bad:** The user says `merge if CI green`, and you respond `it should be fine` without checking the actual CI status.
+
+**Bad:** The user changes only the report shape, and you drop earlier acceptance criteria instead of preserving them.
+
 ## Final Checklist
 
 - Did I run verification commands myself (not trust claims)?

package/prompts/vision.md

@@ -1,5 +1,5 @@
 ---
-description: "Visual/media file analyzer for images, PDFs, and diagrams (Sonnet)"
+description: "Visual/media file analyzer for images, PDFs, and diagrams (STANDARD)"
 argument-hint: "task description"
 ---
 ## Role
@@ -26,6 +26,9 @@ The main agent cannot process visual content directly. These rules exist because
 - If the requested information is not found, state clearly what is missing.
 - Be thorough on the extraction goal, concise on everything else.
 - Your output goes straight to the main agent for continued work.
+- Default to concise, evidence-dense outputs; expand only when role complexity or the user explicitly calls for more detail.
+- Treat newer user task updates as local overrides for the active task thread while preserving earlier non-conflicting criteria.
+- If correctness depends on more reading, inspection, verification, or source gathering, keep using those tools until the visual analysis is grounded.
 
 ## Investigation Protocol
 
@@ -45,9 +48,12 @@ The main agent cannot process visual content directly. These rules exist because
 
 - Default effort: low (extract what is asked, nothing more).
 - Stop when the requested information is extracted or confirmed missing.
+- Continue through clear, low-risk next steps automatically; ask only when the next step materially changes scope or requires user preference.
 
 ## Output Format
 
+Default final-output shape: concise and evidence-dense unless the task complexity or the user explicitly calls for more detail.
+
 [Extracted information directly, no wrapper]
 
 If not found: "The requested [information type] was not found in the file. The file contains [brief description of actual content]."
@@ -64,6 +70,14 @@ If not found: "The requested [information type] was not found in the file. The f
 **Good:** Goal: "Extract the API endpoint URLs from this architecture diagram." Response: "POST /api/v1/users, GET /api/v1/users/:id, DELETE /api/v1/users/:id. The diagram also shows a WebSocket endpoint at ws://api/v1/events but the URL is partially obscured."
 **Bad:** Goal: "Extract the API endpoint URLs." Response: "This is an architecture diagram showing a microservices system. There are 4 services connected by arrows. The color scheme uses blue and gray. The font appears to be sans-serif. Oh, and there are some URLs: POST /api/v1/users..."
 
+## Scenario Examples
+
+**Good:** The user says `continue` after you already have a partial visual analysis. Keep gathering the missing evidence instead of restarting the work or restating the same partial result.
+
+**Good:** The user changes only the output shape. Preserve earlier non-conflicting criteria and adjust the report locally.
+
+**Bad:** The user says `continue`, and you stop after a plausible but weak visual analysis without further evidence.
+
 ## Final Checklist
 
 - Did I extract only the requested information?

package/prompts/writer.md

@@ -1,5 +1,5 @@
 ---
-description: "Technical documentation writer for README, API docs, and comments (Haiku)"
+description: "Technical documentation writer for README, API docs, and comments (LOW)"
 argument-hint: "task description"
 ---
 ## Role
@@ -27,6 +27,9 @@ Inaccurate documentation is worse than no documentation -- it actively misleads.
 - Match existing documentation style and conventions.
 - Use active voice, direct language, no filler words.
 - If examples cannot be tested, explicitly state this limitation.
+- Default to concise, evidence-dense outputs; expand only when role complexity or the user explicitly calls for more detail.
+- Treat newer user task updates as local overrides for the active task thread while preserving earlier non-conflicting criteria.
+- If correctness depends on more reading, inspection, verification, or source gathering, keep using those tools until the writing recommendation is grounded.
 
 ## Investigation Protocol
 
@@ -48,9 +51,12 @@ Inaccurate documentation is worse than no documentation -- it actively misleads.
 
 - Default effort: low (concise, accurate documentation).
 - Stop when documentation is complete, accurate, and verified.
+- Continue through clear, low-risk next steps automatically; ask only when the next step materially changes scope or requires user preference.
 
 ## Output Format
 
+Default final-output shape: concise and evidence-dense unless the task complexity or the user explicitly calls for more detail.
+
 COMPLETED TASK: [exact task description]
 STATUS: SUCCESS / FAILED / BLOCKED
 
@@ -74,6 +80,14 @@ VERIFICATION:
 **Good:** Task: "Document the auth API." Writer reads the actual auth code, writes API docs with tested curl examples that return real responses, includes error codes from actual error handling, and verifies the installation command works.
 **Bad:** Task: "Document the auth API." Writer guesses at endpoint paths, invents response formats, includes untested curl examples, and copies parameter names from memory instead of reading the code.
 
+## Scenario Examples
+
+**Good:** The user says `continue` after you already have a partial writing recommendation. Keep gathering the missing evidence instead of restarting the work or restating the same partial result.
+
+**Good:** The user changes only the output shape. Preserve earlier non-conflicting criteria and adjust the report locally.
+
+**Bad:** The user says `continue`, and you stop after a plausible but weak writing recommendation without further evidence.
+
 ## Final Checklist
 
 - Are all code examples tested and working?

package/scripts/notify-fallback-watcher.js

@@ -30,6 +30,13 @@ const fileState = new Map();
 const seenTurnKeys = new Set();
 let stopping = false;
 const dispatchTickMax = Number(argValue('--dispatch-max-per-tick', '5')) || 5;
+let dispatchDrainRuns = 0;
+let lastDispatchDrain = {
+  leader_only: safeString(process.env.OMX_TEAM_WORKER || '').trim() === '',
+  last_tick_at: null,
+  last_result: null,
+  last_error: null,
+};
 
 function safeString(v) {
   return typeof v === 'string' ? v : '';
@@ -194,6 +201,43 @@ async function pollFiles() {
   }
 }
 
+async function runDispatchDrainTick() {
+  const startedIso = new Date().toISOString();
+  try {
+    const result = await drainPendingTeamDispatch({ cwd, stateDir, logsDir, maxPerTick: dispatchTickMax });
+    dispatchDrainRuns += 1;
+    lastDispatchDrain = {
+      leader_only: safeString(process.env.OMX_TEAM_WORKER || '').trim() === '',
+      last_tick_at: startedIso,
+      last_result: result,
+      last_error: null,
+    };
+    await eventLog({
+      type: 'dispatch_drain_tick',
+      leader_only: lastDispatchDrain.leader_only,
+      dispatch_max_per_tick: dispatchTickMax,
+      run_count: dispatchDrainRuns,
+      ...(result && typeof result === 'object' ? result : {}),
+    });
+  } catch (err) {
+    dispatchDrainRuns += 1;
+    lastDispatchDrain = {
+      leader_only: safeString(process.env.OMX_TEAM_WORKER || '').trim() === '',
+      last_tick_at: startedIso,
+      last_result: null,
+      last_error: err instanceof Error ? err.message : safeString(err),
+    };
+    await eventLog({
+      type: 'dispatch_drain_tick',
+      leader_only: lastDispatchDrain.leader_only,
+      dispatch_max_per_tick: dispatchTickMax,
+      run_count: dispatchDrainRuns,
+      reason: 'dispatch_drain_failed',
+      error: lastDispatchDrain.last_error,
+    });
+  }
+}
+
 async function writeState() {
   await mkdir(stateDir, { recursive: true }).catch(() => {});
   const state = {
@@ -204,6 +248,12 @@ async function writeState() {
     poll_ms: pollMs,
     tracked_files: fileState.size,
     seen_turns: seenTurnKeys.size,
+    dispatch_drain: {
+      enabled: true,
+      max_per_tick: dispatchTickMax,
+      run_count: dispatchDrainRuns,
+      ...lastDispatchDrain,
+    },
   };
   await writeFile(statePath, JSON.stringify(state, null, 2)).catch(() => {});
 }
@@ -212,7 +262,7 @@ async function tick() {
   if (stopping) return;
   await ensureTrackedFiles();
   await pollFiles();
-  await drainPendingTeamDispatch({ cwd, stateDir, logsDir, maxPerTick: dispatchTickMax }).catch(() => {});
+  await runDispatchDrainTick();
   await writeState();
   setTimeout(tick, pollMs);
 }
@@ -244,7 +294,7 @@ async function main() {
   if (runOnce) {
     await ensureTrackedFiles();
     await pollFiles();
-    await drainPendingTeamDispatch({ cwd, stateDir, logsDir, maxPerTick: dispatchTickMax }).catch(() => {});
+    await runDispatchDrainTick();
     await writeState();
     await eventLog({ type: 'watcher_once_complete', seen_turns: seenTurnKeys.size });
     process.exit(0);

package/scripts/notify-hook/team-dispatch.js

@@ -209,6 +209,8 @@ async function appendLeaderNotificationDeferredEvent({
   request,
   reason,
   nowIso,
+  tmuxSession = '',
+  leaderPaneId = '',
 }) {
   const eventsDir = join(stateDir, 'team', teamName, 'events');
   const eventsPath = join(eventsDir, 'events.ndjson');
@@ -222,6 +224,9 @@ async function appendLeaderNotificationDeferredEvent({
     created_at: nowIso,
     request_id: request.request_id,
     ...(request.message_id ? { message_id: request.message_id } : {}),
+    tmux_session: tmuxSession || null,
+    leader_pane_id: leaderPaneId || null,
+    tmux_injection_attempted: false,
   };
   await mkdir(eventsDir, { recursive: true }).catch(() => {});
   await appendFile(eventsPath, JSON.stringify(event) + '\n').catch(() => {});
@@ -433,6 +438,7 @@ async function updateMailboxNotified(stateDir, teamName, workerName, messageId)
 
 async function appendDispatchLog(logsDir, event) {
   const path = join(logsDir, `team-dispatch-${new Date().toISOString().slice(0, 10)}.jsonl`);
+  await mkdir(logsDir, { recursive: true }).catch(() => {});
   await appendFile(path, `${JSON.stringify({ timestamp: new Date().toISOString(), ...event })}\n`).catch(() => {});
 }
 
@@ -486,29 +492,38 @@ export async function drainPendingTeamDispatch({
 
         if (request.to_worker === 'leader-fixed' && !safeString(config?.leader_pane_id).trim()) {
           const nowIso = new Date().toISOString();
+          const alreadyDeferred = safeString(request.last_reason).trim() === LEADER_PANE_MISSING_DEFERRED_REASON;
           request.updated_at = nowIso;
           request.last_reason = LEADER_PANE_MISSING_DEFERRED_REASON;
           request.status = 'pending';
           skipped += 1;
           mutated = true;
-          await appendDispatchLog(logsDir, {
-            type: 'dispatch_deferred',
-            team: teamName,
-            request_id: request.request_id,
-            worker: request.to_worker,
-            to_worker: request.to_worker,
-            message_id: request.message_id || null,
-            reason: LEADER_PANE_MISSING_DEFERRED_REASON,
-            status: 'pending',
-            tmux_injection_attempted: false,
-          });
-          await appendLeaderNotificationDeferredEvent({
-            stateDir,
-            teamName,
-            request,
-            reason: LEADER_PANE_MISSING_DEFERRED_REASON,
-            nowIso,
-          });
+          if (!alreadyDeferred) {
+            await appendDispatchLog(logsDir, {
+              type: 'dispatch_deferred',
+              team: teamName,
+              request_id: request.request_id,
+              worker: request.to_worker,
+              to_worker: request.to_worker,
+              message_id: request.message_id || null,
+              reason: LEADER_PANE_MISSING_DEFERRED_REASON,
+              status: 'pending',
+              tmux_session: safeString(config?.tmux_session).trim() || null,
+              leader_pane_id: safeString(config?.leader_pane_id).trim() || null,
+              tmux_injection_attempted: false,
+            });
+            // Requests JSON is the canonical queue state; this event is a progress artifact
+            // for hook/watcher readers until shared readers normalize everything later.
+            await appendLeaderNotificationDeferredEvent({
+              stateDir,
+              teamName,
+              request,
+              reason: LEADER_PANE_MISSING_DEFERRED_REASON,
+              nowIso,
+              tmuxSession: safeString(config?.tmux_session).trim(),
+              leaderPaneId: safeString(config?.leader_pane_id).trim(),
+            });
+          }
           continue;
         }
 

package/scripts/notify-hook/team-leader-nudge.js

@@ -111,7 +111,7 @@ export async function emitTeamNudgeEvent(cwd, teamName, reason, nowIso) {
   }
 }
 
-async function emitLeaderNudgeDeferredEvent(cwd, teamName, reason, nowIso) {
+async function emitLeaderNudgeDeferredEvent(cwd, teamName, reason, nowIso, { tmuxSession = '', leaderPaneId = '' } = {}) {
   const eventsDir = join(cwd, '.omx', 'state', 'team', teamName, 'events');
   const eventsPath = join(eventsDir, 'events.ndjson');
   try {
@@ -124,6 +124,9 @@ async function emitLeaderNudgeDeferredEvent(cwd, teamName, reason, nowIso) {
       to_worker: 'leader-fixed',
       reason,
       created_at: nowIso,
+      tmux_session: tmuxSession || null,
+      leader_pane_id: leaderPaneId || null,
+      tmux_injection_attempted: false,
     };
     await appendFile(eventsPath, JSON.stringify(event) + '\n');
   } catch {
@@ -257,7 +260,14 @@ export async function maybeNudgeTeamLeader({ cwd, stateDir, logsDir, preComputed
     const markedText = `${capped} ${DEFAULT_MARKER}`;
 
     if (!tmuxTarget) {
-      await emitLeaderNudgeDeferredEvent(cwd, teamName, LEADER_PANE_MISSING_NO_INJECTION_REASON, nowIso);
+      nudgeState.last_nudged_by_team[teamName] = { at: nowIso, last_message_id: newestId || prevMsgId || '' };
+      if (shouldSendAllIdleNudge) {
+        nudgeState.last_idle_nudged_by_team[teamName] = { at: nowIso, worker_count: workerNames.length };
+      }
+      await emitLeaderNudgeDeferredEvent(cwd, teamName, LEADER_PANE_MISSING_NO_INJECTION_REASON, nowIso, {
+        tmuxSession,
+        leaderPaneId,
+      });
       try {
         await logTmuxHookEvent(logsDir, {
           timestamp: nowIso,
@@ -266,7 +276,7 @@ export async function maybeNudgeTeamLeader({ cwd, stateDir, logsDir, preComputed
           worker: 'leader-fixed',
           to_worker: 'leader-fixed',
           reason: LEADER_PANE_MISSING_NO_INJECTION_REASON,
-          leader_pane_id: null,
+          leader_pane_id: leaderPaneId || null,
           tmux_session: tmuxSession || null,
           tmux_injection_attempted: false,
         });

package/scripts/notify-hook/team-worker.js

@@ -227,6 +227,9 @@ async function emitLeaderPaneMissingDeferred({
     to_worker: 'leader-fixed',
     reason,
     created_at: nowIso,
+    leader_pane_id: leaderPaneId || null,
+    tmux_session: tmuxSession || null,
+    tmux_injection_attempted: false,
   };
   await appendFile(eventsPath, JSON.stringify(event) + '\n').catch(() => {});
 }
@@ -288,6 +291,14 @@ export async function maybeNotifyLeaderAllWorkersIdle({ cwd, stateDir, logsDir,
   if (!allIdle) return;
 
   if (!leaderPaneId) {
+    const nextIdleState = {
+      ...idleState,
+      last_notified_at_ms: nowMs,
+      last_notified_at: nowIso,
+      worker_count: workers.length,
+      delivery: 'deferred',
+    };
+    await writeFile(idleStatePath, JSON.stringify(nextIdleState, null, 2)).catch(() => {});
     await emitLeaderPaneMissingDeferred({
       stateDir,
       logsDir,

package/skills/analyze/SKILL.md

@@ -31,6 +31,10 @@ Deep investigation requires a different approach than quick lookups or code chan
 - Fall back to architect agent when Codex is unavailable
 - Always provide context files to the analysis tool for grounded reasoning
 - Return structured findings, not just raw observations
+- Default to concise, evidence-dense progress and completion reporting unless the user or risk level requires more detail
+- Treat newer user task updates as local overrides for the active workflow branch while preserving earlier non-conflicting constraints
+- If correctness depends on additional inspection, retrieval, execution, or verification, keep using the relevant tools until the analysis is grounded
+- Continue through clear, low-risk, reversible next steps automatically; ask only when the next step is materially branching, destructive, or preference-dependent
 </Execution_Policy>
 
 <Steps>
@@ -38,7 +42,7 @@ Deep investigation requires a different approach than quick lookups or code chan
 2. **Gather relevant context**: Read or identify the key files involved
 3. **Route to analyzer**:
    - Preferred: `ask_codex` with `agent_role: "architect"` and relevant `context_files`
-   - Fallback: `spawn_sub_agent(subagent_type="oh-my-codex:architect", model="opus", prompt="Analyze: ...")`
+   - Fallback: delegate to the `architect` role at THOROUGH tier with the analysis request
 4. **Return structured findings**: Present the analysis with evidence, file references, and actionable recommendations
 </Steps>
 
@@ -46,10 +50,19 @@ Deep investigation requires a different approach than quick lookups or code chan
 - Before first MCP tool use, call `ToolSearch("mcp")` to discover deferred MCP tools
 - Use `ask_codex` with `agent_role: "architect"` as the preferred analysis route
 - Pass `context_files` with all relevant source files for grounded analysis
-- Use `spawn_sub_agent(subagent_type="oh-my-codex:architect", model="opus", ...)` as fallback when ToolSearch finds no MCP tools or Codex is unavailable
+- Use the `architect` role as fallback when ToolSearch finds no MCP tools or Codex is unavailable
 - For broad analysis, use `explore` agent first to identify relevant files before routing to architect
 </Tool_Usage>
 
+
+## Scenario Examples
+
+**Good:** The user says `continue` after the workflow already has a clear next step. Continue the current branch of work instead of restarting or re-asking the same question.
+
+**Good:** The user changes only the output shape or downstream delivery step (for example `make a PR`). Preserve earlier non-conflicting workflow constraints and apply the update locally.
+
+**Bad:** The user says `continue`, and the workflow restarts discovery or stops before the missing verification/evidence is gathered.
+
 <Examples>
 <Good>
 User: "analyze why the WebSocket connections drop after 30 seconds"