ima2-gen 2.0.15 → 2.0.16

package/skills/ima2-front/references/brand-asset-sourcing.md

@@ -0,0 +1,122 @@
+# Brand Asset Sourcing — Logos, Icons & SVGs
+
+How to source, use, and handle brand logos in integration/partner sections.
+For anti-slop detection of generic icon substitution, see the Iconography Audit section in `anti-slop.md`.
+
+---
+
+## The Problem with Generic Icons
+
+Using generic stroke icons (Lucide, Heroicons, Feather) as substitutes for brand logos is **always wrong**. A checkmark circle is not Kubernetes. A rectangle is not Docker. A layer stack is not AWS.
+
+Brand logos are recognition signals. Generic substitutes look lazy, undermine trust, and signal AI-generated design.
+
+---
+
+## Official Brand SVG Sources (MIT Licensed)
+
+| Library | Coverage | Best For | URL |
+|---------|----------|----------|-----|
+| **Simple Icons** | 3,400+ brands | Broadest coverage, monochrome SVG + official hex | simpleicons.org |
+| **SVGL** | 400+ icons | Light/dark variants, public API | svgl.app |
+| **theSVG** | 4,000+ brands | Multi-variant (color, mono, wordmark), MCP integration | thesvg.org |
+
+All MIT-licensed. Safe for integration sections.
+
+```bash
+npm install simple-icons  # All 3400+ SVGs as JS objects
+```
+
+**Production recommendation:** Self-host SVGs rather than CDN for performance and reliability.
+
+---
+
+## Company Press Kits
+
+When libraries don't have the brand:
+- Search for "[Company] press kit" or "[Company] brand guidelines"
+- CNCF artwork repo for Kubernetes, Prometheus, etc.
+- AWS icons at aws-icons.com
+- Brandfetch for aggregated brand assets
+
+---
+
+## Legal: Fair Use for Integration Sections
+
+Using brand logos in "integrates with" or "trusted by" sections is generally safe under nominative fair use if:
+
+1. **Necessary** — The brand can't be identified without the mark
+2. **Not confusing** — No suggestion of endorsement or affiliation
+3. **Proportional** — Logo is small, in supporting role
+
+**Safe:** "We support Kubernetes deployments" with small logo
+**Risky:** "Official Kubernetes Partner" with large featured logo
+
+---
+
+## AI Agent Strategy: What To Do When You Can't Access Real Assets
+
+### Strategy 1: Use Official Libraries (Preferred)
+
+If the brand exists in Simple Icons, SVGL, or theSVG, reference the CDN URL or npm package directly.
+
+### Strategy 2: Placeholder with Explicit TODO
+
+```html
+<!-- TODO: Replace with official [BrandName] SVG
+     Source: [BrandName] press kit or simpleicons.org
+     Do NOT ship with this placeholder. -->
+<div class="logo-placeholder" aria-label="BrandName">
+  <span>BrandName</span>
+</div>
+```
+
+### Strategy 3: Ask the User
+
+Report which brands are available in libraries and which need manual sourcing.
+
+### What Agents Must NEVER Do
+
+- Silently substitute generic stroke icons for brand logos
+- Ship without flagging missing brand assets
+- Use approximate icon shapes ("close enough")
+
+---
+
+## Fallback Hierarchy
+
+| Priority | Approach | When |
+|----------|----------|------|
+| 1 | Official library SVG (Simple Icons, SVGL) | Brand exists in library |
+| 2 | Company press kit SVG | Brand not in library, press kit exists |
+| 3 | Text-only label | No SVG available |
+| 4 | Brand color + text | Visually distinctive without logo |
+| 5 | Placeholder + TODO | Temporary, must be resolved before production |
+
+**Text-only is ALWAYS better than a generic icon.** A wrong icon is worse than no icon.
+
+Integration logo walls use brand assets, not icon rows. See also `asset-requirements.md`.
+
+---
+
+## Dark Mode Handling
+
+```css
+[data-theme="dark"] .logo-item img {
+  filter: brightness(0) invert(1);
+}
+```
+
+For multi-variant support, prefer SVGL or theSVG which ship separate light/dark SVGs.
+
+---
+
+## Captured Reference Material vs Shippable Assets
+
+Assets harvested from other sites (HTML, CSS, imagery, fonts) via
+`reference-capture.md` are ANALYSIS-ONLY: they ground structure analysis and
+ima2 mockup references, and they never ship. Webfont binaries are never copied
+(license-restricted by default). Shippable brand assets come only from the
+channels in this file (press kits, Simple Icons/SVGL, licensed libraries), and
+nominative fair use covers shipped integration logos only. Every capture needs
+the provenance manifest defined in `reference-capture.md`.

