Let Designer implement visual-only web UI changes #138

Closed
opened 2026-07-30 09:43:35 +00:00 by coilyco-ops · 1 comment
Member

Outcome

Amend the canonical Designer role so she may implement, locally validate, and land changes whose only product effect is visual presentation in an existing graphical web application.

React and comparable browser UI surfaces are the intended case. This is a narrow exception to the handoff-only boundary established by #85, not general repository implementation authority.

Canonical role-skill shape: #121.

Problem

The current Designer charter says:

You own the experience definition, not repository, deployment, or verification execution.

That correctly keeps Designer out of product logic and infrastructure, but it is too broad when the approved experience change and the implementation are the same visual adjustment. Handing a pure layout, styling, or presentation patch to Engineer adds translation without adding useful ownership.

“Visual” must remain an effect boundary, not a synonym for anything a person can see and not a file-extension allowlist.

Boundary test

A Designer implementation qualifies only when reverting the patch would change presentation while leaving all non-visual behavior and generated system output unchanged.

The file type does not decide the scope:

  • A React or TSX change may qualify when it only rearranges presentational markup or consumes existing props and state.
  • A CSS change does not qualify when it changes interaction availability, product rules, or behavior.
  • A visual result produced by simulation, procedural generation, or game logic does not qualify.

When a requested change mixes visual presentation with behavior, Designer may isolate and land the visual-only slice. Otherwise she stops at a buildable handoff to Engineer.

Included work

  • Layout, spacing, typography, color, iconography, static assets, and design tokens
  • Responsive presentation within existing behavior
  • Presentational component composition using existing data, props, and state
  • Non-behavioral motion and transitions
  • Visual fixture, Storybook, screenshot, and visual-regression updates that directly verify the intended presentation
  • Repository-prescribed formatting, type checking, local UI checks, commit, and delivery through the already resolved workflow

Excluded work

  • Terminal, CLI, or TUI presentation, including the launch gate in #137
  • Game implementation, factory simulation, galaxy generation, world generation, or procedural visual systems
  • Event handling, navigation, routing, forms, validation, keyboard behavior, or interaction-state logic
  • Data models, state flow, persistence, APIs, networking, authentication, permissions, or analytics
  • Accessibility semantics or behavior beyond preserving the existing contract
  • Dependencies, build systems, deployment, release behavior, or live verification
  • Product copy changes whose meaning changes, rather than purely visual treatment

A role skill still grants no commands, credentials, mounts, network access, model selection, or executable permission. The runtime and repository workflow remain authoritative.

Proposed charter behavior

Designer owns experience definition everywhere. In an existing graphical web UI, Designer may also implement and land a change when its complete product effect is visual presentation. She locally verifies that visual slice and follows the repository’s established delivery workflow.

When the work changes behavior, semantics, data, generated systems, terminal experiences, games, infrastructure, or deployment, Designer produces the experience definition and hands implementation to Engineer.

Acceptance criteria

  • The canonical Designer role skill contains the visual-only web implementation exception.
  • Generated and compiled role surfaces render the same boundary without hand-edited copies.
  • The charter uses an effect-based test rather than a file-extension or framework allowlist.
  • A representative React layout or styling task leads Designer to implement, validate, and deliver the change.
  • A React task that changes state or event handling leads Designer to isolate the visual slice or hand off implementation.
  • A terminal UI task leads Designer to specify the experience and hand implementation to Engineer.
  • A factory-game, simulation, galaxy-generation, or procedural-visual task does not activate the exception.
  • Tests preserve the distinction between behavioral doctrine and executable authority.
  • The Designer evaluation pack is refreshed with at least one allowed case and two denied boundary cases.
  • Repository validation passes through the declared Ward verbs and the change lands on canonical main.

Relationship to #137

#137 remains an Engineer implementation. Its visible output is a terminal launch interaction, which this exception explicitly excludes.

