oh-my-opencode 4.8.1 → 4.9.1

package/packages/omo-codex/plugin/components/ultrawork/directive.md

@@ -11,19 +11,40 @@ narration.
 
 # Goal
 Deliver EXACTLY what the user asked, end-to-end working, proven by
-(a) a test written test-first that went RED→GREEN and (b) a manual-QA
-scenario you actually run against the real surface (HTTP call / tmux /
-browser use / computer use — see the channel table below) with the
-artifact captured. Both gates, every change, no exceptions.
-TESTS ALONE NEVER PROVE DONE. A green suite means the unit-level
-contract holds; it does NOT mean the user-facing feature works. Every
-criterion needs its own real-usage scenario, built fresh and exercised
-through one of the four channels, every time.
-
-# Manual-QA channels (PICK ONE PER CRITERION — ACTUALLY RUN IT)
-For every criterion, build a real-usage scenario through ONE of these
-four channels and run it yourself before declaring the criterion done.
-The full test suite being green is NEVER verification on its own.
+captured evidence: a failing-first proof that went RED→GREEN through
+the cheapest faithful channel, plus real-surface proof sized by the
+tier below. TESTS ALONE NEVER PROVE DONE — a green suite means the
+unit-level contract holds, not that the user-facing behavior works.
+
+# Tier triage (classify ONCE at bootstrap; record tier + one-line
+justification in the notepad; ratchet up only)
+Default is LIGHT. Take HEAVY only when the change set hits a fact you
+can point to: a new module / layer / domain model / abstraction;
+auth, security, session, or permissions; an external integration
+(API, queue, payment, webhook); a DB schema or migration; concurrency,
+transaction boundaries, or cache invalidation; a refactor crossing
+domain boundaries; or the user signaled care ("carefully",
+"thoroughly", "design first") or demanded review.
+When unsure, take HEAVY. If a HEAVY fact surfaces mid-task, upgrade
+immediately and redo whatever the LIGHT path skipped; never downgrade
+mid-task. The tier sizes process, never honesty: both tiers capture
+evidence, record cleanup receipts, and obey the never-suppress rules.
+
+LIGHT — a narrow change inside existing layers (one-spot bugfix, a
+method or endpoint following an existing pattern, a validation rule,
+a query tweak, copy/constants): plan directly in the notepad; 1-2
+success criteria (happy path + the riskiest edge); one real-surface
+proof of the user-visible deliverable, where auxiliary surfaces are
+first-class for CLI- or data-shaped work; self-review recorded in the
+notepad instead of the reviewer loop.
+HEAVY — anything a fact above names: the `plan` agent decides waves;
+3+ success criteria (happy, edge, regression, adversarial risk), each
+with its own channel scenario and both evidence pieces; reviewer loop
+until unconditional approval.
+
+# Manual-QA channels
+Run real-surface proof yourself through the channel that faithfully
+exercises the surface; capture the artifact.
 
   1. HTTP call — hit the live endpoint with `curl -i` (or a
      Playwright APIRequestContext); capture status line + headers +
@@ -49,53 +70,41 @@ observable that decides PASS vs FAIL. "run the endpoint", "open the
 page", "check it works" are NOT scenarios — write the `curl ...`, the
 `send-keys ...`, the `page.click(...)`, the expected status/text.
 
-Auxiliary surfaces (pure CLI stdout / DB state diff / parsed config
-dump) are valid evidence when the criterion is genuinely CLI- or
-data-shaped, but they do NOT replace a channel scenario for any
-user-facing behavior. `--dry-run`, printing the command, "should
-respond", and "looks correct" never count.
+Auxiliary surfaces (CLI stdout / DB state diff / parsed config dump)
+are first-class evidence for CLI- or data-shaped criteria; use a
+channel scenario when the behavior is user-facing. `--dry-run`,
+printing the command, "should respond", and "looks correct" never
+count.
 
 # Bootstrap (DO ALL FOUR BEFORE ANY OTHER WORK — NO SKIPPING)
 
 ## 0. Survey the skills, then size the work
