@pixel-point/toolcraft 0.0.17 → 0.0.19

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

@@ -9,7 +9,6 @@ Every visible product entity must prove it works. A control is not accepted beca
 - `src/app/app-acceptance-data.ts`
 - app-specific tests under `src/app` outside the reserved `app-acceptance.*` framework namespace
 - `src/app/app-performance.ts`
-- `src/app/app-verification-impact.json` (presentation, functional, and performance ownership with nearest acceptance ids and exact performance pass ids)
 - `src/app/app-performance.test.ts`
 - `docs/toolcraft/agent-worklog.md`
 - `e2e/app-browser-acceptance.spec.ts`
@@ -18,7 +17,7 @@ Every visible product entity must prove it works. A control is not accepted beca
 - `e2e/app-kernel-benchmarks.ts`
 - `e2e/product-observable-helpers.ts`
 
-Use focused checks during edits. First delivery and later delivery run bare `pnpm verify:delivery` per `workflow.md`. Performance complaint authority adds an iteration; explicit full audit authority permits `pnpm verify:perf`.
+First delivery runs bare `pnpm verify:delivery` once. Later edits run an exact unit/component test and `pnpm test:feature -- <acceptance-id>`: finite selectors expand to affected acceptance peers, while leaf IDs stay one browser scenario. Use `pnpm test:feature -- --all` only for a cross-cutting edit; it still runs product acceptance only. Repeated delivery is a protected no-op. Performance complaint authority adds one targeted iteration; explicit full-audit authority permits `pnpm verify:perf`.
 
 ## Product Readiness
 
@@ -26,9 +25,12 @@ The exported starter may keep `appProductReadiness.mode: "starter"` only while i
 
 - `productName`;
 - `productSummary`;
-- `requestedBehavior`.
+- `requestedBehavior`;
+- required `exportIntent`;
 - `viewInteraction`.
 
+`productReadiness.exportIntent` owns artifact delivery. Acceptance, actions, and applicable settings must match its image, SVG, and video capabilities. SVG has no settings section and means self-contained editable vectors. See `core/setup-export.md`; never infer intent from renderer technology, 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.
@@ -37,7 +39,7 @@ Product readiness also requires product surface: controls, layers, timeline, `ca
 
 ## Implementation Worklog
 
-Product apps must update `docs/toolcraft/agent-worklog.md` before final delivery. The file records why the app chose its renderer, view interaction mode, timeline mode, layer policy, control grouping, export behavior, and performance strategy.
+Product apps must update `docs/toolcraft/agent-worklog.md` before first delivery and when later decisions materially change. The file records why the app chose its renderer, view interaction mode, timeline mode, layer policy, control grouping, export behavior, and performance strategy.
 
 The worklog must declare `Mode: product`. Every `Decision Trail` records human intent: `Request:`, `Task type:`, `User-visible result:`, `Source/reference checked:`, `Reference inputs:`, `Docs/contracts read:`, `Contract rules applied:`, `View interaction intent:`, `Interaction ownership:`, `Decision:`, `Alternatives rejected:`, `State/output mapping:`, `Performance intent:`, bare-delivery `Verification:`, and `Risks:`. Steering within one request stays in that batch. `Reference inputs:` lists every prompt/reference asset or `None`; `State/output mapping:` connects state to visible output or export.
 
@@ -78,9 +80,9 @@ Protected Vitest and Playwright reporters evaluate passed runner results plus ma
 
 The `e2e/app-browser-*` prefix is reserved for signed framework specs.
 
-## Semantic Proof Ownership
+## Proof Boundaries
 
-Every runtime production module/resource has a direct owner in `src/app/app-verification-impact.json`; proof and test paths cannot own them. Each browser file owns one acceptance domain (the first ID segment). Later delivery compares semantic models and selects changed contracts, owners/domains, and product-unit tests—not filenames or reverse imports. Additive owner deltas select only new IDs; other deltas retain affected IDs.
+First delivery proves the complete acceptance catalog. Later ordinary edits do not derive an aggregate proof model or infer from changed files: run the exact product test, then pass its acceptance ID to `test:feature`. Semantic closure reuses current applicability cases; the existing reporter still requires each selected branch, layout, and product outcome. Invalid IDs, titles, or plans fail before browser startup. The development server tests current source instead of stale build output. A repeated bare `verify:delivery` neither discovers nor runs these checks.
 
 Classifier output establishes complaint authority only; unresolved localization creates no intent/path regardless of result. Only localized/clarified work starts an iteration.
 
@@ -88,7 +90,7 @@ Contract docs are signed except product-owned `agent-worklog.md` and optional `w
 
 Framework meta-tests are product-invariant: their synthetic validator cases use protected neutral contract fixtures, never the editable app schema, product acceptance rows, transfer intent, or section inventory. Put exact product targets, defaults, option values, and product-specific expectations in separate app-owned tests. The product gates still read `app-schema.ts`, `app-acceptance-data.ts`, product test names, worklog evidence, and browser scenarios dynamically.
 
