voxflow 1.15.6 → 1.16.0

package/skills/card/references/layouts/card-layouts.md

@@ -0,0 +1,268 @@
+# Card Layout System
+
+Use this reference whenever a card set needs more design structure than a simple title-and-grid treatment. The goal is to make layout a planning and implementation contract, not a vague inspiration list.
+
+Pair this with `references/design-languages.md` when the user wants style variation or a stronger visual point of view. Layout defines the card's structure; design language defines its graphic voice.
+
+## Shape-First Direction
+
+When the user wants stronger design or says the cards feel too plain, do not solve it by adding more thin lines, grids, or boxed panels. Those are utility devices, not a visual concept.
+
+Default away from:
+
+- full-canvas coordinate grids
+- repeated thin-line boxes
+- equal card grids as the main composition
+- hairline-heavy technical diagrams
+- one border around every item
+
+Prefer:
+
+- one dominant visual metaphor per card
+- large cropped shapes, oversized type, silhouettes, stamps, labels, receipts, tickets, dossiers, product objects, image crops, or generated assets
+- asymmetric composition with deliberate overlap
+- thick rules, filled bands, paper cuts, torn labels, diagonal tape, stamps, and large negative space
+- grouped text that attaches to the visual anchor instead of floating in separate boxes
+
+Thin lines, grids, and rectangular panels are allowed only when they support a stronger anchor. If the screenshot would still work after removing the anchor, the design is probably too component-like.
+
+## Layout Contract
+
+Before writing card HTML, create a layout plan table with one row per card:
+
+| Card | Role | Layout | Visual Anchor | Text Density | Asset Slot | Risk |
+|---|---|---|---|---|---|---|
+| 01 | Cover | `cover-object` | package inspection tag | Low | CSS object / image | title crowding |
+| 02 | Mechanism | `split-diagram` | artifact -> scan flow | Medium | diagram 16:10 | too much copy |
+
+Required fields:
+
+- `Role`: cover, context, proof, mechanism, contrast, quote, checklist, closer, etc.
+- `Layout`: one of the layout recipes below.
+- `Visual Anchor`: the dominant object, image, number, diagram, shape, artifact, or typographic move. If this is "none", the card is likely under-designed.
+- `Text Density`: low, medium, or high. Low cards need stronger composition; high cards need tighter information architecture.
+- `Asset Slot`: none, CSS object, photo, screenshot, generated image, diagram, or proof grid.
+- `Risk`: likely failure mode, such as text crowding, weak anchor, repetitive shell, or image crop.
+
+Do not let every card in a real explainer set be low density. A 3-card set should normally include one medium-density explanation or takeaway card. A 5+ card set should include at least two structured information cards.
+
+Do not start coding until every card has a different enough role or visual anchor. A set can share a system, but it should not feel like the same card with swapped text. For high-design cards, also name the `Composition Move`: crop, overlap, diagonal, scale contrast, split field, cutaway, stamp, wraparound, or image-led.
+
+## Set-Level Rhythm
+
+For 1-3 cards:
+
+- Use a `hook / explain / takeaway` density arc by default.
+- Use at least 2 layout recipes.
+- Card 1 should be a cover or bold thesis, not a dense checklist.
+- Avoid making every card `title-stack + cards-grid`.
+- Include one structured information card: numbers, process, comparison, proof grid, callouts, field notes, or checklist.
+- At least one card should use a large non-box visual anchor or cropped shape.
+
+For 4-7 cards:
+
+- Use at least 3 layout recipes.
+- Include one low-density visual card: cover, divider, quote, question, or hero object.
+- Include one structured information card: numbers, process, comparison, proof grid, or checklist.
+- Use at least two medium-density structured cards when the set is an explainer. Strong covers and closers can stay sparse, but the middle should carry concrete information.
+- Do not place more than 2 dense cards back to back.
+- Avoid more than 2 cards whose main structure is equal rectangular panels.
+
+For 8+ cards:
+
+- Use at least 4 layout recipes.
+- Add at least one reset card every 3-4 cards: divider, quote, question, image-led card, or big number.
+
+## Layout Recipes
+
+### `cover-object`
+
+Purpose: make the first card instantly memorable.
+
+Composition:
+
+- small chrome at top
+- large title occupying 45-65% of width
+- one dominant object or visual metaphor occupying 25-50% of canvas, preferably cropped, tilted, stamped, wrapped, or overlapped
+- short promise line
+- footer/source and page number
+
+Use when: topic has a concrete metaphor such as package label, receipt, microscope, map, passport, machine part, screenshot, document, stamp, signal, or artifact.
+
+Avoid: title-only covers unless the typography itself is distinctive. Avoid placing the object inside a neat box; make it behave like a physical or graphic object.
+
+### `cover-crop`
+
+Purpose: make a visual asset or generated image carry the cover.
+
+Composition:
+
+- image fills one edge or corner and is cropped intentionally
+- title overlays or sits in the negative space
+- chrome is minimal
+- footer is quiet
+
+Use when: there is a real photo, product screenshot, event image, object, or generated editorial visual.
+
+Avoid: dark blurred stock imagery or images that do not reveal the subject.
+
+### `split-diagram`
+
+Purpose: explain a mechanism with text and a diagram/object side by side.
+
+Composition:
+
+- 55/45 or 60/40 split in square cards
+- left: kicker, headline, short explanation
+- right: diagram, code/object panel, screenshot crop, cutaway shape, or annotated asset
+- optional callout strip below
+
+Use when: the content needs "how it works".
+
+Avoid: using the right side for another text card. The right side must be visual. Avoid a plain boxed diagram unless it has a strong silhouette, scale, or crop.
+
+### `artifact-board`
+
+Purpose: make abstract software/process content feel tangible.
+
+Composition:
+
+- main title
+- 1 large document, label, ticket, receipt, terminal printout, inspection sheet, or dossier object
+- 2-4 annotations around it
+- restrained stamps, serial numbers, margins, or clipping marks
+
+Use when: content involves packages, audits, release notes, files, policies, contracts, research, incident reports, or checklists.
+
+Avoid: too many equal cards. One artifact should dominate. Make it feel like an object through scale, angle, crop, folding, stamp, tape, or layered paper, not through a thin border.
+
+### `big-number`
+
+Purpose: turn metrics into a visual event.
+
+Composition:
+
+- one oversized number or 2-3 large metrics
+- short labels and notes
+- source line
+- optional scale marks, ruled columns, or small comparison baseline
+
+Use when: numbers are the story.
+
+Avoid: six equal metric boxes unless the goal is a data table.
+
+### `proof-grid`
+
+Purpose: show evidence through multiple assets.
+
+Composition:
+
+- title and one-sentence claim
+- 2x2, 3x1, 3x2, or asymmetric large+small proof grid
+- consistent crop/height within each image group
+- captions that add information, not decoration
+
+Use when: screenshots, examples, posts, UI states, or clips prove the claim.
+
+Avoid: mixing unrelated aspect ratios without an intentional grid. If possible, use an asymmetric proof wall rather than equal boxes.
+
+### `process-rail`
+
+Purpose: make ordered steps readable as one static sequence.
+
+Composition:
+
+- title and context
+- 3-6 steps on a rail, arc, ladder, timeline, conveyor, orbit, stack, or route
+- numbers are prominent
+- one clear start and end
+
+Use when: release flow, workflow, architecture path, migration, or causal chain.
+
+Avoid: equal boxes floating without connection. Add a rail, arrows, rhythm, grouping, or physical metaphor. The rail should be more visually important than individual boxes.
+
+### `before-after`
+
+Purpose: compare two systems or states.
+
+Composition:
+
+- mirrored left and right panels
+- shared row labels or matching bullet counts
+- muted old side, stronger new side
+- clear dividing rule or axis
+
+Use when: old vs new, myth vs reality, risk vs mitigation, manual vs automated.
+
+Avoid: two unrelated lists with no shared comparison structure.
+
+### `quote-poster`
+
+Purpose: give one idea emotional weight.
+
+Composition:
+
+- large quote/principle
+- attribution or context
+- very little supporting text
+- optional ghost word, rule lines, or small source note
+
+Use when: a short sentence is the takeaway.
+
+Avoid: long quotes or dense paragraphs.
+
+### `checklist-sheet`
+
+Purpose: present practical actions without becoming a plain grid.
+
+Composition:
+
+- checklist title
+- one dominant sheet, clipboard, form, stamp, receipt, tag, or inspection object
+- 4-8 checks with clear grouping
+- optional pass/fail marks, stamps, or sections
+
+Use when: actions, launch criteria, recommendations, operational playbooks.
+
+Avoid: six equal boxes if a form metaphor would be stronger. Prefer one large object with grouped rows, stamps, tears, tabs, or highlighted blocks.
+
+### `closer-question`
+
+Purpose: end with a memorable prompt or decision.
+
+Composition:
+
+- one sharp question or conclusion
+- one small line of context
+- large whitespace or single object
+- minimal footer
+
+Use when: final carousel card, act break, or call to action.
+
+Avoid: adding a full checklist to the closer.
+
+## CSS Primitive Requirements
+
+When using this layout system, define card-local classes for the chosen recipes before writing individual cards. Do not rely on ad hoc inline layout for every card.
+
+Recommended primitive names:
+
+- `.chrome`, `.kicker`, `.foot`, `.page-no`
+- `.layout-cover`, `.layout-split`, `.layout-artifact`, `.layout-proof`, `.layout-rail`, `.layout-compare`, `.layout-quote`, `.layout-checklist`
+- `.visual-anchor`, `.artifact`, `.stamp`, `.tape`, `.ticket`, `.cutout`, `.annotation`, `.rail`, `.step`, `.proof-frame`, `.quote-mark`, `.ghost`
+
+The exact CSS can vary, but each chosen layout recipe should have a recognizable parent class in the HTML. This makes visual audit possible.
+
+## Layout QA
+
+Fail and revise a card when:
+
+- the planned `Visual Anchor` is missing or visually weaker than the body text.
+- 3 or more cards in a set share the same `headline + equal grid + footer` structure.
+- the card's primary design language is thin lines, coordinate grids, and rectangular boxes instead of the planned anchor.
+- a supposed `split-diagram` has text on both sides and no real diagram/object/image.
+- a supposed `process-rail` is just disconnected equal boxes.
+- a supposed `checklist-sheet` is just a generic card grid instead of a form, sheet, or grouped checklist.
+- the layout recipe cannot be identified from the rendered screenshot.
+
+During visual review, name the layout actually used for each card. If you cannot name it, the layout system is not being used.

