stylegallery 0.1.4 → 0.1.7

package/design-engineering/state-management/recipes/multi-step-form.md

@@ -0,0 +1,65 @@
+---
+type: Domain Guide
+title: Multi-Step Form With Retained Draft
+description: Retain entered values across steps and guard progression and final submission.
+domain: design-engineering
+lifecycle: experimental
+provenance_kind: local
+---
+
+# Multi-Step Form With Retained Draft
+
+## Repository Boundary
+
+Retain entered values across steps and guard progression and final submission. This is a consumer interaction composition in Design Engineering. Spatial structure comes from [Form Flow](../../../recipes/form-flow.md); this recipe adds no reusable Layout behavior.
+
+## Reusable Method
+
+### Selected Pattern Stack
+
+[single owner](../patterns/single-owner.md), [draft/baseline](../patterns/draft-and-baseline.md), [submitted snapshot](../patterns/submitted-snapshot.md), [unsaved navigation](../patterns/unsaved-navigation.md).
+
+### Ownership And Event Flow
+
+The flow owns all field values and current step; each field emits intents. Validity is derived from relevant fields. The final operation owns the submitted snapshot. Unmounting a step does not destroy the flow draft.
+
+Edit → validate current step → advance if allowed. Back preserves values. Changing an earlier answer recomputes eligibility and invalidates dependent values under an explicit policy. Final Submit captures the whole valid draft once.
+
+### Composition And Substitution
+
+An in-memory step is enough when deep links are not a requirement; use URL state when they are. Versioned restore is optional for long flows and requires retention/privacy decisions. Do not persist request-pending flags.
+
+### Acceptance Sequences
+
+| Sequence | Expected outcome |
+| --- | --- |
+| Advance, go Back, revisit | Values persist; errors follow current validity |
+| Change an earlier branching answer | Hidden dependent answers are cleared or excluded under declared policy |
+| Deep-link to a later step | Guard prerequisites or redirect without silently submitting |
+| Fail final submission | Retain all fields and provide a route to the relevant error |
+| Edit while final save completes | Preserve later edits using snapshot semantics |
+
+## Opinionated Guidance
+
+Keep the ownership boundaries visible when composing the patterns. One screen can combine these mechanisms without making every value global. Record the rejected alternative and its user-visible cost in the [state brief](../state-brief.md).
+
+## Platform-Specific Guidance
+
+Announce step context and move focus to the step heading or first invalid field as appropriate. Step order, DOM order, and validation routes must agree.
+
+## Unsupported Absolutes
+
+These acceptance sequences are proposed integration checks, not captured product evidence. Pattern model tests do not prove this entire screen, its backend, or its focus behavior.
+
+## Verification Contract
+
+Adapt every acceptance row to the consumer and record actual results with the [verification matrix](../verification.md). Include the ordinary successful task and at least one interrupted task. The initial handoff is `consumer_reference: not_applicable` because this fictional recipe selects no consumer profile or conformance record.
+
+## Source, License, And Attribution
+
+Locally authored synthesis and examples. No upstream implementation is copied. These experimental contracts describe consumer-owned behavior; review when a failure, ownership change, or platform change invalidates an assumption.
+
+## IA Navigation
+
+Parent: [State Management](index.md).
+Next: [Continue the state management route](../verification.md).

package/design-engineering/state-management/recipes/search-detail.md

