@pixel-point/toolcraft 0.0.18 → 0.0.19

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

@@ -1,6 +1,6 @@
 # Toolcraft Performance Contract
 
-<!-- toolcraft-performance-lifecycle: first-delivery=functional; later-delivery=functional-targeted; complaint=one-authority-targeted-performance-iteration; full-audit=explicit-only -->
+<!-- toolcraft-performance-lifecycle: first-delivery=functional-complete; later-edits=focused-only; 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 -->
@@ -94,15 +94,13 @@ Do not use an umbrella viewport scenario when a concrete viewport path exists. E
 
 Scenario interaction is the canonical pipeline interaction from its derived path, such as `control-drag`, `viewport-drag`, `viewport-zoom`, `initial-render`, or `export`. Do not introduce scenario-only aliases or umbrella interaction names.
 
-`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.
+Keep frequently edited product defaults and domain behavior in focused product modules so later feature tests can target the edited behavior without loading unrelated product areas. `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. Module boundaries improve development feedback speed; they do not authorize aggregate or measured proof.
 
 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.
+A change isolated to product performance adapters or performance test support runs only its directly affected unit proof during ordinary editing and 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
 
@@ -138,9 +136,9 @@ Artifact dimensions, decoded quality, video duration, and exact 30 FPS packet ca
 
 ## 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.
+During implementation, run targeted unit and functional browser checks for feedback without minting delivery evidence. The protected runner creates complete functional evidence only for first product delivery. After that initial receipt exists, ordinary edits run only directly relevant focused checks; a repeated bare `verify:delivery` exits before inventory, build, tests, export, and performance work. A durable full-performance baseline, when one exists, remains independent historical evidence. Targeted and full performance reports remain bound to their executed plan, nonce, and current source hash; product-authored JSON is not evidence.
 
-First and later functional gates validate every structural envelope, pipeline, path, fixture, and adapter invariant with the runtime-owned deferred coverage policy. They may expose unresolved benchmark requirements but do not require `kernelBenchmarkDecisions`, run `verify:kernel`, or read a kernel receipt. Default strict coverage and authorized performance execution retain those requirements.
+The first functional gate validates every structural envelope, pipeline, path, fixture, and adapter invariant with the runtime-owned deferred coverage policy. It may expose unresolved benchmark requirements but does not require `kernelBenchmarkDecisions`, run `verify:kernel`, or read a kernel receipt. Later focused feature checks validate the structures they edit. Default strict coverage and authorized performance execution retain the full requirements.
 
 Ordinary changes and performance metadata cannot authorize measured performance. Only exact complaint/request authority can create one measured targeted performance iteration. Changed files, tier, ownership, passes, paths, pipeline, boundary, adapter, interaction, output, or subsystem never authorize it. Once authorized, run only the exact `browser perf:` paths named by the request authority; unrelated paths and the full suite remain outside the iteration.
 
@@ -149,9 +147,9 @@ The protected performance-iteration runner requests each path's compiled develop
 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.
+2. **Later ordinary edits.** Run only the directly relevant product tests and browser checks. The same bare command is a protected no-op that preserves the initial receipt and any performance checkpoints without reading current inventory or launching aggregate proof.
 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.
+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 full-performance checkpoint, and preserves the initial delivery receipt and targeted-performance history.
 
 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.
 
@@ -165,7 +163,7 @@ Canonical classification examples:
 - 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.
+Use bare `pnpm verify:delivery` once for first product delivery or one authority-backed targeted performance iteration. Do not use it as a later ordinary edit gate. 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.
 
 After two consecutive compatible protected performance iterations, the runner emits a recommendation and the agent must offer a slower complete audit if the user remains unsatisfied. A demonstrably broad or unlocalizable cross-system problem may justify offering it earlier through semantic agent judgment; do not reduce that decision to the number of selected paths.
 

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

@@ -14,7 +14,7 @@ Use the same producer order for every custom renderer:
 4. Run `assessToolcraftRenderPlan`; resolve errors and run protected `pnpm verify:kernel` only when the assessment requires candidate evidence.
 5. Derive canonical paths and compile combined fixtures through their adapters.
 6. Implement the selected renderer and run targeted checks for the paths being developed.
-7. Run lifecycle-appropriate delivery proof: full functional acceptance with no measured performance for first product delivery, exact ownership-derived functional checks for later work, or one targeted iteration for a performance complaint. Full certification is a separate operator/CI command.
+7. Run lifecycle-appropriate proof: full functional acceptance with no measured performance for first product delivery, feature-focused tests only for later ordinary edits, or one targeted iteration for a performance complaint. Full certification is a separate operator/CI command.
 
 Do not write renderer code before the envelope, `rendererTechnique`, pipeline, and assessment exist.
 