package/skills/card/references/magazine-card-adaptations.md

@@ -0,0 +1,154 @@
+# Magazine Card Adaptations
+
+This reference adapts card-suitable ideas from `op7418/guizang-ppt-skill` without importing its slide runtime, WebGL background, horizontal navigation, or motion system. Use it as a planning aid for editorial card sets that should feel like a compact magazine spread rather than a generic social template.
+
+Source inspiration:
+
+- https://github.com/op7418/guizang-ppt-skill
+
+## What To Reuse
+
+- Editorial shell: small chrome labels, footer metadata, visible page numbers, issue-like naming, and a clear kicker above the main title.
+- Typography roles: serif or expressive display for major titles and numbers, sans-serif for dense explanations, monospace for metadata, code, labels, and timestamps.
+- Layout archetypes: cover, act divider, big-number card, left-text/right-image, image proof grid, pipeline/process, question closer, big quote, before/after, and lead-image/sidebar text.
+- Image discipline: define the image slot first, then source or generate the asset to match that slot. Standardize ratios and crop only the expendable parts.
+- Restrained palette families: `magazine-eink`, `porcelain-research`, `field-notes`, `kraft-editorial`, `dune-gallery`, and other paper-first themes from `references/themes/presets.md`.
+
+## What Not To Reuse
+
+- Do not copy the PPT template, slide classes, JavaScript navigation, WebGL shader background, or Motion One animation recipes.
+- Do not use viewport-height slide dimensions such as `vh` as the main sizing system. Cards must use fixed pixel canvases and tokenized spacing.
+- Do not require one deck-wide theme rhythm for small card sets. Instead, keep all cards visually sibling while varying background emphasis only when it helps pacing.
+- Do not use emoji as icons in editorial or technical cards. Prefer text, Lucide icons when already available, simple CSS marks, or numbered labels.
+
+## Card Layout Archetypes
+
+Choose a small set of archetypes before writing HTML. Each card still uses a single fixed `.card` root, but composition can vary within a shared token system.
+
+For stricter implementation guidance, use this alongside `references/layouts/card-layouts.md`. The layout file is the contract; this file explains the editorial adaptation.
+
+### 1. Editorial Cover
+
+Use for card 1 or a one-card poster.
+
+- Structure: chrome/kicker, oversized title, short deck promise, one strong visual signal, footer/source and page number.
+- Best for: opinion hooks, product notes, security incidents, launches, explainer covers.
+- Card adaptation: keep the title to 2-4 semantic lines. Reserve 20-35% of the canvas for either a visual object or decisive whitespace.
+
+### 2. Section Divider
+
+Use when a carousel has 6+ cards and needs a reset.
+
+- Structure: small act label, one short title, one line of setup, large background word or number.
+- Best for: moving from context to method, from problem to solution, or from facts to takeaways.
+- Card adaptation: do not overuse. One divider in a 7-card set is usually enough.
+
+### 3. Big Numbers
+
+Use when 2-6 metrics carry the story.
+
+- Structure: title, lead sentence, metric cards with label -> number -> note, compact source line.
+- Best for: funding, usage, benchmarks, timelines, incident scale.
+- Card adaptation: numbers should be short enough to read at thumbnail size. Use `K`, `M`, `%`, or compact units instead of long raw values.
+
+### 4. Left Narrative + Right Visual
+
+Use for one key argument supported by a photo, screenshot, UI panel, code block, or diagram.
+
+- Structure: left side kicker/title/body/callout; right side image frame with caption.
+- Best for: contrast, personal story, product proof, workflow explanation.
+- Card adaptation: in square cards, prefer a 60/40 or 55/45 split. In vertical cards, stack title above the visual and keep the callout below.
+
+### 5. Image Proof Grid
+
+Use when multiple screenshots or examples make the claim.
+
+- Structure: title, one-line claim, 2x2, 3x2, or 1x3 image grid, captions.
+- Best for: platform evidence, UI variations, before/after examples, research clips.
+- Card adaptation: all image frames in the same grid must share one height and crop behavior. Avoid mixing portrait and landscape assets in one grid unless the layout intentionally reserves columns for them.
+
+### 6. Pipeline / Process
+
+Use for ordered steps.
+
+- Structure: process label, title, 3-6 step blocks, optional grouped lanes.
+- Best for: release flows, AI workflows, architecture pipelines, content production.
+- Card adaptation: no interactive step reveal. Make the sequence readable in one static glance with numbering, arrows, or a continuous rail.
+
+### 7. Question / Closer
+
+Use as a final card or act break.
+
+- Structure: one sharp question or takeaway, short clarifying line, minimal metadata.
+- Best for: audience reflection, call to action, memorable closing.
+- Card adaptation: preserve whitespace. A closer card should not become a checklist.
+
+### 8. Big Quote
+
+Use for a single idea that deserves weight.
+
+- Structure: large quote or principle, source/attribution, small context note.
+- Best for: executive summary, opinion carousel, report takeaway.
+- Card adaptation: use a large serif/display blockquote only when the quote is short. Paraphrase long source text instead of squeezing it.
+
+### 9. Before / After
+
+Use for two systems, states, or positions.
+
+- Structure: title, left panel, right panel, shared row labels or mirrored bullet structure.
+- Best for: old vs new, myth vs reality, risk vs mitigation, manual vs automated.
+- Card adaptation: make the panels symmetrical and keep bullet counts matched when possible.
+
+### 10. Lead Image + Sidebar
+
+Use when the image leads and text explains.
+
+- Structure: large image or diagram, right/bottom sidebar with 3-5 labeled notes.
+- Best for: annotated screenshots, maps, systems, product UI, visual case studies.
+- Card adaptation: keep annotation labels outside the image when possible so the source asset remains reusable.
+
+## Editorial Shell Rules
+
+- `chrome` is stable metadata: series name, act, date, source class, or page position.
+- `kicker` is the unique hook for that card. Do not repeat or translate the same text used in `chrome`.
+- Footer/source text should be present when facts, quotes, assets, or research affect the card.
+- Page numbers should be stable and visible, but secondary. They should never compete with the headline.
+- Background ghost words or numbers are acceptable at very low opacity when they reinforce the topic and do not reduce legibility.
+
+## Image Slot Workflow
+
+Use this when the card set needs photos, screenshots, generated illustrations, diagrams, or UI scenes.
+
+1. Decide which cards truly need images. Do not force images onto text-led cards.
+2. For each image card, define the slot before sourcing assets:
+   - square card hero image: 1:1, 4:3, 3:2, or 16:10 depending on composition.
+   - vertical card hero image: 3:4, 4:5, 9:16 crop, or stacked 3:2 panels.
+   - infographic or system diagram: 16:9 or 16:10, usually `fit-contain`.
+   - screenshot redesign: 16:10 or 4:3, usually `fit-contain`.
+   - proof grid: one shared frame height and one shared crop policy.
+3. Use `object-fit: cover; object-position: top center;` for photos and screenshots where the top carries identity or UI chrome.
+4. Use `object-fit: contain;` for diagrams, charts, screenshots with important text, or generated infographics.
+5. If a real screenshot is too tall, too narrow, or too dense, crop to meaningful panels or regenerate it as a unified UI scene. Do not stretch it into a long strip.
+6. Generated image prompts should describe only the asset, not the whole card. Do not ask the image model to create card chrome, page numbers, titles, watermarks, decorative borders, or captions.
+7. Save final assets in `cards/<slug>/assets/` and record asset sources or generated-image notes in `sources.md` or `credits.md`.
+
+## Compact Image Prompt Patterns
+
+Use these as short starting points and adapt the language to the card set.
+
+- Documentary photo: `Editorial documentary photo about [scene], natural light, low saturation, real workspace or field context, restrained magazine tone, medium density, leave negative space, no logos or watermark, [ratio].`
+- Magazine infographic: `Restrained editorial infographic explaining [concept/process], ink-on-paper palette, fine lines, short readable labels in [language], ample whitespace, no slide title or border, [ratio].`
+- Pipeline diagram: `Clean process diagram showing [step 1] to [step 2] to [result], numbered segments, fine arrows, short labels in [language], ink-on-paper editorial style, [ratio].`
+- Before/after graphic: `Two-column editorial comparison of [before] versus [after], symmetrical layout, low-saturation accent, short labels in [language], no page chrome, [ratio].`
+- UI scene redesign: `Horizontal UI scene based on [workflow/screenshot], paper background, fine grid, subtle annotations in [language], realistic product workflow feel, no fake logo or dashboard glamour, [ratio].`
+
+## Card QA Additions
+
+Add these checks to the normal render audit:
+
+- Chrome and kicker are not semantically redundant.
+- Serif/display type is used only for titles, quotes, or numbers; dense explanatory text remains sans-serif.
+- Image frames in the same group use consistent dimensions and crop policy.
+- No generated image contains its own card title, page number, footer, watermark, or decorative frame.
+- Long Chinese titles are manually line-broken at semantic boundaries instead of relying on browser wrapping.
+- Decorative background words, grids, and labels stay below the content in visual priority.