-The same ownership split applies to performance: edit `app-performance.ts`, `app-verification-impact.json`, product performance path adapters, and the kernel candidate harness when assessment requires it. Do not edit supplied `app-performance.*` meta-tests, protected reporters, receipt writers, or `app-performance-test-utils.ts`; they validate product inputs and own execution evidence.
+For performance work, edit `app-performance.ts`, product performance path adapters, and the kernel candidate harness when assessment requires it. Do not edit supplied `app-performance.*` meta-tests, protected reporters, receipt writers, or `app-performance-test-utils.ts`; they validate product inputs and own execution evidence.
 
 Slider and range slider rows must prove live behavior. Browser tests should drag the real thumb and assert the runtime value and product-level canvas observable update during the drag, not only after pointer release, blur, an Apply action, or a final commit. Performance-sensitive sliders still need this live acceptance; jank is handled through renderer optimization and targeted performance coverage, not by making the slider deferred by default.
 
@@ -96,7 +98,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 +119,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 +152,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 +164,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`;
@@ -173,7 +178,7 @@ High-confidence wrong-substitution cases:
 
 ## Interaction Ownership Evidence
 
-Product readiness declares `interactionOwnership`. Canvas handles, custom interactions, and panel controls sharing a canvas target bind `interactionId`. Acceptance rejects one id on both surfaces, renamed copies of the same target/capability, bad links, or choices lacking evidence and an alternate-surface reason. Distinct capabilities may share state across surfaces and are proved separately.
+`interactionOwnership` gives each operation one surface; linked canvas/panel operations must be complementary, not renamed copies. Property edits declare global or selected `selectionScope`; selected properties name a selection owner and `selectionScopeCoverage: "two-entity-isolation"`. Protected Canvas/Panel pixels prove selection is inert, editing A changes only A, editing B changes only B, and the control rebinds. `selectedLayer.*` reuses this recipe; whole-canvas/signature/direct-command proof is invalid.
 
 `fileDrop` rows prove upload/admission, clear/remove, reset/default restoration, and binary/model lifecycle. Without Layers ownership they also prove image rotate/flip and `multiple` reorder. With `panels.layers` and typed media-management ownership, omit those claims from `fileDrop`: runtime `layerCoverage: "reorder"` and `"selected-layer-controls"` rows prove order and selected-transform output. Clear-only proof is invalid; Reset restores defaults or removes uploaded media.
 
@@ -181,34 +186,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.
 
@@ -217,7 +202,7 @@ Custom controls cannot be justified by icons, layout, styling, compactness, or c
 Valid acceptance evidence includes:
 
 - rendered product pixels;
-- exported image/video bytes;
+- exported image/SVG/video bytes;
 - canvas hash or DOM-visible product result;
 - clipboard, file, or blob payload;
 - cleared media preview and canvas;
@@ -226,25 +211,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.
+Artifact acceptance follows `productReadiness.exportIntent`. Image/video use complete artifact coverage; requested SVG adds `all-required-svg-export-behavior` and protected exact-download vector proof. Explicit no-export products have no artifact rows. Renderer technology never adds SVG, and timeline behavior never adds video. Clipboard proof cannot replace 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:
 
@@ -282,16 +267,17 @@ Animated viewport tests must also prove that canvas drag, pan, pinch, zoom, and
 
 ## Video References
 
-When a video, GIF, screen recording, contact sheet, or extracted-frame sequence is used as a reference, acceptance is driven by `starterTransferMode.videoReferenceStudy`.
-
-- `storyboard` records timecoded frames with visible state and behavior observations;
-- `transitionAnalysis` records frame-to-frame deltas, not only isolated frame descriptions;
-- `behaviorDecomposition` states which observed behaviors must be copied;
-- `acceptanceMapping` maps each observed video behavior to a real acceptance row;
-- mapped acceptance rows must be automated, browser-backed, and observable in product output, timeline output, export output, or a real command side effect;
-- `agent-worklog.md` records Video Reference Study evidence when `Reference inputs`, `Source/reference checked`, or `Source reviewed` cites video, GIF, screen recording, contact sheet, or extracted frames.
+When a video, GIF, screen recording, contact sheet, or extracted-frame sequence
+is used as a reference, acceptance is driven by typed
+`starterTransferMode.referenceInputs`. Each authored behavior points to one
+observable acceptance row, and that row owns the exact reverse
+`motionReferenceCoverage` pair plus browser `reference-parity` evidence. The
+semantic validator requires complete phases and exactly one classification for
+every detected event. Follow `core/reference-study.md` for preprocessing,
+sampling, artifacts, timing, worklog records, and the no-reference fast path.
 
-Do not accept a video reference implementation proved only by a single screenshot, a visual summary, generic canvas hashes, or static style checks.
+Do not accept a motion-reference implementation proved only by a single
+screenshot, a visual summary, generic canvas hashes, or static style checks.
 
 ## Reference Clone
 
@@ -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

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

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

@@ -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,8 +35,10 @@ 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. |
+| `svgExportRenderer` | Namespace-aware editable vector content for explicit runtime SVG export. |
 | `onPanelAction` | Non-export sticky footer product actions. |
 | `rendererPipelineRegistration` | One compiled executable pipeline shared by render work, actions, evidence, and new-envelope assessment. |
 | Runtime commands/hooks | History, media, canvas, timeline, layers, and controlled app behavior. |
@@ -51,6 +53,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 +69,8 @@ export const appProductReadiness = {
 } as const;
 ```
 
