lazycodex-ai 5.1.62 → 5.1.64

package/packages/shared-skills/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/shared-skills/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/shared-skills/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/shared-skills/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/shared-skills/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/shared-skills/skills/ulw-execute/SKILL.md

@@ -8,6 +8,8 @@ argument-hint: "[plan-name] [--worktree <absolute-path>] [--make-pr] [--ship]"
 
 **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, including its Final Verification Wave and any `review-work` pass run inside it: a worker runs every QA scenario, and you judge the artifacts it captured. 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 Harness Tool Compatibility
 
 Translate any OpenCode-only tool name in an inherited example to its Codex equivalent:
@@ -103,7 +105,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.
 
@@ -143,7 +145,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 |
@@ -153,6 +154,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.
@@ -164,7 +167,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.
@@ -209,10 +212,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`.
 
@@ -230,7 +233,7 @@ Only after verification passes:
 When all top-level checkboxes in `## TODOs` and `## Final Verification Wave` are complete:
 
 1. Run the plan's final verification commands.
-2. For PR/branch work, finish the lifecycle from the last phase's 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.
+2. Under `--make-pr` or `--ship`, finish the lifecycle from the last phase's worktree: sync `.omo/` state back to the main repo, create or update the PR, and wait for review/verification gates. Then follow the delivery mode: `--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.
 3. Remove or mark the Boulder work as completed.
 4. Print an `ORCHESTRATION COMPLETE` block with the plan path, verification commands, artifacts, and cleanup receipts.
 

package/packages/shared-skills/skills/ulw-plan/references/full-workflow.md

@@ -181,7 +181,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 Oracle review via `task(subagent_type="oracle", ...)` on the strongest available reasoning model, in a fully isolated sub-session with normal approval and sandbox policy. Do not add flags that disable approvals or sandboxing. Momus runs at High and may take substantially longer than other agents. One round = exactly ONE `momus` + ONE independent review, dispatched together against the COMPLETE plan file (todos + TL;DR filled) at the draft's exact recorded `plan_path`. Keep Momus in flight and wait for its terminal result: elapsed time alone never justifies cancelling, duplicating, replacing, or treating it as failed. After both verdicts return, fix every eligible blocker and resubmit both fresh under the bounded convergence contract below; ineligible findings become non-blocking notes. CLEAR: runs when the user opts in or `review_required: true`. UNCLEAR: runs automatically unless Classify=Trivial.

package/packages/shared-skills/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/shared-skills/skills/ulw-research/SKILL.md

