40 lines
8.1 KiB
Markdown
40 lines
8.1 KiB
Markdown
# Production rules
|
||
|
||
These rules apply across templates and authoring routes. **Required** rules protect content, provenance, implementation claims, rebuildable inputs and the explicit text/container constraints below. **Recommended** methods can change for a content reason; record the reason and relevant validation. Template parameters remain external. Follow explicit user instructions and settled authorization; these rules add no approval gate. C16–C19 are requirements, including where C04–C06 offer broader design recommendations.
|
||
|
||
## Understand and compose
|
||
|
||
- **C01 · Recommended:** form a brief from the audience, purpose, setting, supplied material, content boundary, output route, length/time, template and review rhythm. Reuse known answers. Ask only for consequential information that cannot reasonably be inferred; do not turn the brief into a questionnaire.
|
||
- **C02 · Required:** preserve facts, numbers, conditions, causal relationships and strength of conclusions. Distinguish source statements, inference and added material. Do not invent unknown values. Identify synthetic examples and retain traceable sources for material claims.
|
||
- **C03 · Recommended:** establish the presentation's main judgment and progression before filling pages. Give each page a purpose and reading order, with as many supporting points as the content needs. Summarize without changing meaning.
|
||
- **C04 · Recommended:** keep hierarchy, color semantics, terminology, units, legends, strokes, icon grammar and component scale consistent across pages. Use declared template exceptions where needed.
|
||
- **C05 · Recommended:** choose layout and columns from content relationships, then place components. Maintain grouping, alignment, spacing, reading order and moderate density. Add decoration for a purpose. Resolve excess content through the template's rewrite/layout/split policy; keep its declared typography and grid rules.
|
||
- **C06 · Recommended:** inspect suitable components and page-library examples before authoring. Read their rationale and method; adapt, combine or create as needed. Remove example content, update data and metadata, and preserve reference attribution.
|
||
|
||
## Materials and information graphics
|
||
|
||
- **C07 · Recommended priority, required paint contract:** reuse suitable template icons; draw new simple icons as SVG/native shapes; use ImageGen for complex icon imagery; use external ready icons as a supplement. Every route must finish with the selected icon production contract: stable semantic parts, permitted whole/partial palette binding, fixed details and transparent structure. Generated or external source material is not exempt. See [icon production](icon-production.md).
|
||
- **C08 · Required truthfulness, recommended selection:** choose photos, evidence figures, illustrations and decoration by their information role. Use supplied/trustworthy originals for exact identity and real evidence. Identify generated material; do not present it as official marks, real scenes or experimental results. Keep originals, derivative/generation provenance and needed production inputs. Preserve proportions and critical evidence when cropping.
|
||
- **C09 · Required data fidelity, recommended expression:** retain data, units, definitions, time range, missing-value policy and sources. Select comparison, trend, distribution, composition or relationship views accordingly. Keep related comparisons semantically and numerically comparable; normally avoid misleading truncation, meaningless dual axes and 3D ornament. Sources may live in notes/metadata; do not introduce a forbidden footer. See [charts](charts.md) and [components](components.md).
|
||
- **C10 · Required semantics, recommended implementation:** nodes, links, arrows, groups and legends represent actual relationships. Distinguish data flow, control flow, dependency and time sequence. Do not turn unordered peers into a causal chain. Prefer native objects/SVG for technical diagrams; preserve code symbols, indentation and necessary context. State the actual formula object type.
|
||
|
||
## Implement and retain
|
||
|
||
- **C11 · Required:** implement text, shapes, connectors, tables and charts according to the selected route. Do not claim a full-page screenshot is editable completion. Use supported tools and disclose technical limits; do not silently change backend, depend on another installed Skill or introduce an online provider. [Native objects](native-objects.md) describes actual object support.
|
||
- **C12 · Required:** retain source data, page content/code, notes, assets, generation parameters, template version, environment and necessary metadata. When content changes, synchronize chart cache/workbook, SVG fallback and current previews. Use relocatable project paths. A cached export or final PPTX alone is not a rebuildable project. See [project workspace](project-workspace.md).
|
||
- **C13 · Recommended:** complete content, visual and implementation checks at the authorized review granularity. Even an authorized batch needs page checks. Multiple authors share a frozen brief/style; the coordinator checks cross-page story, terminology and appearance. Existing page-by-page authorization remains binding. See [page collaboration](page-collaboration.md).
|
||
|
||
## Verify, revise and deliver
|
||
|
||
- **C14 · Required:** before delivery, check missing pages, example residue, text overflow, occlusion, font substitution, chart data, asset resolution, alignment and object types as relevant to the change. Inspect actual current page renders. If a needed host check is unavailable, state it as unverified; old previews cannot replace new render evidence. Reuse unchanged evidence instead of repeating unrelated checks. See [PowerPoint checks](powerpoint-checks.md).
|
||
- **C15 · Recommended:** identify affected pages after shared-input changes and rebuild/recheck them. Retain recoverable sources and accepted versions. Report versions, selected theme, object exceptions, evidence and remaining issues. Record content reasons and validation for departures from recommendations. Version new components/library entries independently; preserve frozen releases.
|
||
|
||
## Text and containers
|
||
|
||
- **C16 · Required:** keep a paragraph as one logical text block, preferably one native text frame with wrapping, line breaks and styled runs. If a technical constraint requires several native frames, use one complete content source, one overall frame, one reading order and one layout implementation to generate and update all fragments together. Independent line strings/positions, or merely grouping manually positioned frames, do not satisfy this rule.
|
||
- **C17 · Required:** small muted notes may supply nonessential background, sources or definitions. They must not carry substantive explanations of a chart/visualization, key process conditions or timing, conclusions, or qualifications/disclaimers that affect interpretation. Put those statements in the main information hierarchy; do not hide them in notes or metadata instead. Classify by meaning, not by a field named `detail`, `caption` or `source`.
|
||
- **C18 · Required:** different text functions inside one container, such as subheading and body, must have a perceptible distinction in declared size, weight and/or palette color. A font-family change alone is insufficient. Bind functions to named text roles and apply the same distinction to all instances.
|
||
- **C19 · Required:** every instance of a container type/variant uses the same shared layout implementation for padding, slots, text roles, wrapping, icon placement and alignment. Authors provide content and whole-container placement/bounds; the implementation computes internal geometry. Do not hand-position/nudge text or icons per instance. Resolve capacity through the shared layout's content-driven rules, a meaningful shared variant, rewriting or page/layout changes, never a one-off override. See [implementation and review](text-and-containers.md).
|
||
|
||
Technical helpers enforce supported inputs, path safety, object consistency and capacity. They do not infer paragraph identity, explanation importance or semantic text roles, and do not automatically enforce all four text/container rules. Inspect source and current native/rendered output; export success alone is insufficient.
|