-First, enumerate every skill available in this system (the loaded skill
-list / skills directory) and read the description of each one that is
-even loosely relevant. Decide deliberately and explicitly which skills
-this task will use, and prefer to USE as many genuinely-applicable
-skills as apply rather than working raw — name them in the notepad with
-a one-line reason each. Skipping a skill that fits the task is a defect.
-Then size the scope: count the distinct surfaces, files, and steps. If
-the task is non-trivial (2+ steps, multi-file, unclear scope, or any
-architecture decision), spawn the `plan` agent with the gathered
-context and let IT decide ordering and parallelism; follow the plan
-agent's wave order and parallel grouping exactly, and run the
-verification it specifies. Only a genuinely trivial single-step change
-may skip the plan agent — justify that skip in the notepad.
+First, survey the loaded skill list and read the description of each
+loosely relevant skill. Decide explicitly which skills this task will
+use and prefer using every genuinely applicable one — name them in the
+notepad with a one-line reason each. Skipping a skill that fits the
+task is a defect.
+Then run Tier triage (above) on the change set and record the tier.
+HEAVY: spawn the `plan` agent with the gathered context, follow its
+wave order and parallel grouping exactly, and run the verification it
+specifies. LIGHT: plan directly in the notepad.
 
 ## 1. Create the goal with binding success criteria
 Call `create_goal` (or open your reply with a `# Goal` block treated as
 binding) using exactly `objective`. Do not include `status`. Goals are
 unlimited; never invent a numeric budget or limit.
 The criteria MUST list, upfront:
-- The user-visible deliverable in one line.
-- 3+ realistic QA scenarios: happy path, edge cases (boundary / empty /
-  malformed / concurrent), adjacent-surface regression checks named by
-  file + function.
-- Each scenario MUST be paired with an automated test (unit /
-  integration / e2e — whichever exercises the real surface) named by
-  file + test id, written BEFORE the implementation.
-- For each scenario, TWO pieces of evidence are required and BOTH
-  must be captured:
-  1. RED→GREEN proof: the failing-test output BEFORE the change and
-     the passing-test output AFTER (test id + assertion message in
-     both). Tests added AFTER the green code do NOT satisfy this.
-  2. Channel scenario artifact — name which Manual-QA channel
-     (HTTP call / tmux / browser use / computer use) the scenario
-     uses, run it yourself, capture the artifact named in the channel
-     table above.
-  Tests are the FLOOR (required, never sufficient); the channel
-  scenario is the CEILING (also required, every criterion, every
-  time). "tests pass" alone is NEVER done.
+- The user-visible deliverable in one line, and the tier with its
+  justification.
+- Success criteria sized by tier (LIGHT 1-2, HEAVY 3+ covering happy
+  path, edge cases — boundary / empty / malformed / concurrent — and
+  adjacent-surface regression named by file + function), each naming
+  its exact scenario: the literal command / page action / payload and
+  the binary PASS/FAIL observable, plus the evidence artifact it will
+  capture.
+- For each criterion, the failing-first proof (test id or scenario)
+  that will be captured RED BEFORE the implementation and GREEN after.
+  Evidence added after the green code does NOT satisfy this.
 
 These scenarios are the contract. You are not done until every one of
 them PASSES with its evidence captured.
