ima2-gen 2.0.15 → 2.0.16

package/skills/ima2-front/references/korea-2026.md

@@ -0,0 +1,174 @@
+# Korea 2026 — Korean-First Frontend Rules
+
+Use this when the UI is Korean-first, Korea-facing, or likely to be judged against Korean consumer/product norms.
+
+## Product Defaults
+
+Korean product UI often values:
+
+- dense but scannable information
+- fast task completion over empty hero space
+- mobile-first navigation and sticky actions
+- trust-first presentation in finance, public services, healthcare, education, and B2B
+- concrete visual assets over abstract gradient atmosphere
+- familiar Korean copy with low friction
+
+Do not treat "Korean design" as automatically cute, pastel, or mascot-heavy.
+
+## Domain Profiles
+
+| Domain | Direction | Avoid |
+| --- | --- | --- |
+| Fintech/payment | calm, precise, explainable, reversible | childish mascots, vague trust claims, generic 3D icons |
+| Public/gov | KRDS/KWCAG-minded, plain, predictable | decorative motion, cute assets, low contrast |
+| B2B/SaaS/ops | dense, restrained, repeatable workflows | landing-page hero composition, card-heavy dashboards |
+| Commerce/community | familiar, local, warm, concrete | generic global SaaS copy, fake reviews |
+| Education/kids | guided, encouraging, visual, forgiving | confusing decoration, inaccessible contrast |
+| AI tools | provenance, process, undo, permission clarity | magical gradients, no error/retry/cancel states |
+
+## Public Service / Regulated Korean UI
+
+For government, public-service, finance, healthcare, education administration, or other regulated Korean surfaces:
+
+- Use KRDS-minded structure when applicable: predictable navigation, consistent tokens, clear service patterns, and plain Korean labels.
+- Apply KWCAG/WCAG accessibility thinking from the start: labels, keyboard operation, focus order, contrast, alternatives, error recovery, and status messaging.
+- Favor trust, reversibility, and task completion over decorative personality.
+- Avoid cute characters, playful metaphors, soft 3D mascots, and heavy motion unless they explain a task and pass stakeholder/a11y review.
+- Treat 44×44px hit areas as a conservative mobile baseline; smaller targets must still satisfy WCAG 2.2 target-size/spacing requirements.
+
+## Korean Typography
+
+- Use CJK-safe stacks first: Pretendard, SUIT, Noto Sans KR, Apple SD Gothic Neo, system sans fallback.
+- Latin display fonts are optional accents, not the default for Hangul.
+- Avoid negative letter-spacing as a default for Korean text.
+- Body line-height should usually sit around 1.55-1.75.
+- Large Korean headings need optical restraint; avoid hero-scale type inside tools.
+- Test labels with long Hangul strings before delivery.
+
+### Korean Hero / Large Display Type (verified 2026-07-08)
+
+Big bold Hangul is NOT the same as big bold Latin. Each Korean syllable is a
+dense, near-square block with little ascender/descender rhythm, so at the same
+px and weight it reads as a heavier graphic mass (Typotheque CJK typesetting;
+Morisawa Hangeul guide). Scaling Hangul to Latin-poster size and weight is a
+slop signal on landing/campaign surfaces too, not only inside tools — a
+`clamp(..., 10rem)` / `line-height: 0.9` / weight `800-900` Korean hero is the
+tell.
+
+Measured on live premium Korean services (2026-07-08, Playwright computed style):
+
+| Service | Korean hero (desktop) | Note |
+| --- | --- | --- |
+| Toss home | 66px / 700 / lh 1.4 | keep-all, letter-spacing normal |
+| Toss team | 72px / 700 / lh 1.3 | keep-all |
+| Daangn about | 64px / 700 / lh 1.31 | keep-all |
+| Kakao corp | 70px / 700 / lh 1.27 | letter-spacing -3px |
+| Woowa | Korean 40px / 700 | its 900 is on ENGLISH display only |
+| Naver / Musinsa | 32px/600, 20px/600 | content- and image-led |
+
+Rules (DEFAULT):
+- **Weight**: `700` is the premium ceiling for long Korean hero copy; `600` for a
+  quieter tone. Reserve `800/900` for SHORT brand phrases (e.g. "토스페이스"),
+  English display, or deliberate poster impact — `900` on long Hangul reads blunt
+  before it reads refined.
+- **Size**: keep desktop Korean heroes ~`56-72px`; avoid 100px+ walls of Hangul.
+  Mobile ~`26-40px`. Do not let a `vw`-relative clamp push Hangul past this.
+- **Line-height**: `1.25-1.4` for multi-line Hangul. Do not copy Latin display
+  `line-height: 0.9-1.0`; dense Hangul needs air between lines.
+- **Breaks**: `word-break: keep-all` + manual `<br>` at 어절/meaning boundaries;
+  never split inside a word.
+- **Tracking**: default `normal` (0). Mild negative (`-0.01` to `-0.02em`) on
+  large display is an observed premium practice but optional and QA-gated; keep
+  body Korean at normal.
+- **Structure over scale**: short Korean headline + supporting copy + whitespace +
+  imagery, or an English display accent, beats a giant Hangul wall. This is how
+  Toss/Woowa/Naver read premium.
+- **Fonts**: Pretendard (safe premium default), Wanted Sans (brand-forward),
+  Spoqa Han Sans Neo (practical); reserve custom faces (Toss Product Sans style)
+  for brand budgets.
+
+Sources: live pages toss.im, about.daangn.com, kakaocorp.com, woowahan.com,
+navercorp.com, musinsa.com; Typotheque CJK typesetting; Morisawa Hangeul guide;
+W3C Korean Layout Requirements (KLREQ); Pretendard / Wanted Sans / Spoqa docs.
+
+### Korean Serif / Myeongjo Display (verified 2026-07-09)
+
+The Latin serif renaissance has a Korean lane, but it is **editorial myeongjo
+display**, not a verified KR-AI-brand wave — do not claim Korean AI services
+moved to myeongjo the way Anthropic moved to serif. Use myeongjo as a
+domain-gated display direction for editorial, literary, cultural, publication,
+and trust/heritage surfaces.
+
+Webfont ranking (DEFAULT):
+- **MaruBuri** (Naver, 명조/부리, ExtraLight-Bold): the best warm Korean
+  display serif for screens; use 400-600 for headlines, never for tiny UI text.
+- **Noto Serif KR**: widest coverage and weight range, but heavy CJK payload —
+  subset aggressively or use the variable build.
+- **Nanum Myeongjo**: familiar and literary, but reads dated for premium tech.
+- **Chosun Myeongjo family**: strong newspaper-authority signal; choose it for
+  press/heritage tone, not soft AI warmth.
+
+Pairing grammar mirrors the Latin three-role system: **myeongjo display +
+Pretendard/SUIT/system sans UI** (+ mono accent for technical surfaces).
+Keep myeongjo out of dashboards, dense tools, and body-size UI text; Hangul
+serif strokes degrade at small sizes on low-DPI screens.
+
+Adjacent sans-display lane: light centered Hangul display heroes use
+Pretendard/SUIT/Wanted Sans at 300-400 **at display sizes only**
+(>= ~40px; FE-HERO-LIGHT-CENTER-01). Hairline Hangul below display scale is a
+legibility failure. This does not change the MaruBuri serif display band:
+MaruBuri keeps its own 400-600 range for editorial myeongjo headlines.
+
+Sources: hangeul.naver.com MaruBuri (명조/부리 category, 5 weights);
+notofonts/noto-cjk Serif KR; live checks 2026-07-09 found no myeongjo-led
+Korean AI product home (Brunch-class editorial products observed on sans).
+
+## Korean Formats
+
+- Dates: `2026년 5월 10일`, `5월 10일`, `오후 9:41`.
+- Counts: use Arabic numerals, Korean units where natural: `3개`, `1.2만`, `3억`.
+- Currency: `1,234,567원`.
+- Phone-like examples should use Korean patterns when relevant: `010-1234-5678`.
+
+Use locale-aware formatters when possible rather than hand-building strings.
+
+## Mobile Patterns
+
+Korean mobile product flows commonly expect:
+
+- bottom sheets for lightweight choices
+- full-screen flows for complex funnel steps
+- sticky bottom actions for primary submit/continue
+- snackbar/toast for reversible or low-risk confirmations
+- pull-to-refresh where feed/list mental models exist
+- safe-area handling on modern mobile devices
+
+Do not use a modal for every decision.
+
+## Copy
+
+For Korean copy, read `ux-writing-ko.md`. The short version:
+
+- familiar words
+- direct recovery actions in errors
+- feature purpose over internal feature names
+- minimal honorifics
+- no translationese
+- no childish friendliness in high-trust flows
+
+## Verified 2026 Additions (2026-07-02)
+
+- **Pretendard** remains a strong Korean-first default; current release line includes
+  `Pretendard Variable` 1.3.9. Do not claim it as "the standard of Toss/당근" without a
+  product-specific source — verify brand font rules per product.
+- **W3C KLREQ** (Korean Layout Requirements) has a 2026-03-21 note version — the
+  authoritative reference for Korean line-breaking and orphan rules.
+- **Rendered screenshot gate**: after responsive changes, verify `word-break: keep-all`,
+  `text-wrap: balance` on short descriptors, and no lone particles/endings ("합니다.",
+  "화.") at target viewports. No browser API detects Korean orphans — screenshots are the gate.
+
+| Claim | Source | Checked |
+|---|---|---|
+| Pretendard Variable 1.3.9 | https://github.com/orioncactus/pretendard | 2026-07-02 |
+| KLREQ note 2026-03-21 | https://www.w3.org/TR/klreq/ | 2026-07-02 |
+| keep-all CJK behavior | https://developer.mozilla.org/en-US/docs/Web/CSS/word-break | 2026-07-02 |

