lazycodex-ai 5.1.62 → 5.1.64

package/packages/omo-codex/plugin/skills/ultimate-browsing/references/agent-reach/web.md

@@ -6,13 +6,13 @@
 
 ```bash
 # 读取任意网页内容
-curl -s "https://r.jina.ai/URL"
+curl -s -H "Authorization: Bearer ${JINA_API_KEY}" "https://r.jina.ai/URL"
 
 # 示例
-curl -s "https://r.jina.ai/https://example.com/article"
+curl -s -H "Authorization: Bearer ${JINA_API_KEY}" "https://r.jina.ai/https://example.com/article"
 ```
 
-**适用场景**: 大多数网页可以直接用 Jina Reader 读取。
+**适用场景**: 大多数网页可以直接用 Jina Reader 读取。匿名调用返回 401，必须带 `JINA_API_KEY`（见 [../insane-search/jina.md](../insane-search/jina.md)）。
 
 ## Web Reader (MCP)
 
@@ -69,7 +69,7 @@ for e in feedparser.parse('FEED_URL').entries[:5]:
 
 | 场景 | 推荐工具 |
 |-----|---------|
-| 通用网页 | Jina Reader (`curl r.jina.ai`) |
+| 通用网页 | Jina Reader (`curl r.jina.ai`，需 `JINA_API_KEY`) |
 | 需要图片/格式控制 | web-reader MCP |
 | 微信公众号 | Exa (搜索+阅读) / Camoufox (可选阅读) |
 | RSS 订阅 | feedparser |

package/packages/omo-codex/plugin/skills/ultimate-browsing/references/chrome-stealth.md

@@ -29,7 +29,8 @@ page that only a signed-in user can reach belongs to the attached engine, not to
 
 ## Cookie login limits
 
-`scripts/extract_cookies.py` still exports cookies from a local browser; inject them with
+`scripts/extract_cookies.py` still exports cookies from a local browser's default profile store (run it only where
+that profile is not the user's live one; see `../SKILL.md`, Cookie login); inject them with
 `injectCookies(page, cookies)` into an **owned** profile. It sanitizes the set (drops expired
 entries, keeps host-prefixed cookies secure and root-scoped). Limits that do not change:
 

package/packages/omo-codex/plugin/skills/ultimate-browsing/references/insane-search/README.md

@@ -17,7 +17,7 @@
 2. 즉시 다음을 실행:
    ```bash
    python3 -B -m engine "<URL>" [--selector "<CSS>"] [--device auto|desktop|mobile] [--trace] \
-                              [--no-retry] [--no-extract]
+                              [--timeout 25] [--max-attempts 12] [--no-playwright] [--allow-proxy] [--json]
    ```
 3. 종료코드 0(ok) 또는 1(fail) 받은 뒤 판단. trace를 먼저 읽고 재시도 결정.
 4. 실패 시에만 `--trace --json`으로 재호출해서 원인 진단 후 `--device` 또는 `user_hint` 조정.
@@ -124,7 +124,7 @@
 ### 단일 진입점
 
 ```python
-from insane_search.engine import fetch
+from engine import fetch      # 스킬 디렉터리에서 실행 (패키지는 engine/)
 
 result = fetch(
     "https://example.com/path",
@@ -136,15 +136,13 @@ result = fetch(
 
 if result.ok:
     print(result.verdict)     # strong_ok | weak_ok
-    html = result.content     # raw body — 단, content-rescue가 발동한 경우 구조 텍스트
-    # v0.10.0 content-rescue: PDF 응답은 pypdf 추출 텍스트, visible text가 얇은
-    # SPA 셸은 JSON-LD articleBody / 렌더된 innerText로 대체될 수 있다.
-    # result.extraction_source로 판별: "raw"(원문 그대로) | pdf | json_ld | *+inner_text.
-    # 일반 HTML 성공은 항상 raw. 끄기: enable_extraction=False / --no-extract.
-    # 429/502/503/504는 probe에서 백오프 재시도(Retry-After 반영, 총 10초 캡);
-    # 끄기: enable_retry=False / --no-retry.
+    html = result.content     # raw body (내장 추출/변환 없음)
+    # 필드: ok, content, final_url, verdict, profile_used, trace, summary,
+    #       provenance, snapshot_timestamp, trust (engine/result_schema.py FetchResult).
+    # 업스트림 신버전의 content-rescue(PDF/JSON-LD 추출)와 Retry-After 백오프는
+    # 이 스냅샷에 없다 — engine/AGENTS.md의 WANT 목록. grid 시도 사이에는 짧은 jitter만 둔다.
 else:
-    # Phase 3 수동 개입 (Playwright MCP) 필요 — result.trace로 원인 진단
+    # result.trace로 원인 진단. 브라우저가 필요하면 아래 "needs_js_exec only 폴백 규칙"을 따른다
     pass
 ```
 
@@ -191,16 +189,17 @@ report     — FetchResult(ok, verdict, profile_used, trace, summary)
 | 태그 | 실행기 | 언제 |
 |------|--------|------|
 | `needs_real_tls_stack` + `needs_js_exec` | `playwright_real_chrome.js` (로컬 Node) | Akamai Bot Manager 등 — Chromium 번들 TLS는 탐지됨 |
-| `needs_js_exec` only | Playwright MCP (`mcp__playwright__*`) | Cloudflare 기본 방어 등 |
+| `needs_js_exec` only | 에이전트가 직접 띄우는 브라우저 (엔진은 stub만 반환, 아래 규칙) | Cloudflare 기본 방어 등 |
 | `needs_mobile_context` (+ real_tls) | `playwright_mobile_chrome.js` | 모바일 디바이스 에뮬레이션 필요 |
 
 자세한 선택 기준: [playwright.md](playwright.md).
 
-### Playwright MCP 호출 규칙
+### `needs_js_exec only` 폴백 규칙
 
-`fetch_chain`의 `needs_js_exec only` 케이스는 **Claude 세션에서 MCP 도구를 직접 호출**해야 한다. subprocess 경로 없음. 즉:
+`fetch_chain`의 `needs_js_exec only` 케이스는 subprocess 경로가 없어 **에이전트가 직접 브라우저를 다뤄야** 한다. 즉:
 1. `result.summary`에 "Playwright MCP must be invoked from the Claude session"이 포함되면