@@ -0,0 +1,65 @@
+---
+type: Domain Guide
+title: Search Filters And Detail Selection
+description: Preserve query context and entity identity across asynchronous search and history navigation.
+domain: design-engineering
+lifecycle: experimental
+provenance_kind: local
+---
+
+# Search Filters And Detail Selection
+
+## Repository Boundary
+
+Preserve query context and entity identity across asynchronous search and history navigation. This is a consumer interaction composition in Design Engineering. Spatial structure comes from [List Detail](../../../recipes/list-detail.md); this recipe adds no reusable Layout behavior.
+
+## Reusable Method
+
+### Selected Pattern Stack
+
+[URL state](../patterns/url-state.md), [latest request wins](../patterns/latest-request-wins.md), [ID selection](../patterns/id-selection.md), [derived state](../patterns/derived-state.md).
+
+### Ownership And Event Flow
+
+The field owns its typing buffer; the route owns committed query/filter/page; the request owner holds results and query identity; the screen or route owns selected ID. A result collection is not necessarily the full entity inventory.
+
+Commit query → reset page → update history → start read → accept only matching outcome. Back reads the route and starts the corresponding read without pushing another entry. Selected detail may be fetched separately with its own keyed request owner.
+
+### Composition And Substitution
+
+URL state can be replaced by screen-local committed state when sharing/history is explicitly unnecessary. Stable identity and stale-read handling remain essential. Debounce may reduce traffic but cannot substitute for request correlation.
+
+### Acceptance Sequences
+
+| Sequence | Expected outcome |
+| --- | --- |
+| Request A/B, resolve B/A | B results and status remain displayed |
+| Change query on page 3 | Commit new query with page 1 |
+| Back then Forward | Controls, query identity, and results follow route history |
+| Selected item absent from filtered page | Retain or explicitly mark unavailable; do not infer deletion |
+| Delete selected entity authoritatively | Apply missing-detail policy and recover focus |
+
+## Opinionated Guidance
+
+Keep the ownership boundaries visible when composing the patterns. One screen can combine these mechanisms without making every value global. Record the rejected alternative and its user-visible cost in the [state brief](../state-brief.md).
+
+## Platform-Specific Guidance
+
+Preserve typed input during IME composition. Label previous results during refresh; an empty accepted result must differ from loading or failure.
+
+## Unsupported Absolutes
+
+These acceptance sequences are proposed integration checks, not captured product evidence. Pattern model tests do not prove this entire screen, its backend, or its focus behavior.
+
+## Verification Contract
+
+Adapt every acceptance row to the consumer and record actual results with the [verification matrix](../verification.md). Include the ordinary successful task and at least one interrupted task. The initial handoff is `consumer_reference: not_applicable` because this fictional recipe selects no consumer profile or conformance record.
+
+## Source, License, And Attribution
+
+Locally authored synthesis and examples. No upstream implementation is copied. These experimental contracts describe consumer-owned behavior; review when a failure, ownership change, or platform change invalidates an assumption.
+
+## IA Navigation
+
+Parent: [State Management](index.md).
+Next: [Continue the state management route](../verification.md).

package/design-engineering/state-management/recipes/settings-save.md

@@ -0,0 +1,64 @@
+---
+type: Domain Guide
+title: Settings With Explicit Save
+description: Edit and save preferences without losing later input or leaving with unsaved work.
+domain: design-engineering
+lifecycle: experimental
+provenance_kind: local
+---
+
+# Settings With Explicit Save
+
+## Repository Boundary
+
+Edit and save preferences without losing later input or leaving with unsaved work. This is a consumer interaction composition in Design Engineering. Spatial structure comes from [SaaS Settings](../../../recipes/saas-settings.md); this recipe adds no reusable Layout behavior.
+
+## Reusable Method
+
+### Selected Pattern Stack
+
+[draft/baseline](../patterns/draft-and-baseline.md), [submitted snapshot](../patterns/submitted-snapshot.md), [single flight](../patterns/single-flight.md), [unsaved navigation](../patterns/unsaved-navigation.md).
+
+### Ownership And Event Flow
+
+The form owns draft; the server owns persisted data; the save attempt owns the snapshot; the router owns pending departure. Dirty is derived. Account changes invalidate the entire form generation.
+
+Edit → validate → capture snapshot → save → reconcile acknowledgement → re-evaluate dirty. For Save-and-leave, leave only after successful reconciliation and only if no newer edits remain.
+
+### Composition And Substitution
+
+Explicit-save semantics require the snapshot and draft separation. A single-flight guard can share or ignore repeats; queuing requires a separately defined sequence of snapshots. Immediate autosave is a different recipe with debounce, ordering, and conflict rules.
+
+### Acceptance Sequences
+
+| Sequence | Expected outcome |
+| --- | --- |
+| Submit A, edit B, acknowledge A | Baseline A; draft B remains dirty; stay if leaving was requested |
+| Save fails, then retry | Preserve draft and release the operation guard |
+| Remote revision conflict | Preserve draft; offer reload/merge under consumer policy |
+| Cancel departure | Keep draft and return focus to the invoker |
+
+## Opinionated Guidance
+
+Keep the ownership boundaries visible when composing the patterns. One screen can combine these mechanisms without making every value global. Record the rejected alternative and its user-visible cost in the [state brief](../state-brief.md).
+
+## Platform-Specific Guidance
+
+The form must connect errors to fields and announce completion without implying newer edits were saved. A disabled submit control is not the duplicate guard.
+
+## Unsupported Absolutes
+
+These acceptance sequences are proposed integration checks, not captured product evidence. Pattern model tests do not prove this entire screen, its backend, or its focus behavior.
+
+## Verification Contract
+
+Adapt every acceptance row to the consumer and record actual results with the [verification matrix](../verification.md). Include the ordinary successful task and at least one interrupted task. The initial handoff is `consumer_reference: not_applicable` because this fictional recipe selects no consumer profile or conformance record.
+
+## Source, License, And Attribution
+
+Locally authored synthesis and examples. No upstream implementation is copied. These experimental contracts describe consumer-owned behavior; review when a failure, ownership change, or platform change invalidates an assumption.
+
+## IA Navigation
+
+Parent: [State Management](index.md).
+Next: [Continue the state management route](../verification.md).

