# MORPH UI/UX Design - FASE 1.5

Fase obrigatória para features com front-end. Coleta requisitos de UI/UX, gera wireframes, specs de componentes e fluxos de usuário.

## Uso

```
/morph-uiux {feature-name}
```

## Pré-requisitos

- [ ] FASE 1 (Setup) concluída
- [ ] Feature tem keywords de UI detectadas (blazor, ui, component, page, dashboard, wizard, form, chart)
- [ ] `uiux-designer` agent ativado

## Workflow

### Passo 1: Detectar Se Fase É Necessária

Verifique se agentes ativos incluem `uiux-designer`:

```bash
node bin/state-manager.js get {feature-name}
```

Se `uiux-designer` NÃO estiver nos `activeAgents`, pule esta fase e vá para `/morph-design`.

### Passo 2: Coletar Input do Usuário

**SEMPRE perguntar ao usuário PRIMEIRO:**

1. **Layout e estilo**:
   - Você tem alguma ideia de layout em mente?
   - Tem alguma referência visual? (sites, apps, screenshots)
   - Como imagina o fluxo do usuário?

2. **Componentes e interações**:
   - Quais os principais componentes desta tela/página?
   - Quais estados precisam ser considerados? (loading, error, empty, success)

3. **Imagens de referência**:
   - Tem imagens de exemplo que eu possa analisar?
   - Se SIM: use Read tool para ler screenshots e extrair padrões

### Passo 3: Decidir Biblioteca UI

Escolha entre **Fluent UI Blazor** (recomendado para AI-first) ou **MudBlazor** (componentes complexos):

**Critérios:**
- Fluent UI: Para dashboards, forms simples, AI components, Microsoft design language
- MudBlazor: Para data grids avançadas, charts complexos, material design

**Documente a decisão:**
```bash
# Adicionar ADR em decisions.md
echo "## ADR: UI Library Choice

Decision: [Fluent UI / MudBlazor]

Rationale:
- {Justificativa baseada nos requisitos}

Date: $(date +%Y-%m-%d)" >> .morph/project/outputs/{feature}/decisions.md
```

### Passo 4: Gerar Deliverables

Crie os seguintes arquivos em `.morph/project/outputs/{feature}/`:

#### 4.1. `ui-design-system.md`

Design system com:
- Paleta de cores (primary, secondary, accent, semantic)
- Tipografia (heading scales, body text, code)
- Spacing e layout (grid, margins, paddings)
- Componentes base (buttons, inputs, cards)

#### 4.2. `ui-mockups.md`

Wireframes ASCII + descrições:
- Layout geral de cada tela/página
- Posicionamento de componentes
- Responsividade (desktop, tablet, mobile)
- Estados (loading, error, empty, success)

Exemplo:
```
┌─────────────────────────────────────────┐
│  Header                   [🔔] [👤]     │
├─────────────────────────────────────────┤
│ ┌─────────┐                             │
│ │ Sidebar │  Main Content Area          │
│ │  Menu   │  ┌─────────────────────┐   │
│ │         │  │ Dashboard Card      │   │
│ │ • Home  │  │ - Chart            │   │
│ │ • Data  │  │ - Metrics          │   │
│ └─────────┘  └─────────────────────┘   │
└─────────────────────────────────────────┘
```

#### 4.3. `ui-components.md`

Specs técnicas de componentes Fluent UI/MudBlazor:
- Componente a usar (FluentButton, MudDataGrid, etc.)
- Props e configurações
- Eventos e bindings
- Validações e estados

Exemplo:
```markdown
### DashboardCard Component

**Library:** FluentCard
**Props:**
- Title: string
- Subtitle: string (optional)
- Loading: bool

**Events:**
- OnRefresh: EventCallback

**Variants:**
- Default (outline)
- Filled (accent color)
- Error (danger color)
```

#### 4.4. `ui-flows.md`

Fluxos de usuário completos:
- User stories
- Diagramas de fluxo (texto/ASCII)
- Edge cases (o que acontece se...?)
- Validações e feedback

Exemplo:
```
## Fluxo: Adicionar Item

1. User clica "Adicionar Item"
2. Modal abre com form
   - Loading: Skeleton placeholders
   - Error: Toast notification
3. User preenche campos
   - Validação em tempo real
   - Campos required marcados com *
4. User clica "Salvar"
   - Success: Modal fecha + toast "Item adicionado"
   - Error: Modal permanece + mensagem de erro destacada
```

### Passo 5: Validar Acessibilidade e Responsividade

Documente nos arquivos UI:
- **WCAG 2.1 Level AA** compliance
  - Contraste de cores adequado
  - Labels acessíveis para screen readers
  - Navegação por teclado
- **Responsive breakpoints**
  - Desktop (>1200px)
  - Tablet (768px - 1199px)
  - Mobile (<768px)

### Passo 6: Atualizar State

```bash
# Marcar fase como uiux-design
node bin/state-manager.js set {feature-name} phase uiux-design

# Marcar outputs criados
node bin/state-manager.js mark-output {feature-name} ui-design-system
node bin/state-manager.js mark-output {feature-name} ui-mockups
node bin/state-manager.js mark-output {feature-name} ui-components
node bin/state-manager.js mark-output {feature-name} ui-flows
```

## Outputs Gerados

- `.morph/project/outputs/{feature}/ui-design-system.md`
- `.morph/project/outputs/{feature}/ui-mockups.md`
- `.morph/project/outputs/{feature}/ui-components.md`
- `.morph/project/outputs/{feature}/ui-flows.md`
- `.morph/project/outputs/{feature}/decisions.md` (atualizado com ADR UI library)

## ⛔ PAUSA OBRIGATÓRIA

Apresente ao usuário 3 ações sugeridas:

1. ✅ **Aprovar UI/UX e prosseguir para design técnico**
   Continuar para `/morph-design` (FASE 2)

2. 🎨 **Ajustar wireframes/componentes de telas específicas**
   Revisar mockups ou adicionar mais detalhes

3. 🔄 **Revisar biblioteca UI escolhida (Fluent UI ↔ MudBlazor)**
   Mudar decisão se justificado

## Critérios de Avanço

- [x] Input do usuário coletado (layout, referências)
- [x] Biblioteca UI escolhida e justificada (ADR)
- [x] 4 deliverables criados (design-system, mockups, components, flows)
- [x] Acessibilidade WCAG 2.1 documentada
- [x] Responsividade especificada
- [x] State atualizado
- [x] Usuário aprovou UI/UX

---

**Feature:** $ARGUMENTS
