@pixel-point/toolcraft 0.0.18 → 0.0.19

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

@@ -10,7 +10,7 @@ The neutral starter has no product renderer, timeline, layers, export behavior,
 
 ## Automatic Delivery Lifecycle
 
-Keep this worklog human-shaped. For the first product delivery, record the request, decisions, state/output mapping, reference evidence, rejected alternatives, and known risks; one bare `pnpm verify:delivery` derives complete contract proof, one build, full functional acceptance, and no measured performance. For later `functional-targeted` delivery, record only the new intent and decisions; the same bare command derives exact ownership-required proof from protected state.
+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 ordinary edits, record new intent and material decisions, the exact unit/component test, and acceptance IDs passed to `pnpm test:feature`; selector expansion is automatic, while explicit `--all` records why the edit could not be bounded. Do not claim or run another aggregate functional delivery.
 
 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.
 
@@ -131,6 +131,93 @@ The quoted evidence must be an exact nontrivial raw substring of `Request` with
 - Verification: One bare `pnpm verify:delivery` remains the generated-app delivery authority; this runtime/template contract delivery also runs the monorepo checks required by the repository entry contract.
 - Risks: Pairwise proof depends on truthful Control Section Inventory grouping; unsupported selector domains fail acceptance instead of silently skipping cases. Legacy low-level consumers remain readable but cannot satisfy generated product acceptance.
 
