oh-my-opencode 5.1.30 → 5.1.33

package/dist/skills/browser/runtime/omowright/manifest.json

@@ -5,5 +5,5 @@
     "index.js": "b6b064fab277031c6c51f5a58b84b31040f9960bf767bf646adc0540c1d25c1b",
     "page-bundle.js": "bfd51e8383cf47200d57387bbbed258bce5a3a3d00c38fc108034d2888e23f0c"
   },
-  "stagedAtUtc": "2026-10-11T14:42:51.925Z"
+  "stagedAtUtc": "2026-10-13T16:36:35.078Z"
 }

package/dist/skills/ulw-execute/SKILL.md

@@ -34,7 +34,7 @@ Plan and reviewer agents may run for a long time: spawn them in the background a
 
 # ulw-execute
 
-Execute a work plan until every top-level checkbox is complete. This skill pairs with the harness's ulw-execute continuation hook, which re-injects the next turn while `.omo/boulder.json` says this `codex:<session_id>` still has unchecked plan work.
+Execute a work plan until every top-level checkbox is `[x]` or `[~]`. This skill pairs with the harness's ulw-execute continuation hook, which re-injects the next turn while `.omo/boulder.json` says this `codex:<session_id>` still has unchecked plan work.
 
 ## Usage
 
@@ -53,7 +53,7 @@ Do ALL of this immediately after the plan is selected, BEFORE the first implemen
 
 1. **Set the goal, in detail.** When a goal tool is available (`create_goal`), call it with a DETAILED objective: the plan name and path, the concrete end state, the phase and task counts, the delivery mode (direct, `--make-pr`, or `--ship`), and how completion will be verified. One work session = one registered goal (the goal tool holds one active goal); each phase then carries its own concrete goal — the ledger entry Phase 2 records before the wave's first dispatch, defined from the previous phase's landed and verified evidence. No goal tool -> record the same objective as the first ledger entry.
 2. **Register every phase and task as todos.** Mirror the plan into the todo/plan tool of your harness: one phase per plan wave, one todo per column-zero checkbox (including the final verification wave). Register ALL of them up front - never keep tasks in memory only.
-3. **Keep them current at every moment.** Mark a todo in_progress when its work dispatches and done immediately after its verification passes. Never batch-complete at the end, never execute work that is not a registered todo; discovered work inside the change's blast radius — the request not delivered, a regression this change introduces, an invalid proof, a failing test or stale doc of touched code — is appended to the plan as a checkbox, mirrored as a todo before it runs, and fixed to the ideal state; a defect outside it gets a tracked issue with reproduction and evidence and a line in the final report. A worker that meets a defect outside its assigned files reports it instead of fixing it; only the orchestrator appends the checkbox and dispatches it to a correctly scoped unit. The todo list, Boulder state, and plan checkboxes must always tell the same story.
+3. **Keep them current at every moment.** Mark a todo in_progress when its work dispatches and done immediately after its verification passes. Never batch-complete at the end, never execute work that is not a registered todo; discovered work inside the change's blast radius — the request not delivered, a regression this change introduces, an invalid proof, a failing test or stale doc of touched code — is appended to the plan as a follow-up checkbox after the checkpoint in progress, mirrored as a todo, and fixed to the ideal state once that checkpoint closes; it joins the open checkpoint only when it blocks that checkpoint's acceptance; a defect outside it gets a tracked issue with reproduction and evidence and a line in the final report. A worker that meets a defect outside its assigned files reports it instead of fixing it; only the orchestrator appends the checkbox and dispatches it to a correctly scoped unit. The todo list, Boulder state, and plan checkboxes must always tell the same story.
 
 ## Phase 1: Select the plan
 
