admin/Templated-PPT-Master
1
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Require buildable projects, mockup fidelity and page hierarchy (0.9.3)

Browse Source
This commit is contained in:
Commilitia
2026-10-31 19:37:26 +08:00
parent e858fa130d
commit 25be7ebb86
10 changed files with 91 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files
references/visual-design.md
+26
View File
@@ -14,6 +14,16 @@ Record confirmed feedback in existing project/page notes or review material: the
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.
## Approved-mockup fidelity
An approved current-page mockup becomes the reconstruction reference. Rebuild it as faithfully as possible: preserve the accepted content, figure/image identities, graphics, relative arrangement, proportions, grouping, emphasis and relationships within the selected template's contracts. The draft's roughness permits necessary quality repair; it does not make its accepted elements optional.
Before reconstruction, inventory the accepted text and visual elements in existing page source/notes, including diagram nodes, links, arrows, braces, enclosures, legend items and labels. A shape that conveys grouping, containment, comparison, direction or a dependency is content. Do not drop it, replace it with an unrelated symbol or call it disposable decoration because native reconstruction is inconvenient. Preserve other accepted graphics too; an allowed picture exception must retain the element and disclose its object type.
Repair typography defects, verified-text spelling, wrapping, contrast, alignment, spacing, clipping and collisions as needed. Keep substantive text, values, groups and relationship meanings intact; do not solve a quality problem by removing an accepted paragraph, figure, graph element or connection. Use the declared template fonts, discrete sizes and shared geometry rather than tracing raster artifacts. If preserving the accepted content would require a substantive redesign or omission, present that specific change for the user's decision; ordinary quality repairs need no repeated approval.
Compare the new full-page render with the approved sample and its inventory. Check for missing elements, changed endpoints, lost group boundaries and altered emphasis as well as appearance. Keep the accepted reference and relevant repairs in the project; do not replace the baseline with a later simplified draft without user instruction. Follow the agreed review assignment without creating a new review pipeline.
## Page composition and HTML boundary
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.
@@ -39,6 +49,22 @@ Use generated text only as visual guidance. Native source text comes from verifi
Native paragraph lines must satisfy [punctuation and singleton rules](text-and-containers.md#paragraph-line-breaking-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.
## Full-page hierarchy check
After completing each page, inspect its actual current render as a whole at a fitted full-page view and normal presentation scale. This check is required even for a single page or an authorized batch, and for both original authoring and mockup reconstruction. Inspect all visible text roles, including labels, chart text, captions, navigation and mathematical text, and the relationships between content containers.
| Dimension | Check across the whole page |
|---|---|
| Font size | Main title/message, section headings, body and supporting details are distinguishable and readable; no essential explanation is demoted to tiny text. Use the declared role sizes. |
| Font family | Each role uses its declared family, including math/monospace where relevant; substitutions and inconsistent families do not disrupt the hierarchy. |
| Font weight | Declared title/heading/body weights are realized correctly; emphasis helps the reader distinguish roles without inventing undeclared bold styles. |
| Spacing | Line spacing, paragraph gaps, internal padding and distances between groups follow the shared recipe and visibly separate their intended levels. Check actual glyph/edge clearance. |
| Visual content groups | Proximity, alignment, containers, headings and meaningful connectors group related material and separate different groups, including across columns and boxes. The groups match the accepted content relationships. |
Judge their combined effect: can the reader identify the main message, then the sections, explanations and supporting details in the intended order? Merely assigning several font sizes, passing a bounding-box check or avoiding overlap is not a pass. Uniform styling or equal gaps can flatten the page even when every object is individually legible.
Repair the source and shared recipes as needed, preserve the approved elements, rebuild and inspect the new render before calling the page complete. Recheck affected pages when a shared recipe changes. Record meaningful findings/repairs briefly in existing page notes or review material; no new scoring schema or specialist review is required. Application editing and projection evidence remain separate under [PowerPoint checks](powerpoint-checks.md).
## 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.