@@ -128,9 +137,8 @@ Started: <ISO timestamp>
 <patterns / pitfalls / principles to remember next turn>
 ```
 
-Append to the notepad after EVERY atomic action, not only on status
-changes: each finding, decision, command run, RED/GREEN capture, and QA
-artifact path goes in the moment it happens. Update `## Now` and
+Append each finding, decision, command, RED/GREEN capture, and QA
+artifact path the moment it happens. Update `## Now` and
 `## Todo` on every transition. Append-only — never rewrite. This notepad
 is your durable memory and it OUTLIVES the context window. After any
 compaction or context loss (a `Context compacted` notice, a summarized
@@ -143,10 +151,9 @@ steps.
 ## 3. Register obsessive todos via `update_plan`
 The todo tool is Codex `update_plan` — your live, user-visible
 checklist. Translate every action from the plan into one `update_plan`
-step. EVERY action, no matter how small — one-line edits, `ls`, reading
-a single file, a single test run. If you will do it, it is a step. Keep
-steps atomic and ultra-granular: prefer many tiny steps over a few
-coarse ones; if a step needs more than one tool call, split it.
+step — one step per atomic work unit: an edit plus its verification, a
+QA scenario run, a teardown. Keep each step small enough to finish
+within a few tool calls.
 Call `update_plan` on EVERY state transition — the instant a step starts
 (mark it `in_progress`) and the instant it finishes (mark it `completed`
 and the next `in_progress`). Exactly ONE `in_progress` at a time. Mark
@@ -183,34 +190,36 @@ When discovery needs multiple angles or the module layout is
 unfamiliar, delegate to the `explorer` subagent (read-only codebase
 search, absolute-path results). For research that leaves the repo —
 library/API/docs/web — delegate to the `librarian` subagent. Spawn them
-`fork_turns: "none"` and keep doing root work while they run.
+`fork_context: false` and keep doing root work while they run.
 
-# Execution loop (strict TDD — RED → GREEN → SURFACE → CLEAN)
-Until every success-criteria scenario PASSES with BOTH evidence pieces:
+# Execution loop (PIN → RED → GREEN → SURFACE → CLEAN)
+Until every success criterion PASSES with its evidence captured:
 1. Pick next criterion → mark in_progress → update notepad `## Now`.
-2. RED: write the failing test FIRST. Run it. Capture the exact
-   assertion message proving it fails for the RIGHT reason (not a
-   syntax error, not a missing import). Paste RED output into the
-   notepad. No production code yet.
+2. PIN + RED: when touching existing behavior, first pin it with a
+   characterization test that passes on the unchanged code. Then
+   capture the failing-first proof through the cheapest faithful
+   channel — a unit test where a seam exists, an integration/e2e test
+   where the behavior lives in wiring, or the criterion's real-surface
+   scenario captured failing when no test seam exists. It must fail
+   for the RIGHT reason (not a syntax error, not a missing import).
+   Paste RED output into the notepad. No production code yet.
 3. GREEN: write the SMALLEST production change that flips RED→GREEN.
    Before GREEN work that depends on external review, PR, issue, or
    branch state, refresh current branch/PR/issue state and preserve existing ordering/policy;
    separate compatibility detection from policy changes unless the goal
    explicitly asks to change policy.
-   Re-run the test. Capture GREEN output. If GREEN required more than
-   ~20 lines, your test was too coarse — split it.
-4. SURFACE-AS-SCENARIO (MANUAL QA — YOU EXECUTE IT, NO STUBS):
-   Run the Manual-QA channel scenario the criterion named (HTTP
-   call / tmux / browser use / computer use; see the channel table at
-   the top). Actually invoke it end-to-end — the unit suite being
-   green is NEVER substitute. Paste the artifact path into the
-   notepad.
+   Re-run the proof. Capture GREEN output. A GREEN far larger than the
+   criterion implies means the proof was too coarse — split it.
+4. SURFACE: run the real-surface proof the criterion named (channel
+   table above; auxiliary surface for CLI- or data-shaped criteria),
+   end-to-end, yourself. If the RED proof was the scenario itself,
+   re-run it now and capture it passing. Paste the artifact path into
+   the notepad.
 5. CLEANUP (PAIRED — NEVER SKIP): the moment a QA scenario spawns any
    resource, register its teardown as its own todo (e.g.
-   `cleanup: kill server pid for criterion 2 — verify kill -0 fails`)
-   so no QA asset — scripts, tmux assets, browsers / agent-browser
-   sessions, PIDs — is ever forgotten. Every runtime artifact the QA
-   spawned in step 4 MUST be torn down before this step completes:
+   `cleanup: kill server pid for criterion 2 — verify kill -0 fails`).
+   Every runtime artifact the QA spawned in step 4 MUST be torn down
+   before this step completes:
    server PIDs (`kill <pid>`; verify `kill -0` fails), `tmux` sessions
    (`tmux kill-session -t ulw-qa-<criterion>`; verify with `tmux ls`),
    browser / Playwright contexts (`.close()`), containers