@@ -96,14 +96,14 @@ Write `.omo/boulder.json` before implementation starts. Prefix session ids with
 }
 ```
 
-Every phase (plan wave) runs in its own task-owned worktree with its own goal: before the wave's first dispatch, record the wave's goal — its checkboxes and their acceptance criteria — as a ledger entry, then `git worktree add <repo>-wt/<plan>-<wave> <branch off the integration base>` (or verify a `--worktree` path with `git worktree list --porcelain`), store the absolute path as `worktree_path`, run every edit, command, test, and evidence capture inside it; the wave lands on the integration base once its checkboxes are verified (direct merge, or the PR under `--make-pr`/`--ship`), and the next wave branches from that landed base.
+Every phase (plan wave) runs in its own task-owned worktree with its own goal: before the wave's first dispatch, record the wave's goal — its checkboxes and their acceptance criteria — as a ledger entry, then `git worktree add <repo>-wt/<plan>-<wave> <branch off the integration base>` (or verify a `--worktree` path with `git worktree list --porcelain`), store the absolute path as `worktree_path`, run every edit, command, test, and evidence capture inside it; the wave lands on the integration base once each of its checkboxes is verified or `[~]` (direct merge, or the PR under `--make-pr`/`--ship`; a `[~]` row's unverified changes do not land: a dispatched worker reverts them in the wave worktree before landing, and the `unmet` entry records the revert), and the next wave branches from that landed base. Use the bundled ultrawork directive’s Task resources and todo rules at wave/worktree creation; read those sections if absent from context.
 
 ## Parallel delivery lanes (teams and worktrees)
 
 Solo orchestration with parallel background workers is the default topology. Decide once, when the wave's lanes are known, and record the verdict in the ledger:
 
 - **Independent lanes -> parallel workers.** Separate files, no shared contract: one parallel spawn burst; no team.
-- **Dependency-ordered lanes -> one `workflow` run per wave.** Sub-tasks with real ordering between them (C needs A and B finished first) and a harness with a native `workflow` tool: dispatch the wave as ONE run (one producer node per lane plus a verification node); recover inside it with `retry`/`amend`/`send`; let node completions wake you instead of arming per-lane watchers; the next wave is a NEW run (or `amend` when only the definition changed) — never one graph for the whole plan. Read the `mass-ulw` skill's `SKILL.md` and `references/planning.md` IN FULL before defining any graph.
+- **Dependency-ordered lanes -> one `workflow` run per wave.** Sub-tasks with real ordering between them (C needs A and B finished first) and a harness with a native `workflow` tool: dispatch the wave as ONE run (one producer node per lane plus a verification node); recover inside it with `retry`/`amend`/`send`; let the run's settle wake you instead of arming per-lane watchers; the next wave is a NEW run (or `amend` when only the definition changed) — never one graph for the whole plan. Read the `mass-ulw` skill's `SKILL.md` and `references/planning.md` IN FULL before defining any graph.
 - **Overlapping lanes -> a team.** The lanes touch the same module or contract AND running them concurrently actually finishes sooner: stand up a team (where the harness has one) so one lane's discoveries relay through you mid-flight.
 - **PR-mode independent lanes -> a worktree per lane.** Under `--make-pr`/`--ship`, when a wave holds independent checkboxes, give each lane its own branch and task-owned worktree, delivered as its own PR.
 
@@ -181,7 +181,7 @@ For each checkbox, complete all five gates before marking it done:
 4. Adversarial QA: exercise every class the Phase 3 trigger map marks applicable and capture the observable result for each.
 5. Cleanup: register every QA resource teardown as its own todo when spawned (QA scripts, tmux assets, browser sessions, PIDs, ports, containers, temp dirs), execute each, and capture the receipt. No QA asset is left running.
 
-Append evidence to `.omo/ulw-execute/ledger.jsonl`, one JSON object per line. Include at least `event`, `plan`, `task`, `session_id`, `commands`, `artifact`, `adversarial_classes`, and `cleanup` fields. `adversarial_classes` lists each probed class with its observable result and each ruled-out class with a one-line reason.
+Append evidence to `.omo/ulw-execute/ledger.jsonl`, one JSON object per line. Include at least `event`, `plan`, `task`, `session_id`, `commands`, `artifact`, `adversarial_classes`, and `cleanup` fields, plus `attempt` and `checkpoint_opened_at` on every entry tied to a checkbox. `adversarial_classes` lists each probed class with its observable result and each ruled-out class with a one-line reason.
 
 ### Completion contract
 
@@ -199,6 +199,7 @@ A worker done claim is never final: each implementation sub-task returns a `Done
   },
   "AdversarialVerify": {
     "verdict": "confirmed | false-positive | needs-fix | needs-human-review",
+    "failure_class": "none | product | harness",
     "evidence": ["file path, command, log, artifact, or explicit not inspected"],
     "repro": "exact command or manual steps when available",
     "confidence": 0.0
@@ -210,7 +211,9 @@ Rules:
 - `confirmed` is the only pass verdict. `false-positive`, `needs-fix`, and `needs-human-review` all block checkbox completion.
 - The verifier must be independent from the executor: use the harness's gate reviewer (see the harness compatibility section) or a fresh reviewer worker on a strong model, or root only when root did not implement or materially rewrite that task.
 - A worker done claim must be independently verified before it becomes checkbox completion.
-- On any non-confirmed verdict, append the feedback to the ledger, reset the checkbox work to in-progress, and re-dispatch the executor with the exact failure.
+- On a non-confirmed verdict, append the feedback to the ledger with the attempt number and its failure signature (the failing check plus its first error line, with volatile values stripped: temp-dir paths, timestamps, process and run ids, durations). Attempts count per checkbox across all its sub-tasks and re-splits, timed from its first dispatch (`checkpoint_opened_at`). STOP when the same signature repeats on consecutive attempts, on the third failed attempt, or 4 hours after the first dispatch (a plan may change these numbers, never remove the stop). Check the 4-hour bound also when a lane's watcher fires or the turn resumes without a verdict; when it has passed, cancel that lane and stop the same way: mark the checkbox `- [~]` (the plan grammar's blocked state) with a one-line gap naming what is unmet and the last evidence, mark every checkbox that depends on it, directly or through another `[~]` row, `- [~]` with the gap `blocked by <id>`, close the todo of every row marked `[~]` here labelled `blocked: <gap>`, append an `unmet` ledger entry listing what each attempt changed, and continue in the same turn with the next checkpoint that depends on none of them, or with Completion when none remains. Otherwise leave the checkbox `- [ ]` and re-dispatch the executor with the exact failure.
+- A `[~]` row counts as closed, never as a met dependency: Phase 3 skips it, Completion starts once every top-level row is `[x]` or `[~]`, and the `ORCHESTRATION COMPLETE` block names each `[~]` row with its gap. Final Verification Wave rows are never dependents of a `[~]` row: they verify the landed work and report each `[~]` row as a known gap, which alone never fails a final-wave row. A `[~]` gap is never re-queued as a new checkbox in this run, by the blast-radius rule or by a final-wave verdict; the one harness-repair follow-up in the next rule is the only exception.
+- The verifier sets `failure_class`. A `harness` failure (the runner, fixture, CI job or environment failed and the product behavior was never exercised) gets one repair dispatch inside the checkpoint, which does not count as an attempt; when it recurs, stop as above with the harness gap named and append the harness repair once as a follow-up checkbox; a harness-repair follow-up that stops is reported, not re-appended.
 - The verifier must probe the applicable adversarial keys, including `stale_state`, `dirty_worktree`, and `misleading_success_output`, before allowing `FullyDone`.
 
 ## Phase 5: Mark progress