package/skills/ima2-front/references/color-system.md

@@ -0,0 +1,132 @@
+# Color System — Token Implementation Mechanics
+
+Implementation owner for color tokens: layering, modern color functions,
+framework wiring, and contrast verification. Palette GENERATION and judgment
+(hue budget, scales, tools) are owned by
+`dev-uiux-design/references/color-system.md` — read it for what colors to
+pick; read this for how to ship them. Runtime theme selection, FOWT
+prevention, and toggle behavior stay in `theme-switching.md`.
+Feature facts below verified 2026-07-07 (MDN/Tailwind/shadcn/W3C, Tier 2).
+
+---
+
+## Token Layering (FE-COLOR-TOKEN-01, DEFAULT)
+
+Three layers, referenced downward only:
+
+1. **Primitive** — raw scale values, no meaning: `--blue-600`, `--gray-100`.
+2. **Semantic** — meaning, theme-switchable: `--background`, `--primary`,
+   `--primary-foreground`, `--border`, `--danger`.
+3. **Component** — scoped knobs derived from semantic: `--button-bg`,
+   `--card-border`.
+
+Rules: components consume SEMANTIC tokens (or their own component tokens),
+never primitives; hardcoded colors in component CSS are a review finding
+(theme-ready enforcement); dark/alt themes redefine SEMANTIC tokens only.
+
+```css
+:root {
+  /* primitives */
+  --blue-600: oklch(0.58 0.22 260);
+  /* semantic */
+  --background: oklch(1 0 0);
+  --primary: var(--blue-600);
+  --primary-foreground: oklch(0.99 0 0);
+}
+.dark {
+  --background: oklch(0.145 0 0);
+  --primary: oklch(0.70 0.18 260);
+}
+.button-primary {
+  --button-bg: var(--primary);
+  --button-bg-hover: color-mix(in oklch, var(--primary) 88%, black);
+  background: var(--button-bg);
+  color: var(--primary-foreground);
+}
+```
+
+## Accent Surface Emphasis (FE-COLOR-ACCENT-SURFACE-01, DEFAULT, verified 2026-07-09)
+
+Emphasized/highlighted panels on opaque functional UI use a FLAT emphasis
+channel, never a gradient fill (see `anti-slop.md` FE-GRADIENT-02). Pick exactly
+one channel per surface:
+
+1. **Flat alpha/step tint** — accent at ~4-8% over the surface, or a dedicated
+   low-step token. Radix uses accent steps 3-5 for component backgrounds and
+   6-8 for borders; Primer ships `--bgColor-accent-muted: #ddf4ff` with
+   `--borderColor-accent-muted: #54aeff66`; shadcn defines flat
+   `--accent: oklch(0.97 0 0)` (dark `oklch(0.269 0 0)`) surfaces.
+2. **Border/ring emphasis** — neutral surface, accent moves to the edge:
+   selected -> `border-color: var(--accent-border)` (Geist pattern), or
+   Tailwind-style `ring-2` + shadow for an emphasized tier.
+3. **Left/top accent bar** — neutral panel body, brand color confined to a
+   small stable indicator (`border-left: 3px solid var(--brand)`; Stripe Apps
+   pattern).
+4. **Elevation** — shadow tokens (`--shadow-resting-*` / `--shadow-floating-*`,
+   Primer pattern) instead of decorative fills.
+5. **Semantic status token** — `background/border/text` role triplets per
+   status (information/success/warning/danger; Atlassian pattern) when the
+   emphasis carries meaning.
+
+```css
+/* flat tint + border, derived from semantic tokens — no wash */
+.panel-emphasis {
+  background: color-mix(in oklch, var(--primary) 6%, var(--background));
+  border: 1px solid color-mix(in oklch, var(--primary) 30%, var(--border));
+}
+```
+
+Field note (live-measured 2026-07-09): Toss/Kakao/Naver/Channel Talk/Daangn all
+style functional highlighted cards as flat solid/pastel tints with border 0-1px
+and little or no shadow; gradients appear only in hero backgrounds and
+illustration mockups.
+
+## Modern Color Functions (baseline status 2026-07-07)
+
+- `oklch()` — Baseline 2023. Default authoring space for new palettes:
+  perceptually uniform lightness, predictable scale steps.
+- `color-mix(in oklch, ...)` — Baseline 2023. Derive hover/pressed/disabled
+  states from semantic tokens instead of hardcoding shade variants.
+- `light-dark(<light>, <dark>)` — Baseline 2024; requires `color-scheme:
+  light dark`. Use for BROWSER-controlled two-mode color. For app-controlled
+  or multi-theme systems, use `.dark`/`[data-theme]` semantic redefinition
+  instead (see `theme-switching.md` for the runtime side).
+- `@supports (color: oklch(0.6 0.2 250))` is the feature gate primitive.
+
+## Fallback Discipline (FE-COLOR-FALLBACK-01, DEFAULT)
+
+`var(--token, fallback)` does NOT rescue a declaration whose variable holds an
+unsupported color function — the whole declaration is discarded at
+computed-value time. Gate by feature, not by var fallback:
+
+```css
+:root { --primary: #2563eb; }                       /* universal fallback */
+@supports (color: oklch(0.6 0.2 250)) {
+  :root { --primary: oklch(0.58 0.22 260); }         /* modern override */
+}
+```
+
+Or precompile fallbacks (PostCSS) when the toolchain already does so. Either
+way, the fallback lives at the PRIMITIVE layer so semantic/component layers
+stay function-agnostic.
+
+## Framework Wiring
+
+- **Tailwind v4** — CSS-first tokens via `@theme` (`--color-*` variables);
+  do not reintroduce JS config for colors. Semantic tokens defined in
+  `:root`/`.dark` map into utilities via `@theme inline`.
+- **shadcn/ui** — current convention is semantic CSS variables in OKLCH
+  mapped through `@theme inline`; follow the project's `components.json`
+  tokens; edit themes with tweakcn (see the uiux toolbox) rather than
+  hand-tuning hex.
+
+## Contrast Verification (FE-COLOR-CONTRAST-01, STRICT)
+
+Implementation gate pointing at the §7 accessibility baseline (WCAG AA
+contrast is already STRICT there): every text/background SEMANTIC pair — in
+EVERY theme — is verified against WCAG 2.2 AA (4.5:1 normal, 3:1 large/UI).
+`color-mix()`-derived states count as new pairs; verify them, not just the
+base. APCA/Lc is a useful advisory second check for perceptual readability
+(WCAG 3 is still a Working Draft as of 2026-07-07) — it does not replace the
+WCAG 2.2 gate. Translucent surfaces: worst-case-background rule in
+`liquid-glass.md` FE-LIQUID-A11Y-01 applies.

