oh-my-opencode 4.19.1 → 4.19.3

package/packages/omo-codex/plugin/skills/frontend/references/design/README.md

@@ -175,6 +175,12 @@ Triggers: dashboard, settings, mail/inbox, list-detail, command surface, split p
 
 **Action:** Add `layout-skill.md` on top of whatever style skill you selected in Steps 1-2. It carries scroll-ownership doctrine, the two silently-failing CSS contracts (`min-block-size: 0` scroll shells, `minmax(min(…),100%)` grids), the named-primitive vocabulary, container-vs-viewport routing, and the content-stress matrix. It adds no visual direction — the style skill still owns taste. Skip it for pure scroll-the-document marketing pages, where `taste-skill` layout guidance already fits.
 
+### Step 9 — Does the work add or change interaction or motion?
+
+Triggers: micro-interactions, animated components, transitions, gestures, hover/press/focus/state feedback, loading/success/error morphs, animated tabs/menus/modals/drawers/toasts — or "make it feel alive", "polish the interactions", "add micro-interactions".
+
+**Action:** Add `interaction-skill.md` on top of whatever style skill you selected. It anchors interaction design to the beui.dev catalog: find the nearest pattern, read its real source through the file's curl recipe, extract the mechanism (spring config, layout strategy, enter/exit order, reduced-motion path), and adapt the values to `DESIGN.md`. It owns interaction mechanics only — no visual direction — so it stacks cleanly, like `layout-skill.md`.
+
 ## Stacking rules (read this once, internalize it)
 
 1. **At most one Layer A *style* skill at a time.** A layout cannot be both `minimalist-skill` and `brutalist-skill` simultaneously — they encode opposite spacing and typography philosophies. Pick one.
@@ -184,6 +190,7 @@ Triggers: dashboard, settings, mail/inbox, list-detail, command surface, split p
 5. **`image-to-code-skill.md` pairs with one imagegen skill** for the full flow.
 6. **Layer B (brand DESIGN.md) is orthogonal to Layer A.** You can pair any Layer A skill with any Layer B brand. Use Layer B as the source of color/type/component tokens; let Layer A drive the execution discipline.
 7. **`layout-skill.md` stacks on top of any style skill** for app-shell / dashboard / split-pane work. It owns spatial structure and scroll ownership only — no visual direction — so it never conflicts with the style skill you picked.
+8. **`interaction-skill.md` stacks on top of any style skill** for interaction/motion work. It owns interaction mechanics — springs, layout morphs, enter/exit orchestration, reduced motion — and no visual direction, so it never conflicts with the style skill either.
 
 ## Anti-patterns — do not do these
 
@@ -227,6 +234,7 @@ Once references are loaded, before writing any UI code:
 | "Also output a DESIGN.md doc" | Add `stitch-skill.md` to current stack |
 | "Build a dashboard / settings / inbox / app shell" | one style skill (usually `taste-skill.md`) + `layout-skill.md` |
 | "Panel won't scroll / footer pushed off-screen / mobile overflow" | Add `layout-skill.md` to current stack |
+| "Add micro-interactions / animate this / make it feel alive" | Add `interaction-skill.md` to current stack |
 
 ## Phase Final — Design QA (MANDATORY, runs after implementation)
 

package/packages/omo-codex/plugin/skills/frontend/references/design/_INDEX.md

@@ -5,7 +5,7 @@ All reference files live flat in this directory. Three layers:
 - **Layer A — taste skills** (12 files): how to execute. Discipline, motion, spacing, anti-slop, output completeness.
 - **Layer B — design systems** (70 files): what it should look like. Brand-specific color/type/component tokens.
 
-**Phase 0 runs first** (check/create `DESIGN.md`), then most non-trivial tasks load **one Layer A + one Layer B** together. See the routing flow in the sibling `README.md`.
+**Phase 0 runs first** (check/create `DESIGN.md`), then most non-trivial tasks load **one Layer A + one Layer B** together. See the routing flow in the sibling `README.md`. Specialized phases (interaction and motion, app-shell layout, URL clones, real-product screen research) load the matching project-original operating reference — see the final section of this index.
 
 ---
 
