@lark-apaas/coding-miaoda-sandbox-skills 0.1.0-dev.b2f659e → 0.1.0-dev.c8cc2b5

package/miaoda/lark-design-prototype/references/restoration-traps.md

@@ -0,0 +1,113 @@
+# Feishu Restoration Traps
+
+Read this reference for high-fidelity restoration, full-page Figma implementation, screenshot recreation, or pages that visibly drift away from the Feishu feel.
+
+## Quick Check
+
+- Has the Figma coordinate system become a fixed page layout?
+- Are there heavy gray backgrounds, strong borders, or ordinary card shadows?
+- Have all modules become cards with equal visual strength?
+- Is there gray backing with white cards, white cards with gray blocks, or gray blocks with smaller cards?
+- Do blue or other accent colors appear in ordinary decoration, icon matrices, category tags, or large backgrounds?
+- Does page UI use gradients?
+- Is the whole main workspace locked by a fixed max width?
+- Are multiple text layers bold in the same list, table, card, or navigation group?
+- Do content sections lack external titles, or are titles wrapped inside bordered containers?
+- Is text compressed, clipped, character-by-character, or vertical?
+- Does the page only look close after 50% or 75% browser zoom?
+- Do top bars, navigation, tabs, list rows, avatars, badges, message cards, or floating actions collide?
+- Are recognizable UD controls rendered as unstyled ordinary `div` elements?
+- Are icon styles mixed?
+- Is a responsible visual anchor missing?
+- Are unrelated modules added only because a case has them?
+
+## Surfaces And Borders
+
+Feishu interfaces express structure first through whitespace, titles, surface hierarchy, and component states. Borders are for real controls, table / list boundaries, key containers, and necessary grouping. Ordinary business cards need only a 0.5px light boundary.
+
+Content section titles are external by default. Except for Hero, overview summary cards, small KPI cards, floating layers, navigation, and single detail cards, do not put section titles inside bordered Card / Table containers. Borders only wrap real content.
+
+Avoid:
+
+- Most modules in the same viewport have full frames;
+- Title and content are wrapped by one frame, making the section hierarchy heavy;
+- Gray backing with white cards, white cards with gray blocks, gray blocks with smaller cards;
+- White cards floating on a heavy gray right rail;
+- Colored borders used as generic decoration.
+
+Side navigation background should use a near-white neutral surface and must not become an obvious gray block. Selected state uses neutral fill and 500 text weight, not light-blue fill or brand-blue text by default.
+
+## Cards And Depth
+
+Ordinary business cards, Hero, metric cards, quick entries, table containers, right summaries, stage pipelines, and insight panels have no shadows by default. Shadows are only for floating layers such as dropdown, popover, tooltip, dialog, and drawer.
+
+Avoid card-in-card layouts. When content needs subdivision, prefer titles, rows, light fills, whitespace, and dividers.
+
+Quick entries and lightweight recommendation entries do not set fixed height. With short titles and descriptions, cards should be shaped naturally by 16px vertical padding, text line-height, and 36–40px icon containers. Cards in one row take the height of the tallest card in that row. The parent uses `grid-auto-rows: auto`; `align-items: stretch` or card `height: 100%` can provide equal height within the row. If the whole group becomes too tall, the cause is usually fixed height, excessive `min-height`, `grid-auto-rows: 1fr`, `grid-auto-rows: minmax(...)`, `aspect-ratio`, or `place-items: center`. Entry icon containers may use light low-opacity blue fills to avoid a flat group of pure white outlined icons.
+
+When multiple modules in Figma / screenshots appear to share a width, first restore the common container line and responsive grid. Do not add `margin-left`, temporary width, or fixed canvas coordinates to individual modules. Page title, Hero, module title, quick entry, table, and right rail should come from the same content wrapper.
+
+## Layout
+
+Figma frames, auto layout, padding, gap, and constraints should convert into responsive layout relationships. Page body uses document flow and does not copy full-page `top/left` coordinates.
+
+For screenshot restoration, infer DPR and target CSS viewport before coding. If a source image is `2840 x 1630` and appears to be a Retina screenshot, the first target CSS viewport should be close to `1420 x 815`. A page that only matches at 50% zoom usually means raw screenshot pixels were used as CSS pixels.
+
+Ordinary fixed dimensions remain only for icons, avatars, control heights, hairline borders, and local media ratios.
+
+The main workspace of workspaces, tables, boards, CRM, admin pages, and data pages must fill the available space after the navigation shell. Max reading width is only for local areas such as long-form text, settings forms, and detail descriptions, not the whole `main-workspace` / `main-content`.
+
+## Text
+
+Table columns, navigation items, buttons, tags, card titles, and metadata all need minimum readable width or ellipsis / wrap strategies. When a title area contains search, filters, or action buttons, it should wrap or stack at narrow widths.
+
+Tables are the exception: table body cells must not become two-line just to hold more information. Customer names, object names, amounts, owners, times, and action links stay 400 weight and single-line; auxiliary content moves to separate columns, tooltip, right detail drawer, or row details.
+
+Default body text, descriptions, table content, card descriptions, and unselected navigation stay 400. Module titles, table headers, buttons, selected navigation, and key numbers may use 500. Page titles or a small number of core headings use 600. Within one information group, usually emphasize only one primary text.
+
+Avoid:
+
+- `word-break: break-all` on regular text;
+- Search input with fixed width compressing the title;
+- Page-level search placed inside a content section, leaving the top-nav tool group without search;
+- Select / DatePicker stretched across the whole row, splitting filters and Tabs;
+- Buttons and tags compressed into character-by-character columns;
+- Two-line table body cells or bold table body text;
+- Titles, descriptions, tags, and numbers all bold, making hierarchy dirty;
+- Fixed-height containers clipping text.
+- Badges, dates, avatars, tabs, or action buttons overlapping titles and message content.
+
+## Icons And Media
+
+Keep one icon style within the same group. Regular page UI icons use catalog `outlined`, preferably v2 when semantically suitable. Screenshot and Figma restoration preserve the source visual type: outlined, filled, or colorful. File lists, recent documents, attachment lists, document cards, and file directories can use File v2 colorful as a group. The same area / module must keep the same family, version, type, and shape and must not mix round and normal shapes.
+
+Blue and other accent colors are only for primary actions, links, focus, current state, real status, and a small amount of brand identification. Do not use accent colors for ordinary card backgrounds, decorative lines, icon matrices, category tags, large KPI emphasis, or entries without state meaning.
+
+Page UI does not use gradients. Backgrounds, Hero backing, cards, buttons, tags, icon backgrounds, borders, masks, and decorative blocks must not use gradients to create hierarchy.
+
+Media needs responsibility and source. Gray boxes, random images, avatars with no source, and purely decorative geometry cannot serve as visual anchors. Generated imagery only creates the independent visual element inside the current media slot.
+
+When Hero, welcome areas, recommended content, product entries, empty states, and workspace home pages carry first-glance explanation, first check the illustration library or record generated-image fallback. Pure outlined icons and text can leave the page without a visual anchor. If you decide not to use media, explain the reason in `media_decision`.
+
+## Contract Pattern
+
+```md
+restoration_traps:
+- trap: over-bordered cards
+  evidence: most modules have full borders
+  decision: keep key container and control boundaries; separate the rest with whitespace, titles, and light surfaces
+- trap: compressed title
+  evidence: title area and search input do not have enough horizontal space
+  decision: from narrow width, wrap tools or stack title and tools
+- trap: nested surfaces
+  evidence: gray backing with white cards, white cards with gray blocks, gray blocks with smaller cards
+  decision: keep only page base and content surface; separate the rest with titles, whitespace, row structure, and light dividers
+- trap: retina scale mismatch
+  evidence: source only matches after 50% or 75% browser zoom
+  decision: write source_viewport_contract, infer DPR, and set browser preview to target CSS viewport
+- trap: header collision
+  evidence: title, avatar, badge, metadata, tabs, or toolbar actions overlap
+  decision: reserve fixed slots, use min-width: 0 text containers, and ellipsis / wrapping boundaries
+```
+
+Omit this field when no risk is matched.

