sinapse-ai 9.2.0 → 9.3.0

package/squads/squad-cybersecurity/knowledge-base/zero-trust-architecture.md

@@ -0,0 +1,225 @@
+# Zero Trust Architecture Reference
+
+## Purpose
+
+Reference for implementing Zero Trust Architecture (ZTA) based on NIST SP 800-207 and NIST SP 800-207A (2025). Used by Wire (network-security-engineer) and Nimbus (cloud-security-engineer) for architecture decisions and hardening recommendations.
+
+---
+
+## Foundational Document: NIST SP 800-207
+
+Published August 2020. The definitive US government standard for Zero Trust. In June 2025, NIST published SP 800-207A with 19 concrete architecture examples using commercial technologies.
+
+**Core premise:** "Never trust, always verify" — no machine, user, or service is implicitly trusted, even inside the corporate network. Contrasts with the traditional "castle and moat" model where passing the firewall grants broad internal access.
+
+---
+
+## The 7 Zero Trust Tenets (NIST SP 800-207)
+
+1. **All data sources and computing services are resources** — applies to personal devices, IoT, cloud services
+2. **All communication is secured regardless of network location** — no "trusted internal network"
+3. **Access to resources is granted per-session** — no persistent access grants
+4. **Access is determined by dynamic policy** — identity, device health, posture, behavioral context
+5. **Enterprise monitors and measures integrity of all assets** — continuous validation
+6. **Authentication and authorization are dynamic and strictly enforced before access** — re-verify as context changes
+7. **Enterprise collects information about assets and uses it to improve security posture** — telemetry-driven
+
+---
+
+## Zero Trust vs. Traditional Perimeter Security
+
+| Aspect | Traditional (Castle & Moat) | Zero Trust |
+|--------|----------------------------|------------|
+| Trust model | Trust everything inside the network | Trust nothing by default |
+| Network location | Inside = trusted | Location is irrelevant |
+| Access control | VPN grants broad access | Per-resource, per-session access |
+| Lateral movement | Easy — flat internal network | Difficult — microsegmentation |
+| Identity | Static roles, rarely reviewed | Continuous verification with context |
+| Devices | Corporate-managed = trusted | Device posture checked every session |
+| Detection | Perimeter-focused | Assume breach, detect everywhere |
+
+---
+
+## The Three Pillars of Zero Trust
+
+### Pillar 1: Identity
+
+Every entity (user, service, device) must have a verified identity. Identity is the new perimeter.
+
+**Identity controls:**
+- Multi-Factor Authentication (MFA) — mandatory for all users, especially privileged access
+- Conditional Access — access depends on user risk score, device compliance, location
+- Privileged Identity Management (PIM) — just-in-time (JIT) access elevation for admins
+- Service-to-service identity — machine identities via SPIFFE/SPIRE or cloud IAM roles
+- Identity governance — regular access reviews, separation of duties
+
+**Commercial identity providers (NIST SP 800-207A examples):**
+- Microsoft Entra ID (formerly Azure AD) — enterprise standard, integrates with most SaaS
+- Okta — multi-cloud identity platform
+- Google Cloud Identity — strong for GCP-native environments
+- HashiCorp Vault — service-to-service identity and secrets management
+
+### Pillar 2: Devices
+
+Device health and compliance as a factor in access decisions.
+
+**Device controls:**
+- Device compliance enforcement — OS version, patches, security software required
+- Endpoint Detection and Response (EDR) — CrowdStrike, SentinelOne, Microsoft Defender
+- Mobile Device Management (MDM) for BYOD — Intune, Jamf
+- Device certificates — cryptographic device identity bound to hardware
+- Continuous posture assessment — device health re-checked during session
+
+### Pillar 3: Microsegmentation
+
+Replace flat networks with fine-grained, software-defined segments where each workload can only communicate with exactly what it needs.
+
+**Network controls:**
+- Software-defined perimeter (SDP) — replace VPN with encrypted, identity-authenticated tunnels
+- Microsegmentation — Illumio, Guardicore, Zscaler, Cilium (Kubernetes)
+- Service mesh mTLS — Istio, Linkerd enforce mutual TLS between services
+- Network policy — Kubernetes NetworkPolicy, AWS Security Groups, GCP Firewall Rules
+- DNS filtering — block malicious domains at the resolver layer
+
+---
+
+## Zero Trust Implementation Roadmap (NIST 5-Phase Approach)
+
+NIST recommends gradual adoption over big-bang deployment:
+
+### Phase 1: Asset Discovery
+- Complete inventory of all assets (hardware, software, data, services)
+- Map all communication flows — who talks to whom
+- Identify crown jewel assets — data and systems requiring highest protection
+- Assess current identity and access management maturity
+
+### Phase 2: Define Trust Zones
+- Group assets by sensitivity and function
+- Define which communication flows are allowed between zones
+- Identify implicit trust relationships that need to be eliminated
+- Document current network topology against desired Zero Trust model
+
+### Phase 3: Policy Modeling
+- Define access policies for each resource (who, what, when, from where, on what device)
+- Model policies using least-privilege principle
+- Define conditional access rules (location, device health, risk score thresholds)
+- Validate policies don't break legitimate workflows
+
+### Phase 4: Pilot Small Environment
+- Select a contained environment (one application, one team)
+- Deploy identity enforcement, device compliance, and microsegmentation for pilot scope
+- Measure impact on productivity and security
+- Iterate on policy before broader rollout
+
+### Phase 5: Monitor, Adjust, and Expand
+- Deploy monitoring and telemetry across the pilot
+- Tune policies based on observed access patterns
+- Expand to next scope incrementally
+- Maintain continuous improvement cycle
+
+---
+
+## Practical Implementation: Cloud-Native Zero Trust
+
+### AWS Zero Trust Pattern
+
+```
+IAM Identity Center (SSO) → Conditional Access → Resources
+    ↑                              ↑
+Device Compliance              VPC Endpoint
+(AWS Verified Access)          (no internet exposure)
+```
+
+**Key AWS services:**
+- **AWS IAM Identity Center** — centralized SSO across all AWS accounts
+- **AWS Verified Access** — application-level zero trust without VPN
+- **VPC Endpoints** — private connectivity to AWS services without internet traversal
+- **AWS PrivateLink** — service mesh private communication
+- **Service Control Policies (SCPs)** — organization-wide guardrails
+- **IMDSv2** — prevent SSRF from accessing EC2 metadata (mandatory)
+
+### Kubernetes Zero Trust Pattern
+
+```
+SPIFFE/SPIRE (workload identity)
+    → Istio/Linkerd mTLS (service mesh)
+    → Network Policies (microsegmentation)
+    → RBAC + OPA/Gatekeeper (authorization)
+    → Falco (runtime detection)
+```
+
+**Key Kubernetes controls:**
+- **RBAC** — role-based access for every service account, no cluster-admin in production
+- **Pod Security Standards** — enforce restricted pod configurations (no privileged containers)
+- **Network Policies** — deny-all default, explicit allow rules per namespace
+- **User namespaces** — isolate container UIDs from host (beta, on by default in K8s 1.32+)
+- **mTLS via service mesh** — Istio or Linkerd for automatic mutual TLS between pods
+- **Admission control** — Kyverno or OPA/Gatekeeper for policy enforcement
+
+### Identity-First Access for SaaS Apps
+
+For organizations using Supabase, the zero trust pattern at the application layer:
+
+```sql
+-- Row Level Security = zero trust at data layer
+-- No row is accessible without explicit policy authorization
+ALTER TABLE sensitive_data ENABLE ROW LEVEL SECURITY;
+
+-- Policy: identity-based access, per-row
+CREATE POLICY "zero_trust_data_access"
+ON sensitive_data
+FOR ALL
+TO authenticated
+USING (
+  user_id = (SELECT auth.uid())
+  AND (SELECT auth.jwt() -> 'app_metadata' ->> 'clearance_level')::int >= required_clearance
+);
+```
+
+---
+
+## Common Zero Trust Anti-Patterns
+
+| Anti-Pattern | Why It Fails |
+|-------------|-------------|
+| VPN as Zero Trust | VPN still grants broad network access after auth — not zero trust |
+| Identity-only Zero Trust | Without device compliance and microsegmentation, identity alone is insufficient |
+| "We have MFA so we're zero trust" | MFA is table stakes, not ZTA |
+| Big bang ZTA deployment | Creates productivity disruption, typically fails — use phased approach |
+| Treating cloud as trusted | Cloud workloads need the same zero trust controls as on-prem |
+| Over-relying on network perimeter | Assumes breach never happens inside — incorrect assumption |
+
+---
+
+## Zero Trust for Brazilian/LGPD Context
+
+Zero Trust architecture directly supports LGPD compliance:
+
+| LGPD Article | Zero Trust Control |
+|-------------|-------------------|
+| Art. 46 — Technical security measures | Identity verification, encryption in transit (mTLS), access control |
+| Art. 38 — DPIA | Zero trust access logs enable privacy impact analysis |
+| Art. 48 — Breach notification | Detailed telemetry enables faster breach detection and scoping |
+| Art. 7 — Lawful basis for processing | Access logs prove data was only accessed per authorized purpose |
+| Principle of data minimization | Microsegmentation prevents services accessing data they don't need |
+
+---
+
+## Key Metrics for Zero Trust Maturity
+
+| Metric | Immature | Mature |
+|--------|---------|--------|
+| % of resources requiring MFA | < 50% | 100% |
+| % of services using mutual TLS | 0% | > 80% |
+| Mean time to detect lateral movement | Days | Minutes |
+| % of network with microsegmentation | < 20% | > 90% |
+| % of access with just-in-time privileged access | 0% | 100% of privileged |
+| % of devices with compliance enforcement | < 30% | 100% |
+
+---
+
+## Sources
+
+- NIST SP 800-207 (Zero Trust Architecture): https://csrc.nist.gov/pubs/sp/800/207/final
+- NIST SP 800-207A (19 ZTA examples): https://www.nist.gov/news-events/news/2025/06/nist-offers-19-ways-build-zero-trust-architectures
+- CISA Zero Trust Maturity Model: https://www.cisa.gov/zero-trust-maturity-model