@@ -52,6 +52,19 @@ From [Leonxlnx/taste-skill](https://github.com/Leonxlnx/taste-skill).
 
 ---
 
+## Operating references — interaction, layout, and research workflows (project-original)
+
+Beyond the 12-file Layer A library, the design ruleset carries project-original operating references for specialized phases. They stack on the routed Layer A + Layer B pair; they never replace a style skill, and they are not counted in the library totals above.
+
+| File | Purpose | Load when |
+|---|---|---|
+| `interaction-skill.md` | Interaction mechanics anchored to the beui.dev catalog: find the nearest pattern, read its real source through the curl recipe, extract the mechanism (spring config, layout strategy, enter/exit order, reduced-motion path), and adapt it to `DESIGN.md` motion tokens. | Any work adding or changing interaction or motion — micro-interactions, animated components, transitions, gestures, hover/press/state feedback, loading/success/error morphs, "make it feel alive". |
+| `layout-skill.md` | Layout mechanics: scroll ownership, the two silent CSS contracts, named primitives, content-stress matrix. Zero visual direction. | App shells, dashboards, split panes, or a layout that breaks under real content. |
+| `lazyweb.md` | Curl-only real-product screen research for design direction. | Greenfield design research lanes. |
+| `clone-from-url.md` | Runtime extraction workflow (browser + `getComputedStyle`) for cloning a named site. | A live site or URL is the visual reference. |
+
+---
+
 ## Layer B — Design Systems (70)
 
 Most Layer B files are materialized from [VoltAgent/awesome-design-md](https://github.com/VoltAgent/awesome-design-md), based on [Google Stitch DESIGN.md format](https://stitch.withgoogle.com/docs/design-md/overview/). Project-original entries such as `aside.md` are listed here only when `ATTRIBUTION.md` and `frontend-refs-manifest.mjs` mark them as original. Each file captures one website's complete visual language: color palette, typography, components, layout principles, depth, do/don't, responsive behavior, and an agent prompt guide.

package/packages/omo-codex/plugin/skills/frontend/references/design/interaction-skill.md

@@ -0,0 +1,144 @@
+---
+name: interaction-skill
+description: "Layer A interaction-mechanics reference anchored to the beui.dev catalog. Stacks on any style skill whenever work adds or changes motion or interaction — micro-interactions, animated components, transitions, gestures, hover/press/state feedback, loading/success/error morphs, 'make it feel alive'. Mandates reading the mapped beui.dev component source before designing an interaction; owns interaction mechanics and reduced-motion discipline; owns zero visual taste. Load it alongside a style skill; it does not replace one."
+---
+
+# Interaction Mechanics — beui.dev-Anchored
+
+Style skills decide how a surface looks. This file decides how it *moves and responds* — spring physics, layout morphs, enter/exit orchestration, gesture feel, and reduced-motion discipline. It stacks on top of any Layer A style skill and any Layer B brand, exactly like `layout-skill.md`, and adds ZERO visual direction: color, type, and material still come from the style skill and `DESIGN.md`.
+
+Load this whenever the deliverable includes interaction feel: micro-interactions, animated components, transitions, hover/press/focus/state feedback, gestures, loading/success/error morphs, animated tabs/menus/modals/drawers/toasts — or the user says "make it feel alive", "polish the interactions", "add micro-interactions".
+
+## 1. The reference contract — never design an interaction from memory
+
+[beui.dev](https://beui.dev) is the interaction benchmark: free, open-source animated React components (Motion + Tailwind CSS) where every component ships reduced-motion support and the full TypeScript source is one `curl` away. Improvised interaction design produces slop motion the same way freestyled styling produces generic SaaS slop, and the fix is the same: consult the reference before designing.
+
+The contract, in order:
+
+1. **Find the nearest pattern** in the catalog (section 3). The live catalog is `https://beui.dev/llms.txt`; refresh from it when a pattern seems missing from the tables below.
+2. **Read its real source** through the recipe (section 2). Never guess spring values, exit orchestration, or gesture thresholds from a preview description.
+3. **Extract the mechanism**, not the pixels: the spring config, the layout strategy (`layoutId` shared layout vs height morph vs clip-path), what animates in what order on enter/exit, where blur crossfades sit, and what the reduced-motion path swaps to.
+4. **Adapt to the project.** Concrete durations, easings, and spring params come from the project `DESIGN.md` Motion & Interaction section. Where beui.dev and `DESIGN.md` disagree, `DESIGN.md` wins. A value that is not in `DESIGN.md` gets added there first, then used.
+5. **No matching pattern?** Compose from the nearest two, or state explicitly that the interaction is novel and record its mechanism in `DESIGN.md` before building it.
+
+## 2. Consultation recipe (curl-only, verified 2026-07)
+
+All endpoints are public, no auth, no browser:
+
+```bash
+curl -s https://beui.dev/llms.txt                          # full catalog: every component + one-line feel
+curl -s https://beui.dev/r                                 # registry index (JSON): slugs, categories, endpoints
+curl -s https://beui.dev/r/{slug}                          # component detail (JSON): files, dependencies, dates
+curl -s https://beui.dev/r/{slug}/raw                      # component source (TypeScript) — the thing to read
+curl -s https://beui.dev/components/{category}/{slug}.md   # component doc page as markdown
+```
+
+Categories are `motion` (primitives) and `blocks` (composed patterns). When the user wants the component itself rather than the mechanism, a shadcn-style item registry exists at `https://beui.dev/r/{slug}.json`. Read source to learn; do not vendor beui.dev files into reference docs, and do not paste whole components into a project when only the mechanism is needed.
+
+## 3. Catalog — pattern routing map
+
+### Buttons, state feedback, and progress
+
+| Pattern (slug) | Mechanism | Reach for it when |
+|---|---|---|
+| `button` | Spring press; StatefulButton idle → loading → success/error with blur-swap slots and morphing width; MagneticButton cursor pull | Any submit/CTA that has async states — never leave a button state-less |
+| `action-swap` | Text/icon swap with blur motion | Copy → check, send → stop, any label that changes meaning in place |
+| `expanding-arrow-button` | Expanding, hold-to-confirm, and slide CTA interactions | Expressive marketing CTAs, destructive hold-to-confirm |
+| `animated-badge` | Animated state icons, pulse feedback | Connection/status dots, live activity indicators |
+| `loader` | 17 variants incl. terminal-ascii; reduced motion swaps every transform for an opacity pulse | Any loading state; copy its reduced-motion contract even when hand-rolling |
+| `otp-input` | Gliding focus ring, per-slot digit roll, error shake, success check draw | Code entry, verification flows |
+| `file-upload` | Progress rows, retry/remove, reduced-motion-safe state changes | Upload queues, long-running item lists |
+| `feedback-widget` | Trigger morphs into a popup with sending/success/retry states | Corner feedback affordances, inline report flows |
+
+### Selection and form controls
+
+| Pattern (slug) | Mechanism | Reach for it when |
+|---|---|---|
+| `switch` | Spring-driven thumb with press feedback | Boolean toggles |
+| `checkbox` | Draw-on checkmark, indeterminate support | Multi-select, tree selection |
+| `radio` | Gliding `layoutId` indicator dot | Single-select groups |
+| `input` | Label, icons, error shake, success check draw | Validated text entry |
+| `select` | Panel bouncily unfolds from the trigger; Morph variant grows the trigger into the panel | Dropdown selection with spatial continuity |
+| `range-slider` | Bouncy vertical-bar thumb gliding between snapped steps | Stepped value entry |
+| `wheel-picker` | iOS-style 3D drum on native momentum scroll with notch snap | Date/time or option drums, mobile-feel pickers |
+| `availability-scheduler` | Per-day spring toggles, blur-slide range add/remove | Schedule/slot editors |
+
+### Navigation and wayfinding
+
+| Pattern (slug) | Mechanism | Reach for it when |
+|---|---|---|
+| `tabs` | Pill/segment/underline with a spring `layoutId` indicator | Tab bars, view-mode selectors |
+| `expandable-tabs` | Active icon tab expands to a labelled pill; panel morphs height, slides direction-aware | Compact tab bars with rich panels |
+| `shared-layout-bg` | Pill glides between hovered items via shared layout, blur enter/exit | Sidebar/menu hover and active states |
+| `dock` | macOS-style grouped actions with a gliding active pill | Toolbars, grouped action rails |
+| `bounce-sidebar` | Active dot jumps between destinations on a curved spring path | Vertical navigation with a playful indicator |
+| `preview-rail` | Compact ticks form a hover pyramid and reveal a floating destination preview | Dense navigation rails, session/thread switchers |
+| `expandable-action-bar` | Icon actions expand into labelled controls on hover/focus | Compact action clusters |
+| `overflow-actions` | Connected pill rail springs open to reveal extra controls | Primary-plus-overflow action groups |
+| `command-palette` | Fuzzy filter with a spring-animated active row | Cmd-K surfaces |
+| `bloom-menu` | Button morphs into a menu blooming iris-out from center with radial stagger | Radial/launcher menus |
+
+### Overlays and surfaces
+
+| Pattern (slug) | Mechanism | Reach for it when |
+|---|---|---|
+| `tooltip` | Blur enter/exit, spring spawn | Hover/focus hints |
+| `popover` | Gooey SVG-filter ooze from the trigger; Morph variant clip-morphs from the trigger corner | Anchored panels that should feel attached to their trigger |
+| `context-menu` | Pointer-origin clip morph, gliding active row, keyboard nav, typeahead, long-press | Right-click and long-press menus |
+| `morphing-modal` | One panel morphs height between inner views, blur cross-fade on content | Multi-step dialogs, settings panes |
+| `center-morph-modal` | Surface unfolds from its exact center toward every edge and folds back | Focused confirm/detail modals |
+| `drawer` | Spring side panel, backdrop blur, body scroll lock, esc-to-close | Side panels, inspector panes |
+| `bottom-sheet` | Draggable sheet with snap points, inertia, glass surface | Mobile-feel sheets on any platform |
+| `dynamic-island` | Pill morphs between live-activity views with bouncy shell resize and blur crossfades | Live status surfaces, compact expanding widgets |
+| `notification-stack` | Cards spring from a stacked summary into a readable list on hover/focus/tap | Notification centers, grouped alerts |
+| `animated-toast-stack` | Status morphs, swipe dismissal, layout-aware stacking | Toast systems — layout-aware stacking is the bar |
+| `theme-toggle` | Full-page clip-path reveal via the View Transition API | Theme switching that should feel like one gesture |
+
+### Content, data, and gestures
+
+| Pattern (slug) | Mechanism | Reach for it when |
+|---|---|---|
+| `bouncy-accordion` | Single-open accordion with weighted spring layout, reduced-motion-safe reveals | Disclosure groups, expandable rows |
+| `table` | Virtualized 10k+ rows, sortable, resizable, minimal reduced-motion-safe motion | Data grids — proof that restraint is also a motion decision |
+| `infinite-masonry` | Virtualized variable-height masonry with progressive load | Media/card walls |
+| `swipeable-list` | Rows swipe to reveal contextual actions | Mobile-style lists with hidden actions |
+| `pull-to-refresh` | Drag resistance, threshold feedback, async refresh | Refreshable feeds |
+| `marquee` | Infinite horizontal/vertical scroll, pause on hover | Logo walls, tickers |
+| `text-animation` | Spring reveals, chromatic sweeps, shimmer loading, letter-cascade swaps | Hero copy, streaming/loading text |
+| `number` | Count-up values, rolling digit tickers | Metrics, token/cost counters |
+| `cylinder-carousel` | Items line a 3D cylinder with springy glide and snap | Showcase carousels |
+| `knockout-bracket` | Animated tournament fixtures paging through rounds | Bracket/progression views |
+| `prediction-market` / `swap` / `wallet-card` | Trade tickets, morphing swap views, morphing account surfaces | Finance-shaped composite widgets |
+| `not-found` | Five animated 404 styles | Error pages that keep the product's feel |
+
+### Ambience and scroll
+
+| Pattern (slug) | Mechanism | Reach for it when |
+|---|---|---|
+| `tilt-card` | 3D perspective tilt with cursor-tracked glare | Hero/product cards that should feel physical |
+| `shader-background` | Canvas shader variants (mesh gradient, grain, warp, waves…); reduced motion freezes them | Atmospheric backgrounds with dimension |
+| `scroll-animation` | Lenis smooth-scroll provider plus a reading-progress indicator | Scroll-driven storytelling |
+
+## 4. Mechanics rules
+
+These sharpen the shared axioms for interaction work; none of them replace the style skill.
+
+- **Motion serves meaning.** Every animation maps to a real interaction, state change, or affordance. A hover that changes nothing is slop — beui.dev patterns all animate *state*, never decoration.
+- **Reduced motion is part of the component, not an afterthought.** Every beui.dev component ships a reduced-motion path; match that bar. Web: `prefers-reduced-motion: reduce` disables or replaces every transform-based animation (the `loader` pattern's opacity-pulse swap is the model). React Native: respect the system reduce-motion setting.
+- **GPU-composited properties only** — `transform`, `opacity`, `filter`. Never animate layout properties; morph layout through shared-layout (`layoutId`) or measured height primitives instead.
+- **Springs move things; easings tint things.** Spatial movement (position, scale, layout morphs) wants spring physics so it stays interruptible and retargetable. Color, opacity, and blur want short duration + easing. Do not put a fixed-duration tween on a gesture-driven surface.
+- **Interruptibility is non-negotiable.** A press, hover-out, or route change mid-animation must retarget smoothly, never queue or block input. This is the practical reason beui.dev uses springs — copy that property, not just the bounce.
+- **Motion never regresses input latency or stream rendering.** Measure with the `perfection` ruleset when in doubt; a virtualized list's measurement contract beats a pretty reveal.
+- **Library choice is a project decision, not a default.** beui.dev assumes Motion (motion.dev) + Tailwind. If the project already has a motion stack, adapt the mechanism to it. If it has none: CSS transitions/WAAPI cover micro-interactions; adding a library is justified by shared-layout or spring-physics needs and gets recorded (with bundle cost) in `DESIGN.md`. Check `package.json` before importing anything.
+
+## 5. DESIGN.md integration
+
+`design-system-architecture.md` defines a Motion & Interaction section in every `DESIGN.md`. This file feeds it:
+
+- Extracted spring configs, durations, and easings land there as named tokens before components use them.
+- Each shipped interaction traces to a catalog pattern (or a recorded novel mechanism) plus its reduced-motion behavior.
+- New reusable interaction patterns (used 2+ times) get documented back into `DESIGN.md` Section 5 with their states, like any other primitive.
+
+## 6. Verification
+
+Interaction work is verified through `/visual-qa` with motion actually driven and inspected — hover, press, open/close, swipe, and theme transitions exercised on the rendered surface, plus a reduced-motion pass (emulate `prefers-reduced-motion: reduce`) proving the fallback exists. Timing-sensitive changes record a short screen capture, not just stills.

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

@@ -102,7 +102,7 @@ Mocks are a last resort, not a default. The priority order:
 - **Accurate**: the test fails for the bug it names, and only that bug. No incidental coupling to format, ordering, whitespace, or unrelated fields. Assert on the *contract*, not on the dump.
 - **Efficient**: the whole unit suite runs in < 30 seconds on a developer laptop. The whole integration suite in < 5 minutes. If you cross those budgets, profile and split — fast tests run on every save, slow ones run on push.
 - **Deterministic**: no `sleep`, no wall-clock dependence, no order dependence (`-shuffle=on`, pytest-randomly, vitest random seed). Inject a `Clock`. Subscribe to the event, do not poll for it. Time-based flake is a bug, not a test issue.
-- **Isolated**: every test starts from a known fixture and tears down. `t.TempDir()`, `t.Setenv()`, transactional rollback for DB tests. Two tests passing individually but failing together is a fixture leak — fix it immediately.
+- **Isolated**: every test starts from a known fixture and tears down. `t.TempDir()`, `t.Setenv()`, transactional rollback for DB tests. Two tests passing individually but failing together is a fixture leak — fix it immediately. Isolation extends **across processes**: suite-global resources — sandbox/cache roots under a fixed tmpdir path, hardcoded listen ports, container names — are namespaced per run (`mktemp`, port `0`/ephemeral, unique names) so that two checkouts or worktrees of the repo running the suite concurrently cannot interfere. A fixed shared path that works on a single-checkout machine is a flake generator on a multi-agent workstation, and its signature is "a different test fails each run".
 
 ### Prompt tests: NEVER assert prose
 
@@ -113,6 +113,7 @@ Assert ONLY what a machine consumes:
 - the builder's routing decision — `expect(getPromptSource(model)).toBe("gpt-5-6")`, never the sentence that routing produces
 - a structural token the runtime dispatches on — a tool name, a tag like `<agent-identity>`, a parsed frontmatter field
 - the conditional the code enforces — skill loaded → tool present; `verbose=false` → directive absent
+- a routing-bearing trigger fragment inside a parsed frontmatter `description` that a router (code or an LLM skill-picker) dispatches on — pin the *minimal fragment that carries the routing decision*, never the surrounding style prose. Such pins are what let a later rewrite change every sentence around them while proving the routing contract survived.
 
 If no machine consumes the text, there is no seam: write NO test and say so in the PR; review guards prose. When you DELEGATE test-writing, hand the child the behavior the test must distinguish ("fails if override precedence breaks"), never a ready-made assertion string, prompt fragment, or marker to copy — a prescribed mechanism that is wrong gets implemented faithfully, and the error ships with a green suite.
 
@@ -234,6 +235,15 @@ Logging is part of the code you ship, and it has iron rules of its own: levels c
 
 ---
 
+## DEPENDENCY UPGRADES — CROSS-CUTTING RULES
+
+- **`0.x` minor = major.** Semver promises nothing below 1.0: treat `0.N → 0.N+1` as a breaking upgrade — read the changelog, build, and run the full suite before trusting it. A required field appearing in a public options type is a routine `0.x` "minor".
+- **Version literals live outside the manifest.** Before committing a bump, grep the repo for the old version string: Dockerfiles pinning a global CLI, CI workflows, docs, and contract tests all carry copies. A bump that updates only the package manifest ships a split-brain deploy.
+- **Pin-parity contract tests are a pattern, not a nuisance.** A small test asserting the lockfile-resolved version equals the deploy artifact's pin (Dockerfile, image tag) turns silent drift into a red test. If the project has one, update it deliberately; if the bump reveals unguarded drift, add the test with the bump.
+- **Never hand-merge a lockfile.** On conflict, take either side whole and regenerate with the package manager — the resolver owns that file, not you.
+
+---
+
 ## MANDATORY POST-WRITE REVIEW LOOP
 
 **This runs EVERY time you finish writing or substantively editing code, before you claim the task is done.** No exceptions.

package/packages/omo-codex/plugin/skills/programming/references/logging.md

@@ -56,9 +56,11 @@ Log where the system decides something, not where it does something:
 - **Decision points** — retry chosen, fallback engaged, cache bypassed, degraded mode entered.
 - **The one place an error is finally handled.**
 
-Never log inside pure functions, utilities, or private helpers — callers with context log outcomes; internals stay silent. Two mechanical rules:
+Never log inside pure functions, utilities, or private helpers — callers with context log outcomes; internals stay silent. The mechanical rules:
 
 - **One event, one line.** Log-and-rethrow at every layer turns one incident into five look-alike incidents. Log where the error is handled; layers that only propagate stay silent.
+- **Answering the caller is not logging.** Converting a failure into a response — an HTTP 5xx body, an SSE error event, an error string returned to an LLM as a tool result, a non-zero exit code — satisfies the caller and leaves operations blind. This is the dominant finding when error paths are audited: the caller got an answer, the on-call got nothing. Every path that converts a failure into a caller-facing signal logs that failure exactly once, at the layer that handles it. When conversion layers stack, mark the error as logged at the handling layer (a symbol/flag on the error object) so outer catch-all handlers skip it — one incident, one line.
+- **Expected feedback returned to the caller is not an event.** Validation results delivered as a normal response — including tool output an LLM agent consumes ("string not found", lint findings, a sandbox-boundary notice) — are response content, not anomalies. Log only the genuine I/O and subprocess failures behind them, and security rejections.
 - **Mechanical logging belongs to middleware.** Request/response logging is wired once at the framework layer, never hand-assembled per handler. High-volume zero-signal paths (health probes, metrics scrapes) are excluded there as data — an exclusion set — not as scattered `if` statements.
 
 **No speculative logs.** "Might need it later" is not a consumer. A log line earns its place through evidence: a debugging session that burned rounds because this state was invisible (see the debugging bridge below), an incident postmortem, an alert that needs the field.
@@ -69,6 +71,7 @@ Never log inside pure functions, utilities, or private helpers — callers with
 - **Correlation or it did not happen.** Request-scoped lines carry the trace/request id; entity-scoped lines carry the entity id. A line you cannot join to its request is noise during the only moments logs matter.
 - **Name events semantically** (`session.destroy`, `payment.fallback`), never positionally ("Step 3"). Step numbers couple the log stream to today's call structure; the first refactor makes them lie.
 - **No secrets.** Tokens, credentials, session cookies, and PII never enter a log line; URLs are sanitized (strip or redact query params like `token`, `key`) before logging. A leaked log is a leaked credential.
+- **Payload content belongs to the tracing channel, not the log stream.** In LLM/agent systems, user messages, model responses, and tool outputs are captured by the tracing product (turn recorder, trace exporter); a log line carries a hash, a length, and at most a short excerpt for correlation. Dumping conversation content into logs bloats the store and leaks data the log pipeline was never hardened for.
 - **The logging path may not break the program.** If a log call can itself fail (serializing exotic state, a wrapper that touches I/O), that failure is caught, downgraded to a `warn` through a channel that cannot fail, and the operation continues. An empty catch around logging is still an empty catch.
 
 ## Anti-patterns
@@ -79,6 +82,8 @@ Never log inside pure functions, utilities, or private helpers — callers with
 | Introducing a logging framework to a project that has none | Uninvited behavior change; Rule 0 violation |
 | 4xx logged as `error` | Alert noise buries real pages |
 | Log-and-rethrow at every layer | One incident looks like five |
+| Failure converted to a caller response (5xx body, SSE error, LLM tool-error string, exit code) with no log | The caller got an answer; operations got nothing |
+| Logging expected validation feedback that is returned to the caller | Response content, not an event — buries real failures |
 | Variables interpolated into the message string | Un-aggregatable, un-alertable |
 | "Might need it later" logs | No consumer → pure cost |
 | Debug-time prints promoted to permanent `info` | Narration, not state transitions |

package/packages/omo-codex/plugin/skills/programming/scripts/typescript/check-no-excuse-rules.ts

@@ -33,21 +33,26 @@ import fs from "node:fs"
 import { createRequire } from "node:module"
 import path from "node:path"
 import process from "node:process"
-import type * as tsTypes from "typescript"
+import type * as tsTypes from "typescript/unstable/ast"
 
-type TsModule = typeof import("typescript")
+type TsApiModule = typeof import("typescript/unstable/async")
+type TsAstModule = typeof import("typescript/unstable/ast")
+type TsModule = {
+  readonly api: TsApiModule
+  readonly ast: TsAstModule
+}
 
 function loadTypescriptFromCaller(): TsModule {
-  // A static `import ts from "typescript"` resolves from this script's location —
-  // an installed skill-cache path (e.g. ~/.codex/...) with no node_modules of its
-  // own — and fails even when the checked project has typescript. Resolve from the
-  // caller project (cwd) instead. When the caller has no local typescript, Bun
-  // falls back to a version-only stub from its global install cache instead of
-  // throwing, so the loaded module's API shape is verified as well.
+  // A static import resolves from this script's installed skill-cache path
+  // instead of the caller project. Resolve each TypeScript 7 API subpath from
+  // the caller so the script uses the project it audits.
   const callerRequire = createRequire(path.join(process.cwd(), "no-excuse-anchor.cjs"))
   try {
-    const loaded: Partial<TsModule> = callerRequire("typescript")
-    if (typeof loaded.createSourceFile === "function") return loaded as TsModule
+    const api: Partial<TsApiModule> = callerRequire("typescript/unstable/async")
+    const ast: Partial<TsAstModule> = callerRequire("typescript/unstable/ast")
+    if (typeof api.API === "function" && typeof ast.isAsExpression === "function") {
+      return { api: api as TsApiModule, ast: ast as TsAstModule }
+    }
   } catch { // no-excuse-ok: catch
     // fall through to the clear error below
   }
@@ -58,7 +63,8 @@ function loadTypescriptFromCaller(): TsModule {
   process.exit(2)
 }
 
-const ts: TsModule = loadTypescriptFromCaller()
+const typescript = loadTypescriptFromCaller()
+const ts = typescript.ast
 
 type RuleId =
   | "no-any-assertion"
@@ -132,9 +138,30 @@ function getLineText(sourceFile: tsTypes.SourceFile, line: number): string {
   return sourceFile.text.slice(start, end)
 }
 
-function analyzeFile(filePath: string): Violation[] {
+async function parseSourceFiles(filePaths: readonly string[]): Promise<ReadonlyMap<string, tsTypes.SourceFile>> {
+  const compiler = new typescript.api.API({ cwd: process.cwd() })
+  try {
+    const snapshot = await compiler.updateSnapshot({ openFiles: [...filePaths] })
+    try {
+      const sourceFiles = await Promise.all(filePaths.map(async (filePath) => {
+        const project = await snapshot.getDefaultProjectForFile(filePath)
+        const sourceFile = await project?.program.getSourceFile(filePath)
+        if (!sourceFile) {
+          throw new Error(`TypeScript did not parse ${filePath}`)
+        }
+        return [filePath, sourceFile] as const
+      }))
+      return new Map(sourceFiles)
+    } finally {
+      await snapshot.dispose()
+    }
+  } finally {
+    await compiler.close()
+  }
+}
+
+function analyzeFile(filePath: string, sourceFile: tsTypes.SourceFile): Violation[] {
   const source = fs.readFileSync(filePath, "utf-8")
-  const sourceFile = ts.createSourceFile(filePath, source, ts.ScriptTarget.Latest, true)
   const violations: Violation[] = []
 
   function pos(node: tsTypes.Node): { line: number; column: number } {
@@ -251,7 +278,7 @@ function analyzeFile(filePath: string): Violation[] {
       }
     }
 
-    ts.forEachChild(node, visit)
+    node.forEachChild(visit)
   }
 
   visit(sourceFile)
@@ -282,7 +309,7 @@ function formatViolation(v: Violation): string {
   return `${v.filePath}:${v.line}:${v.column}: [${v.ruleId}] ${v.message}`
 }
 
-function main(): void {
+async function main(): Promise<void> {
   const args = process.argv.slice(2)
   if (args.length === 0) {
     console.error("usage: check-no-excuse-rules.ts <file-or-dir>...")
@@ -295,7 +322,14 @@ function main(): void {
     process.exit(2)
   }
 
-  const violations = files.flatMap((f) => analyzeFile(f))
+  const sourceFiles = await parseSourceFiles(files)
+  const violations = files.flatMap((filePath) => {
+    const sourceFile = sourceFiles.get(filePath)
+    if (!sourceFile) {
+      throw new Error(`TypeScript did not parse ${filePath}`)
+    }
+    return analyzeFile(filePath, sourceFile)
+  })
 
   if (violations.length === 0) {
     console.log(`No violations in ${files.length} file(s).`)
@@ -309,4 +343,4 @@ function main(): void {
   process.exit(1)
 }
 
-main()
+await main()

package/packages/omo-codex/plugin/skills/start-work/SKILL.md

@@ -45,11 +45,21 @@ Execute a Prometheus work plan until every top-level checkbox is complete. This
 ## Usage
 
 ```text
-$start-work [plan-name] [--worktree <absolute-path>]
+$start-work [plan-name] [--worktree <absolute-path>] [--make-pr] [--ship]
 ```
 
 - `plan-name` (optional): a full or partial file stem under `.omo/plans/`.
 - `--worktree` (required for PR/branch work; otherwise optional): the task-owned git worktree path.
+- `--make-pr` (optional): deliver the work as a pull request. IMPLIES worktree mode: when `--worktree` is absent, create a task-owned worktree (`git worktree add <absolute-path> <base-branch>`) before implementation and record it as `worktree_path`. On completion, push the branch and open a reviewer-readable PR, then hand off with the PR URL - merge only if the user asks.
+- `--ship` (optional): full delivery lifecycle; implies `--make-pr`. After the PR opens, stay on the job until it is MERGED: watch CI and review gates, fix failures and address feedback from the worktree (fresh QA evidence for behavior changes), merge per the repository's merge policy, then remove the worktree and sync `.omo/` state back.
+
+## Goal and todo discipline (MANDATORY)
+
+Do ALL of this immediately after the plan is selected, BEFORE the first implementation dispatch. Skipping any step is a defect.
+
+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 goal. 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 is appended as a todo before it runs. The todo list, Boulder state, and plan checkboxes must always tell the same story.
 
 ## Phase 1: Select the plan
 
@@ -92,7 +102,7 @@ Write `.omo/boulder.json` before implementation starts. Prefix session ids with
 }
 ```
 
-For PR/branch work, `--worktree` is mandatory before implementation starts. Verify the path with `git worktree list --porcelain` or create it with `git worktree add <path> <branch-or-HEAD>`, then store the absolute path as `worktree_path`. All edits, commands, tests, and evidence capture must run inside that worktree.
+For PR/branch work, a task-owned worktree is mandatory before implementation starts: pass `--worktree`, or use `--make-pr`/`--ship`, which auto-create one. Verify the path with `git worktree list --porcelain` or create it with `git worktree add <path> <branch-or-HEAD>`, then store the absolute path as `worktree_path`. All edits, commands, tests, and evidence capture must run inside that worktree.
 
 ## Phase 3: Execute the next checkbox
 

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

@@ -411,13 +411,18 @@ Procedure (NON-NEGOTIABLE):
    2-attempt stop rule below) — do not loop further.
 
 # Commits
-Atomic, Conventional Commits (`<type>(<scope>): <imperative>` — feat /
-fix / refactor / test / docs / chore / build / ci / perf). One logical
-change per commit; each commit builds + tests green on its own. No WIP
-on the final branch. If a plan file exists, final commit footer:
-`Plan: .omo/plans/<slug>.md`. Do NOT auto-`git commit` unless the user
-requested or preauthorised this session — default is stage + draft
-message + present for approval.
+Commit frequently: one atomic commit per verified increment (RED→GREEN
++ its evidence), never one end-of-run omnibus; each commit builds +
+tests green on its own; no WIP on the final branch.
+BEFORE composing each message, read the history and mimic it: run
+`git log --oneline -20` plus `git log -5 -- <touched paths>` and match
+the observed convention — subject shape, scope names, message language,
+body style, and typical commit size. Default to Conventional Commits
+(`<type>(<scope>): <imperative>` — feat / fix / refactor / test / docs /
+chore / build / ci / perf) only where history shows no stronger local
+convention. If a plan file exists, final commit footer:
+`Plan: .omo/plans/<slug>.md`. Skip committing only when the user forbade
+commits this session — then stage + draft the message instead.
 
 # Constraints
 - Every behavior change needs a failing-first proof captured BEFORE

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

@@ -20,6 +20,7 @@ This skill is intentionally compact. The full workflow lives in `references/full
 ## Non-Negotiables
 
 - Use the ulw-loop CLI state under `.omo/ulw-loop`; do not hand-edit goal state.
+- Register goals up front (`omo ulw-loop create-goals`, then `create_goal` from the printed handoff) and mirror every atomic step into the live `update_plan` checklist: one ultra-granular step per action, exactly one in_progress, transitions marked the instant they happen.
 - After any compaction or context loss, re-read brief + goals + ledger FIRST plus `omo ulw-loop status --json`, then resume; never re-plan from scratch.
 - If `omo ulw-loop create-goals` says the existing aggregate is already complete, start unrelated new work with a fresh `--session-id <new-id>` instead of steering or forcing the completed default state. Use `--force` only to intentionally overwrite completed evidence.
 - Every success criterion needs observable evidence from a real surface: a channel (terminal/TUI via the xterm.js web terminal, HTTP, browser, computer-use) or, for CLI- or data-shaped criteria, an auxiliary surface (CLI stdout, DB diff, parsed config dump).
@@ -31,7 +32,24 @@ This skill is intentionally compact. The full workflow lives in `references/full
 - Track spawned agent names locally. Use `wait_agent` for mailbox signals, not proof of completion. A timeout only means no new mailbox update arrived. Treat a running child as alive.
 - While children run, surface the active subagent count, agent names, and latest `WORKING:` phase.
 - Fallback only when the child is completed without the deliverable, ack-only after `followup_task`, explicitly `BLOCKED:`, or no longer running. Then record inconclusive and respawn a smaller `fork_turns: "none"` task with the missing deliverable.
-- Use `git-master` for git-tracked edits: inspect recent and touched-path commit history, then commit each verified work unit atomically in the repository's observed language, scope, and message style with only that unit's files staged.
+- Use `git-master` for git-tracked edits: inspect recent and touched-path commit history, then commit each verified work unit atomically in the repository's observed language, scope, and message style with only that unit's files staged. Never carry verified units into a later omnibus commit.
+
+## Team mode: decide it, do not default to it
+
+Solo execution with parallel background `task` workers is the default. A team (`team_create`) adds per-member briefing, shared-state, and relay overhead, so it must be paid for by the work's shape. Decide ONCE, when the plan's work units are known, and record the verdict plus its reason in the notepad.
+
+Stand up a team when BOTH hold:
+
+1. **The units' scopes overlap in a way you cannot cleanly cut.** They touch the same module, contract, or migration, so one unit's discovery changes what another should do. Fire-and-forget workers cannot exchange that mid-flight; teammates can, because the lead relays it.
+2. **Running them at the same time actually finishes sooner.** The units are each substantial and none is merely waiting on another's output. Two units where the second only consumes the first's result are a sequence, not a team.
+
+When the units are genuinely independent — separate files, no shared contract — spawn parallel background `task` workers instead and avoid the team coordination overhead entirely. When the work is one cohesive unit, do it yourself. Overlap alone is not enough: near-identical units that would collide on the same lines are faster done in sequence by one worker.
+
+Under team mode, isolate and land per unit:
+
+- **One git worktree per member**, never a shared checkout — concurrent members editing one working tree corrupt each other's diffs and evidence. Give each member its own branch off the base and its own worktree path.
+- **Merge per work unit, as each unit is verified.** A member's unit lands when its own evidence is captured and its gates are green; it does not wait for the slowest sibling. Integrate each merged unit back into the base the others branch from, so overlapping members rebase onto real merged work rather than guessing at it.
+- **Conflicts are the lead's job.** When two members' units touch the same lines, the lead decides the order they land and tells the later member what changed; members never resolve a sibling's conflict blind.
 
 ## Codex Tool Mapping
 

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

@@ -108,5 +108,5 @@ Roles: `explorer` (internal patterns/conventions/tests), `librarian` (external d
 
 ## Stop rules
 
-- Plan file exists, template filled, every todo has references + acceptance + QA + commit, dependency matrix consistent, and any required high-accuracy receipts are recorded: present the summary, then (CLEAR without `review_required`) ask the start-or-high-accuracy question, or (CLEAR with `review_required` / UNCLEAR) report the review result - and stop. **Never begin execution yourself.**
+- Plan file exists, template filled, every todo has references + acceptance + QA + commit, dependency matrix consistent, and any required high-accuracy receipts are recorded: present the handoff explanation (Phase 4 delivery format in `references/full-workflow.md`), then (CLEAR without `review_required`) ask the start-or-high-accuracy question, or (CLEAR with `review_required` / UNCLEAR) report the review result - and stop. **Never begin execution yourself.**
 - Brief presented and `status: awaiting-approval` recorded: wait. Do not re-explore unless the user changes scope.

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

@@ -168,6 +168,17 @@ Runs in parallel; ALL must APPROVE; surface results and wait for the user's expl
 - CLEAR with `review_required: true`: run the high-accuracy review before delivery, record receipts, then present the plan summary and review result. Do not ask whether to run the review; the user already asked.
 - UNCLEAR: run the high-accuracy review AUTOMATICALLY before presenting (unless Classify=Trivial), then present a brief that LEADS with the derived approach and the adopted defaults; still wait for the user's explicit okay.
 
+### Handoff explanation (the mandatory shape of every plan summary)
+
+Every "present the plan summary/brief" above delivers THIS structure, in the user's language, derived from the finished plan file (COUNT the rows - never estimate):
+
+1. **What this plan drives** - the work it performs, in 1-2 sentences.
+2. **End state** - the concrete things that will exist or behave differently once execution finishes.
+3. **Shape** - how many phases/waves and how many tasks: N implementation todos (`- [ ] N.` rows) + F final-verification tasks (`- [ ] F<n>.` rows).
+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).
+
 ### 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 Codex CLI review on gpt-5.6-sol at xhigh reasoning, run in a disposable isolated workspace and `CODEX_HOME` with the harness's 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 cited issue and resubmit both fresh until each approves. CLEAR: runs when the user opts in or `review_required: true`. UNCLEAR: runs automatically unless Classify=Trivial.
 
@@ -212,6 +223,6 @@ If your tool list has a flat `spawn_agent` with a required `task_name` instead o
 Roles: `explorer`, `librarian`, `metis`, `momus`. Spawn long plan/reviewer agents in the background; between waits, back off — double the timeout up to ~5 minutes — instead of spinning short cycles. Require the child to send `WORKING: <task> - <phase>` before long passes and `BLOCKED: <reason>` only when progress stops. A wait timeout only means no new mailbox update arrived; treat a running child as alive. Fall back only when the child completed without the deliverable, is ack-only after followup, explicitly `BLOCKED:`, or no longer running; then respawn a smaller `fork_context: false` job. Close each agent after integrating its result.
 
 ## Stop rules
-- Plan file exists, template filled, every todo has references + acceptance + QA + commit, dependency matrix consistent, and any required high-accuracy receipts recorded: present the summary, then (CLEAR without `review_required`) ask the start-or-high-accuracy question, or (CLEAR with `review_required` / UNCLEAR) report the review result - and stop. Execution belongs to the worker, never to you.
+- Plan file exists, template filled, every todo has references + acceptance + QA + commit, dependency matrix consistent, and any required high-accuracy receipts recorded: present the handoff explanation (Phase 4 format), then (CLEAR without `review_required`) ask the start-or-high-accuracy question, or (CLEAR with `review_required` / UNCLEAR) report the review result - and stop. Execution belongs to the worker, never to you.
 - Brief presented and `status: awaiting-approval` recorded: wait. Do not re-explore unless the user changes scope.
 - Two research waves with no new useful facts: stop exploring, present the brief.

package/packages/omo-codex/plugin/skills/ulw-plan/references/intent-clear.md

@@ -30,7 +30,7 @@ CLEARANCE CHECK after each turn: objective defined? scope IN/OUT explicit? appro
 </interview>
 
 <approval_and_deliver>
-Run the durable approval gate (mechanics in `full-workflow.md`): present the brief once with findings (paths), the approach, and EVERY surviving owner-decision as an explicit question with your recommended option (a skipped one resolves to that default); then wait for the user's explicit okay. If "start now, or review first?" would be your ONLY question, you have defaulted forks you should have surfaced - list them first. After approval: scaffold the files, run mandatory Metis, APPEND the todos, fill the human TL;DR last. Then either run the dual high-accuracy review if `review_required: true`, or present the summary and ask ONE question - start work now, or run the dual high-accuracy review first? Never pick for the user when review was not requested; never begin execution.
+Run the durable approval gate (mechanics in `full-workflow.md`): present the brief once with findings (paths), the approach, and EVERY surviving owner-decision as an explicit question with your recommended option (a skipped one resolves to that default); then wait for the user's explicit okay. If "start now, or review first?" would be your ONLY question, you have defaulted forks you should have surfaced - list them first. After approval: scaffold the files, run mandatory Metis, APPEND the todos, fill the human TL;DR last. Then either run the dual high-accuracy review if `review_required: true`, or present the handoff explanation (full-workflow.md Phase 4 format) and ask ONE question - start work now, or run the dual high-accuracy review first? Never pick for the user when review was not requested; never begin execution.
 </approval_and_deliver>
 
 <worked_example>

package/packages/omo-codex/plugin/test/sync-skills-orchestration.test.mjs

@@ -235,6 +235,28 @@ test("#given synced aggregate Codex skills #when they describe background orches
 	}
 });
 
+test("#given packaged start-work and ulw-plan skills #when inspected #then PR delivery options and the handoff explanation ship", async () => {
+	// given
+	const startWork = await readSkill("start-work");
+	const workflow = await readFile(join(root, "skills", "ulw-plan", "references", "full-workflow.md"), "utf8");
+
+	// when / then
+	assert.match(startWork, /--make-pr/);
+	assert.match(startWork, /--ship/);
+	assert.match(startWork, /implies `--make-pr`/i);
+	assert.match(startWork, /IMPLIES worktree mode/i);
+	assert.match(startWork, /Goal and todo discipline/i);
+	assert.match(startWork, /create_goal/);
+	assert.match(startWork, /one todo per column-zero checkbox/i);
+
+	assert.match(workflow, /Handoff explanation/i);
+	assert.match(workflow, /Added beyond the request/i);
+	assert.match(workflow, /\$start-work <plan-name>/);
+	assert.match(workflow, /--make-pr/);
+	assert.match(workflow, /--ship/);
+	assert.match(workflow, /COUNT the rows/i);
+});
+
 test("#given start-work skill #when synced for Codex #then the difficulty-tier delegation guidance survives the overlay", async () => {
 	const content = await readSkill("start-work");
 

package/packages/omo-codex/scripts/install-dist/install-local.mjs

@@ -5903,7 +5903,7 @@ var package_default;
 var init_package = __esm(() => {
   package_default = {
     name: "@oh-my-opencode/omo-codex",
-    version: "4.19.1",
+    version: "4.19.3",
     type: "module",
     private: true,
     description: "Codex harness adapter for oh-my-openagent. Vendored Codex plugin namespace (omo) + TypeScript installer + telemetry.",