@12ui/design 0.2.71 → 0.2.73

package/skills/12ui-design/SKILL.md

@@ -1,98 +1,58 @@
 ---
 name: 12ui-design
-description: "Design interfaces with 12ui, expand an approved screen into pages or app states, convert design images into editable code and assets, and improve existing applications. Use for non-trivial UI creation, image-to-code, and visual redesign."
+description: "Design interfaces with 12ui, expand an approved screen into pages or app states, convert design images into editable code and assets or into a live 3D / Three.js scene, and improve existing applications. Use for non-trivial UI creation, image-to-code, and visual redesign."
 ---
 
 # 12ui Design
 
-If the `12ui` CLI is not present, run `npx -y @12ui/design cli install` once.
+If the `12ui` CLI is not present, run `npx -y @12ui/design cli install` once. Check `12ui workflow --help` for the installed persistent-workflow surface. Use the current coding session's available tools first: 12ui records the operation, its inputs, provider choice and returned artifacts; the session performs the requested design work.
 
-The workflow uses image models and corpus-grounded generation to explore visual hierarchy, composition, typography, and distinct design directions. Expand the selected direction, convert it into editable code and assets, then integrate the requested functionality.
+Read [session.md](session.md) before starting. The durable sequence is **prepare → execute → register → continue**. Prepare freezes a request without inference. Execute selects an eligible provider or returns a session handoff. Perform that handoff with the actual tools available in this session, then register the real result. Continue a successful recipe plan to prepare its dependent operations; execute those explicitly. Keep the workspace and operation ID across interruptions; inspect status before continuing.
 
-Start where you already are: a finished design image goes to §3, an existing interface that should get better to §6, a rough concept to §1, and reference imagery as the deliverable to §5. Each command prints the next, and `12ui <command> --help` prints its flags and choices. The same workflow applies in every supported coding client; the CLI selects and checks the execution engine. Read [outputs.md](outputs.md) only for output boundaries or engine-specific requirements.
+Declare only session capabilities you can actually use. Prefer session execution, then eligible subscription CLI execution, then an explicitly authorized OpenAI API route, then an explicitly authorized 12ui route. Subprocess image capability is not inferred. Codex child execution requires explicit trust in its configured tools and hooks; Claude uses supported safe mode and currently accepts no image attachments for text. Key presence is not permission to spend. Do not fall back or start a new operation after an uncertain dispatch; reconcile the saved operation. Read [outputs.md](outputs.md) for native-format and legacy-engine boundaries.
 
 ## 1. Draft
 
-The draft command uses relevant concepts from the design corpus as starting points for UI candidates. Keep the full design brief in `--concept`; optionally write a separate concise visual caption in `--corpus-query` (or `--corpus-query @file`) for reference retrieval, preserving style details wherever they appear in the brief. Hedge caption generation accepts at most 400 characters after whitespace normalization. Longer queries automatically use balanced retrieval with the complete query and a recorded explanation; a short separate caption keeps hedge retrieval. The CLI owns retrieval, downloads, candidate generation, and resumable identities.
+Use the brief to explore composition, hierarchy, typography, imagery and distinct directions. Retrieve relevant design references when useful; [inspire.md](inspire.md) covers the design DB. Keep the complete brief in the workflow prompt and carry local references as imported artifacts.
 
-    12ui draft --concept "<product, audience, surface, goal, personality>" --corpus-query "<surface, layout, typography, imagery, palette; 400 chars max>" --candidates 4
+Prepare an image operation for each meaningful direction, usually four for an open brief. Execute through the session's native image tool when available and register each actual image. Image generation is a model operation; do not substitute CSS drawings or a screenshot of hand-written markup for requested design imagery. Independent directions can run in parallel with separate stable operation keys.
 
-Prefer 4 or more candidates. Add `--reference <path-or-url>` to carry an existing interface's style into a new page; it retains style and excludes layout, content, and assets by default. Use `--retain layout` only when source geometry should be preserved.
+Inspect real images, choose the strongest fit or present a meaningful choice to the user, and preserve the selected artifact and rationale. A prepared operation or a provider completion alone is not an approved design.
 
-Inspect the real candidate images before continuing. Choose the strongest direction—or present the meaningful choice when the user is involved—rather than averaging them into a generic compromise.
-
-Draft dispatches in the foreground, then generation continues server-side. Run `12ui next <run-dir> --wait` to collect the real images. Keep the recorded run and follow the CLI's continuation instructions.
-
-Only if needed, read [inspire.md](inspire.md) for direct corpus search.
+To let the user choose, open the design workspace on the draft run: call `design.slate.show` with its run directory when the `design.slate.*` tools are available. Otherwise run `npx -y @12ui/design workspace open <run-dir> --wait` (`12ui workspace open <run-dir> --wait` when the installed CLI has that command). It first prints the page's address, then blocks until the user decides; if the sandbox blocks its local page server (a listen or write error), rerun the same command with approval to run outside the sandbox, because it needs a local port and the 12ui state folder. Tell the user in one line to choose in that page. Then stay in this turn until the decision arrives, because ending your turn ends the wait: run the command in the background and read its output every 20 seconds or so (sleep, then read), or give it the longest timeout your shell allows. Continue from the JSON decision it prints.
 
 ## 2. Branch
 
-When the deliverable needs more than one viewport—a full page, a multi-route site, or several app states—expand the approved design rather than re-deriving it per screen.
-
-    12ui branch execute --start <image.png> --scope page|site --convert html --prototype --concept "<what the rest of the surface must cover>"
-
-`--scope page` grows the approved screen into its page; `--scope site` adds sibling routes and app states. Ordered `web_page` viewports belong to one continuous page. Complete application states belong to separate pages; recurring shells must not be stacked into one long document. Inspect the returned page/state mapping and any omitted screens.
-
-    12ui next <run-dir> --wait
+Expand the selected image into the pages or states the deliverable needs. Keep its visual system while preserving each page's real content and purpose. Record an operation for each expansion, with the chosen image among its inputs.
 
