# Lane B: Design Execution Guidance

Lane B feeds `start-work` workers and always loads `frontend` for UI implementation. It does not install a separate builder. Its job is to carry designpowers composition, interaction, motion, content, responsive, adaptive, token, and cognitive-accessibility guidance into worker prompts while keeps ownership of decomposition, implementation, QA, evidence, and ledger updates.

## Phase Owner

| Capability | Materialized designpowers source | owner | Mapping |
|---|---|---|---|
| Visual hierarchy, layout, color, typography, touch targets, and WCAG contrast | `ui-composition` | `start-work` worker plus `frontend` | Add visual constraints and acceptance checks to worker assignments. `frontend` remains the required UI implementation skill. |
| States, feedback, loading, error, keyboard, touch, and recovery behavior | `interaction-design` | `start-work` worker plus `frontend` | Require every interactive component to define default, hover, focus, active, disabled, loading, success, and error states where applicable. |
| Purposeful motion and reduced-motion alternatives | `motion-choreography` | `start-work` worker plus `frontend` | Require motion specs to explain what changed, what to look at next, or how elements relate; require safe alternatives. |
| Content-driven breakpoints and zoom behavior | `responsive-patterns` | `start-work` worker plus `frontend` | Require responsive proof at narrow, mid, desktop, and 200 percent zoom scenarios when the surface is visual. |
| User preference adaptation | `adaptive-interfaces` | `start-work` worker plus `frontend` | Require support for relevant preferences such as color scheme, contrast, reduced motion, text sizing, and density. |
| Mental load, wayfinding, focus management, memory demands, and recovery paths | `cognitive-accessibility` | `start-work` worker plus `frontend` | Add COGA-style checks directly to worker acceptance criteria for flows, forms, navigation, and dense tools. |
| Plain-language labels, headings, alt text, link text, errors, and instructions | `accessible-content` and `voice-and-tone` | `start-work` worker plus `frontend` | Require final copy, no placeholders, useful errors, readable labels, and consistent tone. |
| Tokens and design-system consistency | `token-architecture` and `design-system-alignment` | `frontend` | Require real design tokens and existing component patterns before new one-off styling. |

Materialized agent references for this lane: `design-lead`, `motion-designer`, and `content-writer`. They are prompt-role references for spawned OpenAgent work, not alternate executors.

## Prompt Injection

Add this block to each `start-work` implementation worker that touches UI:

```text
Load `frontend` for UI implementation. Also apply Lane B Design Execution Guidance.

Use the OpenAgent plan and `.omo/frontend-design/state.md` as source of truth. Carry forward:
- design principles, personas, taste direction, and accepted trade-offs
- ui-composition requirements for hierarchy, spacing, type, color, contrast, and touch targets
- interaction-design requirements for all states, feedback, keyboard, touch, loading, empty, and error paths
- motion-choreography requirements for purposeful motion and reduced-motion alternatives
- responsive-patterns requirements for content-driven breakpoints and 200 percent zoom
- adaptive-interfaces requirements for relevant user preferences
- cognitive-accessibility requirements for mental load, wayfinding, focus, memory, and recovery
- accessible-content and voice-and-tone requirements for labels, headings, alt text, link text, and errors
- token-architecture and design-system-alignment requirements for reusable tokens and existing components

Do not invent visual direction that conflicts with the plan. If the plan lacks a design decision that affects users, return BLOCKED with the exact missing owner decision.
```

## Evidence Requirements

Lane B worker DoneClaims must include:

- Exact changed files and the `frontend` references loaded.
- The real-surface QA invocation required by `start-work` for the UI surface, with captured artifact path.
- Screenshot, browser, HTTP, or xterm.js web-terminal artifacts appropriate to the visible surface.
- Accessibility evidence from the existing OpenAgent frontend path, such as Lighthouse, react-doctor, keyboard checks, or other plan-required checks.
- A short design trace: which persona, design principle, token, or state requirement each major UI decision satisfies.
- Cleanup receipts for any browser session, server, tmux session, temporary artifact, or process used during QA.

## Guardrails

- UI implementation always goes through `frontend`; Lane B only enriches the worker prompt.
- `start-work` owns decomposition, worker dispatch, evidence ledger entries, adversarial checks, and completion state.
- The materialized `design-builder` concept is not used as an available executor. OpenAgent workers build.
- No placeholders, generic copy, unverified contrast claims, decorative-only motion, or one-off hardcoded design systems pass this lane.
- Accessibility and cognitive-accessibility are implementation constraints, not review-only cleanup.
- Direct or auto mode language is prompt-only and cannot create new automation.

## Pass / Fail Behavior

PASS when every UI worker loads `frontend`, implements against the OpenAgent plan plus Lane B constraints, and returns evidence showing the design works through the actual surface.

FAIL when a worker skips `frontend`, invents unplanned design direction, omits cognitive-accessibility checks for complex flows, ships placeholder content, leaves required states undesigned, or claims success without captured real-surface evidence.