@pixel-point/toolcraft 0.0.15 → 0.0.17

package/templates/starter/docs/toolcraft/acceptance-testing.md

@@ -9,16 +9,16 @@ Every visible product entity must prove it works. A control is not accepted beca
 - `src/app/app-acceptance-data.ts`
 - app-specific tests under `src/app` outside the reserved `app-acceptance.*` framework namespace
 - `src/app/app-performance.ts`
+- `src/app/app-verification-impact.json` (presentation, functional, and performance ownership with nearest acceptance ids and exact performance pass ids)
 - `src/app/app-performance.test.ts`
 - `docs/toolcraft/agent-worklog.md`
 - `e2e/app-browser-acceptance.spec.ts`
 - `e2e/app-controls.spec.ts`
 - `e2e/app-performance.spec.ts`
+- `e2e/app-kernel-benchmarks.ts`
 - `e2e/product-observable-helpers.ts`
 
-`pnpm verify:final` must pass before final delivery. Incremental edits use the verification tier classifier from `assembly-workflow.md`: run targeted browser acceptance for the changed entity, and add a full browser performance checkpoint for the first working product version or an explicit performance complaint. Run `pnpm verify:perf` before the final gate; its protected Playwright runner records the current-source machine receipt automatically. Agent-controlled browser checks remain useful for targeted diagnosis but cannot replace that receipt. `verify:final` rejects a missing or stale current-source receipt.
-
-A full performance checkpoint is triggered only by the first working app version, or by a user request to optimize performance, fix lag, remove jank, speed up animation, stabilize drag/zoom, or otherwise investigate poor performance.
+Use focused checks during edits. First delivery and later delivery run bare `pnpm verify:delivery` per `workflow.md`. Performance complaint authority adds an iteration; explicit full audit authority permits `pnpm verify:perf`.
 
 ## Product Readiness
 
@@ -27,14 +27,23 @@ The exported starter may keep `appProductReadiness.mode: "starter"` only while i
 - `productName`;
 - `productSummary`;
 - `requestedBehavior`.
+- `viewInteraction`.
+
+`viewInteraction` classifies the product as `non-spatial`, `orbit`,
+`fixed-camera`, or `timeline-camera`. Editable spatial scenes default to orbit;
+fixed/timeline modes require explicit request/reference evidence.
 
 Product readiness also requires product surface: controls, layers, timeline, `canvasContent`, or acceptance coverage. A renamed product folder must not pass tests as a neutral starter.
 
 ## Implementation Worklog
 
-Product apps must update `docs/toolcraft/agent-worklog.md` before final delivery. The file records why the app chose its renderer, timeline mode, layer policy, control grouping, export behavior, and performance strategy.
+Product apps must update `docs/toolcraft/agent-worklog.md` before final delivery. The file records why the app chose its renderer, view interaction mode, timeline mode, layer policy, control grouping, export behavior, and performance strategy.
+
+The worklog must declare `Mode: product`. Every `Decision Trail` records human intent: `Request:`, `Task type:`, `User-visible result:`, `Source/reference checked:`, `Reference inputs:`, `Docs/contracts read:`, `Contract rules applied:`, `View interaction intent:`, `Interaction ownership:`, `Decision:`, `Alternatives rejected:`, `State/output mapping:`, `Performance intent:`, bare-delivery `Verification:`, and `Risks:`. Steering within one request stays in that batch. `Reference inputs:` lists every prompt/reference asset or `None`; `State/output mapping:` connects state to visible output or export.
 
-The worklog must declare `Mode: product`. Every `Decision Trail` iteration must include `Request:`, `Task type:`, `User-visible result:`, `Source/reference checked:`, `Reference inputs:`, `Docs/contracts read:`, `Contract rules applied:`, `Decision:`, `Alternatives rejected:`, `State/output mapping:`, `Files changed:`, `Verification:`, `Skipped checks:`, and `Risks:`. `Reference inputs:` is the explicit inventory of prompt/reference assets for that pass: write `None` only when there were no external references, otherwise list the source apps, URLs, screenshots, videos, GIFs, screen recordings, contact sheets, extracted-frame folders, or media files used. `State/output mapping:` names how controls, commands, timeline, layers, media, or renderer state reaches the visible product or export. Each decision section (`Renderer`, `Timeline`, `Layers`, `Controls`, `Export`, `Performance`) must include `Decision:`, `Reason:`, and `Evidence:` entries. `Evidence` should name files, reference behavior, contract rules, browser checks, performance checks, or exact commands. `Performance` evidence must name the hard limit, smooth target, smooth target ratio, failed higher measurements, and attempted optimizations whenever a load profile lowers the smooth target below the hard limit. `Verification` must list concrete checks such as `pnpm verify:quick`, targeted agent-browser diagnosis, browser tests, and the automated `pnpm verify:perf` checkpoint. First working product delivery must record `pnpm verify:final` and `pnpm verify:perf` as passed. Failed, incomplete, pending, blocked, or skipped required checks make the app incomplete unless the full performance checkpoint is explicitly not required for a post-first-working non-performance edit. `Risks` must include either `Risk:` entries or `None:` with a reason.
+Each decision section (`Renderer`, `View Interaction`, `Interaction Ownership`, `Timeline`, `Layers`, `Controls`, `Export`, `Performance`) includes `Decision:`, `Reason:`, and `Evidence:`. View interaction records mode, source, alternatives, and orientation targets. Performance records the modeled workload, pass lifecycle, assessment, and affected paths. A complaint adds an exact `Performance request evidence:` quote and unique canonical `Performance paths:`.
+
+Protected receipts own changed files, the immutable plan, executed checks, reports, measurements, and pass/fail evidence. A Decision Trail does not duplicate those fields or supply command-shaped authority. `Risks` includes either `Risk:` entries or `None:` with a reason.
 
 The acceptance gate fails if the worklog is missing, still says `Mode: starter`, or lacks concrete decision evidence.
 
@@ -58,29 +67,44 @@ Each row should name:
 - `canvasSizingCoverage: "fixed-output-size"` only for non-product/internal `fixed-output` fixtures.
 - `canvasSizingCoverage: "intrinsic-media-size"` only for explicit media-viewer/source-native upload apps where imported media natural dimensions intentionally own `canvas.size`.
 - `persistenceCoverage: "reload"` when schema `persistence.storage` is `"localStorage"`.
+- `persistenceSlices` exactly equal to resolved `schema.persistence.include` for reload coverage.
 - `timelineLoopProof` on playback rows whose `timelinePlaybackCoverage` includes `"loop"`. It declares `direction: "forward-only"`, `reversePlayback: "forbidden"`, `seam: "first-last-match"`, and `durationChange: "reproved-after-edit"`; browser evidence still proves the real sampled frames.
 
 The test gate rejects rows unless the real Vitest and Playwright runners select exactly one product-owned test with the declared name and that test finishes passed. A matching name in a comment, string, local fake runner, focused/skipped test, conditional branch, or uncalled registration function is not execution evidence.
 