+### Iteration 7 — Evidence-backed adaptive motion reference study
+
+- Request: Make video-reference analysis detailed enough to retain brief behavior changes, choose review density from the source instead of a small fixed frame count, and keep first delivery plus later app refinement fast and contract-correct.
+- Task type: Cross-cutting runtime, starter, protected delivery, CLI packaging, documentation, and generated-app lifecycle architecture.
+- User-visible result: An explicitly registered motion reference is scanned across every decoded frame, reviewed through dense 12 FPS overview evidence plus retained event/focus windows, and automatically split into complete studies of at most 120 reviewed frames. Typed behavior mappings require exact automated evidence and browser `reference-parity`; a product with no registered reference performs no FFmpeg work.
+- Source/reference checked: `docs/superpowers/specs/2026-08-11-video-reference-evidence-design.md`, `docs/superpowers/plans/2026-08-11-video-reference-evidence.md`, runtime decision/component contracts, `core/reference-study.md`, protected delivery planning/reporting, CLI prepack generation, proof-process execution, atomic publication leases/journals, and fresh generated standalone applications.
+- Reference inputs: The neutral starter remains `referenceInputs: []` and contains no invented reference asset. Reproducible analysis begins only after a source is explicitly registered and materialized at a repository-accessible path.
+- Contract rules applied: `video-reference-analysis`, `reference-clone-source-of-truth`, `acceptance-product-observable`, `performance-coverage-levels`, and `workflow-required`.
+- Decision: Use one typed `referenceInputs` boundary with nested partition studies. Separate source inspection, full-frame change scanning, adaptive selection, reviewed-frame materialization, canonical evidence validation, contact-sheet creation, semantic classification, and atomic group publication. Keep focus refinements on the same study identity when segment bounds stay stable; retire the complete previous group in one source-scoped journal transaction when partition identities change.
+- Publication decision: Resolve artifact, staging, and transaction roots before mutation; bind staging children to canonical study IDs; keep journal residue outside the committed artifact root; renew token-owned leases; restore the complete old group on failure; and isolate concurrent sources while serializing one source identity.
+- Alternatives rejected: Fixed 13-frame sampling, single-screenshot or prose-only storyboard authority, app-local/manual evidence artifacts, partial per-study publication, implicit preprocessing during generation or delivery, legacy `videoReferenceStudy` compatibility, product-authored test selection, measured performance triggered by functional work, and a second hand-maintained framework inventory.
+- State/output mapping: Registered source bytes produce canonical source/reference identity, machine evidence JSON, and a contact sheet. Typed studies classify detected events and phases; behavior mappings name `acceptanceId` plus `motionReferenceCoverage`; protected automated evidence and browser `reference-parity` prove the resulting product behavior. Exact study resource paths remain functional verification owners.
+- Validation fixtures: A packaged no-reference app completed initial delivery with 435/435 Vitest tests, build, 14/14 browser scenarios, zero FFmpeg/ffprobe calls, and null performance state. A 12.000333-second, 30 FPS, 360-frame FFV1 source retained one-frame events near frames 91 and 271, produced two bounded studies with 109 and 40 reviewed frames and a 149-frame unique reviewed union, and used one full scan plus one union extraction.
+- Lifecycle evidence: Reference initial delivery completed 435/435 tests, build, and 14/14 browser scenarios including real reference parity. The unchanged gate completed in 0.4 seconds without build, tests, browser, FFmpeg, or performance. A focus refinement atomically changed evidence under the same study IDs with no staging, transaction, journal, or backup residue; later delivery selected 7 affected files, 33/33 tests, build, one browser scenario, and `animation.speed` only. A separate boundary-changing fixture proved two old partition IDs are retired when two new IDs replace them.
+- Verification: `pnpm starter:docs-check`, `pnpm starter:test`, `pnpm starter:typecheck`, `pnpm cli:test`, `pnpm cli:typecheck`, runtime tests/typecheck, website typecheck/docs sync, `pnpm ai:check`, `pnpm build`, packaged fallback execution, 199/199 motion-reference tests, root/staging/crash/isolation regressions, and repeated fresh packaged no-reference/reference lifecycles. Sandbox-only localhost bind failures were repeated with the exact commands outside the sandbox and passed.
+- Performance intent: ordinary functional contract work. Measured performance was intentionally not run; every generated receipt kept current performance and performance baseline null.
+- Risks: FFmpeg and ffprobe are required only for the explicit `reference:study` command. An undeclared chat attachment is not reproducible repository evidence and must be registered before implementation. Previously generated apps retain their copied framework until regenerated. Supported evidence is limited to the documented source/timing formats and fails closed on ambiguous timing, malformed groups, unsafe paths, or incomplete artifacts.
+
+### Iteration 8 — Initial-only aggregate verification lifecycle
+
+- Request: Keep complete checks after the first product build, but make every later ordinary edit use only the tests for the functionality being changed instead of rerunning delivery, export, browser, or performance matrices.
+- Task type: Starter lifecycle, protected receipts, CLI generation, runtime policy, contract documentation, and generated-app workflow.
+- User-visible result: A generated app still receives one complete functional proof before its first delivery. After that receipt exists, ordinary edits finish with directly relevant unit/component and browser checks; a repeated bare delivery command exits before inventory, integrity, planning, build, tests, export, browser, or checkpoint writes.
+- Source/reference checked: The previous functional-targeted delivery implementation, protected lifecycle/plan/receipt/checkpoint modules, CLI generated-product fixtures, documentation mirrors, and a freshly generated standalone product exercised through its initial build and one later material edit.
+- Reference inputs: None. This is a workflow contract change derived from the user's explicit development-lifecycle requirements.
+- Docs/contracts read: `workflow.md`, `acceptance-testing.md`, `core/performance.md`, `performance.md`, the root and generated `AGENTS.md`, and runtime performance verification policy.
+- Contract rules applied: `workflow-required`, `acceptance-product-observable`, and `performance-coverage-levels`.
+- View interaction intent: Unchanged. Verification phase selection does not alter a product's typed `viewInteraction` or renderer behavior.
+- Interaction ownership: Unchanged. Product surfaces retain their existing owners; focused checks observe the edited product behavior without creating a second interaction surface.
+- Decision: Treat the immutable initial delivery receipt as the phase boundary. Keep only two executable protected delivery plans: complete initial functional proof and exact request-authorized targeted performance. Delete later-functional semantic diff, verification-impact inventory, changed-file ownership resolution, and browser-impact selection instead of retaining dormant compatibility paths.
+- Alternatives rejected: Repeating full delivery after every edit, an automatic later-functional aggregate gate, a new `verify:change` command, filename-based test inference, measured performance inferred from touched renderer files, and legacy receipt/impact compatibility branches.
+- State/output mapping: Initial proof writes the durable delivery receipt once. Targeted performance updates only targeted performance history; full audit updates only the independent baseline. Ordinary later edits do not read current source inventory or mutate any checkpoint.
+- Performance intent: ordinary-product-work
+- Verification: The real generated-app lifecycle completed one full initial proof, then one exact material test and a byte-for-byte checkpoint-preserving delivery no-op. Starter tests passed 686/686 script tests and 420/420 Vitest tests; CLI passed 93 tests with three Windows-only skips; starter, CLI, runtime, website, docs, code health, and production build checks passed.
+- Risks: Previously generated apps keep their copied version-1 lifecycle until regenerated or migrated. Focused later checks are intentionally selected by the agent from the edited behavior and do not mint aggregate functional evidence.
+
+### Iteration 9 — Semantic focused feature verification
+
+- Request: Keep later app edits fast while verifying that a change did not break semantically related behavior, and measure the effect on a real generated app.
+- Task type: Starter/CLI workflow command, acceptance selection, Playwright orchestration, generated-app fixture, documentation, and verification.
+- User-visible result: Later edits now run one exact unit/component test plus `pnpm test:feature -- <acceptance-id>`. A leaf behavior stays one browser scenario; a finite selector automatically expands to the acceptance peers required by current applicability semantics. Explicit `--all` remains product-only. No build, delivery, export matrix, framework self-test, or measured performance is added.
+- Source/reference checked: Current acceptance applicability derivation, runtime evidence reporter, exact Playwright title resolver, protected delivery process, generated material fixture, and a fresh standalone lifecycle with a selector edit after initial delivery.
+- Reference inputs: None. This is workflow behavior derived from the user's explicit later-edit speed and safety requirements.
+- Docs/contracts read: `workflow.md`, `acceptance-testing.md`, `agent-worklog.md`, root/generated `AGENTS.md`, and the semantic focused verification design and implementation plan.
+- Contract rules applied: `workflow-required`, `acceptance-product-observable`, `controls-component-layout-invariants`, and `performance-coverage-levels`.
+- View interaction intent: Unchanged. The command selects product acceptance and does not alter renderer view ownership.
+- Interaction ownership: Unchanged. Existing product controls and canvas operations remain their own interaction authorities.
+- Decision: Start from explicit agent-authored acceptance IDs and compute a fixed-point closure through the canonical control applicability cases. Load current TypeScript app semantics through a strict Playwright reporter, validate a versioned JSON plan, resolve exact test titles, and run one worker against the current-source development server. Keep the existing runtime evidence reporter as the only outcome authority. Reuse a previous targeted-performance report only when its source hash equals the current source hash, so ordinary edits cannot create a false consecutive-performance comparison.
+- Alternatives rejected: Repeating complete delivery, restoring changed-file impact inference, selecting tests from filenames, using stale production preview without rebuilding, adding a build to each later edit, silently falling back to all browser tests, and weakening branch/layout evidence.
+- State/output mapping: The command reads current acceptance/schema/inventory, prints the selected IDs and browser scenarios, and produces ordinary test output only. It removes inherited delivery/performance authority and never reads or writes the protected checkpoint. The real lifecycle proved the initial checkpoint remained byte-for-byte unchanged.
+- Performance intent: ordinary-product-work. No measured performance path or full audit was authorized or executed.
+- Verification: Selector 6/6, plan codec 4/4, reporter 6/6, runner 5/5, starter scripts 697/697, starter Vitest 427/427, CLI 94 passed with three Windows-only skips, runtime 2144/2144, typechecks, docs sync, and the production build passed. The real fresh generated lifecycle selected six material control scenarios from `material.layer`, excluded material export and unrelated domains, used no later build, and preserved the initial checkpoint byte-for-byte. A direct one-scenario focused run took 21.08 s while installing the missing Playwright browser once, then 7.80 s warm; the browser phase itself reported 6.1 s on the warm run. No measured performance ran. The final thermo-nuclear pass also proved that same-source performance reports remain comparable while a changed source resets comparison to `none`.
+- Risks: Previously generated apps keep their copied workflow until regenerated or deliberately migrated. A selector may legitimately select several browser scenarios when its entity contract declares multiple controls as semantic peers; this bounded cost is visible in command output.
+
+### Iteration 10 — Structural redundant-control-label guards
+
+- Request: Prevent generated applications from shipping useless visible labels, using the Dispersion `Spectrum` section and its `Color 1` through `Color 4` fields as failure evidence; change only the starter contract, not Dispersion.
+- Task type: Focused starter acceptance-contract and documentation correction.
+- User-visible result: Generated product schemas now fail acceptance when multiple sibling colors use sequential `Color N` labels or when a separately rendered field label repeats its section title. Useful role labels such as `Fill` and `Stroke` remain valid, and tabs retain a matching accessibility name without rendering duplicate text.
+- Source/reference checked: The supplied Dispersion screenshot, its schema/worklog/browser receipt as read-only diagnostic evidence, `core/layout.md`, the copied starter acceptance validator, runtime label rendering, and existing control-label regression tests.
+- Reference inputs: The screenshot is diagnostic evidence only. `/Users/kusnizza/Projects/toolcraft-apps/dispersion` remains outside the implementation scope and is unchanged.
+- Contract rules applied: `controls-component-layout-invariants`, `controls-layout-heuristics`, and `workflow-required`.
+- Root cause: Sequential labels were rejected only after vocabulary-based palette detection. `Spectrum` and `dispersion.customColorA` through `customColorD` did not match that vocabulary, so the invariant returned no errors. Duplicate section-title labels were checked only for switch/checkbox controls.
+- Decision: Make `Color N` rejection depend only on multiple sibling color controls. Move section-title equality into the canonical general label policy, exclude tabs because their label is accessibility-only, and remove the switch-specific duplicate branch so one invariant owns the behavior.
+- Alternatives rejected: Editing Dispersion, adding `Spectrum` or `customColor` to vocabulary lists, silently hiding invalid labels at runtime, introducing `labelIntent`, and retaining duplicate switch/general diagnostics.
+- State/output mapping: Acceptance reads resolved app-authored control sections and emits blocking schema diagnostics before product delivery. Runtime state, rendering, controls, and generated applications are not mutated by this correction.
+- Performance intent: ordinary-product-work. This validation-only edit adds no runtime workload and authorizes no measurement.
+- Verification: The two focused label suites passed 13/13 tests; the complete starter app slice passed 430/430 tests; starter typecheck and local docs check passed.
+- Risks: Previously generated applications retain their copied validator until regenerated or deliberately migrated.
+
+### Iteration 11 — Canonical control values and selected-entity isolation
+
+- Request: Prevent the Logos Grid class of failure where a color edit does not reach the selected object; strengthen only the Toolcraft runtime/starter contract and leave Logos Grid unchanged.
+- Task type: Shared runtime value lifecycle, starter acceptance, protected browser evidence, contracts, docs, and generated propagation. No measured performance.
+- User-visible result: Built-in controls now commit one canonical value representation at every state ingress. Selected-object property controls cannot pass acceptance unless two real product entities prove bidirectional pixel isolation and correct control rebinding.
+- Source/reference checked: `/Users/kusnizza/Projects/toolcraft-apps/logos-grid` logs and source as read-only diagnostic evidence; runtime Color adapter, reducers, state creation, persistence/settings restoration, timeline keyframes, interaction ownership, Layers coverage, browser proof sessions, and generated-app integrity boundaries.
+- Reference inputs: Logos Grid supplied diagnostic context only; no motion reference. Logos Grid and other generated application snapshots remain unchanged.
+- Docs/contracts read: Runtime component and decision contracts; `schema-reference.md`; `component-rules.md`; `acceptance-testing.md`; root and generated `AGENTS.md`.
+- Contract rules applied: `controls-product-coverage`, `interaction-surface-ownership`, `layers-enabled-behavior`, `acceptance-product-observable`, `persistence-policy-explicit`, and `workflow-required`.
+- Root cause: Color UI emits `{ hex }`, while the old normalizer accepted both that payload and a string without canonicalizing them; initial/live/timeline paths did not share one schema codec. Existing whole-output selection evidence could also pass when a global or wrong entity changed.
+- Decision: Use one exhaustive built-in codec registry and one schema-aware ingress policy for defaults, seeds, live commands, persistence, settings, and keyframes. Make property scope explicitly global or selected-entity and reuse one protected two-entity raster recipe for app-owned and `selectedLayer.*` properties.
+- Alternatives rejected: Product-specific Color parsing, editing Logos Grid, a Color-only reducer branch, whole-canvas/signature evidence, one-direction selection tests, and separate layer/app selection algorithms.
+- State/output mapping: Canonical decoded values enter runtime state/history/persistence/timeline before product consumers read them. Selected-entity ownership links the property target to its selection operation; protected actions select A/B on the declared surface and bounded pixel probes prove only the selected entity changes.
+- Performance intent: ordinary-product-work. The request concerns functional integrity and supplies no performance authority.
+- Verification: Focused runtime codec/state/Color/timeline tests, starter selection validator tests, protected Canvas/Panel provenance tests, bidirectional isolation, and adversarial cross-entity mutation rejection are required before the combined functional checks and thermo-nuclear review.
+- Risks: Existing generated apps receive the corrected runtime and signed acceptance helpers only after regeneration or deliberate framework refresh. Custom product renderers must consume the canonical model and provide stable, non-overlapping entity probes for selected-entity proof.
+
 ## Decisions
 
 ### Renderer

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

