sinapse-ai 9.2.0 → 9.3.0

package/squads/squad-design/knowledge-base/designops-maturity.md

@@ -0,0 +1,312 @@
+# Knowledge Base: DesignOps & Maturity Model
+
+## Escopo
+DesignOps como disciplina — modelos de time, maturity model (5 niveis), metricas de adocao, ROI, living documentation e governance. Fonte: MS-002 Design System Research (2026-04-07).
+
+---
+
+## 1. DesignOps como Disciplina
+
+**Dave Malouf** cunhou o termo "DesignOps" (2014) para descrever as praticas, processos e infraestrutura que permitem ao design escalar em uma organizacao. Assim como DevOps elimina atritos entre desenvolvimento e operacoes, DesignOps elimina atritos entre design e o resto da organizacao.
+
+### Dominios do DesignOps
+| Dominio | O que inclui |
+|---------|-------------|
+| **People** | Hiring, onboarding, career growth, team structure |
+| **Workflow** | Processos de design, ferramentas, handoffs, ritmo |
+| **Craft** | Design systems, quality standards, design principles |
+| **Impact** | Metricas, ROI, business alignment, advocacy |
+
+---
+
+## 2. InVision Design Maturity Model (5 Niveis)
+
+| Level | Nome | Caracteristicas |
+|-------|------|----------------|
+| **1** | **Ad Hoc** | Sem sistema. Componentes criados individualmente. Inconsistencia total. Design e siloed. |
+| **2** | **Emerging** | Style guide basico. Algumas convencoes. Adocao inconsistente. Primeiros tokens aparecem. |
+| **3** | **Defined** | Design system formal. Tokens, componentes, documentacao. Time dedicado ou parcial. Storybook ativo. |
+| **4** | **Managed** | Sistema maduro. Metricas de adocao. Governance claro. Contribuicao federada. RFC process ativo. |
+| **5** | **Optimized** | Sistema como produto. Inovacao continua. Benchmark para a industria. Design e infraestrutura. |
+
+### Onde a Industria esta (2024-2026)
+- **Maioria das organizacoes:** Level 2-3
+- **Organizacoes lider** (Google, IBM, Salesforce, Shopify, GitHub): Level 4-5
+- **Startups (0-50 pessoas):** Level 1-2 (normal — premature abstraction e um risco real)
+
+### Sinais de cada nivel
+
+**Level 2 → 3 (quando investir em DS):**
+- 3+ times de produto trabalhando em paralelo
+- Inconsistencias visuais frequentes entre telas
+- Tempo significativo gasto em refactor visual
+- Designers recriando os mesmos componentes
+
+**Level 3 → 4 (quando formalizar governance):**
+- Times ignorando o DS ou criando paralelos
+- Bottleneck no time central para aprovar componentes
+- Adocao estagnada em 50-60% das telas
+- Requests de componentes sem processo claro
+
+**Level 4 → 5 (DS como produto maduro):**
+- Metricas de adocao monitoradas continuamente
+- Contribuicoes regulares de times de produto
+- Roadmap publico com features planejadas
+- NPS > 50 entre times consumidores
+
+---
+
+## 3. Team Models
+
+### Modelo Centralizado (Dedicated Team)
+**Estrutura:** 3-8 pessoas: 1-2 designers, 2-4 engenheiros, 1 PM/DesignOps
+**Times de produto sao consumidoras**
+
+| Vantagem | Desvantagem |
+|----------|-------------|
+| Consistencia maxima | Bottleneck (gargalo) |
+| Qualidade alta e consistente | Lento para atender demandas |
+| Ownership clara | Desconexao com necessidades reais |
+
+**Exemplos:** Salesforce (Lightning), IBM (Carbon), Microsoft (Fluent)
+**Quando usar:** Organizacoes 500+ pessoas, multiplos produtos
+
+### Modelo Federado (Community-Driven)
+**Estrutura:** Sem time dedicado. Board de representantes de cada time.
+
+| Vantagem | Desvantagem |
+|----------|-------------|
+| Rapido — times criam o que precisam | Risco de inconsistencia |
+| Alto engajamento | Precisa de processos rigorosos |
+| Sistema evolui com produto | Overhead de coordenacao |
+
+**Quando usar:** Startups ou organizacoes onde time dedicado nao e viavel
+
+### Modelo Hibrido (Hub + Spokes) — Padrao 2024-2026
+**Estrutura:** Time central pequeno (2-4 pessoas) mantem core + governance. Times contribuem via RFC.
+
+**Exemplos:** Shopify (Polaris), GitHub (Primer), Atlassian
+**Quando usar:** Organizacoes 50-500 pessoas, modelo mais comum e recomendado
+
+---
+
+## 4. Design System como Produto (Dan Mall)
+
+**Dan Mall**, autor de "Design That Scales" (2022), articula a licao mais importante: tratar o design system como um **produto**, nao como um projeto.
+
+| Projeto | Produto |
+|---------|---------|
+| Tem inicio, meio e fim | Evolui continuamente |
+| Orcamento define o escopo | Feedback dos usuarios define o roadmap |
+| "Pronto" quando entregue | Nunca "pronto" |
+| Sem metricas de sucesso | KPIs e NPS monitorados |
+| Time desband ao final | Time permanente com ownership |
+
+### Praticas de Product Management para DS
+
+```yaml
+Roadmap publico:
+  - O que esta em desenvolvimento (Q1/Q2)
+  - O que esta planejado (Q3/Q4)
+  - O que e backlog
+
+Changelog detalhado:
+  - O que mudou em cada versao
+  - Por que mudou
+  - Como migrar (codemod quando possivel)
+
+Office hours:
+  - Sessoes semanais para duvidas e feedback
+  - Abertas para todos os times
+
+Analytics de uso:
+  - Quais componentes sao mais usados
+  - Quais tem mais issues abertas
+  - Quais tem menor adocao (candidatos a deprecacao)
+
+Deprecation notices:
+  - Anunciado com 2 minor releases de antecedencia
+  - Codemod fornecido quando possivel
+  - Migration guide documentado
+```
+
+---
+
+## 5. Metricas de Adocao
+
+### Dashboard de Adocao
+| Metrica | Como medir | Target |
+|---------|-----------|--------|
+| Coverage | % de telas usando componentes do sistema | > 80% |
+| Adoption rate | % de times usando o sistema | > 90% |
+| Token compliance | % de valores visuais via tokens (vs hardcoded) | > 95% |
+| Component reuse | # de instancias por componente | > 10 (media) |
+| Contribution rate | # de PRs de equipes de produto / mes | 2-5 |
+| Satisfaction (NPS) | Survey trimestral | > 50 |
+| Time to implement | Tempo medio para nova tela | Reducao > 40% |
+| Design-dev parity | % com equivalente Figma + codigo | > 90% |
+
+### Ferramentas de Medicao
+- **Omlet** (YC-backed): Analisa codebase automaticamente e gera dashboard de adocao por componente
+- **Figma Analytics:** Quais componentes Figma sao mais duplicados/usados
+- **Custom ESLint:** Regras que detectam uso de elementos HTML nativos (button, input) em vez de componentes do DS
+
+---
+
+## 6. ROI Calculation
+
+### Formula Simplificada
+```
+ROI = ((Horas economizadas × Custo/hora) - Investimento) / Investimento
+
+Horas economizadas = (Tempo sem DS - Tempo com DS) × Numero de features
+```
+
+### Benchmark Industria (Sparkbox 2023)
+- Reducao media de **34%** no tempo de desenvolvimento
+- Reducao de **29%** em bugs visuais
+- **89%** reportam melhoria em consistencia
+- **72%** reportam melhoria em velocidade
+
+### Cases
+| Empresa | DS | Impacto |
+|---------|-----|---------|
+| Salesforce | Lightning Design System | $2B+ economizados anualmente em produtividade |
+| Shopify | Polaris | -50% no tempo de construcao de novas telas |
+| IBM | Carbon | Reducao significativa em QA de acessibilidade |
+
+---
+
+## 7. Living Documentation
+
+### Principios
+1. **Colocalizada com o codigo** — story/doc no mesmo diretorio que o componente
+2. **Automaticamente extraida** — TypeScript types geram prop tables sem esforco manual
+3. **Interativa** — leitor pode mudar props e ver resultado em tempo real
+4. **Contextualizada** — quando usar, quando nao usar, alternativas
+5. **Versionada** — versionada junto com o codigo
+
+### Plataformas de Documentacao
+
+**Storybook (open-source, pelos criadores do Chromatic):**
+- Renderiza componentes em isolamento
+- MDX para documentacao rica
+- Addons: a11y, viewport, controls, actions, docs
+- Visual regression via Chromatic
+- v10 (Out 2025): ESM-only, -29% install size
+
+**Zeroheight (SaaS):** Conecta Figma, Storybook e codigo. Designers contribuem sem tocar codigo.
+
+**Supernova (SaaS):** Sincroniza com Figma automaticamente, gera docs. Multi-brand, design tokens.
+
+**Knapsack (SaaS):** Multi-framework (React, Vue, Angular, Web Components) na mesma documentacao.
+
+### Storybook MDX Example
+```mdx
+{/* Button.mdx */}
+import { Meta, Canvas, Controls } from '@storybook/blocks';
+import * as ButtonStories from './Button.stories';
+
+<Meta of={ButtonStories} />
+
+# Button
+Buttons trigger actions. Use for form submissions, confirmations, interactive processes.
+
+## When to use
+- **Primary:** Main action (max 1 per view)
+- **Secondary:** Supporting actions
+- **Ghost:** Low-emphasis (cancel, dismiss)
+
+## When NOT to use
+- Navigation → use `<Link>` instead
+- Toggling → use `<Toggle>` instead
+
+<Canvas of={ButtonStories.Primary} />
+<Controls />
+```
+
+---
+
+## 8. Versioning Strategy (SemVer)
+
+```
+MAJOR.MINOR.PATCH
+
+MAJOR: Breaking changes (rename prop, remove component, change behavior)
+MINOR: New features backward-compatible (add prop, add component)
+PATCH: Bug fixes, performance improvements
+```
+
+### Breaking Change Management
+```
+1. Deprecation first: @deprecated com mensagem clara + no console
+2. Codemods: Scripts jscodeshift para migracao automatica
+3. Migration guide: Documentar exatamente o que mudar
+4. Grace period: 2 minor releases com deprecated ativo
+5. Removal: Proximo major release
+```
+
+```typescript
+interface ButtonProps {
+  variant?: 'primary' | 'secondary';
+  /** @deprecated Use `variant` instead. Will be removed in v5.0 */
+  type?: 'primary' | 'secondary';
+}
+```
+
+---
+
+## 9. Contribution Checklist
+
+Para um componente entrar no design system, ele deve:
+
+```
+Tecnico:
+- [ ] TypeScript com tipos completos (sem `any`)
+- [ ] forwardRef implementado
+- [ ] displayName definido
+- [ ] className merge com cn()
+- [ ] Default props sensatos
+
+Acessibilidade:
+- [ ] Elementos ARIA corretos (role, aria-*)
+- [ ] Keyboard navigation funcionando
+- [ ] Focus indicator visivel (WCAG 2.4.7)
+- [ ] Testado com axe-core (zero violations)
+- [ ] Testado com teclado manualmente
+
+Visual:
+- [ ] Funciona em light mode e dark mode
+- [ ] Funciona em todos os breakpoints
+- [ ] Tokens usados para todos os valores visuais (sem hardcoded)
+
+Estados:
+- [ ] Default, hover, active, focus, disabled
+- [ ] Loading (quando aplicavel)
+- [ ] Error (quando aplicavel)
+- [ ] Empty (quando aplicavel)
+
+Documentacao:
+- [ ] Storybook stories para cada variante e estado
+- [ ] MDX com when to use / when not to use
+- [ ] API reference completa
+
+Testes:
+- [ ] Unit tests (render, props, events)
+- [ ] a11y test (jest-axe)
+- [ ] Visual regression (Chromatic baseline)
+
+Tokens:
+- [ ] Component tokens criados (L3)
+- [ ] Tokens referenciam semantic layer (L2)
+```
+
+---
+
+## Referencias
+- Dave Malouf — DesignOps (2014)
+- Dan Mall — "Design That Scales" (2022)
+- InVision Design Maturity Model
+- Sparkbox Design Systems Survey 2023
+- Nathan Curtis — Design System Operations (EightShapes)
+- MS-002 Design System Research — SINAPSE (2026-04-07)