@@ -227,7 +230,7 @@ Only after verification passes:
 When all top-level checkboxes in `## TODOs` and `## Final Verification Wave` are complete:
 
 1. Run the plan's final verification commands.
-2. For PR/branch work, finish the lifecycle from the last phase's worktree: sync `.omo/` state back to the main repo, create or update the PR, wait for review/verification gates, merge by default unless explicitly opted out, and remove the worktree only after successful merge or explicit handoff.
+2. For PR/branch work, finish the lifecycle from the last phase's worktree: sync `.omo/` state back to the main repo, create or update the PR, wait for review/verification gates, merge by default unless explicitly opted out, and remove the worktree only after successful merge or explicit handoff. Finish directory teardown per Task resources and record its receipts.
 3. Remove or mark the Boulder work as completed.
 4. Print an `ORCHESTRATION COMPLETE` block with the plan path, verification commands, artifacts, and cleanup receipts.
 

package/dist/skills/ulw-research/SKILL.md

@@ -132,7 +132,7 @@ Then create the session directory:
 mkdir -p .omo/ulw-research/$(date +%Y%m%d-%H%M%S)
 ```
 
-This is `$SESSION_DIR`. The orchestrator owns the journal: you write every file in it; workers never do. Maintain:
+This is `$SESSION_DIR`. The orchestrator owns the journal: you write every file in it; workers never do (a mass-research dag node writes only its own `waves/<run-key>/<node-id>.md` handoff file, which carries its EXPAND tail and claim candidates; you journal from it). Maintain:
 
 - `brief.md` — the analysis block, the axis list, the expected truths, and the `## Deliverable` record from the interview below (lane, state, formats, each field with `answered_by`).
 - `sources-ledger.md` — one line per source the moment it is read: `[S<n>] <url> — <what it is>`. The closing briefing counts sources and domains from this file.
@@ -165,7 +165,7 @@ Phase 5 opens by turning the recorded fields into `design-spec.md`.
 
 ## Phase 1 — Saturation wave
 
-**When the user asked for MASS research, the wave is sized by the topic's angles, not by the roster ceiling.** "mass ulw research", "mulw research", "ulw mass research" — in any language — order over-collection that a team of 8 cannot produce. Where the harness has a dependency-graph surface (the `mass-ulw` skill and its `references/planning.md`), run collection through it instead: a 60+ node opening wave covering every angle the topic has, routed across the whole difficulty ladder in one graph — mechanical sweeps and per-item harvest batches on the cheapest tier, judgment-shaped angles a step up, cross-territory angles a step above that, and the deepest tier reserved for genuinely hairy contradictions. Each wave's EXPAND leads define the next wave's nodes, and the synthesis reduces through several parallel architect-tier nodes into ONE architect-tier reducer (the strongest reasoning tier substitutes wherever no architect tier exists). Absent that surface, hold the same shape with background workers in batched waves. Everything else in this skill still binds: the deliverable interview, the journal, the claim graph, the convergence rules, and the delivery gates.
+**When the user asked for MASS research, the wave is sized by the topic's angles, not by the roster ceiling.** "mass ulw research", "mulw research", "ulw mass research" — in any language — order over-collection that a team of 8 cannot produce. Where the harness has a dependency-graph surface (the `mass-ulw` skill and its `references/planning.md`), run collection through it instead: 60+ angles covering every angle the topic has, routed across the whole difficulty ladder — mechanical sweeps and per-item harvest batches on the cheapest tier, judgment-shaped angles a step up, cross-territory angles a step above that, and the deepest tier reserved for genuinely hairy contradictions. Define each angle as a harvest -> expand -> verify chain before the run starts, each stage reading the previous stage's handoff file; open leads re-enter as new chains in each cluster of angles the moment that cluster settles, and the synthesis reduces through per-cluster architect-tier slice reducers into ONE architect-tier reducer (the strongest reasoning tier substitutes wherever no architect tier exists). Absent that surface, run the same per-angle chains with background workers, pasting each worker's reply into its angle's next-stage prompt the moment it reports. Everything else in this skill still binds: the deliverable interview, the journal, the claim graph, the convergence rules, and the delivery gates.
 
 Otherwise launch the entire first wave in one turn — every axis at once, as team members if you formed a team, else as background workers. Sequential launches and "start with one and see" defeat the mode.
 
@@ -266,7 +266,7 @@ Journal each verdict to `verify-<slug>.md`.
 
 Code settles code-shaped claims (Phase 3). Numeric, market-share, legal, dated, causal, and financial claims cannot be run — so they pass through a data-flow-lock instead (the verification idea adapted from fivetaku/insane-research): the synthesis may assert a high-risk non-code claim **only** if it cleared this gate, and the gate's output is the sole allowlist the synthesis draws from. Skip the gate and there is nothing to synthesize — the lock is self-enforcing.
 