+Every product declaration requires `productReadiness.exportIntent`. It is the authority for exact image/SVG/video schema actions, applicable settings sections, and artifact acceptance. Use `core/setup-export.md` for the single export-intent decision sequence; renderer technology, animation, and timeline choices do not supply delivery intent.
+
 Populate `interactionOwnership` before adding canvas handles or custom
 interactions. One operation has one primary `canvas` or `panel` surface chosen
 from user request, inspected reference, or product usability evidence. Different
@@ -75,7 +83,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.
 
@@ -93,19 +101,19 @@ Use `core/runtime-boundary.md` for shell boundaries, `core/media-upload.md` for
 
 If a Figma URL is provided, use Figma MCP/design context before implementation and rebuild from file structure, not from a screenshot.
 
-If a video, GIF, screen recording, contact sheet, or extracted-frame sequence is provided, write a Video Reference Study before implementation.
+If a video, GIF, screen recording, contact sheet, or extracted-frame sequence is provided, register typed `referenceInputs`, generate the protected dense study before implementation, classify its events and phases, and map behaviors to acceptance plus browser `reference-parity`. Follow `core/reference-study.md`; do not recreate its command, sampling, storage, or timing rules here.
 
 When porting an existing app, use `transferMode: "reference-runtime-clone"` unless the user explicitly asks for redesign. Declare `referenceStudy` plus `referenceFeatureInventory`, then prove each inspected reference feature with acceptance coverage. Use `core/reference-study.md` for the detailed reference, Figma, and video study rules.
 
 ## 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.
 
 ## Renderer Work
 
-For custom renderers, write the Renderer Technique Decision Matrix and typed performance model before code. Follow one sequence: reachable controls and inputs; workload dimensions and enforced boundaries; pass cost, frequency, lifecycle, and invalidation; render-plan assessment and protected kernel benchmark when required; derived paths and combined fixtures; impact-derived functional/browser development checks; lifecycle-appropriate delivery proof. Only exact request authority may add measured targeted performance.
+For custom renderers, write the Renderer Technique Decision Matrix and typed performance model before code. Follow one sequence: reachable controls and inputs; workload dimensions and enforced boundaries; pass cost, frequency, lifecycle, and invalidation; render-plan assessment and protected kernel benchmark when required; derived paths and combined fixtures; feature-focused functional/browser development checks; first-delivery or authority-backed performance proof. Only exact request authority may add measured targeted performance.
 
 Compile one lightweight renderer pipeline registration outside test modules. Supply that exact registration as `rendererPipelineRegistration` in the composition and as `rendererPipeline` to new-envelope performance assessment. Run `assessToolcraftRenderPlan` before implementing the renderer. Derive path ids from the assessed registration and compile workload fixtures from those paths; do not classify workload by target names or author scenario-specific maxima. Renderer work uses `useToolcraftPipelinePass`; retained resources are available only from its generation-bound pass execution context. Product code never receives runtime disposal ownership.
 
@@ -113,16 +121,16 @@ Use `renderer-technique.md`, `core/performance.md`, and `performance.md` for ren
 
 ## Automatic Delivery Lifecycle
 
-Use one normal sequence: assemble or change the product, gather focused functional feedback, finish the coherent delivery batch, run protected functional delivery once, and return the app for user evaluation. Focused checks while implementation is changing do not mint delivery evidence.
+Use one normal sequence: assemble the first product, gather focused functional feedback, run protected functional delivery once, then use only feature-focused checks for later edits and return the app for user evaluation.
 
 1. First product delivery uses bare `pnpm verify:delivery` for complete product contracts, one production build, full functional acceptance, and no measured performance.
-2. Later `functional-targeted` delivery uses the same bare command for exact ownership-derived functional proof relative to the immediately previous successful delivery.
+2. Later ordinary edits run only the directly relevant product tests and browser checks. A repeated bare command exits before inventory, build, tests, export, and performance work and preserves the initial receipt.
 3. Classifier output establishes complaint authority only and never path localization. Only a localized complaint or a post-clarification targeted choice records an exact request quote and canonical affected path IDs in the worklog, then one bare delivery runs one targeted iteration and returns the app for evaluation. Unresolved localization creates neither performance-iteration intent nor canonical path authority regardless of classifier result.
 4. A full audit requires an explicit operator request or accepted offer; only then run `pnpm verify:perf` for one fresh build and the complete maximum-fixture performance matrix.
 
 Protected receipts own changed files, the derived plan, executed checks, reports, measurements, and pass/fail evidence. The worklog keeps product intent and decisions.
 
-For final delivery, run:
+For first product delivery, run:
 
 ```bash
 pnpm verify:delivery

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

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