@pixel-point/toolcraft 0.0.17 → 0.0.18

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

@@ -26,9 +26,12 @@ The exported starter may keep `appProductReadiness.mode: "starter"` only while i
 
 - `productName`;
 - `productSummary`;
-- `requestedBehavior`.
+- `requestedBehavior`;
+- required `exportIntent`;
 - `viewInteraction`.
 
+`productReadiness.exportIntent` is the typed authority for artifact delivery. Acceptance, schema actions, and export settings must correspond exactly to its resolved image and video capabilities. The evidence-bearing modes and decision sequence live in `core/setup-export.md`; do not infer export intent from animation or timeline state.
+
 `viewInteraction` classifies the product as `non-spatial`, `orbit`,
 `fixed-camera`, or `timeline-camera`. Editable spatial scenes default to orbit;
 fixed/timeline modes require explicit request/reference evidence.
@@ -96,7 +99,7 @@ Slider and range slider rows must prove live behavior. Browser tests should drag
 
 ## Infinity Canvas Coverage
 
-Every editable-output app proves `infinityCanvasCoverage` mode/restoration. With Background, proof changes its color, verifies the infinite viewport, turns it off to restore finite mode/disable Infinity, then on without enabling Infinity. Image/video proof decodes scene-bounds output from `sceneBoundsProvider`; runtime video unions exact bounds from every scheduled frame state. Fixed recipes cover excluded content and exact empty, unavailable, and oversized failures. See `core/setup-export.md`.
+Every editable-output app proves `infinityCanvasCoverage`. Background proof covers color, viewport, disable/restore, and finite size. Preview checks the runtime scene against its exact `sceneBoundsProvider` union and real edge pixels; app selectors fail. Raster backing follows `useToolcraftProductSceneFrame`, not dormant finite size. Image/video decode the same bounds; video unions scheduled states. Fixed recipes cover excluded, empty, unavailable, and oversized scenes. See `core/setup-export.md`.
 
 ## Render Scale Coverage
 
@@ -117,6 +120,7 @@ Required parts:
 | `anchorGrid`        | `anchorGrid.position`                                                                                                                                                                     |
 | `channelMixer`      | `channelMixer.activeChannel`, `channelMixer.values`; only for RGB channel matrix behavior                                                                                                 |
 | `collectionActions` | `collectionActions.add`, `collectionActions.remove`, `collectionActions.items`                                                                                                            |
+| `sourceCollection`  | `sourceCollection.items`                                                                                                                                                                   |
 | `colorOpacity`      | `colorOpacity.hex`, `colorOpacity.opacity`                                                                                                                                                |
 | `curves`            | RGB variant: `curves.activeChannel`, `curves.points`; `variant: "single"`: `curves.points`                                                                                                |
 | `fontPicker`        | `fontPicker.fontId`, `fontPicker.fontWeight`, `fontPicker.fontSize`, `fontPicker.letterSpacing`, `fontPicker.lineHeight`, `fontPicker.textCase`, `fontPicker.color`, `fontPicker.opacity` |
@@ -149,6 +153,8 @@ choosing a fixed camera and thereby escaping gizmo acceptance.
 
 Use protected `expectToolcraftOrientationAxisDrag`/`AxisSnap`/`ModelDrag`/`CanvasMissPan`/`UndoReset` recipes. Axis drag finds blank circular background and performs the pointer drag; axis snap projects and clicks the requested endpoint from canonical pose. Evidence follows pose/output/ownership/history assertions. Arbitrary mutations, endpoint-only or generic drag, source spelling, and value changes do not qualify. Use `expectExportExcludesCanvasHandles` for export-clean proof.
 
+`expectToolcraftOrientationAxisDrag` validates paused playback and maximum `canvas.renderScale` when those standard controls are present. Product tests prepare those states through real UI before capturing their baseline; the protected helper does not toggle playback or quality, so one drag remains one history transaction. This is functional browser proof, not measured performance evidence.
+
 ## Control Selection Gates
 
 Acceptance must catch wrong-substitution failures. If the prompt, spec, or app behavior needs a value model owned by a built-in control, the schema must use that built-in or include a documented built-in fit check.
