mirror of
https://github.com/pbakaus/impeccable.git
synced 2026-09-20 18:16:30 +03:00
Harden the comp-to-build translation after the hamster-wheel failure
A codex greenfield build produced an excellent approved comp and then an abysmal page, and the reviewer approved it. The failure chain: the implementation inventory downgraded a photographic hero to 'silhouette in SVG' and sculpted panels to 'material finish: CSS'; the builder read 'no photography on hand' as a license to avoid photographic rendering; QA looked at one full-page thumbnail; the reviewer was spawned with the builder's forked history and then scored fix claims instead of pixels; and the output contract had no way to say 'rejected'. The fixes, stage by stage: - The inventory's medium column gets a gate: a human figure, product object, machinery, or lit material is raster whatever the stack, and such regions are regenerated cleanly at asset resolution with the comp and its embedded prompt as reference. Never cropped from the comp, whose effective resolution is reference grade; the asset producer's direct bucket closes the same hole. Dropping an image-native region is a user decision at the approval point. - Generated imagery is a material, not a claim: evidence rules bind assertions, never render fidelity. - The build thread's inspection becomes a region-by-region side-by-side against the comp at legible scale, never one full-page thumbnail. - The reviewer spawns fresh, never with forked history (fork_turns: 0 in codex), and gains a rejection lane: when TYPE, MATERIAL, and the focal element are all contradicted, the first material fix is a rebuild directive the parent surfaces to the user instead of patching. Verdict passes score recaptures only; the parent's fix narration is not evidence. - The verdict-loop ceiling softens: two rounds ends an unattended run, but an attended session puts the open-items table in front of the user and lets them fund another round; any round that resolves nothing stops the loop. - Comp approval joins the roll as skip-proof: question-tool errors fall back to the decision page, delegation is recorded in the brief and the sidecar and disclosed up front, and the reviewer treats comps with no recorded pick as a material finding. - Craft floor: system display faces (Impact, Arial Black) as an own-world display voice and unicode glyphs standing in for icon systems are named failures. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Fable 5
parent
bb07a7519b
commit
4432b92bbb
@@ -22,11 +22,13 @@ Show the three together: in the harness when it can display images, otherwise on
|
||||
|
||||
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 still recorded in the surface brief and the chosen comp's sidecar and disclosed in your first reply, not your last. The finish reviewer treats a build with generated comps and no recorded approval as carrying a material finding.
|
||||
|
||||
After approval, record the choice where tools can find it: the approved comp's path goes in the surface brief, and the approved comp's `.json` prompt sidecar gains `"approved": true` (every comp generated through `generate-image.mjs` 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. Then 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 surface concept, and build.
|
||||
|
||||
## Inventory implementation fidelity
|
||||
|
||||
Before building, inventory the approved comp's major visible ingredients in writing (a short table in the surface brief or working notes; the finish reviewer audits shipped assets against it) and choose an implementation medium for each: semantic HTML/CSS/SVG, existing project asset, generated raster, sourced raster, icon library, canvas/WebGL, or accepted omission. The same written inventory names the comp's compositional commitments: navigation items and icons, headline levels and their scale relationship, signature geometry such as seams, masks, and overlaps, and each section's arrangement and density. An element never written down is the element the build silently drops, and the direction contract's 150 words cannot carry this list, so this inventory is where it lives. Textures, portraits, and scenes are raster-by-default; a CSS gradient is not a texture medium. The affinity runs both ways: precise geometry, hard-edged shape systems, diagrams, expressive motion, shaders, and anything interactive are vector and GPU territory, SVG, canvas, WebGL, where reaching for a raster flattens what should move, scale, and respond. Raster is for what the world paints; code is for what the world draws, animates, or reacts with, and choosing code there is ambition, not economy. Every `produce` entry is produced before the build ships, through the asset producer or in the current thread; an inventory with unproduced entries is an unfinished build, and this gate is where imagery-free pages come from when it is skipped.
|
||||
Before building, inventory the approved comp's major visible ingredients in writing (a short table in the surface brief or working notes; the finish reviewer audits shipped assets against it) and choose an implementation medium for each: semantic HTML/CSS/SVG, existing project asset, generated raster, sourced raster, icon library, canvas/WebGL, or accepted omission. The same written inventory names the comp's compositional commitments: navigation items and icons, headline levels and their scale relationship, signature geometry such as seams, masks, and overlaps, and each section's arrangement and density. An element never written down is the element the build silently drops, and the direction contract's 150 words cannot carry this list, so this inventory is where it lives. The medium column is where an approved design most often dies, so it obeys a gate: the medium is decided by what the comp region shows, never by what feels buildable in the current stack. A human figure, a product object, machinery, or any material with lighting and depth is raster whatever the stack; writing "silhouette" for a photographic figure, or "CSS" for a sculpted panel's finish, is not a medium choice, it is the quiet deletion of the approved design, and it is how a comp full of physical material becomes a flat page with the same section order. Produce such regions by regenerating them cleanly, with the approved comp and its embedded prompt as the reference for a fresh render at asset resolution; never crop pixels out of the comp itself, whose effective resolution sits far below asset grade. Dropping an image-native region instead of producing it 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, so "no photography on hand" forbids fake proof, not an illustrated hero. The affinity still runs both ways: precise geometry, hard-edged shape systems, diagrams, expressive motion, shaders, and anything interactive are vector and GPU territory, SVG, canvas, WebGL, where reaching for a raster flattens what should move, scale, and respond, and code executed safely and professionally remains first-class there. Raster is for what the world paints; code is for what the world draws, animates, or reacts with, and choosing code there is ambition, not economy. Every `produce` entry is produced before the build ships, through the asset producer or in the current thread; an inventory with unproduced entries is an unfinished build, and this gate is where imagery-free pages come from when it is skipped.
|
||||
|
||||
Pay special attention to the dominant composition, signature use, image-native content, second-fold system, and any interaction the still image only implies. If the concept depends on a photograph, architectural scene, product object, portrait, or other raster-native material, do not silently replace it with generic CSS scenery.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user