@autoaiai/aicut 0.1.11 → 0.1.13

package/skills/hyperframes-motion-director/references/premium-product-promo.md

@@ -1,287 +0,0 @@
-# Premium Product Promo System
-
-Use this reference when a motion video promotes a product, tool, skill, SaaS, CLI, app, API, workflow, template library, or creative system. It is especially important when the user provides a premium reference, asks for a video that feels high-end, or criticizes a draft for lacking icons, decorative elements, image resources, interaction, or sharp copy.
-
-## First Principles
-
-Premium product motion does not come from black backgrounds, large text, or glow alone.
-
-It comes from visible specificity:
-
-1. The viewer sees the product's world, not only a metaphor.
-2. Each claim is backed by an artifact: command, screenshot, document, card, module, number, workflow step, output, logo, provider, or before/after state.
-3. Visual density is organized into reusable components, not scattered decoration.
-4. Motion makes product state change visible: input becomes output, cards fan out, modules assemble, command routes to draft, proof locks.
-5. Copy names a concrete pain, concrete mechanism, concrete proof, and concrete action.
-
-A weak cinematic promo often has one background image and several generic slogan beats. A strong product promo has a product proof ecosystem.
-
-## Source-Driven Visual System
-
-Asset volume does not create premium design. A video can have many icons, generated props, and cards while still feeling ordinary when those assets are not derived from the copy or product mechanism.
-
-Before choosing assets, translate the source material into a visual lexicon:
-
-- Source phrases: exact claims, lines, nouns, verbs, numbers, and tensions from the README, article, product page, script, or confirmed copy.
-- Concrete nouns/entities: commands, files, folders, drafts, reports, modules, screenshots, theme cards, metrics, providers, checks, surfaces, platforms, or states.
-- Process verbs/actions: write, route, convert, collect, inspect, publish, save, export, fan, assemble, lock, recover, grow, or hand off.
-- Core motif: one visual metaphor that can repeat without becoming wallpaper.
-- Component families: three to five reusable families such as command surfaces, output papers, taxonomy chips, validation marks, metric tiles, or route nodes.
-- Text-to-component map: each major component names the source phrase it visualizes.
-- Big-text-box replacement: paragraphs become objects, proof surfaces, chips, kinetic keywords, diagrams, or short captions.
-- Generic rejection list: office props, AI chips, dashboards, paper piles, desk scenes, generic cards, or golden icons that could fit another project.
-
-Use this recognition test: if the still frames could advertise a different product after changing only labels, the visual system is generic. Redesign the motif, component families, or source phrase mapping before implementation.
-
-## Reference Teardown Pattern
-
-When learning from a reference video, extract:
-
-- Scene count and duration.
-- Visible product artifacts per scene.
-- Real assets: logos, screenshots, product images, documents, theme previews, covers, UI states, or exported outputs.
-- Code-generated components: command cards, proof cards, anchored signals, chips, stat blocks, browser frames, device frames, draft cards, badges, and panels.
-- Decorative system: grain, vignette, beams, floating fragments, glows, shadow plates, separators, and background fields.
-- Motion grammar: what enters, what transforms, what holds, what hands off the next beat.
-- Copy strategy: pain phrase, mechanism phrase, proof phrase, outcome phrase, CTA.
-- Design constraints: margins, card radius, panel borders, contrast, type scale, and color restraint.
-
-Do not copy a reference literally. Copy its production logic: proof density, asset specificity, component reuse, and motion handoffs.
-
-## Product Proof Inventory
-
-Before writing a product promo brief, inventory product-specific proof. If the user supplied none, inspect the project and create plausible code-native representations instead of falling back to abstract metaphors.
-
-Look for:
-
-- Product name, logo, favicon, app icon, mascot, or brand mark.
-- CLI commands, API calls, config files, terminal output, code snippets, or workflow syntax.
-- Screenshots, generated outputs, examples, templates, dashboards, exported documents, covers, charts, or before/after artifacts.
-- Numbers: module count, template count, provider count, supported formats, workflow steps, saved time, version count, or benchmark result.
-- Taxonomy: themes, modules, integrations, modes, providers, commands, features, or stages.
-- Trust evidence: checks, validations, snapshots, review reports, export files, logs, or status badges.
-
-Derive the asset inventory from the product and confirmed copy. Include a product/brand lockup, concrete surfaces, proof artifacts, taxonomy, and recurring motion objects only where the source requires them. If the inventory cannot visibly prove the mechanism, the brief must request/supply assets, generate proof-safe representations, or acknowledge that the result will feel more like a concept film than a top-tier product promo.
-
-## Component Library
-
-A premium promo needs a small component library before implementation. Components must be reusable across scenes and bound to product meaning.
-
-No visible product component, no product promo. Treat the component library as a production dependency, not a nice-to-have. A component counts only when it is visible in snapshots and has product-specific content, state, and interaction. Generic cards, titles, labels, background glows, floating lines, and decorative icons are not enough.
-
-Content-derived component coverage:
-
-- Every source phrase, mechanism, proof claim, taxonomy group, and final action that needs a visual object appears in the inventory.
-- Concrete product surfaces, taxonomy components, and final actions are included when the source contains them.
-- Important mechanism or proof components appear early enough that the first half is not only titles and atmosphere.
-- Snapshot proof exists for each major component type.
-- Motion proof exists for every component type. A component that only sits in the frame does not count.
-- Premium vertical generated-image work uses at least one source-driven component sheet designed for clean crop extraction and consistent style. The content decides its inventory size.
-
-Useful product promo components:
-
-- Command card: terminal, prompt, or API call with one highlighted action.
-- Draft/output card: product result as a paper, article, cover, image, report, or document.
-- Anchored route or signal: a workflow path, card-edge highlight, node sequence, progress strip, or CTA edge that connects specific objects; never a decorative divider.
-- Stat block: one huge number with a short proof label and supporting chips.
-- Module chip group: taxonomy labels such as `hero`, `toc`, `quote`, `timeline`, `cta`.
-- Provider chip group: integrations or model/provider names.
-- Theme/output stack: real screenshots or generated output cards fanned with perspective.
-- Proof card: icon/mark, title, one-line explanation.
-- Device/browser/product frame: only when it shows a real surface or believable state.
-- CTA badge or action pill: the final action as a tangible button, stamp, or route endpoint.
-
-Each component must define:
-
-- Role in the story.
-- Source: official asset, screenshot, generated mockup, code-native component, or supplied material.
-- Visual style and constraints.
-- Data/content slots.
-- Visible state in the hero frame.
-- Entry motion.
-- Hold state.
-- Exit or handoff.
-- State-change action: type, route, fan, assemble, reveal, scan, validate, transform, count, lock, export, publish, save, collapse, or hand off.
-- Snapshot timestamp where the component is visible.
-- Rejection test.
-
-## Generated Visual Component Sheet
-
-A component sheet is required for premium vertical generated-image work unless the user approves an explicit pipeline exception. Use it as source material, not as a finished frame. The inventory decides how many components are needed; isolation space and resolution decide whether to use one sheet, multiple sheets, or additional separate hero-object generations.
-
-Allowed sheet contents:
-
-- Product surfaces: browser frame, app panel, command card, output card, report card, document, template preview, theme tile.
-- Taxonomy pieces: feature chips, module chips, provider chips, mode labels, status tags.
-- Action marks: cursor, route node, check stamp, publish stamp, export mark, save pill, progress strip, inspection corner.
-- Texture pieces: shadow plates, paper fragments, screen glow, rim-light strips, subtle material plates.
-
-Sheet requirements:
-
-- Every item has a named role and target scene.
-- Every item maps to a source phrase, noun, verb, number, or product state.
-- Items share one visual language, palette, lighting, border radius, shadow, and material system.
-- Items have enough spacing or transparent background for auto-crop/manual crop.
-- No baked-in final screen text unless that text is the component itself.
-- Accepted items are cropped into local files or isolated as SVG/CSS pieces before implementation.
-- The storyboard records crop boxes, local paths, motion action, and deletion test.
-- Dark and light contact sheets prove clean transparent edges before animation.
-
-Reject a component sheet when it is a decorative sticker pack, contains random icons, mixes styles, lacks crop-safe spacing, looks like generic office/productivity material, or includes components that cannot be assigned to a source phrase, scene, and motion action.
-
-Premium components should feel built, not drawn flat:
-
-- Use nested shell/core structure for important cards, panels, command windows, proof cards, and CTA pills.
-- Outer shell carries spacing, shadow, hairline, and radius.
-- Inner core carries content, inset highlight, subtle material, and smaller radius.
-- Avoid generic gray 1px borders and flat cards on a black background.
-- Use borders, shadows, glow, and blur as material cues, not as default decoration.
-
-## Icon And Decorative Element Policy
-
-Do not ban icons and decoration. Ban meaningless icons and decoration.
-
-Use icons or marks when they:
-
-- Give a keyword physical behavior.
-- Compress a product action.
-- Make taxonomy scannable.
-- Prove a workflow stage.
-- Create a memorable interaction.
-
-Acceptable marks:
-
-- Cursor, terminal prompt, command dot, check tick, route node, upload arrow, save mark, draft stamp, image tile, provider chip, module chip, warning tag, bracket, underline, rail, lens, timeline node, document corner.
-
-Decorative elements are allowed only as a system:
-
-- 1 ambient texture system: grain, paper, glass, haze, or screen noise.
-- 1 light system: gold beams, rim light, glow, scan, or reflection.
-- 1 fragment system: paper chips, UI shards, code tokens, card shadows, or dust.
-- 1 border system: panels, cards, command windows, or frames.
-
-Reject decoration when it:
-
-- Fills empty space without proof.
-- Uses a different visual language from the product.
-- Competes with title or product artifact.
-- Becomes an icon pile.
-- Requires labels to be understood.
-
-## Anchored Connector Policy
-
-Lines, paths, rails, arcs, scan strokes, and underlines are easy to overuse in black-gold promos. Treat them as product components, not decoration.
-
-Keep a connector only when it has:
-
-- A visible start anchor and end anchor.
-- A semantic job: route, reveal, compare, focus, validate, hand off, or close.
-- A motion interaction that changes product state.
-- A safe-zone contract that protects the title, CTA, screenshots, and platform overlays.
-- A deletion test showing what comprehension or proof is lost without it.
-
-Reject a connector when it floats between unrelated areas, forms a pretty arc, fills empty space, or duplicates a clearer component state. In product promos, prefer attached signals: card-edge glows, route nodes, status dots, short progress strips, inspection corners, screenshot checks, chip states, cursor highlights, and CTA border lighting.
-
-## Image And Asset Library
-
-For product promos, image generation is not enough. Use a mixed asset library:
-
-- Supplied official assets first.
-- Existing repository assets next.
-- Generated bitmap assets for atmosphere, product-safe mockups, output stacks, backgrounds, or transition plates.
-- Code-generated SVG/CSS for icons, chips, panels, anchored signals, route-node sequences, command cards, and taxonomy marks.
-- Screenshots or rendered local artifacts when the product's value depends on actual output.
-
-Phase 1 must list the asset library plan:
-
-- Existing assets to inspect.
-- Generated assets to create.
-- Code-native components to build.
-- Screenshots or output previews to capture.
-- What each asset proves.
-- Which scene owns each asset.
-
-Phase 2 must inspect and record accepted asset paths before implementation.
-
-## Copy Sharpness
-
-Generic copy makes premium visuals feel hollow.
-
-Use this product promo copy ladder:
-
-1. Pain: name the old behavior in plain language.
-2. Mechanism: show how the product changes the path.
-3. Proof: name a number, module, output, or workflow step.
-4. Confidence: show checks, variants, providers, or generated outputs.
-5. CTA: give one action that matches the product.
-
-Prefer:
-
-- `公众号排版 / 别再手工调`
-- `一条命令 / 到草稿箱`
-- `43 / 高级排版模块`
-- `40 个 / 专业主题`
-- `AI 写作 / 也能进流程`
-
-Avoid:
-
-- `让创意更高效`
-- `开启全新体验`
-- `提升生产力`
-- `从想法到交付`
-- `更智能，更高效`
-
-If a phrase could describe any product, rewrite it.
-
-## Motion Interaction
-
-Every product artifact should have an interaction, not only an entrance.
-
-Examples:
-
-- A command card types or highlights a command, then routes to an output card.
-- Chips assemble around a stat, then collapse into a module panel.
-- Theme cards fan out with perspective and settle into a proof stack.
-- An anchored route signal draws only when it visibly connects left steps to right output.
-- A card-edge signal lights to show a command was accepted.
-- A node sequence lights to show workflow order without a floating line.
-- A proof card row rises in sequence and locks with a mark.
-- A CTA pill receives the final underline, stamp, or cursor.
-
-Motion review question:
-
-If the component did not move, would the viewer still understand the product action? If yes, the motion is likely decorative. Redesign the interaction around state change.
-
-## Premium Product Promo Gate
-
-Block final delivery when any of these are true:
-
-- The film uses only one abstract metaphor and no product-specific proof artifacts.
-- The product promo has no visible visual component library.
-- The source-driven component inventory is incomplete or its count has no written reason.
-- The component list is only prose and cannot be found in snapshots or rendered frames.
-- Components are generic duplicate cards with changed labels and no different product role.
-- Components are static placements with no state-change action.
-- A generated component sheet is used as a decorative collage instead of cropped, named, scene-owned components.
-- Components or generated assets are visually rich but not source-specific; they could fit a different product after relabeling.
-- Hero frames are dominated by large text boxes while visual components only decorate the margins.
-- The visual system has no source phrase mapping, visual lexicon, motif family, or generic rejection list.
-- The storyboard cannot name every concrete visual component required by the confirmed source and explain why each is needed.
-- The asset library has no official, existing, generated, screenshot, or code-native asset decision.
-- Copy is generic and could fit a different product.
-- Icons or decoration are either absent when the scene needs taxonomy/proof, or present only as unrelated ornaments.
-- Route lines, rails, arcs, or underlines are floating, unanchored, or only decorative.
-- Motion consists of scene fades and repeated text entrance patterns.
-- Snapshots look like title cards rather than product proof frames.
-
-Target score before render:
-
-- 20: product proof artifacts are concrete.
-- 20: component library is coherent and reusable.
-- 15: icon/decorative system supports meaning.
-- 15: copy is specific and high-retention.
-- 15: motion interactions show state change.
-- 10: visual hierarchy and mobile safe zones hold.
-- 5: CTA feels like the end of the product path.
-
-Below 90 blocks final delivery for a premium product promo.