package/skills/ima2-front/references/consistency-locks.md

@@ -0,0 +1,20 @@
+# Consistency Locks (MANDATORY)
+
+## Color Consistency Lock
+Once accent color is chosen for a page, it is used on the WHOLE page.
+- Warm-grey site does not get blue CTA in section 7
+- Rose-accented site does not get teal badge in footer
+- Pick one accent, lock it, audit every component
+
+## Shape Consistency Lock
+Pick ONE corner-radius scale per page:
+- All-sharp (radius 0)
+- All-soft (radius 12-16px)
+- All-pill (full radius for interactive)
+Mixed systems only with documented rule (e.g., "buttons=pill, cards=16px, inputs=8px")
+
+## Page Theme Lock
+ONE theme (light/dark/auto) for the whole page. No section inversions.
+- Section-level background tints within same family OK (zinc-950 next to zinc-900)
+- Flipping to amber-50 in middle of zinc-950 page = broken
+- Exception: one deliberate "color block story" transition per page, if brief demands

package/skills/ima2-front/references/crud-ui.md

@@ -0,0 +1,53 @@
+# CRUD UI Basics — Ordinary Screen Slice
+
+On-demand reference for C2 list/detail/form screens. These are product surfaces, not
+marketing pages — objective UX states matter; visual styling follows the repo's existing
+system (style presets are STYLE_SAMPLE, never requirements).
+
+## State coverage (DEFAULT — the actual quality bar)
+
+Every data-driven view handles all of:
+
+| State | List view | Form/mutation |
+|-------|-----------|---------------|
+| Loading | Skeleton/spinner consistent with repo pattern | Disabled submit + pending indicator |
+| Empty | Honest empty state with the next action | — |
+| Error | Retryable error with message | Field-level + form-level errors, input preserved |
+| Permission-denied | Hidden or explained, per product convention | Action disabled with reason |
+| Success | Data rendered, stable ordering | Confirmation + navigation/refresh per repo pattern |
+
+Missing states are review findings; pixel styling differences are not.
+
+## List + detail
+
+- Reuse the repo's existing table/list component and data-fetch pattern (query lib, store,
+  fetch wrapper) — do not introduce a new data layer for one screen.
+- Pagination/sort/filter UI only when the API provides it and the product needs it.
+- Detail view: deep-linkable when routing exists; 404/permission states handled.
+
+## Forms + mutations
+
+Form `<select>` and picker controls participate in the project dropdown design
+layer (`dropdown-layer.md` FE-DROPDOWN-LAYER-01): one unified skin over
+behavior-correct primitives, with labels, errors, autofill, and keyboard
+operability fully preserved.
+
+- Validation mirrors the API schema; client-side checks are UX sugar, the server stays the
+  source of truth.
+- Submit: prevent double-fire, show pending, surface server errors back into the form.
+- Destructive actions (delete) get an explicit confirm step; irreversible-data deletes are
+  an ESCALATE product decision, not a UI default.
+- Optimistic updates only where the repo already does them.
+
+## Objective UX gates (STRICT/DEFAULT — separate from taste)
+
+- Keyboard: form fully operable by keyboard; visible focus states.
+- Labels: every input has an accessible label; errors are announced/associated.
+- Contrast meets the repo's accessibility baseline.
+
+## Verification (C2 default)
+
+- UI smoke for the changed screen (manual click-through or one Playwright run when UI risk
+  is real — risk-tier rule, not a universal blocker).
+- One negative check: a failing submit shows errors without losing input.
+- See `dev-testing/references/core/crud-test-matrix.md`.