package/miaoda/lark-design-prototype/references/token-semantics.md

@@ -0,0 +1,112 @@
+# Token Semantics
+
+Use token roles by meaning and avoid choosing by personal taste.
+
+## Color Roles
+
+- `primary-fill-default` / `primary-fill-hover` / `primary-fill-pressed`: primary filled actions, selected controls, and direct blue-filled interaction states.
+- `primary-content-default` / `primary-content-hover` / `primary-content-pressed`: blue text, linear icons, borders, and other small-area primary-color content states.
+- `primary-on-primary-fill`: content on primary filled surfaces, especially primary button text and icons.
+- `text-title`: high-emphasis titles, body text, primary labels, and button text that is not on a filled surface.
+- `text-caption`: secondary text, metadata, descriptions, and table auxiliary content.
+- `text-placeholder`: placeholders and low-emphasis hints.
+- `text-link-normal` / `text-link-hover` / `text-link-pressed` / `text-link-disabled`: link states. Do not reuse primary fill tokens for links.
+- `line-border-card`: card and table boundaries.
+- `line-border-component`: interactive control boundaries, including input, checkbox, radio, and selector surfaces.
+- `line-divider-default`: standard dividers.
+- `bg-body`: default large page and workspace background and main content surface (body / app-root / main-workspace / main-content / right content area).
+- `bg-base`: low-emphasis app shell or backing area behind the main work surface.
+- `bg-content-base`: extra backing surface for especially deep hierarchy; do not use it as default page background.
+- `bg-body-overlay`: secondary surface layered on `bg-body`, such as a nested content area.
+- `bg-float` / `bg-float-base` / `bg-float-overlay`: popover, dropdown, dialog, drawer, menu, and nested floating surfaces.
+- `side-nav-bg`: historical semantic name. In the current skill, the main side-navigation background is written directly as `#f9f9f9` and is not mapped to this token during implementation.
+- `side-nav-item-hover` / `side-nav-item-selected` / `side-nav-item-selected-text`: historical semantic names. In the current skill, the main side-navigation current item background is written directly as `#1f23290d`, and current item text uses neutral body color plus 500 weight, not light-blue fill or brand-blue text by default.
+- `aux-side-nav-item-hover` / `aux-side-nav-item-selected`: light hover and current fill for auxiliary sidebars under `top-nav-primary`.
+- `side-nav-divider`: 0.5px divider for side-navigation groups or auxiliary sidebar boundaries.
+- `fill-hover` / `fill-pressed`: neutral interaction fills for text buttons, icon buttons, and rows.
+- `fill-active` / `fill-selected`: active and selected states.
+- `fill-disabled`: disabled fill state.
+- `function-danger-*`: only for destructive or failed states.
+- `function-success-*`: only for success states.
+- `function-warning-*`: only for warning states.
+- `function-info-*`: only for information states.
+- `icon-n1` / `icon-n2` / `icon-n3` / `icon-disabled`: icon hierarchy and disabled state.
+- `static-black` / `static-white`: fixed colors that do not change between light and dark modes.
+
+`DESIGN.md` embeds parsed P0 semantic color tokens as the offline baseline. When a confirmed component pattern needs loading variants, focus fills, functional content colors, or other specialized variants, query the versioned public semantic source with `node scripts/token-query.mjs --query "<token name or intent>"`. For palette-key auditing or non-P0 lookup, add `--source keys`. The helper verifies the pinned SHA-256 values declared in `DESIGN.md` before returning compact matches.
+
+## Surface System
+
+- Explain responsibilities of page root, app shell, content container, real controls, floating layers, and status feedback in `surface_family`.
+- Do not create hierarchy with heavy gray backgrounds, strong shadows, or multiple borders. Prefer tokens, spacing, titles, and component structure.
+- Large pages and workspaces (body / app-root / main-workspace / main-content / right content area) default to white or nearly white `bg-body`; introduce `bg-base` or `bg-content-base` only when app-shell backing or deeper hierarchy requires it.
+- One area usually keeps at most page base and content surface. Avoid gray backing with white cards, white cards with gray blocks, and gray blocks with smaller cards. Local grouping should prefer titles, whitespace, row structure, light dividers, hover, or selected state.
+
+## Typography Roles
+
+- `title-0`: page-level identity and largest title.
+- `title-1`: large page, block, or primary section title.
+- `title-2` and `title-3`: content titles and secondary structure titles.
+- `title-4`: group names, group titles, panel titles, and dialog titles.
+- `title-5`: title-style tabs and sibling view labels.
+- `headline`: emphasized information rows, button labels, active labels, compact strong text, and similar 14px medium-weight emphasis.
+- `body-0`: default product reading text and information-flow body.
+- `body-2`: auxiliary body and secondary explanation text.
+- `caption-0`: compact emphasized labels and tags.
+- `caption-1`: smallest emphasized auxiliary text.
+- `caption-3`: smallest neutral auxiliary text.
+
+Most Feishu product pages should use 12px, 14px, and 16px. Use 10px captions only on truly constrained auxiliary surfaces. Large type should be rare in operational pages.
+
+Default body text, descriptions, table content, card descriptions, and unselected navigation use 400. Module titles, table headers, buttons, selected navigation, and key numbers may use 500. Page titles or very few core headings use 600. Within one information group, usually emphasize only one primary text. Do not make titles, descriptions, tags, and numbers all bold.
+
+## Radius Roles
+
+- `radius.none` / 0: square surfaces and intentionally sharp areas.
+- `radius.s` / 4px: small tags and checkbox-like compact controls.
+- `radius.m` / 6px: default buttons and compact inputs.
+- `radius.l` / 8px: cards, modals, input containers, and table containers.
+- `radius.xl` / 10px: larger panels.
+- `radius.xxl` / 12px: relaxed shells and larger selection surfaces.
+- `radius.full` / 9999px: pills, badges, and circular icon buttons.
+
+Do not mix content radius and container radius on the same element.
+
+Page-level tasks should record radius division in `radius_family`. Controls, content containers, floating layers, and pills may use different roles, but the same local area should not contain too many radius scales.
+
+## Spacing Rhythm
+
+Use 4 / 8 / 12 / 16 / 24 / 32 / 40 / 48px. Repeated areas should share one rhythm.
+
+Typical use:
+
+- 4px: icon-to-label and small inline spacing.
+- 8px: compact controls and row internals.
+- 12px: local binding, auxiliary descriptions, compact tag groups.
+- 16px: title-to-content, same-group card grids, and standard section internals.
+- 24px: card padding, same-type groups, and left-right columns.
+- 40px: default vertical spacing between first-level content groups.
+- 48px: more relaxed first-screen or onboarding sections.
+
+## Shadows
+
+The raw token data retains historical and official elevation tokens for source tracing. When generating workspaces, CRM, portals, and sales dashboards, follow the current page rule in `DESIGN.md`: ordinary business surfaces do not use shadows; shadows are only for floating layers.
+
+Shadows are only for floating surfaces and overlays. Most page grouping should be done with surfaces, borders, and spacing.
+
+## Review Traps
+
+- Hard-coding one-off hex colors;
+- Using arbitrary 13px, 15px, or 17px font sizes in product UI;
+- Using any gradient background, Hero backing, button, card, tag, icon background, border, mask, or decorative block in page UI;
+- Using strong shadows on cards;
+- Using too many radius sizes in the same local area;
+- Replacing surface hierarchy with heavy gray backgrounds, strong borders, or strong shadows;
+- Lacking a clear surface and radius family on the same page;
+- Using an obvious gray-block side navigation background or a light-blue default selected state;
+- Using blue and other accent colors as ordinary decoration, icon matrices, category tags, or large KPI backgrounds;
+- Using filled icons without source evidence or an explicit `source-filled` strategy, or replacing catalog icons with emoji, characters, hand-written SVG, or third-party icon libraries in page UI;
+- Using colorful as ordinary decoration, or mixing icon family, v2 / non-v2 version, or File v2 colorful round / normal shapes in the same explicit area;
+- Applying a fixed max width to the whole main workspace on workspaces, tables, boards, CRM, admin pages, or data pages;
+- Making multiple text layers bold in the same list, table, card, or navigation group;
+- Creating gray backing with white cards, white cards with gray blocks, or gray blocks with smaller cards.

