@pixel-point/toolcraft 0.0.15 → 0.0.17

package/templates/starter/docs/toolcraft/schema-reference.md

@@ -8,15 +8,15 @@ Edit `src/app/app-schema.ts` as the public product surface. Use `defineToolcraft
 
 Top-level schema fields:
 
-| Field | Purpose | Detailed rules |
-| --- | --- | --- |
-| `canvas` | Product workspace, output size, upload/drop support, render scale. | `core/runtime-boundary.md`, `core/setup-export.md`, `core/media-upload.md` |
-| `media` | Predefined attached files/images that appear in `fileDrop`. | `core/media-upload.md` |
-| `panels` | Controls, layers, timeline. | `core/runtime-boundary.md`, `core/timeline-animation.md` |
-| `toolbar` | History, radar, theme, zoom. | `assembly-workflow.md` |
-| `persistence` | Intentional reload persistence for runtime slices. | `performance.md`, `acceptance-testing.md` |
-| `settingsTransfer` | Runtime-owned Export Settings / Import Settings identity. | `core/setup-export.md` |
-| `panelActions` | Sticky product delivery actions such as export, copy, generate, apply. | `core/setup-export.md`, `core/control-selection.md` |
+| Field              | Purpose                                                                | Detailed rules                                                             |
+| ------------------ | ---------------------------------------------------------------------- | -------------------------------------------------------------------------- |
+| `canvas`           | Product workspace, output size, upload/drop support, render scale.     | `core/runtime-boundary.md`, `core/setup-export.md`, `core/media-upload.md` |
+| `media`            | Predefined attached files, images, and models shown in `fileDrop`.      | `core/media-upload.md`                                                     |
+| `panels`           | Controls, layers, timeline.                                            | `core/runtime-boundary.md`, `core/timeline-animation.md`                   |
+| `toolbar`          | History, radar, theme, zoom.                                           | `assembly-workflow.md`                                                     |
+| `persistence`      | Intentional reload persistence for runtime slices.                     | `performance.md`, `acceptance-testing.md`                                  |
+| `settingsTransfer` | Runtime-owned Export Settings / Import Settings identity.              | `core/setup-export.md`                                                     |
+| `panelActions`     | Sticky product delivery actions such as export, copy, generate, apply. | `core/setup-export.md`, `core/control-selection.md`                        |
 
 Schema controls always bind to a `target`, use `defaultValue` for reset behavior, and include `performanceRole` / `performanceReason` on visible non-action controls. Use built-in control `type` values before `controlRenderers`.
 
@@ -24,32 +24,105 @@ Schema controls always bind to a `target`, use `defaultValue` for reset behavior
 
 Canvas sizing modes:
 
-- `editable-output`: product/export apps. Runtime `Setup` shows `Aspect ratio`, `Canvas width`, `Canvas height`, optional `Resolution scale`, and optional `Timeline`.
+- `editable-output`: product/export apps. Runtime `Setup` shows Background beside Infinity canvas, then Background color, `Aspect ratio`, `Canvas width`, `Canvas height`, optional `Resolution scale`, and finally optional `Timeline`. With the standard Background pair, Background off restores finite mode and disables Infinity; an enabled infinite viewport uses the selected Background color.
 - `intrinsic-media`: explicit media-viewer/source-native products where imported media intentionally owns `canvas.size`.
 - `fixed-output`: non-product/internal fixtures where users must not edit output size.
 
 Product-output, exportable, shader, procedural, and reference-clone apps use `editable-output`. Uploaded background/source images inside a product canvas also use `editable-output`: keep the current canvas size and render the image as cover/crop inside current canvas bounds.
 
-Use `canvas.renderScale: true` only for non-vector raster previews such as Canvas 2D, WebGL, or WebGPU. Do not enable it for DOM/SVG/vector-native previews.
+`canvas.mode` is runtime state with values `"finite"` and `"infinite"`; it is not a second schema sizing mode. `canvas.infinity` is the reserved built-in Setup target. Infinite mode preserves `canvas.size` only for later finite restoration and never uses that dormant size for layout or export.
+
+Editable-output apps may opt into Infinity for a fresh workspace and Reset with
+`canvas.sizing: { defaultMode: "infinite", mode: "editable-output" }`. Omitting
+`defaultMode` keeps the runtime default finite. A valid persisted or explicitly
+provided initial canvas mode takes precedence over the schema default.
+
+Custom product output declares bounds on the composition:
+
+```tsx
+export const appComposition: ToolcraftAppComposition = {
+  canvasContent: <ProductCanvas />,
+  sceneBoundsProvider: ({ state, timeRange }) => [
+    getVisibleProductSceneRect(state, timeRange),
+  ],
+  schema: appSchema,
+};
+```
+
+The provider returns world-space `{ x, y, width, height }` rectangles. Runtime unions them once with visible image/model frames. It is called only for infinite export; video passes the requested time range so the provider can return one complete animation envelope. Product code does not read DOM bounds or the dormant finite size.
+
+Use `canvas.renderScale: true` or `canvas.renderScale: { step }` only for non-vector raster previews such as Canvas 2D, WebGL, or WebGPU. For this field, product code may customize only the slider step; authored schema cannot set `enabled`, `min`, `defaultValue`, or `max`. Runtime resolves enabled render scale to `{ enabled: true, min: 1, defaultValue: 2, max: 2, step }`, using `0.25` when no step is authored. A custom step must be finite, between `0.01` and `1`, and evenly partition the canonical `1..2` range so `2` remains reachable; invalid input fails fast. Do not enable it for DOM/SVG/vector-native previews. Enabling it requires one browser runtime acceptance row targeting `canvas.renderScale` with `renderScaleCoverage.kind: "selected-backing-pixels"` and exact sorted states `["interaction", "steady"]`, plus `"playback"` when timeline is enabled. The fixed `canvas-render-scale-backing` recipe proves actual backing pixels rather than timing.
 
 ## Media Defaults
 
-Use `media.defaultAssets` for predefined files, source images, masks, symbol sets, or background images:
+Use `media.defaultAssets` for predefined files, images, or model packages with complete local appearance dependencies:
 
 ```ts
 media: {
   defaultAssets: [
     {
       id: "default-source",
-      name: "source.png",
+      assetKind: "image",
+      dataUrl: "data:image/png;base64,...",
+      fileName: "source.png",
       sourceTarget: "source.image",
-      url: "/assets/source.png",
+    },
+    {
+      id: "default-model",
+      assetKind: "model",
+      fileName: "scene.gltf",
+      sourceTarget: "source.model",
+      sourceFiles: [
+        {
+          dataUrl: "data:model/gltf+json;base64,...",
+          path: "scene/scene.gltf",
+        },
+        {
+          dataUrl: "data:application/octet-stream;base64,...",
+          path: "scene/geometry.bin",
+        },
+      ],
     },
   ],
 }
 ```
 
-`sourceTarget` must match a `fileDrop` control target. Runtime shows the asset as an attached file, users can remove it, and Reset restores it.
+`sourceTarget` must match a compatible `fileDrop` control target. Runtime shows the asset as an attached file, users can remove it, and Reset restores it. Model defaults require `assetKind: "model"`, a root `fileName`, and complete local `sourceFiles`; each source uses a serializable `dataUrl` plus its bundle-relative `path`. Runtime restores default models through the same validation, analysis, repair, repository, and rendering pipeline as a user upload. Persisted empty media remains empty until Reset and must not silently resurrect defaults.
+
+For a multi-item `fileDrop`, `recommendedMaxItems` is advisory. `hardMaxItems`, when present, must be a finite nonnegative safe integer and is enforced before decode or storage allocation. Additive imports count current assets with the same `sourceTarget` plus the incoming logical batch; replacement imports count only the incoming batch.
+
+## Model FileDrop
+
+Declare appearance-preserving 3D import through the built-in control:
+
+```ts
+model: {
+  type: "fileDrop",
+  assetKind: "model",
+  target: "source.model",
+  label: "Model",
+  topologyProfile: "realtime-mesh",
+  modelFormats: ["glb", "gltf", "fbx", "obj", "stl", "ply"],
+  modelLimits: {
+    maxTriangles: 1_000_000,
+  },
+  performanceRole: "workload",
+  performanceReason: "Imported topology controls decode, analysis, repair, and render cost.",
+}
+```
+
+`modelFormats` may narrow the production adapters but cannot advertise an unavailable format. `modelLimits` may narrow normalized runtime admission limits; do not widen protected ceilings in product code. `topologyProfile` is `"realtime-mesh"` or `"solid-mesh"`. Model upload is one package (`multiple: false`): a standalone root, a folder batch with relative paths, or one bounded ZIP. Runtime preserves the supported authored appearance subset, selects the first normalized supported root, and uses the Blender-compatible fallback only when authored appearance is absent. Product code does not add loaders, topology state, repair actions, material reconstruction, or a second model store/cache.
+
+Composition declares the presentation owner:
+
+```ts
+export const appComposition: ToolcraftAppComposition = {
+  modelPresentation: { mode: "runtime" },
+  schema: appSchema,
+};
+```
+
+For a true custom model canvas, use `mode: "custom"` with unique `{ id, sourceTarget, orientationTarget? }` declarations and mount `useToolcraftModelPresentationConsumer` for each declaration. Custom consumers acquire and release presentation leases; they never parse source files or call format loaders. `renderDefaultCanvasMedia: false` does not suppress runtime model presentation.
 
 ## Panels
 
@@ -72,36 +145,36 @@ toolbar: {
 }
 ```
 