-Execute stays in the foreground through its work; `next` can report progress from a second shell. `12ui branch resume <run-dir>` continues the recorded run. Avoid independently rebuilding pages while that conversion is running. Screens land in `<run-dir>/branch/screens/`; converted pages land in `<run-dir>/branch/pages/`.
-
-Use `--prototype` with `--convert html` for a clickable baseline in `<run-dir>/branch/prototype/`. Inspect navigation, shared shells, and any holding pages. Generated interactions do not replace the application's real data and behavior.
-
-Add `--polish` only when the user wants the optional design-improvement pass. For an already converted branch:
-
-    12ui prototype <run-dir>
-
-The same opt-in is available as `12ui prototype <run-dir> --polish`.
+Ordered viewports of one continuous page remain regions of that page. Complete application states belong to separate pages; recurring shells must not be stacked into a long document. Inspect every generated page/state and its mapping before implementation. Labels and navigation proposals are separate text operations when needed, not an automatic paid service requirement.
 
 ## 3. Convert
 
-For a single approved image, convert directly rather than branching.
-
-    12ui convert <source-image> --output html --out-dir <run-dir>
+For a finished design image, prepare the requested conversion directly. Use available session image editing for independent artwork and the coding tools for editable HTML/CSS or the requested framework. Register the output files and material uncertainties. Preserve live text and independent asset ownership; a full-page raster is not editable implementation.
 
-Keep `convert` running in the foreground until it exits. If the client returns a running shell or background task handle, keep waiting on that same handle; use `12ui next <run-dir> --wait` to observe progress while the original process stays alive. Local conversion runs in that process, so ending the client session with work still in flight can interrupt a dispatched model call. Do not deliver a final response until the command has exited and the saved run reports a terminal result. If it reports `needs-reconciliation`, preserve the run and report that state; do not start a fresh conversion or treat `resume` as permission to repeat uncertain paid work.
-
-Use the returned editable HTML/CSS and assets as the implementation baseline. Derive another supported output from the saved run or its output directory:
-
-    12ui convert <run-dir-or-output-dir> --output assets|png|jpg|webp|pdf|react --out-dir <dir>
-
-LayerDoc is optional. Native design formats and hosted conversion-ID derivations have different requirements; consult [outputs.md](outputs.md) when those are requested. Keep the run and follow `12ui next <run-dir>` or `12ui resume <run-dir>` for status and recovery.
+The workflow ledger records what an executor produced; it does not itself reconstruct a LayerDoc, render a page or prove fidelity. Native LayerDoc and its design exports require the dedicated conversion path described in [outputs.md](outputs.md). Do not relabel HTML or arbitrary JSON as LayerDoc.
 
 ## 4. Integrate and close
 
-Integrate the converted code and real assets into the owning project. Preserve its framework, routes, data, controls, and tests. For multi-screen HTML, use the generated prototype as the routing and interaction baseline before wiring application behavior.
-
-After functionality and content are in place, inspect the real browser against each page or state's original approved image. That image remains the visual authority; a derived document or top-viewport screenshot does not prove alignment for lower regions or other states. Check relevant widths and transitions.
-
-Correct concrete observed mismatches in the owning source and re-render. Preserve paid assets and the requested behavior and content. When the CLI provides project apply, use it for focused alignment with the approved image:
+Implement against the selected original image in the owning project. Preserve framework, routes, data, controls and tests. Reuse generated assets. For an existing application, read [improve.md](improve.md).
 
-    12ui improve <implemented-url> --target <approved-screen.png> --repo <repo> --apply --out-dir <directory-outside-repo>
+Inspect the real browser after content and behavior are in place, at relevant wide and narrow widths and through important transitions. Compare each region/state with its original approved image. Correct concrete mismatches in the source and re-render; use a new recorded image edit only when artwork actually needs changing. Keep originals and record the result. Do not impose an automatic broad judge/repair loop.
 
-If project apply is unavailable, omit `--apply` to obtain the existing implementation kit and apply its plan in the owning project. Use the result's source diff, build/test evidence, and browser rendering to verify completion. Do not impose a broad model repair loop when focused normalization suffices or the implementation already matches. Read [improve.md](improve.md) for project apply, hosted kits, and continuous-page coverage.
-
-Deliver openable code, assets, and observed limitations. State when rendering or application behavior remains unverified.
+Deliver openable code and assets, the persistent workspace/operation references, checks performed and observed limitations. State when rendering or behavior remains unverified.
 
 ## 5. Search
 
-Use this when reference imagery itself is the deliverable.
-
-    12ui corpus inspire --query "<product, audience, surface, goal, personality>" --out-dir <directory> --count 4 --reference-image <image.png>
-
-Read [inspire.md](inspire.md) for search modes, ranked manifest order, and interrupted-search recovery.
+Use the design DB when reference imagery is the deliverable or helps ground a design. Follow [inspire.md](inspire.md); preserve ranked manifest order and retrieval evidence. Corpus retrieval is a service boundary separate from local generation and implementation.
 
 ## 6. Improve
 
-Use Improve for an existing interface, Draft for a new first viewport, and Branch to extend an accepted design. With project apply available, let the CLI edit the actual application:
-
-    12ui improve <url> --repo <repo> --apply --out-dir <directory-outside-repo>
-
-Without `--target`, the command drafts candidates and stops for a choice. Inspect the PNGs, choose the strongest fit, then continue the same run:
+Capture and inspect the existing interface locally. With an approved target, prepare implementation work against that image and edit the actual application. For a new direction, prepare redesign image operations from the current capture, inspect the candidates and record the pick before implementation. The pick is mandatory when generating candidates; a design operation alone does not complete the application change.
 
-    12ui improve <url> --repo <repo> --apply --out-dir <directory-outside-repo> --from pick --pick <slot>
+Keep real claims, data, offers, controls and behavior even where the target abbreviates them. [improve.md](improve.md) carries the detailed preservation and inspection guidance, plus explicitly selected legacy CLI and hosted-kit routes. These older commands are alternatives, not the default inside a capable coding session.
 
-With an approved target, use §4's command to skip drafting. Without `--apply`, Improve retains its implementation-kit workflow for URL or image input; read the kit README and apply its plan to the project yourself.
+## 7. 3D scene
 
-Only if needed, read [improve.md](improve.md) for controls, target preparation, site work, and kit use.
+When asked to recreate a design image as a live 3D or Three.js scene, with real geometry, light, and interactions rather than a projection of the picture, read [scene.md](scene.md). It uses the local `12ui scene` tools, which need no account and make no network request:
 