@@ -38,6 +38,7 @@ Allowed app extension points:
 | `infiniteCanvasContent` | Editor-only full-viewport product environment under the Infinity world; never app UI or export content. |
 | `controlRenderers` | True custom controls only after the built-in fit check. |
 | `exportRenderer` | One deterministic scene-coordinate product frame shared by runtime image and video export. |
+| `svgExportRenderer` | Namespace-aware editable vector content for explicit runtime SVG 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. |
@@ -68,7 +69,7 @@ export const appProductReadiness = {
 } as const;
 ```
 
-Every product declaration requires `productReadiness.exportIntent`. It is the authority for exact image/video schema actions, settings sections, and artifact acceptance. Use `core/setup-export.md` for the single export-intent decision sequence; animation and timeline choices do not supply delivery intent.
+Every product declaration requires `productReadiness.exportIntent`. It is the authority for exact image/SVG/video schema actions, applicable settings sections, and artifact acceptance. Use `core/setup-export.md` for the single export-intent decision sequence; renderer technology, animation, and timeline choices do not supply delivery intent.
 
 Populate `interactionOwnership` before adding canvas handles or custom
 interactions. One operation has one primary `canvas` or `panel` surface chosen
@@ -100,7 +101,7 @@ Use `core/runtime-boundary.md` for shell boundaries, `core/media-upload.md` for
 
 If a Figma URL is provided, use Figma MCP/design context before implementation and rebuild from file structure, not from a screenshot.
 
-If a video, GIF, screen recording, contact sheet, or extracted-frame sequence is provided, write a Video Reference Study before implementation.
+If a video, GIF, screen recording, contact sheet, or extracted-frame sequence is provided, register typed `referenceInputs`, generate the protected dense study before implementation, classify its events and phases, and map behaviors to acceptance plus browser `reference-parity`. Follow `core/reference-study.md`; do not recreate its command, sampling, storage, or timing rules here.
 
 When porting an existing app, use `transferMode: "reference-runtime-clone"` unless the user explicitly asks for redesign. Declare `referenceStudy` plus `referenceFeatureInventory`, then prove each inspected reference feature with acceptance coverage. Use `core/reference-study.md` for the detailed reference, Figma, and video study rules.
 
@@ -112,7 +113,7 @@ Use `core/timeline-animation.md` for timeline mode, compact/extended timeline, s
 
 ## Renderer Work
 
-For custom renderers, write the Renderer Technique Decision Matrix and typed performance model before code. Follow one sequence: reachable controls and inputs; workload dimensions and enforced boundaries; pass cost, frequency, lifecycle, and invalidation; render-plan assessment and protected kernel benchmark when required; derived paths and combined fixtures; impact-derived functional/browser development checks; lifecycle-appropriate delivery proof. Only exact request authority may add measured targeted performance.
+For custom renderers, write the Renderer Technique Decision Matrix and typed performance model before code. Follow one sequence: reachable controls and inputs; workload dimensions and enforced boundaries; pass cost, frequency, lifecycle, and invalidation; render-plan assessment and protected kernel benchmark when required; derived paths and combined fixtures; feature-focused functional/browser development checks; first-delivery or authority-backed performance proof. Only exact request authority may add measured targeted performance.
 
 Compile one lightweight renderer pipeline registration outside test modules. Supply that exact registration as `rendererPipelineRegistration` in the composition and as `rendererPipeline` to new-envelope performance assessment. Run `assessToolcraftRenderPlan` before implementing the renderer. Derive path ids from the assessed registration and compile workload fixtures from those paths; do not classify workload by target names or author scenario-specific maxima. Renderer work uses `useToolcraftPipelinePass`; retained resources are available only from its generation-bound pass execution context. Product code never receives runtime disposal ownership.
 
@@ -120,16 +121,16 @@ Use `renderer-technique.md`, `core/performance.md`, and `performance.md` for ren
 
 ## Automatic Delivery Lifecycle
 
-Use one normal sequence: assemble or change the product, gather focused functional feedback, finish the coherent delivery batch, run protected functional delivery once, and return the app for user evaluation. Focused checks while implementation is changing do not mint delivery evidence.
+Use one normal sequence: assemble the first product, gather focused functional feedback, run protected functional delivery once, then use only feature-focused checks for later edits and return the app for user evaluation.
 
 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.
+2. Later ordinary edits run only the directly relevant product tests and browser checks. A repeated bare command exits before inventory, build, tests, export, and performance work and preserves the initial receipt.
 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.
 
-For final delivery, run:
+For first product delivery, run:
 
 ```bash
 pnpm verify:delivery