package/design-engineering/state-management/state-brief.md

@@ -0,0 +1,83 @@
+---
+type: Domain Guide
+title: State Management Brief
+description: Record authority, transitions, effects, lifetime, and acceptance cases before implementation.
+domain: design-engineering
+lifecycle: experimental
+provenance_kind: local
+---
+
+# State Management Brief
+
+## Repository Boundary
+
+This is a consumer planning template within Design Engineering. It supplements the [Component Contract](../component-contract.md); it is not a profile schema or evidence record.
+
+## Reusable Method
+
+For each independently owned value, complete one inventory row. Avoid a single status enum that conflates validation, request progress, persisted revision, and selection.
+
+| Field | Required answer |
+| --- | --- |
+| User task | Action and observable result |
+| Authoritative source | Server, route, form, component, or session owner |
+| State shape | Valid values, initial value, identity and revision |
+| Derived values | Inputs, equality, and cache invalidation if any |
+| Writes | Accepted intents, payloads, rejection and normalization |
+| Transitions | Event + guard → next state + effect |
+| Lifetime | Creation, identity switch, navigation, disposal and cleanup |
+| Async policy | Request identity, duplicates, stale results, uncertainty |
+| Persistence | Stored fields, scope, version, expiry, restoration conflicts |
+| Recovery | Retry, discard, reconciliation and focus destination |
+| Composition | Selected patterns and any rejected alternatives |
+| Evidence | Failure trace, expected result, runtime, actual result |
+
+### Worked Brief: Editing A Display Name
+
+| Value | Owner | Lifetime | Write rule |
+| --- | --- | --- | --- |
+| Acknowledged name and revision | Server; cache holds observation | Account session | Matching authoritative response |
+| Draft name | Settings form | Until discard, accepted save, or guarded departure | User edit |
+| Dirty | Derived | Same as form | Compare draft to acknowledged baseline |
+| Submitted name and request ID | Save operation | One attempt | Capture before starting effect |
+| Pending destination | Router guard | Confirmation decision | Latest attempted destination |
+
+Invariant: acknowledging A never marks later draft B saved. Failure trace: edit A → submit → edit B → acknowledge A. Expected result: A is the baseline; B remains visible and dirty. Rejected alternative: binding fields directly to the cache loses a reliable Cancel target.
+
+### Implementation Handoff
+
+```yaml
+domain: design-engineering
+state_patterns: [draft-and-baseline, submitted-snapshot, unsaved-navigation]
+state_owner: settings form and save operation
+persistence_owner: consumer backend
+consumer_reference: not_applicable
+consumer_reference_reason: This blank planning example selects no consumer profile or conformance record.
+observed_results: not_run
+remaining_evidence: consumer runtime, request traces, keyboard and focus recovery
+```
+
+## Opinionated Guidance
+
+An unresolved owner is an implementation question, not a reason to introduce more booleans. Write product choices such as discard policy explicitly; do not hide them inside effects.
+
+## Platform-Specific Guidance
+
+Include router, cache, framework, and persistence adapter versions only in the consumer handoff where they affect behavior. Check IME input and native form submission for editable fields.
+
+## Unsupported Absolutes
+
+Completing this template does not establish executed evidence or backend persistence. A request token alone cannot resolve concurrent server edits.
+
+## Verification Contract
+
+A second reader should identify every write owner and execute the failure trace without inventing policy. Record normal, failed, interrupted, and identity-changing cases before implementation.
+
+## Source, License, And Attribution
+
+Locally authored synthesis and examples. No upstream implementation is copied. These experimental contracts describe consumer-owned behavior; review when a failure, ownership change, or platform change invalidates an assumption.
+
+## IA Navigation
+
+Parent: [State Management](index.md).
+Next: [Continue the state management route](verification.md).

