canvas-brand-web-design

name	canvas-brand-web-design
description	Use when the user asks JarvisHub AI Chat or a `webHero` workflow to generate a website, landing page, homepage, brand-style web design, preview-first webpage workflow, or wants section screenshots, webpage assets, and final HTML to be produced as one staged flow.

JarvisHub Brand Web Design

Turn a vague web request into a staged JarvisHub production flow that stays visually coherent from preview images to assets to final code.

Success Definition

Treat a webHero website workflow as complete only when all of the following are true:

1. A concrete webHero target node exists for final code. If the flow does not already contain one, create it with canvas_create_webhero_node.
2. Section-level webpage preview screenshots exist as real image nodes.
3. The preview set has been confirmed by the user, or the current thread contains explicit approval for that exact preview set.
4. A prior asset inventory exists before codegen: visibleSubjectInventory plus flat webPageAssetRequirements.visualSlots, with one slot for each preview-visible non-text subject that needs implementation and at least one slot whose direct previewNodeId matches every approved preview.
5. A persistent webPagePreviewVisualSpecs array exists before asset planning, with one implementation-grade visual spec per approved preview. Each image asset slot must bind to that visual spec through visualSpecId, visualSpecSummary, or sourceEvidence.
6. Every image_asset slot is resolved before codegen. Slots marked generate or narrative/product/lifestyle/UI image slots must have a real canvas image node preserving page/asset/slot identity and a browser-usable imageUrl; their webPageResolvedAssets ledger entries persist assetId plus the exact generated sourceNodeId, never a copied internal URL. Searched/reused external assets persist their browser-usable URL directly.
7. Final code is written to webHeroHtml, webHeroCss, and webHeroDocumentHtml on the target webHero node, never into a text node.
8. Every approved preview screenshot is represented by a real final DOM <section data-preview-node-id="...">.

Sub-Agent Delegation

The root agent is the orchestrator: it owns Runtime Stage decisions, the style/preview confirmation gates, pre-code evidence persistence, and final delivery summary. The subtasks below are independent and context-heavy and MUST be delegated to sub-agents via the Agent tool — running any of them inline on the root is a delegation regression. The root agent runs only the orchestration spine (stage decisions, gate decisions, contract persistence, final reply); every search, every preview/asset image generation, every consistency/fidelity check, and final WebHero code generation/commit goes through a sub-agent dispatch. Delegation never bypasses the existing gates (style selection, preview approval, codegen prep).

explore (sync, read-only fact gathering) — MUST be dispatched for every search call:

• Style / icon / web_asset searches: canvas_web_style_reference_search, icon_search, web_asset_search, font_recommendation_search (used in stages 2, 13). Return candidate URLs and metadata to the root agent; do not pick or write canvas.
• Reading existing canvas state: list current webHero / preview / asset node IDs and completion/ownership evidence, surface what's already resolved vs missing. Internal media is handed off by sourceNodeId; do not copy its hidden imageUrl.

plan (sync, Skill-only whitelist, pure synthesis output) — MUST be dispatched for stages 11–12 synthesis:

• Section plan + visual spec + asset slot inventory derivation: webPageReferencePrompt, webPageImplementationBrief, fontPlan, previewDetailChecklist, webPagePreviewVisualSpecs, componentReferencePlan, visibleSubjectInventory, flat webPageAssetRequirements.visualSlots (stages 11–12).
• Resolving search-backed slots into a webPageResolvedAssets proposal for searched/reused URLs (stage 13, search half) — the root agent or a media sub-agent persists the result.
• Final delivery summary: collect node ids, asset URLs, code character counts, failures into a human-readable handoff.
• The synthesis OUTPUT for stages 11–12 MUST come from a real Agent({subagent_type:"plan"}) dispatch. Even though the root agent (not the plan sub-agent) is the one calling canvas_update_node_data to persist the result, the brief content itself — webPageReferencePrompt, webPageImplementationBrief, fontPlan, previewDetailChecklist, webPagePreviewVisualSpecs, componentReferencePlan, visibleSubjectInventory, and the flat webPageAssetRequirements.visualSlots — must be authored by the plan sub-agent and copied verbatim into two ordered persistence calls: first the six stage-11 preview_visual_spec fields, then the stage-12 asset_inventory fields. Never combine those two phases in one patchNodeData[].data item. Doing the synthesis inline in the root agent's own Thinking block / reasoning and only delegating the final write is forbidden: the value of the plan sub-agent is the dedicated synthesis context, not the persistence verb. If the plan dispatch fails with infra errors (Cloudflare 5xx, timeouts, sub-agent 执行失败：LLM 请求失败) two times in a row, STOP and fail loudly to the user — do not author the brief inline as a fallback.