package/miaoda/lark-design-prototype/references/visual-brief.md

@@ -0,0 +1,125 @@
+# Visual Brief
+
+Use this reference for page-level, full-page, highly visual tasks, or when the user asks for goals such as "Feishu style", "minimal and polished", "clean", or "large whitespace". It stabilizes visual direction and does not define fixed page templates.
+
+## Fields
+
+```md
+visual_brief:
+  product_feel:
+  visual_mood:
+  composition_model:
+  density:
+  visual_anchor:
+  media_strategy:
+  polish_level:
+  anti_patterns:
+```
+
+## product_feel
+
+Choose the visual baseline by product surface:
+
+| Scene | product_feel |
+| --- | --- |
+| Approval, settings, admin, audit | quiet_enterprise_tool |
+| Docs, calendar, IM, collaboration space | collaboration_surface |
+| Workspace, portal, home page, launch page | calm_product_home |
+| CRM, sales, data, reports | focused_data_workspace |
+| AI assistant, smart generation, knowledge Q&A | restrained_ai_surface |
+| Official site, solution center | polished_landing |
+
+## visual_mood
+
+- `clean_precise`: default, clean, accurate, and restrained.
+- `warm_welcoming`: suitable for workspaces, home pages, onboarding.
+- `focused_dense`: suitable for tables, CRM, data, audit.
+- `restrained_expressive`: only for small AI or official-site first-screen expression.
+
+## composition_model
+
+Choose a composition that serves the primary task:
+
+- `shell_plus_content`
+- `shell_plus_content_plus_panel`
+- `hero_plus_content_stack`
+- `full_width_table`
+- `card_grid`
+- `detail_focus`
+- `chat_plus_panel`
+- `landing_hero_plus_sections`
+
+Compositions can be mixed, but the primary visual anchor and reading order must be clear.
+
+## density
+
+- `relaxed_enterprise`: default. Content groups use 40px spacing, and information presentation feels clean.
+- `focused_table`: tables, logs, approvals, and data lists. Row internals can be compact while module spacing still stays 40px.
+- `spacious_product_home`: welcome areas, home-page first screens, onboarding, with more relaxed content.
+
+One page can mix density locally. Choose `relaxed_enterprise` by default. Data work areas may keep row-scanning efficiency, but page-level group spacing stays spacious and should not compress into a dense wall of cards.
+
+When the user request only describes a direction, page name, or business type, first use the minimum first-pass content set: product identity, primary task, one main visual or primary task area, one main content area, necessary primary action, and a small set of samples. The first screen usually keeps 2–3 visible content groups. Table / list samples use 5–8 rows, card samples 3–4 items, and KPIs appear only when the primary task needs them, with 1–3 items. Do not proactively add multiple KPI groups, long lists, right-side insights, recent visits, or multi-level navigation.
+
+A clean view is more important than full content. When the request is vague, obvious whitespace can remain at the bottom of the page and between modules. Expand later based on user feedback. The main content area, main-content, and right content area prefer a white or nearly white page base. Light gray is only for side navigation, low-emphasis shells, or local backing surfaces, not for backing the whole main workspace.
+
+If the scene needs first-glance page intent, the main visual in the minimum content set can become `hero-card`. Suitable scenes include workspace, portal, home page, launch page, AI assistant, CRM / sales summary, data-insight entry, recommendation, and empty state. Table directories, settings, audits, approval details, member permissions, and strong operation forms default to no Hero.
+
+Except for Hero, floating layers, navigation, and single detail cards, content sections use external headers. The header sits above the content container, and the border only wraps the real content below.
+
+Page-level search goes by default at the leftmost position of the `top-nav` right tool group. Filters, Tabs, view switches, and local actions inside content sections align as one toolbar group. When space is tight, filters collapse into icon buttons or Dropdown / Popover.
+
+When side navigation appears, use a near-white neutral background and avoid an obvious gray block. Selected state uses neutral fill and 500 text weight, not light-blue fill by default. Blue and other accent colors are only for primary actions, links, focus, current state, real status, and a small amount of brand identification. The first-screen accent-color budget usually contains only one primary filled button, one current state, and necessary real-status feedback. Avatars, icon backgrounds, entry cards, ordinary tags, KPI containers, and decorative areas prefer neutral or low-saturation schemes. Default body text, descriptions, table content, and card descriptions stay 400. Module titles, table headers, buttons, selected navigation, and key numbers may use 500. Page titles or very few core headings may use 600. One area usually keeps at most page base and content surface. Do not express hierarchy with multiple nested backgrounds.
+
+Page UI does not use gradients. Backgrounds, Hero backing, cards, buttons, tags, icon backgrounds, borders, dividers, masks, and decorative blocks express hierarchy through whitespace, light borders, real state, and necessary media.
+
+## visual_anchor
+
+The first glance should have one primary anchor:
+
+- Workspace: welcome Hero, quick entries, recent content, or recommendation module;
+- Data page: table, view switch, or key filter;
+- CRM: key customers, follow-up list, stage pipeline, or key summary Hero;
+- AI: input area, assistant identity Hero, or recommended questions;
+- Official site: solution Hero, product UI image, solution entry, or single primary CTA.
+
+Avoid multiple areas competing with equal visual strength.
+
+## media_strategy
+
+Media appears by responsibility:
+
+- Home pages, workspaces, recommendations, empty states, onboarding, and product entries can use illustrations, thumbnails, avatars, product images, or entry icons. When Hero, welcome areas, recommended content, product entries, and empty states carry first-glance explanation, plan a visual anchor by default.
+- Dense data pages, settings pages, audit pages, and table-first flows can use no imagery. Use media only when explaining state, welcome, recommendation, or product entry.
+- When illustration or visual assets are needed, first check the illustration library and record `library_lookup`, then check UD / product assets. If matching fails, generate an independent bitmap for the current media slot.
+- Generated imagery must serve the current module theme, feel polished, minimal, and light, and may become a local visual focus. It must not be too heavy and must not generate a full page UI or complete dashboard.
+
+## polish_level
+
+- `functional_prototype`: core interactions work and the visual is clear enough.
+- `production_like`: default. States are complete, responsiveness and UD visuals are unified.
+- `polished_product`: higher completion level, requiring polished media, hover, empty states, and breakpoints.
+
+## Anti-Patterns
+
+- Heavy gray backgrounds, strong shadows, excessive borders;
+- Gradients in page UI;
+- Main content area / right content area using an obvious light-gray large background and then stacking white cards for hierarchy;
+- Sidebars becoming obvious gray blocks, or selected state using light-blue fill / brand-blue text;
+- Blue and accent colors used for ordinary decoration, icon matrices, category tags, KPIs, or large backgrounds;
+- Multiple text layers bold in the same list, table, card, or navigation group;
+- Gray backing with white cards, white cards with gray blocks, gray blocks with smaller cards;
+- Spacing, column widths, and module left edges that do not follow the base grid;
+- Marketing-style Hero in enterprise tools;
+- Card-in-card layouts or a full-page wall of cards;
+- Navigation items, entry cards, and list rows centered as a whole;
+- Content sections without titles, or titles wrapped inside bordered content containers;
+- Page-level search placed inside a content section, filters stretched full row, or filters and Tabs split into loose rows;
+- Recognizable system controls hand-written as static `div` elements;
+- Images without source and responsibility;
+- Hero, welcome area, recommended content, product entry, or empty state carrying visual explanation but using only outlined icons or pure text, without planning illustration-library, product image, thumbnail, or generated-image fallback;
+- Page UI icons using filled icons without source evidence or an explicit `source-filled` strategy, or using emoji, characters, hand-written SVG, or third-party icon libraries instead of catalog icons;
+- colorful used as ordinary decoration, or an explicit icon area mixes family, v2 / non-v2 version, or File v2 colorful round / normal shapes;
+- Ordinary entries, categories, KPIs, avatars, or decorative areas using high-saturation colors to distinguish business types;
+- Vague requests proactively filling the whole page with content;
+- Adding modules only because a case contains them.