@@ -114,7 +114,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`. 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.
+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. Models are not silently traced for SVG; explicit SVG delivery requires product-authored editable vector content through `svgExportRenderer`. Runtime owns presentation binding, pose, scene frame, dimensions, pixel ratio, validation/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

@@ -18,7 +18,7 @@ Top-level schema fields:
 | `settingsTransfer` | Runtime-owned Export Settings / Import Settings identity.              | `core/setup-export.md`                                                     |
 | `panelActions`     | Sticky product delivery actions such as export, copy, generate, apply. | `core/setup-export.md`, `core/control-selection.md`                        |
 
-Schema controls always bind to a `target`, use `defaultValue` for reset behavior, and include `performanceRole` / `performanceReason` on visible non-action controls. Use built-in control `type` values before `controlRenderers`.
+Schema controls always bind to a `target`, use `defaultValue` for reset behavior, and include `performanceRole` / `performanceReason` on visible non-action controls. Use built-in control `type` values before `controlRenderers`. Built-in targets have one canonical runtime value model through defaults, seeded/live state, undo/reset, persistence, settings transfer, and keyframes; renderers never decode React callback shapes. `color` state is an expanded uppercase `#RRGGBB` string even though Color emits `{ hex }`. Compound/collection values keep their documented models; ordinary `fileDrop` bytes stay outside `state.values`.
 
 ## Canvas
 
@@ -160,7 +160,7 @@ Common control fields:
 | `description`       | Product-specific help text only when it adds meaning beyond the label.                                                       |
 | `applicability`     | Required product claim: `{ mode: "always" }` or `{ mode: "conditional", all: [...] }`. Hidden values are preserved.       |
 | `orderRole`         | Makes section order testable.                                                                                                |
-| `semanticGroup`     | Language-independent product sub-entity/workflow grouping, required on every control in sections with eight to ten controls. |
+| `semanticGroup`     | Language-independent product sub-entity/workflow grouping, required on every control in sections with eight to ten controls and on every plain Color when a mixed section contains multiple plain Colors. |
 | `sliderValueKind`   | `slider` intent: `"continuous"` or `"discrete"`.                                                                             |
 | `textValueKind`     | `text`/`code` intent: `"single-line"`, `"multiline"`, or `"structured"`.                                                     |
 | `curveIntent`       | `curves` composition: `"single-value-map"` or `"color-channels"`.                                                            |
@@ -220,7 +220,7 @@ before schema controls or renderer code:
 
 ```ts
 export const starterProductReadiness: ToolcraftProductReadiness = {
-  exportIntent: { image: { mode: "toolcraft-default" }, video: { mode: "not-requested" } },
+  exportIntent: { image: { mode: "toolcraft-default" }, svg: { mode: "not-requested" }, video: { mode: "not-requested" } },
   interactionOwnership: [],
   mode: "product",
   productName: "Model Studio",
@@ -313,17 +313,17 @@ Reference and motion metadata lives in `starterTransferMode`.
 
 Use `transferMode: "reference-runtime-clone"` when porting an existing app unless the user explicitly asks for redesign. Reference clones declare `referenceStudy`, `referenceFeatureInventory`, and acceptance mapping; detailed evidence requirements live in `core/reference-study.md`.
 
-Every product readiness declaration includes required `exportIntent`. Its resolved image/video capabilities must correspond exactly to schema actions and settings sections. Use `core/setup-export.md` for the authoritative modes, evidence requirements, and decision sequence.
+Every product readiness declaration includes required `exportIntent`. Its resolved image/SVG/video capabilities must correspond exactly to typed schema actions, applicable settings sections, and artifact acceptance. Use `core/setup-export.md` for the authoritative modes, evidence requirements, and decision sequence.
 
-Video references declare `videoReferenceStudy` before implementation. Animated products declare `animationIntent`, and playback/keyframe timeline apps declare a proven loop duration when known. Detailed animation rules live in `core/timeline-animation.md`.
+Motion references declare typed `referenceInputs` before implementation; each behavior maps bidirectionally to observable acceptance and browser `reference-parity`. The canonical preprocessing, sampling, evidence, timing, and no-reference rules live in `core/reference-study.md`. Animated products declare `animationIntent`, and playback/keyframe timeline apps declare a proven loop duration when known. Detailed animation rules live in `core/timeline-animation.md`.
 
 ## Export And Actions
 
-Product apps expose enabled artifact delivery through sticky `panelActions`, not canvas UI or ordinary body controls. `productReadiness.exportIntent` is required: image export defaults on and is absent only with explicit removal evidence; video export exists only with explicit user-request evidence. Animation, playback, keyframes, and timeline presence never change that intent.
+Product apps expose enabled artifact delivery through sticky `panelActions`, not canvas UI or ordinary body controls. `productReadiness.exportIntent` is required: image export defaults on and is absent only with explicit removal evidence; SVG/video exist only with explicit user-request evidence. Renderer technology, animation, playback, keyframes, and timeline presence never change that intent.
 
-Every app with `Export PNG` includes `Image Export` controls with `export.image.format` and `export.image.resolution`. Apps with `Export Video` include `Video Export` controls with `export.video.format` and `export.video.resolution`. Image-only, image-plus-video, video-only, and explicit no-export layouts must match `core/setup-export.md` exactly.
+Every app with `Export PNG` includes `Image Export` controls with `export.image.format` and `export.image.resolution`. Apps with `Export Video` include `Video Export` controls with `export.video.format` and `export.video.resolution`. `Export SVG` has no settings section and joins the sticky actions without changing image/video settings adjacency. Resolved layouts must match `core/setup-export.md` exactly.
 
-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.
+Use the standard runtime path: declare typed `export-image`/`export-video` actions plus their settings and provide `ToolcraftAppComposition.exportRenderer` when product code contributes pixels. For explicit SVG delivery, declare `export-svg` and provide `svgExportRenderer`, which appends namespace-aware editable vector nodes to the supplied detached group. Call `shouldIncludeToolcraftPreviewBackground(state)` only for bounded live preview; runtime owns artifact composition, frame/sizing, SVG validation/serialization, raster/video 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

@@ -1,6 +1,6 @@
 # Toolcraft Workflow
 
-<!-- toolcraft-performance-lifecycle: first-delivery=functional; later-delivery=functional-targeted; complaint=one-authority-targeted-performance-iteration; full-audit=explicit-only -->
+<!-- toolcraft-performance-lifecycle: first-delivery=functional-complete; later-edits=focused-only; 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 -->
@@ -18,11 +18,11 @@ Before planning or editing app code, runtime code, controls, canvas, panels, ren
    - **Runtime/template source**: use root `AGENTS.md` and runtime contracts.
 3. Classify the task type.
 4. Read the task-specific docs below.
-5. Record the coherent user-visible delivery batch and its focused development checks before implementation.
+5. Record whether this is first product delivery or later feature work, plus its focused development checks, before implementation.
 
 Do not edit implementation files until this preflight is complete.
 
-Renderer and performance work also completes this pre-code 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. Keep `src/app/app-verification-impact.json` current while implementing. Development uses impact-derived functional and browser checks without minting delivery evidence. First and later functional delivery run no measured performance; only exact request authority creates one targeted iteration. Full certification is a separate operator/CI action described in the canonical performance docs.
+Renderer and performance work also completes this pre-code 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. Development uses feature-focused functional and browser checks without minting delivery evidence. First delivery runs no measured performance; only exact request authority creates one targeted iteration. Full certification is a separate operator/CI action described in the canonical performance docs.
 
 ## Local Contract Authority
 
@@ -64,14 +64,14 @@ For product app work, update `docs/toolcraft/agent-worklog.md` before reporting
   - decision;
   - alternatives rejected;
   - state/output mapping from controls, commands, timeline, layers, media, or renderer to the visible product;
-  - one bare-delivery verification narrative;
+  - first-delivery proof or later focused-check narrative;
   - risks or follow-ups.
 - 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.
 
-Protected receipts, not the worklog, own changed files, the derived plan, executed checks, reports, measurements, and pass/fail evidence. Each Decision Trail entry mentions only that one bare `pnpm verify:delivery` will derive and run the protected proof.
+Protected receipts own first-delivery and performance proof. The worklog records which focused tests and browser checks were selected for later edits; those edits do not create another functional receipt.
 
 ## Runtime Boundary
 
@@ -92,26 +92,26 @@ Browser verification is outcome-based. Protected helpers attach versioned eviden
 The normal product loop is:
 
 ```text
-assemble/change
+assemble first product
 → focused functional feedback
