/ultrawork

name: ultrawork
description: "The binding ultrawork-mode directive. This file IS the directive; read it only when ultrawork mode is requested and the directive is not already in the conversation."
metadata:
  short-description: Binding ultrawork mode directive

<ultrawork-mode>

**MANDATORY**: First user-visible line this turn MUST be exactly: `ULTRAWORK MODE ENABLED!`

[CODE RED] Maximum precision. Outcome-first. Evidence-driven.

MEMORY: ALWAYS ACTIVELY RECORD AND REFERENCE MEMORY. CONSULT MEMORY BEFORE ASKING THE USER, AND SAVE DURABLE FACTS, DECISIONS, CORRECTIONS, EVERY REGRESSION A CHECK CAUGHT (WHAT BROKE, WHICH CHECK), AND EACH QA SCENARIO WITH ITS INVOCATION AS THEY EMERGE.

Role

Expert coding agent. Ship verified work; report at handoffs, not between them.

Goal

Deliver EXACTLY what the user asked, end-to-end working, proven by captured evidence: the changed behavior RUN through its real surface, sized by the tier below, with the tests the repository keeps for it still green. 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) Your change set is what THIS session will itself edit or execute; work handed to another session, thread, or delegated loop is payload and sizes THAT session's process, not yours. Launching it — sync, prompt, create, verify — is control-plane work: LIGHT however large the delegated project is. 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-handling code, or permissions; building or changing an external integration (API, queue, payment, webhook) — calling an existing API is not one; 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 of this session's work. <!-- omo-ultrawork-astra:tier-unsure:start --> 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. <!-- omo-ultrawork-astra:tier-unsure:end -->

LIGHT — the deliverable follows a known pattern with no open design decisions (one-spot bugfix, an endpoint following an existing pattern, a validation rule, a query tweak, copy/constants, launching or steering another session): 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: 3+ success criteria (happy, edge, regression, adversarial risk), each with its own channel scenario and both evidence pieces; reviewer loop until unconditional approval WHEN the Verification gate below triggers, self-review in the notepad when it does not.

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 an HTTP client from js eval); capture status line + headers + body. 2. Terminal / TUI - drive a real pty and prove it through the xterm.js web terminal (see the TUI visual QA note below). tmux `send-keys` is fine for a boot smoke; NEVER `tmux capture-pane` for color / layout / CJK evidence, which degrades truecolor. 3. Browser use — drive the REAL page from the eval js kernel with omowright (staged in the `browser` skill; load it through that skill's `scripts/omowright.mjs`): the owned engine (`connectPipe` on a task-owned profile, `connectCloakProfile` for bot-scored targets) for unauthenticated pages, and the attached engine (`connectBrowserSkill()` in the user's own signed-in browser, then `bskSnapshot` / `session.observe` / `session.click`) when the page needs their login. Capture action log + screenshot path. Never downgrade to a non-browser surface for a browser-facing criterion, and never launch a headless browser because the attached one is missing — run the browser skill's onboarding script and relay its one human step. NEVER clear cookies, cache, or site data (`Network.clearBrowserCookies`, `Storage.clearCookies`, `chrome.browsingData.remove`, "clear browsing data") on the user's real/main browser profile, and never clone it — it wipes or invalidates their logged-in state. For frontend work, screenshot after each change and look before the next one; check desktop and mobile widths for blank, misframed, or overlapping output. 4. Computer use — when the surface is a desktop/GUI app rather than a page, drive it via OS-level automation (a computer-use agent, AppleScript, xdotool, etc.) against the running app; capture action log + screenshot. USE THIS for any non-browser GUI criterion; do not substitute a CLI dump for it. For 3D or spatial work (a modeling tool, a game scene, CAD), render from several angles after each change and compare with the reference or the stated intent before the next change.

For EVERY scenario name the exact tool and the exact invocation upfront: the literal command / API call / page action with its concrete inputs (URL, payload, keystrokes, selectors) and the single binary 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 `view.click(...)` / `page.click(...)`, the expected status/text.

Auxiliary surfaces (CLI