package/skills/ima2-front/references/dropdown-layer.md

@@ -0,0 +1,110 @@
+# Dropdown Design Layer - Implementation Guide
+
+Canonical owner for the unified dropdown DESIGN LAYER: visual skin and scope.
+ARIA and keyboard patterns stay in `a11y-patterns.md`; material rules stay in
+`liquid-glass.md`; mobile sheet behavior stays in `mobile-ux.md`; form workflow
+gates stay in `crud-ui.md`.
+---
+## Unified Skin (FE-DROPDOWN-LAYER-01, DEFAULT)
+On projects with a custom design surface, recommend one unified custom dropdown
+design layer over browser-default dropdowns: ONE visual skin across nav menus,
+filter dropdowns, form `<select>`, comboboxes, search suggestions, date pickers,
+and mobile pickers.
+The shared skin contract:
+- Near-opaque solid surface, following the bar-spawned surface rule in
+  `liquid-glass.md` `FE-LIQUID-STATE-01`.
+- Blur-free by default; do not inherit top-bar transparency states.
+- Radius tier from the project scale, usually 12-20px for panels.
+- One shadow language for elevation; avoid stacking multiple nested shadows.
+- Typography aligned to the product UI scale, not decorative hero type.
+- Short, calm motion: opacity/translate only, usually 120-180ms.
+- Item hover, active, selected, and focus states use fill/tint, not rest-state
+  capsule borders inside the panel.
+
+Dropdown panels follow the same fills-not-borders convention as
+`FE-PILL-NEST-01` (whose canonical scope is pill containers with radius
+>= 24px / the 9999px chrome class): child rows and controls render no capsule
+borders or outlines at rest, even though panels themselves sit in the 12-20px
+radius tier. Hover, active, selected, and `aria-current` fills remain legal.
+## Skin Is Not Behavior
+One SKIN does not mean one ARIA pattern.
+Behavior comes from a behavior-correct headless or proven primitive selected
+for the pattern: menu, listbox/select, combobox, date picker, or the repository's
+equivalent. Prefer Radix, React Aria, Base UI, mature design system primitives,
+or the existing local primitive layer.
+
+Hand-rolled dropdown behavior is banned for production UI. Do not invent focus
+management, typeahead, roving tabindex, escape handling, or outside-click
+closing from scratch.
+## Design System Precedence
+Design System Detection in `dev-frontend/SKILL.md` Section 12 wins.
+When MUI, Carbon, Fluent, Ant Design, Chakra, Mantine, Polaris, or a comparable
+system governs the project, unify by theming that system's menus, selects,
+popovers, comboboxes, and pickers. Do not rebuild them just to get a custom
+skin unless the project already has an approved headless replacement path.
+## Scope Table
+| Surface | Primitive | Skin notes |
+| --- | --- | --- |
+| Nav menu | Menu / navigation menu primitive | Near-opaque spawned panel; tap path required for hover menus; no glass transparency. |
+| Filter dropdown | Menu, listbox, or popover with controls | Same panel shell; preserve checkbox/radio state clarity and dense scanning. |
+| Form select | Select / listbox primitive | Skin trigger and panel while preserving label, error, autofill, name/value, and keyboard behavior. |
+| Combobox / search | Combobox primitive | Same panel shell; suggestions, loading, empty, and selected states share item tokens. |
+| Date picker | Date picker / calendar primitive | Same outer shell; calendar grid may use its own selected-day fill and focus ring. |
+| Mobile picker | Sheet / drawer / native-safe picker primitive | Same skin translated to a bottom sheet; no hover dependency or nested scrolling. |
+## Mobile Contract
+Mobile uses the same dropdown skin as the bottom sheet surface. Hover-spawned
+desktop menus need a tap alternative on touch devices. Use a sheet, drawer,
+popover picker, or proven mobile picker primitive with correct focus, dismissal,
+and scroll locking. Avoid nested scrolling: the sheet owns the scroll area, and
+internal option lists are bounded only when the primitive handles them cleanly.
+See `mobile-ux.md`.
+## Form Semantics
+Skinned form selects still behave like form controls. They keep visible and
+programmatic labels, helper text, validation errors, disabled/read-only states,
+autofill where relevant, keyboard operability, and stable submission semantics.
+The visual layer must not break `crud-ui.md` gates: users can scan a form, see
+required/error states, tab through fields, open a select, choose, recover from
+errors, and submit without pointer-only behavior.
+## CSS Tokens (STYLE_SAMPLE)
+```css
+:root {
+  --dropdown-surface: rgb(255 255 255 / 0.96);
+  --dropdown-border: rgb(17 24 39 / 0.08);
+  --dropdown-radius: 16px;
+  --dropdown-shadow: 0 18px 48px rgb(15 23 42 / 0.16);
+  --dropdown-hover: rgb(15 23 42 / 0.06);
+  --dropdown-active: rgb(15 23 42 / 0.10);
+  --dropdown-focus: rgb(37 99 235 / 0.22);
+  --dropdown-motion: 140ms ease;
+}
+.dropdown-surface {
+  background: var(--dropdown-surface);
+  color: rgb(17 24 39);
+  border: 1px solid var(--dropdown-border);
+  border-radius: var(--dropdown-radius);
+  box-shadow: var(--dropdown-shadow);
+  font: inherit;
+}
+.dropdown-item {
+  border: 0;
+  border-radius: 8px;
+  background: transparent;
+  transition: background-color var(--dropdown-motion), color var(--dropdown-motion);
+}
+.dropdown-item:hover,
+.dropdown-item[data-highlighted] { background: var(--dropdown-hover); }
+.dropdown-item[aria-selected="true"],
+.dropdown-item[data-state="checked"] { background: var(--dropdown-active); }
+.dropdown-item:focus-visible {
+  outline: 2px solid var(--dropdown-focus);
+  outline-offset: 2px;
+}
+```
+## Verification Hooks
+Check the keyboard path per primitive: tab entry/exit, arrows where expected,
+typeahead or text input behavior, escape close, trigger focus return, and form
+submission for selects.
+Render the dropdown over the busiest background it can cover and verify normal
+contrast, item state contrast, focus visibility, and shadow separation.
+On mobile, verify the sheet or picker tap path, scroll locking, no nested scroll
+trap, safe-area spacing, and reduced-motion behavior.