package/miaoda/lark-design-prototype/references/visual-style-prompts.md

@@ -0,0 +1,61 @@
+# Visual Style Prompts
+
+Use this reference when the user only says "Feishu style", "minimal and polished", "clean", "large whitespace", or when media assets need to be generated. It provides a unified style direction and does not define fixed page templates.
+
+## Default Style
+
+```md
+visual_style_prompt:
+  feel: polished, minimal, clean, tidy, low-density, real Feishu product feel
+  surface: white or very light neutral surfaces; body / app-root / main-workspace / main-content / right content area should prefer bg-body; light gray is only for side navigation, low-emphasis shells, or local backing surfaces, avoiding heavy gray backgrounds and strong shadows
+  composition: clear app shell + stable content spine + a small number of responsible visual anchors
+  density: content groups default to 40px spacing; information feels clean; one card carries only a small amount of key content; use the minimum content set first when the request is vague
+  color: brand blue is used for primary actions, links, focus, current state, real status, and a small amount of brand identification; entries, avatars, icon backgrounds, KPIs, and ordinary tags prefer neutral or low-saturation colors; avoid multiple accent sources in the same viewport
+  noise: control accent colors, font weight, nested backgrounds, gradients, and random spacing; sidebars stay neutral and low-presence; keep the view clean first
+  shape: controls around 6px radius, content cards around 8px, pills only for tags, filters, and a small number of recommended questions
+  border: ordinary business surfaces use 0.5px light borders; reduce meaningless dividers
+  shadow: ordinary business surfaces have no shadows; shadows only for floating layers
+  imagery: when Hero, welcome areas, recommended content, product entries, empty states, and workspace home pages carry visual explanation, first plan illustrations, thumbnails, product images, or entry icons; check the illustration library before considering generated imagery
+```
+
+## Generated Image Style Fragment
+
+When `media_plan` uses `generated_bitmap`, reuse only this style fragment. The specific visual content is decided by the current slot.
+
+```md
+generated_media_style:
+  overall: Feishu / Lark enterprise product visual, advanced, minimal, light, refined, and directly related to the current module theme.
+  surface: white or very light neutral surface, fine boundaries, low noise.
+  color: small-area brand blue accents, optionally with low-saturation cyan, green, purple, or orange; avoid high-saturation clashes and multiple strong highlights.
+  scope: media_slot_asset_only
+  content: independent visual element, such as data visual, workflow thumbnail, light illustration, avatar, product image, important entry icon, empty-state graphic, or recommendation cover.
+  composition: clear subject, generous whitespace, adapted to target media-slot ratio; may become a local visual focus, but visual weight stays restrained.
+  avoid: heavy shadows, gradient backgrounds, gradient buttons, gradient borders, cyber look, marketing poster, complex background, toy-like cartoon feel, posed people photography, purely decorative abstract image, unreadable pseudo text, full page UI, complete dashboard, navigation bar, sidebar, table page, button/form combination, browser shell.
+```
+
+Prompt assembly:
+
+```md
+prompt_inputs:
+  page_topic:
+  module_context:
+  semantic_goal:
+  content_type: data-visual / product-preview / workflow-visual / empty-state / recommendation-cover / avatar / product-image / entry-icon / light-illustration
+  slot_ratio:
+  library_lookup:
+  generation_scope: media_slot_asset_only
+  style_direction: generated_media_style
+  negative_constraints: generated_media_style.avoid
+```
+
+## Low-Quality Result Corrections
+
+- Reduce information stacking: keep concrete data, metadata, status, or entries in primary areas, but one card presents only a small amount of key content.
+- Narrow content scope: when the request is vague, keep only product identity, primary task, one main content area, necessary primary action, and a small set of samples.
+- Reduce visual noise: reduce unnecessary brand blue, functional colors, bold text, light-gray background nesting, gradients, and random spacing; avoid gray backing with white cards, white cards with gray blocks, all-blue icon matrices, and multiple bold text layers.
+- Reduce boundary weight: reduce full frames and keep only key containers and real control boundaries.
+- External section titles: except for Hero and overview cards, content section titles sit above bordered containers and use titles plus whitespace to express module hierarchy.
+- Add a responsible visual anchor: choose an illustration, product image, or entry icon that matches module semantics.
+- Improve entry hierarchy lightly: quick entries and lightweight recommendation entries may use low-opacity blue fills in icon containers. Cards in the same row take the height of that row's tallest card, avoiding uneven heights from different text line counts and large bottom whitespace from fixed heights.
+- Unify system language: custom shell, navigation, cards, and UD-style controls share tokens, radius, states, and icon scale.
+- Tighten scale: do not enlarge title, icon, card height, and row spacing all at the same time.