-→ one coherent delivery boundary
-→ protected functional delivery
+→ one protected initial delivery
+→ later edits with feature-focused checks only
 → user evaluation
 ```
 
-Use the smallest focused unit and browser checks while implementation is changing. Do not rerun the aggregate, export, or performance matrix after every edit. At the coherent delivery boundary, run one bare `pnpm verify:delivery` and use the automatic sequence:
+Use the smallest focused unit and browser checks while implementation is changing. Do not rerun the aggregate, export, or performance matrix after edits. Use this automatic sequence:
 
 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. **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.
+2. **Later ordinary edits:** run the exact unit/component test for the changed implementation, then `pnpm test:feature -- <acceptance-id>`. The feature command resolves current product acceptance only. A leaf ID runs one browser scenario; a finite selector automatically includes acceptance peers whose applicability cases depend on it. Multiple changed behaviors use multiple explicit IDs. Use `pnpm test:feature -- --all` only when a cross-cutting functional edit cannot be honestly bounded; `--all` still means all product acceptance, not all Playwright tests. The command runs current source through the development server and never runs build, delivery, export matrices, framework self-tests, or measured performance. Commit, push, deploy, preview, steering, and fixes do not authorize aggregate proof. A repeated bare `pnpm verify:delivery` is a protected no-op that exits before inventory, build, tests, export, and performance work and preserves the initial receipt byte-for-byte.
+3. **Localized or clarified targeted performance 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 replacing the initial delivery receipt.
 
 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.
+The proven-product phase guard runs before current-source inventory, integrity, build, tests, or semantic proof collection. The initial receipt remains the durable first-version identity even after later source edits. `workflow-observation.md` is a post-delivery summary, not execution authority; `agent-worklog.md` remains part of first-delivery inputs.
 
 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`.
 
-The app is not complete when required checks are failed, incomplete, pending, blocked, or listed as skipped. Resolve benchmark requirements with the protected internal kernel check before accepting the renderer. The delivery runner executes integrity and lifecycle-specific proof atomically, binds evidence to current source, and advances the delivery anchor only after success. Product prose and command arguments cannot select or broaden that proof.
+The first product version is not complete when its required checks are failed, incomplete, pending, blocked, or listed as skipped. Later work is not complete until its directly relevant focused checks pass. Resolve benchmark requirements with the protected internal kernel check before accepting the renderer. The delivery runner executes initial or authority-backed performance proof atomically; ordinary later edits do not advance or replace the initial receipt. Product prose and command arguments cannot select or broaden performance proof.

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

@@ -6,6 +6,9 @@ import {
   expectToolcraftInfinityCanvasVideoExportEvidence,
   observeInfinityCanvas,
 } from "./browser-infinity-canvas-evidence";
+import { expectToolcraftInfinityCanvasSvgExportEvidence } from "./browser-infinity-canvas-svg-evidence";
+import { createToolcraftSvgFixtureDownload } from "./svg-download-test-fixtures";
+import { inspectToolcraftSvgDownload } from "./svg-artifact-inspection";
 import {
   readToolcraftCanvasViewport,
   zoomToolcraftCanvasViewport,
@@ -96,6 +99,41 @@ test("toolcraft Infinity canvas video evidence compares decoded envelopes", asyn
   );
 });
 
+test("toolcraft Infinity canvas SVG evidence compares inspected vector envelopes", async ({
+  page,
+}) => {
+  const source = (width: number, height: number, x: number, y: number) =>
+    `<svg xmlns="http://www.w3.org/2000/svg" width="${width}" height="${height}" viewBox="${x} ${y} ${width} ${height}"><g data-toolcraft-product-scene="true"><rect data-shape="true" x="${x}" y="${y}" width="${width}" height="${height}" fill="#52AAFF"/></g></svg>`;
+  const finite = await inspectToolcraftSvgDownload({
+    download: await createToolcraftSvgFixtureDownload(
+      page,
+      source(1080, 1350, 0, 0),
+      "finite.svg",
+    ),
+    page,
+  });
+  const infinite = await inspectToolcraftSvgDownload({
+    download: await createToolcraftSvgFixtureDownload(
+      page,
+      source(640, 400, -320, -200),
+      "infinite.svg",
+    ),
+    page,
+  });
+  await expectToolcraftInfinityCanvasSvgExportEvidence(
+    {
+      finite: finite.inspection,
+      infinite: infinite.inspection,
+    },
+    {
+      expectedFiniteSize: { height: 1350, width: 1080 },
+      expectedInfiniteSize: { height: 400, width: 640 },
+      requirementId: "fixture.infinity.svg",
+      target: "canvas.infinity",
+    },
+  );
+});
+
 test("toolcraft Infinity canvas background evidence proves viewport color and dependency", async () => {
   await expectToolcraftInfinityCanvasBackgroundEvidence(
     {