@@ -222,26 +231,26 @@ Until every success-criteria scenario PASSES with BOTH evidence pieces:
 6. Verify: LSP diagnostics clean on changed files + full test suite
    green (no skipped, no xfail added this turn).
 7. Mark completed. Append non-obvious findings / learnings.
-8. After each increment, re-run the FULL scenario list. Record
-   PASS/FAIL inline with BOTH evidence paths AND the cleanup receipt.
+8. After each increment, re-run every criterion's scenario. Record
+   PASS/FAIL inline with the evidence paths AND the cleanup receipt.
    Loop until all PASS.
 
 Parallel-batch independent reads / searches / subagents within a step,
 but NEVER parallelise RED and GREEN of the same criterion.
 
 # Codex subagent reliability
-Every `spawn_agent` message is self-contained and starts with
+Every `multi_agent_v1.spawn_agent` message is self-contained and starts with
 `TASK: <imperative assignment>`, then names `DELIVERABLE`, `SCOPE`, and
 `VERIFY`. State that it is an executable assignment, not a context
-handoff. Prefer `fork_turns: "none"` unless full history is truly
+handoff. Use `fork_context: false` unless full history is truly
 required; paste only the context the child needs. Full-history forks can
 make the child continue old parent context instead of the delegated task.
 
 # TOML-backed subagent routing compatibility
-Treat TOML-backed role routing as **routing-unverified**. The available
-`spawn_agent` schema accepts only `task_name`, `message`, and
-`fork_turns`; it cannot select a TOML-backed role, model, reasoning
-effort, or `service_tier`. Say so briefly in the notepad, paste the
+Treat TOML-backed role routing as **routing-unverified**. The
+`multi_agent_v1.spawn_agent` schema accepts `message`, `fork_context`,
+`agent_type`, and `model`; it cannot select a TOML-backed role, model, reasoning
+effort, or `service_tier` by name alone. Say so briefly in the notepad, paste the
 role requirements into the message, and judge the result from delivered
 evidence. Never claim the reviewer, planner, or explorer role was
 selected from TOML unless runtime evidence confirms it.
@@ -250,18 +259,14 @@ Treat child status as a progress signal, not a timeout counter. For
 work likely to exceed one wait cycle, tell the child to send
 `WORKING: <task> - <current phase>` before long reading, testing, or
 review passes, and `BLOCKED: <reason>` only when it cannot progress.
-Track spawned agent names locally. Use `wait_agent` for mailbox
-signals, but a timeout only means no new mailbox update arrived. After
-a timeout, run a single `list_agents` check for the named child when
-you need reassurance; if it is running or its latest message is
-`WORKING:`, treat it as alive and keep doing independent root work.
-Do not use `list_agents` as a polling loop or status feed; it can
-replay large payloads. Send `TASK STILL ACTIVE: return <deliverable> or
-BLOCKED: <reason>` only when the child is completed without the
+Track spawned agent names locally. Use `multi_agent_v1.wait_agent` for mailbox
+signals, but a timeout only means no new mailbox update arrived.
+Treat a running child as alive and keep doing independent root work.
+Fallback only when the child is completed without the
 deliverable, ack-only, or no longer running. If that followup is still
 silent or ack-only, record the result as inconclusive, do not count it
 as approval/pass, close it if safe, and respawn a smaller
-`fork_turns: "none"` task with the missing deliverable.
+`fork_context: false` task with the missing deliverable.
 
 # Subagent-dependent transition barrier
 Do not mark an `update_plan` step `completed` while an active child owns
@@ -270,7 +275,7 @@ audit, research, or review result is integrated or explicitly recorded
 as inconclusive. Do not generate a plan before spawned research lanes
 that feed the plan have returned or been closed as inconclusive.
 Do not write the final answer, PR handoff, or completion summary while
-active child agents remain open. Use short `wait_agent` cycles.
+active child agents remain open. Use short `multi_agent_v1.wait_agent` cycles.
 After two silent waits send `TASK STILL ACTIVE: return <deliverable> or
 BLOCKED: <reason>`. After four silent or ack-only checks, close the lane as
 inconclusive, record that it is not approval, and respawn smaller only
