@pixel-point/toolcraft 0.0.17 → 0.0.19

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

@@ -4,11 +4,10 @@ Read this module before changing sections, labels, helper icons, inline rows, di
 
 ## Sections
 
-- Build controls-panel sections from product entities and workflow stages, not component types.
-- Before writing controls, export `starterControlSectionInventory`. Each product section declares title, product entity or workflow stage, targets, and grouping reason.
-- Keep sections discrete. Two to seven product controls is the normal size.
-- Split sections that grow past seven controls or mix several meanings.
-- In a section larger than seven controls, every control declares `semanticGroup`. One tightly scoped product sub-entity/workflow shares one group; mixed groups are structural evidence that the section should split. Do not infer this from labels.
+- Build controls-panel sections from logical product entities, not component types, visual control size, or target namespaces. Before writing controls, export `starterControlSectionInventory`; every section declares stable `entityId`, human-readable `entity`, exact targets, and `groupingReason`.
+- One to seven controls is the normal section size. Eight to ten controls are allowed for one cohesive entity and require `semanticGroup` on every control. Ten controls is the hard maximum.
+- One entity with ten or fewer controls stays in one section. Different source, settings, placement, or presentation roles do not create sections by themselves.
+- An entity above ten controls splits into balanced workflow sections containing two to ten controls. Every split section keeps the same `entityId` and `entity` and declares a unique `workflowStage` plus concrete `splitReason`; it may not leave a one-control tail. A one-control section is valid only when that control is the entity's complete editable surface.
 - Do not reuse the same section title for multiple sections.
 - Bad titles: `Controls`, `Settings`, `Options`, `Sliders`, `Inputs`, `Buttons`, `Color`, `Colors`.
 - Good titles name the edited thing: `Background`, `Object`, `Token Pattern`, `Motion`, `Tone Mapping`, `Export`.
@@ -17,8 +16,9 @@ Read this module before changing sections, labels, helper icons, inline rows, di
 
 ## Dependency Cohesion
 
+- Typed `entityId` is the primary authority for section cohesion. Target-prefix checks are secondary diagnostics and never redefine an inventory entity.
 - A selector that controls mode, type, source, variant, or include state stays with the controls it gates when they share the same product entity.
-- Use `visibleWhen` for inactive product branches so the panel shows only usable controls.
+- Declare conditional control applicability for inactive product branches so the panel shows only usable controls while preserving hidden values.
 - Do not create a separate section that merely mirrors one selector option unless that branch is a genuinely separate product entity with its own workflow evidence.
 - A section with no visible controls is hidden automatically.
 - Do not use `disabled: true` or `disabledWhen` for generated product controls.
@@ -50,7 +50,7 @@ Read this module before changing sections, labels, helper icons, inline rows, di
 - If a section contains exactly one control, simple or compound, render only the parent section dividers.
 - Do not add full-width borders inside a compound control.
 - Do not put dividers only around an internal subsection such as Gradient Stops.
-- Small compound fields such as `colorOpacity` and `rangeInput` stay inline fields without section dividers.
+- Small compound fields such as `colorOpacity` and `rangeInput` stay inline fields without section dividers. Repeated `collectionActions` records built from `itemControls` use one content-width line only between adjacent logical records, with 18px spacing on each side and no generated item heading. A FileDrop collection slot and its per-file settings use the same group boundary. Standalone color `itemControl` grids have no item dividers.
 
 ## Labels And Help
 
@@ -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

@@ -51,6 +51,7 @@ Read this module before changing image upload, file upload, source material impo
 - Multiple image uploads render as a sortable four-column thumbnail grid.
 - The add-more tile is last.
 - Per-image removal stays inside the file control.
+- When the product explicitly requires the compact cardinality pattern used by `collectionActions`, set `variant: "collection-actions"` on an `assetKind: "file"` control with `multiple: true`. Its header `+` adds one empty FileDrop slot and `−` removes the final slot or its attached file; the wide add row and per-item remove actions are omitted so cardinality has one owner. When every attached file owns settings, declare built-in `itemControls` with a `defaultValue` for every entry: attached files render those settings directly below their upload row, empty pending slots render no settings, the parent target stores value records keyed by `mediaId`, and runtime media keeps ownership of file bytes and lifecycle. The upload row and its per-file settings form one logical group; runtime renders one content-width line only between adjacent groups and never adds `Item N` headings. Product renderers join both slices by `mediaId`; do not collapse per-file settings into a global sibling section.
 - Dragging thumbnails updates runtime media order.
 - Product renderers and exports consume runtime media order instead of keeping a separate product-only order.
 
@@ -60,6 +61,7 @@ Read this module before changing image upload, file upload, source material impo
 - Long filenames fade/truncate at the end instead of hard-clipping.
 - The last item has no bottom separator.
 - The add row is part of the file control and uses the same width and hover behavior as list rows.
+- The `variant: "collection-actions"` opt-in replaces that add row and the per-row remove buttons with the compact header `− / +` controls while preserving runtime media order.
 - When an app contains both image and file uploaders, canvas drops route by asset kind:
   - image files prefer visible image uploaders;
   - non-image files prefer visible file uploaders;
@@ -102,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

@@ -18,30 +18,42 @@ Use only these app-specific extension points. Shared runtime changes happen upst
 - schema controls;
 - schema `canvas`, `panels`, `toolbar`, `panelActions`, `persistence`, `media`, `assembly`, and transfer-mode metadata;
 - `canvasContent` for product output only;
+- `infiniteCanvasContent` for editor-only product output that must fill the
+  complete Infinity viewport without inheriting world pan, zoom, product scene
+  bounds, or export bounds;
 - `renderDefaultCanvasMedia={false}` only when a product renderer replaces generic image/file preview; it does not suppress runtime model layers;
 - typed `modelPresentation`, with `{ mode: "runtime" }` as the default standard preview/export owner or `{ mode: "custom", consumers }` for declared model targets with checked consumers;
 - `controlRenderers` only for true custom controls that pass the built-in fit check;
 - 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;
-- runtime commands and hooks.
+- runtime commands and hooks, including `useToolcraftProductSceneFrame` inside `canvasContent` when a raster/WebGL renderer needs the active finite or infinite frame.
 
 ## Forbidden Rebuilds
 
 - Do not hand-compose `ToolcraftRoot`, `CanvasShell`, `ControlsPanel`, `LayersPanel`, `TimelinePanel`, `ToolbarPanel`, or panel containers in product routes.
 - Do not render built-in control components such as `SliderControl`, `SelectControl`, `ColorControl`, `GradientControl`, `FontPickerControl`, `FileDropControl`, or `PanelActionsControl` directly in app code.
+- Do not 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
 
 - `canvasContent` contains product output only: WebGL, Canvas 2D, SVG, DOM product text, shaders, generated previews, export previews, or product editing handles.
+- `infiniteCanvasContent` follows the same product-output-only rule. Runtime
+  mounts it only in Infinity mode as a pointer-transparent viewport layer below
+  the transformed world. It is not a scene-bounds or export extension point.
 - App UI, CTAs, upload prompts, helper copy, placeholder instructions, buttons, menus, forms, and settings do not belong in `canvasContent`.
 - If upload/import is part of the source-material flow, the pre-content canvas stays neutral and runtime-backed. Upload affordance belongs in `fileDrop`.
 - DOM product text rendered inside `canvasContent` must be marked with `data-toolcraft-product-output` or `data-toolcraft-product-text` so tests and performance fixtures can target product output instead of app chrome.
 - Product editing handles must be textless overlays, write to runtime state, and stay out of export/copy output.
 - Preserve the runtime canvas backing. Product renderers may draw their own product background, but must not hide, replace, or make the Toolcraft canvas shell/backing transparent.
+- Runtime owns the product scene surface. In infinite mode it resolves `sceneBoundsProvider` for the exact committed state and applies that frame before mounting product output. Product code does not position another scene wrapper from `canvas.size` or DOM measurement.
+- Canvas 2D, WebGL, and WebGPU product output reads `useToolcraftProductSceneFrame()` for backing size and world-to-local translation. Finite frames are `{ x: 0, y: 0, width: canvas.size.width, height: canvas.size.height }`; infinite frames use the provider union. `empty` and `unavailable` are explicit states and never fall back to dormant finite dimensions.
 
 ## Model Presentation Boundary
 
@@ -65,7 +77,7 @@ Use only these app-specific extension points. Shared runtime changes happen upst
 - Generated applications keep their public entry surface in `src/app/app-composition.tsx` and `src/app/app-schema.ts`. Supporting product modules may live anywhere under `src`; every product production module is discovered by the same source inventory and checked by the same AST boundary.
 - The signed framework bootstrap includes `index.html`, `src/main.tsx`, `src/router.tsx`, `src/routes/index.tsx`, `src/routes/root.tsx`, and `src/styles.css`. Do not edit or replace those host files in a generated app.
 - Product styling is local by construction: use locally imported `*.module.css` files only. Every selector starts with a compound containing a local class. A first-compound `:is()` or `:where()` remains local only when every branch is locally anchored; `:not()` and `:has()` do not create a local anchor. Descendants may style product-owned children, but `:global`, bare/root selectors, host-attribute selectors, sibling escapes, CSS `@import`, package CSS imports, and product-created global `<style>`/`CSSStyleSheet` injection are rejected because they cross the product/runtime boundary.