package/squads/squad-design/knowledge-base/design-systems-frameworks.md

@@ -1,25 +1,343 @@
-# Design Systems & UX Frameworks Reference
-
-## Brad Frost — Atomic Design
-**Source:** "Atomic Design" (2016)
-5 levels: Atoms -> Molecules -> Organisms -> Templates -> Pages
-- Atoms: basic HTML elements (buttons, inputs, labels)
-- Molecules: simple groups (search form = input + button + label)
-- Organisms: complex components (header = logo + nav + search)
-- Templates: page-level layouts with placeholders
-- Pages: specific instances with real content
-
-## Dan Mall — Design System Governance
-**Source:** "Design That Scales" (2023)
-- Hot Potato process: design and dev pass work back and forth rapidly
-- Interface Inventory: audit all existing UI patterns
-- Contribution model: how teams contribute to the design system
-- Governance: who decides what goes in, versioning, breaking changes
-
-## Nielsen Norman Group — Usability Heuristics
-**Source:** Jakob Nielsen (1994)
-10 heuristics: Visibility of system status, Match between system and real world, User control and freedom, Consistency and standards, Error prevention, Recognition over recall, Flexibility and efficiency, Aesthetic and minimalist design, Help users recognize/recover from errors, Help and documentation.
-
-## Google — Material Design Principles
-- Material as metaphor, Bold graphic intentional, Motion provides meaning
-- Design for accessibility, responsive, platform-adaptive
+# Knowledge Base: Design Systems & Frameworks Reference
+
+## Escopo
+Referencia completa de design systems — arquitetura 5-camadas, governance models, Atomic Design, component libraries, CSS approaches, DesignOps, e frameworks de mercado.
+
+---
+
+## 1. Arquitetura de 5 Camadas (EightShapes / Nathan Curtis)
+
+```
+┌─────────────────────────────────────────┐
+│           5. TEMPLATES                  │  Layouts de pagina completos
+├─────────────────────────────────────────┤
+│           4. PATTERNS                   │  Composicoes de UI (forms, nav, cards)
+├─────────────────────────────────────────┤
+│           3. COMPONENTS                 │  Elementos reutilizaveis (Button, Input)
+├─────────────────────────────────────────┤
+│           2. TOKENS                     │  Valores de design (cores, spacing, type)
+├─────────────────────────────────────────┤
+│           1. FOUNDATIONS                │  Principios, brand, voz e tom
+└─────────────────────────────────────────┘
+```
+
+| Camada | Papel | Mutabilidade |
+|--------|-------|-------------|
+| **Foundations** | Principios, brand personality, design principles | Raramente muda — e a "constituicao" |
+| **Tokens** | Valores numericos de decisions de design | Muda com theming, dark mode, brands |
+| **Components** | Elementos reutilizaveis com API documentada | Evolui com versioning semantico |
+| **Patterns** | Composicoes que resolvem UX recorrente | Cresce com o produto |
+| **Templates** | Layouts completos de pagina | Especificos por produto |
+
+**Principio central:** Dependencia flui de baixo para cima. Mudar uma Foundation (cor primaria como token) propaga automaticamente para todos os componentes que a referenciam.
+
+---
+
+## 2. Atomic Design (Brad Frost, 2013/2016)
+
+### 5 Niveis
+
+| Nivel | Analogia Quimica | Descricao | Exemplos |
+|-------|-----------------|-----------|----------|
+| **Atoms** | Atomo | Elementos basicos irredutiveis | Button, Input, Label, Icon, Badge |
+| **Molecules** | Molecula | Grupos de atoms com funcao | Search Field, Form Field, Card Action |
+| **Organisms** | Organismo | Secoes compostas | Header, Product Card, Data Table |
+| **Templates** | Blueprint | Layouts sem conteudo real | Dashboard Layout, Settings Page |
+| **Pages** | Pagina final | Templates com conteudo real | Dashboard com dados reais |
+
+### Hierarquia Simplificada (pratica moderna)
+```
+Primitives → Components → Patterns → Layouts
+```
+A maioria dos design systems na pratica usa essa hierarquia, mas o pensamento composicional de Frost permanece como base intelectual.
+
+### Criticas validas
+- Fronteira molecule/organism e nebulosa
+- Templates e Pages sao mais sobre conteudo que sobre componentes
+- Metafora quimica nao escala perfeitamente
+
+---
+
+## 3. System of Systems (Federated Architecture)
+
+### Modelo Umbrella (Google Material)
+```
+          ┌──────────────────────┐
+          │  Material Design     │  ← Core System (foundations + tokens)
+          └──────────┬───────────┘
+     ┌───────────────┼───────────────┐
+     ▼               ▼               ▼
+┌─────────┐   ┌─────────┐   ┌─────────┐
+│ Android │   │ Flutter │   │  Web    │
+│ (M3)    │   │  (M3)   │   │ (MWC)  │
+└─────────┘   └─────────┘   └─────────┘
+```
+
+### Modelo Hub & Spoke (Salesforce)
+O Lightning Design System (SLDS) e o hub central. Cada produto (Sales Cloud, Service Cloud) e um spoke que estende o hub com componentes especificos.
+
+### Modelo Multi-Brand (Natura &Co)
+Core tokens e componentes "neutros" tematizados via L1 tokens de marca. O mesmo `<Button>` renderiza verde para Natura, rosa para Avon — apenas tokens mudam, nao o componente.
+
+---
+
+## 4. Governance Models
+
+### Modelo Centralizado
+| Vantagem | Desvantagem |
+|----------|-------------|
+| Consistencia maxima | Bottleneck (gargalo no time central) |
+| Qualidade alta | Lento para atender demandas |
+| Governanca forte | Desconexao com necessidades reais |
+
+**Exemplos:** Salesforce (Lightning), IBM (Carbon), Microsoft (Fluent)
+
+### Modelo Federado (Community-Driven)
+| Vantagem | Desvantagem |
+|----------|-------------|
+| Rapido — times criam o que precisam | Risco de inconsistencia |
+| Engajamento alto | Precisa de processos rigorosos de review |
+| Evolui com o produto | Overhead de coordenacao |
+
+### Modelo Hibrido (Hub + Spokes) — Mais Comum 2024-2026
+Time central (2-4 pessoas) mantem core components + governance. Contribuidores de equipes adicionam via RFC process.
+
+**Exemplos:** Shopify (Polaris), GitHub (Primer), Atlassian
+
+### RFC Process (Request for Comments)
+```
+1. Proposer cria RFC document
+   (problema, solucao proposta, API, acessibilidade, timeline)
+2. Review period (7-14 dias) — feedback da comunidade
+3. Decisao: aceitar, modificar ou rejeitar
+4. Implementacao (proposer ou core team)
+5. Review de codigo + review de design
+6. Publicacao + documentacao
+```
+
+### Promotion Model
+```
+1. Time cria componente local para necessidade especifica
+2. Componente e util para outros times → candidato a promocao
+3. Core team avalia: reuso potencial, qualidade, acessibilidade
+4. Se aprovado → migra para o sistema central
+```
+
+---
+
+## 5. CSS Approaches para Design Systems
+
+### Tailwind CSS (94K+ stars, v4 Jan 2025)
+Utility-first framework por Adam Wathan e Steve Schoger.
+
+**Tailwind v4 novidades (lancado 22 Jan 2025):**
+- Engine reescrito do zero: full builds ate 5x mais rapidos, incremental 100x+
+- Configuracao CSS-first (nao mais `tailwind.config.js` obrigatorio)
+- Deteccao automatica de conteudo
+- Paleta de cores modernizada em **OKLCH**
+- Suporte nativo a cascade layers, `@property`, `color-mix()`
+
+```tsx
+<button className="bg-blue-500 hover:bg-blue-600 text-white font-semibold
+  py-2 px-4 rounded-lg shadow-md transition-colors duration-200
+  focus:outline-none focus:ring-2 focus:ring-blue-400 focus:ring-offset-2">
+  Button
+</button>
+```
+
+### CSS Modules
+Escopoamento local por arquivo. Zero runtime overhead. Simples e previsivel.
+
+```css
+/* Button.module.css */
+.button { background: var(--color-primary); padding: 8px 16px; }
+.button:hover { background: var(--color-primary-hover); }
+```
+
+### vanilla-extract (9K+ stars)
+CSS-in-TypeScript com zero runtime. Estilos escritos em TypeScript, compilados para CSS em build time.
+
+```typescript
+// button.css.ts
+import { style } from '@vanilla-extract/css';
+import { vars } from './theme.css';
+
+export const button = style({
+  background: vars.color.primary,
+  padding: `${vars.spacing[2]} ${vars.spacing[4]}`,
+  borderRadius: vars.radius.md,
+  ':hover': { background: vars.color.primaryHover },
+});
+```
+
+### Panda CSS (5K+ stars)
+Por Segun Adebayo (criador do Chakra UI). Combina utilities (Tailwind) com CSS-in-JS (tipagem, recipes) e zero runtime.
+
+```typescript
+const button = cva({
+  base: { display: 'flex', alignItems: 'center' },
+  variants: {
+    variant: {
+      primary: { bg: 'blue.500', color: 'white' },
+      secondary: { bg: 'gray.100', color: 'gray.900' },
+    },
+    size: {
+      sm: { px: '3', py: '1', fontSize: 'sm' },
+      md: { px: '4', py: '2', fontSize: 'md' },
+    },
+  },
+});
+```
+
+### CSS Layers (Cascade Layers)
+`@layer` controla especificidade sem `!important`:
+
+```css
+@layer reset, tokens, components, utilities;
+
+@layer tokens {
+  :root { --color-primary: oklch(60% 0.15 250); }
+}
+@layer components {
+  .button { background: var(--color-primary); }
+}
+@layer utilities {
+  .text-primary { color: var(--color-primary); }
+}
+```
+
+---
+
+## 6. Component Libraries React (Comparacao)
+
+| Biblioteca | Stars (Apr 2026) | Abordagem | Base | Bundle |
+|-----------|-----------------|-----------|------|--------|
+| Material UI (MUI) | 97K+ | Styled Material Design | Emotion/CSS vars | Pesado (~70KB) |
+| Ant Design | 93K+ | Enterprise components | Less/CSS | Pesado |
+| Tailwind CSS | 94K+ | Utility framework | PostCSS | Zero runtime |
+| shadcn/ui | 112K+ | Copy-paste components | Radix + Tailwind | Minimal (voce owns) |
+| Chakra UI v3 | 38K+ | Component library | Ark UI (headless) | Medio |
+| Mantine | 27K+ | Full-featured | CSS Modules | Medio |
+| Radix UI | Base para shadcn | Headless primitives | None | Minimal |
+
+### Material UI (MUI) — 97K+ stars
+A mais popular biblioteca React. Implementa Material Design com extensoes proprias. 70+ componentes, customizavel via theme. MUI v6 (2025) introduziu suporte a CSS variables e melhor zero-runtime styling.
+
+### shadcn/ui — 112K+ stars (fenomeno 2023-2026)
+**Nao e um pacote npm** — e uma colecao de componentes copy-paste sobre Radix UI + Tailwind CSS. Voce executa `npx shadcn@latest add button` e o componente e copiado para seu projeto, totalmente customizavel.
+
+Filosofia: "componentes sao seus, nao de uma dependencia."
+
+Em 2025-2026, ferramentas de IA (Claude Code, v0, Lovable) adotaram shadcn como biblioteca UI padrao, acelerando adocao massivamente (250K+ weekly npm installs). Em 2026, lancou Visual Project Builder e expandiu para Vue e Svelte.
+
+### Radix UI
+Criada pela WorkOS. Primitivos de interface (Dialog, Dropdown, Tabs, Accordion, Tooltip) que sao:
+- Acessiveis out-of-the-box (ARIA patterns corretos, keyboard navigation)
+- Unstyled (total liberdade visual)
+- Composiveis (compound components API)
+- Controlados e nao-controlados
+
+### Chakra UI v3 (38K+ stars)
+Por Segun Adebayo. Foco em DX e acessibilidade. v3 (2025) reconstruiu sobre Ark UI (headless) para melhor performance.
+
+### Ant Design (93K+ stars)
+Biblioteca chinesa (Alibaba) massivamente popular na Asia. Rica em componentes enterprise (Table complexo, DatePicker, Layout). Excelente para admin panels e dashboards.
+
+---
+
+## 7. Headless Components
+
+O padrao headless separa **logica/comportamento** da **apresentacao visual**. O componente headless gerencia estado, acessibilidade, keyboard navigation e ARIA — mas sem estilos visuais.
+
+| Biblioteca | Mantida por | Approach |
+|-----------|-------------|----------|
+| **Radix UI** | WorkOS | React unstyled com a11y impecavel |
+| **Headless UI** | Tailwind Labs | Para Tailwind CSS (React + Vue) |
+| **React Aria** | Adobe | Hooks de acessibilidade (base do Spectrum) |
+| **Ark UI** | Chakra/Segun Adebayo | Multi-framework (React, Vue, Solid) |
+| **Kobalte** | Comunidade | Headless para Solid.js |
+| **Melt UI** | Comunidade | Headless para Svelte |
+
+---
+
+## 8. Web Components
+
+Padroes nativos (Custom Elements + Shadow DOM + HTML Templates) para componentes sem framework.
+
+**Lit (Google — 18K+ stars):** Principal biblioteca para Web Components.
+
+```typescript
+@customElement('my-button')
+class MyButton extends LitElement {
+  @property() variant: 'primary' | 'secondary' = 'primary';
+  @property({ type: Boolean }) loading = false;
+
+  render() {
+    return html`
+      <button class="btn btn-${this.variant}" ?disabled=${this.loading}>
+        <slot></slot>
+      </button>
+    `;
+  }
+}
+```
+
+**Organizacoes usando Web Components:** Google (Material Web), SAP (UI5), Salesforce (Lightning Web Components), ING Bank (Lion). Caso de uso mais forte: multiplos frameworks.
+
+---
+
+## 9. ROI e Metricas
+
+### ROI Benchmark (Sparkbox Design Systems Survey 2023)
+- Reducao media de **34%** no tempo de desenvolvimento
+- Reducao media de **29%** em bugs visuais
+- **89%** reportam melhoria em consistencia
+- **72%** reportam melhoria em velocidade
+
+### Cases notaveis
+- **Salesforce Lightning:** Estimados $2B+ economizados anualmente
+- **Shopify Polaris:** Reducao de 50% no tempo de construcao de novas telas
+
+### Metricas de Adocao
+| Metrica | Como medir | Target |
+|---------|-----------|--------|
+| Coverage | % de telas usando componentes do sistema | > 80% |
+| Token compliance | % de valores visuais via tokens | > 95% |
+| Component reuse | # de instancias por componente | > 10 (media) |
+| Design-dev parity | % de componentes com equivalente Figma+codigo | > 90% |
+| Time to implement | Tempo para nova tela | Reducao > 40% |
+| Satisfaction NPS | Survey trimestral | > 50 |
+
+### Ferramentas de Medicao
+- **Omlet** (YC-backed): Analisa codebase e mede adocao automaticamente
+- **Figma Analytics:** Quais componentes sao mais usados no Figma
+- **Custom ESLint rules:** Detectam uso de componentes nao-aprovados
+
+---
+
+## 10. Personagens Fundadores
+
+| Pessoa | Contribuicao | Obra Principal |
+|--------|-------------|----------------|
+| **Brad Frost** | Atomic Design (2013/2016) | "Atomic Design" (2016) |
+| **Nathan Curtis** | DS Operations, governance, token taxonomy | EightShapes articles |
+| **Jina Anne** | Design Tokens (inventou o conceito, 2014) | W3C DTCG co-chair |
+| **Dan Mall** | DS como produto, team models | "Design That Scales" (2022) |
+| **Alla Kholmatova** | Framework teorico de DS como linguagem | "Design Systems" (Smashing, 2017) |
+| **Adam Wathan** | Tailwind CSS, utility-first | "Refactoring UI" (2018) |
+| **Segun Adebayo** | Chakra UI, Panda CSS, Ark UI | Developer advocate |
+| **Heydon Pickering** | Componentes acessiveis | "Inclusive Components" (2019) |
+| **Lea Verou** | OKLCH, CSS moderno | "CSS Secrets" (O'Reilly, 2015) |
+| **Matias Duarte** | Material Design (Google) | material.io |
+
+---
+
+## Referencias
+- Brad Frost — "Atomic Design" (2016) — atomicdesign.bradfrost.com
+- Nathan Curtis — EightShapes articles — medium.com/@nathanacurtis
+- Dan Mall — "Design That Scales" (2022)
+- Alla Kholmatova — "Design Systems" (Smashing Magazine, 2017)
+- Sparkbox Design Systems Survey 2023
+- shadcn/ui — ui.shadcn.com
+- Radix UI — radix-ui.com
+- Tailwind CSS v4 — tailwindcss.com/blog/tailwindcss-v4