package/templates/starter/docs/toolcraft/component-rules.md

@@ -4,7 +4,7 @@
 
 ## Control Decision Catalog
 
-Use `core/control-selection.md` for the built-in fit check, exact control owners, compound-control ownership, actions, collection actions, vector ownership, and the custom control gate.
+Use `core/control-selection.md` for the built-in fit check, exact control owners, compound-control ownership, actions, collection actions, vector ownership, and the custom control gate. Built-in controls own canonical runtime values, not callback payloads: product code reads the documented model without per-renderer parsing. Plain `color` is expanded uppercase hex; invalid live values are atomic no-ops and invalid restored/imported values use the canonical default.
 
 ## Dividers
 
@@ -88,7 +88,7 @@ Use `core/layout.md` for section grouping, dependency cohesion, headers, reset,
 
 ## Colors
 
-Use `core/layout.md` for semantic color grouping, color labels, row fit, and color/opacity layout. Use `core/setup-export.md` for the authored background source pair, its runtime Setup placement, and export background behavior. For repeated built-in controls, use `sourceCollection` for a source-owned array and `collectionActions` for a user-growable array; both support `checkbox`, `color`, `colorOpacity`, `fontPicker`, `rangeInput`, `rangeSlider`, `segmented`, `select`, `slider`, `switch`, `text`, and `vector` items, while unknown item types fail schema validation. Use scalar `itemControl` for one homogeneous repeated value. A `collectionActions` control may instead use `itemControls` only when two or more built-in fields form one logical target-array record that is added or removed atomically. Runtime places a line only between adjacent compound records and leaves standalone color grids unchanged. A multiple file-kind `fileDrop` with `variant: "collection-actions"` may declare `itemControls` to render built-in settings directly below each attached file and persist per-file values keyed by `mediaId`; its upload row and settings are one logical group under the same divider rule.
+Use `core/layout.md` for semantic color grouping, color labels, row fit, and color/opacity layout. A color-only section is one implicit bank. In a mixed section with multiple plain `color` controls, every plain color declares `semanticGroup`; matching type or adjacency alone never authorizes a shared row, and runtime pairs only adjacent colors in the same group. Use `core/setup-export.md` for the authored background source pair, its runtime Setup placement, and export background behavior. For repeated built-in controls, use `sourceCollection` for a source-owned array and `collectionActions` for a user-growable array; both support `checkbox`, `color`, `colorOpacity`, `fontPicker`, `rangeInput`, `rangeSlider`, `segmented`, `select`, `slider`, `switch`, `text`, and `vector` items, while unknown item types fail schema validation. Use scalar `itemControl` for one homogeneous repeated value. A `collectionActions` control may instead use `itemControls` only when two or more built-in fields form one logical target-array record that is added or removed atomically. Runtime places a line only between adjacent compound records and leaves standalone color grids unchanged. A multiple file-kind `fileDrop` with `variant: "collection-actions"` may declare `itemControls` to render built-in settings directly below each attached file and persist per-file values keyed by `mediaId`; its upload row and settings are one logical group under the same divider rule.
 
 ## File Upload
 

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

@@ -61,6 +61,8 @@ Read this module before changing sections, labels, helper icons, inline rows, di
 - Do not add helper icons to obvious homogeneous groups when the section title and label already explain the control.
 - In toggle components, do not prefix labels with `Enable`; the switch already communicates on/off.
 - When a section title supplies the context, remove repeated nouns from nearby labels. Runtime Setup is the exception for its normalized output pair: the switch is `Background` and the color below it is `Background color`.
+- A separately rendered visible field label must not normalize to the same text as its section title. Use `label: false` when the section supplies the complete visible context, or use a more specific label when the control represents a distinct setting.
+- `tabs` keep their schema label as an accessible tab-list name and do not render it as a separate visible field label, so matching the section title is valid for tabs.
 
 ## Inline Rows
 
@@ -89,9 +91,12 @@ Read this module before changing sections, labels, helper icons, inline rows, di
 - Keep color inside the entity section when it configures the same entity as nearby controls.
 - Use a standalone color section only when color is the whole semantic section.
 - Standalone color section titles must describe product role. Never create a section titled `Color` or `Colors`.
-- Omit per-item labels such as `Color 1`, `Color 2`, or `Color 3` when colors only add variety to one shared palette/color bank.
+- A section with multiple sibling `color` or `colorOpacity` controls must not use sequential per-item labels such as `Color 1`, `Color 2`, or `Color 3`, regardless of target spelling, section title, or `semanticGroup`.
 - Keep visible labels when each color edits a distinct user-facing entity or role.
 - Apply label visibility to the whole semantic color group; do not mix labeled and unlabeled items inside one bank.
+- Matching control type and schema adjacency never prove that colors belong to one bank.
+- A section containing only color fields is one implicit color bank. In a mixed section with two or more plain `color` controls, declare `semanticGroup` on every plain color; use the same group only for colors that form one product-meaning row.
+- Runtime pairs only adjacent plain colors with the same semantic group. Conditional controls are filtered before rows are built, so an inactive color never pulls an unrelated visible color into its row.
 - Multiple related plain colors render at most two per row.
 - An odd trailing plain `color` keeps the same half-width footprint instead of stretching to full width.
 - If any color has opacity, keep it stacked instead of placing it in a two-column row.

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

@@ -104,7 +104,7 @@ Read this module before changing image upload, file upload, source material impo
 - Legacy data-URL snapshots migrate through a repository lease before a new snapshot is published. Failed migration preserves the original recoverable snapshot and reports persistence as unavailable.
 - Reset restores default model attachments through the same async import pipeline. Delete, replacement, undo, redo, reset, hydration, and active jobs participate in repository reachability and cleanup.
 - Model acceptance uses complete `modelImportCoverage` and protected browser recipes. Required proof covers every advertised format, package extraction, deterministic root selection, authored appearance, exact fallback, checked presentation readiness, nontransparent RGBA output, staged/committed output, repair diagnosis/action/progress/result, fatal preservation, persistence/unavailable restoration, preview/export parity, and history/reset.
-- Model workload and responsiveness checks derive from normalized model limits and run as targeted model paths. Package extraction and canonical decode are worker passes; presentation, orbit, export, and cleanup are main-thread/GPU passes with frame and completion budgets. The combined geometry-plus-texture envelope, cache reuse, and disposal lifecycle are measured without refreshing the full checkpoint during later functional feature work.
+- Model workload and responsiveness checks derive from normalized model limits and run as targeted model paths. Package extraction and canonical decode are worker passes; presentation, orbit, export, and cleanup are main-thread/GPU passes with frame and completion budgets. The combined geometry-plus-texture envelope, cache reuse, and disposal lifecycle are measured only with request authority; ordinary later feature work runs focused functional checks without refreshing the initial receipt.
 
 ## Canvas Source Images
 

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

@@ -1,6 +1,6 @@
 # Performance
 
-<!-- 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 -->
@@ -17,9 +17,9 @@ Use this order for every product:
 4. Render-plan assessment and capture of any protected kernel benchmark requirement.
 5. Derived paths and combined fixtures.
 6. Targeted functional and browser development checks.
-7. Lifecycle-appropriate delivery proof: first-delivery functional proof with no measured performance, later `functional-targeted` proof, or one authority-backed targeted performance iteration. Full certification is a separate explicit operator/CI action.
+7. Lifecycle-appropriate proof: complete first-delivery functional proof with no measured performance, later feature-focused checks only, or one authority-backed targeted performance iteration. Full certification is a separate explicit operator/CI action.
 
-Do not begin renderer implementation before steps 1-4 are represented in typed configuration and the render-plan assessment has no structural errors. An unresolved kernel benchmark requirement remains explicit pending work; first and later functional delivery defer it without weakening envelope, pipeline, path, fixture, or adapter validation.
+Do not begin renderer implementation before steps 1-4 are represented in typed configuration and the render-plan assessment has no structural errors. An unresolved kernel benchmark requirement remains explicit pending work; first delivery defers it without weakening envelope, pipeline, path, fixture, or adapter validation. Later edits run the focused structural tests for what they change.
 
 ## Envelope
 
@@ -61,17 +61,15 @@ 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.
+Selected image/SVG/video dimensions, decoded output quality, strict SVG validity/vector policy, 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.
+Design product module boundaries so ordinary later edits can run one focused feature test without loading unrelated product areas. Keep frequently changed defaults and domain logic outside the public `app-schema.ts` assembly module when their acceptance coverage is narrower. This organization improves feedback speed but never authorizes measured performance. 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.
+Performance-adapter-only changes 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.
 
@@ -82,7 +80,7 @@ Targeted performance iteration verification requests the compiled development fi
 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.
+- **Later ordinary edits:** run only the tests and browser checks directly relevant to the edited feature. A repeated bare command is a protected no-op that preserves the initial receipt and performance checkpoints and cannot silently invoke measured performance.
 - **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.
@@ -91,7 +89,7 @@ Store agent-produced browser diagnostics under `.toolcraft/browser-artifacts/`,
 
 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.
 
-The preferred conversational delivery boundary is `pnpm verify:delivery`. A targeted failure starts targeted diagnosis and architecture repair; it does not automatically expand into the full suite. After the selected evidence passes, return the app to the user instead of continuing speculative optimization. When two consecutive compatible protected performance iterations have passed, the runner emits an evidence-backed recommendation and the agent must offer the user a slower complete audit if performance remains unacceptable. A demonstrably broad or unlocalizable cross-system problem may justify the same offer earlier through agent judgment; a path-count threshold is not authority.
+Use `pnpm verify:delivery` for first product delivery and authority-backed targeted performance iterations, not as an ordinary later edit boundary. A targeted failure starts targeted diagnosis and architecture repair; it does not automatically expand into the full suite. After the selected evidence passes, return the app to the user instead of continuing speculative optimization. When two consecutive compatible protected performance iterations have passed, the runner emits an evidence-backed recommendation and the agent must offer the user a slower complete audit if performance remains unacceptable. A demonstrably broad or unlocalizable cross-system problem may justify the same offer earlier through agent judgment; a path-count threshold is not authority.
 
 `pnpm verify:perf` is the single protected operator/CI full-audit command: it performs one fresh production build, runs maximum fixtures across every canonical path, writes `full-performance` evidence, and creates or refreshes the durable baseline without advancing the delivery anchor. It runs only after an explicit natural-language request for the complete audit or explicit acceptance of the agent's offer; the user does not need to know the command name. A complaint, repeated complaint, filename, diagnostic classification, or changed subsystem alone never authorizes it. The full audit is diagnostic and certification evidence, not an automatic optimization loop: repair failed paths with focused checks, then run the complete matrix once at the requested certification boundary.
 

package/templates/starter/docs/toolcraft/core/reference-study.md

@@ -74,28 +74,89 @@ Required flow:
 
 Do not implement a Figma design by eye from an image, screenshot, exported PNG, or rough visual memory.
 
-## Video References
-
-When the prompt provides a video, GIF, screen recording, contact sheet, or extracted-frame sequence, study it as behavior before implementation.
-
-Write a Video Reference Study before coding. Record:
-
-- `referenceLocation`;
-- `extractionEvidence`;
-- `storyboard` with timecoded frames, visible state, and behavior observations;
-- `transitionAnalysis` with frame-to-frame deltas;
-- `behaviorDecomposition`;
-- `acceptanceMapping`.
-
-The transition analysis explains what changes between frames: entities, anchors, state persistence, releases, retargeting, input, timeline state, and copied behavior.
-
-Do not implement video references from a single screenshot, generic visual summary, or a few static style observations.
-
-## Acceptance Mapping
+## Video References And Motion Evidence
+
+Every supplied video, GIF, screen recording, contact sheet, or extracted-frame
+sequence is one typed `referenceInputs` item. Preprocess it before product code:
+
+```bash
+pnpm reference:study -- --source /absolute/path/reference.mp4
+```
+
+The protected command accepts exactly one absolute `--source`. Use `--kind`
+with `video`, `gif`, `screen-recording`, `frame-sequence`, or `contact-sheet`
+when detection is unavailable or the source meaning must be explicit. A contact
+sheet also requires `--grid columnsxrows`. Image sources use at most one timing
+authority: `--fps number` or `--timestamps-file /absolute/path/times.json`.
+Timed sources may add one `--segment start:end` and repeated
+`--focus start:end` windows. All ranges are seconds, bounded by the inspected
+source, and focus windows remain inside the selected segment.
+
+The command performs one full-frame source scan. It measures change across
+every decoded frame, keeps a dense 12 FPS overview, expands detected events and
+explicit focus windows, and materializes the union once. A study contains at
+most 120 reviewed frames; larger reviews become a content-addressed partition
+group with one shared plan and atomic publication. This bound limits sheet
+legibility, not source inspection: no source interval is skipped by the scan.
+
+Each committed study owns exactly two generated resources under
+`src/app/reference-studies/<studyId>/`:
+
+- `evidence.json` — canonical source identity, timing, reviewed frames, dense
+  overview, detected events, partition identity, and tool versions;
+- `contact-sheet.png` — the normalized reviewed-frame sheet cited by that JSON.
+
+Both resources are product-owned evidence, not protected framework trust roots.
+Do not edit them by hand. Rerun the command from the original source; publication
+replaces the complete study group or preserves the previous complete group.
+
+Timed video, GIF, and screen-recording evidence uses decoded timestamps.
+Frame sequences and contact sheets use `seconds` timing only with declared FPS
+or strictly increasing timestamps; otherwise they use `ordinal` timing.
+Declared timestamps are normalized to a zero origin while their original file
+hash remains recorded. Make duration, speed, cadence, easing, or loop-seam
+claims only from a seconds-timed study.
+
+After generation, import the checked evidence JSON and author the semantic
+layer in `starterTransferMode.referenceInputs`:
+
+- cover the complete ordered overview with contiguous `phases` and describe
+  each visible state;
+- classify every detected event exactly once as `product-behavior`,
+  `edit-boundary`, `encoding-artifact`, or `irrelevant-change`;
+- attach product events and phases to explicit behaviors;
+- map every behavior bidirectionally to one observable acceptance row through
+  `acceptanceId` and `motionReferenceCoverage`;
+- require the mapped browser row to prove `reference-parity` against the
+  inspected reference, not a generic screenshot or canvas hash.
+
+Review seconds-timed studies at real time. Also review them slowed when a
+detected product event or a timing claim needs transition detail. Review
+ordinal studies as ordered frames. Record one exact worklog line per study:
+
+```md
+- Motion reference study: referenceId=<referenceId>; studyId=<studyId>; sourceSha256=<sha256>; timingMode=<seconds|ordinal>; contactSheetPath=<path>; review=<real-time|real-time+slowed|ordered-frames>
+```
+
+The evidence JSON and contact sheet remain resources cited by product-authored
+`referenceInputs`. The command entrypoint and public evidence decoder plus its
+declaration are explicit trust-root sentinels. Transitive sampling, media,
+protocol, staging, and publication modules are not additional sentinels; the
+canonical framework inventory discovers and signs them automatically. Product
+code must not duplicate preprocessing, validators, or artifact publication.
+
+For a product with no motion reference, declare `referenceInputs: []`. This is
+the no-reference fast path: do not invoke FFmpeg, run `pnpm reference:study`,
+create placeholder evidence, or add `reference-parity` requirements.
+
+## Behavior and Acceptance Mapping
 
 Every reference feature maps to acceptance coverage.
 
