@pixel-point/toolcraft 0.0.16 → 0.0.17

package/templates/starter/docs/toolcraft/core/timeline-animation.md

@@ -63,7 +63,7 @@ Use no timeline only when the motion is explicitly autonomous decoration with no
 
 ## Video Export Timing
 
-- Video export uses runtime timeline time.
-- Offline rendered-frame video export must encode frame timestamps from timeline time.
-- Real-time `canvas.captureStream()` plus `MediaRecorder` is not enough when renderer work can be slower than playback.
-- Browser acceptance verifies exported video metadata duration against edited timeline duration.
+- Runtime video export creates a fixed 30 FPS schedule from runtime timeline duration and evaluates one immutable frame state at every scheduled timeline time.
+- The timestamped Mediabunny backend encodes each completed frame with its explicit schedule timestamp and duration; render wall-clock cost does not affect artifact cadence.
+- Product code must not use `canvas.captureStream()`, `MediaRecorder`, `VideoEncoder`, or its own encoder/download fallback.
+- Protected browser acceptance proves edited timeline duration, actual encoded packet count/timings, and distinct decoded product frames.

package/templates/starter/docs/toolcraft/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 -->
 
 Use this document while authoring `src/app/app-performance.ts`, performance acceptance, and browser evidence. Read `core/performance.md` first. Functional selection and proof ownership are canonical in `workflow.md` and `acceptance-testing.md`; performance metadata does not redefine them.
 
@@ -95,6 +96,14 @@ Scenario interaction is the canonical pipeline interaction from its derived path
 
 `src/app/app-verification-impact.json` maps every current product production module to `presentation`, `functional`, or `performance` impact and names its nearest acceptance ids. A performance entry is reserved for a module that can change a named pass's execution, invalidation, workload, resource lifecycle, or measured output, and names only those exact pass ids. The inventory contains no stale or missing module paths; blanket every-module acceptance or pass ownership is invalid. This mapping is the authority for verification scope after first delivery.
 
+Keep frequently edited product defaults and domain behavior in focused product modules whose ownership entries name only their nearest acceptance ids. `app-schema.ts` remains the public assembly boundary, but it should import those domain definitions instead of accumulating every mutable product decision in one file. A change made directly in a blanket schema owner correctly selects every acceptance id owned by that file; module boundaries are therefore part of later-delivery feedback speed, not cosmetic organization.
+
+Viewport drag and zoom normally stay in transforms or uniforms and must not invalidate expensive passes. A render-scale-enabled raster product may rerasterize on `viewport-zoom` only through an off-main `rasterize` pass with `quality: "retina"`; this is the narrow exception that preserves exact CSS × DPR × selected-scale backing as the visible zoom size changes. Main-thread, non-retina, drag-time, and unrelated expensive invalidations remain invalid.
+
+Each measured interaction phase performs one primary user operation. State-restoring inverse actions belong in a later phase or outside the measurement, never in the same action. Non-animation interaction probes collect at least 20 post-action frames so nearest-rank p95 remains a percentile rather than collapsing to the single maximum frame; animation keeps its dedicated 120-frame sample and export keeps completion-owned timing.
+
+A change isolated to product performance adapters or performance test support selects code-health and any directly affected unit proof for ordinary delivery, but it never infers a measured path. Exact request authority may consume the adapter's performance candidates in one targeted iteration, while explicit `pnpm verify:perf` remains the only full-audit route.
+
 ## 6. Fixture Adapters And Plans
 
 `fixtureAdapters.dimensions` contains exactly one adapter per workload dimension. An adapter:
@@ -125,6 +134,8 @@ Mutating measurements prove a stable baseline, record the first persistent chang
 
 `export` scenarios declare exact `actionValue`, visible `controlLabel`, and `completionEvidence`. They may declare a `completionDeadlineMs` only when the product needs a stricter deadline than the central batch profile; scenarios do not author responsiveness budgets. The protected helper owns the click and completion event. Export evidence still inspects the delivered artifact and verifies that it is non-empty and matches selected output semantics.
 
+Artifact dimensions, decoded quality, video duration, and exact 30 FPS packet cadence are functional proof. Export latency and UI responsiveness become measured performance only through an authorized targeted iteration or explicit full audit.
+
 ## 8. Demand-Only Performance Lifecycle
 
 During implementation, run targeted unit and functional browser checks for feedback without minting delivery evidence. At the coherent delivery boundary, the protected delivery runner diffs current sources against the immediately previous successful delivery and resolves changed modules through `app-verification-impact.json`. Every functional delivery requires only its ownership-derived functional proof, including changes to performance-owned modules. Performance ownership constrains an exact request-authorized iteration; it does not authorize measurements. A durable full-performance baseline, when one exists, remains historical evidence and is not reused as the functional-delivery diff anchor. Reports remain bound to their executed plan, nonce, and current source hash; product-authored JSON is not evidence.