-History owns undo/redo and keyboard shortcuts. Do not add route-local undo/redo listeners.
+History owns undo/redo and keyboard shortcuts. Do not add route-local undo/redo listeners. Standard shortcuts operate from focused non-text controls such as sliders and switches; active text-entry fields retain native text undo until editing ends.
 
 ## Control Fields
 
 Common control fields:
 
-| Field | Purpose |
-| --- | --- |
-| `type` | Built-in type or registered custom renderer type. |
-| `target` | Runtime state target. |
-| `defaultValue` | Initial value and reset value. |
-| `label` | Short UI label, `false`, or omitted. |
-| `description` | Product-specific help text only when it adds meaning beyond the label. |
-| `visibleWhen` | Mode/type/source/include/variant/count visibility. Hidden values are preserved. |
-| `orderRole` | Makes section order testable. |
-| `semanticGroup` | Language-independent product sub-entity/workflow grouping, required on every control in sections larger than seven controls. |
-| `sliderValueKind` | `slider` intent: `"continuous"` or `"discrete"`. |
-| `textValueKind` | `text`/`code` intent: `"single-line"`, `"multiline"`, or `"structured"`. |
-| `curveIntent` | `curves` composition: `"single-value-map"` or `"color-channels"`. |
-| `performanceRole` | `"workload"` or `"responsiveness"` for coverage derivation. |
-| `performanceReason` | Why the role fits this app. |
-| `commitMode` | `text` controls: `"content"` applies while typing, `"setting"` commits on blur/Enter. |
-| `keyframeable` | Timeline/keyframe capability override when structurally needed. |
-| `variant` | Component-specific variant. |
+| Field               | Purpose                                                                                                                      |
+| ------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
+| `type`              | Built-in type or registered custom renderer type.                                                                            |
+| `target`            | Runtime state target.                                                                                                        |
+| `defaultValue`      | Initial value and reset value.                                                                                               |
+| `label`             | Short UI label, `false`, or omitted.                                                                                         |
+| `description`       | Product-specific help text only when it adds meaning beyond the label.                                                       |
+| `visibleWhen`       | Mode/type/source/include/variant/count visibility. Hidden values are preserved.                                              |
+| `orderRole`         | Makes section order testable.                                                                                                |
+| `semanticGroup`     | Language-independent product sub-entity/workflow grouping, required on every control in sections larger than seven controls. |
+| `sliderValueKind`   | `slider` intent: `"continuous"` or `"discrete"`.                                                                             |
+| `textValueKind`     | `text`/`code` intent: `"single-line"`, `"multiline"`, or `"structured"`.                                                     |
+| `curveIntent`       | `curves` composition: `"single-value-map"` or `"color-channels"`.                                                            |
+| `performanceRole`   | `"workload"` or `"responsiveness"` for coverage derivation.                                                                  |
+| `performanceReason` | Why the role fits this app.                                                                                                  |
+| `commitMode`        | `text` controls: `"content"` applies while typing, `"setting"` commits on blur/Enter.                                        |
+| `keyframeable`      | Timeline/keyframe capability override when structurally needed.                                                              |
+| `variant`           | Component-specific variant.                                                                                                  |
 
 Use `visibleWhen` for product availability. Do not use `disabled`, `disabledWhen`, or inert visible controls for generated product branches.
 
 Conditions support `equals`, `notEquals`, `oneOf`, `notOneOf`, `greaterThan`, `greaterThanOrEqual`, `lessThan`, and `lessThanOrEqual`.
 
-Reserved runtime targets include `runtime.settingsTransfer`, `canvas.aspectRatio`, `canvas.size.width`, `canvas.size.height`, `canvas.renderScale`, and `panels.timeline.extended`. Product sections must not declare those controls.
+Reserved runtime targets include `runtime.settingsTransfer`, `canvas.infinity`, `canvas.aspectRatio`, `canvas.size.width`, `canvas.size.height`, `canvas.renderScale`, and `panels.timeline.extended`. Product sections must not declare those controls.
 
 ## Built-In Control Types
 
@@ -116,6 +189,7 @@ Reserved runtime targets include `runtime.settingsTransfer`, `canvas.aspectRatio
 | `code` | `CodeTextarea` |
 | `select` | `Select` |
 | `segmented` | `Segmented` |
+| `tabs` | `TabsControl` |
 | `switch` | `Switch` |
 | `checkbox` | `Checkbox` |
 | `actions` | `Actions` |
@@ -124,6 +198,7 @@ Reserved runtime targets include `runtime.settingsTransfer`, `canvas.aspectRatio
 | `colorOpacity` | `ColorOpacity` |
 | `palette` | `Palette` |
 | `vector` | `Vector` |
+| `orientationGizmo` | `ToolcraftOrientationGizmo` |
 | `color` | `Color` |
 | `gradient` | `Gradient` |
 | `fontPicker` | `FontPicker` |
@@ -137,6 +212,81 @@ Reserved runtime targets include `runtime.settingsTransfer`, `canvas.aspectRatio
 
 Use `component-rules.md` for component-specific fit, labels, variants, units, parser behavior, and exceptions. Use `core/control-selection.md` before deciding a custom control is needed.
 
+`orientationGizmo` uses a non-degenerate `{ position: [x, y, z], up: [x, y, z] }` default, `label: false`, and `keyframeable: false`. Declare one target for the active/selected model and keep it beside at least one visible product control in the semantic model/view section; runtime renders the handle on the canvas rather than in the controls panel. Multiple declarations require statically provable mutually exclusive combined section/control visibility conditions, because runtime permits at most one active orientation handle.
+
+## Product View Interaction
+
+Product-mode `starterProductReadiness` always declares the spatial view decision
+before schema controls or renderer code:
+
+```ts
+export const starterProductReadiness: ToolcraftProductReadiness = {
+  interactionOwnership: [],
+  mode: "product",
+  productName: "Model Studio",
+  productSummary: "An editable three-dimensional product scene.",
+  requestedBehavior: "Rotate the model and export the selected view.",
+  viewInteraction: {
+    mode: "orbit",
+    orientationTargets: ["view.orbit"],
+  },
+};
+```
+
+## Interaction Surface Ownership
+
+Product readiness declares `interactionOwnership` before controls or canvas
+interactions. Each operation uses one primary surface while distinct operations
+may edit related state across surfaces:
+
+```ts
+interactionOwnership: [
+  {
+    alternative: {
+      reason: "A panel copy would separate the same drag from visible output.",
+      surface: "panel",
+    },
+    capability: "direct-spatial-edit",
+    evidence: {
+      detail: "The inspected reference exposes draggable handles over output.",
+      source: "reference",
+    },
+    id: "output-position-drag",
+    reason: "Canvas drag preserves spatial correspondence and immediate feedback.",
+    surface: "canvas",
+    target: "output.position",
+  },
+  {
+    alternative: {
+      reason: "The canvas would obscure output with persistent property chrome.",
+      surface: "canvas",
+    },
+    capability: "property-edit",
+    evidence: {
+      detail: "A usability comparison keeps non-spatial properties discoverable.",
+      source: "usability-analysis",
+    },
+    id: "output-position-properties",
+    reason: "The panel exposes useful properties without duplicating direct drag.",
+    surface: "panel",
+    target: "output.position",
+  },
+]
+```
+
+Capabilities are `direct-spatial-edit`, `spatial-selection`,
+`structured-selection`, `property-edit`, `precise-value-entry`,
+`collection-edit`, and `command`. Evidence sources are `user-request`,
+`reference`, and `usability-analysis`. Canvas handles and custom interactions
+reference the inventory through acceptance `interactionId`; a built-in panel
+control also references it when its target overlaps a canvas handle.
+
+Use `non-spatial` only when no visible three-dimensional scene/model exists.
+Use `fixed-camera` or `timeline-camera` only with `source:
+"explicit-user-request" | "inspected-reference"` and non-empty `evidence`.
+Timeline camera also requires timeline playback/keyframes. Orbit targets must
+exactly match schema `orientationGizmo` targets.
+
 ## Control Section Inventory
 
 Before writing `panels.controls.sections`, export `starterControlSectionInventory` beside `starterAcceptance`:
@@ -167,39 +317,41 @@ Video references declare `videoReferenceStudy` before implementation. Animated p
 
 ## Export And Actions
 
-Product apps expose delivery through sticky `panelActions`, not canvas UI or ordinary body controls. Still products expose `Export PNG`; animated products expose `Export Video` plus `Export PNG`.
-
-Every app with `Export PNG` includes `Image Export` controls with `export.image.format` and `export.image.resolution`. Animated apps also include `Video Export` controls with `export.video.format` and `export.video.resolution`.
+Product apps expose delivery through sticky `panelActions`, not canvas UI or ordinary body controls. Every product exposes `Export PNG`; products whose requested delivery includes animation also expose `Export Video`. A playback or keyframe timeline may drive interactive preview without inventing video delivery.
 
-Use standard helpers:
+Every app with `Export PNG` includes `Image Export` controls with `export.image.format` and `export.image.resolution`. Apps with `Export Video` also include `Video Export` controls with `export.video.format` and `export.video.resolution`.
 
-- `createToolcraftPngExportCanvas({ resolution, includeBackground, state, render })`
-- `shouldIncludeToolcraftPreviewBackground(state)`
-- `getToolcraftVideoExportSize({ resolution, state })`
+Use the standard runtime path: declare typed `export-image`/`export-video` panel actions and their settings, provide one `ToolcraftAppComposition.exportRenderer` when product code contributes pixels, and draw one deterministic frame from the supplied state/time in scene coordinates. Call `shouldIncludeToolcraftPreviewBackground(state)` only for bounded live preview; runtime owns artifact composition, sizing, encoding, download, progress, and errors.
 
 Detailed Setup, Background, Image Export, Video Export, sticky action, icon, and progress rules live in `core/setup-export.md`.
 
 ## Persistence
 
-Use persistence only for intentional user-edited state:
+Generated apps persist their runtime workspace locally by default. The resolved base plan contains `"canvas"`, `"panels"`, and `"values"`; enabled timeline, layers, and media capabilities add `"timeline"`, `"layers"`, and `"media"` automatically. Most apps do not need a `persistence` field.
+
+Use an explicit localStorage configuration only to customize the key/version or request additional compatible slices:
 
 ```ts
 persistence: {
   storage: "localStorage",
-  key: "my-toolcraft-app",
-  version: 1,
-  include: ["values", "canvas", "panels"],
+  key: "toolcraft:my-app:state:v3",
+  version: 3,
+  include: ["timeline"], additionalValueTargets: ["composition.layout"],
 }
 ```
 
-Add `"timeline"`, `"layers"`, or `"media"` only when those runtime slices should survive reload. If localStorage is enabled, add reload acceptance coverage.
+Explicit `include` augments rather than removes capability-derived slices. Control-backed values persist automatically; `additionalValueTargets` opts product-owned non-control state into persistence after trimming and deduplication, while empty entries and undeclared values remain excluded. `{ storage: "none" }` is the only opt-out; record why losing the workspace on reload is intentional.
+
+localStorage contains only small versioned JSON metadata. Image, file, and model bytes live in the Toolcraft binary repository backed by IndexedDB; persisted media records contain resource references, never data URLs. Product code must not read or write either storage API directly. Reset restores schema defaults, Settings Transfer remains the portable JSON boundary, and unavailable binary resources become typed per-asset failures without discarding other restored slices.
+
+Every local app declares `persistenceCoverage: "reload"`, `evidence: "persistence-state"`, and `persistenceSlices` exactly equal to the resolved `schema.persistence.include`, then proves the visible workspace after a real browser reload.
 
 ## Settings Transfer
 
 `settingsTransfer` customizes runtime-owned settings import/export identity:
 
 ```ts