package/design-engineering/state-management/verification.md

@@ -0,0 +1,65 @@
+---
+type: Domain Guide
+title: State Management Verification Matrix
+description: Test event ordering, failure recovery, navigation, and identity boundaries separately from UI presentation.
+domain: design-engineering
+lifecycle: experimental
+provenance_kind: local
+---
+
+# State Management Verification Matrix
+
+## Repository Boundary
+
+This matrix verifies consumer behavior under Design Engineering. Shared [quality gates](../../quality/index.md) own evidence admissibility. Passing a local model does not promote a domain or certify a consumer.
+
+## Reusable Method
+
+Start with the selected pattern's invariant. Use controlled promises or an injected transport to choose completion order. Assert both displayed state and effect count or persistence payload; a screenshot alone cannot show which snapshot was saved.
+
+| Dimension | Required stress when applicable | Observable |
+| --- | --- | --- |
+| Ordering | Start A/B; resolve B/A; stale error after new success | Current result, status, and error remain correlated |
+| Mutation | Edit during save; normalized result; version conflict | Draft, baseline, submitted payload, revision |
+| Duplication | Keyboard + pointer + another caller | Declared count and outcome sharing |
+| Failure | Definitive rejection versus unknown write outcome | Draft retained; reconciliation before unsafe retry |
+| Lifetime | Dispose; A → B → A; logout | No old-generation updates or scope leakage |
+| Navigation | Back, Forward, reload, deep link, canceled departure | URL, visible controls, draft, and selection agree |
+| Persistence | Corrupt version, wrong scope, unavailable storage, delayed restore | Valid defaults and preserved newer edits |
+| Accessibility | Pending, error, empty, removed invoker | Announcements and logical focus recovery |
+| Composition | Filter while deleting; edit during save-and-leave | Combined invariants survive interleaving |
+
+### Executable Local Coverage
+
+From a repository checkout, `npm run test:state-management` extracts and executes the standalone `js` block from each of the 12 pattern pages in an isolated Node process. The examples assert model outcomes for ownership, projections, selection, drafts, save snapshots, navigation decisions, stale completions, duplicate effects, optimistic recovery, URL parsing, identity generations, and restore validation.
+
+The four recipes declare integration acceptance sequences; they are not runnable browser fixtures. Existing [Interaction Lab](../../examples/domain-interactions/README.md) is a separate prototype with its own evidence scope. New recipe acceptance remains unexecuted until adapted to a consumer.
+
+### Evidence Record
+
+Record source revision, runtime, selected pattern/recipe, initial state, event sequence, submitted payload/effect count, expected state, actual state, and remaining limitations. Label unrun cases `not_run`; separate a model assertion from a browser observation and a server acknowledgement.
+
+## Opinionated Guidance
+
+Use deterministic event ordering instead of sleeps. Test the stale failure path as well as stale success, and inspect cleanup/finally paths that can accidentally clear a newer pending operation.
+
+## Platform-Specific Guidance
+
+Run browser navigation, focus, assistive-technology announcements, and storage failure checks in the actual target environment. Node URL and reducer examples cannot certify those integrations.
+
+## Unsupported Absolutes
+
+A green model suite does not prove race freedom under every interleaving, real persistence, or accessibility. Synthetic transports do not establish server idempotency.
+
+## Verification Contract
+
+For every consumer claim, identify a matching executed case or explicitly list missing evidence. Revisit the matrix when a real failure is not representable by its dimensions.
+
+## Source, License, And Attribution
+
+Locally authored synthesis and examples. No upstream implementation is copied. These experimental contracts describe consumer-owned behavior; review when a failure, ownership change, or platform change invalidates an assumption.
+
+## IA Navigation
+
+Parent: [State Management](index.md).
+Next: [Continue the state management route](recipes/index.md).