-The pick is mandatory when generating candidates. Exit code 0 with an INCOMPLETE kit means nothing has been picked yet, not that the run failed. Never work around the checkpoint by approximating the design in CSS.
+    12ui scene init <scene-dir>

package/skills/12ui-design/improve.md

@@ -1,6 +1,10 @@
 # Improve an existing interface
 
-Use Improve to redesign an existing interface or align a built page with its original approved image. `--apply` edits the actual repository; omitting it produces the existing implementation kit for you to apply.
+Use the [persistent session workflow](session.md) to redesign an existing interface or align a built page with its original approved image. Capture the current application locally, import the capture and approved target, prepare the needed image-edit or code operation, execute with available session tools, and register the actual output before continuing. Preserve the current project and use its real browser/build/test tools. An existing approved target does not require fresh candidate generation.
+
+For a new direction, inspect generated redesign candidates and record the selected artifact before preparing implementation. The registered target remains the visual authority. Preserve real claims, numbers, offers, data, and controls. Do not describe sparse real content as a defect to fill with inventions.
+
+The sections below document explicitly selected legacy CLI and hosted-kit routes. They can consume separate provider or 12ui credits and do not use the new workflow operation ledger. Do not choose them automatically inside a capable session or after an uncertain workflow dispatch. For these commands, `--apply` edits the actual repository; omitting it produces an implementation kit for you to apply.
 
 ## Apply to the project
 

package/skills/12ui-design/inspire.md

@@ -1,15 +1,18 @@
 # Search the 12ui design corpus
 
-Use this only when reference imagery itself is needed, or when you need direct control over corpus retrieval.
+Use the design DB when reference imagery itself is needed or when it helps ground local design work. Search, status and reference downloads are free without an account, subject to abuse and service-budget limits. Local preparation, generation and registration do not depend on retrieval. Import chosen downloaded reference files into the [persistent workspace](session.md) before using them as operation inputs. Preserve source attribution and retrieval evidence.
 
-    12ui corpus inspire --query "<surface, layout, typography, imagery, palette; 400 chars max>" --out-dir <directory> --count 4
+    12ui corpus status
+    12ui corpus inspire --query "<surface, layout, typography, imagery, palette>" --out-dir <directory> --count 4
 
-Hedge caption generation accepts at most 400 characters after whitespace normalization. Longer queries automatically use balanced retrieval with the complete text; the CLI explains and records the change. Use a short visual caption when you want hedge retrieval.
+`balanced` is the standalone CLI, SDK and MCP default with or without credentials. It weighs relevance, quality and variety. Use `--mode direct|balanced|adventurer` to select an account-free retrieval policy. Preserve manifest order: it is ranked and diversified. Anonymous requests accept at most 24 references and an 8 KB query. An existing supplied credential is retained; invalid credentials are not silently retried anonymously.
 
-`hedge` is the default mode for a text query: it spreads the first references across distinct directions while holding the query, carries retrieval evidence, and its returned order is authoritative. Use `--mode direct|balanced|adventurer|hedge` to select another locked retrieval policy. Preserve manifest order: it is ranked and diversified.
+Explicit `--mode hedge` requires an account because it runs hosted planning. For account-free planning, use the current session to develop directions, then search those directions with balanced, direct or adventurer. Hedge caption generation accepts at most 400 characters after whitespace normalization; longer keyed queries automatically use balanced retrieval with the complete text and a recorded explanation. The separate legacy hosted draft command keeps its own reference-search policy.
 
-Add `--reference-image <image.png>` to rank against an existing interface. That search defaults to `balanced` instead, because the corpus refuses a hedge query that carries an image; `--mode hedge` with `--reference-image` is refused before the search runs.
+Add `--reference-image <image.png>` to rank against an existing PNG, JPEG or WebP interface. The default remains balanced. Explicit hedge cannot carry a reference image and is refused before the search runs.
 
 If retrieval is interrupted, continue the same durable attempt:
 
     12ui corpus resume --out-dir <directory>
+
+For HTTP 429, wait for the reported Retry-After interval and resume the same attempt. Do not start sign-in, buy credits, or create replacement search identities to bypass limits. The service still incurs retrieval costs; free access does not make model execution or image generation free.

package/skills/12ui-design/outputs.md

@@ -1,6 +1,8 @@
 # Outputs and execution
 
-Use `12ui capabilities` and `12ui <command> --help` for the installed CLI's supported inputs, outputs, and engine choices. The caller may be Codex, Claude, or another supported client; the CLI owns execution setup, selection, cost reporting, and recovery. Do not locate skill runtime scripts or assemble a separate authentication/capture handoff.
+Use the [persistent session workflow](session.md) for new work inside a capable coding session. Its operations keep prompts, inputs, provider decisions, results and recovery state locally. It does not imply that every output format has a local executor. Inspect actual session tools and the installed CLI capabilities before preparing an output contract.
+
+The following table and commands describe the existing conversion/export runtime, which remains an explicitly selected alternative. Do not substitute its older automatic engine selection for the workflow service's explicit provider funding policy. Never silently replace a failed local operation with a hosted purchase.
 
 | Requested result | Input and boundary |
 | --- | --- |
@@ -19,6 +21,25 @@ Reuse a compatible hosted conversion for further native derivations:
 
 A new LayerDoc requirement after local conversion is a new operation on the original source, not an export of edited local HTML. Keep that distinction explicit and follow the CLI's supported next command. Never silently replace a failed local operation with a hosted purchase.
 