-2. `mcp__playwright__browser_navigate` → `browser_wait_for` → `browser_snapshot` 흐름으로 Claude가 직접 처리
+2. 엔진 문구가 MCP를 가리켜도 기본 경로는 Tier 2a owned engine이다: js eval에서 omowright `connectPipe`, 스텔스는 `connectCloakProfile` (`../../SKILL.md` Tier 2, the `browser` skill's `references/owned-engine/`)
+3. `mcp__playwright__*` 도구는 그 MCP가 이미 세션에 연결된 경우에만 쓴다. 없으면 새로 설치하지 않는다 ([playwright.md](playwright.md))
 
 ## Phase 2 — 수동 개입 (옵션)
 
@@ -233,7 +232,7 @@ Tier 1 추출 폴백 전용이며 에이전트가 직접 브라우저를 다루
 
 ```bash
 # 범용 웹 (Jina Reader — 일반 HTML만, WAF 사이트엔 무효)
-curl -s "https://r.jina.ai/{URL}"
+curl -s -H "Authorization: Bearer ${JINA_API_KEY}" "https://r.jina.ai/{URL}"
 
 # yt-dlp — 1,858 사이트 미디어 메타데이터
 yt-dlp --dump-json "URL"
@@ -290,7 +289,7 @@ yt-dlp --write-sub --write-auto-sub --sub-lang "en,ko" --skip-download -o "/tmp/
 | 파일 | 언제 읽는가 | 무엇을 다루는가 |
 |------|-------------|-----------------|
 | [`tls-impersonate.md`](tls-impersonate.md) | curl_cffi 격자가 전부 `challenge`/`blocked`로 끝날 때, 새 impersonate 타겟을 `waf_profiles.yaml`에 추가할 때 | curl_cffi로 Safari/Chrome/Firefox TLS(JA3/JA4) 지문 복제하는 방법, WAF(Akamai/Cloudflare/F5 등)별 최적 타겟 조합, 임퍼소네이션 타겟 버전 목록, `tls_impersonate_avoid`의 실증 근거 |
-| [`playwright.md`](playwright.md) | engine이 Playwright fallback으로 넘어가는데 MCP/Local Chrome 중 어디로 갈지 확인 필요할 때 | Approach 1 (`mcp__playwright__*` — Cloudflare급 챌린지), Approach 2 (Local Node + `channel:'chrome'` + stealth — Akamai Bot Manager급), 템플릿 파라미터 규격 |
+| [`playwright.md`](playwright.md) | engine이 Playwright fallback으로 넘어가는데 MCP/Local Chrome 중 어디로 갈지 확인 필요할 때 | Approach 1 (이미 연결된 경우의 `mcp__playwright__*`, 없으면 omowright owned engine — Cloudflare급 챌린지), Approach 2 (Local Node + `channel:'chrome'` + stealth — Akamai Bot Manager급), 템플릿 파라미터 규격 |
 | [`fallback.md`](fallback.md) | `verdict`가 애매하거나 Phase 전환 타이밍 결정 필요할 때 | engine의 Phase 0→1→2→3 에스컬레이션 원칙, 응답 성공/실패 판정 기준 세부, 각 Phase 종료 조건 |
 | [`metadata.md`](metadata.md) | 본문 전체를 못 가져왔지만 제목·요약·가격·저자 같은 핵심만이라도 필요할 때 | OGP 메타 태그, JSON-LD (Schema.org), Twitter Card 파싱, 구조화 데이터 추출 패턴 |
 
@@ -298,7 +297,7 @@ yt-dlp --write-sub --write-auto-sub --sub-lang "en,ko" --skip-download -o "/tmp/
 
 | 파일 | 언제 읽는가 | 무엇을 다루는가 |
 |------|-------------|-----------------|
-| [`jina.md`](jina.md) | WAF 없는 일반 웹(블로그·뉴스·Wiki)의 깨끗한 마크다운 추출 필요할 때 | `r.jina.ai/URL` 한 줄로 Puppeteer 기반 JS SPA 렌더링, 마크다운 변환, 무료 500 RPM, API 키 불필요 |
+| [`jina.md`](jina.md) | WAF 없는 일반 웹(블로그·뉴스·Wiki)의 깨끗한 마크다운 추출 필요할 때 | `r.jina.ai/URL` + `JINA_API_KEY` Bearer 헤더(익명 호출은 401)로 Puppeteer 기반 JS SPA 렌더링, 마크다운 변환 |
 | [`cache-archive.md`](cache-archive.md) | 원본 사이트가 차단됐지만 과거 스냅샷으로라도 접근 필요할 때 | Wayback Machine CDX API, archive.today, AMP Cache (Google Cache는 2024-07 종료됨) |
 | [`rss.md`](rss.md) | 뉴스·블로그·커뮤니티의 시계열 업데이트를 구조화해 받고 싶을 때 | RSS/Atom 자동 발견, 피드 파싱, 인증 불필요 — 가장 깔끔한 시계열 데이터 소스 |
 

package/packages/omo-codex/plugin/skills/ultimate-browsing/references/insane-search/fallback.md

@@ -23,9 +23,12 @@
 
 ## Phase 1: 경량 프로브 (병렬)
 
+> **R1 ([README.md](README.md))**: 차단된 URL에는 WebFetch나 즉흥 curl을 쓰지 않는다. `python3 -B -m engine "<URL>"`이
+> 아래 Phase 1-3(curl_cffi 프로브, Referer/변환/디바이스 격자, 서로게이트, Playwright 폴백)을 실행한다.
+> 이 문서는 `--trace` 출력을 읽기 위한 단계 설명이다.
+
 **먼저 시도** (동시):
-- WebFetch (Claude 내장)
-- Jina Reader (기본 / JSON / SPA 모드)
+- Jina Reader (기본 / JSON / SPA 모드, `JINA_API_KEY` 있을 때만)
 - curl Chrome Desktop UA
 
 **아직 성공 없으면 추가 시도**:
@@ -34,7 +37,6 @@
 - URL 변형 시도: `.json`, `/rss`, `/feed`
 
 **사이드카** (1차와 동시, low-trust):
-- Google AMP 캐시
 - archive.today
 - Wayback Machine
 → **원본이 하나라도 성공하면 사이드카는 참고만.** 전부 실패 시에만 사이드카 채택 (provenance 태깅 필수)
@@ -90,7 +92,7 @@ for target in TARGETS:
         session = requests.Session(impersonate=target)
         session.headers.update(HEADERS)
         resp = session.get("{URL}", timeout=20)
-        if resp.status_code == 200 and len(resp.text) > 300:
+        if resp.status_code == 200 and len(resp.text) >= 3072 and not any(m in resp.text for m in ("Access Denied", "Just a moment...", "DataDome", "sec-if-cpt-container")):
             # 성공 — JSON-LD도 같이 추출
             break
     except:
@@ -103,7 +105,7 @@ for target in TARGETS:
 
 ---
 
-## Phase 3: Playwright MCP (브라우저)
+## Phase 3: 브라우저 (owned engine, 또는 이미 연결된 Playwright MCP)
 
 **조건**: Phase 2도 실패 또는 JS 챌린지/CAPTCHA 감지
 
@@ -114,7 +116,9 @@ browser_evaluate → () => document.body.innerText  (Light Mode — 먼저)
 필요 시 browser_snapshot → 접근성 트리 전체
 ```
 
-**API 발견**: `browser_network_requests`로 숨은 JSON API를 찾으면 이후 curl_cffi로 재사용 가능.
+위 흐름은 Playwright MCP가 이미 세션에 연결된 경우의 도구 이름이다. 없으면 같은 단계를 Tier 2a owned engine(js eval의 omowright `connectPipe` / `connectCloakProfile`)으로 실행한다 — [README.md](README.md) "`needs_js_exec only` 폴백 규칙".
+
+**API 발견**: `browser_network_requests`(MCP) 또는 owned engine의 `createNetworkSnoop`(the `browser` skill's `references/owned-engine/network.md`)로 숨은 JSON API를 찾으면 이후 curl_cffi로 재사용 가능.
 
 상세: [playwright.md](playwright.md)
 

package/packages/omo-codex/plugin/skills/ultimate-browsing/references/insane-search/jina.md

@@ -21,7 +21,7 @@ curl -s -H "Authorization: Bearer ${JINA_API_KEY}" "https://r.jina.ai/{URL}"
 ### JSON 구조화 출력
 
 ```bash
-curl -H "Accept: application/json" "https://r.jina.ai/{URL}"
+curl -H "Authorization: Bearer ${JINA_API_KEY}" -H "Accept: application/json" "https://r.jina.ai/{URL}"
 ```
 
 반환: `data.{title, description, url, content, metadata, external, usage}`
@@ -31,7 +31,7 @@ curl -H "Accept: application/json" "https://r.jina.ai/{URL}"
 ### CSS 선택자 타겟팅
 
 ```bash
-curl -H "X-Target-Selector: .article-body" "https://r.jina.ai/{URL}"
+curl -H "Authorization: Bearer ${JINA_API_KEY}" -H "X-Target-Selector: .article-body" "https://r.jina.ai/{URL}"
 ```
 
 네비게이션/풋터 제거, 본문만 추출. 커뮤니티 게시판에서 특히 효과적.
@@ -39,7 +39,7 @@ curl -H "X-Target-Selector: .article-body" "https://r.jina.ai/{URL}"
 ### SPA 스트리밍 모드
 
 ```bash
-curl -H "Accept: text/event-stream" "https://r.jina.ai/{URL}"
+curl -H "Authorization: Bearer ${JINA_API_KEY}" -H "Accept: text/event-stream" "https://r.jina.ai/{URL}"
 ```
 
 JS 로딩 완료까지 대기. 동적 콘텐츠가 완전히 렌더링된 최종 버전 반환.
@@ -47,7 +47,7 @@ JS 로딩 완료까지 대기. 동적 콘텐츠가 완전히 렌더링된 최종
 ### 스크린샷
 
 ```bash
-curl -H "X-Respond-With: screenshot" "https://r.jina.ai/{URL}"
+curl -H "Authorization: Bearer ${JINA_API_KEY}" -H "X-Respond-With: screenshot" "https://r.jina.ai/{URL}"
 ```
 
 GCS 서명 URL 반환 (4시간 유효). 비주얼 검증 용도.
@@ -55,7 +55,7 @@ GCS 서명 URL 반환 (4시간 유효). 비주얼 검증 용도.
 ### PDF 처리
 
 ```bash
-curl -s "https://r.jina.ai/https://example.com/file.pdf"
+curl -s -H "Authorization: Bearer ${JINA_API_KEY}" "https://r.jina.ai/https://example.com/file.pdf"
 ```
 
 PDF → 마크다운 자동 변환. 페이지 수 메타데이터 포함.
@@ -63,33 +63,33 @@ PDF → 마크다운 자동 변환. 페이지 수 메타데이터 포함.
 ### 쿠키 전달 (인증 사이트)
 
 ```bash
-curl -H "X-Set-Cookie: session=abc123" "https://r.jina.ai/{URL}"
+curl -H "Authorization: Bearer ${JINA_API_KEY}" -H "X-Set-Cookie: session=abc123" "https://r.jina.ai/{URL}"
 ```
 
 ### 링크 보존
 
 ```bash
-curl -H "X-With-Links: true" "https://r.jina.ai/{URL}"
+curl -H "Authorization: Bearer ${JINA_API_KEY}" -H "X-With-Links: true" "https://r.jina.ai/{URL}"
 ```
 
 ### 캐시 제어
 
 ```bash
 # 캐시 우회 (실시간 필요 시)
-curl -H "X-No-Cache: true" "https://r.jina.ai/{URL}"
+curl -H "Authorization: Bearer ${JINA_API_KEY}" -H "X-No-Cache: true" "https://r.jina.ai/{URL}"
 
 # 캐시 TTL 지정 (초)
-curl -H "X-Cache-Tolerance: 600" "https://r.jina.ai/{URL}"
+curl -H "Authorization: Bearer ${JINA_API_KEY}" -H "X-Cache-Tolerance: 600" "https://r.jina.ai/{URL}"
 ```
 
 ### 순수 텍스트 / 원본 HTML
 
 ```bash
 # body.innerText만
-curl -H "X-Respond-With: text" "https://r.jina.ai/{URL}"
+curl -H "Authorization: Bearer ${JINA_API_KEY}" -H "X-Respond-With: text" "https://r.jina.ai/{URL}"
 
 # 원본 HTML
-curl -H "X-Respond-With: html" "https://r.jina.ai/{URL}"
+curl -H "Authorization: Bearer ${JINA_API_KEY}" -H "X-Respond-With: html" "https://r.jina.ai/{URL}"
 ```
 
 ## 검증된 성공 사이트
@@ -131,6 +131,6 @@ curl -H "X-Respond-With: html" "https://r.jina.ai/{URL}"
 Jina JSON 모드의 `external.alternate`에서 사이트의 RSS URL이 자동 노출됨:
 
 ```bash
-curl -H "Accept: application/json" "https://r.jina.ai/{URL}" | \
+curl -H "Authorization: Bearer ${JINA_API_KEY}" -H "Accept: application/json" "https://r.jina.ai/{URL}" | \
 python3 -c "import sys,json; print(json.load(sys.stdin)['data'].get('external',{}))"
 ```

package/packages/omo-codex/plugin/skills/ultimate-browsing/references/insane-search/naver.md

@@ -26,10 +26,10 @@ Jina Reader로 완전 접근 가능.
 
 ```bash
 # 기사 목록
-curl -s "https://r.jina.ai/https://news.naver.com/"
+curl -s -H "Authorization: Bearer ${JINA_API_KEY}" "https://r.jina.ai/https://news.naver.com/"
 
 # 개별 기사
-curl -s "https://r.jina.ai/https://n.news.naver.com/article/{press_id}/{article_id}"
+curl -s -H "Authorization: Bearer ${JINA_API_KEY}" "https://r.jina.ai/https://n.news.naver.com/article/{press_id}/{article_id}"
 ```
 
 ## 네이버 증권
@@ -37,7 +37,7 @@ curl -s "https://r.jina.ai/https://n.news.naver.com/article/{press_id}/{article_
 Jina Reader로 실시간 주가, 주요 뉴스 접근.
 
 ```bash
-curl -s "https://r.jina.ai/https://finance.naver.com/item/main.naver?code={종목코드}"
+curl -s -H "Authorization: Bearer ${JINA_API_KEY}" "https://r.jina.ai/https://finance.naver.com/item/main.naver?code={종목코드}"
 ```
 
 ## 네이버 금융 시세 (비공식, 무인증)

package/packages/omo-codex/plugin/skills/ultimate-browsing/references/insane-search/playwright.md

@@ -65,7 +65,7 @@ bun install
 ### 호출 (engine 내부)
 
 ```python
-from insane_search.engine.executor import run_playwright_fallback
+from engine.executor import run_playwright_fallback   # 스킬 디렉터리에서 실행 (패키지는 engine/)
 
 attempt, html = run_playwright_fallback(
     "https://example.com/path",

package/packages/omo-codex/plugin/skills/ultimate-browsing/references/insane-search/rss.md

@@ -13,7 +13,7 @@ python3 -c "import feedparser" 2>/dev/null || pip install feedparser -q
 Jina Reader JSON 모드로 사이트의 RSS URL을 자동 탐지:
 
 ```bash
-curl -sH "Accept: application/json" "https://r.jina.ai/{URL}" | \
+curl -s -H "Authorization: Bearer ${JINA_API_KEY}" -H "Accept: application/json" "https://r.jina.ai/{URL}" | \
   python3 -c "import sys,json; print(json.load(sys.stdin)['data'].get('external',{}).get('alternate',[]))"
 ```
 

package/packages/omo-codex/plugin/skills/ultimate-browsing/references/insane-search/tls-impersonate.md

@@ -59,11 +59,11 @@ def cffi_fetch(url, locale="ko-KR"):
 
 generic alias는 항상 최신 버전으로 해석된다. **2026년에 chrome99 같은 옛 버전은 WAF가 의심하므로 generic alias 사용 권장.**
 
-| Alias | 해석 (2026.04) | 용도 |
+| Alias | 해석 (v0.15.0) | 용도 |
 |-------|---------------|------|
-| `safari` | safari260 | **한국 사이트 최적** (쿠팡, 에펨코리아) |
+| `safari` | safari2601 | **한국 사이트 최적** (쿠팡, 에펨코리아) |
 | `chrome` | chrome146 | 범용 (Cloudflare, Akamai) |
-| `firefox` | firefox135 | chrome/safari 실패 시 대안 |
+| `firefox` | firefox147 | chrome/safari 실패 시 대안 |
 | `chrome_android` | chrome131_android | 모바일 API 엔드포인트 |
 | `safari_ios` | safari260_ios | iOS 모바일 |
 
@@ -71,15 +71,20 @@ generic alias는 항상 최신 버전으로 해석된다. **2026년에 chrome99
 <summary>핀 버전 전체 (클릭)</summary>
 
 ```
+edge99, edge101,
 chrome99, chrome100, chrome101, chrome104, chrome107, chrome110,
 chrome116, chrome119, chrome120, chrome123, chrome124, chrome131,
 chrome133a, chrome136, chrome142, chrome145, chrome146,
-chrome131_android, edge99, edge101,
-safari15_3, safari15_5, safari17_0, safari17_2_ios,
-safari18_0, safari18_0_ios, safari260, safari260_ios,
-firefox133, firefox135
+chrome99_android, chrome131_android,
+safari153, safari155, safari170, safari172_ios,
+safari180, safari180_ios, safari184, safari184_ios,
+safari260, safari2601, safari260_ios,
+firefox133, firefox135, firefox144, firefox147,
+tor145
 ```
 
+구 표기(`safari15_3`, `safari15_5`, `safari17_0`, `safari17_2_ios`, `safari18_0`, `safari18_0_ios`, `safari18_4`, `safari18_4_ios`)는 deprecated alias로 아직 받는다.
+
 </details>
 
 ## WAF별 최적 전략

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

@@ -119,6 +119,8 @@ Before the first task command, create one `RUN_TMP=$(mktemp -d)` per task, track
 At task end, after owned processes exit, remove only owned directories, including runtime caches. Never wipe shared caches; retain worktrees still needed by open PRs and any parent directory containing them.
 
 ## 0. Survey the skills, gather context, then size the work
+This section records into the notepad, so run section 2's `NOTE=`
+command first; section 2 then initialises that same file.
 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

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

@@ -32,6 +32,8 @@ For work likely to exceed one wait cycle, require the child to send `WORKING: <t
 
 **YOU DO NOT WRITE CODE. YOU DO NOT EDIT PRODUCT FILES. YOU DO NOT RUN QA YOURSELF. EVERY unit of implementation, test, QA, and review work MUST be delegated to a spawned subagent. NO EXCEPTIONS.** Your hands touch only plan selection, `.omo/` state (Boulder, ledger, plan checkboxes), decomposition, dispatch, verdicts, and evidence records. About to edit a product file or run an implementation command yourself? **STOP. SPAWN A WORKER INSTEAD.** Orchestrate at **MAXIMUM PARALLELISM**: every independent unit runs concurrently; only named dependencies serialize.
 
+This rule binds the root of a ulw-execute run: a worker runs every implementation and per-task QA scenario, and you judge the artifacts it captured. The Codex edition's one exception is the final verification in the Completion section below, where the root runs its own manual QA on the real surface and records a self-review. Outside a ulw-execute run (a bare ultrawork run, a ulw-loop final gate, a standalone `review-work`), the session that owns the run runs the final real-surface QA itself.
+
 ### Codex tier mapping for the delegation router
 When tier worker agents are installed, map the delegation router's parenthesized difficulty to `agent_type`: (low) -> `lazycodex-worker-low`; (medium) -> `lazycodex-worker-medium`; (high) -> `lazycodex-worker-high`. Explorer/librarian research lanes keep their own roles. On spawn surfaces without `agent_type`, state the tier inside `message`. Difficulty (model power) is orthogonal to the LIGHT/HEAVY rigor tier in step 4 — judge each on its own facts.
 
@@ -112,7 +114,7 @@ Every phase (plan wave) runs in its own task-owned worktree with its own goal: b
 Solo orchestration with parallel background workers is the default topology. Decide once, when the wave's lanes are known, and record the verdict in the ledger:
 
 - **Independent lanes -> parallel workers.** Separate files, no shared contract: one parallel spawn burst; no team.
-- **Dependency-ordered lanes -> one `workflow` run per wave.** Sub-tasks with real ordering between them (C needs A and B finished first) and a harness with a native `workflow` tool: dispatch the wave as ONE run (one producer node per lane plus a verification node); recover inside it with `retry`/`amend`/`send`; let the run's settle wake you instead of arming per-lane watchers; the next wave is a NEW run (or `amend` when only the definition changed) — never one graph for the whole plan. When the harness lists the `mass-ulw` skill, read its `SKILL.md` and `references/planning.md` IN FULL before defining any graph.
+- **Dependency-ordered lanes -> one `workflow` run per wave.** Sub-tasks with real ordering between them (C needs A and B finished first) and a harness with a native `workflow` tool: dispatch the wave as ONE run (one producer node per lane plus a verification node); recover inside it with `retry`/`amend`/`send`; let the run's settle wake you instead of arming per-lane watchers; the next wave is a NEW run (use `amend` only to re-run the current wave after its definition changed) — never one graph for the whole plan. When the harness lists the `mass-ulw` skill, read its `SKILL.md` and `references/planning.md` IN FULL before defining any graph.
 - **Overlapping lanes -> a team.** The lanes touch the same module or contract AND running them concurrently actually finishes sooner: stand up a team (where the harness has one) so one lane's discoveries relay through you mid-flight.
 - **PR-mode independent lanes -> a worktree per lane.** Under `--make-pr`/`--ship`, when a wave holds independent checkboxes, give each lane its own branch and task-owned worktree, delivered as its own PR.
 
@@ -152,7 +154,6 @@ When the plan annotates a todo with `Recommended task executor category:`, follo
 | `unspecified-high` (medium) | standard features across a few files with known patterns |
 | `visual-engineering` (medium) | frontend, UI/UX, styling, animation |
 | `writing` (low) | documentation and prose |
-| `git` (low) | git operations |
 | `deep-low` (medium) | hairy debugging, research-heavy or subtle cross-module work the worker can settle from what it reads |
 | `deep-high` (high) | the same, when the central decision cannot be settled from evidence: a trade-off, a cross-package contract, or correctness argued from invariants |
 | `ultrabrain` (high) | ONE genuinely hard, logic-heavy problem — hand it the goal, not step-by-step instructions |
@@ -162,6 +163,8 @@ Sizing is a two-branch decision made per checkbox, before dispatch:
 - **Splittable work splits.** When the checkbox decomposes into independent pieces, dispatch them as a swarm of `quick`/`unspecified-low` workers in ONE parallel burst — many small cheap workers in parallel beat one large delegation.
 - **Cohesive hard work stays whole.** When splitting would sever shared reasoning (one algorithm, one migration, one subtle bug), send the WHOLE problem to `deep-low`, `deep-high` or `ultrabrain` as ONE delegation. Never force-split work whose parts share one insight.
 
+Git operations are not a category: route them to a `quick` worker and name the `git-master` skill in its brief (`load_skills` where the spawn tool takes it).
+
 Each sub-task message must include:
 
 1. Goal and exact files or directories in scope.
@@ -173,7 +176,7 @@ Each sub-task message must include:
    - Terminal / TUI: drive a real pty; `tmux send-keys` is fine for a boot/behavior smoke, but color/layout/CJK evidence goes through the xterm.js web terminal below, NEVER `tmux capture-pane`.
    - Browser use: omowright from js eval (staged in the `browser` skill) — the owned engine (`connectPipe` on a task-owned profile, `connectCloakProfile` for bot-scored targets) for unauthenticated pages, the attached engine (`connectBrowserSkill()` in the user's signed-in browser) when the page needs their login; never a clone of or a launch against the live profile.
    - Computer use: OS-level GUI automation against the running desktop app when the surface is not a page.
-   - TUI visual evidence: when a TUI claim needs visual QA or PR proof, run `bun script/qa/web-terminal-visual-qa.mjs --command "<cmd>" --input "{Enter}" --evidence-dir <dir>` (real pty rendered through xterm.js in Chrome) and attach `terminal.png` plus `metadata.json`.
+   - TUI visual evidence: when a TUI claim needs visual QA or PR proof, run `bun script/qa/web-terminal-visual-qa.mjs --title "<surface>" --command "<cmd>" --input "{Enter}" --evidence-dir <dir>` (real pty rendered through xterm.js in Chrome) and attach `terminal.png` plus `metadata.json`.
 6. The adversarial classes that apply to this sub-task (from the 9 ultraqa classes) and how each is probed.
 7. Required artifact path and cleanup receipt.
 8. Tool-use expectations: batch independent tool calls in parallel; when the harness exposes a code-execution surface (eval), use it for multi-call steps instead of one-by-one calls.
@@ -218,10 +221,10 @@ A worker done claim is never final: each implementation sub-task returns a `Done
 
 Rules:
 - `confirmed` is the only pass verdict. `false-positive`, `needs-fix`, and `needs-human-review` all block checkbox completion.
-- The verifier must be independent from the executor: use the harness's gate reviewer (see the harness compatibility section) or a fresh reviewer worker on a strong model, or root only when root did not implement or materially rewrite that task.
+- The verifier must be independent from the executor: use the harness's gate reviewer (see the harness compatibility section) or a fresh reviewer worker on a strong model. Root never verifies; it records the verifier's verdict.
 - A worker done claim must be independently verified before it becomes checkbox completion.
 - On a non-confirmed verdict, append the feedback to the ledger with the attempt number and its failure signature (the failing check plus its first error line, with volatile values stripped: temp-dir paths, timestamps, process and run ids, durations). Attempts count per checkbox across all its sub-tasks and re-splits, timed from its first dispatch (`checkpoint_opened_at`). STOP when the same signature repeats on consecutive attempts, on the third failed attempt, or 4 hours after the first dispatch (a plan may change these numbers, never remove the stop). Check the 4-hour bound also when a lane's watcher fires or the turn resumes without a verdict; when it has passed, cancel that lane and stop the same way: mark the checkbox `- [~]` (the plan grammar's blocked state) with a one-line gap naming what is unmet and the last evidence, mark every checkbox that depends on it, directly or through another `[~]` row, `- [~]` with the gap `blocked by <id>`, close the todo of every row marked `[~]` here labelled `blocked: <gap>`, append an `unmet` ledger entry listing what each attempt changed, and continue in the same turn with the next checkpoint that depends on none of them, or with Completion when none remains. Otherwise leave the checkbox `- [ ]` and re-dispatch the executor with the exact failure.
-- A `[~]` row counts as closed, never as a met dependency: Phase 3 skips it, Completion starts once every top-level row is `[x]` or `[~]`, and the `ORCHESTRATION COMPLETE` block names each `[~]` row with its gap. Final Verification Wave rows are never dependents of a `[~]` row: they verify the landed work and report each `[~]` row as a known gap, which alone never fails a final-wave row. A `[~]` gap is never re-queued as a new checkbox in this run, by the blast-radius rule or by a final-wave verdict; the one harness-repair follow-up in the next rule is the only exception.
+- A `[~]` row counts as closed, never as a met dependency: Phase 3 skips it, Completion starts once every top-level row is `[x]` or `[~]`, and the `ORCHESTRATION COMPLETE` block names each `[~]` row with its gap; a block with any `[~]` row is a partial-delivery report, never a success claim, and the run's goal is reported unmet. Final Verification Wave rows are never dependents of a `[~]` row: they verify the landed work and report each `[~]` row as a known gap, which alone never fails a final-wave row. A `[~]` gap is never re-queued as a new checkbox in this run, by the blast-radius rule or by a final-wave verdict; the one harness-repair follow-up in the next rule is the only exception.
 - The verifier sets `failure_class`. A `harness` failure (the runner, fixture, CI job or environment failed and the product behavior was never exercised) gets one repair dispatch inside the checkpoint, which does not count as an attempt; when it recurs, stop as above with the harness gap named and append the harness repair once as a follow-up checkbox; a harness-repair follow-up that stops is reported, not re-appended.
 - The verifier must probe the applicable adversarial keys, including `stale_state`, `dirty_worktree`, and `misleading_success_output`, before allowing `FullyDone`.
 
@@ -241,7 +244,7 @@ When all top-level checkboxes in `## TODOs` and `## Final Verification Wave` are
 1. Run the plan's final verification commands.
 2. Record a self-review in the notepad: re-read the diff, run diagnostics, and capture evidence for every acceptance criterion. Run your own manual QA on the real surface.
 3. Only when the user demanded strict, rigorous, or high-accuracy review, spawn ONE `lazycodex-gate-reviewer`; otherwise your self-review is the final verification.
-4. Finish the PR/branch lifecycle from its task-owned worktree: sync `.omo/` state back to the main repo, create or update the PR, wait for review/verification gates, merge by default unless explicitly opted out, and remove the worktree only after successful merge or explicit handoff. Finish directory teardown per Task resources and record its receipts.
+4. Finish the PR/branch lifecycle from its task-owned worktree: sync `.omo/` state back to the main repo, create or update the PR, wait for review/verification gates; `--ship` merges per the repository's merge policy, `--make-pr` hands off with the PR URL and merges only if the user asks; remove the worktree only after a successful merge or that explicit handoff. Finish directory teardown per Task resources and record its receipts.
 5. Remove or mark the Boulder work as completed.
 6. Print an `ORCHESTRATION COMPLETE` block with the plan path, verification commands, artifacts, and cleanup receipts.
 

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

@@ -69,7 +69,7 @@ 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.
+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, keep it in this session - delegating only the code edits, test writes, fixes, and QA executions the rule above requires. 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:
 

package/packages/omo-codex/plugin/skills/ulw-loop/references/define-goal.md

@@ -87,7 +87,7 @@ Repaired: "Resolve every open change-requesting review comment on PR 123 touchin
 | an active goal conflicting with this intent | Stop and surface the conflict; the user decides whether to finish it, complete it, or branch. |
 
 2. Goals are unlimited. Never invent a numeric budget, token limit, or deadline the user did not state — that ban covers run quotas; the `assumed:` work constraints from Objective anatomy #4 are different and required.
-3. In a ulw-loop run, the loop CLI owns per-goal state (`.omo/ulw-loop/goals.json`): `create_goal` registers the aggregate objective from the printed handoff, and this reference shapes both that objective and every goal's `successCriteria` at `create-goals` time.
+3. In a ulw-loop run, the loop SDK owns per-goal state (`.omo/ulw-loop/<session-id>/goals.json`): `create_goal` registers the aggregate objective from the handoff create-goals returns, and this reference shapes both that objective and every goal's `successCriteria` at `create-goals` time.
 
 ## Completion honesty
 

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

@@ -10,7 +10,7 @@ Expert goal orchestration agent. You conduct; right-sized subagents play. Plan d
 Use GPT-5.x style: outcome-first, evidence-bound, atomic decisions, no nested branching prose.
 
 ## Goal
-Deliver every goal in `.omo/ulw-loop/goals.json` end-to-end.
+Deliver every goal in `.omo/ulw-loop/<session-id>/goals.json` end-to-end.
 Prove EVERY success criterion with captured observable evidence from a real-usage scenario you ran (HTTP / tmux / browser / computer-use below).
 TESTS ALONE NEVER PROVE DONE. A green test suite is supporting evidence, not completion proof.
 Audit each pass, fail, block, steering change, and checkpoint in `.omo/ulw-loop/<session-id>/ledger.jsonl`.
@@ -24,8 +24,8 @@ Run each criterion's real-surface proof yourself through the channel that faithf
 4. **Computer use** — for desktop/GUI apps, drive the running app via OS automation (computer-use, AppleScript, xdotool, etc.); capture action log + screenshot.
 
 For TUI visual QA (mandatory when a PR or review must inspect the terminal screen),
-run `node script/qa/web-terminal-visual-qa.mjs --command "<cmd>" --input "{Enter}"
---evidence-dir <dir>` (live pty + xterm.js in Chrome; `--from-file` replays a raw
+run `node script/qa/web-terminal-visual-qa.mjs --title "<surface>" --command "<cmd>"
+--input "{Enter}" --evidence-dir <dir>` (live pty + xterm.js in Chrome; `--from-file` replays a raw
 stream) and record `terminal.png`, `terminal.txt`, and `metadata.json`.
 
 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.
@@ -62,9 +62,9 @@ Codex subagent reliability:
 - Fallback only when the child is completed without the deliverable, ack-only after `followup_task`, explicitly `BLOCKED:`, or no longer running. Then send `TASK STILL ACTIVE: return <deliverable> or BLOCKED: <reason>` via `followup_task` when it can still recover the lane; otherwise record inconclusive, do not count it as pass/review approval, stop it if safe, and respawn a smaller `fork_turns: "none"` task with the missing deliverable.
 
 ## Artifacts
-- `.omo/ulw-loop/brief.md`: original brief and durable constraints.
-- `.omo/ulw-loop/goals.json`: goals with embedded `successCriteria` per goal.
-- `.omo/ulw-loop/ledger.jsonl`: append-only audit trail.
+- `.omo/ulw-loop/<session-id>/brief.md`: original brief and durable constraints.
+- `.omo/ulw-loop/<session-id>/goals.json`: goals with embedded `successCriteria` per goal.
+- `.omo/ulw-loop/<session-id>/ledger.jsonl`: append-only audit trail.
 - Read artifacts before resuming, steering, or checkpointing.
 - After compaction or context loss, re-read brief + goals + ledger FIRST, then `omo-agent-toolkit ulw-loop status --json`. Recover from artifacts; never re-plan from scratch or repeat completed work.
 - Never invent state outside `.omo/ulw-loop` artifacts or `omo-agent-toolkit ulw-loop status --json`.
@@ -152,7 +152,7 @@ Loop per goal. Cap at 5 cycles per goal. Cap identical same-criterion failures a
 
 | get_goal result | action |
 |-----------------|--------|
-| no active goal | You MUST call `create_goal` — goal registration goes through the tool, never prose — with objective only from `instruction.json.objective`; do not copy lifecycle fields such as `status`. |
+| no active goal | You MUST call `create_goal` — goal registration goes through the tool, never prose — with objective only from the handoff's rendered `create_goal` payload; do not copy lifecycle fields such as `status`. |
 | same aggregate objective active | Continue the current ulw-loop story. |
 | different goal active | STOP. Checkpoint blocked and surface the conflict. |
 4. If retrying failed work, run `omo-agent-toolkit ulw-loop complete-goals --retry-failed --json`.
@@ -190,11 +190,11 @@ omo-agent-toolkit ulw-loop status --json
 # Read nextActions and currentAttemptDir.
 omo-agent-toolkit ulw-loop record-evidence --goal-id <g> --criterion-id <c> --status pass --evidence "..."
 # Repeat record-evidence once per criterion.
-# Then use the harness update_goal tool with status complete.
 omo-agent-toolkit ulw-loop checkpoint --goal-id <g> --print-template --json
 # Fill the printed template: replace every placeholder and use real artifact paths under currentAttemptDir.
 # codex-goal-json.goal.objective must equal the plan's codexObjective verbatim.
 omo-agent-toolkit ulw-loop checkpoint --goal-id <g> --status complete --evidence "..." --codex-goal-json <path> --quality-gate-json <path>
+# Only after that gated checkpoint succeeds, use the harness update_goal tool with status complete.
 omo-agent-toolkit ulw-loop complete-goals
 ```
 
@@ -206,7 +206,7 @@ Trigger only for the final aggregate goal after every criterion in every goal is
 2. FREEZE first — no more edits or rebases. At the frozen HEAD, re-run Manual-QA for any PASS criterion whose stamped tree differs from `git rev-parse --short "HEAD^{tree}"`, so every criterion is proven on the frozen tree; each artifact exists and is non-empty.
 3a. Spawn lazycodex-code-reviewer and lazycodex-qa-executor in parallel (`fork_context: false` on v1; `fork_turns: "none"` on v2) with brief, goals, desired outcome, diff, evidence; wait for BOTH and confirm their report artifacts exist on disk.
 3b. Only then spawn lazycodex-gate-reviewer with those artifact paths.
-3c. The gate's approval binds to the frozen tree and full commit SHA and covers its three lanes — code quality, hands-on QA, and goal verification. Immediately append one durable `.omo/ulw-loop/ledger.jsonl` record per passing lane with the lane name, full SHA, verdict, and report artifact/source. Before reuse after continuation or compaction, re-read the ledger and require the exact lane/SHA pair; memory or an unstamped report is not coverage. A later rebase or amend that keeps the tree identical still has a new SHA and needs fresh lane stamps; changed content needs fresh review of the delta.
+3c. The gate's approval binds to the frozen tree and full commit SHA and covers its three lanes — code quality, hands-on QA, and goal verification. Immediately append one durable `.omo/ulw-loop/<session-id>/ledger.jsonl` record per passing lane with the lane name, full SHA, verdict, and report artifact/source. Before reuse after continuation or compaction, re-read the ledger and require the exact lane/SHA pair; memory or an unstamped report is not coverage. A later rebase or amend that keeps the tree identical still has a new SHA and needs fresh lane stamps; changed content needs fresh review of the delta.
 4. Treat timeout, missing deliverable, ack-only, `BLOCKED:`, or inconclusive review as a blocker. Any fix restarts the freeze at the new HEAD: re-run ONLY the proofs it invalidated and stamp the fresh output — never regenerate all evidence or relabel stale output to HEAD — re-review the delta at most TWICE; then record-review-blockers (step 5) and surface to the user.
 5. If review remains blocked, run `omo-agent-toolkit ulw-loop record-review-blockers --goal-id <id> --title "<...>" --objective "<...>" --evidence "<review findings>" --codex-goal-json <snapshot> --json`.
 6. If clean, checkpoint final completion:
@@ -251,7 +251,7 @@ Structured prompt directives accepted: `OMO_ULW_LOOP_STEER: { ... }`, `omo.ulw-l
 3. Evidence is bound to the tree it was captured at; changed tracked content invalidates it — re-run the QA at the current HEAD and re-record (an identical tree after rebase/amend stays valid). NEVER mark PASS from memory, and NEVER relabel, pin, refresh, or regenerate prior output to a moved HEAD.
 4. NEVER bypass the criteria gate: non-final aggregate completion requires all essential criteria; final aggregate completion requires all criteria across the whole plan.
 5. Baseline build/lint/typecheck/test commands are necessary evidence, NOT SUFFICIENT completion proof. Criteria coverage with observable evidence is the gate.
-6. Treat `.omo/ulw-loop/ledger.jsonl` as the durable audit trail; checkpoint after every success or failure.
+6. Treat `.omo/ulw-loop/<session-id>/ledger.jsonl` as the durable audit trail; checkpoint after every success or failure.
 7. Per-story Codex goal mode is opt-in only with `--codex-goal-mode per-story`; default is aggregate.
 8. Structured steering directives mutate state through validation; normal prose does not.
 9. Evidence MUST be observable from the real surface per the Manual-QA channel table — never a printed command, `--dry-run`, or "looks correct".

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

@@ -180,7 +180,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 `$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).
+6. **Execution handoff** - the plan runs in a worker session via `$ulw-execute <plan-name>`; introduce the options: `--worktree <absolute-path>` (optional: reuse an existing task-owned worktree for the first phase; every phase runs in its own task-owned worktree regardless), `--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 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/packages/omo-codex/plugin/skills/ulw-plan/references/intent-unclear.md

@@ -10,7 +10,7 @@ metadata:
 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.
+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 an owner-decision as SKILL.md's two filters define it (irreversible, destructive, or safety-critical, or a cross-cutting product choice the user lives with) - then exactly one focused question per decision. 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.
 </stance>
 
 <research_protocol>
@@ -20,7 +20,7 @@ TOPOLOGY LOCK still applies: enumerate the 1-6 independently-succeed/fail compon
 </research_protocol>
 
 <default_selection>
-For each open decision - including the extrinsic axes the sweep names (budget, mandated stack, expected scale, target audience / compliance) - adopt the default the ideal state for the affected user demands (industry standard and repo convention are evidence for it, never the default itself), RECORD it in the draft's Open-assumptions ledger with rationale and reversibility, and proceed. NO numeric scoring - the ledger IS the audit trail. The ONLY default escalated to a single focused question is one that is irreversible, destructive, or safety-critical, or commits real spend the user never authorized, and research cannot settle.
+For each open decision - including the extrinsic axes the sweep names (budget, mandated stack, expected scale, target audience / compliance) - adopt the default the ideal state for the affected user demands (industry standard and repo convention are evidence for it, never the default itself), RECORD it in the draft's Open-assumptions ledger with rationale and reversibility, and proceed. NO numeric scoring - the ledger IS the audit trail. The ONLY default escalated to a single focused question is an owner-decision as SKILL.md's two filters define it - anything irreversible / destructive / safety-critical, or a cross-cutting product choice the user lives with (public config surface, distribution / packaging, external dependency or pinned SHA, data / schema shape, real budget / paid-service spend, expected scale or capacity target, target-audience / compliance limits) - which survives as a question even when a default exists.
 
 Fold a contrarian self-grill into the Metis spawn: challenge the single highest-leverage adopted assumption - is this constraint real or habitual; does any adopted default add complexity the request never asked for? - and return concrete reframes. The grill targets incidental complexity (unneeded abstraction, speculative capacity), NEVER the feature set: reducing, phasing, or deferring part of the request is not a reframe. Fold a reframe into the plan only as a recommended default plus rationale, never as a forced change.
 </default_selection>

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

@@ -57,7 +57,7 @@ The research is done when all of these hold:
 - Every claim in the deliverable cites a source or a verification artifact.
 - Every asserted claim is represented in the claim graph, tied to an intent-vs-reality diff when an expected truth exists, and backed by observation manifest entries from independent observation groups or a documented single-source exception; convergence or exception status is explicit.
 - The deliverable lane and format were derived from the destination or asked through the empty-info interview without blocking collection, recorded in `brief.md` with `answered_by`, and the final materials match that record.
-- The delivered artifact passed the delivery gates in order (static gates, layout gates, fidelity gate, visual QA, and the proofread pass where the harness provides one), each status is in `outcome.json`, and `outcome verify` passed.
+- The delivered artifact passed the delivery gates in order (static gates, fidelity gate, layout gates, visual QA, and the proofread pass where the harness provides one), each status is in `outcome.json`, and `outcome verify` passed.
 - Every excursion opened during the run was closed by an EXIT rule, folded back into the claim or axis that triggered it, and recorded in both `excursion-log.md` and the ulw-loop ledger.
 - When the harness can show an HTML page inline, the report was shown inline before the artifact paths.
 - When the ask reproduces a visual source, the report carries side-by-side pairs of real source frames and the output rendered at the same moments, each with its critique, and the differences they surfaced were fixed or listed as gaps. A simple or well-understood topic shortens the research, never this comparison.
@@ -142,7 +142,7 @@ The promised formats recorded in `brief.md` and `outcome.json` are binding; `pdf
 
 Asset workers (background, parallel, each fed `design-spec.md`) — visuals are the DEFAULT deliverable of this phase, not garnish the user must ask for; a delivered report without figures is an incomplete run:
 
-- **Charts for every quantitative finding, computed from real data.** Pull the numbers into an actual table first (CSV/JSON under `$SESSION_DIR`), then plot from that table, never from prose. Follow the data-scientist tool doctrine — numpy always, Polars for filtering/sorting/transforms, DuckDB for joins/aggregations/window functions, never pandas — and load the `data-scientist` skill when this session has it: `uv run --with numpy --with polars --with duckdb --with pyarrow --with matplotlib python`. Keep `pyarrow` in that set — the DuckDB-to-Polars handoff (`.pl()`) fails without it, and `.df()` fails without pandas, so hand data across through `.pl()`, never `.df()`. Save to `$SESSION_DIR/assets/`. Plot ONLY from the ledger: export the rows with `node "$SKILL_DIR/scripts/report-tools.mjs" fact export --csv --out "$SESSION_DIR/assets/<chart>.csv" --session-dir "$SESSION_DIR"` and draw from that CSV; every chart figure carries `data-chart-source="assets/<chart>.csv"`, and its axis tick labels sit inside a `<g class="ticks" data-tick-step=".." data-tick-min=".." data-tick-max="..">` group, so the fidelity gate can check every plotted value and tick (the deliverable reference's section 6 tick rule).
+- **Charts for every quantitative finding, computed from real data.** Pull the numbers into an actual table first (CSV/JSON under `$SESSION_DIR`), then plot from that table, never from prose. Follow the data-scientist tool doctrine — numpy for numeric work beyond SQL/DataFrame aggregation, Polars for filtering/sorting/transforms, DuckDB for joins/aggregations/window functions, never pandas — and load the `data-scientist` skill when this session has it: `uv run --with numpy --with polars --with duckdb --with pyarrow --with matplotlib python`. Keep `pyarrow` in that set — the DuckDB-to-Polars handoff (`.pl()`) fails without it, and `.df()` fails without pandas, so hand data across through `.pl()`, never `.df()`. Save to `$SESSION_DIR/assets/`. Plot ONLY from the ledger: export the rows with `node "$SKILL_DIR/scripts/report-tools.mjs" fact export --csv --out "$SESSION_DIR/assets/<chart>.csv" --session-dir "$SESSION_DIR"` and draw from that CSV; every chart figure carries `data-chart-source="assets/<chart>.csv"`, and its axis tick labels sit inside a `<g class="ticks" data-tick-step=".." data-tick-min=".." data-tick-max="..">` group, so the fidelity gate can check every plotted value and tick (the deliverable reference's section 6 tick rule).
 - **Mermaid graphs** for process, architecture, argument, timeline, and evidence-flow structure, themed to the spec's fonts and palette. Render each to SVG and confirm the file exists before the document references it.
 - **Generated visuals through the imagegen skill whenever the session has it:** a cover plus a concept illustration per major theme, prompted from the spec's style, palette, and mood — document-styled illustration, never generic stock art dropped into a designed page.
 - **Full-page screenshots** of the top 5-10 sources, saved by the web workers while reading, as provenance you can show.