Subchapter 2.40
reference/visualize.mdMarkdown11 KBView on GitHub
Load this from new-work.md on a comp-led build, when image generation is available (a harness-native tool or the API fallback impeccable context reports). A code-led contract skips this file by design, not by drift; do not load it then. PRODUCT.md and DESIGN.md are preconditions. New-work has already resolved the visual world; this file must not reopen it. A surface-scope structure round that already put three visualized cards before the user (new-work.md, established world) has discharged this round: the locked card’s comp is the approved comp, so record the approval and continue at After approval; generate nothing new.
A probe tests composition, narrative, hierarchy, density, focal moment, signature use, and image requirements. It is not a second identity workshop. Keep DESIGN.md’s palette, typography direction, material language, component character, imagery stance, and motion grammar fixed.
The comp round runs inside the build’s phase state: impeccable build-phase start --direction <seed key> --kind <...> has already run (the roll’s output names the command) and its comps phase is open before the first comp is generated; a comp rendered before that sits outside the state, and a session resumed from that point has no phases to follow. impeccable generate-image refuses to write under .impeccable/mocks/ until start has run; a harness-native image tool is bound by the same order.
Render three distinct high-fidelity north-star comps of the requested surface, saved under .impeccable/mocks/ so they survive the session. Comp at the surface’s own viewport: portrait at device size for a native app or mobile-first surface, desktop landscape otherwise; a phone screen comped landscape misstates the composition before anything is built against it. Comps are the build thread’s own work, never delegated: the thread that writes the prompts holds the direction’s full context and has seen every comp when the build starts. Open every image by its workspace-relative path; sandboxed viewers reject absolute paths, and everything under the project root has a relative one. Base the comps on real content and the surface concepts already developed with the user. On an established world, anchor every comp on the real identity: capture a screenshot of a representative existing page and pass it as a reference image (the harness image tool’s input image, or impeccable generate-image --ref); the prompt leads with the new surface’s structure while the reference carries palette, type, and component character, because DESIGN.md words alone drift where a pixel reference does not. Name what the reference contributes and what it must not: chrome, palette, type, and component character carry over; the reference page’s own content does not, and a banner, hero, or card lifted verbatim is the reference leaking, not fidelity. Three is the number: one comp invites rubber-stamping; the spread between three surfaces the composition worth building. The chosen card’s decision comp is the first of the three: it already renders this direction at full fidelity under this discipline, so generate two more that vary what the first held fixed, and send all three to the approval point together. Only a round arriving with no decision comp (a degraded roll, an identity-mode page, a direction pinned without the decision round) renders all three here.
Each comp is a direction test, not a screenshot specification. Core UI text, responsive behavior, accessibility, semantics, and interaction states remain implementation responsibilities.
Show the three together on the decision page (impeccable serve-question, one option per comp with the comp as its hero), or in the harness only when it renders images inline; a text-only surface does not count as display. Ask what should carry forward, what feels false to the world, and whether the selected concept should be approved, combined, revised, or rejected. Then stop and wait. A structured simulated user counts as attended and receives the same question.
Do not begin code until the user approves a direction or explicitly delegates the choice. If they delegate, choose using the task brief, PRODUCT.md, and DESIGN.md, and state the evidence. Approval refines the task concept; it does not modify DESIGN.md.
This approval point has no substitute and no skip condition. When the structured question tool errors, fall back to the decision page; only after both fail may you treat the choice as delegated, and a delegated pick is recorded exactly as an approval is and disclosed in your first reply, not your last. The finish reviewer treats comp-round comps with no recorded approval as a material finding; decision comps under .impeccable/mocks/decision/ are the direction round’s hand, not comp-round output, and imply no approval on their own.
After approval, record the choice where tools can find it: the approved comp’s path goes in the surface brief, and its .json prompt sidecar gains "approved": true (every comp generated through impeccable generate-image has one; create it if a native tool didn’t). The sidecar travels with the mocks folder, so the approval survives sessions and machines that never see the brief, and it is what impeccable build-phase advance reads to close the comps phase. Summarize the composition and the parts of the comp that must not be literalized, return to new-work.md, record the direction contract from the approved concept, and build.
The approved comp is a north star for translation into semantic, responsive, accessible code, never a license to recompose: keeping the palette and mood while redrawing the topology is a second art direction. Do not rasterize core UI text or controls. Do not substitute a different visual driver after approval without asking.
What the comp shows is measured, not remembered. new-work.md section 6 runs the build as phases (impeccable build-phase): the spec phase turns the comp into region boxes with sampled palettes (impeccable comp-spec), and the medium of every region follows from what the pixels are, never from what feels buildable: a figure, a product object, machinery, any illustration with perspective, shading, or drawing skill in it, and any texture by name (woven cloth, paper grain, fabric, leather, brushed metal) is a plate / image / texture region and ships as a raster; text, controls, chrome, diagrams with countable elements, flat shape systems, and anything that must move, scale, or respond are semantic. Writing “CSS” for a sculpted panel’s finish, or a many-vertex clip-path for a torn edge, is the quiet deletion of the approved design; the detector’s organic-clip-path and buried-raster rules and the hero gate’s region scores catch it. Dropping an image-native region is a scope decision the user makes at the approval point, never a silent flattening after it. Generated imagery is a material, not a claim: evidence rules bind assertions, specs, testimonials, and photographs presented as real, never render fidelity.
Every raster region’s plate is produced in the plates phase, before any page code, by the shipped asset producer or in the current thread (use impeccable comp-spec --crop <id> and save impeccable comp-spec --plate-prompt <id> to a prompt file; pass the crop and prompt to the harness image tool, or use impeccable generate-image --ref <crop.png> --prompt-file <prompt.txt> --out <plate.png> --size <WxH> --quality high). For isolated cutouts, add --background transparent to both the plate-prompt and API generation commands; use native PNG alpha and preserve white paint and clear gaps. Use --background opaque for full-frame imagery. Create output directories first and inspect alpha on light and dark grounds. Generation context is part of the asset: after generating any image with any tool, run "<skill-base-dir>/scripts/impeccable" embed-prompt <image> --prompt "<prompt>" with the exact string the tool received (impeccable generate-image does this itself), so the intent lives inside the file; --read recovers it, --scan <dir> lists rasters still missing one. The embedded prompt plus the region’s row in the spec is the raster’s provenance, and every raster the artifact references carries it; a sourced, stock, or pre-existing raster embeds its origin instead. A raster created or replaced later, in a fix batch or a reviewer’s rebuild, is produced the same way; a raster a fix abandons is deleted in the same batch.
Convert images with a converter impeccable context reported at boot (the IMAGE_TOOLS line); probe only when it reported none, at most once per session, never per image.
Return to new-work.md for the direction contract, the phased build, and the finishing pass.