mirror of
https://github.com/pbakaus/impeccable.git
synced 2026-09-17 08:36:25 +03:00
One prompt carrier across every harness: embed-prompt.mjs
The prompt behind a generated image was recorded three different ways, a sidecar in the eval harness, nothing in the skill's API tool, nothing for native tools, so intent survived or vanished depending on where you ran. One dependency-free script now embeds the prompt inside the image itself, PNG tEXt or JPEG COM with a sidecar fallback for other formats, idempotent, and reads it back from any impeccable-generated file. The API tool embeds automatically; the prose directs every native-tool generation through it; copies between machines and harnesses keep their intent. Comps meanwhile are declared the build thread's own work, never delegated, and the comp-skeleton guidance now asks for the surface's actual regions instead of prescribing navs onto pages that have none. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Fable 5
parent
abe722d105
commit
47b875a7e3
@@ -6,9 +6,9 @@ The purpose of a probe is to test composition, narrative, hierarchy, density, fo
|
||||
|
||||
## Generate three compositional options
|
||||
|
||||
Render three distinct high-fidelity north-star comps of the requested surface, with whatever generation capability exists, saved under `.impeccable/mocks/` so they survive the session; record the approved comp's path in the surface brief. Open every image you produce or reference by its workspace-relative path, never an absolute one: sandboxed viewers reject absolute paths, and everything under the project root has a relative path. Base them on the real content and the surface concepts already developed with the user. Three is the number: one comp invites rubber-stamping, and the spread between three is what surfaces the composition worth building. A decision-page sketch is not a probe: it chose the direction at deliberately unfinished fidelity, so the three comps render regardless, and the chosen card's sketch seeds at most one of them.
|
||||
Render three distinct high-fidelity north-star comps of the requested surface, with whatever generation capability exists, saved under `.impeccable/mocks/` so they survive the session; record the approved comp's path in the surface brief. Comps are the build thread's own work, never delegated: the thread that writes the comp prompts holds the direction's full context, and it has already seen every comp when the build starts. Open every image you produce or reference by its workspace-relative path, never an absolute one: sandboxed viewers reject absolute paths, and everything under the project root has a relative path. Base them on the real content and the surface concepts already developed with the user. Three is the number: one comp invites rubber-stamping, and the spread between three is what surfaces the composition worth building. A decision-page sketch is not a probe: it chose the direction at deliberately unfinished fidelity, so the three comps render regardless, and the chosen card's sketch seeds at most one of them.
|
||||
|
||||
- A comp is a designed page, not a picture of the subject. State the page's literal skeleton in the generation prompt, navigation bar and its items, headline block and its scale, each section in order, the footer, because a prompt that leads with the world's atmosphere gets a vignette back: the model paints the fish market instead of the fish market's website. Self-check every render: if it could hang as a poster, or reads as a photograph or scene with some text on it, it is not a comp; regenerate with the layout scaffold stated more literally.
|
||||
- A comp is a designed surface, not a picture of the subject. Lead the generation prompt with the surface's own structure, whatever regions this design actually has, named in order with their scale relationships; a page with no navigation states that instead of inventing one, and an unconventional surface states its unconventional skeleton. A prompt that leads with the world's atmosphere gets a vignette back: the model paints the fish market instead of the fish market's website. Self-check every render: if it could hang as a poster, or reads as a photograph or scene with some text on it, it is not a comp; regenerate with the layout scaffold stated more literally.
|
||||
- When the user shortlisted multiple concepts, spread the three across them.
|
||||
- When one direction is committed, vary the structural uncertainty an image can resolve: topology, sequence, density, hierarchy, focal composition, or interaction framing.
|
||||
- Show enough beyond the opening moment to prove the concept can govern the whole requested surface.
|
||||
@@ -34,7 +34,7 @@ Treat the comp as a north star, not something to trace, and know what that allow
|
||||
|
||||
## Produce only the assets the build needs
|
||||
|
||||
Generation context is part of the asset: the thread that wrote a prompt knows what the image contains, why, and how it is meant to sit in the layout, and a build composed by a thread without that knowledge places assets it does not understand. So prefer generating build-critical imagery in the build thread when the budget allows, and when a subagent produces assets instead, every asset must carry its prompt (the generation sidecar or the manifest's prompt_used), and the builder reads those prompts before composing a single one of them.
|
||||
Generation context is part of the asset: the thread that wrote a prompt knows what the image contains, why, and how it is meant to sit in the layout, and a build composed by a thread without that knowledge places assets it does not understand. So prefer generating build-critical imagery in the build thread when the budget allows, and when a subagent produces assets instead, every asset must carry its prompt, and the builder reads those prompts before composing a single one of them. The carrier is uniform across harnesses: after generating any image with any tool, native or `generate-image.mjs` (which does it automatically), run `node {{scripts_path}}/embed-prompt.mjs <image> --prompt "<the prompt used>"` so the intent lives inside the file itself and survives copies between machines and harnesses; `--read` recovers it from any impeccable-generated image.
|
||||
|
||||
When clean raster ingredients are required and the harness runs subagents, use the shipped asset producer, `impeccable-asset-producer` (`impeccable_asset_producer` in codex): give it the approved comp, output paths, required dimensions and formats, transparency needs, crop notes, and what must remain semantic code. Otherwise produce the minimum required assets in the current thread by the book: load [degraded/asset-producer.md](degraded/asset-producer.md) and follow it inline, with whatever generation exists, the native tool or generate-image.mjs.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user