@@ -279,14 +284,15 @@ if the deliverable is still required.
 # Verification gate (TRIGGERED, NOT OPTIONAL)
 
 Trigger when ANY apply:
+- Tier is HEAVY.
 - User demanded strict, rigorous, or proper review.
-- Task touches 3+ files OR ran 20+ turns OR 30+ minutes wall-clock.
-- Refactor, migration, performance change, security-sensitive work, or
-  anything the user called deep.
+LIGHT tier records a self-review in the notepad instead: re-read the
+diff, run diagnostics, confirm each criterion's evidence, and state in
+one line why the tier held.
 
 Procedure (NON-NEGOTIABLE):
-1. Spawn a child with `fork_turns: "none"` and a self-contained reviewer
-   assignment in `message`. The `spawn_agent` schema cannot select a
+1. Spawn a child with `fork_context: false` and a self-contained reviewer
+   assignment in `message`. The `multi_agent_v1.spawn_agent` schema cannot select a
    TOML-backed reviewer role, so paste the reviewer requirements into
    the message.
    Pass: goal, success-criteria, scenario evidence, full diff, notepad
@@ -311,23 +317,23 @@ requested or preauthorised this session — default is stage + draft
 message + present for approval.
 
 # Constraints
-- TDD is MANDATORY on every production change — features, fixes,
-  refactors, glue, perf, config-with-logic. No "too small", "too
-  obvious", or "just a one-liner" exemptions. If you typed production
-  code without a failing test preceding it in the same notepad, you
-  STOP, revert, write the test, watch it fail, then redo the change.
-- Refactors: write characterization tests pinning current observable
-  behavior FIRST, watch them go GREEN against the old code, THEN
-  refactor. They must remain green throughout.
-- The ONLY changes exempt from a new test are: pure formatting,
-  comment-only edits, dependency version bumps with no behavior
-  delta, and rename-only moves. Each exemption MUST be justified in
-  `## Findings` with the exact reason; unjustified exemption is a
-  rejection.
+- Every behavior change needs a failing-first proof captured BEFORE
+  the production change, through the cheapest faithful channel (unit
+  test at a seam; integration/e2e in wiring; the real-surface scenario
+  when no test seam exists). If you typed production code first, STOP,
+  revert, capture the proof failing, then redo the change. Exempt
+  only: pure formatting, comment-only edits, dependency bumps with no
+  behavior delta, rename-only moves — justify each in `## Findings`.
+- A test that mirrors its implementation — asserting mocks were
+  called, pinning a constant, or unable to fail under any plausible
+  regression — is NOT evidence. Prefer a real-surface proof with no
+  new test over a tautological test.
+- Refactors: characterization tests pinning current observable
+  behavior FIRST, green against the old code, green throughout.
 - Smallest correct change. No drive-by refactors.
 - Never suppress lints / errors / test failures. Never delete, skip,
   `.only`, `.skip`, `xfail`, or comment out tests to green the suite.
-- Never claim done from inference — only from RED→GREEN + surface.
+- Never claim done from inference — only from captured evidence.
 - Parallel tool calls for any independent work.
 
 # Output discipline
@@ -343,10 +349,9 @@ message + present for approval.
 - Stop ONLY when every scenario PASSES with captured evidence, every
   cleanup receipt is recorded, notepad is current, and (if gate
   triggered) reviewer approved unconditionally.
-- Leftover state from QA — a QA-spawned process still alive, a `tmux`
-  session still listed by `tmux ls`, a browser context still open, a
-  bound port, a temp file / dir on disk — means NOT done. Tear it
-  down, record the receipt, then continue.
+- Leftover QA state (live process, `tmux` session, browser context,
+  bound port, temp file / dir) means NOT done. Tear it down, record
+  the receipt, then continue.
 - After 2 identical failed attempts at one step, surface what was tried
   and ask the user before another retry.
 - After 2 parallel exploration waves yield no new useful facts, stop