-`--engine auto|codex|api` controls conversion execution when needed; auto is the default. For supported new conversions, auto selects ready local Codex regardless of the calling client; otherwise it selects API before starting, while saved runs keep their recorded engine. Branch image generation and optional prototype interaction labelling remain hosted even when conversion is local. Image execution is independent: before a new local run, the CLI selects external images when `OPENAI_API_KEY` is available, otherwise native images through Codex account access. An explicit image backend or saved run keeps its choice; explicit external images require the separate key before inference starts. Native does not imply zero cost or a known underlying image model. Project apply requires a ready Codex engine; without it, use the implementation-kit path and apply the plan in the calling coding client. Keep run records and use their status/recovery commands instead of restarting uncertain paid work.
+For the legacy conversion commands only, `--engine auto|codex|api` controls execution; auto is the default. For supported new conversions, auto selects ready local Codex regardless of the calling client; otherwise it selects API before starting, while saved runs keep their recorded engine. Branch image generation and optional prototype interaction labelling remain hosted even when conversion is local. Image execution is independent: before a new local run, the CLI selects external images when `OPENAI_API_KEY` is available, otherwise native images through Codex account access. An explicit image backend or saved run keeps its choice; explicit external images require the separate key before inference starts. Native does not imply zero cost or a known underlying image model. Legacy project apply requires a ready Codex engine. In a capable session, prepare a code operation and edit the actual project directly; use a hosted implementation kit only when that route and its spend are authorized. Keep run records and use their status/recovery commands instead of restarting uncertain paid work.
 
 For local HTML conversion, omit the API-only options `--model`, `--width`, `--responsive-quality`, `--origin`, `--api-key`, and `--idempotency-key`. Local work is identified by its saved run directory and receipt; recover it with `12ui resume <local-run-dir>`.
+
+## Explicit legacy draft and branch
+
+These commands retain the older hosted image orchestration and its own run records. Use them only when the user has selected or authorized that service route; native session generation is the default described in the main skill.
+
+Use `12ui <command> --help` for an installed legacy command's options. Existing local conversion and deterministic derivatives remain available:
+
+    12ui convert <source-image> --output html --engine codex --out-dir <run-dir>
+    12ui convert <run-dir-or-output-dir> --output assets|png|jpg|webp|pdf|react --out-dir <dir>
+
+    12ui draft --concept "<product, audience, surface, goal, personality>" --corpus-query "<surface, layout, typography, imagery, palette; 400 chars max>" --candidates 4
+    12ui branch execute --start <image.png> --scope page|site --convert html --prototype --concept "<remaining pages or states>"
+    12ui next <run-dir> --wait
+    12ui branch resume <run-dir>
+    12ui prototype <run-dir>
+
+Standalone `prototype` defaults to `--labels none`: local deterministic assembly without a 12ui account. Use `--labels workflow --workspace <workspace>` to prepare exact DOM-bound label operations, execute/register them through the session workflow, then repeat the same command to build. [session.md](session.md) covers its pending state and provenance. Use `--labels 12ui` only with authorization for hosted per-screen interaction labeling. Generic image `workflow labels` annotations are a separate schema and cannot replace exact prototype actions.
+
+Keep the chosen source and page/state mapping. Retain the foreground process for legacy local conversions; if it reports needs-reconciliation, preserve the run rather than starting the same work again. Optional polish requires a requested design improvement.

package/skills/12ui-design/scene.md