@@ -55,7 +55,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.
@@ -140,7 +140,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.
@@ -175,7 +175,7 @@ Next, write `$SESSION_DIR/pairs-strong.json` (the same file, keeping only the pa
 
 3. **Layout gates.** Print the probe with `node "$SKILL_DIR/scripts/report-tools.mjs" layout-probe --json`, evaluate its `source` in the rendered page through the `browser` skill's owned headless engine, save the result as `$SESSION_DIR/boxes.json`, and re-run `check` with `--layout "$SESSION_DIR/boxes.json"` (overflow, clipped text, distorted images, overlapping siblings).
 4. **Visual QA.** Render the produced artifact back to images — PDF pages to PNG, the HTML through the browser skill at desktop and phone widths — and look at them: missing or broken figures, images stretched or spilling their containers, diagram or chart text rendered off the spec's font or palette, clipped tables, overflowing CJK text, blank pages, unlabeled chart values, wrong page breaks. Reading the source markup is not visual QA; inspect the pixels.
-5. **Proofread gate: `task(category="writing", ...)`.** Hand the final text to a dedicated `writing` worker whose only job is language: grammar, spelling, punctuation, terminology consistency, and whether the prose reads NATIVELY in the report's own language. It proofreads only and never composes, and it never edits the file: it returns `$SESSION_DIR/polish-edits.json`, an array of `{"before": ..., "after": ..., "reason": ...}` where `before` is the exact current text of one or more adjacent sentences. Edits change text only; an edit whose before/after would alter any tag, attribute, comment, or script/style content is rejected, and markup changes go through the full fidelity gates instead. Apply it with `node "$SKILL_DIR/scripts/report-tools.mjs" fact polish-apply "$SESSION_DIR/report.html" --edits "$SESSION_DIR/polish-edits.json" --out "$SESSION_DIR/report.polished.html" --session-dir "$SESSION_DIR"`: each edit is applied alone, and an edit that changes a fact span, a numeral, a link, or a claim id, or drops a hedge or qualifier the source carries, is `polish_edit_rejected` (a `before` not found exactly once is `polish_edit_unlocated`) and leaves its text unchanged. Send the rejected and unlocated edits back to the same worker with their reasons, plus `$SESSION_DIR/polish-defects.json` and the pre-polish `report.html` the backstop compared against, so the worker sees why each edit was refused; it returns either a rewritten sentence or a new edit list, and the repair round re-runs `fact polish-apply` with `"$SESSION_DIR/report.polished.html"` as both input and output, within the repair budget. Then run the backstop `fact polish-diff --before "$SESSION_DIR/report.html" --after "$SESSION_DIR/report.polished.html" --session-dir "$SESSION_DIR"` (exit `1` on `polish_diff_fail`), `fact verify` on `report.polished.html`, and `fact pairs "$SESSION_DIR/report.polished.html" --changed-since "$SESSION_DIR/report.html.fill-map.json" --session-dir "$SESSION_DIR"`, which keeps only the quote and claim pairs whose sentence text changed during polish; run the meaning readers above (cheap, then strong on the flagged pairs) on exactly those pairs and `fact meaning-check` before recording `outcome gate fidelity`. A rewording that keeps every number, hedge, qualifier, and link but swaps who did what to whom therefore still reaches a meaning reader on the delivered text. `report.polished.html` is the report that is delivered. Deliver only on a clean pass. This gate runs BEFORE the first delivery, not after the user finds the typo. Edits must not span entities (such as &amp; or &lt;) or markup; narrow the edit to the surrounding words instead, and a rejected edit comes back with the reason to act on.
+5. **Proofread gate: `task(category="writing", ...)`.** Hand the final text to a dedicated `writing` worker whose only job is language: grammar, spelling, punctuation, terminology consistency, and whether the prose reads NATIVELY in the report's own language. It proofreads only and never composes, and it never edits the file: it returns `$SESSION_DIR/polish-edits.json`, an array of `{"before": ..., "after": ..., "reason": ...}` where `before` is the exact current text of one or more adjacent sentences. Edits change text only; an edit whose before/after would alter any tag, attribute, comment, or script/style content is rejected, and markup changes go through the full fidelity gates instead. Apply it with `node "$SKILL_DIR/scripts/report-tools.mjs" fact polish-apply "$SESSION_DIR/report.html" --edits "$SESSION_DIR/polish-edits.json" --out "$SESSION_DIR/report.polished.html" --session-dir "$SESSION_DIR"`: each edit is applied alone, and an edit that changes a fact span, a numeral, a link, or a claim id, or drops a hedge or qualifier the source carries, is `polish_edit_rejected` (a `before` not found exactly once is `polish_edit_unlocated`) and leaves its text unchanged. Send the rejected and unlocated edits back to the same worker with their reasons, plus `$SESSION_DIR/polish-defects.json` and the pre-polish `report.html` the backstop compared against, so the worker sees why each edit was refused; it returns either a rewritten sentence or a new edit list, and the repair round re-runs `fact polish-apply` with `"$SESSION_DIR/report.polished.html"` as both input and output, within the repair budget. Then run the backstop `fact polish-diff --before "$SESSION_DIR/report.html" --after "$SESSION_DIR/report.polished.html" --session-dir "$SESSION_DIR"` (exit `1` on `polish_diff_fail`), `fact verify` on `report.polished.html`, and `fact pairs "$SESSION_DIR/report.polished.html" --changed-since "$SESSION_DIR/report.html.fill-map.json" --session-dir "$SESSION_DIR"`, which keeps only the quote and claim pairs whose sentence text changed during polish; run the meaning readers above (cheap, then strong on the flagged pairs) on exactly those pairs and `fact meaning-check` before recording `outcome gate fidelity`. A rewording that keeps every number, hedge, qualifier, and link but swaps who did what to whom therefore still reaches a meaning reader on the delivered text. `report.polished.html` is the report that is delivered; polish can change line wrapping, so re-run the layout gates and visual QA on `report.polished.html` and record `layout` and `visual` again. Deliver only on a clean pass. This gate runs BEFORE the first delivery, not after the user finds the typo. Edits must not span entities (such as &amp; or &lt;) or markup; narrow the edit to the surrounding words instead, and a rejected edit comes back with the reason to act on.
 
 **Repair is bounded.** After every gate run that found defects, ask `node "$SKILL_DIR/scripts/report-tools.mjs" repair decide --state "$SESSION_DIR/repair-state.json" --defects "$SESSION_DIR/defects.json" --defects "$SESSION_DIR/fidelity-defects.json" --artifact-bytes <bytes> --renders <pages> --session-dir "$SESSION_DIR"` and obey it: `repair` means fix and re-run; `deliver` means stop and ship with the residual defects the manifest now lists; `block` means a content-integrity defect remains (or there is no usable artifact), so do not deliver: tell the user what blocks it and record the row as `failed` with the reason. Never repair past a stop decision (3 attempts, a 2-attempt plateau, an oscillation, or 15 minutes; the reference's section 8). Fidelity defects ride the same loop (`--defects "$SESSION_DIR/defects.json" --defects "$SESSION_DIR/fidelity-defects.json"`), but a `deliver` decision does not release them: while `fidelity-defects.json` lists `untraceable_number`, `value_mismatch`, `unit_mismatch`, `quote_not_verbatim`, `quote_unbound`, `unbound_sentence`, or `chart_value_untraceable`, `outcome verify` fails with `fidelity_unresolved` and `outcome finish` refuses, even with the repair budget spent. The only ways out are a ledger row, an `assumed` row with its rationale, or removing the sentence.
 

package/packages/shared-skills/skills/ulw-research/references/deliverable-phase.md

@@ -80,7 +80,7 @@ format description: none
 
 The values below are read by `scripts/fidelity-policy.mjs`, the single registry: `SOURCE_FLOOR_RULES` and `parseSourceFloor()` for the `source floor` forms (`pointedFlag` in source registration reads the same grammar), and `FIDELITY_VALUE_RULES` for `derived numbers`, `languages`, `fallback`, and `meaning check`. `derived numbers` and `fallback` accept only the values in their row below (`FIDELITY_VALUE_RULES.tables`, any case); any other value, a free-text answer included, is a usage error (exit `2`) naming the field and the value, as an unknown `source floor` form is. Map a free-text answer onto a table value before writing it: a partial allowance ("growth rates yes, estimates no") records `derived numbers: none`.
 
-Beside `## Deliverable`, the brief records what the report must stay faithful to, under `## Fidelity`. The fields are inferred first; only `as of`, `meaning check`, `source floor`, and `derived numbers` may be asked, each on its own trigger, in the same question call as Q1-Q3 (at most four questions in that call). The inference rules, the triggers, and the question texts are in `SKILL.md`.
+Beside `## Deliverable`, the brief records what the report must stay faithful to, under `## Fidelity`. The fields are inferred first; only `as of`, `meaning check`, `source floor`, and `derived numbers` may be asked, each on its own trigger, in the same question call as Q1-Q3 (at most four questions in that call). The inference rules, the triggers, and the question texts are in [research-collection.md](research-collection.md), under "The fidelity questions".
 
 | Field | Values | Default | Read by |
 | --- | --- | --- | --- |
@@ -175,14 +175,14 @@ Nothing reaches the requester until the gates for its QA tier pass, in this orde
    node "$SKILL_DIR/scripts/report-tools.mjs" layout-probe --json   # .source is one async expression
    ```
 4. **Visual QA.** Render the artifact to images (PDF pages to PNG, the HTML in the browser skill's engine at desktop and phone widths) and look at the pixels for what a machine cannot see: composition, hierarchy, page breaks, figure legibility.
-5. **Proofread.** A dedicated writing lane proofreads the final text only (grammar, spelling, punctuation, terminology, native register); it never composes or rewrites content and never edits the file. Edits change text only; an edit whose before/after would alter any tag, attribute, comment, or script/style content is rejected, and markup changes go through the full fidelity gates instead. It returns `polish-edits.json` (`[{before, after, reason}]`), which the orchestrator applies edit by edit; a rejected or unlocated edit goes back to the lane with its reason, within the repair budget. The backstop diff, `fact verify` on the polished file, and the meaning readers on the pairs whose sentences polish changed run before the fidelity gate is recorded again. Edits must not span entities (such as & or <) or markup; narrow the edit to the surrounding words instead, and a rejected edit comes back with the reason to act on.
+5. **Proofread.** A dedicated writing lane proofreads the final text only (grammar, spelling, punctuation, terminology, native register); it never composes or rewrites content and never edits the file. Edits change text only; an edit whose before/after would alter any tag, attribute, comment, or script/style content is rejected, and markup changes go through the full fidelity gates instead. It returns `polish-edits.json` (`[{before, after, reason}]`), which the orchestrator applies edit by edit; a rejected or unlocated edit goes back to the lane with its reason, within the repair budget. The backstop diff, `fact verify` on the polished file, and the meaning readers on the pairs whose sentences polish changed run before the fidelity gate is recorded again; the layout gates and visual QA then run again on the polished file, which is the one delivered. Edits must not span entities (such as & or <) or markup; narrow the edit to the surrounding words instead, and a rejected edit comes back with the reason to act on.
    ```bash
    node "$SKILL_DIR/scripts/report-tools.mjs" fact polish-apply "$SESSION_DIR/report.html" --edits "$SESSION_DIR/polish-edits.json" --out "$SESSION_DIR/report.polished.html" --session-dir "$SESSION_DIR"
    node "$SKILL_DIR/scripts/report-tools.mjs" fact polish-diff --before "$SESSION_DIR/report.html" --after "$SESSION_DIR/report.polished.html" --session-dir "$SESSION_DIR"   # writes polish-defects.json
    node "$SKILL_DIR/scripts/report-tools.mjs" fact pairs "$SESSION_DIR/report.polished.html" --changed-since "$SESSION_DIR/report.html.fill-map.json" --session-dir "$SESSION_DIR"
    ```
 
-**Every reader-facing edition is verified.** The main report, the inline edition (section 9), LaTeX per-section sources, and slide sources are filled by `fact fill` from one placeholder source and each is verified by `fact verify` into its own record; PDF and DOCX are renders of a verified source. A delivered row is recorded with `outcome set <format> delivered --path <file> --verified-by <record>`, where the record's `artifact_sha256` equals the sha256 of the delivered source; a PDF or DOCX adds `--rendered-from <source>` and is matched against that source. Each delivered edition also carries its own meaning record: run `fact pairs` on that edition's source and `fact meaning-check --edition <format>`, which writes `fidelity-meaning-defects.<format>.json` bound to those bytes (section 7). The barrier binds each edition to a record for its current bytes: every record whose `artifact_sha256` equals those bytes is a candidate (its own record, another edition's record for a byte-identical copy or the html edition a PDF renders, and the legacy single file `fidelity-meaning-defects.json`), and the one with the newest `written_at` wins; on equal times the more severe verdict wins (`meaning_drift_confirmed`, then `meaning_unverified`, then clean). In a session with a fact ledger, `outcome verify` refuses a delivered row without a matching record (`edition_unverified`, blocker, integrity). Markdown and LaTeX verification arrive with the Markdown stage; until then `fact verify --format md|tex` exits `2`, and such an edition is recorded `blocked_capability` with that reason rather than delivered unverified.
+**Every reader-facing edition is verified.** The main report, the inline edition (section 9), LaTeX per-section sources, and slide sources are filled by `fact fill` from one placeholder source and each is verified by `fact verify` into its own record; PDF and DOCX are renders of a verified source. A delivered row is recorded with `outcome set <format> delivered --path <file> --verified-by <record>`, where the record's `artifact_sha256` equals the sha256 of the delivered source; a PDF or DOCX adds `--rendered-from <source>` and is matched against that source. Each delivered edition also carries its own meaning record: run `fact pairs` on that edition's source and `fact meaning-check --edition <format>`, which writes `fidelity-meaning-defects.<format>.json` bound to those bytes (section 7). The barrier binds each edition to a record for its current bytes: every record whose `artifact_sha256` equals those bytes is a candidate (its own record, another edition's record for a byte-identical copy or the html edition a PDF renders, and the legacy single file `fidelity-meaning-defects.json`), and the one with the newest `written_at` wins; on equal times the more severe verdict wins (`meaning_drift_confirmed`, then `meaning_unverified`, then clean). In a session with a fact ledger, `outcome verify` refuses a delivered row without a matching record (`edition_unverified`, blocker, integrity). A LaTeX edition is verified through its Markdown source; `fact verify --format tex` exits `2`.
 
 The light tier runs gate 1 and one render (recorded as `visual`) and records `fidelity`, `layout`, and `proofread` as `not_run` (`fidelity not_run` needs `--reason "<why>"`); the light tier never runs the fidelity verifier, although `fact verify` checks HTML and Markdown editions. The full tier runs all five.
 
@@ -269,7 +269,7 @@ Invoke every command as `node "$SKILL_DIR/scripts/report-tools.mjs" <command>`.
 | `fact polish-apply <report.html>` | `--edits <polish-edits.json>` and `--out <report.polished.html>` (both required; a missing flag or a Markdown edition exits `2`), `--fill-map <file>` (default: the edition's fill map, chosen as `fact verify` chooses it; one that does not record the input's bytes exits `2` and nothing is written), `--format html`, `--ledger <fact-ledger.json>`, `--brief <brief.md>`, `--session-dir <dir>` | `fidelity_interview_incomplete` (nothing written); otherwise never: it exits `0` whenever it wrote the output. With a fill map it also writes `<out>.polished.fill-map.json` (the brief binding, the polished file's hash, and `polishedFrom` naming the fill map) and never rewrites the fill map, even when `--out` is the input. Each rejected (`polish_edit_rejected`) or unlocated (`polish_edit_unlocated`) edit leaves its text unchanged and is printed verbatim, one line per rejection, in the summary and in `data.rejected_reasons`; `data` also carries `applied`, `rejected`, `unlocated`, `applied_indexes`, `input_sha256`, `edits_sha256`, and `out_sha256` |
 | `fact polish-diff` | `--before <pre-polish.html>` and `--after <polished.html>` (both required; a missing flag exits `2`), `--ledger <fact-ledger.json>`, `--out <record>` (default `$SESSION_DIR/polish-defects.json`), `--brief <brief.md>`, `--session-dir <dir>` | `fidelity_interview_incomplete` (nothing written), or a registry blocker in the diff (majors and minors are reported and exit `0`; a defect code the registry does not know refuses with `unknown defect code <code>`). The record is `{command, status, exitCode, before, artifact, artifact_sha256, defects[], counts}`, with `counts` in contract buckets |
 | `fact meaning-check` | `--pairs <pairs.json>` and `--verdicts <file>` (required; repeatable, one per reader tier), `--dispute P<n> --reason <text>`, `--run-id <id>`, `--calibration <file>` (default `fidelity-calibration.jsonl`), `--brief <brief.md>`, `--edition <format>` (writes `fidelity-meaning-defects.<format>.json`, the delivered edition's meaning record), `--out <record>` (default `fidelity-meaning-defects.json`), `--session-dir <dir>` | `fidelity_interview_incomplete`, or `meaning_drift_confirmed` (stderr carries one JSON line with the defect and dropped-verdict counts) |
-| `fact derive` | `--op <op>` and `--now <ISO>` (both required; `--now` is the row's `observed_at`, the script never reads the clock, and without it the command exits `2` with `missing_now` and writes no row) with the operation's operands (section 11), `--unit`, `--to`, `--rationale`, `--disjoint`, `--label`, `--json`, `--session-dir <dir>` | `incompatible_operands` (no row written) |
+| `fact derive` | `--op <op>` and `--now <ISO>` (both required; `--now` is the row's `observed_at`, the script never reads the clock, and without it the command exits `2` with `missing_now` and writes no row) with the operation's operands (section 11), `--unit`, `--to`, `--rationale`, `--disjoint`, `--reference`, `--label`, `--json`, `--session-dir <dir>` | `incompatible_operands` (no row written) |
 | `claims index <claim-graph.md>` | `--out <claims.json>` (required) | never (a malformed claim table exits `2`) |
 
 ## 11. Fidelity gate
@@ -298,7 +298,7 @@ Derivations are computed in exact rationals from the operands' stored values and
 
 | Operation | Operands | Checks |
 | --- | --- | --- |
-| `sum` | two or more ids, `--unit` | one unit; summing `%` needs `--disjoint` and `--rationale` |
+| `sum` | two or more ids, `--unit` | one unit; summing `%` needs `--disjoint`, `--reference <denominator>`, and `--rationale` |
 | `diff` | two ids (minuend, subtrahend) | one unit; a difference of `%` is in `pp` |
 | `growth` | `--from <id> --to <id>` | one declared entity, two different `valid_at` periods, a positive start; result in `%` |
 | `ratio` | `--num <id> --den <id>`, `--unit` | a non-zero denominator |

package/packages/shared-skills/skills/ulw-research/references/report-visualization.md

@@ -35,7 +35,7 @@ Save every asset under `$SESSION_DIR/assets/` and confirm the file exists and is
 
 ### Charts from data
 
-Put the numbers in a table first (`$SESSION_DIR/data/<name>.csv`), then plot from the table, never from prose. Follow the data-scientist doctrine in SKILL.md (numpy, Polars, DuckDB, no pandas).
+Put the numbers in a table first (`$SESSION_DIR/data/<name>.csv`), then plot from the table, never from prose. Follow the data-scientist tool doctrine: numpy for numeric work beyond SQL/DataFrame aggregation, Polars for filtering, sorting, and transforms, DuckDB for joins, aggregations, and window functions, never pandas.
 
 ```bash
 uv run --with numpy --with polars --with matplotlib python plot_<name>.py
@@ -125,7 +125,7 @@ A post by Andrej Karpathy on 2026-10-02 ranks the formats that make model output
 
 ## 5. Quality bar
 
-- Every figure follows the figure standard in SKILL.md: fixed container, contain-fit, aspect ratio preserved, spec fonts and palette.
+- Every figure follows the binding figure standard in [deliverable-phase.md](deliverable-phase.md), section 6: fixed container, contain-fit, aspect ratio preserved, spec fonts and palette.
 - The caption alone tells the reader what the visual shows and what to conclude: "Median build time fell from 9.4 to 3.1 minutes after the cache change [S4]" beats "Build times".
 - Alt text states the content, not the file: the key values or the shape of the trend for a chart, the main nodes and flow for a diagram. A purely decorative image takes `alt=""` plus `role="presentation"` and does not count as a visual; an empty alt without that marker is reported as missing.
 - Every number in a visual comes from the data table and carries its source or lineage tag in the caption.

package/packages/shared-skills/skills/ulw-research/references/research-collection.md

@@ -102,7 +102,7 @@ asked: derived numbers
 
 Values carry no parentheses; `pending` goes only with `answered_by: pending`. When an answer lands, rewrite that one line with `answered_by: user` and leave `asked:` as history; a late answer after `fact fill` is a re-render: fill again, then verify.
 
-**Re-entry.** An `edit-existing` session, or any session created before this block existed, has no `## Fidelity`. Before any `fact` command, run the inference step above and write the block with `answered_by: default` on every field. `claims index` on a free-form `claim-graph.md` (no claim table) returns `{claims: [], errors: [...]}`, exits 2, and writes no `claims.json`; run `fact verify` without it, and the gate reports each unbound sentence as `unbound_sentence` (major) instead of blocking.
+**Re-entry.** An `edit-existing` session, or any session created before this block existed, has no `## Fidelity`. Before any `fact` command, run the inference step above and write the block with `answered_by: default` on every field. `claims index` on a free-form `claim-graph.md` (no claim table) returns `{claims: [], errors: [...]}`, exits 2, and writes no `claims.json`; run `fact verify` without it, and the gate reports each unbound sentence as `unbound_sentence` (major), which blocks delivery until the sentence is bound.
 
 **Calibration.** `fact meaning-check` appends one line per flagged pair to `--calibration` (default `$SESSION_DIR/fidelity-calibration.jsonl`). After each run, also append that run's new lines to the workspace-level `.omo/ulw-research/fidelity-calibration.jsonl`; promotion of `meaning_drift_confirmed` is decided from that log.
 
@@ -129,7 +129,7 @@ Scaling floor — more angles always justify more workers:
 Role protocols — embed the relevant one in each spawn message; every worker gets a unique angle:
 
 - **Codebase (explore), 2-4 workers.** Grep with 3+ keyword variations; structural/AST search; LSP definitions and references; file-name globs; `git log --all -S '<keyword>'` and `--grep` for history including deleted code. Cross-validate hits across tools. Report absolute file paths, patterns with `file:line`, and how findings connect.
-- **Web, 3-9 workers, every one loaded with the `browser` skill.** Search with 10+ websearch queries per worker, each with a different operator or angle (see Search craft); a result is a candidate, not a source. Read every candidate in the user's browser through the `browser` skill's attached engine: one named session per worker, one tab per source, several tabs open side by side while sources are compared — `session.tabCreate` / `tabSelect` / `tabClose` where the harness has a JS eval kernel, `bsk tab create --url <url>` / `tab select <id>` / `tab close <id>` / `tab list` on the CLI — the page scrolled to its end, a full-page screenshot of each top source saved as provenance, the tab closed once reported. A browser on another machine is reached through the `browser` skill's remote reference or a user-level skill that bridges to it, never replaced by a local headless one. `webfetch` is for raw files only: PDF, JSON, feeds, sitemaps. A host the browser cannot open (WAF, bot score, 403) goes to `ultimate-browsing`, whose provenance travels with the claim: a `snapshot` result cites its `snapshot_timestamp` and is never stated as the live page; a `proxy` result is `untrusted` until a second independent route agrees. Context7 with 3+ queries per known library; grep.app and `gh search code|repos|issues` for real-world usage; official docs via sitemap discovery (`<base>/sitemap.xml`), then targeted pages. A worker whose sources are all fetched text has searched, not read.
+- **Web, 3-9 workers, every one loaded with the `browser` skill.** Search with 10+ websearch queries per worker, each with a different operator or angle (see Search craft); a result is a candidate, not a source. Read every candidate in the user's browser through the `browser` skill's attached engine: one named session per worker, one tab per source, several tabs open side by side while sources are compared — `session.tabCreate` / `tabSelect` / `tabClose` where the harness has a JS eval kernel, `bsk tab create --session <session> --url <url>` / `tab select --session <session> <id>` / `tab close --session <session> <id>` / `tab list --session <session>` on the CLI — the page scrolled to its end, a full-page screenshot of each top source saved as provenance, the tab closed once reported. A browser on another machine is reached through the `browser` skill's remote reference or a user-level skill that bridges to it, never replaced by a local headless one. `webfetch` is for raw files only: PDF, JSON, feeds, sitemaps. A host the browser cannot open (WAF, bot score, 403) goes to `ultimate-browsing`, whose provenance travels with the claim: a `snapshot` result cites its `snapshot_timestamp` and is never stated as the live page; a `proxy` result is `untrusted` until a second independent route agrees. Context7 with 3+ queries per known library; grep.app and `gh search code|repos|issues` for real-world usage; official docs via sitemap discovery (`<base>/sitemap.xml`), then targeted pages. A worker whose sources are all fetched text has searched, not read.
 - **Repo deep-dive (librarian), 0-2 workers.** Shallow-clone the most relevant repos to `${TMPDIR:-/tmp}`, pin the HEAD SHA, read core modules, follow call chains, return SHA-pinned permalinks.
 
 Example spawn (codebase axis; web and repo-dive follow the same contract with their own protocol):

package/packages/shared-skills/skills/ulw-research/references/unit-rules.md

@@ -31,7 +31,7 @@ numeric guards may read `exact` values, unit selection may not. The property tes
 
 | op | arity | operand guards | context fields (persisted on the row) | result unit | malformed -> recompute ok:false |
 |---|---|---|---|---|---|
-| sum | n>=2 | non-affine units, all equal after canonicalization; if `%`: `disjoint: true` AND `reference` (one denominator id/text) equal on every operand AND rationale | disjoint, reference, rationale | the common unit (`%` stays `%`) | <2 operands; missing id; no context; unequal/affine units; `%` without disjoint, reference, or rationale |
+| sum | n>=2 | non-affine units, all equal after canonicalization; if `%`: `disjoint: true` AND `reference` (one denominator id/text) equal on every operand AND rationale | disjoint, reference (the `%` rationale goes in the row's `rationale` field, not in context) | the common unit (`%` stays `%`) | <2 operands; missing id; no context; unequal/affine units; `%` without disjoint, reference, or rationale |
 | diff | 2 | non-affine units; typed pairs only: U-U -> U (same non-% unit); %-% -> `%p`; %-%p -> `%`; %p-%p -> `%p`; %p-% REFUSED | none | per the pair rule | arity; invalid pair (`%p - %`, `m - person`); affine units; stray context |
 | growth | 2 (from,to) | equal non-affine units; same entity; two different valid_at; from.exact > 0 | none | `%` (= 100(to-from)/from) | arity; unequal/affine units; entity/valid_at; from<=0; stray context |
 | share | 2 (part,whole) | equal non-affine units; whole.exact > 0; 0 <= part <= whole | none | `%` (= 100 part/whole) | arity; units; whole<=0; part outside [0,whole]; stray context |
@@ -123,7 +123,7 @@ converted rows that carry this version's columns, and to every row this version
 still breaks a strict rule (a scale word as unit, empty metadata, an operation or derivation fields) is flagged when it
 is used: `derive` and `recompute` refuse it with shape `dimension 6`, `dimension 18`, or `dimension 1`, and `addRow`
 refuses to write a new one. Normalization never strips user data: an `exact` carrying keys beyond `num` and `den` is left exactly as written and flagged `dimension 7` on use, never silently reduced to `{ num, den }`. Reading a normalized file again changes nothing. The legacy test fixture is generated by
-dev's own `addRow` (`scripts/tests/fixtures/fidelity/gen-legacy-dev.mjs`, which pins the dev commit).
+dev's own `addRow` (`scripts/tests/fixtures/fidelity/gen-legacy-dev.mjs` in the source repository, which pins the dev commit; the tests and fixtures do not ship with the skill).
 
 ## Trust boundary
 

package/packages/shared-skills/skills/visual-qa/AGENTS.md

@@ -55,4 +55,4 @@ node scripts/visual-qa.mjs tui-check <capture.txt> --cols 80
 bun test scripts/*.test.ts
 ```
 
-- Parent: [`packages/shared-skills/AGENTS.md`](../../AGENTS.md).
+- Parent (source checkout only; not shipped with the skill): `packages/shared-skills/AGENTS.md`.

package/packages/shared-skills/skills/visual-qa/SKILL.md

@@ -130,7 +130,7 @@ This is the platform baseline, distilled from Apple's Human Interface Guidelines
 - A10 Content that continues out of view shows a cue (partial item, fade, chevron).
 - A11 (mac) Nothing important lives only at the window's bottom edge; the minimum window size keeps toolbar and content legible; the sidebar collapses when the window narrows.
 - A12 (web and app screens; N/A for a TUI, a printed page, or a figure) Layout contract: every changed screen or region has a `Layout:` line (in `DESIGN.md`, or in the change description when the project has none; the `frontend` skill's Brief step); the capture shows that pattern's structure; the logged owner is the region's main scroller in the probe output, every other scroller listed is nested inside it for its own content (a code block, a dropdown, a composer) or is named in the line too; none of the line's anti-patterns appear. A missing line, a different main scroller, an unexplained sibling scroller, or a present anti-pattern is a FAIL; a logged skip still owes the scroll-owner check.
-- A13 Spacing rhythm, read from computed values: the space above a section heading is at least 1.5x the space below it, and the gap between groups is at least 2x the gap inside a group (the `frontend` skill's `references/perfection/craft-floor.md`).
+- A13 Spacing rhythm, read from computed values: the space above a section heading is at least 1.5x the space below it, and the gap between groups is at least 2x the gap inside a group, unless the brief's chosen style route sets its own spacing rhythm and the deviation is recorded in the brief or DESIGN.md, in which case that value is the check (the `frontend` skill's `references/perfection/craft-floor.md`).
 
 **B. Hierarchy**
 - B1 One primary action per view, in the prominent style (accent on its background, not its glyph); peers differ by style, never by size.
@@ -181,7 +181,7 @@ This is the platform baseline, distilled from Apple's Human Interface Guidelines
 A13, B8, E7, F8 and F9 are adapted from the craft floor of [pbakaus/impeccable](https://github.com/pbakaus/impeccable) (Apache-2.0, Copyright 2025 Paul Bakaus); the license and the list of changes are in the `frontend` skill's `ATTRIBUTION.md` section 6.
 
 **G. Motion and feedback**
-- G1 Every animation has a cause - an interaction, a state change, an arrival; no motion on non-interactive elements, no hover that changes nothing, no permanent loop.
+- G1 Every animation has a cause - an interaction, a state change, an arrival; no motion on non-interactive elements, no hover that changes nothing, no permanent loop. A background the brief's ambience route asked for may loop on its decorative layer only while in view: it starts from an IntersectionObserver, stops off-screen and on visibilitychange, and paints one static frame under reduced motion (the `frontend` skill's `references/design/ambience-skill.md`).
 - G2 Transitions keep identity: a surface that resizes or moves animates from its old geometry to the new; exit mirrors entry; nothing reflows under the pointer.
 - G3 Motion is interruptible and never gates input: mid-animation input retargets smoothly and never snaps; nobody waits for an animation to act.
 - G4 Under `prefers-reduced-motion`, positional, scale and depth motion becomes a cross-fade; fades, progress and gesture tracking stay; blur never animates.
@@ -249,7 +249,7 @@ SOURCE CODE:
 {Full source of the UI: components, styles/tokens, layout, render code. Include neighboring files that show existing patterns.}
 
 CAPTURES:
-{Web: actual screenshot path(s) plus your described observations. TUI: paste capture.txt and capture-ansi.txt inline.}
+{Web: actual screenshot path(s) plus your described observations. TUI: paste terminal.txt and terminal-ansi.txt inline.}
 
 SHARED SCRIPT EVIDENCE (reference, not verdict):
 {Paste the image-diff or tui-check JSON. Use alphaChannelIntact for the transparency check.}
@@ -306,7 +306,7 @@ BEFORE/AFTER PAIRS:
 SURFACE: {web | tui | both}
 
 CAPTURES:
-{Web: actual and reference screenshot paths plus your described observations. TUI: paste capture.txt and capture-ansi.txt inline.}
+{Web: actual and reference screenshot paths plus your described observations. TUI: paste terminal.txt and terminal-ansi.txt inline.}
 
 SOURCE CODE:
 {For web: include the rendered text/content, components, typography, layout, and style code. For TUI: include render code that controls wrapping, width, and wide-character handling.}
@@ -322,7 +322,7 @@ USE THE EVIDENCE:
 - TUI (tui-check): inspect maxWidth vs expectedColumns, every overflowLines[] entry, borderMisaligned, and wideCharColumns[].
 
 CHECK:
-1. Checklist sections A-F, item by item, on the 390 AND 1440 captures in BOTH themes and on the scrolled-to-end shots: PASS, FAIL or N/A with the capture that proves it. Every FAIL is BLOCKING.
+1. Checklist sections A-F, item by item, on the 390, 1440 and (for page layouts) 1920 captures in BOTH themes and on the scrolled-to-end shots: PASS, FAIL or N/A with the capture that proves it. Every FAIL is BLOCKING.
 2. When a reference packet exists, compare ACTUAL against REFERENCE pixel-perfectly, region by region: page bounds, header/nav, hero, cards, grids, charts, media, typography, copy, color tokens, radius, shadow, border, icon size, spacing, alignment, scroll position, and state. Anything off beyond unavoidable rasterization/rounding is a finding. The overview text is part of the target: missing or rearranged reference content is a finding even if the screenshot looks plausible.
 3. When before/after pairs exist, judge each pair side by side: the after must show the brief's primary action and priorities more legibly than the before, carry fewer elements without a job, and lose nothing from the required-content list. A pair with no change a reader can point to, or a required input, datum, or copy present in before and missing or merged in after, is a BLOCKING [defect].
 4. CJK precision:

package/packages/shared-skills/skills/visual-qa/references/browser-setup.md

@@ -89,8 +89,10 @@ not fall back to the owned engine for an authenticated criterion.
 
 ## Capture at a fixed viewport
 
-Match CSS viewport AND PNG dimensions: pin `deviceScaleFactor` through `emulate` (owned) or
-`resize` (attached) instead of resizing the PNG to force a pass; a 390-wide capture at desktop
+Match CSS viewport AND PNG dimensions: pin `deviceScaleFactor` through `emulate` (owned engine).
+Attached `resize(width, height)` sets the window size only and leaves the device pixel ratio at the
+user's display, so on the attached engine record the capture's DPR (PNG width / CSS viewport width)
+and compare against a reference taken at that DPR. Never resize the PNG to force a pass; a 390-wide capture at desktop
 DPR with classic scrollbars is not a phone capture. Wait for the specific page state (a locator,
 a `waitForURL`, a `createNetworkSnoop(page).waitFor(...)`), not a sleep, then compare: