4.8 KiB
PowerPoint application evidence
Use the host's supported application UI tool, such as CUA, for PowerPoint operations. Initialize it with the documented app/browser entrypoint, read the returned documentation, and operate only through supported APIs. After a resumed computer-use summary, reload that tool's documentation before acting. Do not substitute shell scripting or hidden application automation for UI evidence.
Open the current generated file, verify the visible filename and page thumbnails, and inspect whether PowerPoint shows a repair/recovery warning. Work on task-owned copies and preserve the user's unrelated open presentations. Do not dismiss a repair prompt as successful opening; retain the diagnostic and repair the authored source.
Use the current output of the mandatory project build. Production corrections must be represented in project sources and rebuilt; edits made only in an application test copy do not become the deliverable. When the page follows an approved sample, compare it with that reference and its element inventory, preserving the accepted content and relationship-bearing shapes during repairs.
For rendered evidence, export this file to PDF through PowerPoint's own export dialog using the intended quality setting and a task-owned destination. Check the export exists and belongs to the current file, render its pages and inspect the images. Compare page geometry, text wrapping, typography, images, transparent edges, alignment and separators. Confirm actual PDF font identities when font rendering is disputed; a declared PowerPoint face alone does not prove which font the application rendered.
Use the text/container review: paragraph frame or justified logical-block fallback, no substantive statements in small muted notes, visible size/weight/color hierarchy within containers, one shared internal layout implementation per type/variant, compliant punctuation/singleton handling on every paragraph line, exact active shared spacing and visible fixed paragraph gaps. The active recipe may contain C27's declared project-owned content-area adjustments for an approved mockup; reject caller spacing overrides. Check actual glyphs/edges and visual rows, not only boxes, authored breaks or XML paragraphs. Review content/source and native objects as well as the render. A screenshot cannot prove a shared renderer or unified text source; grouping cannot prove native paragraph flow. Test fragment reflow in the application only when that editing behavior is part of the requested evidence.
For equations, inspect mc:Choice/a14:m and OMML structures separately from compatibility fallback text. Verify the declared math family on runs and operator/control properties, missing glyphs, fraction/radical/script/limit placement and clearance from adjacent prose. Actual equation editing requires selecting and changing the equation in a disposable copy; XML or a correctly shaped picture cannot establish that evidence. See math checks.
Every completed page also requires the full-page hierarchy check: sizes, families, weights, spacing and visual grouping across the whole rendered page. Component checks, a successful export or absence of overlap do not replace it. Repair issues and inspect the updated render; report application/projection evidence at its actual level.
After each approved-mockup font-size or geometry adjustment, complete both container and page overflow checks. Inspect actual text/formula layout and complete visible edges: content must fit its text frame/container, and the full composition must fit the usable page/canvas without unintended clipping, occlusion or fixed-UI collisions. Repair source, rebuild and inspect the current output; container boxes inside the canvas alone are insufficient. Preserve only explicitly intended template crops/contacts under their existing rules.
Opening and exporting are distinct from actual editing. When editing evidence is requested, use a disposable task-owned copy: select a representative text/shape/placeholder, change it through the UI, save or export, and verify the resulting independent object/content change. Check an appropriate inherited object separately if template behavior is in scope. Do not alter the authoritative source project or a user's finished original merely to demonstrate editing.
Report the evidence actually obtained: source/reference validation, native structure and object types, current-page rendering, PowerPoint opening, actual object editing, or projection readability. A successful export cannot establish every later level. If the host application or UI capability is unavailable, deliver the validated source and PPTX with that specific unresolved application check.