media (generation dispatcher) — MUST be dispatched for stages 8–9 and 13 generation:

• Section preview screenshots: dispatch the media sub-agent synchronously so it must return only after canvas_image_generate_to_canvas has created/updated the preview image nodes and canvas_image_wait_for_result has resolved every preview node to success or a clear failed/timed_out status. Do not use run_in_background:true for this phase. The root must not advance to preview review, asset planning, or final code while any preview node is merely queued/running; if generation is still pending, return a waiting summary that names the pending node/task IDs.
• generate-marked image_asset slots: per-slot canvas_image_generate_to_canvas, preserving page/asset/slot/preview/visualSpec identity through fields currently supported by the tool schema (stage 13, generate half). Do not batch all page assets into one sub-agent; one generated image slot should normally be one webhero_asset_generator dispatch so failures and fidelity issues stop at the cheapest breakpoint.

critic (sync, multimodal evaluation) — dispatch only at the two visual gates below; do not add per-tool or per-section critic checks:

• Style / brand consistency check across the approved preview set before the asset stage. Inline self-review (a Thinking-block verdict JSON or any other root-agent self-judgment) is NOT a substitute and is forbidden — the consistency verdict must come from a real Agent({subagent_type:"critic"}) dispatch.
• If the preview critic returns needs_revision/fail for only a subset of preview nodes and those nodes are regenerated, the follow-up critic dispatch must be scoped to the regenerated node IDs plus the minimal neighboring/context preview IDs named in the original issue. Do not reread the entire preview set after a targeted fix unless the original issue was global style inconsistency. Persist the earlier passing node reviews and merge them with the targeted follow-up verdict.
• Asset-vs-preview fidelity check after generate-half resolution: run one batched critic review for the generated assets against their owning approved preview screenshots. Do not call critic once per asset or after every normal canvas write.
• Critic infra failure must fail loudly, not silently fall back. If two consecutive Agent({subagent_type:"critic"}) dispatches for the same review fail with infrastructure errors (Cloudflare 5xx such as 524, LLM provider timeouts, or sub-agent 执行失败：LLM 请求失败 messages), STOP the WebHero workflow and return a final reply to the user that explicitly names the critic failure and the affected stage. The critic verdict (pass / fail / needs_revision or any equivalent shape) MUST come from a real Agent({subagent_type:"critic"}) dispatch and from no other source. The following are explicitly forbidden as substitutes when the critic dispatch is failing: (a) root-agent media reads via canvas_read_node_media_for_context followed by internal judgment; (b) any other root-agent multimodal / evaluation tool that returns a verdict-shaped output, including but not limited to canvas_evaluate_node, canvas_image_evaluate, canvas_visual_compare, or any future tool whose output the root agent could read as pass/fail/needs_revision; (c) Thinking-block self-judgment serialized into a verdict JSON; (d) persisting a webPageWorkflowContract.stepStatus such as critic_unavailable_proceeding_with_runtime_self_check / proceeding_without_critic / runtime_self_check_* or any similar marker that implies the root agent supplied the verdict. Surfacing the critic failure to the user is the required exit; do NOT advance to stages 11–18 codegen, do NOT advance to asset generation, and do NOT mark any stage on the basis of root-agent self-inspection. Resuming requires either the critic infra recovering (third dispatch returning a real verdict) or explicit user instruction to override. A generic continuation such as "继续", "继续做", or "继续生成" is NOT override authorization; override requires explicit language such as "跳过 critic/跳过评审/允许绕过质检继续".

Final WebHero section-draft orchestration — root/main owns stages 16–19:

• Read current canvas state, the target WebHero contract, approved preview node IDs, resolved assets, retrieval records, and the web_generation_codegen_prepare diagnostic contract.
• Do not dispatch the coarse codegen sub-agent for WebHero final-code retries. It is too long-running for breakpoint debugging because it can wrap all section_codegen calls inside one bridge request.
• Step 1, section generation: root/main compares sectionCodegenContract.sections with existing targetNode.data.webPageSectionDrafts, then dispatches section_codegen only for missing or invalid sections with result_mode:"full". Each dispatch must include a scoped task_contract with kind:"webhero_section_codegen", targetNodeIds:[<target WebHero node id>], contextNodeIds:[<that section's approved preview node id>], and allowedNodeIds containing exactly those two identities, plus the section order, section id, visual slots, the emitted assetId -> url map, required embedded asset ids, global font/motion/detail tokens, and a clear instruction that preview screenshot URLs are reference-only and must not be embedded. For internal canvas assets the emitted url is exactly {{asset:<sourceNodeId>}}; pass and embed it verbatim, because commit resolves it server-side.
• Step 1 morphology rule: every section_codegen dispatch must tell the sub-agent to inspect the approved preview before styling media. Only create a card/panel/frame when the preview visibly places that exact subject inside a rounded/square card, bordered frame, shadowed tile, or glass panel. If the preview shows a transparent/cutout/background-matched/masked/full-bleed/inline asset, place the media directly and do not add an invented card, border, drop shadow, white box, glass tile, or generic ImageCard/ProductCard.
• Step 2, section-draft persistence: after each section draft returns successfully, root/main immediately upserts the exact full structured output into the target WebHero top-level field webPageSectionDrafts; the runtime replaces any model-supplied provenance with content-bound codegenProvenance. Do not hand-author, edit, normalize, or alias-convert the draft, and do not wait for every section to finish before the first persistence write. Each item must include sectionId, previewNodeId, order, html, css, , , , , and . A timed-out, failed, blocked, null-output, partial, or legacy alias-only result is not a draft: rerun only that section and never persist a fallback. Re-read the target node and verify one provenance-valid draft covers every approved preview before merge.

Rules that delegation must respect:

• Delegate final WebHero code commit only to webhero_merge_codegen. The root agent owns section_codegen orchestration, section draft persistence, validation, and final reply.
• Never let a sub-agent run section preview image generation before the target webHero's webPageWorkflowContract.selectedStyleReference has been persisted and then verified by a fresh canvas_flow_get (whether selected via ask_user or auto-decided per stage 3). Dispatch with the single canonical task_contract.kind="webPreview_generation", one target WebHero node ID, and flowUpdatedAt copied exactly from that read. Any later canvas write invalidates the read and requires another canvas_flow_get before dispatch.
• If style search returns degraded/empty, do not dispatch a media sub-agent for previews — surface the search failure per the Style Reference Selection Gate.
• After dispatching a media sub-agent, advance the Runtime Stage only from real completed node evidence: every required preview node must have a browser-usable URL and success status before preview review. Do not treat "sub-agent started", submitted task IDs, or queued sub-agent summaries as evidence of completed generation.
• Do not dispatch critic just to read an external style-reference URL from search results. External style URLs are selection metadata, not a hard multimodal gate; persist the selected card and derive the initial style bible from the search result title/metadata plus the user's requested style direction. The two critic gates are for real canvas preview/asset nodes after generation, where media is under JarvisHub control.
• If an upstream URL is missing, leave the dependent slot in blocked; do not invent a substitute prompt.
• plan whitelist is Skill only; do not let it call canvas_* / *_search. explore is read-only; do not let it write canvas.

Runtime Stages

1. Create or reuse one concrete webHero target node and initialize webPageWorkflowContract on it. The contract is the short persistent source of truth and must include currentStep, stepStatus, selectedStyleReference, sharedStyleBible, approvedPreviewNodes, and missingItems.
2. Run canvas_web_style_reference_search before any WebHero webpage preview generation.
3. Present style reference candidates and choose a direction before generating previews. If style search returns usable image candidates, the root agent must call ask_user with visual optionCards and wait for the user's choice. The root agent may auto-select only when the user explicitly asks the system to choose for them in the current request (for example, "你直接选一个风格"). A named category such as "Awwwards 风格" is a search direction, not permission to skip visual selection.
4. Choose 5 visually distinct real results and call ask_user with optionCards. Each card must include value, imageUrl, thumbnailUrl, title, and displayValue. Use value for the machine-readable selection payload, and set displayValue to a short text such as 已选择风格参考：B so the chat never shows a raw URL as the user's visible reply. Do not create canvas reference image nodes, do not create a 网页风格参考候选 group, and do not list source/page/image URLs as text for the user to copy. The UI renders clickable thumbnails and lets the user enlarge the real image.
5. If style search returns degraded or empty results, stop the WebHero preview workflow and report the search failure. Do not create generated fallback style boards, do not call image generation to invent references, and do not continue into section preview generation.
6. Style reference candidates must come from real search results or existing real URLs. Generated images are allowed later for webpage assets, but never as fake public style references.
7. Only after the user chooses a candidate, or after an explicit user instruction to auto-select has been honored, persist that choice as a canonical object in webPageWorkflowContract.selectedStyleReference: include title and at least one public, model-executable HTTP(S) imageUrl, originalImageUrl, or ; a bare URL string, metadata-only object, local/private-only URL, or text-only custom description is invalid. The exact call that changes must also pass , and it must not write specs, assets, briefs, checklists, or section drafts in that same transition call. Derive from the search result title/source/metadata, the user's requested style direction, and the selected card's fit reason. Later step-status patches must be partial and must not resend . Immediately call , verify the exact target node contains that canonical persisted object, and copy that read's exact . Do not mutate the canvas between this verification read and preview-media dispatch. The backend stamps each preview with the exact selected-style URL identity; changing the selection atomically clears prior approval/spec/asset/draft/final-code evidence. Do not block the workflow on reading external Pinterest/Bing image URLs with critic; those hosts are often slow or TLS-fragile. The generated preview screenshots become the first hard multimodal evidence and must be evaluated by critic after they exist on canvas.

Style Reference Selection Gate

• Never call section preview image generation until a fresh canvas_flow_get proves the target webHero node has canonical webPageWorkflowContract.selectedStyleReference; top-level aliases and sharedStyleBible are not authorization evidence. Use canonical task_contract.kind="webPreview_generation" and copy that read's exact updatedAt into flowUpdatedAt.
• Search degraded/empty is not approval to continue into preview generation, and it is not approval to generate fake style references.
• If search is degraded/empty, stop and report the search failure with the provider warnings. The next action is to repair search or adjust search terms/source, not to generate images.
• After the user chooses a style candidate, update the contract first, then generate section previews. The preview prompt must cite the selected reference and the derived shared style bible.
• If the user chooses custom style instead of a candidate, require an uploaded/public model-executable reference image. A text description may supplement sharedStyleBible but cannot by itself become selectedStyleReference; do not generate previews until the canonical object contains a real image URL.

Post-Approval Gate

When the user replies with approval such as "采用这组预览，继续生成最终官网代码", interpret that as permission to enter the asset/reference stage, not permission to write final code immediately.

Immediately after preview approval, the first todos must be about reading the flow, identifying approved preview nodes, extracting the implementation reference prompt/brief, planning component references, planning assets, and resolving or generating assets. Do not create todos named "构建 HTML/CSS", "写最终代码", or "提交 webHero 代码" until the evidence below exists on the target webHero node.

Required evidence before canvas_webhero_code_stage_chunk, canvas_webhero_code_commit, or any canvas_update_node_data that writes webHeroHtml, webHeroCss, or webHeroDocumentHtml:

• webPageReferencePrompt
• webPageImplementationBrief
• fontPlan or webPageImplementationBrief.fontPlan
• previewDetailChecklist or webPageImplementationBrief.previewDetailChecklist
• webPagePreviewVisualSpecs, one item per approved preview
• componentReferencePlan with real retrieval records/section decisions, or explicit per-section write_from_scratch decisions with implementation notes
• visibleSubjectInventory and webPageAssetRequirements.visualSlots as a flat pre-code inventory, not grouped slots and not post-gate patch data; each image_asset slot must carry visualSpecId or sourceEvidence
• webPageResolvedAssets with browser-usable URLs for external searched/reused assets and exact sourceNodeId references for generated canvas asset records
• Real canvas image nodes for every generated/narrative image_asset slot, carrying matching page/asset/slot identity
• webPageAssetDecisions with five sections (icons, searchAssets, generatedAssets, fontPlan, stylePlan); generatedAssets is a non-empty array of real { assetId, slotId, sourceNodeId | generatedNodeId, ... } records, while the other sections are non-empty decision arrays or { emptyReason }

canvas_webhero_check_readiness is a hard final-code gate, not an advisory diagnostic. Root must call it immediately before the single merge dispatch, copy its exact previewNodeIds, flowUpdatedAt, and codeInputDigest into the merge contract, and continue only when data.ready=true. If it returns ready=false, any missing item, or a tool error, return blocked and repair that exact persisted evidence; do not dispatch merge, stage code, or commit.

Forbidden immediately after preview approval:

• Calling canvas_read_node_media_for_context as a shortcut into codegen.
• Calling canvas_webhero_code_stage_chunk or canvas_webhero_code_commit from the root agent.
• Writing webHeroHtml, webHeroCss, or webHeroDocumentHtml in the same patch that first writes the reference prompt or implementation brief.

Preview-Derived Asset Resolution

After preview approval, inspect each preview as an implementation target and decide assets at the moment they are needed:

• Icons, arrows, spec symbols, dock controls, configurator controls, badges, and tiny UI glyphs: call icon_search first. Use existing icon sets such as lucide, tabler, ph, mdi, or meteocons. If SVG/vector metadata or license/dimensions are needed, call web_asset_search too. Do not hand-write SVGs from memory.
• Fonts: extract the preview's typography feel into fontPlan, including display/body font names, loading URL if external fonts are used, fallback stack, and usage notes. Put the font plan on the asset board.
• Public/reusable images: for broad backgrounds, abstract plates, architecture, people, lifestyle, product atmospheres, and generic scene media, search reusable public/Aura assets first and record accepted/rejected candidates.
• Generated images: for precise branded/product hero images, single isolated transparent cutouts, device/watch/car cutouts, unusual crops, or motion state variants, first record the flat slot, then search if search could realistically satisfy the slot. If search fails quality, transparency, license, crop, or relevance checks, call canvas_image_generate_to_canvas for the same assetId/slotId before final code. Set transparentPng=true only for one isolated foreground object/logo/sticker/product with no background plate that must layer over live HTML/CSS. Do not request transparency for full hero scenes, illustration clusters, dashboards, maps, background art, or composed section artwork; generate those as embedded images with a matched background. A failed or unsuitable search is not a terminal state.
• For every generated image prompt, carry the slot's intendedWebUsage.surfaceTreatment/cardPolicy. If the approved preview does not visibly show a card/panel/frame around that subject, the prompt must explicitly say: no rounded rectangle, no square card, no border, no drop shadow, no white box, no glass tile, no framed image container. This prevents image models from baking a fake card into assets that should be cutouts, matched-background media, masked planes, or full-bleed media.
• Generation is mandatory for any slot whose final decision is implementation="generate" and for narrative/product/lifestyle/UI image slots that do not have an accepted searched URL. The generated node must reuse the slot's assetId and slotId; do not create a generic card image and later rename it.
• Every resolved asset must include a source audit: existing canvas checked, public/icon search checked, candidate URLs or record ids, rejection reasons when generating, and final decision.

Asset Decisions (Structured Field)

Before final code, surface asset reasoning as structured data on the webHero node. Write webPageAssetDecisions with five sections:

• icons: array of { iconId, source, usage } from icon_search / icon web_asset_search records.
• searchAssets: array of { url, source, decision: "accepted" | "rejected", reason }.
• generatedAssets: array of { assetId, slotId, generatedNodeId, reason }.
• fontPlan: array of { font, role: "display" | "body", url?, fallback?, usage }.
• stylePlan: array of { title, usage, body?, prompt?, imageUrl?, url? } summarizing the selected style reference and sharedStyleBible into inspectable palette / typography / composition / material / motion cues.

All sections other than generatedAssets may instead be { emptyReason: "<explicit reason>" } when there is a real decision to leave them empty (e.g. all visible glyphs are CSS/text — record that as icons: { emptyReason }). Empty arrays without emptyReason are not accepted, and generatedAssets cannot use emptyReason. Generated image assets continue to live as canvas image nodes associated with the owning webHero; the structured field summarizes decisions, it does not replace the asset nodes. The canvas renders the "网页资产规划" panel automatically from this field; do not call any board-creation tool.

WebHero Target Rules

• Use canvas_create_webhero_node once per website workflow when no target exists.
• Before creating a WebHero target, choose one stable explicit target identity, such as webhero_<slug>_<shortid>, using the current tool schema. Do not rely on validation errors to discover missing identity.
• Keep the target id stable and attach preview/assets metadata to that target when useful.
• Do not create a "final webpage" text node.
• Do not store HTML/CSS/JS in content or prompt.
• If internal generation produced html, css, and documentHtml, stage only html/css (or webHeroHtml/webHeroCss) through the WebHero code tools. Treat the internal document as a local verification artifact; the server derives canonical webHeroDocumentHtml. Do not write any final-code field with canvas_update_node_data or public flow patches.

Embedded vs Reference-Only Assets

Each image_asset slot must declare whether its resolved URL is meant to be embedded in the final HTML/CSS or used only as a visual reference for procedurally-rendered code. The final-code gate enforces URL embedding by default, so reference-only intent must be explicit.

• Embedded (default). The resolved external URL or canonical {{asset:<sourceNodeId>}} token must appear in staged HTML/CSS as <img src=...>, background-image: url(...), or an asset-constant string. Commit materializes canonical tokens to their owned canvas node URLs. Use this for hero photography, product renders, lifestyle visuals, portraits, and any media that the page is supposed to display.
• Reference-only. The resolved asset is a visual guide that informs CSS/HTML procedural rendering for abstract layout or decoration (card grids, dashboard/workflow boards, checklist layouts, decorative line work, typography, ambient glow). The URL is not embedded in final code. Product, device, hardware, camera, hinge, screen, lifestyle, portrait, and scene subjects are not eligible for reference-only treatment. Mark a valid abstract slot reference-only by setting either webPageAssetCodeRole: "reference" (also accepts "evidence"/"inspiration") or by writing an intendedWebUsage string that contains a reference verb plus a code term, e.g. "visual evidence for final CSS card grid", "reference for procedural dashboard", "inspiration for HTML workflow board". Do not inject fake <img> tags purely to satisfy the gate — declare the reference-only intent only when the subject is genuinely abstract/procedural.

When a slot is reference-only the gate skips both the URL-embedding requirement for that assetId and the procedural-narrative-image rejection. Embedded slots and slots without explicit reference intent continue to require URL embedding.

Error-Avoidance Rules

• Webpage preview screenshots must not be 4:3 and must not use portrait canvas dimensions. The direct image tool auto-groups preview nodes into the owning 网页预览可视化图 group when the current schema-supported preview identity is present; do not leave previews ungrouped or create a competing preview group manually.
• Before preview approval, do not call canvas_evaluate_node; it is a post-approval QA/evaluation tool. Use only prompt/metadata/visible result inspection before asking the user to confirm.
• For webpage assets, every generated asset image node must preserve asset identity and owning webHero identity using fields currently supported by the tool schema. The direct image tool will create or reuse the owning webHero's 网页素材资产 group and connect the asset to the webHero; do not create a second competing asset group.
• Searched assets, icon decisions, generated asset summaries, and font planning must be persisted as structured webPageAssetDecisions on the target webHero node; do not leave this evidence only in JSON fields buried elsewhere or in retrieval records.
• For long final code fields, build final webHeroHtml and webHeroCss, freeze both fields' chunks and total before the first stage call, keep one sessionId, copy the latest readiness flowUpdatedAt and previewNodeIds unchanged into every chunk, and commit only after both fields are complete. Do not stage document HTML; the server derives it from the exact staged HTML/CSS.
• When staging long code, prefer the raw-chunk tool. If using the base64 tool, pass exactly one of chunk or chunkBase64; sending both is a hard webhero_code_invalid_args error.
• Final CSS must include a mobile overflow guard: html, body { max-width: 100%; overflow-x: hidden; }, media containers should use max-width: 100%, and mobile @media rules must set grid/flex-heavy contact/footer/header/navigation areas to width: 100%; min-width: 0; max-width: 100%; overflow-wrap: anywhere; with wrapped links. Do not rely on width: min(100% - Npx, ...) alone for nested full-width dark sections.

Final Fidelity Rules

• Treat preview screenshots as primary layout evidence, not decorative inspiration.
• Each preview screenshot should correspond to one final page section in order.
• Preserve section-level typography scale, spacing, density, media placement, and visual hierarchy.
• If CSS or JS references #some-section, the final DOM must include an element with id="some-section".
• If the final page omits a preview section, keep working in the same execution chain instead of declaring completion.
• Before declaring final code complete, mentally check desktop and mobile render constraints: no horizontal overflow at 390px width, no overlapping text/buttons, no unwrapped email/footer/nav lines, and no decorative layer covering readable content.

Anti-Patterns

• Do not skip preview confirmation unless the thread already contains explicit approval.
• Do not finish while preview or asset nodes are still queued/running.
• Do not use preview screenshots as the final webpage media layer when the page needs HTML/CSS structure.
• Do not claim a website is complete when only preview screenshots or assets exist.
• Do not write final code without first reading the approved preview screenshots as multimodal context.