-- Product `import()` and `require()` specifiers must be statically resolvable from literals, same-file constants, templates, or string concatenation. Production and test source share this rule, so computed module loading cannot hide a runtime/control import or a protected evidence channel.
+- Product `import()` and `require()` specifiers must be statically resolvable from literals, same-file constants, templates, or string concatenation. Production and test source share this rule, so computed module loading cannot hide a runtime/control import or a protected evidence channel. Every deep control implementation import is rejected regardless of imported symbol name, and JSX control-substitute checks follow public `Input` aliases.
 - Product production modules must not import product tests, test-support modules, or protected browser-evidence internals, directly or through a product bridge. Runtime evidence is emitted only by the protected public acceptance/performance helpers after their assertions pass; product-owned source must not import, re-export, assemble, or forge the reserved evidence module names and payload identifiers.
 - Product production modules must form an acyclic dependency graph. The code-health gate resolves relative imports, directory `index.*` modules, configured TypeScript path aliases, and local package exports. Type-only imports, external packages, tests, and copied Toolcraft framework internals do not create product dependency edges. When a cycle exists, the gate prints the complete shortest cycle so the ownership boundary can be corrected directly.
 - Imported product source remains under `src`. Code health and product-boundary analysis consume the same canonical source-inventory semantics instead of maintaining independent recursive walkers. The signed Vitest reporter uses the canonical framework-ownership policy to distinguish product-owned runner results, while acceptance and performance requirements derive from typed app configuration.

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,17 +24,24 @@ 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
 
 - `Infinity canvas` is the one runtime-owned mode switch for an unbounded workspace. Product code does not mirror it in `state.values` or create another canvas-mode control.
 - Turning it on removes the finite artboard boundary and clipping. `Aspect ratio`, `Canvas width`, and `Canvas height` disappear because they do not constrain the workspace.
 - Infinity canvas suppresses the bounded product-rendered preview background so the dormant finite output does not appear as a second canvas. While Background is on, `CanvasShell` fills the complete infinite viewport with the selected `Background color`; product code must not draw a synthetic workspace rectangle.
+- Product output that semantically represents an editor environment rather than
+  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/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.
-- 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.
+- 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 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.
@@ -73,15 +80,40 @@ 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
+
+Use this sequence as the single authority for choosing product artifact delivery:
+
+1. Start every product with image export.
+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 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 image/video | No image or video settings section | No image or video export action | No image or video artifact row |
+
+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
 
 - Every app with `Export PNG` exposes a separate `Image Export` section.
 - `Image Export` uses two `select` controls in one compact two-column inline row:
   - `export.image.format`, default `png`, with baseline `PNG` and `JPG` options;
   - `export.image.resolution`, default `4k`, with baseline `2K`, `4K`, and `8K` options.
-- Still-output apps place `Image Export` directly above sticky footer actions.
+- Image-only apps place `Image Export` directly above sticky footer actions.
 - Apps with both image and video export place `Image Export` immediately before `Video Export`.
 - Typed `export-image` actions are handled by the runtime. It resolves the current scene frame, selected format and resolution, allocates the exact backing, composites background plus visible runtime media/models, awaits `ToolcraftAppComposition.exportRenderer`, encodes the selected artifact, downloads it, and reports typed progress/failures.
 - Product code supplies only the shared deterministic `exportRenderer.renderFrame` callback in scene coordinates. It must not allocate an export canvas, call `toBlob`/`toDataURL`, create object URLs, or download the artifact.
@@ -89,9 +121,9 @@ Read this module before changing Setup, canvas sizing, background, image export,
 
 ## Video Export
 
-- Product apps whose requested delivery includes animation expose `Export Video` and `Export PNG`; timeline playback alone does not require video delivery.
+- Only products with video `user-requested` intent and non-empty explicit user-request evidence expose `Export Video`; animation and timeline behavior do not authorize it.
 - Any app with `Export Video` must enable the top Toolcraft timeline.
-- Apps with `Export Video` expose a separate `Video Export` section directly above sticky footer export buttons, after `Image Export`.
+- Apps with `Export Video` expose a separate `Video Export` section directly above sticky footer actions. When image export is also enabled, `Image Export` sits immediately before it.
 - `Video Export` uses two `select` controls in one compact two-column inline row by default:
   - `export.video.format`, default `mp4`, with baseline `MP4` and `WebM` options;
   - `export.video.resolution`, default `current`, with baseline `Current` and `4K` options.
@@ -103,12 +135,36 @@ Read this module before changing Setup, canvas sizing, background, image export,
 - 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
 
-- Product apps always expose export in sticky `panelActions`.
-- Every product exposes `Export PNG`.
-- Products whose requested delivery includes animation also expose `Export Video`.
-- Clipboard copy is optional and never replaces export.
-- Export PNG and Export Video use `icon: "upload-simple"` to match the runtime `Export Settings` action.
+- 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, 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/custom-controls.md