package/skills/ima2-front/references/i18n-global.md

@@ -0,0 +1,104 @@
+# Internationalization (i18n) Global
+
+## Architecture
+
+```
+src/locales/
+  ko.json     — Korean
+  en.json     — English
+  i18n.ts     — config + loader
+```
+
+- All user-facing strings in locale files — never hardcode in components
+- ICU message format for pluralization and interpolation
+- Namespace by feature: `{ "auth": { "login": "로그인" } }`
+- Fallback chain: user preference → browser locale → default locale
+- Libraries: `next-intl` (Next.js), `react-intl`, `i18next` (agnostic)
+
+## RTL Layout
+
+```html
+<html dir="rtl" lang="ar">
+```
+
+Use CSS logical properties everywhere:
+
+```css
+margin-inline-start: 1rem;     /* not margin-left */
+padding-inline-end: 0.5rem;    /* not padding-right */
+text-align: start;              /* not left */
+```
+
+- Flexbox `row` and Grid auto-reverse in RTL — no changes needed
+- Directional icons (arrows, progress): `transform: scaleX(-1)` in RTL
+- Non-directional icons (search, close): no change
+- Numbers always LTR: `direction: ltr; unicode-bidi: embed`
+- Never use `float: left/right` — use flexbox/grid
+
+## Pluralization
+
+| Language | Forms | Example |
+|----------|-------|---------|
+| English | one, other | 1 item, 2 items |
+| Korean | other | 1개, 2개 |
+| Arabic | zero, one, two, few, many, other | 6 forms |
+| Russian | one, few, many, other | 4 forms |
+
+```json
+{ "items": "{count, plural, =0 {No items} one {# item} other {# items}}" }
+```
+
+- Never concatenate for pluralization (`count + " items"`)
+- Test with 0, 1, 2, 5, 21 (catches most plural bugs)
+
+## Date, Number, Currency
+
+```javascript
+new Intl.DateTimeFormat('ko-KR', { dateStyle: 'long' }).format(date)
+// → "2026년 6월 8일"
+
+new Intl.NumberFormat('ko-KR', { style: 'currency', currency: 'KRW' }).format(50000)
+// → "₩50,000"
+```
+
+- Always use `Intl.DateTimeFormat` / `Intl.NumberFormat`
+- Currency symbol position varies by locale
+- Decimal separator varies: `.` (en), `,` (de, fr)
+- Relative dates: `Intl.RelativeTimeFormat`
+
+## Locale Switching UI
+
+- Dropdown in footer or settings
+- Show name in own script: "한국어", "English", "日本語"
+- Never use flags for languages (flags = countries, not languages)
+- Persist: localStorage + URL prefix (`/ko/about`, `/en/about`)
+- URL prefix strategy is best for SEO
+- Never auto-redirect by IP without an override
+
+## Content Expansion
+
+| Language | vs English | Risk |
+|----------|-----------|------|
+| German | +30% | Button/label overflow |
+| Finnish | +30-40% | Same |
+| Arabic | +20-25% | Plus RTL |
+| Chinese | -30 to -50% | Characters wider |
+
+- Design with 40% expansion headroom
+- Test with German pseudo-locale
+- Never fixed `width` on text containers — use `min-width` + flex
+- `text-overflow: ellipsis` + `title` tooltip as last resort
+
+## Pre-flight
+
+- [ ] All user-facing text in locale files, not hardcoded
+- [ ] CSS uses logical properties (`margin-inline-start`)
+- [ ] Dates/numbers use `Intl` API
+- [ ] Buttons/labels have 40% expansion headroom
+- [ ] Language switcher uses language names, not flags
+
+## Cross-references
+
+- Korean-specific: `korea-2026.md`
+- Korean UX writing: `ux-writing-ko.md`
+- CJK wrapping: `typography-wrapping.md`