package/skills/ima2-front/references/layout-discipline.md

@@ -0,0 +1,161 @@
+# Layout Discipline Rules
+
+## Hero Discipline (MANDATORY)
+1. Hero MUST fit initial viewport — headline ≤2 lines, subtext ≤20 words, CTA visible
+2. Font-scale: plan font + image together; default text-4xl md:text-5xl lg:text-6xl
+3. Top padding cap: max pt-24 (6rem) at desktop
+4. Stack discipline: max 4 text elements (eyebrow|brand-strip, headline, subtext, CTAs)
+5. Banned inside hero: tagline below CTAs, trust strip, pricing teaser, feature bullets
+6. "Used by" logo wall → separate section directly below hero
+
+## Hero Composition Grammar (verified 2026-07-09)
+
+The classic SaaS split hero — left bold headline + subcopy + CTA, right boxed
+product screenshot/mockup card — is the exhausted Stripe(2020)->Linear(2023)
+template lineage; "Linear Design" is now a reproducible kit/template category
+(LogRocket 2026-02-03). Treat it as a slop signal on brand/product homepages.
+**FE-HERO-SPLIT-01: never choose a split hero unprompted — build one ONLY when
+the user explicitly requests a split/2-column hero.** The one context where it
+is worth *proposing* is a conversion-focused paid-acquisition landing page
+where 5-second clarity beats brand memorability (Unbounce anatomy) — but even
+there, suggest it and let the user decide; no universal A/B evidence favors
+either shape (VWO). "This looks like a landing page" is NOT an exception.
+
+Core inversion (DEFAULT): **the product visual is the STAGE, not a polite
+right-column card.** Choose from the verified replacement menu (heroes
+live-checked 2026-07-09):
+
+| Composition | Shape | Verified users |
+| --- | --- | --- |
+| Centered stacked over media | centered headline + CTA over full-width media/video/canvas | OpenAI, Dia, Framer, Raycast |
+| Product-as-stage | headline spans the width; huge product UI rises full-width BELOW, not beside | Linear, Cursor |
+| Editorial opener | large text-led mission headline, no screenshot; editorial modules follow | Anthropic |
+| Evolved split | copy left + giant animated canvas/visual behind/right — never a boxed screenshot card | Stripe, Vercel |
+| Full-bleed consumer hero | centered copy over full-bleed photography/brand imagery | Toss |
+
+Rules (DEFAULT):
+- Without an explicit user request for a split hero (FE-HERO-SPLIT-01), do not
+  place a boxed screenshot, media, or device-mockup card in a right column of
+  the hero. If the product must appear in the first viewport, make it
+  full-width, background, environment, or an interactive demo surface.
+- **FE-HERO-LIGHT-CENTER-01 (DEFAULT): Light Centered Display Hero.** A centered
+  hero headline is allowed as an intentional named pattern when the headline is
+  LIGHT weight (300-400, explicitly not bold), set over a full-width real media
+  or motion backdrop (photography, generated texture, or video; never a
+  gradient wash), with generous whitespace and a minimal copy stack (FE-HERO-01
+  copy budget still applies). Evidence: OpenAI announcement grammar; aside.com
+  measured 2026-07-10 with a custom display variable font, weight 400, 36px,
+  centered, over soft sky photography. The generic centered BOLD hero plus
+  template composition remains banned. This exception exists ONLY when the
+  light-weight headline and authored-media backdrop conditions both hold.
+  Composition ownership lives here; type exemplar details live in
+  `aesthetics.md` / `design-isms.md`.
+- Korean note: "left bold Pretendard headline + right mockup" is the same dead
+  template in Korean surfaces; Toss itself uses centered copy over full-bleed
+  imagery, not a split.
+- Replacement trend labels: story-driven heroes, scrollytelling, immersive 3D,
+  dimensionality/layers (SaaSFrame / Figma / Digidop / Contra, 2025-2026).
+
+Sources: LogRocket "Linear Design" (2026-02-03); Nordcraft "why do all websites
+look the same" (2024-09-03); Rectangle "The Linear effect" (2023-01-10); live
+hero inspections of openai.com, linear.app, cursor.com, anthropic.com,
+stripe.com, vercel.com, raycast.com, diabrowser.com, framer.com, toss.im
+(2026-07-09); Unbounce landing-page anatomy; VWO A/B testing guide.
+
+## Eyebrow Restraint (MANDATORY)
+- Maximum 1 eyebrow per 3 sections (hero counts as 1)
+- Pre-flight mechanical check: count uppercase+tracking instances ≤ ceil(sectionCount / 3)
+- Alternative: drop the eyebrow. Headline alone is enough.
+
+## Section Layout Repetition Ban
+- Each layout family (3-col cards, split-text-image, full-width-quote, etc.) at most ONCE per page
+- 8-section page needs ≥4 different layout families
+- Cross-ref: aesthetics.md § Spatial Composition also bans 3-col cards and
+  centered heroes, except the named FE-HERO-LIGHT-CENTER-01 pattern above.
+
+## Zigzag Alternation Cap
+- Max 2 consecutive left-image/right-text alternating sections
+- 3rd consecutive = fail. Break with full-width, vertical-stack, bento, or different family
+- Note: aesthetics.md recommends zigzag as alternative to 3-cards — that's fine for 1-2 uses, this rule caps overuse
+
+## Split-Header Ban
+- "Left big headline + right small explainer paragraph" as section header: BANNED as default
+- Stack vertically: headline on top, body below, max-width 65ch
+
+## Bento Rules
+- Cell count: EXACTLY as many cells as content items. No empty cells.
+- Background diversity: ≥2-3 cells need real visual variation (image, gradient, pattern)
+- Rhythm: no one-sided repetition (6 left-image/right-text rows)
+
+### Bento Composition (FE-BENTO-01, DEFAULT)
+
+A bento is one composed object, not a pile of cards. Catch these failures before styling:
+
+- **Ragged rows**: cells in the same visual row ending at different heights with dead air below the short ones. Compose on an explicit grid (`grid-template-rows` / `grid-row: span n`) so every row edge lands on a shared line. If a cell can't fill its slot, its span is wrong or its content is thin.
+- **Uniform-span monotony**: 6+ cells all 1x1 is a card grid wearing a bento costume. A real bento has 1 dominant cell (2x2 or 2x1) and clear size hierarchy: big = most important, not "whatever fit".
+- **Span-content mismatch**: cell size must track content weight. A 2x2 cell holding one metric, or a 1x1 cell with a cramped 4-row table, both fail. Resize the cell or recut the content.
+- **Orphan tail row**: last row with 1 cell + void. Re-span the tail cell to full width or merge its content upward.
+- **Sealed-box syndrome**: every cell = same radius + same border + same padding + same background. Vary surface treatment: let 1-2 cells go borderless, let an image bleed to cell edges, let one cell be a flat stat with no chrome.
+- **Density whiplash**: one cell packed with a data table next to a cell holding 3 words. Balance per-cell content weight before styling.
+- **Gap drift**: one `gap` value for the whole bento, followed by random local margins, breaks the object illusion.
+
+**Pre-ship check**: screenshot the bento, squint. If it reads as one interlocking slab, pass. If it reads as boxes floating near each other, recompose spans before touching colors.
+
+## Section Content Limits
+- Default per section: short headline (≤8 words) + sub-paragraph (≤25 words) + one visual/CTA
+- Long lists (>5 items): use cards/tabs/accordion/scroll-snap/carousel, not default <ul>
+- Carousel is for browsing long homogeneous lists (product catalog, image gallery), NOT a default response to "복잡한" or "complex" briefs. If Design Read does not specify list-browsing UX, do not add carousels.
+- Spec sheets: 2-col card grid, scroll-snap pills, grouped chunks, or featured-vs-rest
+- Quotes: max 3 lines, attribution = name + role [+ company]
+
+## Page Containment (MANDATORY)
+See `responsive-viewport.md` for the canonical containment rule (`max-w-[1400px] mx-auto`) and full explanation. Full-bleed sections break out with `w-screen` or negative margins; content inside stays contained.
+
+## Responsive Transforms by Section Type (MANDATORY)
+
+Every section type MUST declare its behavior at each viewport tier. "Tailwind handles it" is not a responsive strategy.
+
+### Hero
+- **Desktop (≥1024px)**: Side-by-side text+image or full-bleed. `text-4xl md:text-5xl lg:text-6xl`.
+- **Tablet (768-1023px)**: Stack image behind/above, text below. One font-scale step down.
+- **Mobile (<768px)**: Vertical stack. Image max 60vh. `text-3xl` max. Subtext ≤15 words. CTA visible without scroll. Full-width button.
+
+### Split Text-Image (60/40, 50/50)
+- **Desktop**: Side-by-side columns.
+- **Tablet**: Side-by-side if container ≥900px with tighter gap; stack if container <900px (use `@container`, not viewport).
+- **Mobile**: Always stack. Image first (product/visual), text first (story/narrative). Never side-by-side.
+
+### Multi-Column Cards/Features (3+ columns)
+- **Desktop**: `grid-cols-3` or `grid-cols-4`.
+- **Tablet**: `grid-cols-2`.
+- **Mobile**: `grid-cols-1`. Limit visible to 3-4 cards; rest behind "Show more" or horizontal scroll-snap.
+
+### Full-Width Quote
+- **Desktop**: Large text, generous padding.
+- **Tablet**: Same layout, one font-scale step down.
+- **Mobile**: `text-xl` max. `px-6`. Attribution inline below quote.
+
+### Bento Grid
+- **Desktop**: Multi-cell asymmetric layout.
+- **Tablet**: Reduce to 2-column grid.
+- **Mobile**: Single column. Each cell full-width.
+
+### Zigzag (Alternating Left/Right)
+- **Desktop**: Left/right alternation.
+- **Tablet**: Same if container ≥900px, else stack (use `@container`).
+- **Mobile**: Always stack. Consistent order (no alternation). Pick image-then-text or text-then-image and keep it.
+
+### CTA Section
+- **Desktop**: Centered with breathing room.
+- **Tablet**: Same, tighter padding.
+- **Mobile**: Full-width button. Remove decorative elements. Consider sticky bottom bar (see `mobile-ux.md`).
+
+### Logo Wall
+- **Desktop**: Horizontal row or multi-row grid.
+- **Tablet**: Wrap to 2 rows if needed.
+- **Mobile**: Horizontal scroll-snap marquee or compact 2×3 grid. No orphan cells.
+
+### Pricing/Spec Grid
+- **Desktop**: 2-3 column card layout.
+- **Tablet**: 2 columns.
+- **Mobile**: 1 column. Featured plan first. Comparison table → accordion.