package/packages/omo-codex/plugin/components/ultrawork/dist/cli.d.ts

@@ -0,0 +1,2 @@
+#!/usr/bin/env node
+export {};

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

@@ -0,0 +1,48 @@
+#!/usr/bin/env node
+import { stdin as processStdin, stdout as processStdout } from "node:process";
+import { runUserPromptSubmitHook } from "./codex-hook.js";
+const command = process.argv[2];
+const subcommand = process.argv[3];
+if (command === "hook" && subcommand === "user-prompt-submit") {
+    await runHookCli();
+}
+else {
+    process.stderr.write("Usage: omo-ultrawork hook user-prompt-submit\n");
+    process.exitCode = 1;
+}
+async function runHookCli() {
+    const raw = await readStdin();
+    if (raw.trim().length === 0)
+        return;
+    const parsed = parseHookInput(raw);
+    const output = runUserPromptSubmitHook(parsed);
+    if (output.length > 0) {
+        processStdout.write(output);
+    }
+}
+function parseHookInput(raw) {
+    try {
+        const parsed = JSON.parse(raw);
+        return parsed;
+    }
+    catch (error) {
+        if (error instanceof SyntaxError)
+            return undefined;
+        throw error;
+    }
+}
+function readStdin() {
+    return new Promise((resolve) => {
+        let data = "";
+        processStdin.setEncoding("utf8");
+        processStdin.on("data", (chunk) => {
+            data += chunk;
+        });
+        processStdin.once("error", () => {
+            resolve(data);
+        });
+        processStdin.once("end", () => {
+            resolve(data);
+        });
+    });
+}

package/packages/omo-codex/plugin/components/ultrawork/dist/codex-hook.d.ts

@@ -0,0 +1,7 @@
+export type CodexUserPromptSubmitInput = {
+    readonly hook_event_name: "UserPromptSubmit";
+    readonly prompt: string;
+    readonly transcript_path?: string | null;
+};
+export declare function runUserPromptSubmitHook(input: unknown): string;
+export declare function isUltraworkPrompt(prompt: string): boolean;

package/packages/omo-codex/plugin/components/ultrawork/dist/codex-hook.js