package/skills/ima2-front/references/iterative-design.md

@@ -0,0 +1,90 @@
+# Iterative Design — LLM Limitations & Multi-Round Process
+
+How to overcome the statistical convergence problem inherent in LLM-generated design.
+Adapted from b1rdmania/claude-brand-skills enhanced frontend-design skill.
+
+---
+
+## The Convergence Problem
+
+Every design choice gravitates toward the statistical center of training data — the average of "good design."
+This produces competent, polished work that looks like EVERY other competent, polished work.
+
+### Why This Happens
+- **No visual feedback loop** — Writing HTML/CSS as text tokens. No perception of beauty or distinction.
+- **Optimized for coherence** — Training rewards consistency, polish, completeness. Deliberately rule-breaking design fights the model's weights.
+- **Can't feel tension** — Great experimental design creates productive discomfort. The model can't calibrate this.
+- **No taste** — Taste is judgment not reducible to rules. "This feels corporate" or "this needs to breathe" are embodied calls that can only be approximated with heuristics — and heuristics converge to the mean.
+- **Can generate divergence, can't evaluate it** — Can produce 10 structurally different layouts but genuinely cannot tell which one is "surprising AND right."
+
+### What This Means
+User direction and references are NOT optional — they ARE the design.
+The model is the hand, not the eye. User taste, references, and gut reactions push output somewhere it would never go alone.
+
+---
+
+## The Multi-Round Process
+
+**CRITICAL**: Never treat this as single-pass (brief → design → done). That guarantees convergence.
+
+For runnable implementation mechanics, read `prototype-variants.md`: this file owns
+creative divergence; that file owns `?variant=` routing, switchers, verification, and
+prototype cleanup after a winner is selected.
+
+### Round 1: Diverge
+Generate 3-5 **structurally different** variants. Not color/font swaps — fundamentally different:
+- Different spatial logic
+- Different rhythm and composition
+- Different dominant aesthetic
+- Each variant names which design convention it's "fighting"
+
+### Round 2: Kill
+User makes **binary decisions**: Alive or Dead.
+**NO blending** — blending is averaging. Averaging is convergence.
+
+Precedence: this Alive/Dead process governs POST-CODE iteration rounds. The
+pre-code concept stage is owned by `ima2-uiux` UX-CONCEPT-GEN-01, whose
+mockup SYNTHESIS rule applies there and does not conflict with this ban.
+
+### Round 3: Mutate
+Within the surviving direction, introduce deliberate "breaks":
+- Named violations of design convention
+- Specific rules being intentionally broken
+- User picks which breaks work
+
+### Round 4+: Repeat
+Each cycle moves further from center.
+User selections are the creative act. The model is the generator.
+
+---
+
+## User Guidance
+
+The user should:
+1. **Provide reference images/sites** — especially from OUTSIDE the same industry. A restaurant menu layout applied to fintech is more distinctive than "experimental fintech."
+2. **Name what they hate** — "I hate card grids" eliminates a convergence attractor better than "make it interesting."
+3. **Expect multiple rounds** — First output is most average. Each "kill this, keep that, push further" cycle moves away from center.
+4. **Kill boldly** — If a variant feels safe or familiar, it IS. Unfamiliarity feels wrong before it feels right.
+
+---
+
+## Upgrade Techniques Library
+
+High-impact techniques for replacing generic patterns:
+
+### Typography
+- **Variable font animation** — Interpolate weight/width on scroll or hover
+- **Outlined-to-fill transitions** — Text starts as stroke, fills with color on entry
+- **Text mask reveals** — Large type as a window to video/animation behind it
+
+### Layout
+- **Broken grid / asymmetry** — Overlapping, bleeding off-screen, offset with calculated randomness
+- **Whitespace maximization** — Aggressive negative space forcing focus on single element
+- **Parallax card stacks** — Sections stick and physically stack during scroll
+- **Split-screen scroll** — Two halves sliding in opposite directions
+
+### Surfaces
+- **True glassmorphism** — see `liquid-glass.md` (recipes + gates); the tell of fake glass is `backdrop-blur` with no edge refraction
+- **Spotlight borders** — Card borders illuminating dynamically under cursor
+- **Grain/noise overlays** — Fixed `pointer-events-none` overlay breaking digital flatness
+- **Colored tinted shadows** — Shadows carrying background hue, not generic black