Integrate confirmed report workflow and review inputs (0.9.0)
This commit is contained in:
@@ -1,12 +1,22 @@
|
||||
# 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](content-handoff.md), 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.
|
||||
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](content-handoff.md), then define its layout, asset roles and required native objects before generating its mockup. Establish a minimal page brief if none is supplied. Follow the confirmed [execution choices](execution-and-review.md), including ImageGen scope/budget and selected alternatives. Review only consequential decisions that remain open; do not restart settled outline, style or tool 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.
|
||||
|
||||
## Rough layouts and confirmed preferences
|
||||
|
||||
For page-by-page work with ImageGen enabled, use an actual visual or actual render from the selected template and theme as the reference. Inspect it before generation. Make a rough layout with the main content elements approximately in their intended regions, retaining the fixed page UI as a reference; focus on grouping, hierarchy, reading order and the contribution-to-evidence relationship. Do not spend the layout-draft budget on fine detail or claim pixel correspondence with the final PPT.
|
||||
|
||||
Let the user review the current layout at the agreed granularity, incorporate feedback, then implement the authorized page. Later authorized pages reuse the confirmed ImageGen choice and budget; seeing each new layout is page review, not a repeated permission question. If ImageGen is declined or unavailable, use only the user's selected alternative or resolve that pending choice before dependent work. Do not silently switch to another generator, Agent arrangement or text-only plan.
|
||||
|
||||
Record confirmed feedback in existing project/page notes or review material: the preference, user confirmation, applicable page/report scope and reference image/source revision. Reuse it within that scope on subsequent authorized pages. A local change does not become a global rule; an ongoing preference needs explicit support. Do not create another preference database or write global memory. Keep rejected drafts distinguishable from accepted references.
|
||||
|
||||
The template/shared recipe owns final geometry, typography, fixed spacing and UI. Rough positions in the draft cannot override those contracts. Rebuild the actual page with supported native objects and check its reading order, capacity and visual evidence associations. Draft feedback does not establish final native rendering, editing or projection acceptance. Follow [review after revision](execution-and-review.md#review-after-revision) for the agreed independent check of substantive changes.
|
||||
|
||||
## 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.
|
||||
Every title, text, formula, label, visualization and meaningful decorative group must serve the page task and, through it, the section and report goals. Choose 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.
|
||||
|
||||
@@ -14,7 +24,7 @@ Do not use HTML/DOM/CSS to lay out report pages, including layouts later capture
|
||||
|
||||
## Mockup prompt inputs
|
||||
|
||||
Use the host image-generation tool directly for requested raster page samples. Supply:
|
||||
For a requested raster page sample within the confirmed ImageGen scope, use the host image-generation tool directly. 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.
|
||||
|
||||
Reference in New Issue
Block a user