package/design-engineering/text-input-and-internationalization.md

@@ -0,0 +1,91 @@
+---
+type: Domain Guide
+title: Text Input And Internationalization
+description: Design composition-aware editing, explicit text units, bidirectional content, and locale-bound presentation without corrupting user input.
+domain: design-engineering
+lifecycle: experimental
+provenance_kind: local
+reviewed_on: 2026-09-21
+---
+
+# Text Input And Internationalization
+
+Primary role: multilingual text interaction and verification guide.
+
+## Repository Boundary
+
+This guide owns text editing and product-data decisions. Layout owns spatial constraints; a translation or input method does not authorize copying product typography into reusable Layout CSS. Browser text measurement is not proof that an editor preserves user intent.
+
+## Reusable Method
+
+Declare three contracts before implementing formatting: what the user can edit, what the application stores, and what it displays. Name the unit of any limit or selection offset. Then inventory composition, paste, autofill, correction, undo, direction, and locale changes. An event sequence from one Latin keyboard is a narrow sample.
+
+### Source Findings
+
+| Source | Bounded finding | Design consequence |
+| --- | --- | --- |
+| [UI Events](https://www.w3.org/TR/uievents/#events-compositionevents) | Composition has its own event lifecycle; `isComposing` identifies events within a composition session. | Do not treat every intermediate edit as a committed command. |
+| [Input Events Level 2](https://www.w3.org/TR/input-events-2/) | Input types describe edit intentions. The draft distinguishes cancelability during IME composition. | Inspect actual events; a universal keydown filter cannot govern every edit path. |
+| [Unicode Text Segmentation, UAX #29](https://www.unicode.org/reports/tr29/) | Grapheme clusters approximate user-perceived characters; boundaries are distinct from code points and words. | State whether a limit counts bytes, code units, code points, or grapheme clusters. |
+| [ECMA-402 Segmenter](https://tc39.es/ecma402/#segmenter-objects) | `Intl.Segmenter` exposes locale-sensitive segmentation at named granularities. | Name locale and granularity when using segmentation in a UI. |
+| [W3C bidirectional markup guidance](https://www.w3.org/International/questions/qa-html-dir) | HTML direction metadata and isolation help mixed-direction content retain its intended ordering. | Treat document direction and inserted user text separately. |
+| [Accessible Authentication explanation](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum.html) | WCAG 2.2's AA criterion limits required cognitive-function tests, with specified alternatives and assistance. | Do not casually remove paste or password-manager assistance from an authentication flow. |
+
+Sources were inspected 2026-09-21. UI/Input Events and ECMA-402 publication states must be read as labeled; a draft API description is not a claim that every target implements it identically. UAX #29 has versioned rules, so record the Unicode/runtime boundary for a reproducible segmentation claim.
+
+### Worked Scenario: Korean Search With Suggestions
+
+The user enters a Korean name, navigates candidates, commits composition, and then submits a search. Product state distinguishes the editable text, composition status, selected suggestion identity, and submitted query.
+
+Local policy: preserve the browser's in-progress composition. Do not move focus, replace the input node, run destructive formatting, or submit the form merely because a command key arrived during composition. Commit-driven search is a product choice; live preview during composition needs a separate decision and stale-result policy.
+
+| Event or condition | Proposed responsibility | Failure it prevents |
+| --- | --- | --- |
+| Composition starts | Keep the editing node and draft stable. | Rerendering discards the input method's active composition. |
+| Intermediate input | Retain the edit without treating a candidate as the submitted query. | A provisional syllable becomes an unintended request or selection. |
+| Candidate confirmation | Let the input method complete its edit before interpreting a separate application command. | Enter both confirms composition and submits unexpectedly. |
+| Suggestions return out of order | Match them to current query intent. | An old response replaces suggestions for the current text. |
+| User presses Escape | Resolve input-method, popup, and outer-surface ownership deliberately. | One key cancels composition, closes the popup, and closes the editor. |
+
+The exact native event order is a target observation, not prescribed here. Test the real IME in each supported browser/OS; synthetic composition events do not recreate the operating system's input method. Use [latest request wins](state-management/patterns/latest-request-wins.md) for replaceable reads.
+
+### Text Units And Limits
+
+For a visible “characters remaining” count, decide what users should perceive as one unit, then compare that policy with the backend limit. A grapheme count cannot guarantee that a byte-limited service accepts the value. Show the relevant limit rather than truncating silently after submission.
+
+Use a corpus containing Hangul composition, a base letter plus combining mark, emoji sequences, an empty value, pasted line breaks, and a long unbroken identifier. Verify counters, truncation, deletion, selection restoration, and round trips. A correct count with corrupted cursor placement is still an editing failure.
+
+Formatting belongs at a declared boundary. If a field needs grouping separators, preserve an editable representation and caret policy. A localized display string is not automatically a canonical stored number or date. Decide how incomplete input, ambiguous separators, and locale changes are resolved before adding automatic reformatting.
+
+### Direction And Mixed Content
+
+Set the document's language and base direction intentionally. Isolate inserted names, identifiers, and other independently directed text where needed; test punctuation and adjacent controls as well as the text itself. CSS alignment alone cannot establish the semantic direction of user data.
+
+Product tests should include an RTL name beside an LTR identifier, paired punctuation, numerals, and a trailing action. Preserve logical reading order while the Layout owner chooses logical spacing and containment.
+
+## Opinionated Guidance
+
+Preserve raw editing intent until a clear commit boundary. Prefer a reversible validation message over eager rewriting that the user cannot undo. Store stable identity separately from the localized label of a suggestion.
+
+## Platform-Specific Guidance
+
+Keyboard layouts, IMEs, dictation, autofill, and virtual keyboards can take different event paths. Record OS, browser, input method, locale, and assistive technology instead of a generic “mobile tested.” For typography and scaling, use [Preferences And Accessibility](../platform-guides/preferences-and-accessibility.md).
+
+## Unsupported Absolutes
+
+One code point is not necessarily one perceived character. A keypress is not the only way to edit text. A segmentation API is not a locale-aware parser. Programmatically dispatched events are not evidence that a native IME works.
+
+## Verification Contract
+
+The proposed cases cover real composition, candidate selection, paste, undo/redo, replacement selection, autofill, server rejection, mixed direction, and locale change with an unfinished draft. Bind observed input and submitted data to the same scenario; independently inspect the accepted backend value where that claim matters.
+
+Record both intended and observed event/selection outcomes, without storing private user input in diagnostic artifacts. The examples above are test data proposals; no IME, browser, or backend execution is claimed. Re-review after editor, formatter, runtime, or locale-policy changes.
+
+## Source, License, And Attribution
+
+Locally authored synthesis of the linked primary sources, inspected 2026-09-21. No upstream examples are reproduced. `consumer_reference: not_applicable` because no consumer editor record is selected.
+
+## IA Navigation
+
+Parent: [Design Engineering](index.md).
+Next: [Loading And Feedback](loading-and-feedback.md).

package/design-engineering/worked-examples.md

@@ -0,0 +1,129 @@
+---
+type: Domain Guide
+title: Design Engineering Worked Examples
+description: Apply component contracts to settings, asynchronous search, and destructive list actions with explicit recovery cases.
+domain: design-engineering
+lifecycle: experimental
+provenance_kind: local
+---
+
+# Design Engineering Worked Examples
+
+Primary role: product interaction recipe collection.
+
+## Repository Boundary
+
+These fictional examples connect decisions to expected behavior. They are neither shipped components nor captured product evidence. Values and presentation belong to the consumer; the referenced Layout recipes retain their spatial boundaries.
+
+The separate [Interaction Lab](../examples/domain-interactions/README.md) implements the save and search contracts as a local web prototype. Its [browser observations](../examples/domain-interactions/verification.md) apply to that exact example and source snapshot; they do not prove a consumer backend or the destructive-action recipe below.
+
+## Reusable Method
+
+Choose a matching user task, adapt its state ownership through the [Component Contract](component-contract.md), and execute the listed failure cases in the consuming application. The decision is incomplete until expected and actual results are recorded separately.
+
+The [State Management recipes](state-management/recipes/index.md) expand these tasks into explicit pattern stacks and substitution rules, including a multi-step form. These existing scenarios remain at their original anchors.
+
+## Settings With Explicit Save
+
+Task: edit preferences, inspect changes, and save intentionally. Compose the [SaaS Settings recipe](../recipes/saas-settings.md); let its selected patterns own page structure and scrolling. The form owns the editable draft, the operation owns the submitted snapshot, and persistence determines success.
+
+Keep field errors beside their inputs and provide a route to the first relevant error. On network failure, retain all entered values. A successful save of an older snapshot must leave subsequent edits dirty. If leaving the screen can lose changes, define discard/cancel/save behavior and what happens if saving fails.
+
+| Test | Expected behavior |
+| --- | --- |
+| Submit missing required input | Expose the error and retain other values |
+| Submit, edit again, then receive success | Confirm the submitted snapshot; preserve later edits |
+| Fail and retry | Keep the draft; issue the retry under the declared request policy |
+| Cancel navigation with dirty data | Stay on the form with the same draft and a usable focus target |
+
+Evidence still needed: keyboard/error announcement, persistence responses, and source-bound runtime capture. A prototype cannot prove real data was saved.
+
+## Search With Detail Selection
+
+Task: search a collection and inspect an item without losing the search context. Compose [List Detail](../recipes/list-detail.md). Separate query text, submitted query, active request, results, and selected item identity. Displayed detail must name the selected item even when the result set refreshes.
+
+Keep typing responsive; a request for an older query cannot replace a newer result. Distinguish “no results” from loading and failure. On a tight surface, preserve selection and query when navigating between list and detail. If the selected item disappears, choose a documented empty detail or next-item policy instead of silently showing stale data.
+
+| Test | Expected behavior |
+| --- | --- |
+| Submit A, then B; resolve B before A | Results remain for B after A arrives |
+| Receive zero results | Show the submitted query and a recovery action |
+| Resize with detail selected | Preserve selection and query; keep focus on a logical available target |
+| Remove the selected item remotely | Explain its unavailability or choose the documented next target |
+
+Evidence still needed: out-of-order response trace, selection identity, tight/wide rendered states, and input coverage. Motion is optional; use [Reorder and Filter](../motion/interaction-recipes.md#reorder-and-filter) only when it communicates stable identity.
+
+## Destructive Action In A List
+
+Task: remove a selected item with understandable consequences. Separate the initiating control, decision surface, pending operation, and final list update. Choose confirmation or undo from actual reversibility and product requirements. Do not offer undo when the backend cannot restore the item.
+
+Name the affected item and scope. During pending deletion, prevent unintended duplicate operations according to the contract. Failure preserves the item and a recovery path. On success, return focus to an appropriate neighboring item or list heading if the invoker was removed. A dialog's visual exit must not leave a blocker behind.
+
+| Test | Expected behavior |
+| --- | --- |
+| Cancel confirmation | No deletion; return to the invoker |
+| Fail the operation | Explain failure and preserve the item |
+| Succeed while filters change | Remove by stable identity, not old row position |
+| Remove the final item | Present an empty state and a logical focus destination |
+
+Evidence still needed: actual operation result, focus trace, dialog semantics, and recovery behavior. Use [Modal Transition](../motion/interaction-recipes.md#modal-transition) only for optional presentation.
+
+## Implementation Handoff
+
+```yaml
+example: # settings-save, search-detail, or destructive-list-action
+consumer_reference: not_applicable
+consumer_reference_reason: These fictional examples select no consumer-owned profile or evidence record.
+layout_source: # the selected recipe and the consumer's pinned revision
+state_owner: # component, screen, and persistence responsibilities
+acceptance_cases: # adapted rows above
+observed_results: not_run
+remaining_evidence: # actual runtime, input, device, and user evidence
+```
+
+## Product Story And Media Handoff
+
+Start with an observation sheet for a product homepage: section job, reading order, scene boundaries, changing objects, media crop, and source-confidence level. Record an unknown rendering mechanism as unknown; cinematic appearance alone does not establish video, Canvas, WebGL, or a library.
+
+| Decision | Product-owned record | Verification |
+| --- | --- | --- |
+| Typography and rhythm | Heading measure, copy length, spacing, contrast and image ratio | Real copy, text growth, narrow windows |
+| Scene composition | Subject identity, crop and focal point, transparent layers, background transitions | First/middle/last and transition frames |
+| Media export | Dimensions, frame order, codec/format, alpha, poster, source/license | Decode readiness and failed asset |
+| Runtime budget | Download bytes, decoded-memory estimate, cache and concurrency limits | Slow requests, repeated reversal, idle work |
+| Static equivalent | Every essential message in semantic HTML, explicit reading mode | No script, reduced motion, keyboard access |
+
+Use the [Motion scene contract](../motion/interaction-recipes.md#scene-composition-contract) and compare the [Flow and headphones examples](../examples/scroll-story/README.md). Their shared controller demonstrates content substitution; both are related local examples and establish no independent adopter evidence. Their different typography, colors, and assets remain product choices.
+
+Complete one representative scene before producing an entire video or image sequence. Review its composition and transition framing, then export at the target dimensions. A polished poster does not validate the intervening frames. This section is locally authored practice guidance, not adapted external visual expression.
+
+### Persistent Subject And Page Navigation
+
+The Flow story keeps one device shell mounted while its screen content and pose change with progress. The [Scene Navigation example](../examples/scene-navigation/README.md) carries that same identity principle into a page whose chapter selection changes while document position stays fixed. Background, text, device pose, and screen layers share one state owner. These are local product treatments, not profile values or reusable Layout CSS.
+
+For this page type, add an input map and URL/history contract to the visual handoff. Specify which surface owns wheel/swipe, which copy regions retain native scrolling, how a focused outgoing action is recovered, and how the user reaches ordinary reading. Review intermediate frames as well as the endpoints; semantic availability must not depend on a visual completion callback.
+
+## Opinionated Guidance
+
+Preserve the user's work across recoverable failures. Status text should explain the real operation; motion and color alone are insufficient descriptions of what happened.
+
+## Platform-Specific Guidance
+
+Native navigation, browser history, component libraries, and platform controls differ. Record the exact implementation of cancellation and focus return rather than copying a screenshot's apparent behavior.
+
+## Unsupported Absolutes
+
+Confirmation is not always safer than undo. Optimistic updates are not always appropriate. A worked example does not certify a consumer migration or establish universal usability.
+
+## Verification Contract
+
+Execute all adapted acceptance rows plus long text, empty content, relevant constraints and preferences, and every claimed input method. For a migration use the larger [Migration Readiness](consumer-migration-readiness.md) contract. Review these examples when an observed failure lacks an owner or recovery action.
+
+## Source, License, And Attribution
+
+Locally authored scenarios and expected-result tables. Repository links provide spatial and evidence contracts, not proof that these scenarios have run.
+
+## IA Navigation
+
+Parent: [Design Engineering](index.md).
+Next: [Interface Craft Decisions](interface-craft.md).