-settingsTransfer: "auto"
+settingsTransfer: { enabled: "auto", additionalValueTargets: ["composition.layout"] };
 ```
 
-Allowed values are `"auto"`, `true`, `false`, or `{ enabled, appId, fileName }`. None of these hide mandatory runtime `Setup`; they only affect metadata. Do not implement settings import/export through `panelActions`, hidden file inputs, or route-local handlers.
+Allowed values are `"auto"`, `true`, `false`, or `{ enabled, appId, fileName, additionalValueTargets }`. Control-backed values transfer automatically; `additionalValueTargets` opts product-owned non-control state into settings JSON while undeclared values stay excluded. Transfer and persistence allowlists are independent; both are trimmed and deduplicated during resolution. None of these options hide mandatory runtime `Setup`; do not implement settings import/export through `panelActions`, hidden file inputs, or route-local handlers.

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

@@ -1,5 +1,10 @@
 # Toolcraft Workflow
 
+<!-- toolcraft-performance-lifecycle: first-delivery=functional; later-delivery=functional-targeted; complaint=one-authority-targeted-performance-iteration; full-audit=explicit-only -->
+<!-- toolcraft-performance-iteration: authority=exact-request-evidence+canonical-path-ids; fixture=reachable-development; after-pass=return-app-to-user+stop -->
+<!-- toolcraft-performance-full-authority: automatic=forbidden; recommendation=two-compatible-iterations-or-broad-unlocalizable-problem; command=pnpm verify:perf; authority=explicit-user-request-or-accepted-offer -->
+<!-- toolcraft-performance-routing: localized=agent-targeted; ambiguous=one-user-facing-choice; broad=offer-targeted-or-full; full=explicit-only -->
+
 This file is the app-local routing layer for Toolcraft work. It does not replace the detailed contracts; it tells an agent which contract to read and which verification path to use before editing.
 
 ## Required Preflight
@@ -13,13 +18,15 @@ Before planning or editing app code, runtime code, controls, canvas, panels, ren
    - **Runtime/template source**: use root `AGENTS.md` and runtime contracts.
 3. Classify the task type.
 4. Read the task-specific docs below.
-5. Choose and record a verification tier before implementation.
+5. Record the coherent user-visible delivery batch and its focused development checks before implementation.
 
 Do not edit implementation files until this preflight is complete.
 
+Renderer and performance work also completes this pre-code sequence: reachable controls and inputs; workload dimensions and enforced boundaries; pass cost, frequency, lifecycle, and invalidation; render-plan assessment and protected kernel benchmark when required; derived paths and combined fixtures. Keep `src/app/app-verification-impact.json` current while implementing. Development uses impact-derived functional and browser checks without minting delivery evidence. First and later functional delivery run no measured performance; only exact request authority creates one targeted iteration. Full certification is a separate operator/CI action described in the canonical performance docs.
+
 ## Local Contract Authority
 
-The signed local `AGENTS.md` plus `docs/toolcraft/*` are sufficient and mandatory workflow input for a standalone generated app. External workflow skills should be used when available, but missing skills never invalidate `--no-skills` generation and never justify skipping the equivalent local spec, plan, debugging, browser, or verification requirement. `pnpm ai:check` enforces local code health and reports missing external skills as actionable guidance rather than a build failure.
+The signed local `AGENTS.md` plus `docs/toolcraft/*` are sufficient and mandatory workflow input for a standalone generated app. External workflow skills should be used when available, but missing skills never invalidate `--no-skills` generation and never justify skipping the equivalent local spec, plan, debugging, browser, or verification requirement. `pnpm ai:check` enforces local code health and the product AST boundary only; it neither discovers nor validates workflow skill installations.
 
 Core modules are required reading when listed by the routing table. Read each listed module fully, one phase at a time. Open exactly one listed document per terminal or tool read, even when several documents belong to the same route and phase. Do not concatenate documents or rely on a truncated excerpt; finish the current phase, then open the next phase when the work reaches it. The signed host and runtime validators enforce platform boundaries, while product organization remains open inside those boundaries.
 
@@ -46,24 +53,26 @@ Use the smallest route set that covers the changed surface. When a task matches
 
 For product app work, update `docs/toolcraft/agent-worklog.md` before reporting completion. Record:
 
-- `Decision Trail` entries for each significant implementation pass, including:
+- one `Decision Trail` entry for each coherent user-visible delivery batch, including:
   - request;
   - task type;
   - user-visible result;
   - source/reference checked;
-  - docs/contracts read;
-  - contract rules applied;
+  - docs/contracts read and contract rules applied;
+  - typed view interaction mode, evidence, and orientation target mapping when the product has a spatial scene;
+  - typed interaction ownership for operations that could live on canvas or in the panel, including evidence, selected surface, rejected duplicate surface, and complementary operations;
   - decision;
   - alternatives rejected;
   - state/output mapping from controls, commands, timeline, layers, media, or renderer to the visible product;
-  - files changed;
-  - verification;
-  - skipped checks with reason;
+  - one bare-delivery verification narrative;
   - risks or follow-ups.
-- updated high-level decisions for renderer, timeline, layers, controls, export, and performance when those choices change.
+- for localized performance work, or a post-clarification targeted choice, an exact request quote and the canonical affected performance path IDs; classifier output establishes complaint authority only, and unresolved localization records neither performance-iteration intent nor canonical path authority regardless of classifier result.
+- updated high-level decisions for renderer, view interaction, interaction ownership, timeline, layers, controls, export, and performance when those choices change.
 
 If the folder is still the neutral starter, do not invent product decisions. Once it becomes a product, switch the worklog to product mode and keep it concrete.
 
+Protected receipts, not the worklog, own changed files, the derived plan, executed checks, reports, measurements, and pass/fail evidence. Each Decision Trail entry mentions only that one bare `pnpm verify:delivery` will derive and run the protected proof.
+
 ## Runtime Boundary
 
 Use the runtime extension points described in the current contracts:
@@ -78,20 +87,31 @@ Do not recreate controls, panels, toolbar, timeline, layers, canvas shell, or ru
 
 Browser verification is outcome-based. Protected helpers attach versioned evidence only after a persistent observable change, an observed fixture application, a decoded non-empty export inspection, a completed output action, an immutable scenario measurement, and its matching budget check. The signed reporter derives required evidence from acceptance and performance config and fails skipped, missing, duplicate, transient, unmeasured, or unbudgeted scenarios.
 
-## Verification Gate
+## Automatic Delivery Lifecycle
+
+The normal product loop is:
+
+```text
+assemble/change
+→ focused functional feedback
+→ one coherent delivery boundary
+→ protected functional delivery
+→ user evaluation
+```
+
+Use the smallest focused unit and browser checks while implementation is changing. Do not rerun the aggregate, export, or performance matrix after every edit. At the coherent delivery boundary, run one bare `pnpm verify:delivery` and use the automatic sequence:
 
-Choose the tier from `AGENTS.md` before editing. Use the tier to decide checks.
+1. **First product delivery:** bare `pnpm verify:delivery` proves complete product contracts, performs one production build, runs full functional acceptance, and runs no measured performance.
+2. **Later functional-targeted delivery:** bare `pnpm verify:delivery` compares the immediate previous and current semantic functional proof models. It selects exact changed acceptance contracts, their direct owners and domains, and tests reached through the affected product-unit dependency graph.
+3. **Localized or clarified targeted work:** only a localized complaint or a post-clarification targeted choice records domain authority in the worklog—an exact request quote plus canonical affected path IDs—and runs one bare `pnpm verify:delivery`. It executes one targeted iteration against the reachable development fixture, returns the verified app, and waits for user evaluation. Classifier output alone never localizes a path; unresolved localization creates neither performance-iteration intent nor canonical path authority, whether classification returned high-confidence `performance-iteration` or `needs-agent-judgment`.
+4. **Full audit:** only an explicit operator request or accepted offer authorizes `pnpm verify:perf`. It performs one fresh build and the complete maximum-fixture performance matrix without advancing the delivery anchor.
 
-- Tier 0-1: targeted docs/typecheck/unit plus focused browser when visual.
-- Tier 2: `pnpm verify:quick` plus relevant browser acceptance.
-- Tier 3: `pnpm verify:quick`, targeted browser acceptance, and targeted performance scenarios only for touched workload/viewport/export paths.
-- Tier 4: run `node scripts/check-toolcraft-integrity.mjs` directly. For the first working product version, run the browser performance checkpoint and record its current-source receipt first, then run `pnpm verify:final`, then start `pnpm dev` for the local URL.
+Performance authority and localization are separate decisions. Classifier output establishes complaint authority only and never path localization. A localized complaint lets the agent select the affected canonical paths and run one targeted iteration without asking the user. For an ambiguous complaint, ask one user-facing question that names the visible operation and offers targeted diagnosis or a complete performance review; never ask the user to choose internal path IDs, and record no performance-iteration intent or canonical path authority before the answer. For a broad or honestly unlocalizable problem, the agent may recommend the complete performance review in that single targeted/full choice, but the user still chooses. A direct request for the complete performance review runs `pnpm verify:perf` without another clarification.
 
-Run a full performance checkpoint only when:
+Store agent-produced browser diagnostics under `.toolcraft/browser-artifacts/`. Browser integrations may instead use their external tool-owned storage; diagnostic files never belong in product source.
 
-- the first working version of the app exists;
-- the user explicitly asks to optimize performance, fix lag, remove jank, speed up animation, stabilize drag/zoom, or otherwise complains about performance.
+The unchanged `sourceHash` fast path does not collect the catalog, dependency graph, or functional proof model and does not execute proof. For a changed source, the current catalog, input roles, ownership inventory, and semantic model are collected once and remain the immutable basis for that delivery plan. `workflow-observation.md` is a post-delivery summary, not execution authority, so it stays outside this hash; `agent-worklog.md` remains included.
 
-Fast feature loops after the first working version do not run the full performance suite by default. Renderer, canvas, animation, export, timeline, layers, `canvas.renderScale`, bug fixes, and performance-sensitive controls still need targeted functional/browser checks first, plus targeted performance scenarios only when they directly exercise the touched path. Record any skipped full performance run and reason in the worklog.
+After two consecutive compatible targeted iterations, offer the slower full audit if the user remains unsatisfied. A complaint, filename, or touched subsystem never authorizes it. Canonical classification details, failure behavior, and evidence wording live in `core/performance.md` and `performance.md`.
 
-The app is not complete when required checks are failed, incomplete, pending, blocked, or listed as skipped. Run the integrity checker directly before the final gate so verification does not depend only on mutable package-script dispatch. First working product delivery runs `pnpm verify:perf` before `pnpm verify:final`; the protected Playwright checkpoint records the machine receipt, while agent-controlled browser work remains targeted diagnostic evidence. `verify:final` rejects missing or stale receipts. After the first working version, use the typed `pnpm verify:perf:record-exemption -- --tier=<0|1|2>` path only for a post-first-working non-performance edit backed by a prior passed receipt.
+The app is not complete when required checks are failed, incomplete, pending, blocked, or listed as skipped. Resolve benchmark requirements with the protected internal kernel check before accepting the renderer. The delivery runner executes integrity and lifecycle-specific proof atomically, binds evidence to current source, and advances the delivery anchor only after success. Product prose and command arguments cannot select or broaden that proof.

package/templates/starter/e2e/app-browser-control-coverage.spec.ts

@@ -1,14 +1,43 @@
 import { expect, test } from "@playwright/test";
-import type { ToolcraftPerformanceConfig } from "@repo/toolcraft-runtime";
-
-import { parseToolcraftBrowserRuntimeEvidence } from "../src/app/test-evidence/browser-runtime-contract";
 import { expectToolcraftExportedArtifact } from "./browser-acceptance-outcome-helpers";
 import {
-  dragToolcraftSliderToPerformanceStressValue,
+  expectToolcraftDiscreteSliderMarkers,
   expectToolcraftSegmentedControlCellsPreservePadding,
   getToolcraftFieldByLabel,
 } from "./performance-helpers";
 
+test("discrete slider layout accepts one interior marker and rejects none", async ({
+  page,
+}) => {
+  await page.setContent(`
+    <div data-slot="toolcraft-runtime-app">
+      <div data-toolcraft-control-target="canvas.renderScale">
+        <div data-slot="field" style="display:block;width:200px;height:24px;">
+          <div data-slot="slider" data-variant="discrete" style="display:block;width:200px;height:24px;">
+            <span data-slot="slider-marker" style="display:block;width:1px;height:6px;"></span>
+          </div>
+        </div>
+      </div>
+    </div>
+  `);
+
+  await expectToolcraftDiscreteSliderMarkers(page, "canvas.renderScale");
+
+  await page.setContent(`
+    <div data-slot="toolcraft-runtime-app">
+      <div data-toolcraft-control-target="canvas.renderScale">
+        <div data-slot="field" style="display:block;width:200px;height:24px;">
+          <div data-slot="slider" data-variant="discrete" style="display:block;width:200px;height:24px;"></div>
+        </div>
+      </div>
+    </div>
+  `);
+
+  await expect(
+    expectToolcraftDiscreteSliderMarkers(page, "canvas.renderScale"),
+  ).rejects.toThrow(/at least one interior marker/);
+});
+
 test("segmented layout helper catches paddingless or colliding cells", async ({ page }) => {
   await page.setContent(`
     <div data-slot="field">FX Preset
@@ -49,56 +78,6 @@ test("performance helpers match control labels literally", async ({ page }) => {
   );
 });
 
-test("slider stress helper applies the declared value and emits runtime evidence", async ({
-  page,
-}, testInfo) => {
-  await page.setContent(`
-    <div data-slot="toolcraft-runtime-app">
-      <div class="contents" data-toolcraft-control-target="density.value">
-        <div data-slot="field">Density
-          <input data-slot="slider" role="slider" type="range" min="0" max="10" value="0" style="width:200px;height:20px;" />
-        </div>
-      </div>
-    </div>
-  `);
-  const config = {
-    rendererStrategy: "none",
-    rendererWorkload: "none",
-    scenarios: [{
-      automated: true,
-      automatedTestName: "perf: density stress",
-      browser: true,
-      browserTestName: "browser perf: density stress",
-      budget: { maxInteractionMs: 500 },
-      expectedObservable: "Density drag completes.",
-      fixture: "Density stress fixture.",
-      id: "density-stress",
-      interaction: "control-drag",
-      stressFixture: { kind: "max-value", reason: "Maximum density.", value: 9 },
-      target: "density.value",
-      workload: true,
-    }],
-    usesCustomRenderer: false,
-    workloadTargets: ["density.value"],
-  } as const satisfies ToolcraftPerformanceConfig;
-
-  await dragToolcraftSliderToPerformanceStressValue(
-    page,
-    "Density",
-    config,
-    "density-stress",
-  );
-
-  expect(
-    testInfo.attachments.map((attachment) =>
-      parseToolcraftBrowserRuntimeEvidence(attachment)?.evidenceType,
-    ),
-  ).toEqual(expect.arrayContaining([
-    "performance-control-drag",
-    "performance-stress-fixture",
-  ]));
-});
-
 test("export acceptance rejects a verifier that does not return an artifact observation", async () => {
   await expect(
     expectToolcraftExportedArtifact(