oh-my-opencode 5.0.0-beta.79 → 5.0.0-beta.80

package/packages/omo-codex/plugin/package-lock.json

@@ -1,12 +1,12 @@
 {
 	"name": "@sisyphuslabs/omo-codex-plugin",
-	"version": "5.0.0-beta.79",
+	"version": "5.0.0-beta.80",
 	"lockfileVersion": 3,
 	"requires": true,
 	"packages": {
 		"": {
 			"name": "@sisyphuslabs/omo-codex-plugin",
-			"version": "5.0.0-beta.79",
+			"version": "5.0.0-beta.80",
 			"workspaces": [
 				"components/comment-checker",
 				"components/git-bash",
@@ -90,7 +90,7 @@
 		},
 		"components/comment-checker": {
 			"name": "@code-yeongyu/codex-comment-checker",
-			"version": "5.0.0-beta.79",
+			"version": "5.0.0-beta.80",
 			"license": "MIT",
 			"bin": {
 				"omo-comment-checker": "dist/cli.js"
@@ -111,7 +111,7 @@
 		},
 		"components/git-bash": {
 			"name": "@sisyphuslabs/codex-git-bash-hook",
-			"version": "5.0.0-beta.79",
+			"version": "5.0.0-beta.80",
 			"bin": {
 				"omo-git-bash-hook": "dist/cli.js"
 			},
@@ -125,7 +125,7 @@
 		},
 		"components/lazycodex-executor-verify": {
 			"name": "@code-yeongyu/codex-lazycodex-executor-verify",
-			"version": "5.0.0-beta.79",
+			"version": "5.0.0-beta.80",
 			"license": "MIT",
 			"bin": {
 				"lazycodex-executor-verify": "dist/cli.js"
@@ -142,7 +142,7 @@
 		},
 		"components/lsp": {
 			"name": "@code-yeongyu/codex-lsp",
-			"version": "5.0.0-beta.79",
+			"version": "5.0.0-beta.80",
 			"license": "MIT",
 			"dependencies": {
 				"@code-yeongyu/lsp-daemon": "file:../../../../lsp-daemon",
@@ -163,7 +163,7 @@
 		},
 		"components/rules": {
 			"name": "@code-yeongyu/codex-rules",
-			"version": "5.0.0-beta.79",
+			"version": "5.0.0-beta.80",
 			"license": "MIT",
 			"dependencies": {
 				"picomatch": "^4.0.7"
@@ -185,7 +185,7 @@
 		},
 		"components/teammode": {
 			"name": "@sisyphuslabs/codex-teammode",
-			"version": "5.0.0-beta.79",
+			"version": "5.0.0-beta.80",
 			"devDependencies": {
 				"@types/node": "^26.2.0",
 				"bun-types": "^1.4.2",
@@ -198,7 +198,7 @@
 		},
 		"components/telemetry": {
 			"name": "@code-yeongyu/codex-telemetry",
-			"version": "5.0.0-beta.79",
+			"version": "5.0.0-beta.80",
 			"license": "MIT",
 			"bin": {
 				"omo-telemetry": "dist/cli.js"
@@ -216,7 +216,7 @@
 		},
 		"components/ultrawork": {
 			"name": "@code-yeongyu/codex-ultrawork",
-			"version": "5.0.0-beta.79",
+			"version": "5.0.0-beta.80",
 			"license": "MIT",
 			"bin": {
 				"omo-ultrawork": "dist/cli.js"
@@ -234,7 +234,7 @@
 		},
 		"components/ulw-execute-continuation": {
 			"name": "@code-yeongyu/codex-ulw-execute-continuation",
-			"version": "5.0.0-beta.79",
+			"version": "5.0.0-beta.80",
 			"license": "MIT",
 			"bin": {
 				"omo-ulw-execute-continuation": "dist/cli.js"
@@ -251,7 +251,7 @@
 		},
 		"components/ulw-loop": {
 			"name": "@code-yeongyu/codex-ulw-loop",
-			"version": "5.0.0-beta.79",
+			"version": "5.0.0-beta.80",
 			"license": "MIT",
 			"bin": {
 				"omo-ulw-loop": "dist/cli.js",

package/packages/omo-codex/plugin/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sisyphuslabs/omo-codex-plugin",
-  "version": "5.0.0-beta.79",
+  "version": "5.0.0-beta.80",
   "description": "Aggregate Codex plugin root for OMO components.",
   "type": "module",
   "packageManager": "npm@11.12.1",

package/packages/omo-codex/plugin/skills/debugging/references/methodology/02-investigate.md

@@ -75,22 +75,22 @@ When the `team_*` tools are present, create a **debug-squad** team and split inv
   "members": [
     {
       "kind": "category",
-      "category": "deep",
+      "category": "deep-low",
       "prompt": "You are the Runtime State Inspector. Your job: attach to the live process, hit breakpoints, read program state (variables, heap, goroutines, stack, registers depending on runtime), and report observed values verbatim. Never guess — if you don't see the value, say so. Report back via team_send_message with file:line / address references and captured values. Never edit source code. Never run git commands. If you need an instrumentation statement added (breakpoint(), debugger;, dbg!, etc.), ask the Lead first."
     },
     {
       "kind": "category",
-      "category": "deep",
+      "category": "deep-low",
       "prompt": "You are the Log Archaeologist. Your job: grep server logs, stderr streams, SDK-internal debug output (DEBUG env, RUST_LOG, GODEBUG, PYTHONASYNCIODEBUG), and correlate timestamps. Produce a timeline of events with latencies. Flag anything that looks like a silent catch, a swallowed rejection, a panic recovered-and-ignored, a success response that contains failure signals (HTTP 200 with empty body, stopReason=error, exit 0 with error-in-stdout). Never edit source code."
     },
     {
       "kind": "category",
-      "category": "deep",
+      "category": "deep-low",
       "prompt": "You are the Reproduction Engineer. Your job: build the smallest reliable repro — a curl command, a vitest/pytest/go test, a tmux script, a Playwright script for browser bugs, a pwntools script for binary targets. It must reproduce on first try and be copy-pasteable by the Lead. Document exact input, expected output, observed output. Save repro artifacts under /tmp/ and tell the Lead to journal them. If the bug is browser-based you MUST use Playwright CLI — do not simulate with curl."
     },
     {
       "kind": "category",
-      "category": "deep",
+      "category": "deep-low",
       "prompt": "You are the Trace Correlator. Your job: take findings from the other members and cross-link them. Build a causal chain from symptom to suspected cause. Identify missing evidence. Propose the next single most-decisive runtime query. Never edit source code; only reason across already-captured evidence. If hypotheses diverge sharply after correlation, tell the Lead immediately — that is the signal for the Oracle Triple."
     }
   ]
@@ -117,7 +117,7 @@ task(subagent_type="explore", load_skills=[], run_in_background=true,
      Runtime state investigation for hypothesis 1: ...")
 task(subagent_type="explore", load_skills=[], run_in_background=true,
      prompt="Log/timing investigation for hypothesis 2: ...")
-task(category="deep", load_skills=[], run_in_background=true,
+task(category="deep-low", load_skills=[], run_in_background=true,
      prompt="Reproduction minimizer for hypothesis 3: ...")
 ```
 

package/packages/omo-codex/plugin/skills/refactor/SKILL.md

@@ -708,7 +708,7 @@ Record the chosen path in the TodoWrite list.
 
 Rationale for this composition:
 - **4 workers = team mode's parallel cap.** 5+ just queues.
-- **No verifier team member.** Verification needs \`deep\` reasoning (or \`unspecified-high\` fallback). In-team category routing downcasts to the category worker, which is weaker than required — the verifier runs OUTSIDE the team as a \`task(category="deep")\`.
+- **No verifier team member.** Verification needs \`deep-high\` reasoning (or \`unspecified-high\` fallback). In-team category routing downcasts to the category worker, which is weaker than required — the verifier runs OUTSIDE the team as a \`task(category="deep-high")\`.
 - **quick × 2** for mechanical edits, **unspecified-low × 2** for reasoning edits — mirrors the plan's split.
 
 **Team lifecycle** (one team, reused until Phase 6 cleanup):
@@ -740,7 +740,7 @@ While any team task is \`pending | claimed | in_progress\`:
 - On a worker completion report, immediately dispatch an **external verifier** — verification runs OUTSIDE the team because team-member category routing downcasts to the category worker:
   \`\`\`
   task(
-    category="deep",
+    category="deep-high",
     load_skills=[],
     run_in_background=true,
     description="verify step <N>",

package/packages/omo-codex/plugin/skills/remove-ai-slops/SKILL.md

@@ -184,9 +184,9 @@ File: src/bar.py
 
 Order rule (safest → riskiest): comments → dead code → defensive → duplication → complexity → abstraction/boundary → performance → tests → oversized-modules. This minimizes blast radius of any one change.
 
-### Phase 4: Parallel slop removal via `deep` agents in batches of 5
+### Phase 4: Parallel slop removal via `deep-low` agents in batches of 5
 
-Files are processed by `deep` category agents with the `$omo:remove-ai-slops` skill loaded, **batched 5 at a time in parallel**. The executable skill name is `remove-ai-slops`. The `deep` category gives the agent enough thoroughness to correctly evaluate the 9 categories and respect the KEEP rules without slipping into surface fixes; the 5-wide batch is the sweet spot — more than 5 creates result-merging noise and context contention, fewer wastes parallelism.
+Files are processed by `deep-low` category agents with the `$omo:remove-ai-slops` skill loaded, **batched 5 at a time in parallel**. The executable skill name is `remove-ai-slops`. The `deep-low` category gives the agent enough thoroughness to correctly evaluate the 9 categories and respect the KEEP rules without slipping into surface fixes; the 5-wide batch is the sweet spot — more than 5 creates result-merging noise and context contention, fewer wastes parallelism.
 
 **Batching protocol** (strict):
 
@@ -203,7 +203,7 @@ Files are processed by `deep` category agents with the `$omo:remove-ai-slops` sk
 
 ```
 task(
-  category="deep",
+  category="deep-low",
   load_skills=["remove-ai-slops"],
   run_in_background=true,
   description="Slop removal: {filename}",
@@ -229,7 +229,7 @@ For each skipped issue, give reason.
 )
 ```
 
-**Batch failure handling**: a `multi_agent_v1.wait_agent` timeout only means no new mailbox update arrived, not that a `deep` agent failed. For long passes, require each child to send `WORKING: <file> - <current phase>` and `BLOCKED: <reason>` only when it cannot progress. Treat a running child as alive. Mark a file for retry only when the child is completed without the deliverable, ack-only after followup, explicitly `BLOCKED:`, or no longer running. Do NOT block the remaining 4 in that batch; collect successful results and retry the failed file once later. If retry also fails, escalate that file under "Issues Found & Fixed" in the final report.
+**Batch failure handling**: a `multi_agent_v1.wait_agent` timeout only means no new mailbox update arrived, not that a `deep-low` agent failed. For long passes, require each child to send `WORKING: <file> - <current phase>` and `BLOCKED: <reason>` only when it cannot progress. Treat a running child as alive. Mark a file for retry only when the child is completed without the deliverable, ack-only after followup, explicitly `BLOCKED:`, or no longer running. Do NOT block the remaining 4 in that batch; collect successful results and retry the failed file once later. If retry also fails, escalate that file under "Issues Found & Fixed" in the final report.
 
 ### Phase 5: Verify with quality gates + critical review
 

package/packages/omo-codex/plugin/skills/ulw-execute/SKILL.md

@@ -152,13 +152,14 @@ When the plan annotates a todo with `Recommended task executor category:`, follo
 | `visual-engineering` (medium) | frontend, UI/UX, styling, animation |
 | `writing` (low) | documentation and prose |
 | `git` (low) | git operations |
-| `deep` (high) | hairy debugging, research-heavy or subtle cross-module work |
+| `deep-low` (medium) | hairy debugging, research-heavy or subtle cross-module work the worker can settle from what it reads |
+| `deep-high` (high) | the same, when the central decision cannot be settled from evidence: a trade-off, a cross-package contract, or correctness argued from invariants |
 | `ultrabrain` (high) | ONE genuinely hard, logic-heavy problem — hand it the goal, not step-by-step instructions |
 
 Sizing is a two-branch decision made per checkbox, before dispatch:
 
 - **Splittable work splits.** When the checkbox decomposes into independent pieces, dispatch them as a swarm of `quick`/`unspecified-low` workers in ONE parallel burst — many small cheap workers in parallel beat one large delegation.
-- **Cohesive hard work stays whole.** When splitting would sever shared reasoning (one algorithm, one migration, one subtle bug), send the WHOLE problem to `deep` or `ultrabrain` as ONE delegation. Never force-split work whose parts share one insight.
+- **Cohesive hard work stays whole.** When splitting would sever shared reasoning (one algorithm, one migration, one subtle bug), send the WHOLE problem to `deep-low`, `deep-high` or `ultrabrain` as ONE delegation. Never force-split work whose parts share one insight.
 
 Each sub-task message must include:
 

package/packages/omo-codex/plugin/skills/ulw-plan/references/full-workflow.md

@@ -154,7 +154,7 @@ No Metis, no plan file, no execution until the user approves. The UNCLEAR path a
 ## Commit strategy
 ## Success criteria
 ```
-> Target 5-8 todos per wave; fewer than 3 (except the final) means under-splitting. Implementation + Test = ONE todo. Each todo carries: exhaustive References (the executor has no interview context), agent-executable Acceptance criteria, happy + failure QA scenarios each with an evidence path, a Commit line, and a `Recommended task executor category:` line - the routing verdict the executor follows, with a one-line reason, in the omo category vocabulary: `quick` (mechanical / single-file - the default for every splittable piece), `unspecified-low` (small misc), `unspecified-high` (standard multi-file feature), `visual-engineering` (frontend/UI), `writing` (docs), `git` (git ops), `deep` (hairy debugging or cross-module reasoning), `ultrabrain` (ONE genuinely hard cohesive problem, delegated whole). Prefer many small `quick`-routable todos spread across parallel waves; when splitting would sever shared reasoning, keep ONE todo routed to `deep`/`ultrabrain` - never force-split work whose parts share one insight. Harnesses without categories map by difficulty: quick/unspecified-low/writing/git = low, unspecified-high/visual-engineering = medium, deep/ultrabrain = high.
+> Target 5-8 todos per wave; fewer than 3 (except the final) means under-splitting. Implementation + Test = ONE todo. Each todo carries: exhaustive References (the executor has no interview context), agent-executable Acceptance criteria, happy + failure QA scenarios each with an evidence path, a Commit line, and a `Recommended task executor category:` line - the routing verdict the executor follows, with a one-line reason, in the omo category vocabulary: `quick` (mechanical / single-file - the default for every splittable piece), `unspecified-low` (small misc), `unspecified-high` (standard multi-file feature), `visual-engineering` (frontend/UI), `writing` (docs), `git` (git ops), `deep-low` (hairy debugging or cross-module reasoning the worker can settle from what it reads), `deep-high` (the same, when the central decision cannot be settled from evidence: a trade-off, a cross-package contract, or correctness argued from invariants), `ultrabrain` (ONE genuinely hard cohesive problem, delegated whole). Prefer many small `quick`-routable todos spread across parallel waves; when splitting would sever shared reasoning, keep ONE todo routed to `deep`/`ultrabrain` - never force-split work whose parts share one insight. Harnesses without categories map by difficulty: quick/unspecified-low/writing/git = low, unspecified-high/visual-engineering = medium, deep/ultrabrain = high.
 
 ## Plan artifact producer contract
 

package/packages/omo-codex/plugin/skills/ulw-research/SKILL.md

@@ -255,7 +255,7 @@ Interest alone is not a trigger. Anything without one stays a queued lead in `ex
 Settle with executed code, not judgment, whenever sources disagree, a behavior is undocumented, a claim is performance- or compatibility-shaped, or the honest answer is "it should work". Spawn one verification worker per claim:
 
 ```
-task(category="deep", run_in_background=true, prompt="TASK: verify by execution: <claim>.
+task(category="deep-low", run_in_background=true, prompt="TASK: verify by execution: <claim>.
 SOURCE: <where it came from>; CONTRADICTION: <opposing source, if any>.
 Write a minimal self-contained script that tests the claim; run it (uv run --with <deps> python / bun / direct compile); capture full stdout+stderr; pin versions.
 Reply with: the exact code, the full output, environment (OS, runtime, dependency versions), and a verdict — CONFIRMED / REFUTED / PARTIAL — grounded in the output.")
@@ -335,7 +335,7 @@ Asset workers (background, parallel, each fed `design-spec.md`) — visuals are
 
 **Verify the asset manifest before rendering.** List every asset the document references, assert each file exists and is non-empty on disk, and re-render whatever is missing. A document that renders with three broken diagrams is a document you will publish twice.
 
-Assembly worker — `task(category="deep", load_skills=["frontend", "visual-qa", "open-design", "data-scientist", "imagegen", "ulw-loop"], run_in_background=true, ...)`: before writing, read every available design and visualization skill and apply it — the report is a designed artifact, not a text dump; the worker's prompt carries `design-spec.md`. Use the template the user approved; absent a stronger house style the default skeleton is executive summary → key findings by theme → detailed analysis (quotes under 20 words with attribution, charts, Mermaid graphs, generated visuals, SHA-pinned permalinks, verification results) → comparative analysis when options compete → numbered sources with access dates → methodology appendix (workers, waves, searches, verifications, debate rounds) → correction log naming what verification overturned. Write it long and specific: every claim cites `[Source N]`, and the sources section lists every source the run actually used rather than a curated few.
+Assembly worker — `task(category="deep-low", load_skills=["frontend", "visual-qa", "open-design", "data-scientist", "imagegen", "ulw-loop"], run_in_background=true, ...)`: before writing, read every available design and visualization skill and apply it — the report is a designed artifact, not a text dump; the worker's prompt carries `design-spec.md`. Use the template the user approved; absent a stronger house style the default skeleton is executive summary → key findings by theme → detailed analysis (quotes under 20 words with attribution, charts, Mermaid graphs, generated visuals, SHA-pinned permalinks, verification results) → comparative analysis when options compete → numbered sources with access dates → methodology appendix (workers, waves, searches, verifications, debate rounds) → correction log naming what verification overturned. Write it long and specific: every claim cites `[Source N]`, and the sources section lists every source the run actually used rather than a curated few.
 
 ### The delivery gate — visual QA must PASS