package/skills/hyperframes-motion-director/references/text-over-background-layout.md

@@ -1,221 +0,0 @@
-# Text Over Background Layout
-
-Use this reference whenever text sits on, beside, or near a generated background image. The goal is to make the readable hold, entrance path, transition midpoint, and mobile safe zones work as one vertical motion composition.
-
-## Intent First
-
-Choose the layout intent before generating or placing an image. The intent defines the relationship between message, subject, background, movement, and transition. From that relationship, derive image ratio, subject position, quiet text zone, type scale, crop behavior, motion boundaries, and transition logic.
-
-Before choosing a lower-safe layout, map attention. In vertical video, the strongest first-read zone is center to slightly above center. Use this zone for hooks, sharp viewpoints, emotional keywords, and big typographic moments when the visual subject leaves it free. Lower-middle copy works for CTA holds, proof notes, or subject-dominant frames.
-
-Every text-over-background beat must declare one compact layout contract:
-
-```text
-Layout contract: cinematic side-title stage / 9:16 / left axis / textRect x=8% y=24% w=44% h=28% / subjectRect x=54% y=20% w=36% h=46% / quiet zone left 46% / safeBottomY<=85% / title tier main / motion stays inside textRect
-```
-
-The contract must include:
-
-- Layout intent: the visual relationship between background, subject, text, and transition.
-- Image ratio: final intended image ratio; avoid copying the source ratio by habit.
-- Text axis: left / right / center / top / bottom-safe / split.
-- `textRect`: the allowed title/support/CTA region in percent or pixels.
-- `subjectRect`: the required subject region after crop in percent or pixels.
-- Quiet text zone: where type may sit without fighting image detail.
-- Safe bottom boundary: the lowest allowed edge for CTA, subtitle, support line, or proof note.
-- Title size tier: hero / large / main / reduced / compact, chosen from copy length and language.
-- Motion bounds: text and key subjects must not move through unsafe zones during entrance, hold, transition, or exit.
-- Regenerate / recrop trigger: what failure means the image or layout must be changed.
-
-In Phase 1, this may be a candidate layout strategy rather than final geometry. After generated/supplied imagery is inspected, the storyboard must lock the final per-beat layout contract.
-
-If the final contract is missing or vague, the frame is not ready for HyperFrames implementation.
-
-The contract is not paperwork. It is the geometry of the frame. If it cannot be drawn as rectangles on a 1080x1920 canvas, it is not specific enough.
-
-## Layout Intent Patterns
-
-Choose the simplest intent that matches the message. These patterns are starting points. If the story needs another relationship, describe it in the same contract geometry.
-
-Default cinematic vertical films should start from a full-bleed stage, a center-symbol hold, or pure kinetic type. Use product panels, proof cutaways, and multi-evidence structures only for product demos, proof/evidence moments, UI explanation, or before/after comparison. Keep the film from feeling like static pages.
-
-### Cinematic Side-Title Stage
-
-- Use for cinematic metaphor scenes with one strong background image.
-- Image ratio: 9:16 generated or cropped from a larger source.
-- Subject zone: opposite the text axis or centered in the middle 60%; avoid right-edge social UI controls when targeting short-video platforms.
-- Text axis: left or right vertical column, usually upper-middle.
-- Quiet zone: 42%-48% of canvas width on the text side.
-- Avoid: centered subject plus centered title competing for the same space.
-
-### Center Symbol Hold
-
-- Use for one dominant symbol, product silhouette, number, or object.
-- Image ratio: 9:16.
-- Subject zone: center 60% width, 22%-58% height.
-- Text axis: lower-middle, but above the bottom platform overlay.
-- Quiet zone: dark lower third with local contrast treatment.
-- Avoid: CTA below the safe bottom boundary.
-- Caution: when text is the hook or emotional center, let it dominate the center and move the symbol behind/around it, or choose a side-title / kinetic-type layout.
-
-### Center Impact Type
-
-- Use for hooks, manifesto lines, major emotional turns, and short claims where the words are the image.
-- Image ratio: 9:16 background stage, pure kinetic type, or low-detail generated plate.
-- Subject zone: type owns center 70% width, 28%-58% height; image subject must stay behind, above, below, or at low contrast.
-- Text axis: center axis or controlled split axis.
-- Quiet zone: center field protected by darkness, blur, mask, or negative space.
-- Motion: type reveal should have a clear text transition, such as mask open, scan highlight, compression release, split-line handoff, or word assembly.
-- Avoid: treating center type as a static title slide. The text itself must move with intent.
-
-### Proof Cutaway Hold
-
-- Use when the image is evidence, product context, or atmosphere and the message needs a clean text field.
-- Image ratio: 21:9 or 16:9 proof cutaway cropped into the top 34%-42% of the vertical canvas.
-- Text axis: left-aligned bottom statement block.
-- Quiet zone: paper/black field below image; no text over busy image.
-- Avoid: putting the title inside the image cutaway unless the image was generated with a quiet zone.
-- Exception pattern: use sparingly in cinematic films; this is an explainer/proof relationship.
-
-### Split Product / Claim
-
-- Use for product launch, SaaS/UI, hardware, or feature reveal scenes.
-- Image ratio: 16:10 / 4:3 / 1:1 inside a stable frame.
-- Subject zone: product or UI panel in one half; claim in the other half.
-- Text axis: claim side, top-to-middle.
-- Quiet zone: claim side must be mostly solid black or low-detail texture.
-- Avoid: stretching screenshots or product images to fill the full 9:16 frame.
-- Exception pattern for product or UI beats. Use it for abstract metaphor scenes only when the split itself expresses the idea.
-
-### Sequential Proof Beats
-
-- Use for multiple screenshots, proof panels, feature cards, or before/after visual evidence when the viewer can understand the images without reading dense text inside them.
-- Image ratio: unified 16:10, 3:2, or 1:1 for the whole group.
-- Text axis: title above the evidence group, proof note below each panel only if readable.
-- Quiet zone: each panel owns its proof note; no floating text between panels.
-- Avoid: mixed image ratios, mixed scale, or proof notes falling into the bottom overlay zone.
-- Mobile caution: multi-panel evidence becomes unreadable quickly. Prefer sequential proof beats when the viewer must read text inside the images.
-- Exception pattern. Use multi-panel proof as a last resort.
-
-### Pure Kinetic Type
-
-- Use only when the confirmed brief explicitly chooses pure type or code-generated visuals.
-- Image ratio: none.
-- `subjectRect` may be `none`; the type itself becomes the subject.
-- Text axis: locked to an alignment system; title, support, and CTA still need safe zones.
-- Quiet zone: code-generated texture or black field behind type.
-- Avoid: using this exception to skip image planning.
-
-## Image Ratio Rules
-
-- Full background: generate or crop to 9:16 for `1080x1920`.
-- Proof cutaway: generate 21:9 only when the image is panoramic; keep subject in the central 70%.
-- Product / UI panel: use 16:10 or 4:3; preserve text and UI detail with contain behavior.
-- Sequential proof group: all images in the group must share the same ratio and visual scale.
-- User screenshots: if content must remain faithful, adapt to the intended frame with a background canvas before considering redraw.
-
-Never copy source-image odd ratios into the layout. The layout owns the ratio.
-
-## Title Size Tiers
-
-Chinese text has more visual mass than English. Pick the title tier before implementing the frame. Use Chinese tiers by default; if the brief overrides language, document the alternate tier logic.
-
-Approximate 1080x1920 starting points:
-
-| Title shape | Tier | Size | Line height |
-| --- | --- | --- | --- |
-| 1 line, 2-6 Chinese chars | hero | 118-156px | 0.95-1.05 |
-| 1 line, 7-10 Chinese chars | large | 96-118px | 1.0-1.08 |
-| 2 lines, each line <= 7 chars | main | 78-96px | 1.05-1.12 |
-| 2 lines, any line 8-11 chars | reduced | 62-78px | 1.08-1.18 |
-| 3 lines or required legal/product text | compact | 48-62px | 1.14-1.24 |
-
-Rules:
-
-- Prefer rewriting copy over shrinking type.
-- Set manual line breaks at semantic boundaries.
-- Maximum title lines: 2 for most beats; 3 only for quote or manifesto scenes.
-- Support text is 1-2 lines, usually 30-44px on 1080x1920.
-- CTA / brand lockup is 1 line, usually 28-40px, and must not compete with the title.
-- Mixed Chinese/English terms need a fallback width rule so product names cannot escape the text block.
-- Letter spacing defaults to `0`; do not use negative tracking.
-
-## Mobile Text Density And Spacing
-
-Short-video viewers read in glances. Text density must let the main idea land in one look.
-
-- One beat carries one sentence-level idea.
-- Title: 4-14 Chinese characters is the normal range; beyond that, rewrite or split beats.
-- Support: one clarifying line.
-- Proof text: use one number or one short claim; dense evidence belongs in sequential beats, not small panels.
-- Vertical spacing between title and support: 24-48px depending on title size.
-- Vertical spacing between support and CTA/proof: 40-72px.
-- Keep at least 72px between any text block and the edge of its local text field.
-- Keep text blocks visually grouped; do not scatter title, support, proof, and CTA into unrelated corners.
-
-## Text Axis Rules
-
-- Left or right axis: align title, support, and CTA to the same vertical edge.
-- Center axis: use when the text is the subject or the image subject sits away from center.
-- Split axis: image and text occupy separate zones; do not let text float over the image edge.
-- Bottom axis: valid only when the safe bottom boundary is explicit and the title clears platform UI.
-- Axis consistency is the default. Break it only when semantic hierarchy requires it, and document why.
-- For hooks, center axis is often the strongest choice because it owns first attention. If center axis feels weak, check type scale, motion, contrast, and background detail first.
-
-Platform UI, subtitle, proof note, support line, and CTA are different semantic layers. Do not repeat the same text in two layers.
-
-## Safe Bottom Rule
-
-For 9:16 social video, the bottom overlay zone is dangerous. Default:
-
-- Keep CTA, subtitle, proof note, support line, and brand lockup above the bottom 15% of the canvas.
-- Keep primary title above the bottom 22% unless the layout is a confirmed lower-title frame.
-- Keep important text away from the right-side control rail when targeting TikTok/Reels/Douyin style surfaces; avoid placing small text in the rightmost 12% unless the platform is explicitly clean.
-- Keep top identity labels and title text below the top 8%-10% unless the platform/surface has no top interface overlay.
-- If a beat needs bottom text, reserve a local black field and document the lowest y-boundary.
-- Keep bottom-aligned CSS and motion paths above the final 15% during entrance, hold, and exit.
-
-The storyboard must include a safe bottom boundary such as `safeBottomY<=85%` or `lowest text edge <= 1632px on 1080x1920`.
-
-## Background Prompt Requirements
-
-Generated background prompts must include layout information:
-
-- Final role: stage / symbol / product context / evidence / texture.
-- Layout intent.
-- Aspect ratio and target crop.
-- Subject location.
-- `textRect` and `subjectRect` in plain language if the image tool cannot use coordinates.
-- Quiet text zone.
-- Crop-safe subject zone.
-- Forbidden content: baked-in text, logos, platform UI, subtitles, proof labels, watermarks, decorative borders, high-frequency detail in the text zone.
-
-If the image returns with text in the quiet zone, a subject on the wrong side, or no crop-safe region, regenerate or recrop before writing animation code.
-
-## Static Frame Gate
-
-Before motion, inspect the readable hold frame. This is a gate:
-
-- Confirm the first eye target is obvious within one second.
-- Confirm hook text keeps a strong attention zone.
-- Snapshot the hero frame or inspect the static composition.
-- Confirm one dominant visual mass and one dominant text block.
-- Confirm `textRect`, `subjectRect`, and `safeBottomY` match the layout contract.
-- Confirm title, support, CTA, subtitles, and proof notes are inside their declared zones.
-- Confirm title size tier, line count, line height, max width, and spacing are readable at phone size.
-- Confirm contrast treatment is local and does not look like a generic card unless the selected intent calls for a panel.
-- Confirm no important subject, UI text, face, product edge, subtitle, or proof note is cropped.
-- Confirm the frame remains readable without animation.
-
-If the still frame fails, fix layout or image first. Motion cannot rescue a broken text-over-background composition.
-
-## Motion And Transition Integration
-
-Text, background, motion, and transition are one composition.
-
-- Background motion must preserve the quiet zone during the full readable hold.
-- Text entrance must land inside `textRect` before the viewer needs to read it.
-- Text exit keeps readable copy away from unsafe bottom and right-side control zones.
-- Transitions should use the existing subject, text axis, mask, light direction, or camera move as the bridge.
-- If the next beat uses a different layout intent, define the transition midpoint: what remains stable, what moves, and when the new quiet zone becomes readable.
-- The strongest transition is often a hold plus one meaningful movement.