@@ -139,17 +150,20 @@ The conversational lifecycle is automatic:
 
 1. **First product delivery.** Bare `pnpm verify:delivery` proves complete product contracts, performs one production build, and runs full functional acceptance with no measured performance. The receipt preserves any independent full-performance baseline and cannot claim targeted or full performance evidence.
 2. **Later functional-targeted delivery.** The same bare command derives exact ownership-required functional checks from the current inputs and immediately previous successful delivery. It preserves a baseline when present and cannot silently run measured performance or create one.
-3. **Performance complaint.** The latest Decision Trail records only an exact request quote and canonical affected path IDs. One bare `pnpm verify:delivery` then runs one targeted iteration against the reachable development fixture. The protected report stores independently validated `cold`, `warm`, and `sustained` measurements; compatible prior evidence produces diagnostic deltas, while absent or incompatible evidence records a non-comparable result. Current absolute budgets remain the pass/fail authority. Deliver the verified app, then stop and wait for user evaluation. A later complaint creates a new Decision Trail authority for another bounded iteration.
+3. **Localized or clarified targeted work.** Only a localized complaint or a post-clarification targeted choice records an exact request quote and canonical affected path IDs in the latest Decision Trail. 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`. One bare `pnpm verify:delivery` then runs one targeted iteration against the reachable development fixture. The protected report stores independently validated `cold`, `warm`, and `sustained` measurements; compatible prior evidence produces diagnostic deltas, while absent or incompatible evidence records a non-comparable result. Current absolute budgets remain the pass/fail authority. Deliver the verified app, then stop and wait for user evaluation. Each later localized request may create one new bounded iteration.
 4. **Full audit.** Only an explicit operator request or accepted offer authorizes `pnpm verify:perf`. It performs one fresh production build and the complete maximum-fixture performance matrix, updates only the performance checkpoints, and preserves the delivery anchor.
 
-Use the runtime request classifier as a guard, not as a substitute for understanding the user. It returns high-confidence `performance-iteration`, high-confidence ordinary product work, or `needs-agent-judgment`. High-confidence ordinary product instructions stay ordinary. For ambiguous language, the AI reads the actual request and decides. Iteration mode requires `Performance intent: performance-iteration — Request evidence: "<verbatim exact Request quote>"` in the worklog before the command runs. The quote must be a nontrivial exact raw substring of the current Request, including identical whitespace and Unicode code units; invented, whitespace-collapsed, or NFKC-equivalent evidence is invalid.
+Use the runtime request classifier as a guard, not as a substitute for understanding the user. It returns high-confidence `performance-iteration`, high-confidence ordinary product work, or `needs-agent-judgment`. High-confidence ordinary product instructions stay ordinary. Classifier output establishes complaint authority only and never path localization. A localized complaint lets the agent select the affected canonical paths and run one targeted iteration without asking the user. For an ambiguous complaint, ask one user-facing question naming the visible operation and offering targeted diagnosis or a complete performance review; never ask the user to choose 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 only the user's choice authorizes it. A direct complete-performance-review request runs `pnpm verify:perf` without another clarification. Iteration mode requires `Performance intent: performance-iteration — Request evidence: "<verbatim exact Request quote>"` in the worklog before the command runs. The quote must be a nontrivial exact raw substring of the current Request, including identical whitespace and Unicode code units; invented, whitespace-collapsed, or NFKC-equivalent evidence is invalid.
+
+Store agent-produced browser diagnostics under `.toolcraft/browser-artifacts/`, or leave them in external tool-owned storage when the browser integration owns them. Diagnostics are not product source and must not affect verification inventory.
 
 Canonical classification examples:
 
-- direct reports that the app lags, the editor is slow, dragging has latency, frames stutter, or CPU/GPU/memory use is excessive select one performance iteration;
+- reports that the app lags, the editor is slow, frames stutter, or CPU/GPU/memory use is excessive may establish high-confidence complaint authority, but without a visible operation they remain unlocalized and do not select an iteration;
+- “dragging has latency” is localized to a visible operation, so the agent selects its affected canonical paths and runs one targeted iteration without clarification;
 - product commands such as increasing animation speed, freezing a camera at a frame, renaming a mode to “Performance”, or stating that the app does not lag are high-confidence ordinary product work;
-- wording such as “the controls feel sticky” or “something feels off” needs agent judgment from the full request;
-- classification is clause-local: an independent complaint still selects an iteration even when another clause negates a different complaint or requests a product speed change.
+- wording such as “the controls feel sticky” or “something feels off” needs agent judgment from the full request; if localization remains unresolved, ask the one visible-operation targeted/full question and record no iteration or path authority before the answer;
+- classification is clause-local: an independent complaint may establish complaint authority even when another clause negates a different complaint or requests a product speed change, while localization is still resolved separately.
 
 Use bare `pnpm verify:delivery` once for the coherent delivery batch. Complaint wording, repetition, filename, diagnostic classification, and touched subsystem never launch the complete matrix automatically. A targeted failure triggers targeted diagnosis, not an automatic full-suite run, and a passing iteration stops after returning the verified app for user evaluation.
 
@@ -165,7 +179,7 @@ User-facing completion text must distinguish the levels. Functional delivery rep
 
 ## Performance Quality
 
-Preserve selected output quality, preview fidelity, backing resolution, source fidelity, product boundaries, and live interaction behavior. Raster products with Resolution scale declare functional `renderScaleCoverage` using `kind: "selected-backing-pixels"` and exact `interaction`/`steady` states, plus `playback` when timeline is enabled. Their product browser scenario uses `expectToolcraftCanvasRenderScaleEvidence`; `canvas-render-scale-backing` is emitted only after real backing dimensions satisfy the selected scale without changing visible CSS size.
+Preserve selected output quality, preview fidelity, backing resolution, source fidelity, product boundaries, and live interaction behavior. Raster products with Resolution scale declare functional `renderScaleCoverage` using `kind: "selected-backing-pixels"` and exact `interaction`/`steady` states, plus `playback` when timeline is enabled. Their product browser scenario uses `expectToolcraftCanvasRenderScaleEvidence`; `canvas-render-scale-backing` is emitted only after real backing dimensions satisfy the selected scale without changing visible CSS size. Every measured path in a render-scale-enabled raster product must prove actual `CSS size × devicePixelRatio × 2` backing after each measured phase.
 
 A renderer that caps 2x output during interaction, playback, or steady state fails functional acceptance without measured performance. `performance-render-scale` remains limited to an explicitly authorized performance path and follows the same backing-pixel assertion; path metadata alone is not evidence. When a budget fails, inspect assessed pass cost, invalidation, resource lifecycle, scheduling, cancellation, and execution location before changing product scope.
 

package/templates/starter/docs/toolcraft/renderer-technique.md

@@ -110,7 +110,7 @@ The `mount*` and error functions above stand for product renderer integration on
 
 The presentation lease is keyed by canonical document reference and shares immutable geometry/material/texture GPU resources across preview and export while cloning only scene roots. Replacement, delete/reset, failed creation, release, and provider unmount dispose ownership deterministically. The original uploaded folder/ZIP remains immutable durable source; display fit and camera pose live outside the leased root.
 
-The runtime presents structurally valid analyzing or repairing geometry at `0.4` opacity and committed clean/fixed geometry at `1`. Export is always `1`. Product image export renders its own pixels first, then awaits the `renderModelsToCanvas(exportCanvas)` helper supplied to `onPanelAction`. The public `renderToolcraftModelsToCanvas` API is the host-level implementation behind that helper; product apps should not bypass the action context to assemble their own host. Video export uses the same binding, visible layers, pose, current canvas dimensions, and target pixel ratio for every frame.
+The runtime presents structurally valid analyzing or repairing geometry at `0.4` opacity and committed clean/fixed geometry at `1`. Export is always `1`. Runtime image/video export composites visible committed model layers before awaiting the product's shared `ToolcraftAppComposition.exportRenderer` frame. Runtime owns the presentation binding, pose, scene frame, dimensions, pixel ratio, encoding, and download; product code does not call model compositors or construct a parallel export host.
 
 When `viewInteraction.mode` is `orbit`, schema `orientationGizmo`, direct model drag, preview rendering, hit testing, reset/history, and export share every declared orientation pose target. The product renderer supplies geometry-aware `hitTest`; Toolcraft owns gesture scheduling and history through `useToolcraftModelOrbitInteraction`.
 

package/templates/starter/docs/toolcraft/schema-reference.md

@@ -51,7 +51,7 @@ export const appComposition: ToolcraftAppComposition = {
 
 The provider returns world-space `{ x, y, width, height }` rectangles. Runtime unions them once with visible image/model frames. It is called only for infinite export; video passes the requested time range so the provider can return one complete animation envelope. Product code does not read DOM bounds or the dormant finite size.
 
-Use `canvas.renderScale: true` only for non-vector raster previews such as Canvas 2D, WebGL, or WebGPU. Do not enable it for DOM/SVG/vector-native previews. Enabling it requires one browser runtime acceptance row targeting `canvas.renderScale` with `renderScaleCoverage.kind: "selected-backing-pixels"` and exact sorted states `["interaction", "steady"]`, plus `"playback"` when timeline is enabled. The fixed `canvas-render-scale-backing` recipe proves actual backing pixels rather than timing.
+Use `canvas.renderScale: true` or `canvas.renderScale: { step }` only for non-vector raster previews such as Canvas 2D, WebGL, or WebGPU. For this field, product code may customize only the slider step; authored schema cannot set `enabled`, `min`, `defaultValue`, or `max`. Runtime resolves enabled render scale to `{ enabled: true, min: 1, defaultValue: 2, max: 2, step }`, using `0.25` when no step is authored. A custom step must be finite, between `0.01` and `1`, and evenly partition the canonical `1..2` range so `2` remains reachable; invalid input fails fast. Do not enable it for DOM/SVG/vector-native previews. Enabling it requires one browser runtime acceptance row targeting `canvas.renderScale` with `renderScaleCoverage.kind: "selected-backing-pixels"` and exact sorted states `["interaction", "steady"]`, plus `"playback"` when timeline is enabled. The fixed `canvas-render-scale-backing` recipe proves actual backing pixels rather than timing.
 
 ## Media Defaults
 
@@ -321,11 +321,7 @@ Product apps expose delivery through sticky `panelActions`, not canvas UI or ord
 
 Every app with `Export PNG` includes `Image Export` controls with `export.image.format` and `export.image.resolution`. Apps with `Export Video` also include `Video Export` controls with `export.video.format` and `export.video.resolution`.
 
-Use standard helpers:
-
-- `createToolcraftPngExportCanvas({ resolution, includeBackground, state, render })`
-- `shouldIncludeToolcraftPreviewBackground(state)`
-- `getToolcraftVideoExportSize({ resolution, state })`
+Use the standard runtime path: declare typed `export-image`/`export-video` panel actions and their settings, provide one `ToolcraftAppComposition.exportRenderer` when product code contributes pixels, and draw one deterministic frame from the supplied state/time in scene coordinates. Call `shouldIncludeToolcraftPreviewBackground(state)` only for bounded live preview; runtime owns artifact composition, sizing, encoding, download, progress, and errors.
 
 Detailed Setup, Background, Image Export, Video Export, sticky action, icon, and progress rules live in `core/setup-export.md`.
 

package/templates/starter/docs/toolcraft/workflow.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 -->
 
 This file is the app-local routing layer for Toolcraft work. It does not replace the detailed contracts; it tells an agent which contract to read and which verification path to use before editing.
 
@@ -65,7 +66,7 @@ For product app work, update `docs/toolcraft/agent-worklog.md` before reporting
   - state/output mapping from controls, commands, timeline, layers, media, or renderer to the visible product;
   - one bare-delivery verification narrative;
   - risks or follow-ups.
-- for a performance complaint only, an exact request quote and the canonical affected performance path IDs.
+- for localized performance work, or a post-clarification targeted choice, an exact request quote and the canonical affected performance path IDs; classifier output establishes complaint authority only, and unresolved localization records neither performance-iteration intent nor canonical path authority regardless of classifier result.
 - updated high-level decisions for renderer, view interaction, interaction ownership, timeline, layers, controls, export, and performance when those choices change.
 
 If the folder is still the neutral starter, do not invent product decisions. Once it becomes a product, switch the worklog to product mode and keep it concrete.
@@ -102,9 +103,13 @@ Use the smallest focused unit and browser checks while implementation is changin
 
 1. **First product delivery:** bare `pnpm verify:delivery` proves complete product contracts, performs one production build, runs full functional acceptance, and runs no measured performance.
 2. **Later functional-targeted delivery:** bare `pnpm verify:delivery` compares the immediate previous and current semantic functional proof models. It selects exact changed acceptance contracts, their direct owners and domains, and tests reached through the affected product-unit dependency graph.
-3. **Performance complaint:** record domain authority in the worklog—an exact request quote plus canonical affected path IDs—then run one bare `pnpm verify:delivery`. It executes one targeted iteration against the reachable development fixture, returns the verified app, and waits for user evaluation.
+3. **Localized or clarified targeted work:** only a localized complaint or a post-clarification targeted choice records domain authority in the worklog—an exact request quote plus canonical affected path IDs—and runs one bare `pnpm verify:delivery`. It executes one targeted iteration against the reachable development fixture, returns the verified app, and waits for user evaluation. Classifier output alone never localizes a path; unresolved localization creates neither performance-iteration intent nor canonical path authority, whether classification returned high-confidence `performance-iteration` or `needs-agent-judgment`.
 4. **Full audit:** only an explicit operator request or accepted offer authorizes `pnpm verify:perf`. It performs one fresh build and the complete maximum-fixture performance matrix without advancing the delivery anchor.
 
+Performance authority and localization are separate decisions. Classifier output establishes complaint authority only and never path localization. A localized complaint lets the agent select the affected canonical paths and run one targeted iteration without asking the user. For an ambiguous complaint, ask one user-facing question that names the visible operation and offers targeted diagnosis or a complete performance review; never ask the user to choose internal path IDs, and record no performance-iteration intent or canonical path authority before the answer. For a broad or honestly unlocalizable problem, the agent may recommend the complete performance review in that single targeted/full choice, but the user still chooses. A direct request for the complete performance review runs `pnpm verify:perf` without another clarification.
+
+Store agent-produced browser diagnostics under `.toolcraft/browser-artifacts/`. Browser integrations may instead use their external tool-owned storage; diagnostic files never belong in product source.
+
 The unchanged `sourceHash` fast path does not collect the catalog, dependency graph, or functional proof model and does not execute proof. For a changed source, the current catalog, input roles, ownership inventory, and semantic model are collected once and remain the immutable basis for that delivery plan. `workflow-observation.md` is a post-delivery summary, not execution authority, so it stays outside this hash; `agent-worklog.md` remains included.
 
 After two consecutive compatible targeted iterations, offer the slower full audit if the user remains unsatisfied. A complaint, filename, or touched subsystem never authorizes it. Canonical classification details, failure behavior, and evidence wording live in `core/performance.md` and `performance.md`.

package/templates/starter/e2e/app-browser-control-coverage.spec.ts

@@ -1,10 +1,43 @@
 import { expect, test } from "@playwright/test";
 import { expectToolcraftExportedArtifact } from "./browser-acceptance-outcome-helpers";
 import {
+  expectToolcraftDiscreteSliderMarkers,
   expectToolcraftSegmentedControlCellsPreservePadding,
   getToolcraftFieldByLabel,
 } from "./performance-helpers";
 
+test("discrete slider layout accepts one interior marker and rejects none", async ({
+  page,
+}) => {
+  await page.setContent(`
+    <div data-slot="toolcraft-runtime-app">
+      <div data-toolcraft-control-target="canvas.renderScale">
+        <div data-slot="field" style="display:block;width:200px;height:24px;">
+          <div data-slot="slider" data-variant="discrete" style="display:block;width:200px;height:24px;">
+            <span data-slot="slider-marker" style="display:block;width:1px;height:6px;"></span>
+          </div>
+        </div>
+      </div>
+    </div>
+  `);
+
+  await expectToolcraftDiscreteSliderMarkers(page, "canvas.renderScale");
+
+  await page.setContent(`
+    <div data-slot="toolcraft-runtime-app">
+      <div data-toolcraft-control-target="canvas.renderScale">
+        <div data-slot="field" style="display:block;width:200px;height:24px;">
+          <div data-slot="slider" data-variant="discrete" style="display:block;width:200px;height:24px;"></div>
+        </div>
+      </div>
+    </div>
+  `);
+
+  await expect(
+    expectToolcraftDiscreteSliderMarkers(page, "canvas.renderScale"),
+  ).rejects.toThrow(/at least one interior marker/);
+});
+
 test("segmented layout helper catches paddingless or colliding cells", async ({ page }) => {
   await page.setContent(`
     <div data-slot="field">FX Preset