package/squads/squad-design/knowledge-base/famous-design-systems-study.md

@@ -0,0 +1,291 @@
+# Knowledge Base: Famous Design Systems Study
+
+## Escopo
+Analise profunda dos 10 design systems mais influentes da industria — historia, diferenciais, licoes aprendidas e comparacao arquitetural. Fonte: MS-002 Design System Research (2026-04-07).
+
+---
+
+## 1. Material Design (Google)
+
+**Lancamento:** 2014 (M1), 2018 (M2), 2021 (Material 3 / Material You)
+**URL:** material.io
+
+Criado por **Matias Duarte** (VP of Design, Google), Material Design e o design system mais influente da historia. Introduziu conceitos que se tornaram industria: superficies com elevacao, motion com significado, tipografia como sistema, color harmony algoritmica.
+
+### Material 3 (Material You — 2021)
+- **Dynamic Color:** Gera paleta inteira a partir de uma cor (papel de parede do celular)
+- **OKLCH-based color system:** Cores perceptualmente uniformes
+- **Expressividade:** Mais personalidade que M2 (border-radius variavel, color themes)
+- **W3C DTCG:** Tokens publicados em formato W3C DTCG
+
+### Licoes
+- Rigor sistematico (documentacao exaustiva de cada decisao)
+- Motion guidelines com principios teoricos (fisica de materiais)
+- Accessibility-first (todos os componentes testados com screen readers)
+- Token architecture que suporta customizacao profunda
+
+### Implementacoes
+- Material Web Components (web)
+- Jetpack Compose Material 3 (Android)
+- Flutter Material 3
+
+---
+
+## 2. Carbon Design System (IBM)
+
+**Lancamento:** 2017 (open-source)
+**URL:** carbondesignsystem.com
+
+Design system da IBM para centenas de produtos enterprise. Foco em: data visualization, complex forms, dashboards, acessibilidade AA/AAA (exigida por contratos federais).
+
+### Diferenciais
+- **Grid sofisticado:** 2x Grid (column grid + mini unit grid de 8px)
+- **Data visualization system:** Charting guidelines completas (paleta de cores para graficos, tipos de viz)
+- **Accessibility como P0:** IBM Federal contracts exigem Section 508 + WCAG AAA
+- **Multi-framework:** React, Angular, Vue, Svelte, Web Components
+- **Design tokens:** Publicados e documentados com 3 tiers
+
+### Licoes
+- Enterprise UX patterns (navigation para produtos complexos)
+- Data visualization como componente do design system
+- Multi-framework strategy com Web Components como base
+- Accessibility rigor que vai alem do minimo (AAA em componentes criticos)
+
+---
+
+## 3. Polaris (Shopify)
+
+**Lancamento:** 2017 (open-source)
+**URL:** polaris.shopify.com
+
+Design system do Shopify para 2+ milhoes de comerciantes e milhares de desenvolvedores. Foco em commerce UX e admin interfaces.
+
+### Diferenciais
+- **Design principles memoraveis:** "Put merchants first", "Be familiar, be clear", "Be consistent"
+- **Token-driven (pioneiro):** Polaris foi um dos primeiros DS a adotar design tokens na pratica
+- **RFC process publico:** Qualquer pessoa pode abrir uma RFC no GitHub
+- **UX Patterns extensivos:** Nao apenas componentes, mas *como usa-los* em contextos especificos
+
+### Contribution Model
+```
+Issue → RFC → Design Review → Implementation → Documentation → Release
+```
+RFC publicas sao comentadas pela comunidade antes de aprovadas. Isso garante que components resolvem problemas reais.
+
+### Licoes
+- Principles-driven design (os principios guiam todas as decisoes)
+- Contribution model aberto e transparente
+- Commerce UX patterns (pagamento, inventario, relatorios)
+- Documentacao de "quando usar" e "quando nao usar" para cada componente
+
+---
+
+## 4. Primer (GitHub)
+
+**Lancamento:** 2016 (open-source)
+**URL:** primer.style
+
+Design system do GitHub. React-based, usa Radix primitives, profundamente integrado com a cultura open-source.
+
+### Diferenciais
+- **React components + acessibilidade:** Todos os componentes sobre Radix UI primitives
+- **Primer CSS:** CSS utility framework proprio (precursor do Tailwind no GitHub)
+- **ViewComponents:** Componentes Ruby on Rails server-side (design system multi-layer)
+- **Brand system:** Octicons (icon set), illustrations system, marketing components
+- **Dark mode:** Cidadao de primeira classe — GitHub tem dark mode desde 2020
+
+### Licoes
+- Developer-centric design (design para quem usa ferramentas de dev)
+- Dark mode architecture (tokens separados para light/dark/dimmed/high-contrast)
+- Open-source governance (o design system *e* open-source e aceita PRs da comunidade)
+- Icon system como produto separado (Octicons tem sua propria versioning e docs)
+
+---
+
+## 5. Atlassian Design System
+
+**Lancamento:** 2018 (evolucao do ADG — Atlassian Design Guidelines)
+**URL:** atlassian.design
+
+Sistema maduro para produtos enterprise: Jira, Confluence, Trello, Bitbucket.
+
+### Diferenciais
+- **Atlassian Design Tokens:** Plataforma propria com 3-tier token system
+- **Emotion-based styling** com theme provider sofisticado
+- **Pattern library extensiva:** Navigation, onboarding, empty states, error states
+- **Pragmatismo:** Foco em "good enough at scale" — nao perfeicao
+
+### Licoes
+- Enterprise patterns (onboarding para produtos complexos, empty states)
+- Scaling governance: como manter consistencia com dezenas de times e 4 produtos grandes
+- Pragmatic approach (nem sempre o design mais bonito — o que funciona para milhoes de usuarios)
+
+---
+
+## 6. Lightning Design System (Salesforce)
+
+**Lancamento:** 2015 (open-source — pioneiro)
+**URL:** lightningdesignsystem.com
+
+Um dos primeiros design systems enterprise publicados. Criado com forte influencia de **Jina Anne** (que cunhou "design tokens").
+
+### Diferenciais
+- **Pioneiro em design tokens (2014):** Jina Anne criou o conceito durante o desenvolvimento do SLDS
+- **Lightning Web Components (LWC):** Web Components como tecnologia base
+- **Blueprints extensivos:** Patterns documentados em detalhe com exemplos HTML
+- **Section 508:** Acessibilidade exigida por contratos governamentais nos EUA
+
+### Licoes
+- Design tokens como single source of truth (o conceito nasceu aqui)
+- Enterprise patterns para CRM (formularios complexos, tabelas, dashboards)
+- Accessibility compliance para regulatorio (Section 508, ADA)
+- Web Components como estrategia de longo prazo para cross-framework
+
+---
+
+## 7. Spectrum (Adobe)
+
+**Lancamento:** 2019 (open-source)
+**URL:** spectrum.adobe.com
+
+Design system da Adobe, construido sobre React Aria (hooks de acessibilidade) e React Spectrum (componentes estilizados).
+
+### Arquitetura Unica (3 Camadas)
+```
+React Aria        ← Behavior + Accessibility (ARIA, keyboard, focus)
+React Stately     ← State management (controlled/uncontrolled, selection)
+React Spectrum    ← Visual (tokens, theming, CSS)
+```
+
+Cada camada e separada e pode ser usada independentemente.
+
+### Diferenciais
+- **React Aria:** A melhor biblioteca de acessibilidade da industria — resolve problemas que ninguem mais resolveu (date pickers, color pickers, comboboxes acessiveis)
+- **Cross-platform:** Web + iOS via React Native
+- **Internationalization nativa:** RTL, number formatting, date formatting, locale-aware sorting
+- **Adaptive:** UI adapta para mouse, touch e keyboard naturalmente
+
+### Licoes
+- Layered architecture (behavior/state/visual separation permite maxima flexibilidade)
+- Accessibility-first como arquitetura (nao como addon)
+- i18n como cidadao de primeira classe
+- Hooks como API publica de comportamento
+
+---
+
+## 8. Fluent (Microsoft)
+
+**Lancamento:** 2017 (Fluent Design System), 2022 (Fluent 2)
+**URL:** fluent2.microsoft.design
+
+Design system da Microsoft para Windows, Office, Teams, Azure. Foco em produtividade enterprise e cross-platform.
+
+### Diferenciais
+- **Fluent UI React:** 18K+ stars, usado em produtos Microsoft com bilhoes de usuarios
+- **Griffel:** CSS-in-JS engine com zero runtime usando atomic CSS (semelhante ao Stylex)
+- **Themes nativos:** Light, Dark, High Contrast (Windows accessibility feature)
+- **Cross-platform:** Web, Windows (WinUI 3), iOS, Android
+
+### Licoes
+- Enterprise scale (bilhoes de usuarios impoe constraints diferentes)
+- High-contrast accessibility (Windows High Contrast Mode e feature nativa — DS deve suportar)
+- CSS atomic optimization (Griffel gera CSS atomico, minimizando bundle)
+- Cross-platform design language sem abandonar convencoes de cada plataforma
+
+---
+
+## 9. Human Interface Guidelines (Apple)
+
+**Lancamento:** 1987 (Mac original), evoluido continuamente
+**URL:** developer.apple.com/design
+
+As HIG sao o design system mais antigo em uso continuo. Nao sao open-source mas a documentacao e extremamente detalhada.
+
+### Diferenciais
+- **Platform-native:** Nunca tenta ser cross-platform — cada plataforma tem sua propria HIG
+- **SF Symbols:** 5000+ icones com 9 weights, 3 scales, variable color — sistema de icones mais sofisticado da industria
+- **Haptics guidelines:** Toque como canal de feedback (design para sensacao fisica)
+- **Spatial computing (visionOS):** Apple Vision Pro como nova fronteira do design system
+
+### Licoes
+- Platform-native design (nao tentar criar uma unica UI para todos os contextos)
+- Attention to detail (cada guideline e baseada em research extenso)
+- Haptics como dimensao de UX (vibration patterns como parte do design language)
+- Design for delight (nao apenas usabilidade — encantamento)
+
+---
+
+## 10. Geist (Vercel)
+
+**Lancamento:** 2023 (open-source)
+**URL:** vercel.com/geist
+
+O design system mais recente e moderno desta lista. Criado pela Vercel (empresa por tras do Next.js), reflete a estetica minimalist-developer.
+
+### Diferenciais
+- **Geist Font:** Fonte propria (Geist Sans + Geist Mono) — tipografia como identidade de marca
+- **Minimalismo extremo:** Poucos componentes, muito bem feitos
+- **Dark-first:** Design para dark mode como primaria, light como variacao
+- **Tailwind-native:** Tokens como classes Tailwind, nao CSS separado
+- **shadcn/ui influence:** Copy-paste philosophy
+
+### Licoes
+- Modern minimalism (menos e mais — curadoria rigorosa de componentes)
+- Developer-first UX (design para quem usa ferramentas de dev)
+- Font como brand identity (criar uma fonte propria como estrategia de diferenciacao)
+- Dark-first design (invertendo o default)
+
+---
+
+## Comparacao Arquitetural
+
+| Design System | Token Format | CSS Approach | Framework | Open Source | Componentes |
+|--------------|-------------|-------------|-----------|-------------|-------------|
+| Material Design | W3C DTCG | CSS custom properties | Multi (Web, Flutter, Android) | Sim | 50+ |
+| Carbon (IBM) | Custom JSON | Sass + CSS vars | Multi (React, Vue, Angular, Svelte) | Sim | 80+ |
+| Polaris (Shopify) | Custom JSON | CSS Modules | React | Sim | 60+ |
+| Primer (GitHub) | JSON | Styled Components + CSS | React | Sim | 60+ |
+| Atlassian DS | Custom | Emotion | React | Parcial | 70+ |
+| Lightning (Salesforce) | Custom (pioneiro) | BEM CSS | LWC (Web Components) | Sim | 100+ |
+| Spectrum (Adobe) | Custom | CSS Modules | React (+ React Aria) | Sim | 70+ |
+| Fluent (Microsoft) | Custom | Griffel (atomic) | React | Sim | 80+ |
+| HIG (Apple) | N/A | SwiftUI/UIKit | Native (iOS/macOS) | Nao | N/A |
+| Geist (Vercel) | Tailwind | Tailwind CSS | React | Sim | 30+ |
+
+---
+
+## The Component Gallery
+
+**componentgallery.design** — Catalogo de como os mesmos componentes (Button, Input, Modal) sao implementados em 60+ design systems. Recurso essencial para benchmarking e padronizacao de nomenclatura.
+
+Exemplo: o componente "Popover" e chamado de "Popover" em Radix, "Overlay" em Spectrum, "Popup" em MUI, e "Floating" em Floating UI. Ver como diferentes sistemas resolvem o mesmo problema e invaluavel para decisoes de API design.
+
+---
+
+## Licoes Universais
+
+| Licao | Fonte | Aplicacao |
+|-------|-------|-----------|
+| Tokens como single source of truth | Jina Anne (Salesforce, 2014) | Token-driven development — sem valores hardcoded |
+| Design system como produto, nao projeto | Dan Mall | Roadmap, metricas, versioning, changelog |
+| Acessibilidade como arquitetura | Adobe Spectrum | React Aria como camada separada |
+| Governance define velocidade | Shopify Polaris | RFC process antes de implementar |
+| Documentacao viva | Storybook ecosystem | Docs colocalizedas com codigo |
+| Tokens fluem de baixo para cima | Nathan Curtis | L1 → L2 → L3, nunca ao contrario |
+| Motion e fundacao, nao feature | Material Design | Motion tokens como parte das foundations |
+
+---
+
+## Referencias
+- material.io/design
+- carbondesignsystem.com
+- polaris.shopify.com
+- primer.style
+- atlassian.design
+- lightningdesignsystem.com
+- spectrum.adobe.com
+- fluent2.microsoft.design
+- developer.apple.com/design
+- vercel.com/geist
+- componentgallery.design
+- MS-002 Design System Research — SINAPSE (2026-04-07)