-The protected Vitest marker publishes the current automated requirements to the signed runner reporter, which evaluates actual selected test results instead of parsing test source. The signed full-test command fails when that marker is missing, duplicated, failed, invalid, or not framework-owned. User-visible browser behavior is proved at runtime: protected Playwright helpers attach versioned evidence after their assertion succeeds, and the signed reporter derives every required evidence id from `app-acceptance-data.ts`. A skipped/failed test, duplicate product test titles, a passed browser test without matching evidence, evidence from a failed retry, or a direct forged attachment fails its runner.
+Protected Vitest and Playwright reporters evaluate passed runner results plus matching runtime evidence instead of test-source spelling. They reject missing, duplicate, skipped, failed, retry-failed, invalid, or forged evidence.
+
+`src/app/app-acceptance.ts`, `src/app/acceptance`, supplied `app-acceptance.*` meta-tests, and the generic browser harness are framework-owned and signed. Edit only `app-acceptance-data.ts` for product rows/readiness/inventory/transfer intent. Put registered browser scenarios in `e2e/product-<domain>.spec.ts`; reserve `app-controls.spec.ts` for unregistered smoke checks or the `app` domain.
 
-`src/app/app-acceptance.ts`, `src/app/acceptance`, supplied `app-acceptance.*` meta-tests, and the generic browser acceptance harness are framework-owned and covered by the signed integrity manifest. Edit only `app-acceptance-data.ts` for product rows/readiness/inventory/transfer intent. Add product-specific automated tests in separate app-owned files and add browser scenarios to `e2e/app-controls.spec.ts` or new app-owned specs.
+The `e2e/app-browser-*` prefix is reserved for signed framework specs.
 
-The `e2e/app-browser-*` filename prefix is reserved for signed framework specs. Product browser tests use `app-controls.spec.ts` or a product-specific filename that does not start with `app-browser-`.
+## Semantic Proof Ownership
 
-The local contract docs under `docs/toolcraft` are also signed framework-owned input to this workflow. Do not rewrite them inside a generated app. `docs/toolcraft/agent-worklog.md` remains product-owned so each implementation pass can record current decisions and evidence.
+Every runtime production module/resource has a direct owner in `src/app/app-verification-impact.json`; proof and test paths cannot own them. Each browser file owns one acceptance domain (the first ID segment). Later delivery compares semantic models and selects changed contracts, owners/domains, and product-unit tests—not filenames or reverse imports. Additive owner deltas select only new IDs; other deltas retain affected IDs.
+
+Classifier output establishes complaint authority only; unresolved localization creates no intent/path regardless of result. Only localized/clarified work starts an iteration.
+
+Contract docs are signed except product-owned `agent-worklog.md` and optional `workflow-observation.md`; only the observation stays outside `sourceHash`.
 
 Framework meta-tests are product-invariant: their synthetic validator cases use protected neutral contract fixtures, never the editable app schema, product acceptance rows, transfer intent, or section inventory. Put exact product targets, defaults, option values, and product-specific expectations in separate app-owned tests. The product gates still read `app-schema.ts`, `app-acceptance-data.ts`, product test names, worklog evidence, and browser scenarios dynamically.
 
-The same ownership split applies to performance: edit `app-performance.ts`, but do not edit supplied `app-performance.*` meta-tests or `app-performance-test-utils.ts`. They are framework-owned and validate the editable product matrix.
+The same ownership split applies to performance: edit `app-performance.ts`, `app-verification-impact.json`, product performance path adapters, and the kernel candidate harness when assessment requires it. Do not edit supplied `app-performance.*` meta-tests, protected reporters, receipt writers, or `app-performance-test-utils.ts`; they validate product inputs and own execution evidence.
 
 Slider and range slider rows must prove live behavior. Browser tests should drag the real thumb and assert the runtime value and product-level canvas observable update during the drag, not only after pointer release, blur, an Apply action, or a final commit. Performance-sensitive sliders still need this live acceptance; jank is handled through renderer optimization and targeted performance coverage, not by making the slider deferred by default.
 
-`fixed-output` canvas sizing must be deliberate and is not valid for generated product/output apps with export actions. A default, reference, or fixed-format size from the prompt should use `editable-output`, which keeps the runtime Aspect ratio, Canvas width, and Canvas height controls.
+`fixed-output` is invalid for generated product/export apps; prompt/reference dimensions are editable `canvas.size` defaults. Use `intrinsic-media` only for source-native viewers. Product background/source uploads stay `editable-output`; browser proof uses a mismatched aspect ratio to confirm upload preserves canvas size and renders cover/crop.
+
+## Infinity Canvas Coverage
+
+Every editable-output app proves `infinityCanvasCoverage` mode/restoration. With Background, proof changes its color, verifies the infinite viewport, turns it off to restore finite mode/disable Infinity, then on without enabling Infinity. Image/video proof decodes scene-bounds output from `sceneBoundsProvider`; runtime video unions exact bounds from every scheduled frame state. Fixed recipes cover excluded content and exact empty, unavailable, and oversized failures. See `core/setup-export.md`.
+
+## Render Scale Coverage
 
-`intrinsic-media` upload sizing must also be deliberate. Uploaded background/source images inside product canvases use `editable-output`, keep the current canvas size after upload, keep Setup canvas controls visible, and render cover/crop inside the current canvas bounds. Browser acceptance must upload an image with a different aspect ratio and prove the current canvas size remains unchanged while the image covers/crops the canvas.
+For a raster product with render scale, add one `canvas.renderScale` browser row: `renderScaleCoverage: { kind: "selected-backing-pixels", states: ["interaction", "steady"] }`; timeline adds `"playback"`.
 
-When localStorage persistence is enabled, add a runtime acceptance row that proves reload behavior. The browser test must change a real user-facing setting, wait for persistence to write, call a real page reload, and verify the restored control value or product output. Importing a settings JSON file is not persistence coverage.
+Run `expectToolcraftCanvasRenderScaleEvidence` per state. CSS size stays fixed and backing must equal `CSS × devicePixelRatio × selected scale` within one pixel before `canvas-render-scale-backing`; mismatch fails. Every measured path in that product proves exact `CSS × devicePixelRatio × 2` after each phase.
+
+Default local persistence requires one runtime row with `evidence: "persistence-state"`, `persistenceCoverage: "reload"`, and `persistenceSlices` equal to the resolved plan. Browser proof changes each slice, waits for status `success`, reloads, then verifies restored state and real output before evidence. Settings import/export is not reload proof.
 
 ## Compound Controls
 
@@ -88,19 +112,19 @@ Compound controls have multiple semantic value parts inside one visible control.
 
 Required parts:
 