@@ -159,7 +165,7 @@ High-confidence wrong-substitution cases:
 - typography without `fontPicker`;
 - sibling typography controls that split case, color, opacity, size, weight, letter spacing, or line height away from `fontPicker`;
 - color plus opacity without `colorOpacity`;
-- repeatable user-editable item sets without `collectionActions` or another justified collection owner;
+- source-sized repeated item sets without `sourceCollection`, or user-editable cardinality without `collectionActions`;
 - from/to range without `rangeSlider` or `rangeInput`;
 - curve, remap, easing, or response without `curves`;
 - manual stable two-axis position, direction, focus, anchor, light, or vector parameters without `vector`;
@@ -181,34 +187,14 @@ A model `fileDrop` row declares `modelImportCoverage: "all-required-model-import
 
 Protected browser evidence imports every format plus folder/ZIP; proves first-root choice, runtime/custom readiness, nontransparent RGBA, and authored signatures versus fallback. Metadata, changed pose, or a canvas node is not proof. Fatal input keeps the prior commit. `Fix model` requires a deterministic topology plan and verified result; appearance warnings never expose it. Processing preview is `40%`; committed preview/export is `100%`. Both share document, appearance key, pose pixels, and omit gizmo chrome. Reload proves repository-backed appearance; corrupt refs become `unavailable`. History/reset proves removal, enabled undo/redo, and default restore through import.
 
-Rows that use custom controls must include `customControlCoverage` and typed `builtInFitCheck`.
-
-```ts
-builtInFitCheck: {
-  capabilities: [
-    "collection",
-    "reorder",
-    "selection",
-    "commands",
-    "custom-value-model",
-  ],
-  checkedBuiltIns: ["fileDrop", "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.",
-  productObservable:
-    "Changing a glyph density threshold changes which uploaded glyph renders for the same depth-map tone.",
-}
-```
-
-The fit check declares broad typed capabilities, names real checked built-ins, the closest built-in or `"none"`, why it is insufficient, and the product-observable evidence that proves the custom control works. At least one of `custom-interaction`, `custom-value-model`, or `custom-visualization` is required; collection/command chrome alone does not justify custom UI.
+Custom-control rows require `customControlCoverage` and typed `builtInFitCheck`; see `custom-controls.md` for the canonical shape. The fit check records capabilities, checked controls, the closest control (or `"none"`), the missing interaction, and observable proof. One `custom-*` capability is required; collection/command chrome alone is insufficient.
 
 A fit check containing `custom-interaction` also requires `interactionId` and a
 panel ownership entry. The fit check compares built-in controls; ownership
 separately proves why the operation belongs in the panel instead of directly on
 the canvas. Passing one gate never bypasses the other.
 
-For collection-like custom controls, the fit check must include `collectionActions` and `actions`. Collection-like is decided from the runtime value model and workflow: arrays, `{ items: [...] }` objects, selected-item state, grow/shrink item sets, ordering, add, remove, delete, or reorder behavior. Acceptance should fail if the row compares only unrelated built-ins such as `vector` or `select` while the actual value model is a collection.
+Collection-like custom controls must check `sourceCollection` and `collectionActions`, plus `actions` when commands exist. Arrays, `{ items: [...] }`, selection, cardinality, ordering, or item commands establish collection behavior; product nouns and unrelated controls do not.
 
 Custom controls cannot be justified by icons, layout, styling, compactness, or custom buttons alone. `whyInsufficient` must name the product interaction or value model that built-ins cannot express.
 
@@ -226,25 +212,25 @@ Valid acceptance evidence includes:
 - changed timeline playback state plus rendered frame.
 - restored persisted value or product output after browser reload.
 
-Product apps must include output delivery acceptance. Every product needs `Export PNG` evidence. Apps whose requested delivery includes animation also need `Export Video` evidence; timeline playback or keyframes alone do not invent video delivery. Clipboard copy can be tested as an additional behavior, but it cannot replace export coverage.
+Product apps include artifact acceptance only for the delivery enabled by `productReadiness.exportIntent`. Image-only products prove complete image coverage; image-plus-video products prove both; video-only products prove complete video coverage; explicit no-export products have no image/video artifact rows. Timeline playback, keyframes, or animation never add video acceptance. Clipboard copy can be tested as an additional behavior, but it cannot substitute for the recorded artifact intent.
 
 Export-content proof is distinct from export mechanics: content inspects selected artifact semantics; mechanics proves lifecycle, format, dimensions, transport, and errors. Neither substitutes.
 
-Every app with `Export PNG` must exercise the separate `Image Export` section: choose at least two `export.image.format` values, choose at least two `export.image.resolution` values, export the image, and decode the result to prove file type and actual pixel dimensions changed. Animated apps with both `Export PNG` and `Export Video` still need this image-export coverage; `Video Export` does not replace it.
+Every app with `Export PNG` must exercise the separate `Image Export` section: choose at least two `export.image.format` values, choose at least two `export.image.resolution` values, export the image, and decode the result to prove file type and actual pixel dimensions changed. Apps with both `Export PNG` and explicitly requested `Export Video` still need this image-export coverage; `Video Export` does not replace it.
 
 Runtime Export acceptance must prove the sticky footer top accent indicator advances through real render/encode/download work and hides only after the artifact settles. Async non-export Download, Copy, Generate, or Apply acceptance must prove the indicator is visible while the returned `onPanelAction` Promise is pending, advances when `reportProgress(0..1)` is called, and hides after it settles.
 
-Animated app acceptance exercises two video formats and resolutions. It proves real bytes, dimensions, actual MIME/container or typed capability failure, timeline duration, 30 FPS timestamps/durations from actual encoded packet metadata, decoded product motion, current even-safe sizing, and aspect-preserving 4K inside 3840x2160. Renderer/encoder/muxer errors reject; `blobSize`, metadata alone, assumed FPS, synthetic frame counts, or substituted expectations are invalid. Animated output requires distinct decoded frame hashes.
+Every video-enabled app exercises two video formats and resolutions. It proves real bytes, dimensions, actual MIME/container or typed capability failure, timeline duration, 30 FPS timestamps/durations from actual encoded packet metadata, decoded product motion, current even-safe sizing, and aspect-preserving 4K inside 3840x2160. Renderer/encoder/muxer errors reject; `blobSize`, metadata alone, assumed FPS, synthetic frame counts, or substituted expectations are invalid. Animated output requires distinct decoded frame hashes.
 
 Footer action acceptance must not include Reset. Reset is already available in the controls panel header and uses schema `defaultValue`; duplicating it in sticky `panelActions` fails acceptance.
 
 Local `actions` acceptance must click every visible action and prove the nearby entity changed through runtime state or product output. A section-level `Randomize palette` must change palette output, `Normalize weights` must change weights/output, and `Clear selection` must clear only the scoped selection. Do not accept a test that only proves the button rendered. A single-button `actions` control fails validation when the control label duplicates the button label; the label must add concise context. Visual acceptance rejects side-label actions; labels sit above a two-column button grid where each button cell is 50% width.
 
-`collectionActions` acceptance must click plus and minus in the real panel, prove the runtime target array length changes, prove `minItems` prevents invalid removal, prove `recommendedMaxItems` is not a hidden hard limit, and prove preview/export consumes the changed item list.
+`collectionActions` keeps parts `collectionActions.add`, `collectionActions.remove`, `collectionActions.items`. Prove limits, full-default add, sibling-preserving edit, preview/export, and whole-record removal. `sourceCollection` proves source count, item edit, output, and no add/remove.
 
 Image export proves background changes in preview/artifact/infinite viewport; Background off restores finite mode, disables Infinity, hides bounded preview background, and makes PNG transparent while JPEG/video stay opaque. Restoring it enables Infinity availability without entering that mode. Protected proof decodes real type, selected dimensions, product bounds/pixels, and pixel hash; bytes or dimensions alone are insufficient.
 
-Hard acceptance semantics are typed, not inferred from English prose. Every `visibleWhen` acceptance row declares `visibilityCoverage` for both `hidden` and `visible`; the protected conditional-visibility recipe must remove the dependent target from the rendered panel and restore it through the same target-scoped gating control. The `export.includeBackground` row declares `backgroundOutputCoverage` for preview exclusion and transparent image alpha, plus preserved video background when the schema exposes video export. Its protected recipe verifies the preview transition, decodes a non-empty image artifact and checks background alpha, and inspects video background behavior when applicable. `expectedObservable` and `userAction` remain human-readable context and may use any language; matching words such as “hidden”, “PNG”, or “video” never satisfy these requirements by themselves.
+Hard acceptance semantics are typed, not inferred from English prose. Control applicability derives exact pairwise cases from the control's section-inventory peers for both `always` and `conditional` controls. Each non-matching case requires target absence. Each matching case requires target presence plus every existing product outcome on that acceptance row, under a canonical case-suffixed requirement ID. A missing predicate therefore cannot hide behind a passing default branch. The `export.includeBackground` row separately declares `backgroundOutputCoverage` for preview exclusion and transparent image alpha, plus preserved video background when the schema exposes video export. Its protected recipe verifies the preview transition, decodes a non-empty image artifact and checks background alpha, and inspects video background behavior when applicable. `expectedObservable` and `userAction` remain human-readable context and may use any language; matching words such as “hidden”, “PNG”, or “video” never satisfy these requirements by themselves.
 
 Invalid final acceptance evidence:
 
@@ -332,6 +318,6 @@ Performance browser tests use the derived path matrix. Each path has one browser
 
 ## Fixtures
 
-Use fixtures that make each behavior visible. For example, background character-size controls need visible background characters, transparency needs alpha-sensitive pixels, selected-layer controls need multiple layers, timeline controls need deterministic playback or keyframe fixtures, and mode-specific controls need fixtures for every mode branch. Conditional coverage must prove visible controls, inactive controls hidden with `visibleWhen`, preserved values after switching away and back, and renderer output for the active branch. Count-controlled control banks must test both the low-count UI state and the expanded-count UI state; the test fails if inactive controls remain visible while the renderer ignores them.
+Use fixtures that make each behavior visible. For example, background character-size controls need visible background characters, transparency needs alpha-sensitive pixels, selected-layer controls need multiple layers, timeline controls need deterministic playback or keyframe fixtures, and mode-specific controls need fixtures for every mode branch. Applicability coverage proves matching controls visible, non-matching controls absent, values preserved after switching away and back, and the accepted renderer/export outcome in every visible finite sibling branch. Count-controlled control banks prove the numeric boundary states; the test fails if inactive controls remain visible or a visible control is ignored by the renderer.
 
 Generic hash differences are not enough for semantic controls. If a control promises a direction, test that direction.

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

@@ -116,6 +116,21 @@ The quoted evidence must be an exact nontrivial raw substring of `Request` with
 - Verification: One bare `pnpm verify:delivery` will derive and run the protected proof.
 - Risks: Already-exported applications retain their copied runtime until regenerated. Browser proof relies on the runtime gizmo's canonical pose/target attributes and intentionally fails closed if the real handle is absent or ambiguous.
 
+### Iteration 6 — Executable product-control applicability
+
+- Request: Fix starter contracts so generated products show only settings that apply to the selected type and cannot pass delivery with a visible control that the renderer ignores.
+- Task type: Shared runtime schema, controls-panel visibility, starter acceptance, protected browser evidence, generated fixtures, CLI, and documentation.
+- User-visible result: Every generated product control explicitly declares `always` or `conditional` applicability. Non-matching controls disappear without losing their values, while every visible finite sibling branch must prove the control's real accepted product outcome.
+- Source/reference checked: Badge behavior was used only as failure evidence; implementation scope remained the Toolcraft runtime and starter contracts. The legacy `visibleWhen` runtime path, control-section inventory, acceptance requirement derivation, reporter, and generated image/video/material fixtures were inspected.
+- Contract rules applied: `controls-product-coverage`, `controls-section-inventory-required`, `controls-component-layout-invariants`, `acceptance-product-observable`, and `workflow-required`.
+- Interaction ownership: The runtime owns applicability normalization and panel presence. Product schemas own explicit applicability claims. Existing product acceptance owns actions and outcomes; the applicability layer only derives the branch cases in which those outcomes must be reproved.
+- Decision: Normalize explicit applicability, legacy `visibleWhen`, and omitted low-level input into one resolved model with origin metadata; reject legacy/implicit origins for product controls; combine conditional predicates with AND; derive pairwise cases from semantic section peers; preserve the authored `Background` inventory ownership after runtime relocates its product controls into `Setup`; attach case-scoped evidence only after exact presence/absence and real outcome assertions pass.
+- Alternatives rejected: Extending optional `visibleWhen`, selector-owned target lists, renderer dependency inference, acceptance prose heuristics, Cartesian branch enumeration, and Badge-specific logic.
+- State/output mapping: Applicability reads canonical runtime target values and changes only panel presence. Hidden values remain in runtime state, persistence, transfer, and history. Matching cases reuse the control's existing preview, rendered-pixel, artifact, command, or semantic proof.
+- Performance intent: ordinary-product-work
+- 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.
+
 ## Decisions
 
 ### Renderer

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

@@ -25,7 +25,7 @@ export const appComposition = {
 } satisfies ToolcraftAppComposition;
 ```
 
-Edit `src/app/app-composition.tsx`, not the signed route. Product composition may provide only `schema`, `canvasContent`, `controlRenderers`, `exportRenderer`, `modelPresentation`, `onPanelAction`, `renderDefaultCanvasMedia`, and optional `rendererPipelineRegistration`; the protected route owns `className` and other host layout. Model products default to `modelPresentation: { mode: "runtime" }`. Custom presentation declares checked consumers and suppresses only their model targets; `renderDefaultCanvasMedia={false}` affects generic image/file preview, not runtime models. Do not compose `ToolcraftRoot`, `CanvasShell`, `ControlsPanel`, `LayersPanel`, `TimelinePanel`, or `ToolbarPanel` by hand. If a runtime surface has a performance or behavior issue, fix the shared runtime instead of replacing the surface locally.
+Edit `src/app/app-composition.tsx`, not the signed route. Product composition may provide only `schema`, `canvasContent`, `infiniteCanvasContent`, `controlRenderers`, `exportRenderer`, `modelPresentation`, `onPanelAction`, `renderDefaultCanvasMedia`, `sceneBoundsProvider`, and optional `rendererPipelineRegistration`; the protected route owns `className` and other host layout. `infiniteCanvasContent` is editor-only product output for a full Infinity viewport backdrop; it does not inherit world transforms or participate in scene bounds/export. Model products default to `modelPresentation: { mode: "runtime" }`. Custom presentation declares checked consumers and suppresses only their model targets; `renderDefaultCanvasMedia={false}` affects generic image/file preview, not runtime models. Do not compose `ToolcraftRoot`, `CanvasShell`, `ControlsPanel`, `LayersPanel`, `TimelinePanel`, or `ToolbarPanel` by hand. If a runtime surface has a performance or behavior issue, fix the shared runtime instead of replacing the surface locally.
 
 Supporting product modules may be organized anywhere under `src`; there is no folder allowlist. The product boundary follows all product production files and rejects host/runtime surface imports, built-in control imports/re-exports, dynamic bypasses, and production dependencies on test/spec modules.
 
@@ -35,6 +35,7 @@ Allowed app extension points:
 | --- | --- |
 | Schema controls | Built-in controls, targets, defaults, visibility, panel actions. |
 | `canvasContent` | Product output only. |
+| `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. |
 | `onPanelAction` | Non-export sticky footer product actions. |
@@ -51,6 +52,10 @@ Once the folder is a real product, switch `src/app/app-acceptance-data.ts` from
 
 ```ts
 export const appProductReadiness = {
+  exportIntent: {
+    image: { mode: "toolcraft-default" },
+    video: { mode: "not-requested" },
+  },
   interactionOwnership: [],
   mode: "product",
   productName: "Product name",
@@ -63,6 +68,8 @@ 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.
+
 Populate `interactionOwnership` before adding canvas handles or custom
 interactions. One operation has one primary `canvas` or `panel` surface chosen
 from user request, inspected reference, or product usability evidence. Different
@@ -75,7 +82,7 @@ the prompt did not separately request rotation.
 
 ## Controls
 
-Before writing product sections, export `starterControlSectionInventory`. Each product section declares its title, targets, product entity or workflow stage, and grouping reason.
+Before choosing component layout, export `starterControlSectionInventory` and make the entity-first grouping decision. Every product section declares stable `entityId`, human-readable `entity`, exact targets, and `groupingReason`; one entity stays in one section through ten controls, while larger entities split only into explicit balanced workflow stages.
 
 Use `core/layout.md` for section grouping, dependency cohesion, headers, reset, collapse, spacing, dividers, labels, and inline rows. Use `core/control-selection.md` and `component-rules.md` before choosing concrete controls. Built-in compound controls stay compound; extend the kit instead of splitting owned fields into neighboring controls.
 
@@ -99,7 +106,7 @@ When porting an existing app, use `transferMode: "reference-runtime-clone"` unle
 
 ## Timeline And Animation
 
-Before adding animation controls, write an Animation Intent Inventory. Product animation, keyframes, playback, and video export use the top Toolcraft timeline. Autonomous no-timeline animation is allowed only for non-product decorative motion with no user-facing transport and no video export.
+Before adding animation controls, write an Animation Intent Inventory. Product animation, keyframes, and playback use the top Toolcraft timeline. Explicitly requested video export also requires that timeline, but the timeline never authorizes video delivery. Autonomous no-timeline animation is allowed only for non-product decorative motion with no user-facing transport and no video export.
 
 Use `core/timeline-animation.md` for timeline mode, compact/extended timeline, seamless forward loops, duration changes, keyframes, viewport interaction performance, and video export timing.
 

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

@@ -36,13 +36,15 @@ Range slider value editing accepts common range separators such as `20/80`, `20-
 
 Discrete sliders must still drag smoothly. Heavy preview work may be coalesced, cached, or split into lightweight live feedback plus heavier refinement, but the canvas/product output must not stay unchanged until pointer release.
 
-Use `visibleWhen` when a slider or range slider is meaningful only in some mode, type, source, include, variant, or count state. Inactive branches disappear so the panel shows only controls that can be used in the current state.
+Every product slider and range slider declares `applicability`. Use `mode: "conditional"` when it is meaningful only in some mode, type, source, include, variant, or count state. Every predicate in `all` must match; inactive branches disappear while their values remain preserved.
 
-Do not use schema `disabled: true` or `disabledWhen` for product sliders and range sliders. Product panels should show only controls usable in the current state. Use `visibleWhen` for unavailable product states instead of rendering disabled controls.
+Do not use schema `disabled: true` or `disabledWhen` for product sliders and range sliders. Product panels show only controls usable in the current state.
 
-For mode/type/source/include/count branches, hide with `visibleWhen` instead of disabling. Example: when Texture is `Off`, hide texture pattern, upload, blend, and opacity. When Texture is `Image`, show the image uploader and shared texture settings. When `Shades` is `2`, `Shade 3`, `Shade 4`, and `Shade 5` are not visible. Do not keep inactive controls visible while making the renderer ignore them.
+For mode/type/source/include/count branches, declare conditional applicability instead of disabling. Example: when Texture is `Off`, texture pattern, upload, blend, and opacity predicates do not match. When Texture is `Image`, the uploader and shared texture settings match. When `Shades` is `2`, `Shade 3`, `Shade 4`, and `Shade 5` do not match. Do not keep inactive controls visible while making the renderer ignore them.
 
-If `visibleWhen` points to a selector for the same target entity or selected branch, keep the selector and the dependent controls in the same semantic section. A section that exists only because one selector option is active is not a separate product section just because the branch uses a standalone control. Use one section with conditional controls; split only when the dependent branch is a separate product entity with its own workflow and acceptance evidence.
+If applicability points to a selector for the same target entity or selected branch, keep the selector and dependent controls in the same semantic section. A section that exists only because one selector option is active is not a separate product section just because the branch uses a standalone control. Use one section with conditional controls; split only when the dependent branch is a separate product entity with its own workflow and acceptance evidence.
+
+An `always` declaration is testable, not a shortcut: protected acceptance varies every supported finite sibling selector from the same Control Section Inventory and proves the control's existing product outcome in each branch. Conditional controls use the same pairwise cases; a non-matching case proves absence, and every matching case reproves the real output. This catches both missing predicates and incorrect always-visible declarations.
 
 ## Palette
 
@@ -86,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.
+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.
 
 ## File Upload
 
@@ -179,7 +181,7 @@ Use `useToolcraftModelOrbitInteraction` on the product renderer and provide a hi
 
 Multiple `orientationGizmo` declarations are allowed only for model modes whose combined section/control visibility conditions are statically provable as mutually exclusive. Runtime renders at most one active canvas handle and rejects an ambiguous state instead of selecting the first declaration.
 
-Click a signed axis endpoint to return to that view. Drag anywhere inside the circular gizmo to orbit with Blender-style Turntable behavior: horizontal movement rotates around world up, vertical movement rotates around the screen-horizontal axis, and sensitivity is 0.4 degrees per CSS pixel. Direct model drag uses the same rotation kernel. Axis snaps use angle-scaled Blender Smooth View timing with a 200ms maximum. Gizmo drag, snap, and direct model drag share target-scoped ownership, so a newer gesture, reset, undo/redo, or external target write cancels stale work. A background click is inert; pointer cancel and lost capture end the gesture. The runtime handle is fixed under canvas pan/zoom, uses one history group per completed gesture, and is excluded from export. Product code selects it through schema and must not import or render the visual gizmo directly.
+Click a signed axis endpoint to return to that view. Drag anywhere inside the circular gizmo to orbit with Blender-style Turntable behavior: horizontal movement rotates around world up, vertical movement rotates around the screen-horizontal axis, and sensitivity is 0.4 degrees per CSS pixel. Direct model drag uses the same rotation kernel. Axis snaps use angle-scaled Blender Smooth View timing with a 200ms maximum. Gizmo drag, snap, and direct model drag share target-scoped ownership, so a newer gesture, reset, undo/redo, or external target write cancels stale work. A background click is inert; pointer cancel and lost capture end the gesture. The runtime handle is fixed under canvas pan/zoom, uses one history group per completed gesture, and is excluded from export. Product code selects it through schema and must not import or render the visual gizmo directly. When the product also enables the Toolcraft timeline or `canvas.renderScale`, orientation axis-drag proof runs with playback paused and render scale at its declared maximum. The shared pose and visible product pixels must update before pointer release in that state. Cooperative rendering may coalesce work, but it must publish a changed high-quality frame during the gesture; pointer release is not the first allowed visible commit.
 
 ## Curves
 

package/templates/starter/docs/toolcraft/core/control-selection.md

@@ -84,6 +84,7 @@ renamed copy of the same capability is still duplication.
 - Use `tabs` for finite choices that replace the content or workflow view below the control; the runtime changes overflowing tabs to Select without changing the value.
 - Use `segmented` for compact finite mode settings that leave the surrounding view unchanged.
 - Use `actions` for local section commands that affect only the nearby entity.
+- Use `sourceCollection` when source analysis or another runtime workflow owns the array length and users edit only existing built-in item values.
 - Use `collectionActions` for repeatable product entities whose actual item list can grow or shrink.
 - Use `panelActions` for sticky final product actions such as export, copy, generate, apply, or download.
 
@@ -91,18 +92,22 @@ renamed copy of the same capability is still duplication.
 
 - `fontPicker` owns font family, weight, size, text case, text color/opacity, letter spacing, and line height.
 - `gradient` owns gradient type, angle, draggable stop track, and Stops list.
-- RGB `curves`, `channelMixer`, `palette`, and `collectionActions` are also compound controls.
+- RGB `curves`, `channelMixer`, `palette`, `sourceCollection`, and `collectionActions` are also compound controls.
 - Do not split owned fields into neighboring schema controls.
 - If a needed owned field is missing from a built-in, extend the kit instead of composing a parallel control.
 
-## Collection Actions
+## Collection Cardinality
 
+- Use `sourceCollection` when a loaded, derived, detected, or otherwise external source owns the exact array length. It renders the declared built-in `itemControl` for every current item and never exposes add/remove commands.
 - Use `collectionActions` when users edit the actual growable/shrinkable set: colors, glyphs, symbols, points, rules, variants, objects, style entries, or similar repeatable entities.
+- Both controls use the same runtime-owned built-in item renderer. Product code must not copy a child control implementation to support a dynamic list.
+- Source workflows replace the complete `sourceCollection` target array; panel edits change item values only.
+
 - Adding/removing items must update runtime state and product preview/export.
 - Do not use a count slider plus hidden fixed item controls when the user needs to add or remove actual entities.
 - The collection control shows the collection label on the left and remove/add icon buttons on the right.
 - Homogeneous repeated items do not show visible per-item labels when the collection label already names the group.
-- Plain color items may use equal 50% columns; color+opacity items stay stacked.
+- Plain color items may use equal 50% columns; color+opacity items stay stacked. Use `itemControl` for one homogeneous value. Use `itemControls` only when two or more built-in fields form one logical target-array record and affect that entity's outcome: `+` appends all field defaults, `−` removes the final record, and runtime places a content-width line only between records without `Item N` headings. Standalone color `itemControl` stays a divider-free two-column grid; color may still be a legitimate compound field.
 
 ## Actions
 
@@ -156,4 +161,5 @@ typed evidence-backed `fixed-camera` escape hatch.
 - Remove file names, helper text, and captions that do not help distinguish items or explain state.
 - Do not make tiny item-level action buttons below kit comfort sizes.
 - Do not recreate built-in controls, panels, toolbar, timeline, layers, canvas shell, or runtime surfaces.
+- Do not import deep Toolcraft control implementation modules or substitute native form controls for a schema-owned value model.
 - A custom control with `custom-interaction` must reference its typed interaction owner. Its built-in fit check does not justify panel UI when the same operation is already owned by a canvas interaction.

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
 

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;

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

@@ -18,18 +18,24 @@ 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 `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.
 - 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.
@@ -37,11 +43,16 @@ Use only these app-specific extension points. Shared runtime changes happen upst
 ## 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 +76,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

@@ -31,9 +31,16 @@ Read this module before changing Setup, canvas sizing, background, image export,
 - `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/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.
 - 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.
@@ -75,13 +82,34 @@ Read this module before changing Setup, canvas sizing, background, image export,
 - Runtime image export reads Background directly: PNG can be transparent, while JPG remains opaque.
 - Runtime video export keeps the selected background even when Background is off.
 
+## Artifact Export Intent
+
+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`.
+
+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:
+
+| 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 |
+
+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`.
+
 ## 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 +117,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.
@@ -105,10 +133,8 @@ Read this module before changing Setup, canvas sizing, background, image export,
 
 ## 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 actions in sticky `panelActions` match the resolved artifact intent exactly. Explicit no-export products have no image 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.
 - 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,7 +21,7 @@ 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 clone | Invariant | Preserve reference behavior unless redesign is explicit |
@@ -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, 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`.
+
 [//]: # (toolcraft-contract:decision-rule-table:start)
 | Rule ID | Level | Area |
 | --- | --- | --- |

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

@@ -27,6 +27,10 @@ Do not write renderer code before the envelope, `rendererTechnique`, pipeline, a
 - Prefer retained resources and stable cache keys. Source-bound resources live outside React render, survive unrelated interactions according to pass lifecycle, and release during cleanup.
 - Separate layers when they have different semantics, invalidation, lifecycle, interaction, or export treatment. A costly layer does not force unrelated output into the same renderer.
 - Preserve selected quality, product boundaries, backing resolution, and source fidelity. A renderer is not accepted by silently reducing them.
+- In infinite mode, custom Canvas 2D, WebGL, and WebGPU previews use `useToolcraftProductSceneFrame()` as their backing and coordinate frame. Do not keep rendering into dormant finite `canvas.size`, derive another bounds wrapper, or measure DOM geometry; runtime already positions the product scene surface from `sceneBoundsProvider`.
+- A preview-only environment that must stay fixed to the complete Infinity
+  viewport uses `infiniteCanvasContent`, not the bounded product renderer. Keep
+  that layer pointer-transparent and exclude it from scene bounds and export.
 
 When assessment requires a benchmark, declare `kernelBenchmarkDecisions`, implement only the named executable candidates in `e2e/app-kernel-benchmarks.ts`, and let protected `pnpm verify:kernel` measure them at the exact combined workload vector. Candidate outputs must be deterministic and equal at full quality. Do not author timing values or add speculative benchmark metadata when generic assessment resolves the choice.