-The claim graph is orchestrator-owned. Workers only return verified-claim markers, observation candidates, and claim candidates as message text, the same channel as EXPAND markers — never a file. As leads resolve, you record one node per asserted claim in `claim-graph.md` and compute its status; workers report claim candidates in their replies, and you decide. The graph is the single claim store: final synthesis may not draw from free-form claims that skipped it.
+The claim graph is orchestrator-owned. Workers only return verified-claim markers, observation candidates, and claim candidates as message text, the same channel as EXPAND markers — never a file (except a mass-research dag node's handoff file). As leads resolve, you record one node per asserted claim in `claim-graph.md` and compute its status; workers report claim candidates in their replies, and you decide. The graph is the single claim store: final synthesis may not draw from free-form claims that skipped it.
 
 A high-risk claim clears the gate to `verified-claims` only when all hold:
 
@@ -387,7 +387,7 @@ High-yield combinations: official docs (`site:<docs domain>`), GitHub implementa
 | Worker reply without the EXPAND tail | One follow-up demanding it; the lane stays open until it lands |
 | Stopping after wave 1 because "enough was found" | Convergence rules only: 2+ expansion waves, leads run dry |
 | Obeying a surrounding "stop exploring" rule mid-research | Authority section — those rules do not bind this mode |
-| Asking a worker to write journal or session files | Workers are read-only; you journal every return |
+| Asking a worker to write journal or session files | Workers are read-only (except a mass-research dag node's handoff file); you journal every return |
 | Two workers given the same angle | One unique angle per worker, always |
 | A web worker that returned only fetched text, or a `Collection: browser` run whose workers never opened a tab | Sources are read in the user's browser through the `browser` skill; `webfetch` is for raw files; every web worker carries the skill from the first wave |
 | Contested claim settled by judgment | Phase 3 — run code, capture output, verdict |

package/dist/tools/delegate-task/executor-types.d.ts

@@ -12,6 +12,7 @@ export interface ExecutorContext {
     browserProvider?: BrowserAutomationProvider;
     agentOverrides?: AgentOverrides;
     sisyphusAgentConfig?: SisyphusAgentConfig;
+    claudeCodeAgentsEnabled?: boolean;
     modelFallbackControllerAccessor?: ModelFallbackControllerAccessor;
     onSyncSessionCreated?: (event: {
         sessionID: string;

package/dist/tools/delegate-task/sync-session-creator.d.ts

@@ -5,6 +5,7 @@ export declare function createSyncSession(client: OpencodeClient, input: {
     agentToUse: string;
     description: string;
     defaultDirectory: string;
+    category?: string;
     categoryModel?: DelegatedModelConfig;
 }): Promise<{
     ok: true;

package/dist/tools/delegate-task/types.d.ts

@@ -124,6 +124,8 @@ export interface DelegateTaskToolOptions {
     /** Reload model-bearing config at task invocation time so edits are honored without rebuilding tools. */
     loadCurrentModelConfig?: () => Pick<OhMyOpenCodeConfig, "agents" | "categories">;
     sisyphusAgentConfig?: SisyphusAgentConfig;
+    /** Mirrors `claude_code.agents`; when false, `.claude/agents` definitions are not read during subagent matching. */
+    claudeCodeAgentsEnabled?: boolean;
     modelFallbackControllerAccessor?: ModelFallbackControllerAccessor;
     onSyncSessionCreated?: (event: SyncSessionCreatedEvent) => Promise<void>;
     syncPollTimeoutMs?: number;

package/dist/tools/session-manager/session-error.d.ts

@@ -0,0 +1,7 @@
+export declare function describeSessionError(error: unknown): string;
+export declare function toSessionError(error: unknown): Error;
+export type SkippedSession = {
+    readonly id: string;
+    readonly reason: string;
+};
+export declare function formatSkippedSessions(skipped: readonly SkippedSession[]): string;

package/dist/tui.js

@@ -70113,7 +70113,8 @@ var init_memory = __esm(() => {
   }).strict();
   OmoMemoryFactsSchema = object({
     enabled: boolean2().default(true),
-    debounce_settles: number2().int().min(1).default(4)
+    debounce_settles: number2().int().min(1).default(4),
+    model: string2().min(1).optional()
   }).strict();
   OmoMemoryDreamSchema = object({
     enabled: boolean2().default(true),
@@ -70175,7 +70176,8 @@ var init_memory = __esm(() => {
   }).strict();
   OmoMemoryFactsLayerSchema = object({
     enabled: boolean2().optional(),
-    debounce_settles: number2().int().min(1).optional()
+    debounce_settles: number2().int().min(1).optional(),
+    model: string2().min(1).optional()
   }).strict();
   OmoMemoryDreamLayerSchema = object({
     enabled: boolean2().optional(),
@@ -74974,7 +74976,7 @@ init_shared();
 // package.json
 var package_default = {
   name: "oh-my-opencode",
-  version: "5.1.30",
+  version: "5.1.33",
   description: "The Best AI Agent Harness - Batteries-Included OpenCode Plugin with Multi-Model Orchestration, Parallel Background Agents, and Crafted LSP/AST Tools",
   main: "./dist/index.js",
   types: "dist/index.d.ts",
@@ -75151,7 +75153,7 @@ var package_default = {
   },
   devDependencies: {
     "@clack/prompts": "^1.8.1",
-    "@code-yeongyu/senpi": "2026.10.11",
+    "@code-yeongyu/senpi": "2026.10.13",
     "@modelcontextprotocol/sdk": "^1.30.0",
     "@oh-my-opencode/agents-md-core": "workspace:*",
     "@oh-my-opencode/ast-grep-mcp": "workspace:*",
@@ -75210,18 +75212,18 @@ var package_default = {
     typescript: "^7.0.2"
   },
   optionalDependencies: {
-    "oh-my-opencode-darwin-arm64": "5.1.30",
-    "oh-my-opencode-darwin-x64": "5.1.30",
-    "oh-my-opencode-darwin-x64-baseline": "5.1.30",
-    "oh-my-opencode-linux-arm64": "5.1.30",
-    "oh-my-opencode-linux-arm64-musl": "5.1.30",
-    "oh-my-opencode-linux-x64": "5.1.30",
-    "oh-my-opencode-linux-x64-baseline": "5.1.30",
-    "oh-my-opencode-linux-x64-musl": "5.1.30",
-    "oh-my-opencode-linux-x64-musl-baseline": "5.1.30",
-    "oh-my-opencode-windows-arm64": "5.1.30",
-    "oh-my-opencode-windows-x64": "5.1.30",
-    "oh-my-opencode-windows-x64-baseline": "5.1.30"
+    "oh-my-opencode-darwin-arm64": "5.1.33",
+    "oh-my-opencode-darwin-x64": "5.1.33",
+    "oh-my-opencode-darwin-x64-baseline": "5.1.33",
+    "oh-my-opencode-linux-arm64": "5.1.33",
+    "oh-my-opencode-linux-arm64-musl": "5.1.33",
+    "oh-my-opencode-linux-x64": "5.1.33",
+    "oh-my-opencode-linux-x64-baseline": "5.1.33",
+    "oh-my-opencode-linux-x64-musl": "5.1.33",
+    "oh-my-opencode-linux-x64-musl-baseline": "5.1.33",
+    "oh-my-opencode-windows-arm64": "5.1.33",
+    "oh-my-opencode-windows-x64": "5.1.33",
+    "oh-my-opencode-windows-x64-baseline": "5.1.33"
   },
   overrides: {
     hono: "^4.13.8",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "oh-my-opencode",
-  "version": "5.1.30",
+  "version": "5.1.33",
   "description": "The Best AI Agent Harness - Batteries-Included OpenCode Plugin with Multi-Model Orchestration, Parallel Background Agents, and Crafted LSP/AST Tools",
   "main": "./dist/index.js",
   "types": "dist/index.d.ts",
@@ -177,7 +177,7 @@
   },
   "devDependencies": {
     "@clack/prompts": "^1.8.1",
-    "@code-yeongyu/senpi": "2026.10.11",
+    "@code-yeongyu/senpi": "2026.10.13",
     "@modelcontextprotocol/sdk": "^1.30.0",
     "@oh-my-opencode/agents-md-core": "workspace:*",
     "@oh-my-opencode/ast-grep-mcp": "workspace:*",
@@ -236,18 +236,18 @@
     "typescript": "^7.0.2"
   },
   "optionalDependencies": {
-    "oh-my-opencode-darwin-arm64": "5.1.30",
-    "oh-my-opencode-darwin-x64": "5.1.30",
-    "oh-my-opencode-darwin-x64-baseline": "5.1.30",
-    "oh-my-opencode-linux-arm64": "5.1.30",
-    "oh-my-opencode-linux-arm64-musl": "5.1.30",
-    "oh-my-opencode-linux-x64": "5.1.30",
-    "oh-my-opencode-linux-x64-baseline": "5.1.30",
-    "oh-my-opencode-linux-x64-musl": "5.1.30",
-    "oh-my-opencode-linux-x64-musl-baseline": "5.1.30",
-    "oh-my-opencode-windows-arm64": "5.1.30",
-    "oh-my-opencode-windows-x64": "5.1.30",
-    "oh-my-opencode-windows-x64-baseline": "5.1.30"
+    "oh-my-opencode-darwin-arm64": "5.1.33",
+    "oh-my-opencode-darwin-x64": "5.1.33",
+    "oh-my-opencode-darwin-x64-baseline": "5.1.33",
+    "oh-my-opencode-linux-arm64": "5.1.33",
+    "oh-my-opencode-linux-arm64-musl": "5.1.33",
+    "oh-my-opencode-linux-x64": "5.1.33",
+    "oh-my-opencode-linux-x64-baseline": "5.1.33",
+    "oh-my-opencode-linux-x64-musl": "5.1.33",
+    "oh-my-opencode-linux-x64-musl-baseline": "5.1.33",
+    "oh-my-opencode-windows-arm64": "5.1.33",
+    "oh-my-opencode-windows-x64": "5.1.33",
+    "oh-my-opencode-windows-x64-baseline": "5.1.33"
   },
   "overrides": {
     "hono": "^4.13.8",

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

@@ -1,6 +1,6 @@
 {
   "name": "omo",
-  "version": "5.1.30",
+  "version": "5.1.33",
   "description": "One Codex plugin namespace for Yeongyu's local Codex components.",
   "author": {
     "name": "Yeongyu Kim",

package/packages/omo-codex/plugin/components/bootstrap/dist/cli.js

@@ -7158,7 +7158,8 @@ var OmoMemoryNudgeSchema = object({
 }).strict();
 var OmoMemoryFactsSchema = object({
   enabled: boolean2().default(true),
-  debounce_settles: number2().int().min(1).default(4)
+  debounce_settles: number2().int().min(1).default(4),
+  model: string2().min(1).optional()
 }).strict();
 var OmoMemoryDreamSchema = object({
   enabled: boolean2().default(true),
@@ -7220,7 +7221,8 @@ var OmoMemoryNudgeLayerSchema = object({
 }).strict();
 var OmoMemoryFactsLayerSchema = object({
   enabled: boolean2().optional(),
-  debounce_settles: number2().int().min(1).optional()
+  debounce_settles: number2().int().min(1).optional(),
+  model: string2().min(1).optional()
 }).strict();
 var OmoMemoryDreamLayerSchema = object({
   enabled: boolean2().optional(),

package/packages/omo-codex/plugin/components/bootstrap/hooks/hooks.json

@@ -8,7 +8,7 @@
 						"command": "node \"${PLUGIN_ROOT}/components/bootstrap/dist/cli.js\" hook session-start",
 						"commandWindows": "powershell -NoProfile -ExecutionPolicy Bypass -File \"${PLUGIN_ROOT}\\components\\bootstrap\\scripts\\bootstrap.ps1\"",
 						"timeout": 30,
-						"statusMessage": "(OmO 5.1.30) Checking Bootstrap Provisioning"
+						"statusMessage": "(OmO 5.1.33) Checking Bootstrap Provisioning"
 					}
 				]
 			}

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

@@ -1,6 +1,6 @@
 {
 	"name": "@sisyphuslabs/codex-bootstrap",
-	"version": "5.1.30",
+	"version": "5.1.33",
 	"description": "Codex SessionStart bootstrap component that provisions LazyCodex runtime dependencies from a detached worker.",
 	"type": "module",
 	"private": true,

package/packages/omo-codex/plugin/components/comment-checker/hooks/hooks.json

@@ -8,7 +8,7 @@
 						"type": "command",
 						"command": "node \"${PLUGIN_ROOT}/dist/cli.js\" hook post-tool-use",
 						"timeout": 30,
-						"statusMessage": "(OmO 5.1.30) Checking Comments"
+						"statusMessage": "(OmO 5.1.33) Checking Comments"
 					}
 				]
 			}

package/packages/omo-codex/plugin/components/comment-checker/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@code-yeongyu/codex-comment-checker",
-	"version": "5.1.30",
+	"version": "5.1.33",
 	"description": "Codex plugin that runs comment-checker after edit-like PostToolUse hooks.",
 	"type": "module",
 	"packageManager": "npm@11.12.1",

package/packages/omo-codex/plugin/components/git-bash/hooks/hooks.json

@@ -8,7 +8,7 @@
 						"type": "command",
 						"command": "node \"${PLUGIN_ROOT}/dist/cli.js\" hook pre-tool-use",
 						"timeout": 5,
-						"statusMessage": "(OmO 5.1.30) Recommending Git Bash MCP"
+						"statusMessage": "(OmO 5.1.33) Recommending Git Bash MCP"
 					}
 				]
 			}
@@ -20,7 +20,7 @@
 						"type": "command",
 						"command": "node \"${PLUGIN_ROOT}/dist/cli.js\" hook post-compact",
 						"timeout": 5,
-						"statusMessage": "(OmO 5.1.30) Resetting Git Bash MCP Reminder"
+						"statusMessage": "(OmO 5.1.33) Resetting Git Bash MCP Reminder"
 					}
 				]
 			}

package/packages/omo-codex/plugin/components/git-bash/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@sisyphuslabs/codex-git-bash-hook",
-	"version": "5.1.30",
+	"version": "5.1.33",
 	"description": "Codex hook component that reminds Windows sessions to prefer the OMO git_bash MCP.",
 	"type": "module",
 	"private": true,

package/packages/omo-codex/plugin/components/lazycodex-executor-verify/hooks/hooks.json

@@ -8,7 +8,7 @@
 						"type": "command",
 						"command": "node \"${PLUGIN_ROOT}/components/lazycodex-executor-verify/dist/cli.js\" hook subagent-stop",
 						"timeout": 10,
-						"statusMessage": "(OmO 5.1.30) Verifying LazyCodex Executor Evidence"
+						"statusMessage": "(OmO 5.1.33) Verifying LazyCodex Executor Evidence"
 					}
 				]
 			}

package/packages/omo-codex/plugin/components/lazycodex-executor-verify/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@code-yeongyu/codex-lazycodex-executor-verify",
-	"version": "5.1.30",
+	"version": "5.1.33",
 	"description": "Codex SubagentStop evidence verifier for LazyCodex executor completions.",
 	"type": "module",
 	"packageManager": "npm@11.12.1",

package/packages/omo-codex/plugin/components/lcx/skills/lcx-contribute-bug-fix/SKILL.md

@@ -37,11 +37,12 @@ For `code-yeongyu/lazycodex`, create an issue (never a PR) that includes:
 
 ## Required Workflow
 
-1. Read the user's bug report and identify the affected surface.
+1. Read the user's bug report and identify the affected surface. Before commands, apply the bundled ultrawork directive’s Task resources and todo rules; read those sections if absent from context.
 2. Invoke `$omo:debugging` for the investigation. If only unqualified skill names are exposed, invoke `$debugging` and state that it is the OMO debugging skill.
 3. Materialize the latest sources under `LAZYCODEX_SOURCE_ROOT="${LAZYCODEX_SOURCE_ROOT:-${TMPDIR:-/tmp}/lazycodex-sources}"`, then decide the target repository. Sync both checkouts on every run and compare them before choosing. Validate cached checkouts before reuse so an incomplete `.git` directory cannot route the fix to the wrong repo:
 
 ```bash
+# The default checkout cache is per-task under TMPDIR=$RUN_TMP.
 LAZYCODEX_SOURCE_ROOT="${LAZYCODEX_SOURCE_ROOT:-${TMPDIR:-/tmp}/lazycodex-sources}"
 mkdir -p "$LAZYCODEX_SOURCE_ROOT"
 
@@ -86,11 +87,11 @@ sync_latest_source() {
 sync_latest_source code-yeongyu/lazycodex "$LAZYCODEX_SOURCE_ROOT/lazycodex-source"
 sync_latest_source openai/codex "$LAZYCODEX_SOURCE_ROOT/chatgpt-subscription-source"
 ```
-4. Create a fresh temporary clone and branch under `${TMPDIR:-/tmp}`. Do not modify the user's current repository for the target fix unless the current repository is itself the requested target and the user explicitly asked for local edits.
+4. Create a fresh temporary clone and branch under `${TMPDIR:-/tmp}`. Do not modify the user's current repository for the target fix unless the current repository is itself the requested target and the user explicitly asked for local edits. Apply those resource rules at clone/worktree creation.
 
 ```bash
 TARGET_REPO="code-yeongyu/lazycodex" # or openai/codex
-WORK_ROOT="$(mktemp -d "${TMPDIR:-/tmp}/lazycodex-fix-XXXXXX")"
+WORK_ROOT="${RUN_TMP:?apply ultrawork Task resources first}"
 gh repo clone "$TARGET_REPO" "$WORK_ROOT/repo" -- --depth=1
 cd "$WORK_ROOT/repo"
 BASE_BRANCH="$(git remote show origin | sed -n '/HEAD branch/s/.*: //p')"
@@ -152,13 +153,15 @@ git push -u fork "$BRANCH_NAME"
 gh pr create --repo openai/codex --base "$BASE_BRANCH" --head "$GH_USER:$BRANCH_NAME" --title "<short fix title>" "${LABEL_ARGS[@]}" --body-file "$PR_BODY"
 ```
 
-13. Clean up:
+13. Finish cleanup per Task resources. Run this only when that rule permits removing the worktree and run root; otherwise retain them and report the outstanding cleanup todo:
 
 ```bash
 cd /
 git -C "$WORK_ROOT/repo" worktree remove "$WORK_ROOT/worktree"
+unset TMPDIR NODE_COMPILE_CACHE BUN_RUNTIME_TRANSPILER_CACHE_PATH
 find "$WORK_ROOT" -mindepth 1 -maxdepth 1 -exec rm -r -- {} +
 rmdir "$WORK_ROOT"
+test ! -e "$WORK_ROOT" && printf 'cleanup: worktree and caches REMOVED\n'
 ```
 
 Return the PR or issue URL, the reproduction command, the verification command, and the cleanup receipt.

package/packages/omo-codex/plugin/components/lsp/dist/.omo-runtime-manifest.json

@@ -1,7 +1,7 @@
 {
   "schemaVersion": 1,
-  "version": "5.1.30",
-  "inputDigest": "sha256:cf776d8585ec0e86540cc12d9a01c22a20b3e13b24300062c7dae109304ad483",
+  "version": "5.1.33",
+  "inputDigest": "sha256:4371f9aa85f140a0d0329d0c4fea93008200e1f40523c65cc62d772a3d6f1ded",
   "outputs": [
     {
       "path": "cli.d.ts",

package/packages/omo-codex/plugin/components/lsp/hooks/hooks.json

@@ -8,7 +8,7 @@
 						"type": "command",
 						"command": "node \"${PLUGIN_ROOT}/dist/cli.js\" hook post-tool-use",
 						"timeout": 60,
-						"statusMessage": "(OmO 5.1.30) Checking LSP Diagnostics"
+						"statusMessage": "(OmO 5.1.33) Checking LSP Diagnostics"
 					}
 				]
 			}
@@ -21,7 +21,7 @@
 						"type": "command",
 						"command": "node \"${PLUGIN_ROOT}/dist/cli.js\" hook post-compact",
 						"timeout": 5,
-						"statusMessage": "(OmO 5.1.30) Resetting LSP Diagnostics Cache"
+						"statusMessage": "(OmO 5.1.33) Resetting LSP Diagnostics Cache"
 					}
 				]
 			}

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

@@ -1,6 +1,6 @@
 {
 	"name": "@code-yeongyu/codex-lsp",
-	"version": "5.1.30",
+	"version": "5.1.33",
 	"description": "Codex plugin that exposes Language Server Protocol tools and post-edit diagnostics.",
 	"type": "module",
 	"packageManager": "npm@11.12.1",

package/packages/omo-codex/plugin/components/rules/hooks/hooks.json

@@ -7,7 +7,7 @@
 						"type": "command",
 						"command": "node \"${PLUGIN_ROOT}/dist/cli.js\" hook session-start",
 						"timeout": 10,
-						"statusMessage": "(OmO 5.1.30) Loading Project Rules"
+						"statusMessage": "(OmO 5.1.33) Loading Project Rules"
 					}
 				]
 			}
@@ -19,7 +19,7 @@
 						"type": "command",
 						"command": "node \"${PLUGIN_ROOT}/dist/cli.js\" hook user-prompt-submit",
 						"timeout": 10,
-						"statusMessage": "(OmO 5.1.30) Loading Project Rules"
+						"statusMessage": "(OmO 5.1.33) Loading Project Rules"
 					}
 				]
 			}