-| Control | Required `controlPartCoverage` |
-| --- | --- |
-| `anchorGrid` | `anchorGrid.position` |
-| `channelMixer` | `channelMixer.activeChannel`, `channelMixer.values`; only for RGB channel matrix behavior |
-| `collectionActions` | `collectionActions.add`, `collectionActions.remove`, `collectionActions.items` |
-| `colorOpacity` | `colorOpacity.hex`, `colorOpacity.opacity` |
-| `curves` | RGB variant: `curves.activeChannel`, `curves.points`; `variant: "single"`: `curves.points` |
-| `fontPicker` | `fontPicker.fontId`, `fontPicker.fontWeight`, `fontPicker.fontSize`, `fontPicker.letterSpacing`, `fontPicker.lineHeight`, `fontPicker.textCase`, `fontPicker.color`, `fontPicker.opacity` |
-| `gradient` | `gradient.gradientType`, `gradient.angle`, `gradient.stops.position`, `gradient.stops.color`, `gradient.stops.opacity` |
-| `palette` | `palette.family`, `palette.shade` |
-| `rangeInput` | `rangeInput.start`, `rangeInput.end` |
-| `rangeSlider` | `rangeSlider.lower`, `rangeSlider.upper` |
-| `vector` | `vector.x`, `vector.y` |
+| Control             | Required `controlPartCoverage`                                                                                                                                                            |
+| ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `anchorGrid`        | `anchorGrid.position`                                                                                                                                                                     |
+| `channelMixer`      | `channelMixer.activeChannel`, `channelMixer.values`; only for RGB channel matrix behavior                                                                                                 |
+| `collectionActions` | `collectionActions.add`, `collectionActions.remove`, `collectionActions.items`                                                                                                            |
+| `colorOpacity`      | `colorOpacity.hex`, `colorOpacity.opacity`                                                                                                                                                |
+| `curves`            | RGB variant: `curves.activeChannel`, `curves.points`; `variant: "single"`: `curves.points`                                                                                                |
+| `fontPicker`        | `fontPicker.fontId`, `fontPicker.fontWeight`, `fontPicker.fontSize`, `fontPicker.letterSpacing`, `fontPicker.lineHeight`, `fontPicker.textCase`, `fontPicker.color`, `fontPicker.opacity` |
+| `gradient`          | `gradient.gradientType`, `gradient.angle`, `gradient.stops.position`, `gradient.stops.color`, `gradient.stops.opacity`                                                                    |
+| `palette`           | `palette.family`, `palette.shade`                                                                                                                                                         |
+| `rangeInput`        | `rangeInput.start`, `rangeInput.end`                                                                                                                                                      |
+| `rangeSlider`       | `rangeSlider.lower`, `rangeSlider.upper`                                                                                                                                                  |
+| `vector`            | `vector.x`, `vector.y`                                                                                                                                                                    |
 
 Testing only one sub-control is not enough. For example, a `gradient` test that changes only a stop color must fail if the app also renders Gradient type, Angle, Position, or Opacity controls.
 
@@ -112,6 +136,19 @@ For `fontPicker`, product output evidence must come from actual rendered/exporte
 
 For `vector`, acceptance must prove both axes affect output and that the pad represents a user-authored stable two-axis parameter. Do not accept `vector` controls for current animation state, keyboard/pointer movement, physics state, timeline phase, velocity, target pose, current pose, or simulated position/direction; those belong to timeline/input/simulation state plus higher-level tuning controls such as Speed, Step, Spread, Path, Duration, or Timeline.
 
+For `orientationGizmo`, use one `kind: "canvas-handle"` row per declared handle whose `canvasHandle.writesTarget` is the schema pose target and whose `testId` is `toolcraft-orientation-gizmo`. Declare `orientationGizmoCoverage: "all-required-orientation-gizmo-behavior"` or every required part: axis drag, axis snap, model drag, canvas miss-pan, shared pose/output, undo/reset, and export-clean.
+
+Orientation coverage begins with product readiness, not with an already-present
+control. Every product declares `viewInteraction`. `orbit` must list a non-empty,
+unique set of targets that exactly matches all schema `orientationGizmo`
+targets. `non-spatial`, `fixed-camera`, and `timeline-camera` reject direct-orbit
+gizmos. Fixed and timeline camera modes require explicit request/reference
+evidence; timeline camera additionally requires timeline playback or keyframes
+intent and an enabled Toolcraft timeline. This prevents a renderer from silently
+choosing a fixed camera and thereby escaping gizmo acceptance.
+
+Use protected `expectToolcraftOrientationAxisDrag`/`AxisSnap`/`ModelDrag`/`CanvasMissPan`/`UndoReset` recipes. Axis drag finds blank circular background and performs the pointer drag; axis snap projects and clicks the requested endpoint from canonical pose. Evidence follows pose/output/ownership/history assertions. Arbitrary mutations, endpoint-only or generic drag, source spelling, and value changes do not qualify. Use `expectExportExcludesCanvasHandles` for export-clean proof.
+
 ## Control Selection Gates
 
 Acceptance must catch wrong-substitution failures. If the prompt, spec, or app behavior needs a value model owned by a built-in control, the schema must use that built-in or include a documented built-in fit check.
@@ -126,12 +163,23 @@ High-confidence wrong-substitution cases:
 - from/to range without `rangeSlider` or `rangeInput`;
 - curve, remap, easing, or response without `curves`;
 - manual stable two-axis position, direction, focus, anchor, light, or vector parameters without `vector`;
+- user-rotatable 3D model/view orientation implemented as `vector`, paired sliders, axis buttons, or custom gizmo instead of `orientationGizmo`;
+- a visible editable spatial scene classified as fixed/non-spatial without explicit request or inspected-reference evidence;
 - source upload without `fileDrop`;
 - app-wide transport in the controls panel instead of timeline;
 - segmented choices that clip instead of falling back to `select`;
 - custom controls recreating built-ins.
+- one user operation mirrored across canvas and panel, even when the two copies use different labels, ids, or chrome.
+
+## Interaction Ownership Evidence
 
-`fileDrop` media-lifecycle rows must prove upload/import, clear/remove, image rotate/flip, thumbnail reorder for `multiple: true`, and global or section reset. A test that only clicks the clear button is not enough because Reset controls must also restore `media.defaultAssets` for predefined attached files or remove uploaded source material when no default exists. Product preview/export must consume runtime media order and `mediaAssets[].transform`.
+Product readiness declares `interactionOwnership`. Canvas handles, custom interactions, and panel controls sharing a canvas target bind `interactionId`. Acceptance rejects one id on both surfaces, renamed copies of the same target/capability, bad links, or choices lacking evidence and an alternate-surface reason. Distinct capabilities may share state across surfaces and are proved separately.
+
+`fileDrop` rows prove upload/admission, clear/remove, reset/default restoration, and binary/model lifecycle. Without Layers ownership they also prove image rotate/flip and `multiple` reorder. With `panels.layers` and typed media-management ownership, omit those claims from `fileDrop`: runtime `layerCoverage: "reorder"` and `"selected-layer-controls"` rows prove order and selected-transform output. Clear-only proof is invalid; Reset restores defaults or removes uploaded media.
+
+A model `fileDrop` row declares `modelImportCoverage: "all-required-model-import-behavior"` or every typed item: `advertised-format-import`, `staged-preview`, `clean-commit`, `package-extraction`, `deterministic-root-selection`, `appearance-preservation`, `fallback-appearance`, `presentation-consumer-readiness`, `pixel-output`, `repairable-diagnosis`, `repair-action`, `repair-progress`, `verified-repair`, `fatal-rejection`, `persistence-restore`, `resource-unavailable`, `preview-output`, `export-output`, and `history-reset`.
+
+Protected browser evidence imports every format plus folder/ZIP; proves first-root choice, runtime/custom readiness, nontransparent RGBA, and authored signatures versus fallback. Metadata, changed pose, or a canvas node is not proof. Fatal input keeps the prior commit. `Fix model` requires a deterministic topology plan and verified result; appearance warnings never expose it. Processing preview is `40%`; committed preview/export is `100%`. Both share document, appearance key, pose pixels, and omit gizmo chrome. Reload proves repository-backed appearance; corrupt refs become `unavailable`. History/reset proves removal, enabled undo/redo, and default restore through import.
 
 Rows that use custom controls must include `customControlCoverage` and typed `builtInFitCheck`.
 