@@ -4,11 +4,13 @@
 
 Use a custom control only when no built-in Toolcraft control represents the product interaction.
 
-Built-ins come first: `slider`, `rangeSlider`, `select`, `segmented`, `switch`, `checkbox`, `color`, `colorOpacity`, `vector`, `gradient`, `curves`, `fontPicker`, `imagePicker`, `fileDrop`, `text`, `code`, `rangeInput`, `palette`, `actions`, `collectionActions`, and `panelActions`.
+Built-ins come first: `slider`, `rangeSlider`, `select`, `segmented`, `switch`, `checkbox`, `color`, `colorOpacity`, `vector`, `gradient`, `curves`, `fontPicker`, `imagePicker`, `fileDrop`, `text`, `code`, `rangeInput`, `palette`, `actions`, `sourceCollection`, `collectionActions`, and `panelActions`.
 
 Register custom renderers through `ToolcraftApp controlRenderers`.
 
-Do not use `controlRenderers` to recreate a built-in control. If the product needs a slider, select, segmented mode picker, color input, gradient editor, font picker, image upload, arbitrary file upload, textarea, local action group, repeatable item add/remove, or footer action, declare the matching schema control instead of rendering the component manually.
+Do not use `controlRenderers` to recreate a built-in control. If the product needs a slider, select, segmented mode picker, color input, gradient editor, font picker, image upload, arbitrary file upload, textarea, local action group, source-sized repeated item editor, repeatable item add/remove, or footer action, declare the matching schema control instead of rendering the component manually.
+
+Product modules never import deep paths below `src/toolcraft/ui/components/controls/**` and never replace schema value models with native `color`, `range`, `file`, `checkbox`, `radio`, `select`, or `textarea` controls. If a built-in lacks a required variant, improve the shared runtime instead of copying its private popover, parser, history, or state mechanics.
 
 Do not edit `ControlsPanel`, copied `src/toolcraft`, or Toolcraft internals inside a generated app.
 
@@ -40,7 +42,7 @@ builtInFitCheck: {
     "commands",
     "custom-value-model",
   ],
-  checkedBuiltIns: ["fileDrop", "collectionActions", "imagePicker"],
+  checkedBuiltIns: ["fileDrop", "sourceCollection", "collectionActions", "imagePicker"],
   closestBuiltIn: "fileDrop",
   whyInsufficient:
     "FileDrop imports, previews, orders, and removes source files, but this product also needs per-glyph density thresholds stored with each item.",
@@ -51,7 +53,7 @@ builtInFitCheck: {
 
 `capabilities` is required and uses broad behavior facts: `collection`, `reorder`, `selection`, `commands`, `custom-interaction`, `custom-value-model`, or `custom-visualization`. At least one of the three `custom-*` capabilities must explain why built-ins cannot own the interaction. `checkedBuiltIns` must name real Toolcraft built-in controls. `closestBuiltIn` must be one of those checked controls or `"none"` when no built-in is meaningfully close. `whyInsufficient` explains the missing interaction. `productObservable` names the output or side effect that proves the custom control is necessary.
 
-If the custom control owns a growable, removable, selectable, or reorderable runtime item set, `checkedBuiltIns` must include both `collectionActions` and `actions`. Decide this from the value model and workflow, such as arrays, `{ items: [...] }` objects, selected-item state, or add/remove/reorder behavior, not from entity names like masks or glyphs. This applies even when the empty state visually looks like a few icon buttons: the fit check must prove why `collectionActions` cannot own the runtime list and why `actions` alone cannot represent the collection state.
+If the custom control owns a repeated runtime item set, `checkedBuiltIns` must include `sourceCollection` and `collectionActions` so the fit check distinguishes source-owned from user-owned cardinality. Include `actions` when the custom interaction also exposes commands. Decide this from the value model and workflow, such as arrays, `{ items: [...] }` objects, selected-item state, or add/remove/reorder behavior, not from entity names like masks or glyphs. This applies even when the empty state visually looks like a few icon buttons: the fit check must prove why neither built-in collection owner can represent the state and why command UI is necessary when commands exist.
 
 Do not justify a custom control with icons, layout, styling, compactness, or custom buttons alone. If the built-in control has the right value model and mechanics, use it or improve that built-in instead.
 

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

@@ -21,9 +21,9 @@ Use this before writing a schema, spec, or implementation plan. It separates har
 | Panels | Mixed | Panel mechanics are hard; panel presence is product-dependent |
 | Layers | Heuristic, then invariant | Enable only for real layer behavior; fully test when enabled |
 | 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 prove product output 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,6 +36,8 @@ 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, 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 |
 | --- | --- | --- |