@@ -32,7 +32,7 @@
 						"type": "command",
 						"command": "node \"${PLUGIN_ROOT}/dist/cli.js\" hook post-tool-use",
 						"timeout": 10,
-						"statusMessage": "(OmO 5.1.30) Matching Project Rules"
+						"statusMessage": "(OmO 5.1.33) Matching Project Rules"
 					}
 				]
 			}
@@ -45,7 +45,7 @@
 						"type": "command",
 						"command": "node \"${PLUGIN_ROOT}/dist/cli.js\" hook post-compact",
 						"timeout": 10,
-						"statusMessage": "(OmO 5.1.30) Resetting Project Rule Cache"
+						"statusMessage": "(OmO 5.1.33) Resetting Project Rule Cache"
 					}
 				]
 			}

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

@@ -1,6 +1,6 @@
 {
 	"name": "@code-yeongyu/codex-rules",
-	"version": "5.1.30",
+	"version": "5.1.33",
 	"description": "Codex plugin that injects project rule files into model context through lifecycle hooks.",
 	"type": "module",
 	"packageManager": "npm@11.12.1",

package/packages/omo-codex/plugin/components/teammode/hooks/hooks.json

@@ -8,7 +8,7 @@
 						"type": "command",
 						"command": "node \"${PLUGIN_ROOT}/dist/cli.js\" hook post-tool-use",
 						"timeout": 10,
-						"statusMessage": "(OmO 5.1.30) Checking Thread Title Hygiene"
+						"statusMessage": "(OmO 5.1.33) Checking Thread Title Hygiene"
 					}
 				]
 			}

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