@@ -155,6 +203,11 @@ builtInFitCheck: {
 
 The fit check declares broad typed capabilities, names real checked built-ins, the closest built-in or `"none"`, why it is insufficient, and the product-observable evidence that proves the custom control works. At least one of `custom-interaction`, `custom-value-model`, or `custom-visualization` is required; collection/command chrome alone does not justify custom UI.
 
+A fit check containing `custom-interaction` also requires `interactionId` and a
+panel ownership entry. The fit check compares built-in controls; ownership
+separately proves why the operation belongs in the panel instead of directly on
+the canvas. Passing one gate never bypasses the other.
+
 For collection-like custom controls, the fit check must include `collectionActions` and `actions`. Collection-like is decided from the runtime value model and workflow: arrays, `{ items: [...] }` objects, selected-item state, grow/shrink item sets, ordering, add, remove, delete, or reorder behavior. Acceptance should fail if the row compares only unrelated built-ins such as `vector` or `select` while the actual value model is a collection.
 
 Custom controls cannot be justified by icons, layout, styling, compactness, or custom buttons alone. `whyInsufficient` must name the product interaction or value model that built-ins cannot express.
@@ -173,13 +226,15 @@ Valid acceptance evidence includes:
 - changed timeline playback state plus rendered frame.
 - restored persisted value or product output after browser reload.
 
-Product apps must include output delivery acceptance. Still-output apps need `Export PNG` evidence. Animated apps need both `Export Video` evidence and `Export PNG` evidence. Clipboard copy can be tested as an additional behavior, but it cannot replace export coverage.
+Product apps must include output delivery acceptance. Every product needs `Export PNG` evidence. Apps whose requested delivery includes animation also need `Export Video` evidence; timeline playback or keyframes alone do not invent video delivery. Clipboard copy can be tested as an additional behavior, but it cannot replace export coverage.
+
+Export-content proof is distinct from export mechanics: content inspects selected artifact semantics; mechanics proves lifecycle, format, dimensions, transport, and errors. Neither substitutes.
 
 Every app with `Export PNG` must exercise the separate `Image Export` section: choose at least two `export.image.format` values, choose at least two `export.image.resolution` values, export the image, and decode the result to prove file type and actual pixel dimensions changed. Animated apps with both `Export PNG` and `Export Video` still need this image-export coverage; `Video Export` does not replace it.
 
-Async Export, Download, Copy, Generate, or Apply acceptance must prove the sticky footer top accent indicator is visible while the returned `onPanelAction` Promise is pending, advances when `reportProgress(0..1)` is called, and hides after it settles. Video export acceptance must prove frame-based progress updates during render/encode instead of only toggling a pending state.
+Runtime Export acceptance must prove the sticky footer top accent indicator advances through real render/encode/download work and hides only after the artifact settles. Async non-export Download, Copy, Generate, or Apply acceptance must prove the indicator is visible while the returned `onPanelAction` Promise is pending, advances when `reportProgress(0..1)` is called, and hides after it settles.
 
-Animated app acceptance must also exercise the separate `Video Export` section: choose at least two `export.video.format` values, choose at least two `export.video.resolution` values, verify unsupported MIME/container choices fall back safely, and assert exported video bytes, dimensions, MIME/container, and duration match runtime timeline state. `current` video export must use the current canvas/output size with even encoder-safe rounding. `4k` video export must use `getToolcraftVideoExportSize`, fit inside 3840x2160, preserve aspect ratio, and produce even dimensions; do not accept PNG-style 4096px long-edge video sizing. Recorder/encoder errors must reject instead of resolving corrupt blobs. The duration assertion must load the exported blob as a video, wait for metadata, and compare `video.duration` with the edited timeline duration; `blobSize > 0`, `blobType`, WebM parser fallback, or assigning the expected duration when metadata is missing are not enough.
+Animated app acceptance exercises two video formats and resolutions. It proves real bytes, dimensions, actual MIME/container or typed capability failure, timeline duration, 30 FPS timestamps/durations from actual encoded packet metadata, decoded product motion, current even-safe sizing, and aspect-preserving 4K inside 3840x2160. Renderer/encoder/muxer errors reject; `blobSize`, metadata alone, assumed FPS, synthetic frame counts, or substituted expectations are invalid. Animated output requires distinct decoded frame hashes.
 
 Footer action acceptance must not include Reset. Reset is already available in the controls panel header and uses schema `defaultValue`; duplicating it in sticky `panelActions` fails acceptance.
 
@@ -187,14 +242,14 @@ Local `actions` acceptance must click every visible action and prove the nearby
 
 `collectionActions` acceptance must click plus and minus in the real panel, prove the runtime target array length changes, prove `minItems` prevents invalid removal, prove `recommendedMaxItems` is not a hidden hard limit, and prove preview/export consumes the changed item list.
 
-PNG export tests must prove runtime background behavior: changing the background color affects preview/export, turning `export.includeBackground` off hides the live preview product background and creates transparent PNG output, video export still keeps the background, turning Include on includes the current background color in PNG, and exported pixel dimensions are retina size, at least `state.canvas.size * 2`.
+Image export proves background changes in preview/artifact/infinite viewport; Background off restores finite mode, disables Infinity, hides bounded preview background, and makes PNG transparent while JPEG/video stay opaque. Restoring it enables Infinity availability without entering that mode. Protected proof decodes real type, selected dimensions, product bounds/pixels, and pixel hash; bytes or dimensions alone are insufficient.
 
 Hard acceptance semantics are typed, not inferred from English prose. Every `visibleWhen` acceptance row declares `visibilityCoverage` for both `hidden` and `visible`; the protected conditional-visibility recipe must remove the dependent target from the rendered panel and restore it through the same target-scoped gating control. The `export.includeBackground` row declares `backgroundOutputCoverage` for preview exclusion and transparent image alpha, plus preserved video background when the schema exposes video export. Its protected recipe verifies the preview transition, decodes a non-empty image artifact and checks background alpha, and inspects video background behavior when applicable. `expectedObservable` and `userAction` remain human-readable context and may use any language; matching words such as “hidden”, “PNG”, or “video” never satisfy these requirements by themselves.
 
 Invalid final acceptance evidence:
 
 - control exists;
-- `data-*` attribute changed;
+- app `data-*` or SVG signature changed;
 - runtime state was mutated directly;
 - DOM text changed but product output did not;
 - shader uniform changed without output proof;
@@ -221,7 +276,7 @@ Specialized state, layer, compound, and timeline recipes begin with `createToolc
 
 Exported-byte rows use `expectToolcraftExportedArtifact`. The action produces a non-empty artifact and the verifier returns a typed inspection with positive integer `byteLength`; decoded `width`, `height`, and `frameCount` are positive integers, `durationMs` is positive and finite, and `mediaType`/`contentHash` are non-empty strings when present. Missing/empty artifacts, void callbacks, `{ ok: true }`, fractional or zero-byte observations, and fractional decoded dimensions cannot emit evidence. Clean-export checks for canvas handles compare decoded product semantics through `contentHash` plus media metadata, not raw encoded bytes or file size, because two valid encoders may produce different bytes for the same output.
 
-Specialized metadata adds evidence for the same row: canvas handles prove drag and a separate clean-export test compares real exported artifacts with handles visible and hidden; segmented/discrete controls use their protected layout helpers; every declared compound-control part uses `expectToolcraftCompoundControlPartOutcome` and gets its own `row-id#part` evidence; layers use the fixed `expectToolcraftLayer*` recipes for selection, visibility, reorder, grouping, selected-layer controls, and media lifecycle; and reference parity uses `expectToolcraftReferenceParity` to compare the inspected result with the reference baseline. Playback uses the fixed `expectToolcraftTimeline*` recipes. Duration binds runtime duration and renderer cycle to the same expected value; scrub binds time to rendered output; pause/resume proves a stable paused window and resumed time/output; keyframes bind keyframe data, evaluated value, and output. Loop evidence requires normalized forward samples with exactly one end-to-start wrap, equal seam signatures, and the same proof again after changing duration. The reporter derives these requirements from acceptance plus schema; naming a helper in source or passing a desired evidence type to a generic helper is never proof.
+Specialized metadata adds evidence for the same row: canvas handles prove drag and a separate clean-export test compares real exported artifacts with handles visible and hidden; segmented/discrete controls use their protected layout helpers; every declared compound-control part uses `expectToolcraftCompoundControlPartOutcome` and gets its own `row-id#part` evidence; layer selection emits only `layer-selection`; output rows separately use the public pixel/export helper. Other layer recipes emit base evidence only after output changes; reference parity uses `expectToolcraftReferenceParity` to compare the inspected result with the reference baseline. Playback uses the fixed `expectToolcraftTimeline*` recipes. Duration binds runtime duration and renderer cycle to the same expected value; scrub binds time to rendered output; pause/resume proves a stable paused window and resumed time/output; keyframes bind keyframe data, evaluated value, and output. Loop evidence requires normalized forward samples with exactly one end-to-start wrap, equal seam signatures, and the same proof again after changing duration. The reporter derives these requirements from acceptance plus schema; naming a helper in source or passing a desired evidence type to a generic helper is never proof.
 
 Animated viewport tests must also prove that canvas drag, pan, pinch, zoom, and radar/center interactions suspend or coalesce non-essential animation preview work without changing the user's play/pause state. After the interaction, the renderer must resume from the correct timeline or autonomous time and keep canvas zoom/offset stable.
 
@@ -271,9 +326,9 @@ Component variants are acceptance requirements.
 - Range sliders must stay full-width, start with different lower and upper defaults, and accept built-in manual range separators such as slash, hyphen, spaces, and dashes.
 - Segmented controls must preserve cell padding and avoid label collision.
 - Select, segmented, and image-picker controls should cover every visible option unless options come from separately tested runtime data.
-- Custom controls must declare `customControlCoverage` and `builtInFitCheck`. Coverage proves the custom control is not a built-in replacement, uses kit chrome, keeps only necessary UI, writes through runtime state, and changes product output; the fit check proves which built-ins were considered and why the custom interaction is necessary.
+- Custom controls must declare `customControlCoverage` and `builtInFitCheck`. Coverage proves the custom control is not a built-in replacement, uses kit chrome, keeps only necessary UI, writes through runtime state, and changes product output; the fit check proves which built-ins were considered and why the custom interaction is necessary. Custom interactions also bind `interactionId` so surface ownership is validated independently from built-in fit.
 
-Performance browser tests pass `scenarioId` to protected measurement/interaction helpers and await `expectToolcraftScenarioPerformanceBudget(..., appPerformance, scenarioId)`. Every mutating measurement supplies `observeOutcome`; generic change evidence first proves a stable baseline and then requires the product outcome to remain different through the stability window. Autonomous products use `expectedOutcome` with a stable semantic observation or measure at a deterministic fixed phase. Latency ends at that expected result, never at an incidental animation frame. Scalar fixtures provide both `applyValue` and `observeValue`; object fixtures provide both functions for every exact fixture key, and the observed value must equal the declared fixture before measurement. Measurement results are immutable and branded to one scenario, so another scenario or a mutable literal cannot satisfy the gate. The reporter requires matching measurement, budget, fixture, interaction/completion, and product-outcome evidence for each typed scenario. Do not hardcode budget numbers, toy values, or toy baseline app states; `app-performance.ts` is the single source of truth.
+Performance browser tests use the derived path matrix. Each path has one browser adapter, compiled development and maximum fixtures, a centrally profiled budget, and protected measurement evidence bound to the same `pathId`. Every mutating measurement supplies `observeOutcome`; generic change evidence first proves a stable baseline and then requires the product outcome to remain different through the stability window. Autonomous products use `expectedOutcome` with a stable semantic observation or measure at a deterministic fixed phase. Latency ends at that expected result, never at an incidental animation frame. Fixture adapters apply and observe every compiled dimension exactly before measurement. The reporter requires matching path, fixture phase, product outcome, measurement, pipeline, completion/interaction, and budget evidence. Do not hardcode budget numbers, toy values, or toy baseline app states; `app-performance.ts`, the runtime profile catalog, and derived paths are the authoritative inputs.
 
 ## Fixtures
 

package/templates/starter/docs/toolcraft/agent-worklog.md

@@ -8,26 +8,113 @@ Mode: starter
 
 The neutral starter has no product renderer, timeline, layers, export behavior, or performance workload yet. Replace this status with `Mode: product` when the folder becomes a real app.
 
+## Automatic Delivery Lifecycle
+
+Keep this worklog human-shaped. For the first product delivery, record the request, decisions, state/output mapping, reference evidence, rejected alternatives, and known risks; one bare `pnpm verify:delivery` derives complete contract proof, one build, full functional acceptance, and no measured performance. For later `functional-targeted` delivery, record only the new intent and decisions; the same bare command derives exact ownership-required proof from protected state.
+
+Classifier output establishes complaint authority only and never path localization. A localized performance complaint adds the domain authority below, then one bare `pnpm verify:delivery` runs one targeted iteration. If localization remains unresolved regardless of classifier result, ask one user-facing question naming visible operations and offering targeted diagnosis or a complete review; record neither `performance-iteration` intent nor canonical path authority until the answer supplies exact localization evidence. Never ask the user to choose internal path IDs. A broad or honestly unlocalizable problem may present that single choice with a recommendation for complete review, but the user still chooses. A direct complete-review request needs no further clarification. The full audit remains separate and requires an explicit operator request or accepted offer before `pnpm verify:perf` may run. Protected receipts own changed files, plans, checks, reports, measurements, and pass/fail evidence.
+
+When `canvas.renderScale` is enabled, record the renderer decision to preserve selected backing quality and map it to functional `renderScaleCoverage` for interaction and steady state, plus playback when timeline is enabled. The worklog may name the protected `canvas-render-scale-backing` recipe, but it cannot claim its evidence or turn a quality failure into performance authority.
+
+## Performance Iteration Entry Contract
+
+For high-confidence ordinary work, record `Performance intent: ordinary-product-work`. For unresolved localization, whether classification returned high-confidence `performance-iteration` or `needs-agent-judgment`, record the unresolved visible operation but no `Performance intent: performance-iteration` field or `Performance paths` until the user's one clarification provides exact localization. For a localized performance complaint or post-clarification targeted choice, record exactly these domain fields in the latest iteration:
+
+```md
+- Performance intent: performance-iteration
+- Performance request evidence: "<verbatim exact Request quote>"
+- Performance paths: ["performance-path:%5B...%5D"]
+- Verification: One bare `pnpm verify:delivery` will derive and run the protected proof.
+```
+
+The quoted evidence must be an exact nontrivial raw substring of `Request` with identical whitespace and Unicode code units. `Performance paths` must be a non-empty unique JSON array of canonical path IDs. Do not record command arguments, changed-file inventory, executed checks, reports, or measurements; the protected planner and receipt own that machine evidence. Each localized complaint or post-clarification targeted choice authorizes one bounded iteration; after it passes, return the app and wait for user evaluation. Classifier output or complaint evidence alone never supplies path localization or authorizes full certification. The separate operator command is permitted only after the user explicitly requests a complete audit or explicitly accepts the agent's offer; the user does not need to name the command.
+
 ## Decision Trail
 
-No product iterations yet. When this folder becomes a product, replace this note with iteration entries:
-
-### Iteration 1 — <short task name>
-
-- Request:
-- Task type:
-- User-visible result:
-- Source/reference checked:
-- Reference inputs:
-- Docs/contracts read:
-- Contract rules applied:
-- Decision:
-- Alternatives rejected:
-- State/output mapping:
-- Files changed:
-- Verification:
-- Skipped checks:
-- Risks:
+### Iteration 1 — Model appearance and presentation runtime contract
+
+- Request: Preserve authored model materials and textures from folders or ZIP packages, use a Blender-like fallback only when authored appearance is absent, render the result on the canvas, and keep direct orbit synchronized with the orientation gizmo.
+- Task type: Runtime, starter, contract, CLI, and generated-app delivery.
+- User-visible result: GLB/glTF/OBJ/FBX/PLY/STL imports now retain the supported authored appearance subset, folder and ZIP resources remain durable, missing appearance resources surface typed warnings, and materialless geometry uses the canonical fallback. Runtime preview keeps one presentation lease and one camera pose for canvas rendering, direct model drag, gizmo snap, history, reset, and export.
+- Source/reference checked: `/Users/kusnizza/Projects/toolcraft-apps/rain-drops`, the production model adapters, canonical document codecs, binary repository reachability, runtime canvas/model presentation, and generated-app browser evidence.
+- Reference inputs: The user selected preservation for both folder and ZIP imports, fallback only when authored material is absent, and the current Toolcraft application contract as the source of truth.
+- Docs/contracts read: `core/runtime-boundary.md`, `core/media-upload.md`, `core/performance.md`, `renderer-technique.md`, `acceptance-testing.md`, and the runtime decision/component contracts.
+- Contract rules applied: `canvas-surface-preserved`, `interaction-surface-ownership`, `renderer-view-interaction`, `renderer-technique-inventory`, `acceptance-product-observable`, `performance-coverage-levels`, and `persistence-policy-explicit`.
+- View interaction intent: A visible editable model uses `orbit`; runtime canvas drag and `orientationGizmo` consume the same orientation target without mutating canonical source data.
+- Interaction ownership: Canvas owns direct spatial orbit and gizmo snap. The panel owns source package selection, status, warning, repair, and removal actions.
+- Decision: Preserve immutable source packages and canonical appearance data; build a disposable Three.js projection with bounded batching/deduplication only for pixel-equivalent opaque geometry. Retain the renderer prewarm resource across remove/reimport and dispose it with the owning presentation host.
+- Alternatives rejected: Product-owned model loaders, remote texture fallback, storing Three.js objects in state, appearance-driven topology repair, duplicate standard/custom presentation owners, and metadata-only browser evidence.
+- State/output mapping: Durable package refs and canonical document refs live in runtime media state; resolved appearance resources feed a shared presentation lease; evaluated orientation state feeds preview, hit testing, gizmo, history/reset, and export.
+- Performance intent: ordinary-product-work
+- Verification: One bare `pnpm verify:delivery` will derive and run the protected proof.
+- Risks: The canonical contract intentionally covers static geometry and the documented PBR subset; unsupported skins, morph targets, animation clips, texture transforms, or missing resources remain nonfatal diagnostics when possible. Synthetic browser fixtures prove contract behavior but cannot guarantee every malformed third-party exporter file.
+
+### Iteration 2 — Infinity canvas runtime and scene-cropped export
+
+- Request: Add an `Infinity canvas` toggle to the first Project Settings section; when enabled, remove canvas size controls and artboard limits, use the whole workspace, and export a crop around scene elements.
+- Task type: Runtime, canvas, export, acceptance, starter contract, documentation, CLI, and generated-app delivery.
+- User-visible result: Project Settings now starts with `Infinity canvas`. Enabling it removes aspect ratio, width, and height controls plus the finite artboard boundary; disabling it restores the exact previous finite dimensions. Image export remains full-artboard in finite mode and crops to visible scene bounds in infinite mode.
+- Source/reference checked: Current Toolcraft canvas state, canvas viewport, image/model presentation, panel action boundary, generated product fixture, export pipeline, and the user-approved crop behavior.
+- Reference inputs: The user explicitly selected an unrestricted infinite workspace, preservation of the current finite size, and export by the outer scene-element bounds.
+- Docs/contracts read: `core/setup-export.md`, `core/runtime-boundary.md`, `acceptance-testing.md`, `schema-reference.md`, and the runtime decision/component contracts.
+- Contract rules applied: `canvas-surface-preserved`, `controls-product-coverage`, `output-export-required`, `acceptance-product-observable`, and `infinity-canvas-scene-bounds`.
+- View interaction intent: Infinity mode changes the canvas extent only; existing product `viewInteraction` and model orbit/gizmo ownership remain unchanged.
+- Interaction ownership: Project Settings owns the finite/infinite mode. The canvas owns navigation across the unbounded workspace. Export actions consume canonical scene bounds without adding a second editing surface.
+- Decision: Store the mode in canonical runtime state and history; retain finite dimensions while infinite; give runtime images and models explicit world frames; accept product bounds through the signed composition boundary; union only visible exportable entities; and reject empty, unavailable, or oversized scene exports with typed visible feedback.
+- Alternatives rejected: Encoding Infinity as a sentinel width/height, deriving bounds from DOM pixels, always calling product bounds in finite mode, exporting the current viewport, retaining hidden/editor-only entities, and an implicit global bounds registry.
+- State/output mapping: `canvas.setMode` drives settings visibility and artboard layout. Runtime image/model frames and `sceneBoundsProvider` feed one canonical resolver. Image and model compositors render the resolved scene frame at export scale; video exporters must resolve a bound over their explicit time range.
+- Performance intent: ordinary-product-work
+- Verification: One bare `pnpm verify:delivery` will derive and run the protected proof.
+- Risks: Product-owned visual entities must provide truthful bounds through `sceneBoundsProvider`; the runtime fails closed with `scene-bounds-unavailable` instead of silently cropping them out.
+
+### Iteration 3 — Grass controls-panel section navigation parity
+
+- Request: "возьми механику навигации по секциям панели из этого проекта. перенеси полностью дизайн и поведение в стартер. панель появляется когда секции не влезают в высоту одного экрана"
+- Task type: Shared runtime, controls-panel interaction, generated browser evidence, starter documentation, and standalone generation.
+- User-visible result: Generated Toolcraft apps use the Grass section-navigation popup only while the controls body overflows its available viewport. A fitting panel cannot reveal the popup; losing overflow clears pending hover intent, and restoring overflow requires a fresh 300ms dwell.
+- Source/reference checked: `/Users/kusnizza/Projects/toolcraft-apps/grass`, its generated runtime copy, the live app at `http://127.0.0.1:3003/`, canonical runtime/UI sources, and computed popup geometry and typography.
+- Reference inputs: The user selected full Grass design and behavior, with navigation eligibility determined by sections not fitting within one screen height.
+- Docs/contracts read: `component-rules.md`, `workflow.md`, `acceptance-testing.md`, and the runtime panel component contract.
+- Contract rules applied: `panel-host-behavior`, `controls-component-layout-invariants`, `controls-layout-heuristics`, and `acceptance-product-observable`.
+- Interaction ownership: The runtime controls panel owns overflow measurement, hover intent, section scroll-spy, and popup navigation. Product code supplies sections only and cannot render a duplicate navigation surface.
+- Decision: Keep one runtime implementation, retain the complete Grass surface, spacing, type, scrolling, pointer corridor, timing, click, and keyboard behavior, and reset every pending popup timer when overflow disappears.
+- Alternatives rejected: Copying the component into starter product code, retaining navigation state after overflow disappears, showing navigation persistently, and editing the exported Grass folder instead of the source runtime.
+- State/output mapping: `scrollHeight > clientHeight + 1` makes navigation eligible; a 300ms dwell in the inner-left 12px strip mounts the runtime popup; its items map visible non-sticky sections to immediate viewport scroll positions.
+- Performance intent: ordinary-product-work
+- Verification: One bare `pnpm verify:delivery` will derive and run the protected proof.
+- Risks: Already-exported applications retain their copied runtime until regenerated; the Grass reference remains unchanged.
+
+### Iteration 4 — Runtime history keyboard shortcuts from focused controls
+
+- Request: Make Undo and Redo work through standard keyboard shortcuts in generated apps.
+- Task type: Shared runtime, generated keyboard interaction, contract, and standalone browser evidence.
+- User-visible result: Cmd/Ctrl+Z, Cmd/Ctrl+Shift+Z, and Ctrl+Y operate Toolcraft history while focus remains on sliders, switches, checkboxes, and other non-text controls; active text editors keep native text undo.
+- Source/reference checked: The runtime ToolcraftRoot shortcut listener, its unit tests, and a built standalone app where the focused Blur slider input reproduced the failure.
+- Contract rules applied: `runtime-shell-required`, `interaction-surface-ownership`, `acceptance-product-observable`, and `workflow-required`.
+- Interaction ownership: ToolcraftRoot owns one document-level history shortcut listener; product apps do not register duplicates.
+- Decision: Classify input targets by native text-editing capability instead of treating every input as a text editor.
+- Alternatives rejected: Always stealing text undo, per-control marker attributes, and app-local shortcut listeners.
+- State/output mapping: Recognized shortcuts dispatch `history.undo`/`history.redo` through the runtime command bus; native text editors return before dispatch.
+- Performance intent: ordinary-product-work
+- Verification: One bare `pnpm verify:delivery` will derive and run the protected proof.
+- Risks: Previously exported apps retain their copied runtime until regenerated; newly generated apps receive the fix through the CLI copy path.
+
+### Iteration 5 — Blender-compatible orientation gizmo interaction
+
+- Request: Make the orientation gizmo behave "все как в блендере": click signed points to return to axes and drag the gizmo with Blender-equivalent rotation.
+- Task type: Shared runtime interaction, generated browser evidence, starter contract, and website documentation.
+- User-visible result: The existing 70px Toolcraft gizmo keeps its size, colors, hover treatment, and 16px placement. Users can now drag anywhere inside its circular surface; gizmo and direct model drag share Blender factory Turntable sensitivity and pole recovery; signed-axis clicks use Blender Smooth View timing.
+- Source/reference checked: Blender 4.5.2 LTS factory preferences plus the official navigation gizmo, view rotate, axis view, and smooth-view source. Factory Turntable sensitivity is 0.4 degrees per CSS pixel and Smooth View is 200ms maximum, scaled by quaternion angle.
+- Contract rules applied: `canvas-handle-placement`, `interaction-surface-ownership`, `renderer-view-interaction`, `acceptance-product-observable`, `performance-coverage-levels`, and `workflow-required`.
+- View interaction intent: A visible editable spatial model remains `orbit`; the runtime gizmo and visible-model hit surface consume one canonical `{ position, up }` target.
+- Interaction ownership: An unmodified primary press inside the gizmo circle owns Turntable drag; a signed endpoint also owns click-to-axis; blank click is inert; outside-circle and model-miss presses remain canvas pan.
+- Decision: Map Blender Z-up behavior to Toolcraft Y-up, use fixed world-up yaw plus screen-horizontal pitch with Blender's pole horizon blend, keep a 3px click/drag threshold, and use cubic smoothstep quaternion slerp with `200ms * angle / pi` duration.
+- Alternatives rejected: Keeping endpoint-only sphere projection, changing only gizmo math while direct model drag remains viewport-scaled, and adopting a Three.js helper that owns a separate camera/controller.
+- Licensing: This is an independent behavioral and mathematical reimplementation from documented behavior and observed source structure; no Blender GPL source code is copied.
+- State/output mapping: Every drag or snap writes the canonical runtime pose under one history group and target-scoped interaction lease. Preview, hit testing, gizmo projection, reset/undo/redo, persistence, and export continue to consume that pose; stale gestures cannot write after a newer owner.
+- Performance intent: ordinary-product-work
+- Verification: One bare `pnpm verify:delivery` will derive and run the protected proof.
+- Risks: Already-exported applications retain their copied runtime until regenerated. Browser proof relies on the runtime gizmo's canonical pose/target attributes and intentionally fails closed if the real handle is absent or ambiguous.
 
 ## Decisions
 
@@ -35,7 +122,7 @@ No product iterations yet. When this folder becomes a product, replace this note
 
 - Decision: No product renderer yet.
 - Reason: The starter is intentionally neutral.
-- Evidence: No `canvasContent` product renderer is declared.
+- Evidence: No `canvasContent` product renderer is declared. The neutral composition still declares `modelPresentation: { mode: "runtime" }` so future model uploads have one standard owner until a product explicitly declares checked custom consumers.
 
 ### Timeline
 
@@ -55,6 +142,18 @@ No product iterations yet. When this folder becomes a product, replace this note
 - Reason: Controls are added only after the requested product behavior is known.
 - Evidence: The starter schema exposes no product control sections.
 
+### View Interaction
+
+- Decision: No spatial product view yet.
+- Reason: The neutral starter has no visible three-dimensional scene or model.
+- Evidence: Product readiness remains in starter mode; product apps must declare typed `viewInteraction` before controls or renderer code.
+
+### Interaction Ownership
+
+- Decision: No product interaction surfaces yet.
+- Reason: The neutral starter has no canvas handles or product controls to compare.
+- Evidence: Product apps must declare typed `interactionOwnership` before implementing controls or canvas interactions.
+
 ### Export
 
 - Decision: No product export yet.
@@ -70,13 +169,13 @@ No product iterations yet. When this folder becomes a product, replace this note
 ## Evidence
 
 - Source reviewed: neutral starter schema and local Toolcraft docs.
-- Contract applied: starter baseline remains neutral until product behavior exists.
+- Contract applied: starter baseline remains neutral until product behavior exists; `model-appearance-presentation` keeps package import, appearance leases, model canvas output, gizmo pose, and export ownership explicit.
 
 ## Verification
 
-- Run: `pnpm verify:quick` for starter baseline checks.
-- Run: `pnpm verify:final` after turning this folder into a product app.
+Protected receipts own changed files, the derived plan, commands, selectors, reports, measurements, and pass/fail evidence. Decision Trail iterations record only one bare `pnpm verify:delivery` narrative.
 
 ## Risks
 
 - Risk: This template must be replaced with product-specific decisions before final delivery.
+- Risk: A product that selects custom model presentation must mount every declared checked consumer; otherwise runtime reports typed retryable presentation feedback and suppresses only that declared target.

package/templates/starter/docs/toolcraft/assembly-workflow.md

@@ -25,7 +25,7 @@ export const appComposition = {
 } satisfies ToolcraftAppComposition;
 ```
 
-Edit `src/app/app-composition.tsx`, not the signed route. Product composition may provide only `schema`, `canvasContent`, `controlRenderers`, `onPanelAction`, and `renderDefaultCanvasMedia`; the protected route owns `className` and other host layout. Do not compose `ToolcraftRoot`, `CanvasShell`, `ControlsPanel`, `LayersPanel`, `TimelinePanel`, or `ToolbarPanel` by hand. If a runtime surface has a performance or behavior issue, fix the shared runtime instead of replacing the surface locally.
+Edit `src/app/app-composition.tsx`, not the signed route. Product composition may provide only `schema`, `canvasContent`, `controlRenderers`, `exportRenderer`, `modelPresentation`, `onPanelAction`, `renderDefaultCanvasMedia`, and optional `rendererPipelineRegistration`; the protected route owns `className` and other host layout. Model products default to `modelPresentation: { mode: "runtime" }`. Custom presentation declares checked consumers and suppresses only their model targets; `renderDefaultCanvasMedia={false}` affects generic image/file preview, not runtime models. Do not compose `ToolcraftRoot`, `CanvasShell`, `ControlsPanel`, `LayersPanel`, `TimelinePanel`, or `ToolbarPanel` by hand. If a runtime surface has a performance or behavior issue, fix the shared runtime instead of replacing the surface locally.
 
 Supporting product modules may be organized anywhere under `src`; there is no folder allowlist. The product boundary follows all product production files and rejects host/runtime surface imports, built-in control imports/re-exports, dynamic bypasses, and production dependencies on test/spec modules.
 
@@ -36,7 +36,9 @@ Allowed app extension points:
 | Schema controls | Built-in controls, targets, defaults, visibility, panel actions. |
 | `canvasContent` | Product output only. |
 | `controlRenderers` | True custom controls only after the built-in fit check. |
-| `onPanelAction` | Sticky footer product actions. |
+| `exportRenderer` | One deterministic scene-coordinate product frame shared by runtime image and video export. |
+| `onPanelAction` | Non-export sticky footer product actions. |
+| `rendererPipelineRegistration` | One compiled executable pipeline shared by render work, actions, evidence, and new-envelope assessment. |
 | Runtime commands/hooks | History, media, canvas, timeline, layers, and controlled app behavior. |
 
 Do not render built-in controls such as `SliderControl`, `SelectControl`, `ColorControl`, `GradientControl`, `FontPickerControl`, `FileDropControl`, or `PanelActionsControl` directly in app code. Declare them in schema so layout, reset, history, visibility, keyframes, labels, and tests stay runtime-owned.
@@ -49,13 +51,28 @@ Once the folder is a real product, switch `src/app/app-acceptance-data.ts` from
 
 ```ts
 export const appProductReadiness = {
+  interactionOwnership: [],
   mode: "product",
   productName: "Product name",
   productSummary: "What the app creates or edits.",
   requestedBehavior: "The user-facing behavior this app must implement.",
+  viewInteraction: {
+    mode: "non-spatial",
+    reason: "This product has no visible three-dimensional scene or model.",
+  },
 } as const;
 ```
 
+Populate `interactionOwnership` before adding canvas handles or custom
+interactions. One operation has one primary `canvas` or `panel` surface chosen
+from user request, inspected reference, or product usability evidence. Different
+operations may share related state across surfaces; mirrored operations may not.
+
+Use `viewInteraction.mode: "orbit"` for a visible editable spatial scene and
+list its `orientationGizmo` targets. `fixed-camera` or `timeline-camera` require
+explicit request/reference evidence; do not infer fixed framing merely because
+the prompt did not separately request rotation.
+
 ## Controls
 
 Before writing product sections, export `starterControlSectionInventory`. Each product section declares its title, targets, product entity or workflow stage, and grouping reason.
@@ -88,26 +105,26 @@ Use `core/timeline-animation.md` for timeline mode, compact/extended timeline, s
 
 ## Renderer Work
 
-For custom renderers, write the Renderer Technique Decision Matrix and Render Pipeline Inventory before code. The implementation plan maps every performance-sensitive control to the render pass it invalidates.
+For custom renderers, write the Renderer Technique Decision Matrix and typed performance model before code. Follow one sequence: reachable controls and inputs; workload dimensions and enforced boundaries; pass cost, frequency, lifecycle, and invalidation; render-plan assessment and protected kernel benchmark when required; derived paths and combined fixtures; impact-derived functional/browser development checks; lifecycle-appropriate delivery proof. Only exact request authority may add measured targeted performance.
 
-Use `renderer-technique.md` and `core/performance.md` for renderer strategy, cache keys, workload fixtures, render scale, and optimization evidence.
+Compile one lightweight renderer pipeline registration outside test modules. Supply that exact registration as `rendererPipelineRegistration` in the composition and as `rendererPipeline` to new-envelope performance assessment. Run `assessToolcraftRenderPlan` before implementing the renderer. Derive path ids from the assessed registration and compile workload fixtures from those paths; do not classify workload by target names or author scenario-specific maxima. Renderer work uses `useToolcraftPipelinePass`; retained resources are available only from its generation-bound pass execution context. Product code never receives runtime disposal ownership.
 
-## Verification Tiers
+Use `renderer-technique.md`, `core/performance.md`, and `performance.md` for renderer strategy, envelope dimensions, pass metadata, adapters, derived paths, render scale, and optimization evidence.
 
-Before every edit, classify blast radius and record the planned checks:
+## Automatic Delivery Lifecycle
 
-```md
-Verification tier: Tier N
-Reason: <changed surface and expected blast radius>
-Run: <commands and browser checks>
-Skip: <checks not needed for this pass and why>
-```
+Use one normal sequence: assemble or change the product, gather focused functional feedback, finish the coherent delivery batch, run protected functional delivery once, and return the app for user evaluation. Focused checks while implementation is changing do not mint delivery evidence.
+
+1. First product delivery uses bare `pnpm verify:delivery` for complete product contracts, one production build, full functional acceptance, and no measured performance.
+2. Later `functional-targeted` delivery uses the same bare command for exact ownership-derived functional proof relative to the immediately previous successful delivery.
+3. Classifier output establishes complaint authority only and never path localization. Only a localized complaint or a post-clarification targeted choice records an exact request quote and canonical affected path IDs in the worklog, then one bare delivery runs one targeted iteration and returns the app for evaluation. Unresolved localization creates neither performance-iteration intent nor canonical path authority regardless of classifier result.
+4. A full audit requires an explicit operator request or accepted offer; only then run `pnpm verify:perf` for one fresh build and the complete maximum-fixture performance matrix.
 
-Use `pnpm verify:ui` when browser acceptance is required without the performance suite. Run `pnpm verify:final` for first working product delivery, folder export, runtime/template/contract/CLI changes, broad refactors, and final gates. Full performance checkpoints run only for the first working product version or explicit performance complaints; otherwise run targeted performance checks only for touched paths.
+Protected receipts own changed files, the derived plan, executed checks, reports, measurements, and pass/fail evidence. The worklog keeps product intent and decisions.
 
 For final delivery, run:
 
 ```bash
-pnpm verify:final
+pnpm verify:delivery
 pnpm dev
 ```