6.0 KiB
Page mockups and visual materials
Reuse the user's settled template, theme, route and page workflow. Receive the current page's title/message, evidence, content groups and notes through content handoff, then define its layout, asset roles and required native objects before generating its mockup. Establish a minimal page brief if none is supplied. Review only consequential decisions that remain open; do not restart settled outline or style choices. A request to review one page does not authorize a full-deck generation run.
When extracting style from an existing presentation or PDF, render representative pages and inspect the actual images. XML/object counts alone cannot establish density, hierarchy, ornament or spacing. Keep style references separate from strict source assets. Use existing accepted references; a rejected mockup does not remain a design baseline.
Page composition and HTML boundary
Choose text, figures, diagrams and their arrangement from the current information relationship. Pure text can serve a short question, quotation or conclusion; a picture or icon needs a useful role. Do not mechanically reuse website hero sections, selling cards or dashboards as report layouts. The page's main meaning must be readable without scrolling, hovering or clicking.
Make conclusions and their supporting evidence visibly correspond through proximity, a shared heading, matching labels, annotations, highlighting or a necessary connector. Use only connections that express real relationships. Preserve exact premises and key reasoning/derivation steps where the audience needs them; check progression and information burden in the actual composition. Internal item counts, maintenance IDs and authoring decisions stay in process material unless the audience needs them for the report itself.
Do not use HTML/DOM/CSS to lay out report pages, including layouts later captured as screenshots, printed or converted to another format. HTML may contain a JavaScript visualization itself and its necessary runtime container. This exception does not cover surrounding titles, prose, columns or page UI; produce those through the permitted native/SVG route. A direct SVG diagram is allowed. Keep the selected route's editability claims accurate for any visualization asset.
Mockup prompt inputs
Use the host image-generation tool directly for requested raster page samples. Supply:
- The selected canvas/aspect ratio, template palette, typography intent, grid and fixed content regions.
- The exact current-page text and moderate content density, with a declared hierarchy and clear content division.
- The intended page progression, necessary premises or key steps, and the association between conclusions and evidence.
- Approved representative images as style references, with the current layout allowed to differ.
- Supplied logos, figures and screenshots as strict identity/evidence assets. Preserve values, axes, labels, proportions and scientific meaning; do not synthesize substitute evidence.
- The editable reconstruction plan: decorative pictures may remain assets, while title/body, controls, separators and diagrams must later become independent native objects as required.
Inspect local reference images using the available image-viewing tool before editing or conditioning on them. Label each input's role in the prompt. Save prompt, tool result, source attribution and review status under the project. Show the current sample for the user's requested review and incorporate concrete corrections before native reconstruction.
Use generated text only as visual guidance. Native source text comes from verified content, with the template's declared fonts and sizes; do not copy misspellings or typography defects from the raster sample. Preserve original evidence/identity assets independently so the final native page can use those files exactly.
Native paragraph lines must satisfy punctuation and singleton rules. Do not preserve a mockup's forbidden line-head/tail punctuation or a row containing only one character with optional punctuation; reflow the complete paragraph within the declared layout.
Material generation and transparent assets
For new bitmap illustrations, photos, textures or image edits, use the selected host image-generation capability. Request a transparent background when the final asset needs transparency. Preserve transparency on edits unless the user asks to change it. Use reference-image paths when all targets have paths, otherwise the smallest supported recent-image set that includes every target; do not silently omit a required target.
Ask for complete separated objects with consistent perspective, stroke and illumination. A material sheet can contain several non-overlapping assets with clear outer padding, but verify identity/count and edges after separation. Keep logos and strict evidence originals; generated approximations need explicit permission for that role. Repair small occlusions locally rather than redesigning an entire source background.
Check transparent edges against both light and dark backgrounds for halos, missing thin strokes and unintended holes. Avoid arbitrary color-key removal that erases matching subject colors. If an approved layered source or role mask exists, retain it with a clear mask-to-material contract; otherwise regenerate an unsuitable cutout through the image tool.
For an existing SVG icon system, use its vector source and declared paint contract rather than generating a new bitmap. Multiple independent color roles need stable element IDs and per-channel rules. Palette binding, fixed details, structural none and unlisted paint remain distinct. See icon handoff.
For all new icon sources use icon production: reuse, simple authored vectors, complex generated materials, then external supplements. Every route finishes with compliant adjustable parts; raw generated or downloaded rasters are production inputs. Apply the source and evidence requirements in production rules.