-Each `acceptanceMapping` item points to a real acceptance row that proves the copied behavior with automated and browser coverage.
+Each authored behavior in `referenceInputs[].behaviors` names its observable
+acceptance row through `acceptanceId`. That acceptance row maps back to the same
+`referenceId` and behavior through `motionReferenceCoverage`, and its browser
+proof must emit `reference-parity` evidence against the inspected reference.
 
 The port is incomplete until inventory and acceptance coverage prove that reference functionality was reviewed and transferred.
 

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

@@ -25,6 +25,7 @@ Use only these app-specific extension points. Shared runtime changes happen upst
 - 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;
 - one `exportRenderer` that draws a deterministic product frame for runtime-owned image/video export;
+- one `svgExportRenderer` that appends namespace-aware editable vector content for runtime-owned SVG export;
 - one `sceneBoundsProvider` that returns exact-state product world-space rectangles for infinite preview and runtime-owned 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;
@@ -37,7 +38,7 @@ Use only these app-specific extension points. Shared runtime changes happen upst
 - Do not import anything below `src/toolcraft/ui/components/controls/**` (or the equivalent workspace package path), even when the private symbol name is not a public control. Private popovers, parsers, inputs, and state helpers are implementation details.
 - Do not substitute native or primitive `input` types `color`, `range`, `file`, `checkbox`, or `radio`, or native `select`/`textarea`, for schema controls. Generic text inputs and product-specific primitives remain available inside a justified custom interaction.
 - 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.
+- Do not create product-owned export canvases/documents, SVG serializers, encoders, file pickers, object-URL downloads, or direct Mediabunny integrations; runtime owns typed image/SVG/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

@@ -1,6 +1,6 @@
 # Setup, Background, And Export
 
-Read this module before changing Setup, canvas sizing, background, image export, video export, sticky actions, render scale, or timeline visibility.
+Read this module before changing Setup, canvas sizing, background, image export, SVG export, video export, sticky actions, render scale, or timeline visibility.
 
 ## Runtime Setup
 
@@ -24,7 +24,7 @@ Read this module before changing Setup, canvas sizing, background, image export,
 - Runtime aspect presets apply canonical canvas sizes; `16:9` is `1920x1080`.
 - A prompt-provided, reference, fixed-format, or base/default size is only the initial `canvas.size`.
 - Fixed/reference/base dimensions are not reasons to hide `Aspect ratio`, `Canvas width`, or `Canvas height`.
-- Manual Canvas width/height edits keep the typed dimension, keep the other dimension unchanged, switch Aspect ratio to Custom, and show the reduced current ratio in the custom ratio inputs.
+- Manual Canvas width/height edits keep the typed dimension, keep the other dimension unchanged, switch Aspect ratio to Custom, and store the reduced current ratio in runtime state. The Aspect ratio control shows `Custom` without a second numeric pair; `Canvas width` and `Canvas height` are the sole custom dimension editors.
 
 ## Infinity Canvas
 
@@ -35,13 +35,13 @@ Read this module before changing Setup, canvas sizing, background, image export,
   bounded scene geometry may use `ToolcraftAppComposition.infiniteCanvasContent`.
   Runtime mounts it only in Infinity mode, below the transformed product world,
   across the full viewport, with pointer input disabled. It does not pan, zoom,
-  contribute to `sceneBoundsProvider`, or enter image/video export.
+  contribute to `sceneBoundsProvider`, or enter image/SVG/video export.
 - 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 for the supplied exact frame state; do not use a registry, DOM measurement, or app-authored time-range envelope.
 - Runtime resolves that provider for the live committed state and positions one product scene surface at the exact union. Product output fills that surface; it does not create another absolute wrapper or reuse dormant finite `canvas.size` in infinite mode.
 - Canvas 2D, WebGL, and WebGPU renderers call `useToolcraftProductSceneFrame()` inside `canvasContent` and use its rect for backing dimensions plus world-to-local translation. The hook reports finite, infinite, empty, or unavailable explicitly; empty/unavailable infinite frames do not silently render through finite fallback geometry.
-- 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.
+- Infinite PNG and SVG export crop 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. SVG still requires the product to author real vector content; runtime media/model pixels are not silently traced or wrapped in SVG.
 - 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 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.
@@ -80,6 +80,7 @@ Read this module before changing Setup, canvas sizing, background, image export,
 - 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.
 - Runtime image export reads Background directly: PNG can be transparent, while JPG remains opaque.
+- Runtime SVG export reads Background directly: enabled output gets one runtime-owned vector background rectangle; disabled output remains transparent.
 - Runtime video export keeps the selected background even when Background is off.
 
 ## Artifact Export Intent
@@ -87,21 +88,24 @@ Read this module before changing Setup, canvas sizing, background, image export,
 Use this sequence as the single authority for choosing product artifact delivery:
 
 1. Start every product with image export.
-2. Add video export only when the user explicitly requests video delivery.
-3. Do not infer video from animation, playback, keyframes, or timeline.
-4. Keep image with video unless the user explicitly requests removal.
-5. Record in `productReadiness.exportIntent`.
+2. Add SVG export only when the user explicitly requests SVG delivery.
+3. Add video export only when the user explicitly requests video delivery.
+4. Do not infer SVG from an SVG preview renderer, or video from animation, playback, keyframes, or timeline.
+5. Keep image with requested SVG/video unless the user explicitly requests image removal.
+6. Record all three decisions in `productReadiness.exportIntent`.
 
-Product-mode readiness requires both discriminated decisions. Image uses `toolcraft-default`, `user-requested`, or `user-removed`: `user-requested` requires non-empty user-request evidence, and `user-removed` requires non-empty explicit user-removal evidence. Video uses `not-requested` or `user-requested`; `user-requested` requires non-empty explicit user-request evidence. Do not add optional modes, legacy fallbacks, or schema-derived inference. Resolved intent must correspond exactly to runtime-owned schema actions, settings sections, and artifact acceptance:
+Product-mode readiness requires all three discriminated decisions. Image uses `toolcraft-default`, `user-requested`, or `user-removed`: `user-requested` requires non-empty user-request evidence, and `user-removed` requires non-empty explicit user-removal evidence. SVG and video each use `not-requested` or `user-requested`; `user-requested` requires non-empty explicit user-request evidence. Do not add optional modes, legacy fallbacks, or schema-derived inference.
+
+Image/video settings keep their existing base layout:
 
 | Resolved delivery | Settings layout | Sticky export actions | Artifact acceptance |
 | --- | --- | --- | --- |
 | Image only | `Image Export` directly above sticky actions | `Export PNG` primary | Complete image coverage only |
 | Image and video | `Image Export` immediately before `Video Export`; `Video Export` directly above sticky actions | `Export PNG` secondary, `Export Video` primary | Complete image and video coverage |
 | Video only | `Video Export` directly above sticky actions | `Export Video` primary | Complete video coverage only |