package/skills/card/references/taste.md

@@ -0,0 +1,121 @@
+# Taste Baseline
+
+Global visual quality baseline for every card mold and every design language. Read this file before planning or generating HTML. Treat it as a floor, not a style preset.
+
+Adapted for the VoxFlow `card` skill from the taste rules in `lijigang/ljg-skills`:
+https://github.com/lijigang/ljg-skills/blob/master/skills/ljg-card/references/taste.md
+
+## Core Principle
+
+Remove obvious AI-generated design traces.
+
+Hard bans:
+
+- Do not use Inter as the default font.
+- Do not use pure black `#000`, `#000000`, or `rgb(0,0,0)`.
+- Do not use centered hero layouts by default.
+- Do not use three equal cards or three equal columns as the main composition.
+- Do not use AI-copy phrases such as "赋能", "无缝", "释放", "下一代", "智能化", "重塑", or "革新" unless they are quoted source material.
+- Do not invent fake-looking data such as `99.99%`, `1234567`, `50%`, or generic placeholder metrics.
+
+## Baseline Parameters
+
+Use these as planning defaults unless the user explicitly asks for something else:
+
+- `DESIGN_VARIANCE`: `8`
+  - The composition should feel intentionally designed, not perfectly symmetrical.
+- `VISUAL_DENSITY`: `5`
+  - Default card sets should carry enough information to be useful, not only attractive. Keep editorial breathing room, but avoid making every card a title plus one short sentence.
+
+Adjust by card role:
+
+- Cover, poster, quote, cinematic, or closer card: density `2-4`. These cards earn low density through strong composition, not emptiness.
+- Mechanism, explanation, proof, process, or comparison card: density `5-6`. Include a concrete claim plus 2-4 supporting points, labels, or observations.
+- Checklist, field-note, product-catalog, how-to, or operational takeaway card: density `6-7`. Include structured detail, but keep the hierarchy scannable.
+- Data card: density `5-6`. Use one dominant metric plus 2-3 context notes. Do not create competing metric boxes.
+- Long reading card: density `4-5`, calmer color shifts, more reading comfort.
+- Infographic card: density `6-7`, larger labels, data-driven structure.
+
+## Information Density
+
+Do not confuse taste with emptiness. Taste baseline reduces generic AI traces; it does not require low-information cards.
+
+Card set requirements:
+
+- A 3-card set should usually follow `hook / explain / takeaway`.
+- A 5-card set should usually follow `hook / context / mechanism / evidence / takeaway`.
+- A 7-card set should usually follow `hook / context / mechanism / evidence / contrast / action / closer`.
+- Every explanatory set must include at least one medium-density information card.
+- Do not let every card be only a headline plus one support sentence.
+
+Per-card minimums:
+
+- Low-density cards may have one headline and one short support line only when they are covers, posters, quotes, cinematic frames, or closers.
+- Standard explanation cards should include one claim plus 2-4 concrete information points, labels, observations, or steps.
+- Operational cards should include a checklist, sequence, comparison, decision rule, or callouts attached to a visible object.
+- Data cards should include one dominant number plus context: source, scope, definition, or implication.
+
+Conflict resolution:
+
+- If a primary design language says `Low` or `Very low`, obey that card-level limit, but make another card in the same set carry the useful detail.
+- For `swiss-poster`, keep each card low-density; use a sequence of posters to distribute the story across the set.
+- For `cinematic-still`, keep cards very low-density; pair it with another language or add a separate explainer card when the user needs details.
+- For `data-poster`, keep one dominant metric per card; density comes from context notes, not extra numbers.
+
+## Typography
+
+- Default sans choices: Geist, Satoshi, Cabinet Grotesk, Outfit, Avenir Next, system-ui fallback.
+- Default serif choices: Noto Serif SC, Source Han Serif, Songti SC, Georgia.
+- Technical dashboard-like cards should use high-quality sans or mono, not decorative serif.
+- Large editorial cards may use serif/display titles, but body text should stay readable.
+- Body text should avoid pure black. Use charcoal or deep gray such as `#1f1d1a`, `#2f2a24`, `#333333`, or `#4a4a4a`.
+- Do not build hierarchy by making the H1 huge and leaving everything else weak. Use contrast, placement, weight, and object scale.
+- Dense mobile-facing annotations should remain readable after downscaling. Avoid tiny labels below roughly 22-24px on a 1080px canvas.
+
+## Color
+
+- Use at most one dominant accent color per card unless the content genuinely requires categories or data comparison.
+- Avoid saturated AI purple-blue gradients, neon glows, holographic color, and generic tech auroras.
+- Keep warm/cool temperature consistent inside one card. Do not mix warm paper, cold gray panels, and random saturated accents.
+- Replace pure black with off-black, charcoal, zinc-like darks, or ink colors.
+- Background gradients must be subtle. Do not use gradient-filled headline text as a default move.
+
+## Layout
+
+- Avoid centered hero compositions when the card needs design quality. Prefer left alignment, split fields, asymmetry, edge crop, object dominance, diagonal placement, or large negative space.
+- Do not use three equal cards, three equal columns, or three equal metric boxes as the main structure. Prefer asymmetric ratios such as `2fr 1fr`, staggered blocks, overlapping objects, or one dominant object plus secondary notes.
+- Cards and boxed panels should exist only when they express a real hierarchy or object metaphor. Do not box every idea.
+- Data should breathe. Use whitespace, scale, alignment, or dividers before resorting to repeated bordered boxes.
+- Shadows should be tinted to the palette, not default gray drop shadows.
+- Spacing must look mathematically intentional. Align edges across elements and avoid awkward near-alignments.
+
+## Copy And Data
+
+- Rewrite generic AI copy into concrete claims and verbs.
+- Prefer nouns and actions that name the actual subject: "审发布包", "阻断源码目录", "标记 source map".
+- Do not use generic placeholder people, brands, or products unless the content is explicitly fictional.
+- If numbers are factual, verify or cite them. If numbers are illustrative, label them as synthetic or use them only in test/demo contexts.
+- For synthetic demos, use plausible uneven values rather than fake-perfect numbers.
+
+## Surface And Effects
+
+- Avoid outer glows, glass panels, neon blur blobs, and default SaaS shimmer.
+- Use material effects only when they support the metaphor: paper folds, labels, tape, stamps, specimen cards, photo crops, catalog objects.
+- If glass is deliberately used, it needs physical edge treatment: subtle border, inner highlight, and controlled contrast. Do not rely on blur alone.
+- Rounded corners are not a style by themselves. Use radius only when it matches the object or product language.
+
+## Pre-Export Taste QA
+
+Before screenshot export, verify:
+
+- No Inter default font.
+- No pure black.
+- No centered hero unless explicitly justified.
+- No three equal-card layout as the main structure.
+- No AI purple-blue gradient or neon glow default.
+- No generic AI copy.
+- No fake-looking data.
+- No meaningless boxes, dashboards, or decorative panels.
+- One clear visual anchor dominates every card.
+- Spacing and alignment are deliberate.
+- Shadows, textures, and surfaces match the palette and metaphor.