--- name: "playbook-prototype-config-panel" type: playbook description: 'The prescribed response when a design decision turns on feel — interaction and motion values such as durations, easings and offsets — that a static ticket, a comment or a screenshot cannot carry: deliver a live configuration panel on the prototype, with named presets to walk the client through curated options and full manual control over every value, so the client dials it until it feels right and the chosen values are the spec. Read and follow it whenever a verify or feedback ticket asks for a change of feel (snappier, calmer, less floaty), before routing a value guess to a build, and when scoping any A1 interactive prototype that carries motion tokens. Dev-only overlay, never in the public build. Surfaced by APP-794; a Pixel capability skill is extracted only once the panel has been built twice.' license: CC BY-NC-SA 4.0 --- # Prototype config panel — refining feel by direct manipulation The prescribed response to a recurring scenario: a decision that turns on **feel**. Motion feel — snap versus floaty, the weight of a panel move, how a flip lands — is subjective and only legible in motion, so it cannot be settled through the comment → ticket → build → verify loop. Three of the Jul-17 Meirion verify tickets turned on a feel judgement a static ticket could not carry, and A1-298 sat mis-scoped for weeks because nobody could cheaply re-check the feel. The playbook collapses that loop: the client dials the values live until it feels right, and the values they chose *are* the specification (APP-794; direction affirmed by the Owner 2026-08-11, form ruled 2026-09-03). Read and followed, not run. Composes `convention-ticket`, `skill-design-tokens`, `skill-design-review-round` and `skill-product-design`; it does not restate their rules. ## When to use - A review comment or verify ticket asks for a change of *feel* — "snappier", "calmer", "less floaty", "lands too hard" — rather than a change of value or layout. - A refinement round (`skill-design-review-round`) triages a row as *needs discussion* because it turns on motion or interaction feel. - An A1 interactive prototype is being scoped and it carries motion tokens at all — plan the panel in from the start rather than retrofitting it at the first feel comment. Not for a value the client has already stated, or a layout or colour decision — those are ordinary tickets. ## The prototype the panel sits on The panel is an overlay, and the prototype around it is built to one of two bars (Owner ruling 2026-10-07, D105 in `log.meirion-decisions.2026-W41`). Settle which before building the panel: the bar decides what the client can usefully react to. - **Isolated configuration.** One interaction, one component or section, configured on its own. It matches the latest design of that component and shows nothing else — no nav, no surrounding chrome. Normally the right kind here, because a feel decision turns on one motion. - **Full site.** For crossover interactions and tests that need navigating around, such as page transitions. It is exactly like `main`, so it carries the whole build; use it only where the interaction needs it. Both bars exist so the client gives feedback only on what is required, and not on UI or interactions that are not up for consideration or are correct on the build and wrong on the prototype. How each kind receives its designs, the shared shell and the `/prototypes` index are designed under A1-628; this playbook fixes only which bar applies. ## The sequence ### 1. Confirm the values are tokens The panel binds to tokens, so the prototype must hold its interaction and motion values as named tokens first — durations, easings, offsets, delays (`--panel-dur`, `--preview-dur`, `--flip-dur`, the easings, on the Meirion prototype; A1-289 sourced the durations from them). Where a value is hardcoded in the prototype, tokenise it before building the panel; that is `skill-design-tokens`' work and is a prerequisite leaf, not something the panel step absorbs. ### 2. Build the panel — two modes, one overlay - **Presets.** A small curated set the client is walked through — "Prototype default", "Snappy", "Calm" and the like, each a complete named set of values. The presets are the conversation: real options to react to rather than a blank slider. - **Full control.** Every token editable live — duration and easing per motion, offsets where they exist — with the current set readable and exportable (copy as the token block), so the agreed values port straight back as token values with no re-derivation and no bounce. - **Dev-only overlay.** Gated behind a query flag or a build-time switch; never present in the public build. State the gate in the ticket's definition of done and check it at review. ### 3. Run the session The client (or the Owner) uses the prototype with the panel: presets first, then free adjustment on the one that is closest. Record the chosen set — the exported token block — on the review-round document row or the ticket, with the date and who chose it. Where two people disagree, record both sets and route the choice to the Owner; do not average them. ### 4. Port the values back The chosen token block becomes the token values — a normal build leaf against the prototype or the production code, with the block verbatim in its acceptance criteria. The panel stays in the prototype for the next round; nothing is rebuilt. ## Open questions travelling with this draft Two "how" calls the Owner left open on 2026-09-03; each is answered by the second build, not by this draft. - **Where the panel lives** — baked into each prototype, or a reusable harness shared across A1 prototypes. First instance: baked in. If the second prototype wants the same panel, extract the harness then. - **Who curates the presets** — Pixel proposes the option set; the Owner confirms it before the client session. Revisit if a client wants to author their own. ## Graduation This playbook is the prescribed response; it is not yet a repeatable procedure. A Pixel capability skill (`skill-prototype-config-panel` or similar) is extracted only once the panel has been **built twice** and the shared steps are visible (Owner ruling 2026-09-03). Until then, each build follows this sequence and records what differed. ## First application A1-298 — the Meirion modifier-motion refinement (Figma comment #54, "panel move feel: snap into place, reduce floatiness"), re-scoped to the modifiers and parked in Refinement against this playbook. Expose `--preview-dur`, `--flip-dur` and the preview easing, and let Meirion pick snap versus calm directly. ## Guardrails - **Never guess a feel value into a build.** A feel comment that reaches a builder as a number was routed wrongly; send it here. - **Never ship the panel.** Dev-only, gated, checked at review. - **The chosen values are the spec** — ported verbatim, not re-interpreted. - **Compose, don't duplicate.** Token work is `skill-design-tokens`'; the round document is `skill-design-review-round`'s; the ticket shape is `convention-ticket`'s. ## Tone Calm, precise, sentence case, British spelling, no exclamation marks, outcome before adjective. (cos.tov.)