## Outcome Amend the canonical Designer role so she may implement, locally validate, and land changes whose only product effect is visual presentation in an existing graphical web application. React and comparable browser UI surfaces are the intended case. This is a narrow exception to the handoff-only boundary established by #85, not general repository implementation authority. Canonical role-skill shape: #121. ## Problem The current Designer charter says: > You own the experience definition, not repository, deployment, or verification execution. That correctly keeps Designer out of product logic and infrastructure, but it is too broad when the approved experience change and the implementation are the same visual adjustment. Handing a pure layout, styling, or presentation patch to Engineer adds translation without adding useful ownership. “Visual” must remain an effect boundary, not a synonym for anything a person can see and not a file-extension allowlist. ## Boundary test A Designer implementation qualifies only when reverting the patch would change presentation while leaving all non-visual behavior and generated system output unchanged. The file type does not decide the scope: * A React or TSX change may qualify when it only rearranges presentational markup or consumes existing props and state. * A CSS change does not qualify when it changes interaction availability, product rules, or behavior. * A visual result produced by simulation, procedural generation, or game logic does not qualify. When a requested change mixes visual presentation with behavior, Designer may isolate and land the visual-only slice. Otherwise she stops at a buildable handoff to Engineer. ## Included work * Layout, spacing, typography, color, iconography, static assets, and design tokens * Responsive presentation within existing behavior * Presentational component composition using existing data, props, and state * Non-behavioral motion and transitions * Visual fixture, Storybook, screenshot, and visual-regression updates that directly verify the intended presentation * Repository-prescribed formatting, type checking, local UI checks, commit, and delivery through the already resolved workflow ## Excluded work * Terminal, CLI, or TUI presentation, including the launch gate in #137 * Game implementation, factory simulation, galaxy generation, world generation, or procedural visual systems * Event handling, navigation, routing, forms, validation, keyboard behavior, or interaction-state logic * Data models, state flow, persistence, APIs, networking, authentication, permissions, or analytics * Accessibility semantics or behavior beyond preserving the existing contract * Dependencies, build systems, deployment, release behavior, or live verification * Product copy changes whose meaning changes, rather than purely visual treatment A role skill still grants no commands, credentials, mounts, network access, model selection, or executable permission. The runtime and repository workflow remain authoritative. ## Proposed charter behavior Designer owns experience definition everywhere. In an existing graphical web UI, Designer may also implement and land a change when its complete product effect is visual presentation. She locally verifies that visual slice and follows the repository’s established delivery workflow. When the work changes behavior, semantics, data, generated systems, terminal experiences, games, infrastructure, or deployment, Designer produces the experience definition and hands implementation to Engineer. ## Acceptance criteria * [ ] The canonical Designer role skill contains the visual-only web implementation exception. * [ ] Generated and compiled role surfaces render the same boundary without hand-edited copies. * [ ] The charter uses an effect-based test rather than a file-extension or framework allowlist. * [ ] A representative React layout or styling task leads Designer to implement, validate, and deliver the change. * [ ] A React task that changes state or event handling leads Designer to isolate the visual slice or hand off implementation. * [ ] A terminal UI task leads Designer to specify the experience and hand implementation to Engineer. * [ ] A factory-game, simulation, galaxy-generation, or procedural-visual task does not activate the exception. * [ ] Tests preserve the distinction between behavioral doctrine and executable authority. * [ ] The Designer evaluation pack is refreshed with at least one allowed case and two denied boundary cases. * [ ] Repository validation passes through the declared Ward verbs and the change lands on canonical `main`. ## Relationship to #137 #137 remains an Engineer implementation. Its visible output is a terminal launch interaction, which this exception explicitly excludes.
Author
Member

Engineer checkpoint caed7d4 is pushed on issue-138-designer-visual-web. It adds the canonical effect-based visual-only web exception, native and compiled delivery proof, explicit behavioral, terminal, and procedural-game denials, authority-boundary tests, docs, and a Designer evaluation prompt covering one allowed case plus three denied cases. ward exec pre-commit and ward exec smoke pass. ward exec test stops only because evaluations/latest/designer-codex.yaml is correctly bound to the prior pack digest. Independent QA must generate fresh serial frontier and OSS responses from exact revision caed7d4, score every rubric criterion, and return the v2 Designer result. The branch is intentionally not landed and #138 remains open until that evidence validates.

Engineer checkpoint caed7d4 is pushed on issue-138-designer-visual-web. It adds the canonical effect-based visual-only web exception, native and compiled delivery proof, explicit behavioral, terminal, and procedural-game denials, authority-boundary tests, docs, and a Designer evaluation prompt covering one allowed case plus three denied cases. ward exec pre-commit and ward exec smoke pass. ward exec test stops only because evaluations/latest/designer-codex.yaml is correctly bound to the prior pack digest. Independent QA must generate fresh serial frontier and OSS responses from exact revision caed7d4, score every rubric criterion, and return the v2 Designer result. The branch is intentionally not landed and #138 remains open until that evidence validates.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
coilyco-flight-deck/agent-compose#138
No description provided.