package/skills/ima2-front/references/liquid-glass.md

@@ -0,0 +1,181 @@
+# Liquid Glass & Translucent Materials - Implementation Guide
+
+Implementation rules for Apple-class translucent materials ("Liquid Glass"),
+classic glassmorphism, and the cheaper pill-over-imagery alternative.
+Sources: Apple HIG Materials + aside.com rendered measurements + dcinside
+practitioner notes (verified 2026-07-07; evidence:
+`devlog/_fin/260707_liquid_glass_motion_trends/000_research.md`).
+Design judgment (is glass domain-correct at all?) is owned by
+`ima2-uiux` - this file owns material recipes. Top-bar composition,
+slots, and scroll choreography live in `references/core/top-bar.md`.
+
+---
+
+## Layer Discipline (FE-LIQUID-LAYER-01, DEFAULT)
+
+Apple's 2025-2026 material system treats glass as a **functional-layer
+material**, and the rule ports directly to the web:
+
+- Glass belongs to floating **controls and navigation**: sticky headers, tab
+  bars, sidebars, floating toolbars, command palettes, media overlays.
+  Content scrolls and "peeks through" beneath it - that is the entire point.
+- **Never in the content layer.** Cards-as-content, app backgrounds, article
+  panels, and form bodies use solid or standard translucent surfaces, not
+  glass. Glass-on-everything flattens hierarchy and reads as 2026 AI slop.
+  Exception: a transient interactive element (slider/toggle mid-interaction)
+  may momentarily adopt glass to emphasize interactivity.
+- **Use sparingly.** One glass layer class per viewport region. If two glass
+  surfaces stack, the lower one loses its meaning; merge, solidify, or demote
+  one.
+- Prefer named material states over generic "regular glass" decisions. Text
+  chrome defaults to near-opaque pill material; highly transparent glass is a
+  media-overlay exception, not the baseline.
+
+## Named Material States (FE-LIQUID-STATE-01, DEFAULT)
+
+| State | Legal Use | Material Contract |
+| --- | --- | --- |
+| `pill-at-top` | Text-bearing top bar ONLY while resting over a hero authored with a calm bar zone. | Pill chrome at about 70-80% opacity. No busy imagery, hard contrast, or scrolling content may sit beneath text. |
+| `pill-scrolled` | Default text-bearing chrome state once content can pass beneath the bar. | Near-opaque 85-95% surface with blur 12-16px when blur is affordable; may collapse to blur-free near-opaque. |
+| `media-overlay` | Media/photo/video controls where the image remains the subject. | The old canvas-55% regular recipe, demoted to overlay chrome only. Avoid dense text. |
+| `clear` | Sparse, large controls over rich media only. | No blur backing; tint/border only. Never for text-heavy nav, menus, forms, or body content. |
+
+Scroll-adaptive top bars transition from `pill-at-top` to `pill-scrolled` by
+animating background-color/opacity only. Do not morph size, radius, padding, or
+layout on a blurred bar; that belongs in `top-bar.md` composition planning and
+is also a performance constraint below.
+
+Bar-spawned surfaces (dropdowns, menus, popovers, combobox panels, date pickers,
+and hover/tap-revealed chrome) are **unconditionally near-opaque, blur-free
+SOLID**. They do not inherit `pill-at-top`, `pill-scrolled`, `media-overlay`, or
+`clear`. This resolves glass-on-glass stacking and preserves the <= 2 visible
+blurred-surfaces budget.
+
+## Pill Nesting (FE-PILL-NEST-01, DEFAULT)
+
+Inside a pill container (border-radius >= 24px or the `9999px` chrome class),
+child elements must NOT render their own capsule border or outline at rest. The
+`( () () () )` nested-ring look is banned.
+
+This is a visual border/outline rule, not a functional ban:
+
+- Solid fills are not restricted by this rule, at any count.
+- One-primary-action and accent-budget hierarchy rules still apply on top.
+- The container's own single hairline border stays legal.
+- Shadow-only children are legal.
+- Hover, active, and `aria-current` fills/tints are legal at rest.
+
+## CSS Recipes (STYLE_SAMPLE)
+
+```css
+/* pill-at-top - text-bearing top bar over an authored calm hero zone */
+.liquid-pill-at-top {
+  background: rgb(255 255 255 / 0.76);
+  border: 1px solid rgb(255 255 255 / 0.26);
+  border-radius: 9999px;
+  box-shadow: inset 0 1px 0 rgb(255 255 255 / 0.16),
+              0 8px 28px rgb(0 0 0 / 0.10);
+}
+
+/* pill-scrolled - default text-bearing chrome */
+.liquid-pill-scrolled {
+  background: rgb(255 255 255 / 0.90);
+  backdrop-filter: blur(14px) saturate(1.25);
+  -webkit-backdrop-filter: blur(14px) saturate(1.25);
+  border: 1px solid rgb(255 255 255 / 0.24);
+  border-radius: 9999px;
+  box-shadow: inset 0 1px 0 rgb(255 255 255 / 0.14),
+              0 10px 32px rgb(0 0 0 / 0.12);
+}
+
+/* media-overlay - old "regular glass", now only for media/photo overlay chrome */
+.liquid-media-overlay {
+  background: color-mix(in oklab, canvas 55%, transparent);
+  backdrop-filter: blur(16px) saturate(1.4);
+  -webkit-backdrop-filter: blur(16px) saturate(1.4);
+  border: 1px solid rgb(255 255 255 / 0.18);
+  box-shadow: inset 0 1px 0 rgb(255 255 255 / 0.12),
+              0 8px 32px rgb(0 0 0 / 0.12);
+}
+
+/* clear - sparse controls over rich media only */
+.liquid-clear {
+  background: rgb(255 255 255 / 0.10);
+  border: 1px solid rgb(255 255 255 / 0.25);
+  /* no backdrop-filter: content behind stays crisp */
+}
+
+/* bar-spawned menu/popover/select surface */
+.chrome-surface-solid {
+  background: rgb(255 255 255 / 0.96);
+  border: 1px solid rgb(0 0 0 / 0.08);
+  border-radius: 18px;
+  box-shadow: 0 18px 48px rgb(0 0 0 / 0.16);
+}
+
+/* blur-free pill chip - aside.com pattern */
+.pill-chip {
+  background: rgb(255 255 255 / 0.92);
+  border-radius: 9999px;
+  box-shadow: 0 2px 12px rgb(0 0 0 / 0.08);
+}
+```
+
+### Glass without blur (aside.com pattern, measured 2026-07-07)
+
+The user-visible "liquid glass feel" often needs NO backdrop-filter at all.
+aside.com renders 0 `backdrop-filter` elements site-wide; the material feel
+comes from **opaque/translucent white pills and rounded cards floating over
+soft photographic or pastel-gradient backgrounds**.
+
+Prefer this pattern when: many chips/cards per viewport, mid/low-end device
+targets, or text-heavy chips - it is cheaper, more legible, and still reads
+as the 2026 Apple-pastel language.
+
+### Pill geometry (STYLE_SAMPLE, aside.com measured)
+
+Rounded systems read as designed when radii form a small scale, not one
+global value: e.g. 8px (inputs, small cards) / 12px (cards) / 16-20px
+(containers, modals) + `9999px` pill class for chips, CTAs, and eyebrows.
+Interactive chips are pills; page-level containers take the largest tier.
+Do not mix a pill CTA with a 4px-radius input in the same cluster.
+
+## Performance Gate (FE-LIQUID-PERF-01, DEFAULT)
+
+Conservative local guidance. The cost model below is Tier-1 corroborated,
+not locally benchmarked (see the research doc in the header) - treat
+`backdrop-filter` as expensive by default until profiling says otherwise:
+
+- Keep blurred surfaces **small**: chrome bars and chips, never full-page
+  overlays or hero-sized panels.
+- Keep radius modest (12-16px for pill chrome; 8-20px broader range); expect
+  cost to grow with blurred area and radius.
+- Avoid `backdrop-filter` on elements inside scrolling containers or on
+  elements that animate size, position, radius, padding, or layout; scroll
+  state changes on blurred bars animate background-color/opacity only.
+- Per-viewport budget: aim for <= 2 backdrop-filtered surfaces visible at
+  once; prefer blur-free near-opaque surfaces beyond that.
+- Profile on a mid-range phone before shipping any glass-heavy surface; if
+  scrolling stutters, swap blurred states for near-opaque solid surfaces first.
+
+## Accessibility Gate (FE-LIQUID-A11Y-01, STRICT)
+
+This gate is supreme over all named states. Under reduced-transparency or
+high-contrast preferences, every translucent state collapses to solid or
+near-opaque; state names do not override the user preference.
+
+- Honor user material preferences: reduce or remove translucency under
+  `@media (prefers-reduced-transparency: reduce)` (check current browser
+  support before relying on it; provide a solid fallback background
+  regardless) and raise surface opacity under `@media (prefers-contrast:
+  more)`.
+- **Contrast on translucent states is unprovable from tokens alone**: text
+  over `pill-at-top`, `pill-scrolled`, `media-overlay`, or `clear` must pass
+  WCAG contrast against the WORST-case background that can appear beneath it.
+  Verify with a rendered screenshot over the busiest background state, not
+  against the tint color. Unconditionally opaque spawned surfaces are audited
+  for normal contrast, not translucency.
+- Blur is not a contrast tool. If text needs the blur to be readable, the
+  surface opacity is too low.
+- `backdrop-filter` failures (unsupported engines) must degrade to a solid
+  or near-opaque background via `@supports not (backdrop-filter: blur(1px))`.