oh-my-opencode 5.0.0-beta.13 → 5.0.0-beta.15

package/dist/skills/frontend/SKILL.md

@@ -15,6 +15,7 @@ This file is a router, not a rulebook. The rules live in four rulesets under `re
 |---|---|
 | ANY UI implementation, styling, redesign, mockup, or visual decision | `references/design/README.md` FIRST. It enforces two mandatory gates — the Design System Gate (a `DESIGN.md` must exist before any component is written) and the React Dev Tooling Gate (react-grab / react-scan / react-doctor installed by default) — then routes to the taste and brand references below. |
 | Spatial structure — app shells, scroll ownership, "what goes where", "this layout breaks at X" | ALSO `references/design/layout-skill.md` for the mechanics, then `references/design/stylegallery.md` to fetch a named pattern contract for that exact spatial problem. Both stack on the style skill and add no visual direction. |
+| Paged output — a PDF report, a print stylesheet, a headless-Chrome print pipeline, an HTML deck printed to paper, or any "why is this page half empty" break defect | ALSO `references/design/print-paged-media.md` for the page box, the fragmentation properties, the atomic-block set, and the keep-together side effect that strands a block on a near-empty page. It adds no visual direction and stacks on the routed style skill. |
 | Interaction or motion work — micro-interactions, animated components, transitions, gestures, hover/press/state feedback, "make it feel alive" | ALSO `references/design/interaction-skill.md`. The beui.dev catalog is the mandatory interaction reference: find the nearest pattern, read its real source through the file's curl recipe, and adapt the mechanism to `DESIGN.md` motion tokens. It stacks on the routed style skill — never replaces it. |
 | Writing or modifying frontend code, OR auditing performance / SEO / accessibility / quality | ALSO `references/perfection/README.md`. Lighthouse 100 in every category, measured on real Playwright Chromium (never the `lighthouse` CLI), achieved through architecture — never by dropping animations or hiding content. |
 | Looking up a concrete style, palette, font pairing, chart type, landing structure, or UX guideline — or generating a design system from keywords | `references/ui-ux-db/README.md`. A searchable CSV database with a CLI: a lookup tool, not a posture. `design` stays the source of truth for taste and the `DESIGN.md` contract. |

package/dist/skills/frontend/references/design/print-paged-media.md

@@ -0,0 +1,76 @@
+---
+name: print-paged-media
+description: "Layer A paged-media reference. Load it when output is a document that breaks into pages - a PDF report, a print stylesheet, a headless-Chrome print pipeline, or an HTML deck printed to paper - instead of a continuously scrolling screen. Owns the page box, fragmentation properties, the atomic-block set, and the keep-together side effect that strands a block on a near-empty page. Adds zero visual taste; the style skill and DESIGN.md still own color, type, and spacing."
+---
+
+# Paged Media
+
+Screen layout has one viewport and infinite scroll. Paged media has a fixed page box and a fragmentation engine that cuts your content into pages whether or not you told it where. This file owns that cut. It stacks on top of a Layer A style skill and adds ZERO visual direction - color, type, radius, and spacing still come from the style skill and `DESIGN.md`.
+
+Load this when the deliverable is a PDF report, a print stylesheet, a `chrome --headless --print-to-pdf` pipeline, a WeasyPrint render, or any HTML meant to land on paper.
+
+## 1. The page box comes first
+
+Declare the page before styling anything inside it. `@page { size: A4; margin: 2cm; }` sets the sheet and the content area; every measurement downstream is relative to what survives those margins.
+
+- `@page:first` targets the cover alone. A full-bleed cover is `@page:first { margin: 0 }`, which also suppresses the running header and footer on page one.
+- Running headers and footers live in the page margin boxes. In headless Chrome they come from `headerTemplate` / `footerTemplate` on `Page.printToPDF`, rendered into the margins that `@page` declared - not from a fixed-position element in the body.
+- Pass `preferCSSPageSize: true` when printing through CDP so your `@page` rule wins over the caller's paper defaults. Without it, the size you declared and the size you get can differ.
+- Body content flows through the page area. An element with a viewport unit (`100vh`) or a fixed position does not mean on paper what it means on screen; size page furniture in `mm` or `pt`.
+
+## 2. Fragmentation vocabulary
+
+Three properties decide every cut. Modern names first; the `page-break-*` aliases still work and appear in older pipelines.
+
+| Property | Use it for |
+|---|---|
+| `break-before: page` | Start a section on a fresh page. |
+| `break-after: avoid` | Keep a heading with the block that follows it (keep-with-next). |
+| `break-inside: avoid` | Forbid a cut *through* one block: a table, a figure, a callout, a code listing. |
+| `orphans` / `widows` | Minimum lines of a paragraph left at a page foot / carried to the next page. Set both to at least 2; 3 reads better in dense body copy. |
+
+`break-inside: avoid` on a wrapper is what actually protects a table - apply it to the element that owns the whole exhibit, not to the `<table>` alone, or the caption and the rules can still separate from the rows.
+
+## 3. The atomic set - keep it small on purpose
+
+Mark as atomic only what is unreadable when split: a data table with its caption, a figure with its `figcaption`, a callout, a short code listing. Everything else - ordinary paragraphs, long prose lists, multi-page tables - should be allowed to break, because a block that cannot break and cannot fit is a defect generator, not a protected exhibit.
+
+A block taller than the page area gets split regardless of what you declared. `avoid` is a request the engine honors only when honoring it is possible.
+
+## 4. The keep-together side effect - the defect this file exists to prevent
+
+This is the failure that looks like a bug in your CSS but is your CSS working exactly as written.
+
+A block carrying `break-inside: avoid` reaches the bottom of a page with too little room left. The engine cannot split it, so it moves the WHOLE block to the next page. That is correct. The damage appears when the block is the LAST content of its section and the next section carries `break-before: page`: nothing can flow up to backfill the gap it left, and nothing can flow down beside it. You ship one page with a short box at the top and a column of whitespace under it, and one page before it with an unexplained gap at the foot.
+
+Nothing in the cascade detects this. Both rules are locally correct; the artifact is their interaction with where the text happened to land.
+
+How to prevent and repair it:
+
+- **Shrink the atomic set.** Every unnecessary `break-inside: avoid` is one more block that can be stranded. Protect exhibits, not paragraphs.
+- **Do not wrap a lead-in with its block** unless the pair reliably fits together. Binding more content into one unbreakable unit makes stranding more likely, not less.
+- **Reconsider the forced section break.** `break-before: page` on every section is a strong default for a report and a poor one for short trailing sections; allowing a brief section to continue on the current page removes the trap entirely.
+- **Editorial repair is legitimate.** Shortening the block by a line, or moving it a paragraph earlier, is a real fix - and often the correct one for a hand-tuned deliverable.
+- **Detect it by ink, not by intent.** A page whose content coverage falls far below its neighbors is the signal. Ranking pages by rendered coverage finds stranded blocks faster than reading CSS does.
+
+## 5. What the engine actually honors
+
+Fragmentation support is uneven, and reading the stylesheet will not tell you what happened.
+
+- `break-inside: avoid` inside flex, grid, and multi-column containers is partially implemented across engines; a constraint that holds in normal flow can be dropped inside a nested fragmentation context.
+- Transformed, absolutely positioned, and `overflow`-clipped subtrees fragment differently from ordinary blocks, and sometimes not at all.
+- Background colors and images on split blocks may or may not repaint on the continuation page. Chrome needs `printBackground: true` before any of it renders.
+
+Treat every fragmentation rule as a hypothesis until you have seen the rendered page.
+
+## 6. Verify by rendering every page
+
+A paged deliverable is verified by looking at its pages. Render them and inspect each one:
+
+```bash
+pdftoppm -png -r 150 report.pdf out/page   # one PNG per page
+```
+
+Read every page image for: blank or near-empty pages, a block stranded alone after a keep-together push, a table or figure split mid-exhibit, a heading orphaned at a page foot, clipped or overflowing text, and a running header or footer that drifted or vanished.
+
+Extracting the text proves the words are present. It cannot see any defect in this list - layout is exactly the information that extraction discards. Fix, re-render, and look again until the pages are clean; the same standard governs the `ulw-research` delivery gate and the `mass-ulw` verification wave.

package/dist/skills/ulw-research/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ulw-research
-description: "Maximum-saturation research orchestration: ALWAYS proposes the final materials first (PDF+DOCX default), then parallel explore+librarian swarms across codebase, web, official docs, and OSS repos — max-roster teammode when the harness has it — with live journaling, a recursive EXPAND loop driven by leads workers return in message text, empirical verification by running code, and a cited synthesis with charts/Mermaid/assets behind a mandatory visual-QA gate. ACTIVATES ONLY on an explicit user demand for research — the word 'ulw-research' ('/ulw-research', '$ulw-research'), any 'ulw' research wording, 'ultradebate' or 'hyperdebate' research requests, or an explicit request for research / deep research / an ultra-precise investigation, in any language. Never self-activates for ordinary questions, debugging, or implementation context-gathering. While active it overrides exploration-bounding defaults: exhaustive coverage is the goal."
+description: "Maximum-saturation research orchestration: ALWAYS proposes the final materials first (PDF+DOCX default), then parallel explore+librarian swarms across codebase, web, official docs, and OSS repos — max-roster teammode when the harness has it — with live journaling, a recursive EXPAND loop driven by leads workers return in message text, empirical verification by running code, and a cited synthesis with charts/Mermaid/assets behind a mandatory visual-QA gate. ACTIVATES ONLY on an explicit user demand for research — the word 'ulw-research' in any prefix form, any 'ulw' research wording including combined invocations like 'mass ulw research', 'ultradebate' or 'hyperdebate' research requests, or an explicit request for research / deep research / an ultra-precise investigation, in any language. Never self-activates for ordinary questions, debugging, or implementation context-gathering. While active it overrides exploration-bounding defaults: exhaustive coverage is the goal."
 ---
 
 ## Codex Harness Tool Compatibility

package/dist/skills/visual-qa/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: visual-qa
-description: "MUST USE after building/changing any UI or when asked whether a page, component, or TUI looks right. Rigorous visual QA across web/page and terminal UIs. Prefer browser:control-in-app-browser for unauthenticated browser/page QA in Codex, then Playwright/agent-browser/dev-browser. Captures screenshot/TUI evidence with bundled diff scripts, runs design-system/functional and visual-fidelity/CJK reviewer passes, then synthesizes a good/bad verdict. Triggers: visual QA, screenshot/pixel diff, UI looks wrong, reference fidelity, design system check, responsive check, CJK text clipping, TUI alignment, box-drawing drift."
+description: "MUST USE after building/changing any UI or when asked whether a page, component, or TUI looks right. Rigorous visual QA across web/page, terminal, and paginated-document surfaces. Prefer browser:control-in-app-browser for unauthenticated browser/page QA in Codex, then Playwright/agent-browser/dev-browser. Captures screenshot/TUI evidence with bundled diff scripts, runs design-system/functional and visual-fidelity/CJK reviewer passes, then synthesizes a good/bad verdict. Triggers: visual QA, screenshot/pixel diff, UI looks wrong, reference fidelity, design system check, responsive check, CJK text clipping, TUI alignment, box-drawing drift, PDF page check, deck review, blank or near-empty page, wrong page break."
 ---
 
 # Visual QA - Dual-Oracle Web and TUI Verification
@@ -9,7 +9,7 @@ Verify a rendered UI against intent using objective script evidence plus two par
 
 ## Purpose and when to use
 
-- Use after you build or change any UI, before calling it done. Covers web/page UIs and TUI/terminal UIs.
+- Use after you build or change any UI, before calling it done. Covers web/page UIs, TUI/terminal UIs, and paginated documents.
 - Use when output must match a mock, a baseline, or a stated design intent; when you suspect a regression; when CJK (Korean/Japanese/Chinese) text may clip, misalign, or wrap awkwardly; when a claimed design system might actually be a flat image; when a terminal layout may overflow or its borders may break.
 - Skip when there is no rendered surface (pure backend or library logic with no visual or terminal output). For broad post-implementation review use review-work; this skill is the visual specialist.
 
@@ -19,6 +19,7 @@ In the commands below, `$SKILL_DIR` is this skill's own directory (the folder co
 
 - Web/page UI: renders in a browser (HTML/CSS/JS, components, canvas, SVG). Evidence is screenshots.
 - TUI/terminal UI: renders as text in a terminal (box-drawing, panes, status lines, REPL/TUI apps). Evidence is terminal captures.
+- Paginated document: renders as ordered pages (PDF report, printed HTML, exported deck). Evidence is every page rendered to an image - `pdftoppm -png -r 150 <file>.pdf <prefix>` or the pipeline's own renderer. Extracted text is not evidence here: layout is exactly what extraction discards, so a stranded block, a split table, or a near-empty page survives a clean text check.
 - Reference-fidelity UI: any web/page UI built from a concrete reference packet, including screenshots, generated Imagen/Stitch mockups, Figma exports, overview text, annotations, or source-site captures. Evidence is the full reference packet plus same-size actual captures.
 
 If the change touches both, run both capture tracks and feed both into the passes.