-| Explicit no-export | No image or video settings section | No image or video export action | No image or video artifact row |
+| Explicit no image/video | No image or video settings section | No image or video export action | No image or video artifact row |
 
-Video-only requires non-empty evidence for both the explicit video request and explicit image removal. Explicit no-export requires non-empty image-removal evidence and video `not-requested`.
+SVG is an orthogonal enabled capability: add one typed `Export SVG` action and complete SVG artifact row, but no SVG settings section. It joins the existing sticky actions without changing Image Export/Video Export adjacency. SVG-only requires explicit SVG request evidence plus explicit image removal and video `not-requested`. Explicit no-export requires non-empty image-removal evidence with SVG/video both `not-requested`.
 
 ## Image Export
 
@@ -131,10 +135,36 @@ Video-only requires non-empty evidence for both the explicit video request and e
 - 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.
 
+## SVG Export
+
+- Only products with SVG `user-requested` intent and non-empty explicit request evidence expose `Export SVG`.
+- SVG means a standalone, self-contained, editable vector artifact. Raster-in-SVG (`image`, data URLs), `foreignObject`, scripts, event handlers, animation elements, external resources, and external `url(...)` references are rejected.
+- SVG has no export settings section. Runtime derives `width`, `height`, and `viewBox` from the same finite or Infinity scene frame used by artifact export.
+- Use a typed `export-svg` sticky action and provide `ToolcraftAppComposition.svgExportRenderer`. The product callback appends namespace-aware vector nodes only to the supplied detached group:
+
+```ts
+export const svgExportRenderer = {
+  baseFileName: "column-graph",
+  renderFrame: ({ container, frame, state }) => {
+    const rect = container.ownerDocument.createElementNS("http://www.w3.org/2000/svg", "rect");
+    rect.setAttribute("data-column-track", "true");
+    rect.setAttribute("x", String(frame.x)); rect.setAttribute("y", String(frame.y));
+    rect.setAttribute("width", String(frame.width));
+    rect.setAttribute("height", String(frame.height));
+    rect.setAttribute("fill", String(state.values["appearance.foreground"]));
+    container.append(rect);
+  },
+} satisfies ToolcraftProductSvgExportRenderer;
+```
+
+- Product code never receives the final `<svg>` root and never serializes XML, constructs the Blob, opens a file picker, creates an object URL, or downloads the artifact. Runtime owns root/frame/background assembly, strict validation and reparse, serialization, progress, typed failures, and `.svg` download.
+- Canvas 2D, WebGL, WebGPU, photos, videos, and models are not automatically vectorized. If the requested product output cannot be represented as vector geometry/text, record the incompatibility instead of emitting a fake SVG.
+- Acceptance declares `all-required-svg-export-behavior` and uses `expectToolcraftSvgExportArtifact` on the real Playwright `Download`. The protected recipe verifies the exact downloaded bytes, `.svg` filename, strict XML/namespace, dimensions/viewBox, vector-only self-containment, native decode, SHA-256 hash, and non-empty exact product element expectations before attaching `svg-export-artifact` evidence. Generic exported-artifact evidence cannot satisfy this requirement.
+
 ## Sticky Product Actions
 
-- Export actions in sticky `panelActions` match the resolved artifact intent exactly. Explicit no-export products have no image or video export action.
+- Export actions in sticky `panelActions` match the resolved artifact intent exactly. Explicit no-export products have no image, SVG, or video export action.
 - Clipboard copy may be an additional product action, but it never changes or substitutes for the recorded artifact intent.
-- Export PNG and Export Video use `icon: "upload-simple"` to match the runtime `Export Settings` action.
+- Export PNG, Export SVG, and Export Video use `icon: "upload-simple"` to match the runtime `Export Settings` action.
 - 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.

package/templates/starter/docs/toolcraft/decision-contract.md

@@ -23,7 +23,7 @@ Use this before writing a schema, spec, or implementation plan. It separates har
 | Timeline | Heuristic, then invariant | Choose from Animation Intent Inventory and transport behavior |
 | Controls | Mixed | Bind every visible control, choose one evidence-backed surface per operation, and make artifact UI match required export intent |
 | Renderer | Default plus invariant | Choose technique from fidelity/workload and declare spatial view interaction before renderer code |
-| Reference analysis | Invariant | Study video references as frame-to-frame behavior before implementation |
+| Reference analysis | Invariant | Register typed motion-reference evidence, classify complete behavior, and prove browser parity before implementation |
 | Reference clone | Invariant | Preserve reference behavior unless redesign is explicit |
 | Acceptance | Invariant | Prove product observables, not only runtime mutation |
 | Performance | Mixed | Workload controls need enforced envelope boundaries; derived paths receive central profiles; animated previews yield to viewport interactions |
@@ -36,7 +36,7 @@ The runtime shell invariant means product code exports the typed composition and
 
 This catalog mirrors `TOOLCRAFT_DECISION_CONTRACT`. If runtime adds or renames a rule id, this page and `AGENTS.md` must list the same id.
 
-`output-export-required` keeps artifact intent and implementation in exact correspondence. Product-mode readiness records `productReadiness.exportIntent`; schema actions, settings sections, and artifact acceptance expose exactly the enabled image/video capabilities. The authoritative decision sequence and evidence requirements live in `core/setup-export.md`.
+`output-export-required` keeps artifact intent and implementation in exact correspondence. Product-mode readiness records `productReadiness.exportIntent`; schema actions, applicable settings sections, and artifact acceptance expose exactly the enabled image/SVG/video capabilities. SVG is explicit-request-only and means self-contained editable vectors. The authoritative decision sequence and evidence requirements live in `core/setup-export.md`. `interaction-surface-ownership` classifies property edits as global or selected-entity; selected properties name their selection interaction and prove bidirectional isolation with two entities. `layers-enabled-behavior` reuses that proof for `selectedLayer.*`.
 
 [//]: # (toolcraft-contract:decision-rule-table:start)
 | Rule ID | Level | Area |