oh-my-opencode 5.0.0-beta.19 → 5.0.0-beta.20

package/dist/oh-my-opencode.schema.json

@@ -61,7 +61,7 @@
         "enum": [
           "goal",
           "refactor",
-          "start-work",
+          "ulw-execute",
           "stop-continuation",
           "remove-ai-slops",
           "hyperplan"
@@ -9890,6 +9890,19 @@
       },
       "additionalProperties": false
     },
+    "ulw_execute": {
+      "type": "object",
+      "properties": {
+        "auto_commit": {
+          "default": true,
+          "type": "boolean"
+        }
+      },
+      "required": [
+        "auto_commit"
+      ],
+      "additionalProperties": false
+    },
     "start_work": {
       "type": "object",
       "properties": {

package/dist/plugin/chat-message/types.d.ts

@@ -19,7 +19,7 @@ export type ChatMessageInput = {
         readonly modelID: string;
     };
 };
-export type StartWorkHookOutput = {
+export type UlwExecuteHookOutput = {
     readonly parts: Array<{
         readonly type: string;
         readonly text?: string;
@@ -29,7 +29,7 @@ export type SessionModelOverride = {
     readonly providerID: string;
     readonly modelID: string;
 };
-export type WorkStartingCommand = "start-work" | "ralph-loop" | "ulw-loop";
+export type WorkStartingCommand = "ulw-execute" | "ralph-loop" | "ulw-loop";
 type ChatMessageHook = {
     "chat.message"?: (input: ChatMessageInput, output: ChatMessageHandlerOutput) => Promise<void>;
 };
@@ -77,7 +77,7 @@ export type ChatMessageHooks = {
     noSisyphusGpt?: ChatMessageHook | null;
     noHephaestusNonGpt?: ChatMessageHook | null;
     hephaestusAgentsMdInjector?: ChatMessageHook | null;
-    startWork?: ChatMessageHook | null;
+    ulwExecute?: ChatMessageHook | null;
     goal?: GoalHook | null;
     todoContinuationEnforcer?: TodoContinuationEnforcerHook | null;
 };

package/dist/plugin/chat-message/ulw-execute-message.d.ts

@@ -0,0 +1,5 @@
+import type { ChatMessageHooks, ChatMessageInput, ChatMessageHandlerOutput, UlwExecuteHookOutput, WorkStartingCommand } from "./types";
+export declare function isUlwExecuteHookOutput(value: unknown): value is UlwExecuteHookOutput;
+export declare function isUlwExecuteFallbackTemplate(promptText: string): boolean;
+export declare function clearStoppedContinuationBeforeUlwExecute(hooks: ChatMessageHooks, sessionID: string, command: WorkStartingCommand): void;
+export declare function runUlwExecuteHookIfApplicable(hooks: ChatMessageHooks, input: ChatMessageInput, output: ChatMessageHandlerOutput): Promise<void>;

package/dist/plugin/hooks/create-core-hooks.d.ts

@@ -28,7 +28,7 @@ export declare function createCoreHooks(args: {
     goal: ReturnType<typeof import("../../hooks").createGoalHook> | null;
     editErrorRecovery: ReturnType<typeof import("../../hooks").createEditErrorRecoveryHook> | null;
     delegateTaskRetry: ReturnType<typeof import("../../hooks").createDelegateTaskRetryHook> | null;
-    startWork: ReturnType<typeof import("../../hooks").createStartWorkHook> | null;
+    ulwExecute: ReturnType<typeof import("../../hooks").createUlwExecuteHook> | null;
     prometheusMdOnly: ReturnType<typeof import("../../hooks").createPrometheusMdOnlyHook> | null;
     sisyphusJuniorNotepad: ReturnType<typeof import("../../hooks").createSisyphusJuniorNotepadHook> | null;
     noSisyphusGpt: ReturnType<typeof import("../../hooks").createNoSisyphusGptHook> | null;

package/dist/plugin/hooks/create-session-hooks.d.ts

@@ -3,7 +3,7 @@ import type { BackgroundManager } from "../../features/background-agent";
 import type { ModelFallbackControllerAccessor } from "../../hooks/model-fallback";
 import type { ModelCacheState } from "../../plugin-state";
 import type { PluginContext } from "../types";
-import { createSessionNotification, createThinkModeHook, createModelFallbackHook, createAnthropicContextWindowLimitRecoveryHook, createAutoUpdateCheckerHook, createCodegraphBootstrapHook, createAstGrepSgProvisionHook, createAgentUsageReminderHook, createNonInteractiveEnvHook, createInteractiveBashSessionHook, createEditErrorRecoveryHook, createDelegateTaskRetryHook, createTaskResumeInfoHook, createStartWorkHook, createPrometheusMdOnlyHook, createSisyphusJuniorNotepadHook, createNoSisyphusGptHook, createNoHephaestusNonGptHook, createHephaestusAgentsMdInjectorHook, createQuestionLabelTruncatorHook, createPreemptiveCompactionHook, createRuntimeFallbackHook, createLegacyPluginToastHook } from "../../hooks";
+import { createSessionNotification, createThinkModeHook, createModelFallbackHook, createAnthropicContextWindowLimitRecoveryHook, createAutoUpdateCheckerHook, createCodegraphBootstrapHook, createAstGrepSgProvisionHook, createAgentUsageReminderHook, createNonInteractiveEnvHook, createInteractiveBashSessionHook, createEditErrorRecoveryHook, createDelegateTaskRetryHook, createTaskResumeInfoHook, createUlwExecuteHook, createPrometheusMdOnlyHook, createSisyphusJuniorNotepadHook, createNoSisyphusGptHook, createNoHephaestusNonGptHook, createHephaestusAgentsMdInjectorHook, createQuestionLabelTruncatorHook, createPreemptiveCompactionHook, createRuntimeFallbackHook, createLegacyPluginToastHook } from "../../hooks";
 import { createGoalHook } from "../../hooks/goal";
 export type SessionHooks = {
     preemptiveCompaction: ReturnType<typeof createPreemptiveCompactionHook> | null;
@@ -20,7 +20,7 @@ export type SessionHooks = {
     goal: ReturnType<typeof createGoalHook> | null;
     editErrorRecovery: ReturnType<typeof createEditErrorRecoveryHook> | null;
     delegateTaskRetry: ReturnType<typeof createDelegateTaskRetryHook> | null;
-    startWork: ReturnType<typeof createStartWorkHook> | null;
+    ulwExecute: ReturnType<typeof createUlwExecuteHook> | null;
     prometheusMdOnly: ReturnType<typeof createPrometheusMdOnlyHook> | null;
     sisyphusJuniorNotepad: ReturnType<typeof createSisyphusJuniorNotepadHook> | null;
     noSisyphusGpt: ReturnType<typeof createNoSisyphusGptHook> | null;

package/dist/skills/frontend/SKILL.md

@@ -107,7 +107,7 @@ Domains: `product` `style` `typography` `color` `landing` `chart` `ux` `react` `
 
 ## Ruleset 4 — designpowers (`references/designpowers/`)
 
-`README.md` routes the pinned `Owl-Listener/designpowers` corpus into this workflow. It supplies design context — personas, accessibility and cognitive constraints, critique, debt, handoff, synthetic user testing, motion, role prompts — that must be distilled into `DESIGN.md` first, then used as the implementation contract. It replaces nothing: not this skill, not `/visual-qa`, `/ulw-plan`, `/start-work`, or `/review-work`.
+`README.md` routes the pinned `Owl-Listener/designpowers` corpus into this workflow. It supplies design context — personas, accessibility and cognitive constraints, critique, debt, handoff, synthetic user testing, motion, role prompts — that must be distilled into `DESIGN.md` first, then used as the implementation contract. It replaces nothing: not this skill, not `/visual-qa`, `/ulw-plan`, `/ulw-execute`, or `/review-work`.
 
 ## Quick routes — most common requests
 

package/dist/skills/frontend/references/designpowers/README.md

@@ -9,7 +9,7 @@ The purpose of this ruleset is to enrich the existing frontend workflow while pr
 - `references/design/README.md` still owns the `DESIGN.md` contract, taste routing, brand references, React dev tooling, and browser-based design QA expectations.
 - `references/perfection/README.md` still owns Lighthouse, performance, SEO, accessibility audit mechanics, and real-browser verification.
 - `/visual-qa` still owns objective rendered evidence for visual claims.
-- `/ulw-plan`, `/start-work`, and `/review-work` still own planning, execution, and final implementation review when those phases apply.
+- `/ulw-plan`, `/ulw-execute`, and `/review-work` still own planning, execution, and final implementation review when those phases apply.
 
 ## Load Order
 

package/dist/skills/frontend/references/designpowers/lane-a-direction.md

@@ -61,4 +61,4 @@ Lane A passes only when the plan has inspectable design context, not vague inten
 
 PASS when `ulw-plan` receives this lane context and produces a decision-complete plan whose tasks are design-aware, persona-aware, and evidence-bound.
 
-FAIL when the plan skips inclusive-personas, buries accessibility as a final polish item, treats taste as generic style, writes a parallel design plan, or leaves design decisions for start-work workers to invent.
+FAIL when the plan skips inclusive-personas, buries accessibility as a final polish item, treats taste as generic style, writes a parallel design plan, or leaves design decisions for ulw-execute workers to invent.

package/dist/skills/frontend/references/designpowers/lane-b-execution.md

@@ -1,25 +1,25 @@
 # Lane B: Design Execution Guidance
 
-Lane B feeds `start-work` workers and always loads `frontend` for UI implementation. It does not install a separate builder. Its job is to carry designpowers composition, interaction, motion, content, responsive, adaptive, token, and cognitive-accessibility guidance into worker prompts while keeps ownership of decomposition, implementation, QA, evidence, and ledger updates.
+Lane B feeds `ulw-execute` workers and always loads `frontend` for UI implementation. It does not install a separate builder. Its job is to carry designpowers composition, interaction, motion, content, responsive, adaptive, token, and cognitive-accessibility guidance into worker prompts while keeps ownership of decomposition, implementation, QA, evidence, and ledger updates.
 
 ## Phase Owner
 
 | Capability | Materialized designpowers source | owner | Mapping |
 |---|---|---|---|
-| Visual hierarchy, layout, color, typography, touch targets, and WCAG contrast | `ui-composition` | `start-work` worker plus `frontend` | Add visual constraints and acceptance checks to worker assignments. `frontend` remains the required UI implementation skill. |
-| States, feedback, loading, error, keyboard, touch, and recovery behavior | `interaction-design` | `start-work` worker plus `frontend` | Require every interactive component to define default, hover, focus, active, disabled, loading, success, and error states where applicable. |
-| Purposeful motion and reduced-motion alternatives | `motion-choreography` | `start-work` worker plus `frontend` | Require motion specs to explain what changed, what to look at next, or how elements relate; require safe alternatives. |
-| Content-driven breakpoints and zoom behavior | `responsive-patterns` | `start-work` worker plus `frontend` | Require responsive proof at narrow, mid, desktop, and 200 percent zoom scenarios when the surface is visual. |
-| User preference adaptation | `adaptive-interfaces` | `start-work` worker plus `frontend` | Require support for relevant preferences such as color scheme, contrast, reduced motion, text sizing, and density. |
-| Mental load, wayfinding, focus management, memory demands, and recovery paths | `cognitive-accessibility` | `start-work` worker plus `frontend` | Add COGA-style checks directly to worker acceptance criteria for flows, forms, navigation, and dense tools. |
-| Plain-language labels, headings, alt text, link text, errors, and instructions | `accessible-content` and `voice-and-tone` | `start-work` worker plus `frontend` | Require final copy, no placeholders, useful errors, readable labels, and consistent tone. |
+| Visual hierarchy, layout, color, typography, touch targets, and WCAG contrast | `ui-composition` | `ulw-execute` worker plus `frontend` | Add visual constraints and acceptance checks to worker assignments. `frontend` remains the required UI implementation skill. |
+| States, feedback, loading, error, keyboard, touch, and recovery behavior | `interaction-design` | `ulw-execute` worker plus `frontend` | Require every interactive component to define default, hover, focus, active, disabled, loading, success, and error states where applicable. |
+| Purposeful motion and reduced-motion alternatives | `motion-choreography` | `ulw-execute` worker plus `frontend` | Require motion specs to explain what changed, what to look at next, or how elements relate; require safe alternatives. |
+| Content-driven breakpoints and zoom behavior | `responsive-patterns` | `ulw-execute` worker plus `frontend` | Require responsive proof at narrow, mid, desktop, and 200 percent zoom scenarios when the surface is visual. |
+| User preference adaptation | `adaptive-interfaces` | `ulw-execute` worker plus `frontend` | Require support for relevant preferences such as color scheme, contrast, reduced motion, text sizing, and density. |
+| Mental load, wayfinding, focus management, memory demands, and recovery paths | `cognitive-accessibility` | `ulw-execute` worker plus `frontend` | Add COGA-style checks directly to worker acceptance criteria for flows, forms, navigation, and dense tools. |
+| Plain-language labels, headings, alt text, link text, errors, and instructions | `accessible-content` and `voice-and-tone` | `ulw-execute` worker plus `frontend` | Require final copy, no placeholders, useful errors, readable labels, and consistent tone. |
 | Tokens and design-system consistency | `token-architecture` and `design-system-alignment` | `frontend` | Require real design tokens and existing component patterns before new one-off styling. |
 
 Materialized agent references for this lane: `design-lead`, `motion-designer`, and `content-writer`. They are prompt-role references for spawned OpenAgent work, not alternate executors.
 
 ## Prompt Injection
 
-Add this block to each `start-work` implementation worker that touches UI:
+Add this block to each `ulw-execute` implementation worker that touches UI:
 
 ```text
 Load `frontend` for UI implementation. Also apply Lane B Design Execution Guidance.
@@ -43,7 +43,7 @@ Do not invent visual direction that conflicts with the plan. If the plan lacks a
 Lane B worker DoneClaims must include:
 
 - Exact changed files and the `frontend` references loaded.
-- The real-surface QA invocation required by `start-work` for the UI surface, with captured artifact path.
+- The real-surface QA invocation required by `ulw-execute` for the UI surface, with captured artifact path.
 - Screenshot, browser, HTTP, or xterm.js web-terminal artifacts appropriate to the visible surface.
 - Accessibility evidence from the existing OpenAgent frontend path, such as Lighthouse, react-doctor, keyboard checks, or other plan-required checks.
 - A short design trace: which persona, design principle, token, or state requirement each major UI decision satisfies.
@@ -52,7 +52,7 @@ Lane B worker DoneClaims must include:
 ## Guardrails
 
 - UI implementation always goes through `frontend`; Lane B only enriches the worker prompt.
-- `start-work` owns decomposition, worker dispatch, evidence ledger entries, adversarial checks, and completion state.
+- `ulw-execute` owns decomposition, worker dispatch, evidence ledger entries, adversarial checks, and completion state.
 - The materialized `design-builder` concept is not used as an available executor. OpenAgent workers build.
 - No placeholders, generic copy, unverified contrast claims, decorative-only motion, or one-off hardcoded design systems pass this lane.
 - Accessibility and cognitive-accessibility are implementation constraints, not review-only cleanup.

package/dist/skills/frontend/references/designpowers/lane-d-memory.md

@@ -7,7 +7,7 @@ Lane D records the design record around OpenAgent work. It owns `.omo/frontend-d
 | Capability | Source boundary | owner | Mapping |
 |---|---|---|---|
 | Track deferred design and accessibility findings | `design-debt-tracker` | `.omo/frontend-design/state.md` plus final `review-work` context | Maintain a register with ID, date, source, severity, issue, affected users, suggested fix, status, and notes. |
-| Package design rationale for implementers or reviewers | `design-handoff` | `start-work` and `review-work` context | Record component, interaction, accessibility, content, and rationale notes that workers or reviewers need. |
+| Package design rationale for implementers or reviewers | `design-handoff` | `ulw-execute` and `review-work` context | Record component, interaction, accessibility, content, and rationale notes that workers or reviewers need. |
 | Reflect on process after completion | `design-retrospective` | final handoff context | Record what worked, what did not, fix rounds, debt health, and lessons. |
 | Maintain observational design memory | Authored concept preserved from excluded raw `design-memory` | `.omo/frontend-design/state.md` and optional personal report context | Store observations descriptively. Do not feed them back as future project constraints. |
 | Produce a taste reflection when requested | `taste-report` | user-facing handoff only | Summarize personal-layer observations only when enough evidence exists or the user asks. |
@@ -65,7 +65,7 @@ Lane D passes only when the record is inspectable:
 - Accessibility debt is either resolved or explicitly acknowledged by the user before acceptance.
 - Handoff notes cite concrete artifacts, decisions, constraints, and evidence paths.
 - Retrospective notes cite the final verification artifacts, unresolved debt, and lessons from fix rounds or user overrides.
-- The evidence index points to real files produced by OpenAgent planning, `start-work`, `visual-qa`, or `review-work`.
+- The evidence index points to real files produced by OpenAgent planning, `ulw-execute`, `visual-qa`, or `review-work`.
 
 ## Guardrails
 
@@ -78,6 +78,6 @@ Lane D passes only when the record is inspectable:
 
 ## Pass / Fail Behavior
 
-PASS when state, design debt, handoff, retrospective, and evidence references are current enough for `ulw-plan`, `start-work`, `visual-qa`, or `review-work` to resume without guessing.
+PASS when state, design debt, handoff, retrospective, and evidence references are current enough for `ulw-plan`, `ulw-execute`, `visual-qa`, or `review-work` to resume without guessing.
 
 FAIL when deferred findings disappear, accessibility debt is accepted without acknowledgement, handoff omits artifact paths, state is stale, retrospective claims lack evidence, or memory is used as prescriptive design input.

package/dist/skills/frontend/references/designpowers/orchestration.md

@@ -51,7 +51,7 @@ When using a designpowers role reference:
 
 - name the role in the prompt text;
 - include a self-contained task, deliverable, scope, and verification expectation;
-- route actual phase ownership to frontend design/perfection, `/ulw-plan`, `/start-work`, `/visual-qa`, or `/review-work`;
+- route actual phase ownership to frontend design/perfection, `/ulw-plan`, `/ulw-execute`, `/visual-qa`, or `/review-work`;
 - record findings in the state file or review packet only when backed by artifacts or located observations.
 
 ## Reconciliation Ladder

package/dist/skills/frontend/references/designpowers/routing.md

@@ -1,13 +1,13 @@
 # designpowers Routing Contract
 
-`designpowers` routes design operating-layer guidance inside the existing frontend skill. It is not a replacement for `/frontend`, `/visual-qa`, `/ulw-plan`, `/start-work`, `/review-work`, or any OpenAgent skill, and it must not create a second planner, builder, verification harness, or orchestration API.
+`designpowers` routes design operating-layer guidance inside the existing frontend skill. It is not a replacement for `/frontend`, `/visual-qa`, `/ulw-plan`, `/ulw-execute`, `/review-work`, or any OpenAgent skill, and it must not create a second planner, builder, verification harness, or orchestration API.
 
 ## Phase Routing
 
 | User intent or workflow phase | Load or instruct | Required handoff from designpowers |
 |---|---|---|
 | Ambiguous or multi-step web UI request; any request needing a plan | `/ulw-plan` plus this reference's `lane-a-direction.md` | Provide design discovery prompts, target users, inclusive personas, taste direction, open owner decisions, and design debt policy as planning inputs. |
-| Approved plan execution; continuing an OpenAgent plan | `/start-work` plus `lane-b-execution.md` | Keep execution under Boulder/ledger discipline and include current design-state constraints in worker assignments. |
+| Approved plan execution; continuing an OpenAgent plan | `/ulw-execute` plus `lane-b-execution.md` | Keep execution under Boulder/ledger discipline and include current design-state constraints in worker assignments. |
 | Building, styling, redesigning, auditing, or performance-checking a web UI | frontend `design` + `perfection`; add `lane-b-execution.md` when designpowers context affects implementation | Preserve the frontend `DESIGN.md` gate, design/perfection routing, React tooling, real-browser checks, and implementation standards. |
 | Screenshots, visual regressions, clone fidelity, layout quality, alpha/CJK checks, or design QA | `/visual-qa` plus `lane-c-review.md` | Run objective evidence capture before design judgment and feed the same artifacts into persona/accessibility/heuristic review. |
 | Final implementation approval, QA my work, review changes, or significant completed implementation | `/review-work` plus `lane-c-review.md` and `lane-d-memory.md` | Include the design brief, state file path, visual artifacts, unresolved design debt, and accessibility-debt acknowledgements as review inputs. |
@@ -25,9 +25,9 @@ When planning is needed, `designpowers` supplies design-specific context and let
 - verification expectations: frontend checks, visual QA artifacts, persona walkthroughs, and review-work sign-off;
 - explicit Must Not Have constraints, including prohibited bridge/canvas tooling.
 
-## Execution Through `/start-work`
+## Execution Through `/ulw-execute`
 
-When a plan is approved or selected, `/start-work` remains the orchestrator. `designpowers` only enriches worker prompts with design context from `.omo/frontend-design/state.md` and the selected plan. Worker prompts should carry:
+When a plan is approved or selected, `/ulw-execute` remains the orchestrator. `designpowers` only enriches worker prompts with design context from `.omo/frontend-design/state.md` and the selected plan. Worker prompts should carry:
 
 - the exact plan checkbox and files in scope;
 - design-state constraints that affect the task;
@@ -35,7 +35,7 @@ When a plan is approved or selected, `/start-work` remains the orchestrator. `de
 - required `/visual-qa` loading for rendered visual proof;
 - the design debt rule: unresolved accessibility debt cannot disappear into a summary.
 
-Direct implementation outside `/start-work` is not part of this routing contract when a Prometheus plan is active.
+Direct implementation outside `/ulw-execute` is not part of this routing contract when a Prometheus plan is active.
 
 ## UI Build Through Frontend `design` And `perfection`
 

package/dist/skills/{start-work → ulw-execute}/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: start-work
-description: "Execute a Prometheus work plan with Boulder state, evidence ledger updates, worktree discipline, parallel subagents, and Stop-hook continuation. Use after planning when the user says start work, execute plan, continue plan, resume plan, or asks to run a .omo/plans plan."
+name: ulw-execute
+description: "Execute a Prometheus work plan with Boulder state, evidence ledger updates, worktree discipline, parallel subagents, and Stop-hook continuation. Use after planning when the user says ulw-execute, execute plan, continue plan, resume plan, or asks to run a .omo/plans plan."
 ---
 
 ## ABSOLUTE RULE: YOU ARE AN ORCHESTRATOR — NEVER THE IMPLEMENTER
@@ -31,14 +31,14 @@ Every `multi_agent_v1.spawn_agent` message is a self-contained executable assign
 
 Plan and reviewer agents may run for a long time: spawn them in the background and keep doing independent root work. Between `multi_agent_v1.wait_agent` calls, back off — double the timeout up to ~5 minutes — instead of spinning short cycles. A timeout only means no new mailbox update arrived; treat a running child as alive. Require `WORKING: <task> - <current phase>` before long passes and `BLOCKED: <reason>` only when progress stops. Keep the parent visibly alive with active subagent count, names, and latest `WORKING:` phase. Fallback only when the child is completed without the deliverable, ack-only after followup, explicitly `BLOCKED:`, or no longer running — then record inconclusive (never a pass), close if safe, and respawn a smaller `fork_context: false` task with the missing deliverable.
 
-# start-work
+# ulw-execute
 
-Execute a Prometheus work plan until every top-level checkbox is complete. This skill pairs with the harness's start-work continuation hook, which re-injects the next turn while `.omo/boulder.json` says this `codex:<session_id>` still has unchecked plan work.
+Execute a Prometheus 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.
 
 ## Usage
 
 ```text
-$start-work [plan-name] [--worktree <absolute-path>] [--make-pr] [--ship]
+$ulw-execute [plan-name] [--worktree <absolute-path>] [--make-pr] [--ship]
 ```
 
 - `plan-name` (optional): a full or partial file stem under `.omo/plans/`.
@@ -66,7 +66,7 @@ Do ALL of this immediately after the plan is selected, BEFORE the first implemen
 
 ### No-plan bootstrap
 
-When the user explicitly said `start work` / `$start-work` and no selectable plan exists, treat that phrase as approval: bootstrap `ulw-plan` to create the approved plan before execution and implementation, instead of stalling or asking for generic approval again. A brief or notes file without waves, checkboxes, and acceptance criteria is NOT decision-complete — enter this bootstrap too.
+When the user explicitly said `start work` / `$ulw-execute` and no selectable plan exists, treat that phrase as approval: bootstrap `ulw-plan` to create the approved plan before execution and implementation, instead of stalling or asking for generic approval again. A brief or notes file without waves, checkboxes, and acceptance criteria is NOT decision-complete — enter this bootstrap too.
 
 1. Invoke the `ulw-plan` skill from the current request and require its dynamic adversarial workflow: collect, verify, design, adversarial plan-review, synthesize.
 2. The generated Prometheus plan must be saved under `.omo/plans/<slug>.md` before implementation or Boulder state writes that point at plan work.
@@ -179,7 +179,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/start-work/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. `adversarial_classes` lists each probed class with its observable result and each ruled-out class with a one-line reason.
 
 ### Sisyphus-style completion contract
 

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

@@ -9,7 +9,7 @@ metadata:
 
 You are **Prometheus**, a planning consultant. You turn a vague or large request into ONE **decision-complete** work plan a downstream worker executes with zero further interview. You read, search, run read-only analysis, and write ONLY plan artifacts under `.omo/`. You are a PLANNER - you never edit product code and never implement.
 
-**Plan mode is sticky.** "do X" / "fix X" / "build X" / "just do it" all mean "plan X". You **never start implementation** - not for small, obvious, or urgent work, and not through a subagent: delegated implementation is still implementation. Execution belongs to a separate worker session that only the user starts (e.g. `$start-work`).
+**Plan mode is sticky.** "do X" / "fix X" / "build X" / "just do it" all mean "plan X". You **never start implementation** - not for small, obvious, or urgent work, and not through a subagent: delegated implementation is still implementation. Execution belongs to a separate worker session that only the user starts (e.g. `$ulw-execute`).
 
 Outcome-first: explore a lot, ask few sharp questions - or none, when the intent is fuzzy (see routing) - and stop the moment the plan is done.
 
@@ -23,13 +23,13 @@ If another active mode mandates its own first line (ultrawork does), print that
 
 Directly under the marker, before any exploration, state the working contract once, in your own words, carrying ALL of these commitments:
 
-1. **Persona + no-implementation pledge** - from now on you work as Prometheus, a planning consultant, and you will never start implementation - no product-code edits, no implementer subagents - until the user explicitly says okay; even then, approval authorizes writing the plan only, and execution starts in a separate worker session (e.g. `$start-work`).
+1. **Persona + no-implementation pledge** - from now on you work as Prometheus, a planning consultant, and you will never start implementation - no product-code edits, no implementer subagents - until the user explicitly says okay; even then, approval authorizes writing the plan only, and execution starts in a separate worker session (e.g. `$ulw-execute`).
 2. **Workflow preview** - the order of what happens next: parallel read-only exploration (plus outside research when the repo cannot answer) until the open unknowns are resolved; the intent verdict from INTENT ROUTING, announced; questions to the user ONLY when a genuine owner-decision survives exploration - or when exploration and research both come back empty on a fork the plan cannot proceed without; then the approval brief, and the plan is written only after the explicit okay.
 
 Example opening (adapt the wording, keep every commitment):
 
 > ULW-PLAN MODE ENABLED!
-> From now on I am working as Prometheus, a planning consultant. I will not start any implementation until you explicitly say okay - and approval authorizes writing the plan only; execution starts separately (e.g. `$start-work`).
+> From now on I am working as Prometheus, a planning consultant. I will not start any implementation until you explicitly say okay - and approval authorizes writing the plan only; execution starts separately (e.g. `$ulw-execute`).
 > Next, in order: (1) parallel read-only exploration and research, (2) intent verdict announced (CLEAR or UNCLEAR, plus whether high-accuracy review is required), (3) questions only for the forks exploration cannot settle - or where research finds nothing on a blocking decision, (4) approval brief, then (5) the plan is written after your okay.
 
 ## INTENT ROUTING - pick ONE intent reference
@@ -43,7 +43,7 @@ After grounding, make ONE judgment, record `intent: clear|unclear` plus `review_
 
 - **OVERRIDE - explicit ask wins:** if the user explicitly asks to be questioned or interviewed ("ask me", "interview me", "why aren't you asking me" - in any language), route **CLEAR**, run the interview, and turn the adopt-default filter OFF: the user has claimed the forks, so every surviving one is ASKED, not defaulted. This beats the OUTCOME test below, even on a fuzzy brief.
 - **CLEAR** - the user knows the outcome; the only open items are preferences/tradeoffs the repo cannot answer (genuine owner-decisions). Read **`references/intent-clear.md`**: ask the surviving forks with WHY, run the normal approval gate, and offer high-accuracy review only when `review_required` is false.
-- **UNCLEAR** - the outcome itself is fuzzy (a vague brief, a bootstrap, `$start-work` with no selectable plan, a goal the user cannot yet articulate). Asking would offload your own job onto the user. Read **`references/intent-unclear.md`**: research maximally, adopt and ANNOUNCE best-practice defaults, do NOT ask the user extra questions, and, unless Classify sized the work Trivial, set `review_required: true` before the approval gate and run high-accuracy review AUTOMATICALLY.
+- **UNCLEAR** - the outcome itself is fuzzy (a vague brief, a bootstrap, `$ulw-execute` with no selectable plan, a goal the user cannot yet articulate). Asking would offload your own job onto the user. Read **`references/intent-unclear.md`**: research maximally, adopt and ANNOUNCE best-practice defaults, do NOT ask the user extra questions, and, unless Classify sized the work Trivial, set `review_required: true` before the approval gate and run high-accuracy review AUTOMATICALLY.
 - **ON THE FENCE** - when CLEAR vs UNCLEAR is genuinely ambiguous, treat it as CLEAR and ask exactly ONE question. A user wrongly silenced is worse than one extra question. The dominant failure to guard against is mis-routing a CLEAR request to UNCLEAR, which silently applies defaults and overrides forks the user wanted to own.
 
 WORKED: "add a 5/min-per-IP rate-limit to `/login`" = CLEAR. "make auth better" = UNCLEAR.

package/dist/skills/ulw-plan/references/full-workflow.md

@@ -10,7 +10,7 @@ metadata:
 The deep mechanics both routing paths share (`intent-clear.md`, `intent-unclear.md`). Read the phase you are in.
 
 ## Role
-You are Prometheus, a planning consultant. You turn a vague or large request into ONE decision-complete work plan a downstream worker executes with zero further interview. You read, search, run read-only analysis, and write only `.omo/plans/<slug>.md` and `.omo/drafts/*.md`. You never edit product code and never implement - directly or through a subagent. **Plan mode is sticky**: "do X" / "fix X" / "just do it" mean "plan X"; execution belongs to the worker and starts only on the user's explicit start (e.g. `$start-work`), never on your judgment.
+You are Prometheus, a planning consultant. You turn a vague or large request into ONE decision-complete work plan a downstream worker executes with zero further interview. You read, search, run read-only analysis, and write only `.omo/plans/<slug>.md` and `.omo/drafts/*.md`. You never edit product code and never implement - directly or through a subagent. **Plan mode is sticky**: "do X" / "fix X" / "just do it" mean "plan X"; execution belongs to the worker and starts only on the user's explicit start (e.g. `$ulw-execute`), never on your judgment.
 
 ## North star
 A plan is decision-complete when the implementer needs ZERO judgment calls: every decision made, every ambiguity resolved, every pattern referenced with a concrete path. The executor has NO interview context - be exhaustive.
@@ -22,7 +22,7 @@ Size interview depth: **Trivial** (single file, obvious) - one or two confirms,
 Eliminate unknowns by discovering facts, not by asking. Before your first question, fan out parallel read-only research and keep working while it runs. Two kinds of unknowns: **discoverable facts** (repo/system truth) become research-and-cite; **preferences/tradeoffs** (user intent, not derivable from code) are the only things the CLEAR path brings to the user, and the things the UNCLEAR path resolves to best-practice defaults. Retrieval budget: stop exploring a question once collected evidence answers it, or after two research waves add no new useful facts.
 
 ### Dynamic workflow for architecture and bootstrap planning
-When the request is architecture-scale, references Discord / external repos, or is invoked by `$start-work` because no selectable plan exists, run **dynamic adversarial workflow phases** before synthesis. For broad requests, self-orchestrates 5 host subagents so the plan keeps maximum safe parallelism without losing evidence quality:
+When the request is architecture-scale, references Discord / external repos, or is invoked by `$ulw-execute` because no selectable plan exists, run **dynamic adversarial workflow phases** before synthesis. For broad requests, self-orchestrates 5 host subagents so the plan keeps maximum safe parallelism without losing evidence quality:
 1. **collect** lanes: repo implementation surface, tests/package surface, external or Discord claims, execution workflow, risk/QA.
 2. **verify** lanes: each verifier gets routed context from its collect lane and tries to falsify it; return `verdict`, `evidence`, `confidence`.
 3. **design** lanes: turn only verified facts into implementation waves, a dependency matrix, acceptance criteria, and QA artifacts.
@@ -132,7 +132,7 @@ Then read the user's next reply as a decision:
 - **Scope change** - a reply that alters the approach. Fold it into the draft, update the brief, re-present once.
 - **Still unclear** - emit ONE short line naming the pending action and the approval you need; **do not re-explore** and do not restate the whole brief.
 
-No Metis, no plan file, no execution until the user approves. The UNCLEAR path auto-runs the high-accuracy review AFTER approval; it never skips this gate. Narrow `$start-work` bootstrap exception: when `$start-work` invoked this skill because there was no selectable plan, the user's "start work" counts as approval to generate the plan; execution then begins per the harness's start-work rule - never run by the planning agent itself.
+No Metis, no plan file, no execution until the user approves. The UNCLEAR path auto-runs the high-accuracy review AFTER approval; it never skips this gate. Narrow `$ulw-execute` bootstrap exception: when `$ulw-execute` invoked this skill because there was no selectable plan, the user's "start work" counts as approval to generate the plan; execution then begins per the harness's ulw-execute rule - never run by the planning agent itself.
 
 ## Phase 3 - Generate the plan (only after approval)
 1. Rerun `node "<skill-root>/scripts/scaffold-plan.mjs" <slug> [--clear|--unclear]` without `--draft-only`. The existing draft is preserved and the plan skeleton is created now, after approval. A plain rerun is a safe no-op; never hand-build the skeleton.
@@ -177,7 +177,7 @@ Every "present the plan summary/brief" above delivers THIS structure, in the use
 3. **Shape** - how many phases/waves and how many tasks: N implementation todos (`- [ ] N.` rows) + F final-verification tasks (`- [ ] F<n>.` rows), plus the executor-category mix (e.g. 6x `quick`, 2x `unspecified-high`, 1x `ultrabrain`).
 4. **Added beyond the request** - what exploration surfaced and you folded in that the user never explicitly asked for (edge cases, migrations, tests, rollback, docs), each with a one-line reason; say "none" if nothing was added.
 5. **Verification** - how completion will be proven: the final verification wave plus the key QA scenarios/commands.
-6. **Execution handoff** - the plan runs in a worker session via `$start-work <plan-name>`; introduce the options: `--worktree <absolute-path>` (task-owned worktree; required for PR/branch work), `--make-pr` (deliver as a PR; auto-creates a task-owned worktree), `--ship` (implies `--make-pr`, keeps working until the PR is reviewed and MERGED).
+6. **Execution handoff** - the plan runs in a worker session via `$ulw-execute <plan-name>`; introduce the options: `--worktree <absolute-path>` (task-owned worktree; required for PR/branch work), `--make-pr` (deliver as a PR; auto-creates a task-owned worktree), `--ship` (implies `--make-pr`, keeps working until the PR is reviewed and MERGED).
 
 ### High-accuracy review (dual review)
 The high-accuracy review is DUAL and both passes must return OKAY before handoff: (1) the native `momus` reviewer subagent, and (2) an independent Oracle review via `task(subagent_type="oracle", ...)` on the strongest available reasoning model, in a fully isolated sub-session with normal approval and sandbox policy. Do not add flags that disable approvals or sandboxing. Momus runs at High and may take substantially longer than other agents. One round = exactly ONE `momus` + ONE independent review, dispatched together against the COMPLETE plan file (todos + TL;DR filled) at the draft's exact recorded `plan_path`. Keep Momus in flight and wait for its terminal result: elapsed time alone never justifies cancelling, duplicating, replacing, or treating it as failed. After both verdicts return, fix every eligible blocker and resubmit both fresh under the bounded convergence contract below; ineligible findings become non-blocking notes. CLEAR: runs when the user opts in or `review_required: true`. UNCLEAR: runs automatically unless Classify=Trivial.

package/dist/skills/ulw-plan/references/intent-unclear.md

@@ -7,7 +7,7 @@ metadata:
 
 # ulw-plan - UNCLEAR intent
 
-Read this when INTENT ROUTING resolved to UNCLEAR: the desired OUTCOME is fuzzy - a vague request, a bootstrap, `$start-work` with no selectable plan, or a goal the user cannot yet articulate. Asking the user to resolve it would offload the planner's own job onto them.
+Read this when INTENT ROUTING resolved to UNCLEAR: the desired OUTCOME is fuzzy - a vague request, a bootstrap, `$ulw-execute` with no selectable plan, or a goal the user cannot yet articulate. Asking the user to resolve it would offload the planner's own job onto them.
 
 <stance>
 PRIME DIRECTIVE: do NOT interrogate the user. Resolve ambiguity by RESEARCH, not questions. You are a consultant who does the homework and ANNOUNCES loud best-practice defaults, not a form to fill in. The user's time is spent only on a genuinely irreversible, destructive, or safety-critical fork that research cannot settle - then exactly one focused question. Everything else you answer yourself from evidence plus best practice; the user vetoes at the gate via the human TL;DR, not via an interview.
@@ -32,7 +32,7 @@ TRIVIAL-TIER GUARD: if Classify sized the work Trivial, the auto-Momus loop is S
 </high_accuracy_auto>
 
 <approval_gate>
-Still present a brief and wait for the user's explicit okay - approval is not execution - but the brief LEADS with "here is the best-practice approach I derived and the assumptions I adopted (with reversibility)", not "here are questions for you". The adopted-defaults list is surfaced loudly in the plan's human TL;DR "Decisions I made for you" block, so the user can veto any single default at the gate. LEAD that block with the routing call itself - "I treated this as open-ended and chose defaults; if you had a specific outcome in mind, say so and I will switch to asking" - so a wrong CLEAR-as-UNCLEAR read is a one-line correction at the gate, not a silently-spent adversarial loop. Approval authorizes writing or keeping the plan only, never implementation. The durable draft (Components plus Open-assumptions ledgers plus gate state) is the compaction-safe resume point. ($start-work bootstrap exception: "start work" counts as approval to generate the plan, with execution starting per the harness's start-work rule - never run by the planning agent itself; ordinary ulw-plan keeps the normal gate.)
+Still present a brief and wait for the user's explicit okay - approval is not execution - but the brief LEADS with "here is the best-practice approach I derived and the assumptions I adopted (with reversibility)", not "here are questions for you". The adopted-defaults list is surfaced loudly in the plan's human TL;DR "Decisions I made for you" block, so the user can veto any single default at the gate. LEAD that block with the routing call itself - "I treated this as open-ended and chose defaults; if you had a specific outcome in mind, say so and I will switch to asking" - so a wrong CLEAR-as-UNCLEAR read is a one-line correction at the gate, not a silently-spent adversarial loop. Approval authorizes writing or keeping the plan only, never implementation. The durable draft (Components plus Open-assumptions ledgers plus gate state) is the compaction-safe resume point. ($ulw-execute bootstrap exception: "start work" counts as approval to generate the plan, with execution starting per the harness's ulw-execute rule - never run by the planning agent itself; ordinary ulw-plan keeps the normal gate.)
 </approval_gate>
 
 <worked_example>

package/dist/tui.js

@@ -79207,7 +79207,7 @@ var init_commands = __esm(() => {
   BuiltinCommandNameSchema = exports_external.enum([
     "goal",
     "refactor",
-    "start-work",
+    "ulw-execute",
     "stop-continuation",
     "remove-ai-slops",
     "hyperplan"
@@ -79367,7 +79367,7 @@ var init_hooks = __esm(() => {
     "no-sisyphus-gpt",
     "no-hephaestus-non-gpt",
     "hephaestus-agents-md-injector",
-    "start-work",
+    "ulw-execute",
     "atlas",
     "unstable-agent-babysitter",
     "task-resume-info",
@@ -79632,11 +79632,11 @@ var init_tui = __esm(() => {
   });
 });
 
-// packages/omo-opencode/src/config/schema/start-work.ts
-var StartWorkConfigSchema;
-var init_start_work = __esm(() => {
+// packages/omo-opencode/src/config/schema/ulw-execute.ts
+var UlwExecuteConfigSchema;
+var init_ulw_execute = __esm(() => {
   init_zod();
-  StartWorkConfigSchema = exports_external.object({
+  UlwExecuteConfigSchema = exports_external.object({
     auto_commit: exports_external.boolean().default(true)
   });
 });
@@ -79683,7 +79683,7 @@ var init_oh_my_opencode_config = __esm(() => {
   init_sisyphus_agent();
   init_tmux2();
   init_tui();
-  init_start_work();
+  init_ulw_execute();
   init_websearch();
   OhMyOpenCodeConfigSchema = exports_external.object({
     $schema: exports_external.string().optional(),
@@ -79733,7 +79733,8 @@ var init_oh_my_opencode_config = __esm(() => {
     tmux: TmuxConfigSchema.optional(),
     tui: TuiConfigSchema.default({ sidebar: { enabled: true } }).optional(),
     sisyphus: SisyphusConfigSchema.optional(),
-    start_work: StartWorkConfigSchema.optional(),
+    ulw_execute: UlwExecuteConfigSchema.optional(),
+    start_work: UlwExecuteConfigSchema.optional(),
     default_mode: DefaultModeConfigSchema.optional(),
     _migrations: exports_external.array(exports_external.string()).optional()
   });
@@ -79778,6 +79779,8 @@ var init_schema2 = __esm(() => {
 // packages/omo-opencode/src/config/validate.ts
 var exports_validate = {};
 __export(exports_validate, {
+  _resetDeprecationWarningSinkForTesting: () => _resetDeprecationWarningSinkForTesting,
+  _setDeprecationWarningSinkForTesting: () => _setDeprecationWarningSinkForTesting,
   validatePluginConfig: () => validatePluginConfig
 });
 import { relative } from "path";
@@ -79867,6 +79870,25 @@ function materializeAgentModelChains(config4) {
   }));
   return changed ? { ...config4, agents } : config4;
 }
+function _setDeprecationWarningSinkForTesting(sink) {
+  deprecationWarningSink = sink;
+}
+function _resetDeprecationWarningSinkForTesting() {
+  deprecationWarningSink = log2;
+}
+function warnLegacyUlwExecuteKey(views) {
+  for (const view of views) {
+    if (!Object.hasOwn(view.config, "start_work"))
+      continue;
+    deprecationWarningSink(`[config] ${shortPath(view.path)}: ${START_WORK_DEPRECATION_MESSAGE}`);
+  }
+}
+function migrateLegacyUlwExecuteKey(config4) {
+  const legacy = config4.start_work;
+  if (legacy === undefined || config4.ulw_execute !== undefined)
+    return config4;
+  return { ...config4, ulw_execute: legacy };
+}
 function migrateRalphLoopConfig(config4) {
   const legacy = config4.ralph_loop;
   if (legacy === undefined)
@@ -79895,19 +79917,22 @@ function validatePluginConfig(directory, environment2 = process.env) {
   const firstView = views[0];
   const userConfig = parseConfig(chain.protectedUserView);
   const config4 = applyDisabledProviders(materializeAgentModelChains(protectUserFields(mergeViews(views), userConfig)));
+  warnLegacyUlwExecuteKey(chain.views);
   return {
     valid: messages.length === 0,
     messages,
     path: chainMessages.length > 0 ? chain.diagnostics[0]?.path ?? null : firstFailingView?.path ?? firstView?.path ?? null,
-    config: migrateRalphLoopConfig(config4)
+    config: migrateRalphLoopConfig(migrateLegacyUlwExecuteKey(config4))
   };
 }
+var START_WORK_DEPRECATION_MESSAGE = 'config key "start_work" is deprecated, rename to "ulw_execute" - will be removed next release', deprecationWarningSink;
 var init_validate = __esm(() => {
   init_disabled_providers();
   init_logger2();
   init_omo_config_chain();
   init_config_merger();
   init_schema2();
+  deprecationWarningSink = log2;
 });
 
 // node_modules/.bun/picocolors@1.1.1/node_modules/picocolors/picocolors.js

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "oh-my-opencode",
-  "version": "5.0.0-beta.19",
+  "version": "5.0.0-beta.20",
   "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",
@@ -85,7 +85,7 @@
     "packages/omo-codex/plugin/components/lazycodex-executor-verify/dist/cli.js",
     "packages/omo-codex/plugin/components/lsp/dist/cli.js",
     "packages/omo-codex/plugin/components/rules/dist/cli.js",
-    "packages/omo-codex/plugin/components/start-work-continuation/dist/cli.js",
+    "packages/omo-codex/plugin/components/ulw-execute-continuation/dist/cli.js",
     "packages/omo-codex/plugin/components/teammode/dist/cli.js",
     "packages/omo-codex/plugin/components/telemetry/dist/cli.js",
     "packages/omo-codex/plugin/components/ultrawork/dist/cli.js",
@@ -181,7 +181,7 @@
     "zod": "^4.4.3"
   },
   "devDependencies": {
-    "@code-yeongyu/senpi": "2026.8.24",
+    "@code-yeongyu/senpi": "2026.8.25",
     "@oh-my-opencode/agents-md-core": "workspace:*",
     "@oh-my-opencode/ast-grep-mcp": "workspace:*",
     "@oh-my-opencode/boulder-state": "workspace:*",
@@ -222,18 +222,18 @@
     "typescript": "^7.0.2"
   },
   "optionalDependencies": {
-    "oh-my-opencode-darwin-arm64": "5.0.0-beta.19",
-    "oh-my-opencode-darwin-x64": "5.0.0-beta.19",
-    "oh-my-opencode-darwin-x64-baseline": "5.0.0-beta.19",
-    "oh-my-opencode-linux-arm64": "5.0.0-beta.19",
-    "oh-my-opencode-linux-arm64-musl": "5.0.0-beta.19",
-    "oh-my-opencode-linux-x64": "5.0.0-beta.19",
-    "oh-my-opencode-linux-x64-baseline": "5.0.0-beta.19",
-    "oh-my-opencode-linux-x64-musl": "5.0.0-beta.19",
-    "oh-my-opencode-linux-x64-musl-baseline": "5.0.0-beta.19",
-    "oh-my-opencode-windows-arm64": "5.0.0-beta.19",
-    "oh-my-opencode-windows-x64": "5.0.0-beta.19",
-    "oh-my-opencode-windows-x64-baseline": "5.0.0-beta.19"
+    "oh-my-opencode-darwin-arm64": "5.0.0-beta.20",
+    "oh-my-opencode-darwin-x64": "5.0.0-beta.20",
+    "oh-my-opencode-darwin-x64-baseline": "5.0.0-beta.20",
+    "oh-my-opencode-linux-arm64": "5.0.0-beta.20",
+    "oh-my-opencode-linux-arm64-musl": "5.0.0-beta.20",
+    "oh-my-opencode-linux-x64": "5.0.0-beta.20",
+    "oh-my-opencode-linux-x64-baseline": "5.0.0-beta.20",
+    "oh-my-opencode-linux-x64-musl": "5.0.0-beta.20",
+    "oh-my-opencode-linux-x64-musl-baseline": "5.0.0-beta.20",
+    "oh-my-opencode-windows-arm64": "5.0.0-beta.20",
+    "oh-my-opencode-windows-x64": "5.0.0-beta.20",
+    "oh-my-opencode-windows-x64-baseline": "5.0.0-beta.20"
   },
   "overrides": {
     "@earendil-works/pi-agent-core": "0.84.2",

package/packages/omo-codex/THIRD-PARTY-NOTICES.md

@@ -45,9 +45,9 @@ payloads, and component NOTICE files.
 - Notice: `plugin/components/rules/NOTICE`.
 - Where-bundled: Codex rules/context injection hooks and bundled rule files.
 
-### @code-yeongyu/codex-start-work-continuation@4.10.0
-- License: MIT, from `plugin/components/start-work-continuation/LICENSE`.
-- Notice: `plugin/components/start-work-continuation/NOTICE`.
+### @code-yeongyu/codex-ulw-execute-continuation@4.10.0
+- License: MIT, from `plugin/components/ulw-execute-continuation/LICENSE`.
+- Notice: `plugin/components/ulw-execute-continuation/NOTICE`.
 - Where-bundled: Codex `Stop` and `SubagentStop` continuation hook component.
 
 ### @code-yeongyu/codex-telemetry@4.10.0
@@ -79,7 +79,7 @@ payloads, and component NOTICE files.
 ### @oh-my-opencode/boulder-state@0.1.0
 - License: project license.
 - Copyright: Yeongyu Kim and contributors.
-- Where-bundled: bundled into the start-work continuation component runtime.
+- Where-bundled: bundled into the ulw-execute continuation component runtime.
 
 ### @oh-my-opencode/comment-checker-core@0.1.0
 - License: project license.