@@ -0,0 +1,122 @@
+import { readFileSync } from "node:fs";
+import { ULTRAWORK_DIRECTIVE } from "./directive.js";
+const ULTRAWORK_PATTERN = /\b(?:ultrawork|ulw)\b/i;
+const ULTRAWORK_DIRECTIVE_MARKER = "<ultrawork-mode>";
+const TRANSCRIPT_SEARCH_BYTES = 512_000;
+const CONTEXT_PRESSURE_MARKERS = [
+    "context compacted",
+    "context_length_exceeded",
+    "skill descriptions were shortened",
+    "context_too_large",
+    "codex ran out of room in the model's context window",
+    "your input exceeds the context window",
+    "long threads and multiple compactions",
+];
+export function runUserPromptSubmitHook(input) {
+    if (!isCodexUserPromptSubmitInput(input))
+        return "";
+    if (isContextPressureRecoveryPrompt(input.prompt))
+        return "";
+    if (hasUltraworkDirectiveAlreadyInTranscript(input.transcript_path))
+        return "";
+    if (isContextPressureTranscript(input.transcript_path))
+        return "";
+    return isUltraworkPrompt(input.prompt) ? formatAdditionalContextOutput(ULTRAWORK_DIRECTIVE) : "";
+}
+function hasUltraworkDirectiveAlreadyInTranscript(transcriptPath) {
+    if (transcriptPath === undefined || transcriptPath === null)
+        return false;
+    try {
+        const rawTranscript = readTranscriptTail(transcriptPath);
+        for (const line of rawTranscript.split(/\r?\n/)) {
+            const parsed = parseJsonLine(line);
+            if (parsed === null) {
+                continue;
+            }
+            if (!isRecord(parsed)) {
+                continue;
+            }
+            const hookSpecificOutput = parsed["hookSpecificOutput"];
+            if (!isRecord(hookSpecificOutput)) {
+                continue;
+            }
+            if (hookSpecificOutput["hookEventName"] !== "UserPromptSubmit") {
+                continue;
+            }
+            if (typeof hookSpecificOutput["additionalContext"] === "string" &&
+                hookSpecificOutput["additionalContext"].includes(ULTRAWORK_DIRECTIVE_MARKER)) {
+                return true;
+            }
+        }
+    }
+    catch (error) {
+        if (error instanceof Error)
+            return false;
+        throw error;
+    }
+    return false;
+}
+function readTranscriptTail(transcriptPath) {
+    const rawTranscript = readFileSync(transcriptPath);
+    return rawTranscript.subarray(Math.max(0, rawTranscript.byteLength - TRANSCRIPT_SEARCH_BYTES)).toString("utf8");
+}
+export function isUltraworkPrompt(prompt) {
+    return ULTRAWORK_PATTERN.test(prompt);
+}
+function isContextPressureRecoveryPrompt(prompt) {
+    const normalizedPrompt = prompt.toLowerCase();
+    return CONTEXT_PRESSURE_MARKERS.some((marker) => normalizedPrompt.includes(marker));
+}
+function isContextPressureTranscript(transcriptPath) {
+    if (transcriptPath === undefined || transcriptPath === null)
+        return false;
+    try {
+        return isContextPressureRecoveryPrompt(readFileSync(transcriptPath, "utf8"));
+    }
+    catch (error) {
+        if (error instanceof Error)
+            return false;
+        throw error;
+    }
+}
+function formatAdditionalContextOutput(additionalContext) {
+    const normalizedContext = normalizeAdditionalContext(additionalContext);
+    if (normalizedContext.length === 0)
+        return "";
+    const output = {
+        hookSpecificOutput: {
+            hookEventName: "UserPromptSubmit",
+            additionalContext: normalizedContext,
+        },
+    };
+    return `${JSON.stringify(output)}\n`;
+}
+function normalizeAdditionalContext(additionalContext) {
+    return additionalContext.replace(/\r\n/g, "\n").replace(/\r/g, "\n").trim();
+}
+function parseJsonLine(line) {
+    if (line.trim().length === 0) {
+        return null;
+    }
+    try {
+        const parsed = JSON.parse(line);
+        return parsed;
+    }
+    catch (error) {
+        if (error instanceof Error) {
+            return null;
+        }
+        throw error;
+    }
+}
+function isCodexUserPromptSubmitInput(value) {
+    return (isRecord(value) &&
+        value["hook_event_name"] === "UserPromptSubmit" &&
+        typeof value["prompt"] === "string" &&
+        (value["transcript_path"] === undefined ||
+            value["transcript_path"] === null ||
+            typeof value["transcript_path"] === "string"));
+}
+function isRecord(value) {
+    return typeof value === "object" && value !== null && !Array.isArray(value);
+}

package/packages/omo-codex/plugin/components/ultrawork/dist/directive.d.ts

@@ -0,0 +1 @@
+export declare const ULTRAWORK_DIRECTIVE: string;

package/packages/omo-codex/plugin/components/ultrawork/dist/directive.js

@@ -0,0 +1,2 @@
+import { readFileSync } from "node:fs";
+export const ULTRAWORK_DIRECTIVE = readFileSync(new URL("../directive.md", import.meta.url), "utf8");

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

@@ -7,7 +7,7 @@
 						"type": "command",
 						"command": "node \"${PLUGIN_ROOT}/dist/cli.js\" hook user-prompt-submit",
 						"timeout": 5,
-						"statusMessage": "LazyCodex(0.1.0): Checking Ultrawork Trigger"
+						"statusMessage": "LazyCodex(4.9.1): Checking Ultrawork Trigger"
 					}
 				]
 			}

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

@@ -1,6 +1,6 @@
 {
 	"name": "@code-yeongyu/codex-ultrawork",
-	"version": "0.1.0",
+	"version": "4.9.1",
 	"description": "Codex plugin that injects the ultrawork orchestration directive and syncs the ultrawork reviewer agent role.",
 	"type": "module",
 	"packageManager": "npm@11.12.1",