@@ -1,6 +1,6 @@
 {
 	"name": "@sisyphuslabs/codex-teammode",
-	"version": "5.1.30",
+	"version": "5.1.33",
 	"description": "Codex team-mode hook component that keeps background thread titles descriptive after create_thread.",
 	"type": "module",
 	"private": true,

package/packages/omo-codex/plugin/components/teammode/skills/teammode/SKILL.md

@@ -229,9 +229,9 @@ cannot clobber each other. Decide this whenever you see the collision - at team
 not only up front. For each colliding member run `worktree-add --team <id> --id <member>`: it creates
 the worktree off the base branch on a derived branch, flips the team into worktree mode, records it in
 `team.json`, and prints the `cd` path to hand that member. The member works and commits only inside
-its own worktree. To land the work, `integrate --team <id>` merges every member branch into your
+its own worktree. Use the bundled ultrawork directive’s Task resources and todo rules at member/worktree creation; read those sections if absent from context. To land the work, `integrate --team <id>` merges every member branch into your
 current branch with a merge commit (never a squash or rebase); resolve any conflict it reports, then
-`worktree-remove` each worktree at cleanup.
+finish owned directory teardown per Task resources.
 
 Delivering the path differs by transport: on MultiAgentV2, create the worktree BEFORE spawning
 so the bootstrap carries it, or send it to an already-running member as a `followup_task`; on
@@ -280,7 +280,7 @@ is never disbanded is a leak.
 - `delete` removes `.omo/teams/{session_id}` and refuses while the team is unarchived or any member
   is still active unless `--force`.
 - When the work wraps up, land it the way the user asked: `integrate --team <id>` for a direct merge
-  commit, or push each member branch and open a PR. Then `worktree-remove` each worktree, archive, and
+  commit, or push each member branch and open a PR. Then finish worktree cleanup per Task resources, archive, and
   delete. Cleanup is real work; respect the user's instruction on how to land it.
 
 ## Stop rules

package/packages/omo-codex/plugin/components/telemetry/hooks/hooks.json

@@ -7,7 +7,7 @@
 						"type": "command",
 						"command": "node \"${PLUGIN_ROOT}/dist/cli.js\" hook session-start",
 						"timeout": 5,
-						"statusMessage": "(OmO 5.1.30) Recording Session Telemetry"
+						"statusMessage": "(OmO 5.1.33) Recording Session Telemetry"
 					}
 				]
 			}

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

@@ -1,6 +1,6 @@
 {
 	"name": "@code-yeongyu/codex-telemetry",
-	"version": "5.1.30",
+	"version": "5.1.33",
 	"description": "Codex plugin component that emits omo-codex anonymous daily-active telemetry on SessionStart.",
 	"type": "module",
 	"packageManager": "npm@11.12.1",