@pixel-point/toolcraft 0.0.16 → 0.0.17

package/templates/runtime/schema/schema-resolvers.ts

@@ -18,14 +18,6 @@ export const defaultToolcraftCanvasSize = {
   width: 1920,
 } satisfies ToolcraftCanvasSize;
 
-const defaultCanvasRenderScale = {
-  defaultValue: 2,
-  enabled: false,
-  max: 2,
-  min: 1,
-  step: 0.25,
-} satisfies ResolvedToolcraftAppSchema["canvas"]["renderScale"];
-
 export function resolveToolcraftCanvasSizing(
   canvas: ToolcraftAppSchema["canvas"],
 ): ToolcraftCanvasSizingSchema {
@@ -44,54 +36,6 @@ export function resolveToolcraftCanvasSizing(
   return { mode: "intrinsic-media" };
 }
 
-function clampCanvasRenderScale(value: number | undefined, fallback: number): number {
-  if (typeof value !== "number" || !Number.isFinite(value)) {
-    return fallback;
-  }
-
-  return Math.max(1, Math.min(2, value));
-}
-
-export function resolveToolcraftCanvasRenderScale(
-  renderScale: ToolcraftAppSchema["canvas"]["renderScale"],
-): ResolvedToolcraftAppSchema["canvas"]["renderScale"] {
-  if (renderScale === true) {
-    return {
-      ...defaultCanvasRenderScale,
-      enabled: true,
-    };
-  }
-
-  if (!renderScale) {
-    return defaultCanvasRenderScale;
-  }
-
-  const min = clampCanvasRenderScale(renderScale.min, defaultCanvasRenderScale.min);
-  const max = Math.max(
-    min,
-    clampCanvasRenderScale(renderScale.max, defaultCanvasRenderScale.max),
-  );
-  const step =
-    typeof renderScale.step === "number" && Number.isFinite(renderScale.step)
-      ? Math.max(0.01, Math.min(1, renderScale.step))
-      : defaultCanvasRenderScale.step;
-  const defaultValue = Math.max(
-    min,
-    Math.min(
-      max,
-      clampCanvasRenderScale(renderScale.defaultValue, defaultCanvasRenderScale.defaultValue),
-    ),
-  );
-
-  return {
-    defaultValue,
-    enabled: renderScale.enabled ?? true,
-    max,
-    min,
-    step,
-  };
-}
-
 export function resolveToolcraftExport(
   exportSchema: ToolcraftAppSchema["export"],
 ): ResolvedToolcraftAppSchema["export"] {

package/templates/runtime/schema/types.ts

@@ -40,10 +40,10 @@ export type ToolcraftCanvasSizingSchema =
 export type ToolcraftCanvasRenderScaleSchema =
   | boolean
   | {
-      defaultValue?: number;
-      enabled?: boolean;
-      max?: number;
-      min?: number;
+      defaultValue?: never;
+      enabled?: never;
+      max?: never;
+      min?: never;
       step?: number;
     };
 

package/templates/runtime/state/canvas-background-state.ts

@@ -64,6 +64,12 @@ export function getToolcraftInfiniteCanvasBackgroundColor(
     return undefined;
   }
 
+  return getToolcraftRuntimeBackgroundColor(state);
+}
+
+export function getToolcraftRuntimeBackgroundColor(
+  state: ToolcraftState,
+): string | undefined {
   const background = getToolcraftRuntimeSetupBackgroundControls(state.schema);
   const value = background
     ? state.values[background.color.target] ?? background.color.defaultValue

package/templates/runtime/testing/performance-render-plan-integration.test.ts

@@ -34,6 +34,70 @@ describe("Toolcraft render plan integration", () => {
     );
   });
 
+  it("allows off-main retina rasterization to preserve exact backing during viewport zoom", () => {
+    const pass = createPass({
+      cacheKey: undefined,
+      cost: {
+        dimensions: ["output-units"],
+        frequency: "interaction",
+        relationship: "linear",
+      },
+      id: "viewport-raster",
+      inputs: ["canvas.viewport.zoom"],
+      invalidatedBy: ["canvas.viewport.zoom"],
+      kind: "rasterize",
+      lifecycle: { cache: "none", resourceScope: "interaction" },
+      quality: "retina",
+      runsOn: "worker",
+    });
+    const baseConfig = createEnvelopeConfig({ pass });
+    const rendererPipeline = {
+      ...baseConfig.rendererPipeline!,
+      interactionInvalidation: [
+        {
+          interaction: "viewport-zoom" as const,
+          invalidates: [pass.id],
+          targets: ["canvas.viewport.zoom"],
+        },
+      ],
+    };
+    const renderScaleSchema = {
+      ...testSchema,
+      canvas: {
+        ...testSchema.canvas,
+        renderScale: { ...testSchema.canvas.renderScale, enabled: true },
+      },
+    };
+    const errors = validateToolcraftPerformanceCoverage(
+      renderScaleSchema,
+      { ...baseConfig, rendererPipeline },
+      TOOLCRAFT_FUNCTIONAL_PERFORMANCE_COVERAGE_POLICY,
+    );
+
+    expect(errors).not.toContainEqual(
+      expect.stringContaining(
+        'viewport-zoom must not invalidate expensive pass "viewport-raster"',
+      ),
+    );
+    expect(
+      validateToolcraftPerformanceCoverage(
+        renderScaleSchema,
+        {
+          ...baseConfig,
+          rendererPipeline: {
+            ...rendererPipeline,
+            passes: [{ ...pass, quality: "full" }],
+          },
+        },
+        TOOLCRAFT_FUNCTIONAL_PERFORMANCE_COVERAGE_POLICY,
+      ),
+    ).toContainEqual(
+      expect.stringContaining(
+        'viewport-zoom must not invalidate expensive pass "viewport-raster"',
+      ),
+    );
+  });
+
   it.each(["memoized", "retained-resource"] as const)(
     "requires cacheKey for a composite pass with %s cache",
     (cache) => {

package/templates/runtime/testing/performance-renderer-pipeline-validation.ts

@@ -106,6 +106,22 @@ function hasPipelineReference(value: string): boolean {
   return value.trim().length > 0 && !vaguePipelineReferencePattern.test(value.trim());
 }
 
+function isRetinaViewportZoomRaster(
+  schema: ResolvedToolcraftAppSchema,
+  interaction: ToolcraftPipelineInteraction,
+  pass: ToolcraftRenderPass,
+): boolean {
+  return (
+    interaction === "viewport-zoom" &&
+    schema.canvas.renderScale.enabled &&
+    pass.kind === "rasterize" &&
+    pass.quality === "retina" &&
+    (pass.runsOn === "worker" ||
+      pass.runsOn === "gpu" ||
+      pass.runsOn === "worker-or-gpu")
+  );
+}
+
 function getPipelineReferenceErrors(
   passId: string,
   field: string,
@@ -317,7 +333,8 @@ function getRendererPipelineErrorsFromParsedPipeline(
 
       if (
         highFrequencyViewportInteractions.has(invalidation.interaction) &&
-        expensiveRenderPassKinds.has(pass.kind)
+        expensiveRenderPassKinds.has(pass.kind) &&
+        !isRetinaViewportZoomRaster(schema, invalidation.interaction, pass)
       ) {
         errors.push(
           `rendererPipeline ${invalidation.interaction} must not invalidate expensive pass "${passId}" (${pass.kind}). Move viewport work to transforms/uniforms or explain it through a cheaper pass.`,

package/templates/starter/AGENTS.md

@@ -33,7 +33,7 @@ Process matching routes sequentially within the current phase and skip repeated
 13. Generated apps follow the mandatory runtime Setup, Infinity canvas/finite canvas sizing, render scale, Timeline switch, Background, Image Export, Video Export, and sticky action rules in `docs/toolcraft/core/setup-export.md`. Do not duplicate or reinterpret those controls in app-authored sections.
 14. Media uploads, image/file mode, source images, multi-upload sorting, default assets, and image transform actions follow `docs/toolcraft/core/media-upload.md`.
 15. Keep `docs/toolcraft/agent-worklog.md` current with a decision trail, product decisions, explicit reference inputs, evidence, verification, and risks. Reference-runtime-clone apps also declare `referenceStudy` plus `referenceFeatureInventory` so every inspected reference feature has feature-level behavior evidence and maps to Toolcraft implementation and acceptance coverage.
-16. Prove every visible entity through acceptance, browser, and performance coverage. Browser acceptance and performance pass only when protected helpers emit matching runtime evidence after successful assertions; source-code spelling and acceptance prose are not outcome authority. Declare typed conditional-visibility and background-output coverage, then use their fixed protected browser recipes. Raster products with `canvas.renderScale` declare `renderScaleCoverage` for interaction and steady state, plus playback when timeline is enabled, and prove real backing pixels with `canvas-render-scale-backing`; clamping quality is a functional failure without measured performance. Generic acceptance outcomes prove command side effects only; use the fixed media, persistence, viewport, compound-control, layer, and timeline semantic recipes for specialized evidence.
+16. Prove every visible entity through acceptance, browser, and performance coverage. Browser acceptance and performance pass only when protected helpers emit matching runtime evidence after successful assertions; source-code spelling and acceptance prose are not outcome authority. Declare typed conditional-visibility and background-output coverage, then use their fixed protected browser recipes. Raster products with `canvas.renderScale` declare `renderScaleCoverage` for interaction and steady state, plus playback when timeline is enabled, and prove real backing pixels with `canvas-render-scale-backing`; clamping quality is a functional failure without measured performance. Every measured path in a render-scale-enabled raster product proves actual CSS × devicePixelRatio × 2 backing after each measured phase. Generic acceptance outcomes prove command side effects only; use the fixed media, persistence, viewport, compound-control, layer, and timeline semantic recipes for specialized evidence.
 17. Performance planning follows 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; targeted functional/browser development checks; lifecycle-appropriate delivery proof. Keep `src/app/app-verification-impact.json` complete so later functional changes derive exact verification scope. Only exact request authority may create a measured targeted performance iteration. Details live in `docs/toolcraft/core/performance.md` and `docs/toolcraft/performance.md`.
 18. Custom renderer apps compile one canonical `rendererPipelineRegistration`, supply it through `ToolcraftAppComposition`, reuse that registration as `rendererPipeline` in performance assessment, and derive paths and fixtures from it. The neutral starter has no registration, runtime provider, or fixture adapters.
 19. Classify each coherent user-visible delivery batch with a verification tier before editing. Steering and fixes inside the same request stay in that batch. Use targeted checks for development feedback, then run the protected delivery gate once when the batch is ready.
@@ -119,11 +119,12 @@ These ids mirror `TOOLCRAFT_DECISION_CONTRACT` in `@/toolcraft/runtime`. Keep th
 
 - Use `defineToolcraft` from `@/toolcraft/runtime`.
 - Export an `appComposition` satisfying `ToolcraftAppComposition` from `src/app/app-composition.tsx`.
-- Keep product composition limited to `schema`, `canvasContent`, `controlRenderers`, `modelPresentation`, `onPanelAction`, `renderDefaultCanvasMedia`, and optional `rendererPipelineRegistration`; host `className` and `style` are not product extension points.
+- Keep product composition limited to `schema`, `canvasContent`, `controlRenderers`, `exportRenderer`, `modelPresentation`, `onPanelAction`, `renderDefaultCanvasMedia`, and optional `rendererPipelineRegistration`; host `className` and `style` are not product extension points.
 - Custom renderers use one compiled `rendererPipelineRegistration` as the canonical declaration for runtime execution and new-envelope performance assessment. Product code receives only the disposal-free pipeline client through hooks and panel action context.
 - Do not import `ToolcraftApp`, low-level runtime surfaces, or built-in controls into product modules. The signed host renders the shell; product modules use schema controls and supported composition fields.
 - Use `renderDefaultCanvasMedia={false}` when a custom renderer replaces generic image/file preview. This flag does not suppress runtime model layers; use typed `modelPresentation` custom mode with checked consumers for declared model targets.
-- Use `ToolcraftApp onPanelAction` for sticky footer product actions such as Generate, Apply, Export, Copy, or Download.
+- Use `ToolcraftApp onPanelAction` for non-export sticky footer product actions such as Generate, Apply, Copy, or Download. Typed `export-image` and `export-video` actions are executed by the runtime from the shared `ToolcraftAppComposition.exportRenderer`.
+- Product export renderers draw one deterministic scene-coordinate frame and return/await their real work. Product modules never allocate export canvases, choose encoders, encode blobs, create download URLs, or duplicate image/video composition.
 - Keep final app behavior in the schema and runtime command bus, not in isolated local control state.
 - For animated products, write an Animation Intent Inventory before coding: use top playback timeline for product transport, keyframes timeline for editable property animation, and no timeline only for explicitly autonomous decorative output with no video export. Any app with `Export Video` must enable the top Toolcraft timeline.
 - For keyframes timeline apps, renderers read keyframed settings through Toolcraft evaluated-value helpers/hooks. Do not parse timeline `valueLabel` strings or read raw `state.values` for keyframed targets.
@@ -172,7 +173,7 @@ Do not rerun `pnpm install` after every edit. Run it after fresh export, depende
 
 Do not run the full browser performance suite for Tier 0-2 edits.
 
-The automatic lifecycle is sequential. First product delivery uses bare `pnpm verify:delivery` for complete product contracts, one production build, full functional acceptance, and zero measured performance. Later delivery is functional-targeted: it compares the immediately previous and current semantic functional proof models and derives exact direct-owner, domain, and affected-unit-graph proof. A performance complaint may authorize one targeted iteration; a full audit remains explicit-only. The canonical selection and evidence rules live in `docs/toolcraft/workflow.md`, `docs/toolcraft/acceptance-testing.md`, and `docs/toolcraft/performance.md`; do not duplicate their algorithm here.
+The automatic lifecycle is sequential. First product delivery uses bare `pnpm verify:delivery` for complete product contracts, one production build, full functional acceptance, and zero measured performance. Later delivery is functional-targeted: it compares the immediately previous and current semantic functional proof models and derives exact direct-owner, domain, and affected-unit-graph proof. Classifier output establishes complaint authority only, never path localization. For a localized performance complaint, select affected canonical paths and run one targeted iteration without clarification. When localization remains unresolved, regardless of whether classification is high-confidence `performance-iteration` or `needs-agent-judgment`, ask one user-facing question naming visible operations and offering targeted diagnosis or a complete review; unresolved localization creates neither performance-iteration intent nor canonical path authority, and internal path IDs are never user choices. A broad or unlocalizable problem may justify recommending the complete review in that single choice, but the user still chooses; an explicit complete-review request runs `pnpm verify:perf` directly. The canonical selection and evidence rules live in `docs/toolcraft/workflow.md`, `docs/toolcraft/acceptance-testing.md`, and `docs/toolcraft/performance.md`; do not duplicate their algorithm here.
 
 Feature loops after the first working version run only the smallest focused functional and browser checks while implementation is changing, then one bare `verify:delivery` at the coherent boundary. Do not rerun aggregate, export, or performance matrices after every edit. An unchanged `sourceHash` uses the protected fast path and does not recollect semantic proof inputs.
 
@@ -187,7 +188,7 @@ pnpm verify:delivery
 pnpm dev
 ```
 
-The protected runner selects first-delivery functional proof, later `functional-targeted` ownership-derived proof, or one complaint-authorized targeted performance iteration from protected state. `pnpm verify:perf` is the separate operator/CI full-audit command; run it only after an explicit user request or accepted agent offer, never as an inferred continuation of a complaint.
+The protected runner selects first-delivery functional proof, later `functional-targeted` ownership-derived proof, or one localized-or-clarified targeted performance iteration from protected state. Classifier output alone never supplies path localization; unresolved localization creates neither performance-iteration intent nor canonical path authority regardless of classifier result. `pnpm verify:perf` is the separate operator/CI full-audit command; run it only after an explicit user request or accepted agent offer, never as an inferred continuation of a complaint.
 
 Use `pnpm install` before this final gate when the folder is fresh or dependencies changed.
 
@@ -207,9 +208,9 @@ The app is complete only when:
 - sticky footer export actions operate on final product output at `state.canvas.size`;
 - every product exposes Export PNG; products whose requested delivery includes animation also expose Export Video;
 - PNG export uses the background controls normalized into runtime Setup: `Background` beside `Infinity canvas`, then `Background color`; live preview hides product background when Background is off, and video keeps background;
-- every PNG export includes `Image Export` format/resolution `select` controls, and passes `export.image.resolution` into `createToolcraftPngExportCanvas`;
+- every PNG export includes `Image Export` format/resolution `select` controls; runtime resolves the selected settings and exact output size;
 - products with both PNG and video export place `Image Export` immediately before `Video Export`;
-- export paths use the standard export helpers: PNG uses selected image resolution or retina fallback, while video uses current canvas/output size or the selected 4K target;
+- one shared `exportRenderer` draws product pixels for both image and video; runtime owns selected settings, scene crop, background, runtime media/model compositing, canvas allocation, encoding, download, progress, and typed errors;
 - layers are absent for single-layer apps and fully working when enabled;
 - timeline is absent, playback, keyframes, or custom reference timeline according to product behavior;
 - performance checks cover workload and responsiveness for all relevant controls;

package/templates/starter/NOTICE.md

@@ -6,3 +6,9 @@ starter, UI component, documentation, and template source code.
 Use of that Toolcraft code is governed by the MIT License in `LICENSE.md`.
 Product-specific design, content, configuration, and application code that you
 create remain yours.
+
+## Mediabunny
+
+Video export uses Mediabunny 1.52.2, Copyright © 2026 Vanilagy,
+licensed under the Mozilla Public License 2.0 (MPL-2.0).
+Source: https://github.com/Vanilagy/mediabunny

package/templates/starter/docs/toolcraft/README.md

@@ -40,7 +40,8 @@ Use focused tests while a coherent user-visible delivery batch is changing. Stee
 
 - **First product delivery:** bare `pnpm verify:delivery` proves complete product contracts, performs one production build, runs full functional acceptance, and runs no measured performance. It preserves any independent performance baseline.
 - **Later functional delivery:** the same bare command compares with the immediately previous successful delivery and derives exact ownership-required proof.
-- **Performance complaint:** record an exact request quote and canonical affected path IDs in the worklog, then run one bare delivery for one targeted iteration and return the verified app for evaluation.
+- **Localized or clarified targeted work:** 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 verified app for evaluation. Unresolved localization creates neither performance-iteration intent nor canonical path authority regardless of classifier result.
+- **Adaptive complaint route:** a localized complaint lets the agent choose affected paths without a question; an ambiguous complaint gets one visible-operation choice between targeted diagnosis and a complete performance review; a broad problem may receive the same recommendation, while only an explicit request or accepted offer authorizes the full review.
 - **Full audit:** only an explicit operator request or accepted offer authorizes `pnpm verify:perf`, which performs one fresh build and the complete maximum-fixture performance matrix.
 
 Use the current AI agent's controlled browser for targeted diagnosis and visual checks.

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

@@ -82,6 +82,8 @@ The `e2e/app-browser-*` prefix is reserved for signed framework specs.
 
 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.
@@ -94,13 +96,13 @@ Slider and range slider rows must prove live behavior. Browser tests should drag
 
 ## Infinity Canvas Coverage
 
-Every editable-output product app proves `infinityCanvasCoverage` mode/restoration. When the standard Background pair exists, the fixed proof also changes Background color, verifies that the complete infinite viewport uses it, turns Background off to prove finite fallback plus a disabled Infinity switch, and turns Background back on to prove availability returns without enabling Infinity. PNG/video apps also prove decoded scene-bounds output (video uses one `timeRange` envelope) from `ToolcraftAppComposition.sceneBoundsProvider`; fixed recipes cover hidden/editor exclusion and exact empty, unavailable, and oversized failure codes. Full recipes live in `core/setup-export.md`.
+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
 
-With `canvas.renderScale: true`, add one browser row on `canvas.renderScale`: `renderScaleCoverage: { kind: "selected-backing-pixels", states: ["interaction", "steady"] }`; timeline uses `["interaction", "playback", "steady"]`.
+For a raster product with render scale, add one `canvas.renderScale` browser row: `renderScaleCoverage: { kind: "selected-backing-pixels", states: ["interaction", "steady"] }`; timeline adds `"playback"`.
 
-Call `expectToolcraftCanvasRenderScaleEvidence` with transitions. It keeps CSS size, asserts backing ≥ `CSS × DPR × scale`, then emits `canvas-render-scale-backing`. A clamp is a functional failure without measured performance.
+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.
 
@@ -230,9 +232,9 @@ Export-content proof is distinct from export mechanics: content inspects selecte
 
 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.
 
@@ -240,7 +242,7 @@ 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 and the complete infinite viewport, turning `export.includeBackground` off through the Setup `Background` switch exits infinite mode, disables Infinity, hides the live preview product background, and creates transparent PNG output; video export still keeps the background, turning Background on restores Infinity availability without enabling it and 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.
 

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

@@ -12,13 +12,13 @@ The neutral starter has no product renderer, timeline, layers, export behavior,
 
 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.
 
-A performance complaint adds only the domain authority below, then one bare `pnpm verify:delivery` runs one targeted iteration. A 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.
+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 a performance complaint or optimization request, record exactly these domain fields in the latest iteration:
+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
@@ -27,7 +27,7 @@ For high-confidence ordinary work, record `Performance intent: ordinary-product-
 - 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. One complaint authorizes one bounded iteration; after it passes, return the app and wait for user evaluation. For `needs-agent-judgment`, read the full request and record the chosen intent. Complaint evidence never 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.
+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
 

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`, `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.
+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,8 @@ 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. |
 
@@ -116,7 +117,7 @@ Use one normal sequence: assemble or change the product, gather focused function
 
 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. A performance complaint records its 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.
+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.
 
 Protected receipts own changed files, the derived plan, executed checks, reports, measurements, and pass/fail evidence. The worklog keeps product intent and decisions.

package/templates/starter/docs/toolcraft/core/media-upload.md

@@ -92,8 +92,8 @@ Read this module before changing image upload, file upload, source material impo
 - A structurally valid staged draft may preview during analysis without replacing committed state.
 - Analyzing and repairing preview opacity is `40%`; committed preview and export opacity is `100%`.
 - Rotatable model products use `orientationGizmo`. Direct drag on model geometry and the gizmo write the same orientation target against the same presentation lease; a canvas miss remains viewport pan. Preview, undo/reset, and export read that shared pose, canonical document reference, and appearance cache key.
-- Product image export creates its normal target canvas, renders product-owned pixels, then awaits `renderModelsToCanvas(exportCanvas)` from `onPanelAction` before encoding or downloading. This composites visible committed model layers at the current canvas size, target pixel ratio, and shared orientation. Do not enumerate model assets or call Three loaders in product export code.
-- Video export must render the same visible models and shared pose through the runtime model binding for every exported frame; it cannot substitute the panel preview or omit model layers.
+- Runtime image/video export composites visible committed model layers at the exact scene frame, output size, pixel ratio, and shared orientation before awaiting the product's shared `exportRenderer` frame. Product code does not enumerate model assets, call Three loaders, invoke model compositors, encode canvases, or download artifacts.
+- Every scheduled video frame uses the same runtime model binding and shared pose; it cannot substitute the panel preview or omit model layers.
 
 ### Persistence And Proof
 

package/templates/starter/docs/toolcraft/core/performance.md

@@ -3,6 +3,7 @@
 <!-- toolcraft-performance-lifecycle: first-delivery=functional; later-delivery=functional-targeted; complaint=one-authority-targeted-performance-iteration; full-audit=explicit-only -->
 <!-- toolcraft-performance-iteration: authority=exact-request-evidence+canonical-path-ids; fixture=reachable-development; after-pass=return-app-to-user+stop -->
 <!-- toolcraft-performance-full-authority: automatic=forbidden; recommendation=two-compatible-iterations-or-broad-unlocalizable-problem; command=pnpm verify:perf; authority=explicit-user-request-or-accepted-offer -->
+<!-- toolcraft-performance-routing: localized=agent-targeted; ambiguous=one-user-facing-choice; broad=offer-targeted-or-full; full=explicit-only -->
 
 Read this module before changing renderer technique, animation, canvas, media, export, render scale, workload controls, or performance tests.
 
@@ -60,10 +61,18 @@ Include `initial-render` and every reachable interaction that executes or intent
 
 Browser checks apply compiled values through the real UI, observe every dimension, exercise the real preview or export path, assert the product result, and then check the budget. Export scenarios keep exact `actionValue`, visible `controlLabel`, and `completionEvidence` proof.
 
+Selected image/video dimensions, decoded output quality, video duration, and exact 30 FPS packet cadence are functional correctness and never require measured performance authority. Export completion latency and UI responsiveness are measured only for a user-authorized targeted iteration or explicit full audit.
+
 ## Verification Triggers
 
 Keep `src/app/app-verification-impact.json` complete: every product production module is `presentation`, `functional`, or `performance`, every owner names its nearest acceptance ids, and performance owners name their exact renderer pass ids. `performance` means the module can change a named pass's execution, invalidation, workload, resource lifecycle, or measured output. Shared modules name only the acceptance and pass coverage they can actually change; blanket every-module ownership is invalid. The protected delivery runner compares the inventory with the immediately previous successful delivery and requires ownership-derived functional proof for changed implementation. Performance ownership constrains which passes and paths an exact request may authorize; it does not authorize measurements by itself. A durable full-performance baseline, when one exists, remains historical evidence rather than the functional change anchor. Missing modules, stale paths, unknown acceptance or pass ids, and blanket ownership fail before a receipt can be written.
 
+Design product module boundaries for this exact later-delivery ownership. Keep frequently changed defaults and domain logic outside the public `app-schema.ts` assembly module when their acceptance coverage is narrower; otherwise a valid edit to that broad owner must select all of its acceptance ids. For raster zoom, prefer viewport transforms, but when exact render-scale backing requires rerasterization, declare one off-main `rasterize` pass with `quality: "retina"` owned by `viewport-zoom`. No other expensive viewport invalidation is accepted.
+
+Performance adapters measure one primary user operation per phase; do not include an inverse cleanup action inside the measured operation. Non-animation interaction probes retain at least 20 post-action frames so nearest-rank p95 is statistically distinct from the maximum frame without weakening either threshold.
+
+Performance-adapter-only changes remain functional delivery work: run code health and directly affected unit proof, but do not infer measurement. Their path candidates become executable only through exact complaint authority or an explicit full audit.
+
 Run targeted functional and browser checks during development. Only exact request authority can create a measured targeted performance iteration; a changed pipeline, workload boundary, adapter, interaction, measured output, owner, pass, path, filename, tier, or subsystem cannot. During an authorized iteration, the targeted Playwright reporter binds passed test names, pass ids, canonical path ids, nonce, and current source hash; product code and prose cannot mint that evidence.
 
 Functional performance coverage uses the runtime-owned deferred validation policy: all structural envelope, renderer pipeline, path, fixture, and adapter errors still fail, while unresolved kernel benchmark decisions remain visible as pending assessment requirements and require no kernel receipt. Strict/default validation and every authorized performance run continue to require the decision and protected current-source evidence.
@@ -74,9 +83,11 @@ The protected conversational lifecycle is automatic:
 
 - **First product delivery:** bare `pnpm verify:delivery` runs complete product contracts, one production build, and full functional acceptance with no measured performance. It preserves any independent full-performance baseline and cannot claim targeted or full performance evidence.
 - **Later functional-targeted delivery:** the same bare command runs exact ownership-derived functional checks for the changed implementation. It preserves any existing baseline and cannot silently invoke measured performance.
-- **Performance complaint:** record only domain authority in the latest Decision Trail—an exact request quote and canonical affected path IDs—then one bare `pnpm verify:delivery` runs one targeted iteration against the reachable development fixture. The same authority cannot produce a second successful iteration. Deliver the verified app, then stop and wait for user evaluation. A later complaint creates a new Decision Trail authority and starts another bounded iteration from the immediately previous successful delivery.
+- **Localized or clarified targeted work:** only a localized complaint or a post-clarification targeted choice records domain authority in the latest Decision Trail—an exact request quote and canonical affected path IDs—then one bare `pnpm verify:delivery` runs one targeted iteration against the reachable development fixture. Classifier output establishes complaint authority only and never path localization. Any unresolved localization creates neither performance-iteration intent nor canonical path authority, whether classification returned high-confidence `performance-iteration` or `needs-agent-judgment`. The same authority cannot produce a second successful iteration. Deliver the verified app, then stop and wait for user evaluation. Each later localized request may create one new bounded iteration from the immediately previous successful delivery.
+
+Request classification is tri-state. High-confidence performance language returns `performance-iteration`; high-confidence ordinary product work remains ordinary; ambiguous or unrecognized language becomes `needs-agent-judgment`, and the AI decides from the complete request. Classifier output establishes complaint authority only and never path localization. A localized complaint lets the agent select affected canonical paths and run one targeted iteration without asking the user. For an ambiguous complaint, ask one user-facing question naming visible operations and offering targeted diagnosis or a complete performance review; never ask the user for internal path IDs, and create neither performance-iteration intent nor canonical path authority before the answer. A broad or honestly unlocalizable problem may lead to that single targeted/full choice with a recommendation for complete performance review, but the user still chooses. An explicit complete-performance-review request runs `pnpm verify:perf` directly. Local negation and product commands are interpreted in their own clause rather than through a global phrase list. Before a performance iteration, the worklog must contain a nontrivial exact raw substring of Request as evidence. Whitespace and Unicode code units must match exactly; invented, whitespace-collapsed, NFKC-equivalent, or otherwise mismatched text is rejected. Complaint wording, repetition, filename, diagnostic classification, and touched subsystem never launch the complete matrix automatically.
 
-Request classification is tri-state. High-confidence performance language selects `performance-iteration`; high-confidence ordinary product work remains ordinary; ambiguous or unrecognized language becomes `needs-agent-judgment`, and the AI decides from the complete request. Local negation and product commands are interpreted in their own clause rather than through a global phrase list. Before a performance iteration, the worklog must contain a nontrivial exact raw substring of Request as evidence. Whitespace and Unicode code units must match exactly; invented, whitespace-collapsed, NFKC-equivalent, or otherwise mismatched text is rejected. Complaint wording, repetition, filename, diagnostic classification, and touched subsystem never launch the complete matrix automatically.
+Store agent-produced browser diagnostics under `.toolcraft/browser-artifacts/`, or use external tool-owned storage when the browser integration owns the artifact. Diagnostics never become product source or performance authority.
 
 Every protected targeted performance report stores the independently validated `cold`, `warm`, and `sustained` numeric observations for each selected canonical path. When the immediately previous successful delivery contains compatible targeted measurements, the next complaint records metric deltas against that report; otherwise it records an explicit non-comparable result. Deltas are diagnostic evidence, not a noisy strict-improvement gate: the current iteration must pass its absolute profile budgets, then return to the user without launching another optimization pass.
 
@@ -92,7 +103,7 @@ Completion wording must name the evidence level. Functional delivery reports fun
 
 Render Scale preserves selected backing resolution and visible quality. A raster product with `canvas.renderScale` declares typed `renderScaleCoverage: { kind: "selected-backing-pixels", states }` on one browser runtime row targeting `canvas.renderScale`. Exact sorted states are `["interaction", "steady"]`, plus `"playback"` when timeline is enabled.
 
-The product browser scenario supplies real state transitions to `expectToolcraftCanvasRenderScaleEvidence`. The protected helper keeps CSS size stable, checks actual canvas backing pixels against `css size × devicePixelRatio × selected scale` in every state, and only then emits `canvas-render-scale-backing` for each `<acceptance-id>#<state>`. A clamp or downsample is a functional failure without measured performance. In an explicitly authorized render-scale performance path, `performance-render-scale` may be emitted only after the same real backing assertion passes.
+The product browser scenario supplies real state transitions to `expectToolcraftCanvasRenderScaleEvidence`. The protected helper keeps CSS size stable, checks actual canvas backing pixels against `css size × devicePixelRatio × selected scale` in every state, and only then emits `canvas-render-scale-backing` for each `<acceptance-id>#<state>`. A clamp or downsample is a functional failure without measured performance. Every measured path in a render-scale-enabled raster product proves actual `CSS size × devicePixelRatio × 2` backing after each measured phase before `performance-render-scale` evidence may be emitted.
 
 Do not pass budgets by silently reducing selected quality, backing resolution, product range, source fidelity, export fidelity, or live interaction semantics. Diagnose pass cost, invalidation, cache lifetime, scheduling, and execution location first.
 

package/templates/starter/docs/toolcraft/core/runtime-boundary.md

@@ -21,7 +21,8 @@ Use only these app-specific extension points. Shared runtime changes happen upst
 - `renderDefaultCanvasMedia={false}` only when a product renderer replaces generic image/file preview; it does not suppress runtime model layers;
 - typed `modelPresentation`, with `{ mode: "runtime" }` as the default standard preview/export owner or `{ mode: "custom", consumers }` for declared model targets with checked consumers;
 - `controlRenderers` only for true custom controls that pass the built-in fit check;
-- `onPanelAction` for sticky product actions;
+- one `exportRenderer` that draws a deterministic product frame for runtime-owned image/video export;
+- `onPanelAction` for non-export sticky product actions;
 - optional `rendererPipelineRegistration` for one compiled executable custom-renderer pipeline shared by product work, runtime evidence, and performance assessment;
 - runtime commands and hooks.
 
@@ -30,6 +31,7 @@ Use only these app-specific extension points. Shared runtime changes happen upst
 - Do not hand-compose `ToolcraftRoot`, `CanvasShell`, `ControlsPanel`, `LayersPanel`, `TimelinePanel`, `ToolbarPanel`, or panel containers in product routes.
 - Do not render built-in control components such as `SliderControl`, `SelectControl`, `ColorControl`, `GradientControl`, `FontPickerControl`, `FileDropControl`, or `PanelActionsControl` directly in app code.
 - Do not recreate controls, panels, toolbar, timeline, layers, canvas shell, drag handles, section headers, section reset, history, or runtime surfaces by hand.
+- Do not create product-owned export canvases, encoders, object-URL downloads, or direct Mediabunny integrations; runtime owns typed image/video actions end to end.
 - If a shared behavior is wrong, fix the shared runtime/template source and regenerate or sync the copied Toolcraft source instead of patching one exported app.
 
 ## Canvas Boundary

package/templates/starter/docs/toolcraft/core/setup-export.md

@@ -33,20 +33,22 @@ Read this module before changing Setup, canvas sizing, background, image export,
 - Infinity canvas suppresses the bounded product-rendered preview background so the dormant finite output does not appear as a second canvas. While Background is on, `CanvasShell` fills the complete infinite viewport with the selected `Background color`; product code must not draw a synthetic workspace rectangle.
 - The last finite `canvas.size` remains dormant and immutable while Infinity canvas is on. Turning it off restores that exact size and centers the finite artboard; reset, undo/redo, persistence, and settings transfer preserve the same canonical `canvas.mode` behavior. Fixed proof compares exact artboard pixels and width/height control values before Infinity, after restoration, and after redo.
 - Runtime image and model assets keep explicit center-anchored world frames. Zoom, pan, radar, and model orientation change presentation, not scene geometry or export bounds.
-- Product `canvasContent` and custom renderer output declare one direct `ToolcraftAppComposition.sceneBoundsProvider`. It returns product world-space rectangles and receives `{ state, timeRange? }`; do not use a registry or DOM measurement.
+- Product `canvasContent` and custom renderer output declare one direct `ToolcraftAppComposition.sceneBoundsProvider`. It returns product world-space rectangles for the supplied exact frame state; do not use a registry, DOM measurement, or app-authored time-range envelope.
 - Infinite PNG export crops to the outward-rounded union of visible product, image, and model frames. Hidden or unavailable layers, runtime media suppressed by the composition, and editor-only handles or gizmos are excluded.
 - Prove unavailable-image exclusion with `createToolcraftUnavailableImageResourceFixture` and `expectToolcraftInfinityCanvasUnavailableImageExportEvidence`; product tests never mutate storage/state or call the reserved bridge, and evidence publishes only after deterministic cleanup restores the ready resource.
-- Infinite video export resolves one bounds envelope for the requested `timeRange` and uses it for every frame, preventing frame-to-frame output size changes.
+- Infinite video export asks the provider for every state in the runtime-owned frame schedule, unions those bounds once, and uses the result for every encoded frame, preventing frame-to-frame output size changes.
 - Finite-mode export remains the full finite canvas and does not call the product bounds provider.
 - Empty scenes, missing/invalid product bounds, and artifacts above `8192px` per edge or `67,108,864` pixels fail before canvas allocation with visible typed feedback: `empty-scene`, `scene-bounds-unavailable`, or `scene-export-too-large`.
 
 ## Resolution Scale
 
-- Non-vector raster, Canvas 2D, WebGL, and WebGPU previews set `canvas.renderScale: true`.
+- Non-vector raster, Canvas 2D, WebGL, and WebGPU previews author `canvas.renderScale` as `true` or `{ step }`. For this control, product code may customize only the slider step; it cannot author `enabled`, `min`, `defaultValue`, or `max`.
+- Runtime resolves the enabled slider to canonical `min: 1`, `defaultValue: 2`, and `max: 2`; the default step is `0.25`.
+- A custom step must be finite, between `0.01` and `1`, and evenly partition the canonical `1..2` range so the `2` maximum remains reachable. Invalid or non-partitioning steps fail schema resolution instead of being clamped.
 - Runtime then appends `Resolution scale` after canvas sizing.
 - `Resolution scale` changes backing pixels from `1` to `2` without changing visible CSS size or product output dimensions.
 - The product acceptance matrix adds exactly one browser runtime row targeting `canvas.renderScale` with `renderScaleCoverage: { kind: "selected-backing-pixels", states: ["interaction", "steady"] }`; insert `"playback"` in sorted order when timeline is enabled.
-- The product browser scenario uses `expectToolcraftCanvasRenderScaleEvidence` for every declared state. Only after CSS size remains stable and actual backing dimensions honor `css size × devicePixelRatio × selected scale` does the protected reporter emit `canvas-render-scale-backing`.
+- The product browser scenario uses `expectToolcraftCanvasRenderScaleEvidence` for every declared state. Only after CSS size remains stable and actual backing dimensions equal `css size × devicePixelRatio × selected scale` within the one-physical-pixel tolerance does the protected reporter emit `canvas-render-scale-backing`.
 - Any quality clamp or lower-resolution stretch is a functional failure without measured performance.
 - DOM/SVG/vector-native previews should not use render scale.
 - Performance fixes must preserve the user's selected render scale. Do not pass budgets by silently downsampling, stretching a lower-resolution backing canvas, blurring output, or clamping render scale below the chosen value.
@@ -70,8 +72,8 @@ Read this module before changing Setup, canvas sizing, background, image export,
 - Use a schema `color` target such as `appearance.background` or `scene.background`.
 - Do not hardcode a configurable background in CSS, Canvas `fillStyle`, or WebGL clear color.
 - Live preview calls `shouldIncludeToolcraftPreviewBackground(state)` and hides only the bounded product-rendered background when Background is off or Infinity canvas is on. In Infinity mode, the runtime viewport—not the product renderer—uses the selected Background color.
-- PNG export passes the Background value to the standard PNG export helper.
-- Video export keeps the background even when Background is off.
+- Runtime image export reads Background directly: PNG can be transparent, while JPG remains opaque.
+- Runtime video export keeps the selected background even when Background is off.
 
 ## Image Export
 
@@ -81,7 +83,8 @@ Read this module before changing Setup, canvas sizing, background, image export,
   - `export.image.resolution`, default `4k`, with baseline `2K`, `4K`, and `8K` options.
 - Still-output apps place `Image Export` directly above sticky footer actions.
 - Apps with both image and video export place `Image Export` immediately before `Video Export`.
-- PNG export resolves the concrete scene frame through the panel action context, then calls `createToolcraftPngExportCanvas({ frame, includeBackground, resolution, state, render })` and `renderRuntimeSceneToCanvas(canvas, frame)` before drawing product pixels.
+- Typed `export-image` actions are handled by the runtime. It resolves the current scene frame, selected format and resolution, allocates the exact backing, composites background plus visible runtime media/models, awaits `ToolcraftAppComposition.exportRenderer`, encodes the selected artifact, downloads it, and reports typed progress/failures.
+- Product code supplies only the shared deterministic `exportRenderer.renderFrame` callback in scene coordinates. It must not allocate an export canvas, call `toBlob`/`toDataURL`, create object URLs, or download the artifact.
 - The selected `export.image.resolution` must produce real 2048/4096/8192px long-edge PNG output for 2K/4K/8K. Retina sizing is only the fallback for current/omitted resolution.
 
 ## Video Export
@@ -93,11 +96,12 @@ Read this module before changing Setup, canvas sizing, background, image export,
   - `export.video.format`, default `mp4`, with baseline `MP4` and `WebM` options;
   - `export.video.resolution`, default `current`, with baseline `Current` and `4K` options.
 - Stack the pair only when labels or selected values would clip, and record that fit reason in the worklog.
-- Use `MediaRecorder.isTypeSupported(...)` or an explicit encoder/transcoder capability check before choosing the actual MIME/container.
+- Runtime uses the pinned Mediabunny timestamped encoder to select an actually supported container and codec. It reports the real MIME/extension or a typed visible failure.
 - `MOV` and `ProRes` are not baseline browser outputs; use them only with a custom encoder/transcoder plus acceptance and performance coverage.
 - Use `getToolcraftVideoExportSize` for video dimensions. `current` uses current canvas/output size with even encoder-safe rounding; `4k` fits inside 3840x2160, preserves aspect ratio, and returns even dimensions.
-- Offline rendered-frame video export must write timeline-based timestamps. `canvas.captureStream()` plus `MediaRecorder` records wall-clock time and cannot be the only duration mechanism for heavy renderers.
-- Browser acceptance must load the exported blob as a video, wait for metadata, and compare `video.duration` with the runtime timeline duration.
+- Runtime renders the same shared product frame callback at a fixed 30 FPS offline schedule, evaluates each immutable frame state at its timeline timestamp, and writes explicit packet timestamps/durations. Renderer wall-clock cost changes export latency only, never media cadence or duration.
+- Product code must not instantiate `MediaRecorder` or `VideoEncoder`, call `canvas.captureStream()`, import `mediabunny`, or provide a wall-clock fallback.
+- Protected browser acceptance decodes representative video frames, enumerates actual encoded packet timings, and proves dimensions, duration, cadence, background, and changing product pixels before publishing evidence.
 
 ## Sticky Product Actions
 
@@ -106,5 +110,5 @@ Read this module before changing Setup, canvas sizing, background, image export,
 - Products whose requested delivery includes animation also expose `Export Video`.
 - Clipboard copy is optional and never replaces export.
 - Export PNG and Export Video use `icon: "upload-simple"` to match the runtime `Export Settings` action.
-- Async export/download/copy/generate/apply handlers return the real Promise from `onPanelAction`. The runtime shows the sticky footer top accent indicator while the Promise is pending.
-- Use `reportProgress(0..1)` for determinate progress when available.
+- Runtime export actions own their real Promise and report render/encode/download progress through the sticky footer indicator.
+- Async non-export download/copy/generate/apply handlers return the real Promise from `onPanelAction` and use `reportProgress(0..1)` when determinate progress is available.