@@ -0,0 +1,172 @@
+# Rebuild a design image as a live 3D scene
+
+Use this when asked to recreate a design or concept image (hero shot, product on a surface, landing-page render,
+illustrated scene) as a live Three.js scene with real geometry, materials, light and a few interactions, not a
+projection of the picture. Solve the camera from landmarks, model the objects, then check the result from the source
+camera and from 15 degrees either side. Everything runs on this machine through `12ui scene`: no account, no model
+call, no network. `12ui scene --help` lists the tools and `12ui scene <verb> --help` explains each one.
+
+## The rule
+
+- **Model the objects.** Boxes, slabs, lathes, extrusions, instanced detail, procedural textures, physical materials,
+  real lights and shadows. If it is solid in the picture it is solid in the scene.
+- **Use the source image only as a reference** for colour, layout and mood, and as a texture on **flat printed things**
+  (a screen, a label, a poster, a sleeve print). Never paint the whole picture onto geometry, and never bake shading
+  or a reflection into a texture that should be lit.
+- **It must hold at +-15 degrees and beyond.** You are trading some landing-view exactness (proportions, exact colour,
+  a display font) for a scene that is real from every angle. That is the point. Say so in your report.
+- **Everything is modelled procedurally.** There is no image-to-mesh step: a box, lathe, extrusion or instanced
+  field covers the objects a design image shows.
+- Budget 12 to 20 render passes. Stop when passes stop improving the worst mismatch.
+
+## Setup (once)
+
+Work in one folder, with the source image copied into it:
+
+    12ui scene init <scene-dir>
+    12ui scene serve <scene-dir> --port <port>
+
+`init` writes the starter (`index.html`, `camera.js`, `scene.js`, `lib.js`, `gobo.js`, `main.js`) and three.js r186 in
+`vendor/` (no build step, an importmap), and refuses to overwrite anything already there. `serve` binds 127.0.0.1 and
+prints its PID; stop it by that PID when done, never by a name pattern.
+
+The starter already gives you the renderer, tone mapping, the solved camera, a contain-fit frame, orbit about a pivot,
+click-to-toggle actions, and the capture contract (`window.__ready`, `window.__scene.{actions,setOrbit,setAction,reset,render}`).
+`buildScene(scene, renderer, camera)` gets the renderer (PMREM env maps) and camera (gobos, overlays).
+You write `scene.js` (split into modules by object once it grows: `box.js`, `floor.js`, `textures.js`, `actions.js`).
+Page text and buttons are real DOM inside `#stage`, positioned in source pixels.
+
+## 1. Camera first
+
+Everything else is placed through the camera, so solve it before modelling anything.
+
+1. Read the source at full size. Pick **6 to 8 landmarks**: corners of the most clearly rectangular objects (a box, a
+   screen, a table edge, a sleeve, a book), read to the pixel. Include at least one landmark off the main plane, or
+   the field of view is ambiguous. Read them yourself from the image; zoom crops help. If a landmark residual is
+   large later, you misread it.
+2. Write `spec.json` and solve (`12ui scene solve --help` has the format). World coordinates are yours: choose a
+   unit (an object height of 1, or a floor at y = 0), let unknown dimensions be `free`, pin a scale with `"fix"`.
+
+       12ui scene solve spec.json --out cam.json
+
+   rms should be 1 to 4 px. Roll is pinned to 0 unless you set `"solve_roll": true`. Read the `warnings` and
+   `fovSensitivity`: flat-lay and table shots are near top-down and coplanar, where fov is not determined by
+   landmarks. Pin it (`"fix": {"fov": 35}`; 20-30 product shot, 35-50 normal, 60+ wide) or add an off-plane landmark
+   such as an object's top edge above its base. A non-square object of unknown depth: fix its width, `free` its depth.
+3. Paste the printed `camera.js` line into the starter's `camera.js` (degrees, same keys as `cam.json`, plus the `clip`
+   near/far, which must stay tight: far/near under about 100). Set `PIVOT` to the subject centre.
+4. **Place objects by ray, not by eye.** Cast the source pixel of an object's base onto the ground plane, or solve a
+   rectangle directly, then check with `project`:
+
+       12ui scene ray cam.json --plane-y 0 836,691 1237,749
+       12ui scene rect cam.json --corners "TLu,TLv;TRu,TRv;BRu,BRv;BLu,BLv" --plane-y 0
+       12ui scene rect cam.json --corners "TLu,TLv;TRu,TRv;BRu,BRv;BLu,BLv" --width 0.6 --height 0.4
+       12ui scene project cam.json 0.1,0,0.3
+
+   `--plane-y` is a rectangle flat on a surface; `--width` and `--height` are a tilted one of known size. Render once
+   with plain grey boxes at the solved positions. If the silhouettes overlay the source, the rest is modelling and
+   light. If not, fix the camera now: nothing downstream repairs it. A rectangle seen from one view is ambiguous in
+   lean versus depth (give `--width` alone to solve the other side); use what you know (it rests on the floor, it
+   leans on the wall) and force draw order when something ends up inside another object.
+
+## 2. Model and material, per object type
+
+| Object | Build |
+|---|---|
+| Box, carton, crate, wall, table | `BoxGeometry` with real wall thickness, or five walls plus hinged flaps. Bevel visible edges. |
+| Book, card, drive, phone, laptop deck, sleeve | `slabGeometry(w,h,t,r)` from `lib.js` (rounded extrude, clean cap UVs), a page block and boards for a book. |
+| Cup, jar, bottle, vinyl, bucket, lamp | `LatheGeometry` from a profile you read off the silhouette. Vinyl grooves: concentric bands in a roughness and colour canvas. |
+| Logos, rings, outlines, ribbons | `ExtrudeGeometry` of a `Shape`, or a canvas texture if it is printed flat. |
+| Rows of small things (keys, grass, bricks, sand, pins) | `InstancedMesh` with per-instance jitter in scale, rotation, colour. |
+| Terrain, sand, cloth | Displaced plane plus a grain normal or bump map; never a photo. |
+| Flat printed surface | Canvas texture, or the source region rectified (section 4). |
+
+Materials: `MeshStandardMaterial` or `MeshPhysicalMaterial` (clearcoat for lacquer, glass, varnish; roughness map for
+scuffs). Make surface textures procedural on a canvas (`canvasTex`, `grain` in `lib.js`): fibres and speckle for kraft
+or paper, weave for cloth, streaks for brushed metal, value noise for concrete. **Sample the source for colour** before
+you tune: `12ui scene colors source.png --box x0,y0,x1,y1` gives the hex to use; comparing regions against a render
+afterwards gives brightness ratios to correct light, not paint.
+
+Give thin parts real thickness (a sleeve, card or book is 1 to 2 percent of its width, not zero), and keep it consistent
+with the source's shadow length: a long crisp shadow from a thin object means a low light, not a thicker object.
+Glossy discs, lacquer and glass want an environment map, not more lights: `studioEnv(renderer)` from `lib.js`,
+assigned to those materials only.
+
+Light like the source: one key (spot or directional) placed by where the shadows fall, a low hemisphere or ambient
+fill, a warm or cool bounce on the side faces if they read lit. Add `contactShadow` under everything that sits on a
+surface. For a glossy floor use `reflections()` from `lib.js` (mirrored, jittered copies with fade) and a sheen strip;
+planar reflection is often the biggest single win. Window light and leaf shadows: a `SpotLight.map` gobo drawn in
+source-image pixels and resampled through the solved camera, so it lands where drawn and stays real light: the
+starter's `gobo.js` (its header has the recipe and the orientation, which is verified; do not flip anything by hand).
+Volumetric beams: an additive open cone. Use `ACESFilmicToneMapping`, `SRGBColorSpace`, and shadow bias about -0.0004.
+Do not use `PCFSoftShadowMap` (removed in r186).
+
+## 3. Layout and page text
+
+Real DOM for real page text: headline, nav, buttons, body copy, callout labels, in `#stage` at source pixel
+coordinates. Pick the display font by rendering candidate faces at the measured cap height in a strip next to a source
+crop and choosing the closest glyph shapes, then fit the measured line width with a `scaleX` on a span (`data-fit`).
+
+Fonts are local only. Copy a `.ttf`, `.otf` or `.woff2` into the scene folder (from the user's project or an installed
+system font) and load it with `@font-face { src: url(./file.woff2) }`, or use a face that is already installed. Never
+link a hosted font stylesheet: capture blocks it, and its `remote requests blocked` and `fonts:` lines show a missing
+face. Leader lines are SVG whose end dots track 3D anchors (`Object3D.getWorldPosition(v).project(camera)`), so they
+follow the orbit. Never render page text into the 3D scene.
+
+## 4. Screens and app UI
+
+- **Flat and static** (default): flatten the screen quad to a texture, then map it on the screen face of the device
+  slab. Remove painted glare and shadows in the crop, cover any bezel bleed, and light the screen with an emissive map
+  so it reads as lit.
+
+      12ui scene rectify source.png --corners "TLu,TLv;TRu,TRv;BRu,BRv;BLu,BLv" --size 1200x800 --out screen.png
+
+- **Live and editable screens**, only if the user asks for one. Optional, needs network: `12ui convert <crop.png> --output html`.
+  Put the result in a `CSS3DRenderer` layer (`vendor/addons/renderers/CSS3DRenderer.js`) with the same camera, or as
+  an iframe texture; keep the rectified crop as the offline default in the report.
+- A wall of screens, a dashboard, cards on a wall: same recipe per screen, one rectified crop each.
+
+## 5. The self-review loop (this is the work)
+
+After every pass, render and compare:
+
+    12ui scene capture http://127.0.0.1:<port>/index.html --out-dir shots/i01 --size 1536x1024
+    12ui scene sheet source.png shots/i01/landing.png shots/i01/az-15.png shots/i01/az+15.png --out shots/i01/sheet.png
+    12ui scene blend source.png shots/i01/landing.png --out shots/i01/blend.png
+    12ui scene colors source.png shots/i01/landing.png --exclude "x0,y0,x1,y1;x0,y0,x1,y1"
+
+`capture` writes `landing`, `az-15/-10/+10/+15` and `act-<name>` (each action at t = 1), then prints
+`remote requests blocked: N`, `fonts: N loaded, M failed` and any console errors. A blocked count above 0 is a defect:
+the scene reached for something off this machine; make it local. If capture reports that Chromium is missing, run the
+install command it prints once, then retry. Custom views: `half=0:0:lid=0.5` (name=azimuth:elevation:action=t,...).
+Debug an object with `--hide vinyl` (name substring; name your groups), `--eval "js"`, `--size 900x600` for fast passes.
+
+`colors` lists the worst cells of a grid; `--exclude` the boxes covered by DOM text (or `--exclude-dom boxes.json`),
+or the text cells read as error. `--region "name:x0,y0,x1,y1;name:x0,y0,x1,y1"` compares named regions instead.
+
+Open the sheet and the blend (source, render, 50 percent overlay, difference) and look. Fix the **single largest
+mismatch** in this order: camera and silhouettes, object proportions, light direction and value, colour, then texture
+detail. Log one line per pass (what looked wrong, what you changed). Look at `az-15` and `az+15` every time: if an
+object turns into a card, a floor smears, or an edge opens, that is a real defect the landing view hides. Stop when
+the biggest gap left is texture realism. Headless software GL is slow (a few fps); do not chase framerate, but keep
+triangle counts sane (under about 500k) and do not run 9-tap reflections on everything.
+
+## 6. Interactions
+
+Two or three, each on a **separate object**, each a pure function `apply(t)` of `t` in 0..1 (the starter's `actions`
+registry, click a mesh to toggle, ease in and out): a **hinge** (lid, flap, cover, door: a Group at the hinge line,
+rotate it), a **lift** (book, cup, card: translate along its own up axis with a small tilt), a **slide** (drive, paper,
+drawer: translate along its own axis, optionally rotate slightly). Optional small extras: a lit-to-dark toggle,
+a bucket tipping upright. Also give pointer-drag or arrow-key orbit clamped to +-15 degrees, and one or two labelled
+buttons in `#stage` that call `__scene.toggle(name)`. Verify with a real click in the headless page as well as
+`setAction`, and capture each action at t = 1 from the landing camera.
+
+## 7. Report
+
+Say what you built (objects, interactions), the camera rms and worst landmark, how many render passes, the paths of
+the contact sheet and captures, the capture's `remote requests blocked` and `fonts:` lines, and the remaining gaps
+against the source (fonts, texture realism, proportions). Do not claim a pixel match; claim a real scene that reads as
+the source from the landing camera and holds at +-15 degrees.
+
+Ports and processes: use only the ports you were given; stop your servers by the PID `serve` printed; never kill by
+name pattern. Keep output small: `init` copies three.js once per scene folder, and captures go under `shots/`.