package/templates/starter/e2e/app-browser-infinity-canvas-evidence.spec.ts

@@ -1,4 +1,4 @@
-import { test } from "@playwright/test";
+import { expect, test } from "@playwright/test";
 
 import {
   expectInfiniteCanvasObservation,
@@ -6,6 +6,10 @@ import {
   expectToolcraftInfinityCanvasVideoExportEvidence,
   observeInfinityCanvas,
 } from "./browser-infinity-canvas-evidence";
+import {
+  readToolcraftCanvasViewport,
+  zoomToolcraftCanvasViewport,
+} from "./performance-canvas-helpers";
 
 test("toolcraft Infinity canvas observation reads runtime-owned geometry", async ({
   page,
@@ -24,6 +28,44 @@ test("toolcraft Infinity canvas observation reads runtime-owned geometry", async
   );
 });
 
+test("toolcraft canvas viewport observation reads the runtime world transform", async ({
+  page,
+}) => {
+  await page.setContent(`
+    <div
+      data-toolcraft-canvas-world
+      data-toolcraft-canvas-offset-x="96"
+      data-toolcraft-canvas-offset-y="-64"
+      data-toolcraft-canvas-zoom="125"
+    ></div>
+  `);
+
+  await expect(readToolcraftCanvasViewport(page)).resolves.toEqual({
+    offsetX: 96,
+    offsetY: -64,
+    zoom: 125,
+  });
+});
+
+test("toolcraft canvas zoom helper performs only the requested direction", async ({
+  page,
+}) => {
+  await page.setContent(`
+    <button aria-label="Zoom in" onclick="document.body.dataset.zoomIn = String(Number(document.body.dataset.zoomIn ?? 0) + 1)"></button>
+    <button aria-label="Zoom out" onclick="document.body.dataset.zoomOut = String(Number(document.body.dataset.zoomOut ?? 0) + 1)"></button>
+  `);
+
+  await zoomToolcraftCanvasViewport(page, {
+    direction: "in",
+    repetitions: 2,
+  });
+  await expect(page.locator("body")).toHaveAttribute("data-zoom-in", "2");
+  await expect(page.locator("body")).not.toHaveAttribute("data-zoom-out");
+
+  await zoomToolcraftCanvasViewport(page, { direction: "out" });
+  await expect(page.locator("body")).toHaveAttribute("data-zoom-out", "1");
+});
+
 test("toolcraft Infinity canvas video evidence compares decoded envelopes", async () => {
   await expectToolcraftInfinityCanvasVideoExportEvidence(
     {

package/templates/starter/e2e/app-browser-render-scale-evidence.spec.ts

@@ -1,5 +1,8 @@
 import { expect, test, type Page, type TestInfo } from "@playwright/test";
 
+import {
+  parseToolcraftBrowserRuntimeEvidence,
+} from "../src/app/test-evidence/browser-runtime-contract";
 import { attachedEvidenceTypes } from "./browser-semantic-evidence-test-helpers";
 import {
   expectToolcraftCanvasRenderScaleEvidence,
@@ -89,6 +92,24 @@ test("selected 2x rejects a 1x backing store and attaches no evidence", async ({
   expect(testInfo.attachments).toHaveLength(attachmentCount);
 });
 
+test("selected 2x rejects a 3x backing store and attaches no evidence", async ({
+  page,
+}, testInfo: TestInfo) => {
+  await installCanvas(page, 3);
+  const attachmentCount = testInfo.attachments.length;
+
+  await expect(
+    expectToolcraftCanvasRenderScaleEvidence(page, {
+      canvasSelector,
+      requirementId: "canvas.render-scale",
+      selectedScale: 2,
+      stateTransitions: [transition("steady", () => setBackingScale(page, 3))],
+      target: "canvas.renderScale",
+    }),
+  ).rejects.toThrow(/backing width.*one physical pixel/iu);
+  expect(testInfo.attachments).toHaveLength(attachmentCount);
+});
+
 test("a backing clamp introduced by a state transition fails the whole recipe", async ({
   page,
 }, testInfo: TestInfo) => {
@@ -164,15 +185,23 @@ test("performance render-scale evidence attaches only after real backing proof",
   const attachmentCount = testInfo.attachments.length;
 
   await expectToolcraftPerformanceRenderScaleBackingEvidence(page, {
+    baselineCssSize: { height: 80, width: 120 },
     canvasSelector,
+    cssSizePolicy: "fixed",
     pathId: "performance-path:render-scale",
-    selectedScale: 2,
+    phase: "cold",
     target: "canvas.renderScale",
   });
 
-  expect(attachedEvidenceTypes(testInfo, attachmentCount)).toEqual([
-    "performance-render-scale",
-  ]);
+  const [qualityEvidence] = testInfo.attachments
+    .slice(attachmentCount)
+    .map(parseToolcraftBrowserRuntimeEvidence)
+    .filter(
+      (evidence) => evidence?.evidenceType === "performance-render-scale",
+    );
+  expect(qualityEvidence?.requirementId).toBe(
+    "performance-path:render-scale#cold",
+  );
 });
 
 test("performance render-scale evidence rejects a quality clamp without attaching", async ({
@@ -183,11 +212,36 @@ test("performance render-scale evidence rejects a quality clamp without attachin
 
   await expect(
     expectToolcraftPerformanceRenderScaleBackingEvidence(page, {
+      baselineCssSize: { height: 80, width: 120 },
       canvasSelector,
+      cssSizePolicy: "fixed",
       pathId: "performance-path:render-scale",
-      selectedScale: 2,
+      phase: "warm",
       target: "canvas.renderScale",
     }),
-  ).rejects.toThrow(/backing width.*Resolution scale 2/iu);
+  ).rejects.toThrow(/warm.*backing width/iu);
+  expect(testInfo.attachments).toHaveLength(attachmentCount);
+});
+
+test("performance render-scale evidence rejects a changed CSS baseline", async ({
+  page,
+}, testInfo: TestInfo) => {
+  await installCanvas(page, 2);
+  const attachmentCount = testInfo.attachments.length;
+  await page.locator(canvasSelector).evaluate((canvas) => {
+    canvas.setAttribute("style", "display:block;width:60px;height:40px");
+  });
+  await setBackingScale(page, 2);
+
+  await expect(
+    expectToolcraftPerformanceRenderScaleBackingEvidence(page, {
+      baselineCssSize: { height: 80, width: 120 },
+      canvasSelector,
+      cssSizePolicy: "fixed",
+      pathId: "performance-path:render-scale",
+      phase: "sustained",
+      target: "canvas.renderScale",
+    }),
+  ).rejects.toThrow(/sustained.*preserve.*CSS width/iu);
   expect(testInfo.attachments).toHaveLength(attachmentCount);
 });

package/templates/starter/e2e/app-browser-render-scale-requirements.spec.ts

@@ -1,7 +1,14 @@
 import { expect, test } from "@playwright/test";
+import {
+  defineToolcraft,
+  type ToolcraftPerformancePath,
+} from "@repo/toolcraft-runtime";
 
 import type { ToolcraftComponentAcceptance } from "../src/app/starter-acceptance";
-import { deriveToolcraftBrowserRuntimeRequirements } from "./browser-runtime-evidence-requirements";
+import {
+  deriveToolcraftBrowserRuntimeRequirements,
+  deriveToolcraftPerformancePathRuntimeRequirements,
+} from "./browser-runtime-evidence-requirements";
 
 function renderScaleAcceptance(
   states: readonly ("interaction" | "playback" | "steady")[],
@@ -57,6 +64,20 @@ test("render-scale coverage derives one exact functional requirement per state",
   ]);
 });
 
+test("render-scale backing replaces generic visual-change evidence", () => {
+  const requirements = deriveToolcraftBrowserRuntimeRequirements([
+    renderScaleAcceptance(["interaction", "steady"]),
+  ]);
+
+  expect(requirements.map(({ evidenceType }) => evidenceType)).not.toContain(
+    "product-observable-change",
+  );
+  expect(requirements.map(({ evidenceType }) => evidenceType)).toEqual([
+    "canvas-render-scale-backing",
+    "canvas-render-scale-backing",
+  ]);
+});
+
 test("render-scale functional requirements remain separate from performance evidence", () => {
   const requirements = deriveToolcraftBrowserRuntimeRequirements([
     renderScaleAcceptance(["interaction", "steady"]),
@@ -69,3 +90,58 @@ test("render-scale functional requirements remain separate from performance evid
     "performance-render-scale",
   );
 });
+
+const unrelatedPerformancePaths = [
+  {
+    id: "performance-path:color",
+    interaction: "control-drag",
+    invalidates: ["composite"],
+    profile: "live-interaction",
+    runsOn: ["main"],
+    targets: ["appearance.color"],
+    workloadDimensions: [],
+  },
+  {
+    id: "performance-path:viewport",
+    interaction: "viewport-drag",
+    invalidates: ["composite"],
+    profile: "frame-budget",
+    runsOn: ["main"],
+    targets: [],
+    workloadDimensions: [],
+  },
+] as const satisfies readonly ToolcraftPerformancePath[];
+
+test("every raster performance path derives cold, warm, and sustained 2x requirements", () => {
+  const requirements = deriveToolcraftPerformancePathRuntimeRequirements(
+    unrelatedPerformancePaths,
+    defineToolcraft({
+      canvas: { enabled: true, renderScale: true },
+      panels: {},
+    }),
+  ).filter(({ evidenceType }) => evidenceType === "performance-render-scale");
+
+  expect(requirements).toEqual([
+    expect.objectContaining({ requirementId: "performance-path:color#cold" }),
+    expect.objectContaining({ requirementId: "performance-path:color#warm" }),
+    expect.objectContaining({
+      requirementId: "performance-path:color#sustained",
+    }),
+    expect.objectContaining({ requirementId: "performance-path:viewport#cold" }),
+    expect.objectContaining({ requirementId: "performance-path:viewport#warm" }),
+    expect.objectContaining({
+      requirementId: "performance-path:viewport#sustained",
+    }),
+  ]);
+});
+
+test("vector performance paths derive no raster quality requirements", () => {
+  const requirements = deriveToolcraftPerformancePathRuntimeRequirements(
+    unrelatedPerformancePaths,
+    defineToolcraft({ canvas: { enabled: true }, panels: {} }),
+  );
+
+  expect(requirements.map(({ evidenceType }) => evidenceType)).not.toContain(
+    "performance-render-scale",
+  );
+});

package/templates/starter/e2e/app-browser-runtime-provenance.spec.ts

@@ -23,6 +23,13 @@ test("protected observable evidence is attached only after its assertion succeed
     const output = document.createElement("div");
     output.dataset.toolcraftProductOutput = "";
     output.dataset.toolcraftProofProductOutput = "";
+    output.style.backgroundColor = "#000000";
+    output.style.height = "24px";
+    output.style.left = "0";
+    output.style.position = "fixed";
+    output.style.top = "0";
+    output.style.width = "24px";
+    output.style.zIndex = "100";
     output.textContent = "Before";
     const button = document.createElement("button");
     button.id = "change-output";
@@ -46,6 +53,7 @@ test("protected observable evidence is attached only after its assertion succeed
         button.dataset.activated = "true";
       });
       await currentPage.locator('[data-toolcraft-proof-product-output]').evaluate((output) => {
+        (output as HTMLElement).style.backgroundColor = "#FFFFFF";
         output.textContent = "After";
       });
     }),

package/templates/starter/e2e/app-browser-runtime-reporter.spec.ts

@@ -135,6 +135,41 @@ test("performance marker requires every derived scenario evidence type", () => {
   expect(errors).toContainEqual(expect.stringContaining("performance-budget"));
 });
 
+test("performance reporter rejects missing warm and sustained raster quality evidence", () => {
+  const testName = "browser perf: toolcraft path performance-path:color";
+  const requirements: ToolcraftBrowserRuntimeRequirement[] = [
+    "cold",
+    "warm",
+    "sustained",
+  ].map((phase) => ({
+    evidenceType: "performance-render-scale",
+    requirementId: `performance-path:color#${phase}`,
+    target: "appearance.color",
+    testName,
+  }));
+  const marker = fakeTestCase({
+    file: "/product/e2e/app-browser-runtime-evidence.spec.ts",
+    title: TOOLCRAFT_BROWSER_PERFORMANCE_MARKER_TEST_NAME,
+  });
+  const scenarioTest = fakeTestCase({
+    results: [passedResultWithEvidence(requirements[0]!)],
+    title: testName,
+  });
+  const errors: string[] = [];
+  const reporter = new ToolcraftBrowserRuntimeEvidenceReporter({
+    acceptanceRequirements: [],
+    performanceRequirements: requirements,
+    reportError: (error) => errors.push(error),
+  });
+
+  reporter.onBegin?.({} as never, fakeSuite([marker, scenarioTest]));
+  expect(reporter.onEnd?.({ status: "passed" } as never)).toEqual({
+    status: "failed",
+  });
+  expect(errors).toContainEqual(expect.stringContaining("#warm"));
+  expect(errors).toContainEqual(expect.stringContaining("#sustained"));
+});
+
 test("runtime evidence reporter requires render-scale proof for every covered state", () => {
   const testName = "browser: canvas render scale backing pixels";
   const requirements: ToolcraftBrowserRuntimeRequirement[] = [

package/templates/starter/e2e/app-browser-runtime-requirements.spec.ts

@@ -35,7 +35,10 @@ test("derived paths own one canonical browser evidence requirement set", () => {
     },
   ] as const;
 
-  const requirements = deriveToolcraftPerformancePathRuntimeRequirements([path]);
+  const requirements = deriveToolcraftPerformancePathRuntimeRequirements(
+    [path],
+    defineToolcraft({ canvas: { enabled: true }, panels: {} }),
+  );
 
   expect(requirements.map(({ evidenceType }) => evidenceType)).toEqual([
     "performance-measurement",

package/templates/starter/e2e/app-browser-semantic-evidence.spec.ts

@@ -169,7 +169,6 @@ test("layer recipes reject collection substitution and prove exact reorder", asy
   expect(attachedEvidenceTypes(testInfo, attachmentCount)).toEqual([
     "product-observable-change",
     "layer-reorder",
-    "product-observable-change",
     "layer-selection",
   ]);
 });

package/templates/starter/e2e/app-browser-shell.spec.ts

@@ -74,11 +74,19 @@ test("product observable helper catches changed and unchanged output", async ({
   `);
 
   const snapshot = await getToolcraftProductObservableSnapshot(page);
-
-  expect(
-    snapshot,
-    "The product observable helper should read marked product output.",
-  ).toContain("Before");
+  const decodedSnapshot = JSON.parse(snapshot) as {
+    height: number;
+    rasterHash: string;
+    width: number;
+  };
+
+  expect(decodedSnapshot).toMatchObject({
+    height: expect.any(Number),
+    rasterHash: expect.stringMatching(/^[a-f0-9]+$/u),
+    width: expect.any(Number),
+  });
+  expect(decodedSnapshot.height).toBeGreaterThan(0);
+  expect(decodedSnapshot.width).toBeGreaterThan(0);
 
   await expectToolcraftProductObservableToChange(page, async () => {
     await page.locator("#change-output").evaluate((button) => {

package/templates/starter/e2e/app-performance-path-adapters.ts

@@ -1,4 +1,11 @@
-import type { ToolcraftPerformancePathAdapter } from "./performance-path-adapter-contract";
+import type {
+  ToolcraftPerformanceCanvasBacking,
+  ToolcraftPerformancePathAdapter,
+} from "./performance-path-adapter-contract";
+
+export const appPerformanceCanvasBacking:
+  | ToolcraftPerformanceCanvasBacking
+  | undefined = undefined;
 
 export const appPerformancePathAdapters =
   [] as const satisfies readonly ToolcraftPerformancePathAdapter[];