package/skills/12ui-design/session.md

@@ -0,0 +1,161 @@
+# Persistent local workflow
+
+Use one local workspace for related work. The CLI and MCP share the same operation service; choose whichever is available. Neither preparation nor artifact import needs a 12ui account. A session handoff lets this conversation use its native tools without extracting credentials or launching a nested coding agent.
+
+## Prepare and import
+
+Import an existing reference once:
+
+    12ui workflow import <image.png> --workspace <workspace> --media-type image/png --role reference
+
+Use an absolute source path when the file is outside the workspace. Relative imported paths resolve inside the workspace, not the shell's current directory. The returned artifact identifies stored bytes by path, hash, size and media type. Put returned artifact objects in the request's `inputs`; do not invent hashes or use expiring remote URLs as durable input identities.
+
+Write a request JSON file. A new design direction can start with:
+
+```json
+{
+  "capability": "image",
+  "prompt": "Design an editorial architecture homepage with warm materials, clear project navigation and restrained typography. Use the attached references as visual context.",
+  "inputs": [],
+  "output": { "kind": "image" }
+}
+```
+
+    12ui workflow prepare <request.json> --workspace <workspace> --key <stable-operation-key>
+
+Preparation returns the persistent operation ID. Reusing the same key with the same request recovers that operation; changed intent needs a new key. Use separate operations for candidates, selected-page expansion, image edits, labels and implementation so dependent work can reuse verified outputs.
+
+`text`, `image`, `image-edit`, `code` and `convert` are distinct capabilities. Output kinds are `json`, `image`, `html` and `project`; JSON may include an output schema. Keep provider credentials, environment dumps and private authentication state out of prompts, parameters and result files.
+
+## Execute in the current session
+
+    12ui workflow execute <operation-id> --workspace <workspace> --providers session --session-capabilities image
+
+Declare the capability of this request only after confirming its tool is available. For an image edit use `image-edit`; for implementation use `code`. A session route returns a handoff with the frozen prompt, input artifacts, expected output, public parameters, work/evidence directories and `attemptNumber`. Keep that attempt number with the returned result or failure; it prevents an old session from settling a newer attempt. Use its selected project directory for implementation; do not edit a different project. This claims the operation before generation. Execute it once using the available native tool, preserve its returned output, and register that output. Do not mistake the handoff for a generated result.
+
+Write a result JSON file using actual existing local files:
+
+```json
+{
+  "files": [
+    { "path": "/absolute/generated-image.png", "mediaType": "image/png", "role": "candidate" }
+  ]
+}
+```
+
+For structured text, use `value` with the requested JSON object. Include `providerRequestId` and `usage` only when actually supplied by the provider; do not estimate missing quota or image price from an account-wide percentage.
+
+    12ui workflow register <operation-id> --workspace <workspace> --attempt <handoff-attempt-number> --result <result.json>
+    12ui workflow status <operation-id> --workspace <workspace>
+
+Registration copies and hashes file artifacts. Use the registered artifacts as inputs to the next prepared operation. Continue from this stored state after a restart, conversation change or executor change. Registration and schema validation establish an artifact contract, not visual approval; inspect the image/browser before accepting it for dependent work.
+
+For an `implement` operation, the service records a baseline of the explicit `projectCwd` before the handoff. Make the actual changes in that project, then register a normal result with `value` containing your report and optional `files` for real additional receipts. Registration compares the project with its saved baseline and adds verified project-change evidence and changed-file artifacts automatically. Do not fabricate that evidence JSON or use a provider receipt as proof of implementation. No changed files produces `project_no_changes`; a claimed no-op is not a successful implementation. Report actual browser/test checks separately: verified file changes do not prove those checks passed, and the service does not invent validation evidence.
+
+For a successful recipe plan, prepare its dependent operations deterministically:
+
+    12ui workflow continue <plan-operation-id> --workspace <workspace>
+
+Continue returns `readyOperationIds`, children, verified artifacts and waiting/blocked state. It does not execute models. Execute each ready operation with the intended provider policy, register its result, then continue the same parent plan again. Draft continuation creates candidate image operations; branch continuation unlocks later slots only after their actual dependency artifacts exist. A redesign plan continues to a draft plan, then to its candidate images. Repeated continuation reuses child IDs. Generic prepared requests have no recipe expansion; prepare their next dependent operation explicitly from registered artifacts.
+
+## Provider selection and cost
+
+    12ui workflow capabilities --session-capabilities text,image,image-edit,code
+
+Only declare the subset actually available. Without a session image tool, a Codex or Claude text CLI is not an image provider. Default routing considers session, Codex, Claude, OpenAI and 12ui in order, filtering for the requested capability and explicit funding permission. Limit `--providers` when a particular execution boundary is required.
+
+Subscription execution consumes the user's model allowance and local resources. OpenAI API execution requires its key and authorization; 12ui execution requires its service credentials and authorization. Set `--allow-paid openai` or `--allow-paid 12ui` only when the user has authorized that provider's spend for this work. A configured key alone does not authorize either. Preparation does not imply authorization for later paid fallback.
+
+The OpenAI adapter requires an explicit account-available model: set public `parameters.model` on a generic request, or use `OPENAI_MODEL` for text/generated HTML and `OPENAI_IMAGE_MODEL` for images. `OPENAI_API_KEY` and `TWELVE_UI_API_KEY` identify separately funded routes; never put keys in requests or results. Native subprocesses remove API-key/provider overrides from their environment. Codex text/code execution is unavailable unless the user trusts their existing CLI configuration, including configured tools and hooks: pass `--trust-codex-config` on execution or discovery only with that authorization. Its read-only text sandbox does not isolate remote tool effects. This opt-in is independent of paid-provider authorization and is unnecessary for the current session's tools. Claude uses supported safe mode, empty MCP configuration and a fixed file-tool set for code; it cannot run shell tests, and its text path currently rejects image attachments. Run project checks in the parent session. Use the session for visual planning, labels and review when it can inspect images. OpenAI code produces HTML without running a project; 12ui code uses its conversion path. Neither is an implementation executor for an existing project.
+
+An unavailable provider can be skipped before dispatch. After a dispatch, a failure is not permission to buy the same work elsewhere. Follow the saved failure disposition: only a recorded proof of non-dispatch or a terminal no-output failure can make another provider eligible. An ambiguous outcome stays in reconciliation; preserve it and recover the actual result before any new dispatch. Do not clear state, change the key or repeatedly execute a handoff to work around this boundary.
+
+If a session tool refuses, is denied permission or has an uncertain outcome, preserve that evidence and record a failure JSON containing `code`, `message` and `disposition`:
+
+    12ui workflow fail <operation-id> --workspace <workspace> --attempt <handoff-attempt-number> --failure <failure.json>
+
+Use `terminal-stop` for refusals or permission denials and `ambiguous` when dispatch/output is uncertain. Neither permits fallback. Use `not-dispatched` or `terminal-no-output` only with actual evidence establishing that outcome; elapsed time, a missing screenshot or a new session is not proof. An ambiguous operation can be completed by registering its recovered original result, not by downgrading the failure to enable another call.
+
+An accepted hosted job with a failed download, or a completed response whose output is malformed, remains in reconciliation under its original operation and attempt. Recover the original provider output and dependencies, validate them and register them against that same attempt. Keep provider IDs and retained responses; do not regenerate or switch providers to repair a delivery failure. Refusals and permission denials remain terminal stops.
+
+## Recipes and MCP
+
+Workflow recipes prepare the same persistent operations. They are request builders, not a hosted pipeline or a guarantee that images/code have already been generated.
+
+| Recipe | Input JSON | Prepared work |
+| --- | --- | --- |
+| `draft` | `concept`, optional `candidates`, `references`, `retain`, `content`, `aspect` | Text plan of distinct candidate prompts; continue it to prepare image operations. |
+| `branch` | `concept`, approved `source`, optional `scope`, `maxScreens`, `references` | Text plan of pages and ordered viewport slots; preserve the existing root and generate only additional slots. |
+| `edit` | `source`, `prompt`, optional `references`, `quality` | Image edit of the first source. |
+| `redesign` | `source`, `direction`, optional `references` | Text concept/retain/corpus-query plan; image generation and implementation are subsequent operations. |
+| `labels` | `source`, optional `context` | JSON labels and proposed interactions; not working behavior. |
+| `review` | `source`, optional `target`, `context`, `criteria` | Evidence-based visual findings and limitations; no numeric quality score, runtime verification or automatic repair. |
+| `convert` | `source`, optional `prompt`, `output`, `native` | Editable HTML/code by default. LayerDoc requires explicit native conversion and its supported provider. |
+| `implement` | absolute existing `projectCwd`, `targets`, optional `prompt` | Code changes in that selected project; preserve source changes and verify real behavior. |
+
+Image paths inside recipe JSON and file paths inside result JSON are relative to the workspace unless absolute. The JSON specification/result file passed to the CLI itself is read relative to the shell's current directory. For example, save `{"concept":"An editorial architecture homepage","candidates":4}` as the draft specification:
+
+    12ui workflow draft <draft-spec.json> --workspace <workspace> --key <draft-plan-key>
+
+Execute that operation with a text-capable session, register the JSON plan, and continue it to obtain stable candidate operation IDs. Inspect candidate images before selecting one for branch or implementation. Check installed help before relying on optional fields; generic `prepare` remains available for an explicit request.
+
+## Capture, review and portable output
+
+Capture a running local or public page with local Chromium:
+
+    12ui workflow capture <http-or-https-url> --workspace <workspace> --width 1440 --height 900 --full-page
+
+This stores screenshot, DOM and manifest artifacts without model work. It uses a fresh unauthenticated browser, not the user's signed-in browser profile. Inspect `requestedUrl`, `capturedUrl` and `redirected` plus the actual image before treating it as application evidence. For an authenticated interface, capture with an available authorized session browser and import that screenshot instead. Chromium must already be available locally.
+
+Prepare a review specification with current screenshot `source`, optional approved `target` and `criteria`:
+
+    12ui workflow review <review-spec.json> --workspace <workspace> --key <review-key>
+
+Execute and register its findings like any text operation with image inputs. A screenshot review cannot prove route behavior, accessibility-tree semantics or tests. Use actual browser and project tools for those checks; prepare only justified corrections after inspection.
+
+For session-generated HTML, register the entrypoint and every asset with their original relative paths. For example:
+
+```json
+{
+  "files": [
+    { "path": "/absolute/generated/index.html", "mediaType": "text/html", "role": "entrypoint", "relativePath": "index.html" },
+    { "path": "/absolute/generated/assets/style.css", "mediaType": "text/css", "role": "asset", "relativePath": "assets/style.css" }
+  ]
+}
+```
+
+Preserve image, font, script and stylesheet mappings; copying only the HTML can break its references. The SDK's `collectBundleFiles(directory, entrypoint)` returns mapped file entries for an isolated generated-output directory; register those entries through the same operation service. Never collect a whole existing project checkout or credential directory. Project changes stay in the selected project; provider receipts alone are not a portable project.
+
+    12ui workflow export <operation-id> --workspace <workspace> --destination <new-output-directory>
+
+Export verifies stored bytes and retains the logical paths. A new or empty directory is required; an identical previous export is reused and differing existing files are refused. Export does not execute a model, convert to another native format, publish a site or validate browser behavior.
+
+## Prototype interaction labels
+
+For an existing converted branch, prepare labels from its actual DOM candidates and known destinations:
+
+    12ui prototype <run-dir> --labels workflow --workspace <workspace>
+
+This performs local browser inventory/analysis and returns `awaiting_labels` with stable operation IDs. It does not dispatch a model or read hosted credentials. Execute each prepared operation through the shared workflow service with an available text provider, then register its JSON using the handoff's attempt number. For a dispatched/reconciling operation, recover its existing result instead of executing again. Repeat the same prototype command once those operations succeed; it consumes the exact completed results and runs the normal build/runtime gates. Legacy branch resume will not replace an `awaiting_labels` pause with hosted label calls.
+
+These operations freeze the real candidate IDs, screen, destinations and source HTML/plan/completion evidence. Generic image `workflow labels` annotations cannot be substituted. Each candidate requires exactly one supported action; unknown navigation targets, duplicate IDs and contradictory payloads are rejected before success. Ambiguous controls should be `none`; local-page outputs permit only navigation to known real pages or `none`. Existing links/forms and deterministic rules retain precedence. A prototype dialog demonstrates behavior; it does not execute a backend task.
+
+For converted branches, a semantic dropdown may label any evidenced menu trigger, regardless of its analyzer kind. Registration preserves the supplied option strings. The existing builder normalizes and deduplicates them; fewer than three usable choices produce an inert control with a recorded `dropdown_options_incomplete` degradation.
+
+The prototype manifest records source custody, operation IDs, provider, funding and reported usage. Its label `costMicros` counts only new hosted prototype-label calls; zero there does not imply free workflow model execution. Repeating preparation or moving the saved branch/workspace preserves IDs when the bound source content and candidate facts are unchanged. The source binding covers HTML, plan, completion and candidate facts, not a snapshot of every remotely linked asset.
+
+Standalone prototype still defaults to `--labels none`. Explicit `--labels 12ui` selects the older hosted per-screen route; it is separate from these local workflow operations.
+
+## Verified native LayerDoc
+
+Native LayerDoc registration requires a canonical public LayerDoc v2 document with role `layerdoc` and `relativePath: "document.layerdoc.json"`, a role `layerdoc-assets` sidecar mapped to `layerdoc-assets.json`, and every referenced raster as a mapped role `asset` file. The sidecar uses schema `12ui.layerdoc-assets.v1`; its `assets` maps each canonical `artifactId` to `{path, sha256, mediaType}`. Paths identify retained local bytes. All files need portable relative mappings, and hashes, media types and declared pixel dimensions must agree with those bytes. Keep canonical artifact identities; do not insert invented URLs or relabel arbitrary JSON as LayerDoc.
+
+Read a completed native operation locally:
+
+    12ui workflow layerdoc <operation-id> --workspace <workspace>
+
+The SDK equivalents are `loadWorkflowLayerDoc({workspace, operationId})` and, for a relocated exported directory, `loadLayerDocBundle({directory})`. They return the canonical `document`, absolute `documentPath` and `manifestPath`, plus `assets` keyed by artifact ID with verified local `path`, `relativePath`, `sha256` and `mediaType`. Raster dimensions are validated against the document. This is a verified local reader contract, not an offline editor or a new conversion.
+
+The standard hosted `12ui convert <layerdoc.json>` path does not consume this sidecar bundle. It requires supported hydrated HTTP asset references; uploading local assets and hydrating those references needs a separate API path that is not supplied by the reader. Do not upload the raw canonical JSON alone and claim its local assets will follow.
+
+The MCP equivalents are `design.workflow.prepare`, `design.workflow.execute`, `design.workflow.register`, `design.workflow.continue`, `design.workflow.fail`, `design.workflow.status`, `design.workflow.import`, `design.workflow.capabilities`, `design.workflow.capture`, `design.workflow.export` and `design.workflow.layerdoc`. Recipes use `design.workflow.prepare` with `recipe` and `input`; registration and failure use the handoff's `attemptNumber`. MCP execution and discovery accept `trustCodexConfig` for the same explicit Codex configuration trust boundary. Use the tool's supplied schema. They call the same service and obey the same provider authorization, custody and reconciliation rules as the CLI. Do not log into 12ui merely to prepare, inspect or register local operations.