jarvis-ai-framework 2.1.0 → 3.0.0

package/skills/eng-frontend/SKILL.md

@@ -3,10 +3,10 @@ name: eng-frontend
 description: >
   Skill base de desenvolvimento frontend para a plataforma web, válida em qualquer framework:
   HTML semântico, CSS e design responsivo, JavaScript e DOM, estado e componentes, UI e UX,
-  acessibilidade, performance, APIs do navegador, testes e segurança do cliente.
-  Pode ser complementada por skills especializados de uma stack.
+  acessibilidade, performance, APIs do navegador, testes, segurança do cliente, design system/tokens
+  e arquitetura de micro frontend. Pode ser complementada por skills especializados de uma stack.
   Trigger: Use para componentes, interface, estado, bundle, renderização, Core Web Vitals,
-  acessibilidade (WCAG), design system, testes de interface ou frontend em geral.
+  acessibilidade (WCAG), design system, micro frontend, testes de interface ou frontend em geral.
 license: AGPL-3.0
 compatibility: Designed for Claude Code (or similar products)
 allowed-tools: Read Write Edit Glob Grep Bash
@@ -34,7 +34,7 @@ Construir interfaces corretas, performáticas e acessíveis, com foco em qualida
 ## Recursos
 
 - **ENV**: `$IDE/ENV.md` (variáveis e configurações do projeto)
-- **Base universal**: os 12 temas em [references/](references/), carregados sob demanda
+- **Base universal**: os 14 temas em [references/](references/), carregados sob demanda
 - **Saída**: código e testes no repositório atual
 
 ---
@@ -59,6 +59,7 @@ Use este skill quando:
 - Otimizar o desempenho da interface (carregamento, renderização, Core Web Vitals)
 - Revisar ou implementar acessibilidade (WCAG, ARIA, semântica, teclado)
 - Construir ou evoluir um design system (componentes e tokens)
+- Projetar ou integrar uma arquitetura de micro frontend (shell/remote, contratos, shared deps)
 - Escrever testes de interface e tratar a segurança do lado do cliente
 
 **NÃO usar quando:**
@@ -144,6 +145,8 @@ Usar um recurso nativo do navegador?        → tema 9 (APIs do navegador)
 Escrever testes?                            → tema 10 (testes)
 Entrada de dados, cookies ou terceiros?     → tema 11 (segurança do cliente)
 Refatorar ou revisar código?                → tema 12 (qualidade de código)
+Definir token, variante ou versionar componente público? → tema 13 (design system e tokens)
+Integrar remote/shell ou contrato entre apps?            → tema 14 (arquitetura de micro frontend)
 ```
 
 ---
@@ -156,6 +159,12 @@ Refatorar ou revisar código?                → tema 12 (qualidade de código)
 4. **Testar**: cobrir o comportamento, os estados de erro e os casos limite
 5. **Validar**: percorrer o checklist de conclusão abaixo
 
+### Skills invocados durante a execução do skill
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| — | Nenhuma — skill autocontida | — |
+
 ---
 
 ## Base Universal
@@ -176,6 +185,8 @@ Carregue **só o tema necessário** para a tarefa, em vez de todos de uma vez.
 | 10 | [Testes](references/10-testes.md) | Fundamental | Definir a estratégia e a qualidade dos testes |
 | 11 | [Segurança do cliente](references/11-seguranca.md) | Fundamental | Evitar XSS, CSRF e tratar armazenamento, CORS e dependências |
 | 12 | [Qualidade de código](references/12-qualidade-codigo.md) | Fundamental | Refatorar, revisar código e documentar |
+| 13 | [Design system e tokens](references/13-design-system.md) | Importante | Criar/versionar componente público, definir token semântico ou auditar consistência visual |
+| 14 | [Arquitetura de micro frontend](references/14-microfrontend.md) | Importante | Criar remote, integrar ao shell, definir contrato de interface ou resolver shared deps |
 
 ---
 
@@ -188,6 +199,8 @@ Carregue **só o tema necessário** para a tarefa, em vez de todos de uma vez.
 - Fazer requisições diretamente em componentes de UI quando o projeto tem uma camada de dados
 - Contornar o sistema de tipos do projeto sem justificativa
 - Esquecer os casos limite (lista vazia, falha de rede)
+- Hardcodar cor, espaçamento ou fonte fora dos tokens do design system
+- Importar diretamente de outro micro frontend (rompe o isolamento) ou compartilhar estado via módulo entre eles
 
 ### Sempre
 - Considerar mobile-first
@@ -273,4 +286,4 @@ Não invente convenções nem comandos específicos da tecnologia: siga o códig
 
 ## Recursos Adicionais
 
-- **Base universal**: os 12 temas em [references/](references/)
+- **Base universal**: os 14 temas em [references/](references/)

package/skills/eng-frontend/references/13-design-system.md

@@ -0,0 +1,48 @@
+# 13. Design System e Tokens
+
+**Nível:** IMPORTANTE  
+**Independência:** ✅ Válido em qualquer framework ou biblioteca de estilos
+
+## Objetivo
+Traduzir decisões de design em código reutilizável — tokens e componentes primitivos — sem lógica de negócio, versionados de forma que consumidores não quebrem sem aviso.
+
+## Conhecimentos Principais
+
+### O que é (e o que não é) um design system
+- É: componentes primitivos reutilizáveis, tokens de cor/tipografia/espaçamento, padrões de acessibilidade, contrato público de props, documentação viva
+- Não é: lógica de negócio, chamadas de API, estado global da aplicação, componente de feature específica, implementação de tela completa
+
+### Hierarquia de tokens
+- Primitivo: o valor bruto (ex: a cor azul #1a73e8, espaçamento base de 4px)
+- Semântico: o nome que traduz intenção (ex: `color.action.primary`, `space.card.padding`) — aponta para um primitivo
+- Aplicações consomem **semânticos**, nunca primitivos diretamente — permite trocar o valor sem tocar quem usa
+- Tokens de tema (claro/escuro, marca) são uma camada de semânticos, não primitivos novos
+
+### Componentes primitivos
+- Contrato público de props estável — mudar a assinatura é breaking change
+- Variantes (tamanho, tonalidade, estado) descritas declarativamente, não por composição de classes soltas
+- Acessibilidade (semântica, ARIA, foco, contraste) resolvida uma vez no primitivo, herdada por quem consome
+- `forwardRef`/equivalente para componentes que envolvem um elemento nativo — quem consome pode precisar da referência
+
+### Documentação como contrato vivo
+- Cada componente público tem exemplo executável de cada variante e estado (catálogo vivo, não só texto)
+- A documentação é testada: se a variante documentada não compila/renderiza, o catálogo quebra o build
+- Acessibilidade verificada automaticamente no catálogo antes de publicar
+
+### Versionamento e breaking changes
+- Semver: patch (correção visual sem mudar contrato), minor (nova variante/prop opcional), major (contrato muda ou quebra)
+- Breaking change vem com aviso de depreciação antes da remoção, não só no changelog
+- Auditoria periódica: tokens hardcoded fora do sistema e componentes fora do catálogo são dívida, não exceção
+
+## O que NÃO Inclui
+- Sintaxe de uma ferramenta de variantes específica (ex: CVA, Stitches)
+- Configuração de uma ferramenta de catálogo específica (ex: Storybook, Ladle)
+- Framework de componentização (React, Vue, Web Components) — os princípios valem para qualquer um
+
+## Por quê é Universal
+Token semântico, contrato de props estável e versionamento por semver continuam válidos trocando o framework, a biblioteca de estilos ou a ferramenta de catálogo — só a sintaxe muda.
+
+## Referências
+- Frost, *Atomic Design*
+- Material Design — Design Tokens
+- W3C Design Tokens Community Group

package/skills/eng-frontend/references/14-microfrontend.md

@@ -0,0 +1,46 @@
+# 14. Arquitetura de Micro Frontend
+
+**Nível:** IMPORTANTE  
+**Independência:** ✅ Válido em qualquer bundler ou mecanismo de composição
+
+## Objetivo
+Decompor um frontend grande em partes independentes — que times evoluem e publicam sem coordenação síncrona — sem perder coesão para quem usa o produto.
+
+## Conhecimentos Principais
+
+### Papéis
+- Shell (host): orquestra a composição; decide quando e onde montar cada parte
+- Remote (micro frontend): feature isolada; expõe uma API pública (componentes, rotas) para o shell consumir
+- Pacote compartilhado (design system, utilitários): consumido por shell e remotes, não é ele mesmo um remote
+
+### Contrato entre as partes
+- Contrato de interface explícito e tipado — o que o remote expõe e o que ele espera receber do shell
+- Mudar o contrato sem versionar é breaking change silencioso para quem integra
+- O remote nunca importa diretamente de outro remote — isso rompe o isolamento e recria o monolito
+
+### Dependências compartilhadas
+- Bibliotecas que só podem existir em uma instância (ex: a biblioteca de UI, o roteador) são compartilhadas como singleton
+- Carregamento adiantado (eager) de uma dependência compartilhada tende a causar erro de inicialização — carregue sob demanda
+- Conflito de versão entre shell e remote é a causa mais comum de bug "funciona isolado, quebra integrado"
+
+### Comunicação entre partes
+- Estado não se compartilha via import direto de módulo — um barramento de eventos ou callbacks via o shell desacoplam quem fala de quem escuta
+- Cada remote deve funcionar sozinho (modo standalone) para desenvolvimento e teste local, sem depender do shell rodando
+
+### Isolamento de falha e deploy
+- Um remote que falha ao montar não deve derrubar o shell nem os outros remotes — isolar com um limite de erro no ponto de montagem
+- Deploy de um remote é independente do deploy do shell e dos demais remotes — isso é a razão de existir da arquitetura
+- URL/endereço de cada remote vem de configuração/variável de ambiente, nunca hardcoded
+
+## O que NÃO Inclui
+- Configuração de uma implementação de federation específica (ex: Module Federation do Webpack, plugin do Vite)
+- Escolha de bundler
+- Como estruturar o monorepo (ferramenta de workspace, pipeline de CI) — é decisão de projeto
+
+## Por quê é Universal
+Shell/remote, contrato de interface, dependência compartilhada como singleton e isolamento de falha continuam válidos trocando o bundler ou o mecanismo de composição — só a configuração muda.
+
+## Referências
+- Jackson, *Micro Frontends* (martinfowler.com)
+- Module Federation — conceitos (independente de bundler)
+- Geers, *Micro Frontends in Action*

package/skills/eng-global-docs-write/SKILL.md

@@ -25,7 +25,7 @@ Garantir que a documentação reflita com precisão o **estado atual do codebase
 ## Recursos
 
 - **Template C4**: `$IDE/templates/engineering/c4-model-template.md`
-- **Skill arch-c4**: `$IDE/skills/arch-c4/SKILL.md`
+- **Skill eng-backend-arch-c4**: `$IDE/skills/eng-backend-arch-c4/SKILL.md`
 - **Saída**: `$DOCS_FOLDER/` (conforme ENV.md)
 
 > **Dica**: Em caso de dúvida sobre documentação de bibliotecas ou frameworks, use o MCP `context7` para consultar documentação atualizada.
@@ -172,7 +172,7 @@ Você gostaria que eu prosseguisse com essas atualizações?
 
 ## Documentação de Arquitetura (C4 Model)
 
-Quando houver **mudanças arquiteturais significativas**, utilize a skill `arch-c4`:
+Quando houver **mudanças arquiteturais significativas**, utilize a skill `eng-backend-arch-c4`:
 
 ### Quando usar C4 Model
 
@@ -289,10 +289,15 @@ Antes de finalizar:
 
 ## Integração com Outros Skills
 
-Após atualizar a documentação, considere:
+### Skills invocados durante a execução do skill
 
-- **jarvis-docs-index**: Atualizar o índice de documentação (`$IDE/skills/jarvis-docs-index/SKILL.md`)
-- **arch-c4**: Atualizar diagramas C4 se houver mudanças arquiteturais
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Documentação de Arquitetura (C4 Model) | `/eng-backend-arch-c4` | Se houver mudanças arquiteturais significativas (novos serviços ou contêineres, integrações externas, componentes, bancos ou filas, APIs públicas) |
+
+Sugestões após atualizar a documentação (não são chamadas do fluxo):
+
+- `jarvis-docs-index`: atualizar o índice de documentação (`$IDE/skills/jarvis-docs-index/SKILL.md`)
 
 ---
 

package/skills/eng-global-pr/SKILL.md

@@ -29,7 +29,7 @@ Criar branch, commitar alterações e abrir um MR (GitLab) ou PR (GitHub/Bitbuck
 ## Recursos
 
 - **Template**: `$IDE/templates/engineering/PR-template.md`
-- **Regras**: `$IDE/rules/engineering/eng.pr-rules.md`
+- **Regras**: `$IDE/rules-on-demand/engineering/eng.pr-rules.md`
 - **Workflow**: `$IDE/workflows/engineering/eng.pr.md`
 
 ---
@@ -247,6 +247,12 @@ rm -rf $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/
 
 > ⚠️ **IMPORTANTE**: Sempre pedir confirmação antes de executar comandos destrutivos.
 
+### Skills invocados durante a execução do skill
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Passo 6 — Atualizar o card | `/eng-global-task-comment` | Se `TASK_MANAGER` estiver preenchido (freelance pula): comentário no card com o link do MR |
+
 ---
 
 ## Regras de Segurança

package/skills/eng-global-task-comment/SKILL.md

@@ -47,10 +47,10 @@ set -a
 eval "$(grep -E '^(TASK_MANAGER|TASK_MANAGER_URL_BASE|TOKEN_TASK_MANAGER|USER)=' $IDE/ENV.md)"
 set +a
 
-node "$JARVIS_ROOT/bin/lib/tasks/comment.js" "{TASK_MANAGER_KEY}" "{mensagem}"
+jarvis tasks comment "{TASK_MANAGER_KEY}" "{mensagem}"
 ```
 
-`$JARVIS_ROOT` = raiz do framework (ou `$(git rev-parse --show-toplevel)` se o Jarvis estiver no repo). Se o script não existir no projeto, usar o path do clone do framework.
+Se o CLI `jarvis` não estiver instalado no projeto, usar `node "$JARVIS_ROOT/bin/jarvis.js" tasks comment "{TASK_MANAGER_KEY}" "{mensagem}"`, onde `$JARVIS_ROOT` é a raiz do clone do framework (ou `$(git rev-parse --show-toplevel)` se o Jarvis estiver no repo).
 
 Exit 0 → comentário ok. Exit 2 → avisar e **não bloquear** o workflow.
 
@@ -62,3 +62,9 @@ Exit 0 → comentário ok. Exit 2 → avisar e **não bloquear** o workflow.
 ```
 
 Nunca pedir credenciais no chat. Nunca parar o fluxo principal por falha de comentário.
+
+### Skills invocados durante a execução do skill
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| — | Nenhuma — skill autocontida | — |

package/skills/eng-platform/SKILL.md

@@ -0,0 +1,331 @@
+---
+name: eng-platform
+description: >
+  Skill base de platform & infraestrutura, válida em qualquer provedor de nuvem, orquestrador ou
+  ferramenta de pipeline: sistemas, redes, cloud, infraestrutura como código, contêineres e
+  orquestração, CI/CD, observabilidade, confiabilidade (SRE), segurança de infraestrutura e
+  fundamentos de segurança da informação (risco, ameaças, identidade, resposta, GRC, privacidade),
+  resiliência, platform-as-product, FinOps, profiling e diagnóstico de performance, testes de
+  carga/chaos engineering e cache multi-camada. Pode ser complementada por skills especializados
+  de ferramenta ou provedor (ex: Terraform, Kubernetes, AWS, Datadog, k6).
+  Trigger: Use para provisionar ou alterar infraestrutura, criar/ajustar pipelines de CI/CD,
+  instrumentar observabilidade, planejar confiabilidade ou alta disponibilidade, hardening de
+  infraestrutura, modelar ameaças, responder a incidente de segurança, diagnosticar gargalo de
+  performance, planejar teste de carga/chaos ou projetar estratégia de cache, ou analisar custo de nuvem.
+license: AGPL-3.0
+compatibility: Designed for Claude Code (or similar products)
+allowed-tools: Read Write Edit Glob Grep Bash
+metadata:
+  author: jarvis-team
+  version: "1.0"
+  area: platform
+# Campos Claude Code-specific (não fazem parte da spec oficial agentskills.io):
+argument-hint: "[iac|cicd|observabilidade|incidente|seguranca-infra|seguranca-info|custo|performance|cache|chaos] [contexto]"
+disable-model-invocation: false
+---
+
+# Eng Platform - Skill Base de Platform & Infraestrutura
+
+Você é uma **pessoa especialista em platform engineering/infraestrutura sênior**, com domínio dos princípios que valem em qualquer provedor de nuvem, orquestrador ou ferramenta: sistemas, redes, automação, entrega, observabilidade, confiabilidade e segurança — de infraestrutura e de informação.
+
+## Objetivo
+
+Construir e operar a base sobre a qual o software roda — confiável, segura, automatizada e com custo sob controle — aplicando a **base universal** de platform/infraestrutura. Este skill não presume um provedor de nuvem, orquestrador ou ferramenta: ele descobre o que o projeto já usa pelo próprio código (IaC, pipelines, manifests) e segue o padrão que encontra.
+
+## Entrada
+
+- `$ARGUMENTS` - Operação, funcionalidade ou problema a resolver (ex: `provisionar-cluster-k8s`, `criar-pipeline-deploy`, `instrumentar-slo-checkout`, `investigar-incidente-latencia`, `modelar-ameacas-checkout`, `reduzir-custo-storage`)
+
+## Recursos
+
+- **ENV**: `$IDE/ENV.md` (variáveis de ambiente e configurações do projeto)
+- **Base universal**: os 16 temas em [references/](references/), carregados sob demanda
+- **Funções × skills**: [references/especializacoes.md](references/especializacoes.md) — peso por função (DevOps, SRE, Platform Engineering, Cloud, FinOps, DevSecOps, Security Engineering, IAM, Incident Response, GRC etc.)
+- **Saída**: manifests, pipelines, dashboards e runbooks no repositório atual
+
+---
+
+## Pré-requisito
+
+Verificar se o `ENV.md` existe e se as variáveis necessárias ao projeto estão configuradas:
+
+```bash
+cat $IDE/ENV.md
+```
+
+---
+
+## Quando Usar
+
+Use este skill quando:
+- Provisionar, alterar ou revisar infraestrutura como código (Terraform, Pulumi, CloudFormation)
+- Empacotar e orquestrar workloads (contêineres, Kubernetes, scheduling)
+- Criar ou ajustar pipelines de CI/CD e estratégias de deploy
+- Instrumentar observabilidade (métricas, logs, traces, SLI/SLO, alertas)
+- Planejar confiabilidade, incidentes, error budget ou postmortem (SRE)
+- Aplicar segurança de infraestrutura (menor privilégio, segredos, supply chain, hardening)
+- Modelar ameaças, planejar resposta a incidente de segurança, governança/risco/conformidade (GRC) ou privacidade
+- Projetar resiliência, alta disponibilidade ou disaster recovery
+- Reduzir carga cognitiva de times com plataforma como produto (golden paths, self-service)
+- Analisar e otimizar custo de nuvem (FinOps)
+- Diagnosticar gargalo de performance com profiling (CPU, memória, I/O)
+- Planejar teste de carga, teste de estresse ou chaos engineering
+- Projetar estratégia de cache multi-camada (aplicação, distribuído, CDN, browser)
+
+**NÃO usar quando:**
+- A tarefa é exclusivamente de lógica de aplicação (backend/frontend) sem tocar infraestrutura
+- A tarefa é segurança de código de aplicação (OWASP, inputs, auth) — isso já é padrão embutido em `eng-backend`/`eng-frontend`
+
+---
+
+## Validação de Entrada
+
+Se `$ARGUMENTS` está vazio, o skill funciona em modo interativo: pergunte à pessoa o contexto da tarefa de platform/infraestrutura antes de prosseguir.
+
+---
+
+## Padrões Críticos
+
+### Padrão 1: Ler a infraestrutura antes de escrever
+
+Antes de criar ou alterar qualquer coisa, descubra como o projeto já opera:
+
+```
+1. Qual provedor de nuvem, orquestrador e ferramenta de IaC o projeto já usa?
+2. Como os pipelines de CI/CD já estão estruturados?
+3. Como observabilidade e alertas já são feitos (métricas, logs, traces)?
+4. Existe um padrão de nomenclatura e de tags/labels a seguir?
+5. Qual é o estado desejado versionado (Git) e onde ele vive?
+```
+
+Siga o padrão existente do projeto, **não** o padrão genérico deste skill. Se não conseguir identificar o provedor ou a ferramenta, pergunte antes de prosseguir.
+
+### Padrão 2: Tudo falha — projete para falha
+
+```
+1. Todo componente tem um modo de falha conhecido
+2. Meça antes de prometer (SLI real, não suposição)
+3. Defina SLO e error budget antes de prometer confiabilidade
+4. Planeje recuperação (retry, failover, rollback) antes do incidente acontecer
+5. Documente o runbook antes de precisar dele
+```
+
+### Padrão 3: Automatize o repetível, estado em versão
+
+- O que é manual é frágil: automatize o que se repete
+- Infraestrutura como código, declarativa e idempotente — não scripts imperativos sem controle de estado
+- Git é a fonte da verdade do estado desejado (GitOps); drift é detectado, não ignorado
+- Mudança de infraestrutura passa por revisão, como mudança de código
+
+### Padrão 4: Segurança é gestão de risco, não eliminação de ameaça
+
+- Menor privilégio, defesa em profundidade e zero trust desde o desenho, não como camada adicionada depois
+- Assuma violação: detectar e responder pesa tanto quanto prevenir
+- Segredos nunca em texto plano ou hardcoded — sempre em secret manager com rotação
+- Controle sem evidência não passa em auditoria; controle que trava o negócio é contornado
+
+### Padrão 5: Custo é requisito, não etapa final
+
+- Custo é dimensionado e medido desde o provisionamento, não revisado só na fatura
+- Varreduras de segurança (SAST, dependências, imagens) rodam na pipeline, não manualmente
+
+### Padrão 6: Plataforma é produto
+
+- Quem usa a plataforma (outros times) é cliente interno — meça a carga cognitiva que a plataforma impõe
+- Prefira golden paths e self-service a processos que dependem de um time central como gargalo
+- Documentação e exemplos fazem parte da entrega, não um anexo opcional
+
+### Padrão 7: Meça antes de otimizar performance
+
+```
+1. Estabelecer baseline → sem métrica atual, não há "melhor"
+2. Identificar o maior gargalo → profiling e traces, não suposição
+3. Priorizar por impacto no usuário/negócio, não pelo que é mais fácil de otimizar
+4. Implementar com plano de rollback → validar contra o baseline
+5. Monitorar após otimizar → alerta para prevenir regressão
+```
+
+---
+
+## Base ou especialização?
+
+Pergunta-chave para decidir onde um conhecimento mora:
+
+> **Isso continua válido se eu trocar de provedor de nuvem, orquestrador ou ferramenta de pipeline?**
+> **Sim** → pertence à base universal (este skill). **Não** → pertence a uma especialização de ferramenta/provedor.
+
+---
+
+## Árvore de Decisão
+
+```
+Provisionar ou alterar infraestrutura?        → tema 4 (IaC e automação) e tema 3 (cloud)
+Empacotar ou orquestrar workloads?            → tema 5 (contêineres e orquestração)
+Criar ou ajustar pipeline de CI/CD?           → tema 6 (CI/CD e entrega)
+Instrumentar métricas, logs, traces, alertas? → tema 7 (observabilidade)
+Definir SLO, lidar com incidente ou toil?     → tema 8 (confiabilidade e SRE)
+Hardening, segredos ou supply chain?          → tema 9 (segurança de infraestrutura)
+Modelar ameaças, GRC, IAM ou privacidade?     → tema 13 (fundamentos de segurança da informação)
+Planejar alta disponibilidade ou DR?          → tema 10 (resiliência e arquitetura)
+Reduzir carga cognitiva, criar self-service?  → tema 11 (plataforma como produto e DevEx)
+Analisar ou reduzir custo de nuvem?           → tema 12 (FinOps)
+Entender rede, DNS, TLS ou balanceamento?     → tema 2 (redes)
+Entender SO, processos, memória ou I/O?       → tema 1 (fundamentos de sistemas)
+Diagnosticar gargalo com profiling?           → tema 14 (profiling e diagnóstico de performance)
+Planejar teste de carga ou chaos engineering? → tema 15 (testes de carga e chaos engineering)
+Projetar estratégia de cache?                 → tema 16 (cache multi-camada)
+```
+
+---
+
+## Fluxo de Trabalho
+
+1. **Entender**: ler a infraestrutura existente (Padrão 1) e esclarecer o requisito, inclusive o que **não** está no escopo
+2. **Projetar**: escolher a abordagem na base universal; decidir estado desejado, segurança e custo antes de provisionar
+3. **Implementar**: seguir o padrão do projeto, em passos pequenos e revisáveis (plan antes de apply)
+4. **Validar**: testar o plano (dry-run/plan), observar o resultado e confirmar que o estado real bate com o desejado
+5. **Documentar**: runbook, dashboard ou doc de operação para quem vai operar depois
+
+### Skills invocados durante a execução do skill
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| — | Nenhuma — skill autocontida | — |
+
+---
+
+## Base Universal
+
+Carregue **só o tema necessário** para a tarefa, em vez de todos de uma vez.
+
+| # | Tema | Nível | Carregue quando |
+|---|------|-------|-----------------|
+| 1 | [Fundamentos de sistemas](references/1-fundamentos-sistemas.md) | Fundamental | Precisar entender SO, processos, memória, I/O ou limites de recurso |
+| 2 | [Redes](references/2-redes.md) | Fundamental | Projetar TCP/IP, DNS, TLS, balanceamento ou segmentação |
+| 3 | [Computação em nuvem](references/3-cloud.md) | Fundamental | Decidir modelo de serviço, responsabilidade compartilhada ou domínios de falha |
+| 4 | [Infraestrutura como código e automação](references/4-iac-automacao.md) | Fundamental | Provisionar de forma declarativa, idempotente, com GitOps |
+| 5 | [Contêineres e orquestração](references/5-containers-orquestracao.md) | Fundamental | Empacotar, isolar ou agendar workloads |
+| 6 | [CI/CD e entrega de software](references/6-cicd-entrega.md) | Fundamental | Projetar pipelines, estratégias de deploy ou medir métricas DORA |
+| 7 | [Observabilidade e monitoramento](references/7-observabilidade.md) | Fundamental | Instrumentar métricas, logs, traces, SLI/SLO ou alertas |
+| 8 | [Confiabilidade e gestão de incidentes](references/8-confiabilidade-sre.md) | Fundamental | Definir SLO, error budget, lidar com toil, incidente ou postmortem |
+| 9 | [Segurança de infraestrutura e DevSecOps](references/9-seguranca-infra.md) | Fundamental | Aplicar menor privilégio, zero trust ou proteger a cadeia de suprimentos |
+| 10 | [Resiliência e arquitetura de infraestrutura](references/10-resiliencia-arquitetura.md) | Importante | Planejar HA, DR, RTO/RPO, domínios de falha ou degradação |
+| 11 | [Plataforma como produto e DevEx](references/11-plataforma-devex.md) | Importante | Criar golden paths, self-service ou reduzir carga cognitiva |
+| 12 | [FinOps e gestão de custos](references/12-finops-custos.md) | Importante | Alocar, medir unit economics, rightsizing ou negociar compromissos |
+| 13 | [Fundamentos de segurança da informação](references/13-seguranca-fundamentos.md) | Fundamental | Modelar ameaças, tratar identidade/acesso, responder a incidente ou tratar GRC/privacidade |
+| 14 | [Profiling e diagnóstico de performance](references/14-profiling-performance.md) | Importante | Encontrar gargalo de CPU, memória ou I/O antes de otimizar |
+| 15 | [Testes de carga e chaos engineering](references/15-testes-carga-chaos.md) | Importante | Validar capacidade, ponto de ruptura ou injetar falha deliberada |
+| 16 | [Cache multi-camada](references/16-cache-multicamada.md) | Importante | Decidir onde cachear e como invalidar sem servir dado velho |
+
+> **Segurança tem duas entradas**: o tema 9 opera segurança na infraestrutura e na pipeline; o tema 13 é o mapa da disciplina (risco, ameaças, arquitetura, identidade, detecção, resposta, governança e privacidade) e serve a todas as funções de Security. Use os dois juntos quando a tarefa for de Security, não só de infra.
+
+---
+
+## Funções e Peso por Área
+
+Platform/infraestrutura reúne várias funções (DevOps, SRE, Platform Engineering, Cloud, FinOps, DevSecOps, Security Engineering, Security Architecture, IAM, Incident Response, GRC, Privacy Engineering etc.) que partem da mesma base, mas pesam os 16 temas de forma diferente. Ver [references/especializacoes.md](references/especializacoes.md) para o núcleo (●) e o apoio (○) esperado de cada função.
+
+> Para Security: este skill dá o panorama (tema 13) e a operação em infraestrutura (tema 9). A profundidade de código seguro de aplicação está na skill base de Backend/Frontend, a de privacidade/segurança de dados na skill base de Data, e a de segurança de IA na skill base de AI — `Application Security` e `Privacy Engineering` combinam essas bases com esta.
+
+---
+
+## Regras
+
+### Nunca
+- Aplicar mudança de infraestrutura sem revisar o plano antes (dry-run/plan antes de apply)
+- Armazenar segredos, chaves ou credenciais em texto plano ou commitados no código
+- Expor serviço publicamente sem revisar superfície de ataque e menor privilégio
+- Prometer SLO sem medir o SLI real antes
+- Otimizar performance sem baseline, ou gerar carga/injetar falha em produção sem aprovação e blast radius definido
+- Adicionar camada de cache sem estratégia de invalidação
+- Tratar custo como revisão só na fatura, depois do provisionamento
+- Tratar controle de segurança como eliminação de risco, sem plano de detecção e resposta
+- Documentar decisões específicas de um provedor/ferramenta como se fossem universais
+
+### Sempre
+- Versionar o estado desejado da infraestrutura (Git como fonte da verdade)
+- Automatizar o que se repete; tratar drift como algo a detectar, não ignorar
+- Medir antes de prometer confiabilidade ou performance
+- Projetar para falha: ter plano de recuperação antes do incidente
+- Registrar runbook e documentação de operação junto da entrega
+- Ler a infraestrutura e os pipelines existentes antes de criar novas abstrações
+
+---
+
+## Tratamento de Erros
+
+### Provedor ou ferramenta não identificada
+- Procurar arquivos de IaC, manifests de pipeline e configs de observabilidade existentes
+- Se não encontrar, perguntar à pessoa antes de prosseguir
+
+### Infraestrutura existente com padrão diferente
+- Seguir o padrão do projeto, não o genérico deste skill
+- Registrar a divergência quando relevante
+
+### Mudança não idempotente ou com drift detectado
+- Isolar a causa do drift antes de aplicar uma nova mudança por cima
+- Nunca aplicar `apply`/`force` sobre um estado com drift não entendido
+
+---
+
+## Checklist de Conclusão
+
+- [ ] Plano revisado antes de aplicar (dry-run/plan)
+- [ ] Segredos e credenciais fora do código, com rotação definida
+- [ ] Observabilidade mínima (métrica, log ou trace) cobrindo o que foi criado
+- [ ] SLO/SLI definidos quando a mudança afeta confiabilidade
+- [ ] Custo estimado e dentro do esperado para o provisionamento
+- [ ] Ameaças relevantes consideradas quando a mudança afeta superfície de ataque
+- [ ] Baseline e gargalo medidos antes de qualquer otimização de performance
+- [ ] Runbook ou documentação de operação atualizada
+- [ ] Estado desejado versionado (Git) refletindo a mudança
+
+---
+
+## Output
+
+| Artefato | Descrição |
+|----------|-----------|
+| Manifesto de IaC | Definição declarativa e idempotente da infraestrutura |
+| Pipeline de CI/CD | Build, teste e deploy automatizados com estratégia definida |
+| Dashboard/alerta | Observabilidade do que foi provisionado (SLI/SLO) |
+| Runbook | Documentação de operação, resposta a incidente (técnico ou de segurança) |
+| Relatório de performance | Baseline, gargalo identificado e resultado pós-otimização |
+
+---
+
+## Mensagem de Conclusão
+
+```
+Implementação de platform/infraestrutura concluída!
+
+Operação: {descrição do que foi implementado}
+Provedor/ferramenta do projeto: {identificados no código}
+
+Segurança: {menor privilégio / segredos / hardening / ameaças consideradas}
+Observabilidade: {métricas, logs ou traces criados / pendentes}
+Custo: {estimado / dentro do esperado}
+
+Próximo passo: {aplicar o plano / validar no ambiente / revisar dashboard}
+```
+
+---
+
+## Aviso: uso só da skill base
+
+Quando o trabalho usar **só a skill base** e envolver um provedor, orquestrador ou ferramenta para a qual **não há skill especializado** disponível, avise a pessoa de forma explícita:
+
+```
+ℹ️ Estou usando só a skill base de platform.
+   Não há skill especializado para {provedor/ferramenta}; vou seguir os princípios universais
+   e o padrão que encontrei no projeto.
+```
+
+Não invente convenções nem comandos específicos do provedor ou da ferramenta: siga o código do projeto e a base universal.
+
+---
+
+## Recursos Adicionais
+
+- **Base universal**: os 16 temas em [references/](references/)
+- **Funções × skills**: [references/especializacoes.md](references/especializacoes.md)

package/skills/eng-platform/references/1-fundamentos-sistemas.md

@@ -0,0 +1,23 @@
+# 1. Fundamentos de Sistemas
+
+**Nível:** FUNDAMENTAL · **Agnóstico de tecnologia:** ✅
+
+**Objetivo:** Entender como uma máquina executa software para diagnosticar problemas abaixo da aplicação.
+
+**Conhecimentos:** processos, threads e escalonamento; memória virtual, paginação e swap; sistemas de arquivos e I/O; usuários, permissões e chamadas de sistema; boot e gerenciamento de serviços; limites de recurso (CPU, memória, descritores); virtualização vs. isolamento; shell e scripting.
+
+**Princípios:**
+- Todo recurso é finito: meça utilização, saturação e erros (método USE) antes de ajustar.
+- Abstrações vazam; saiba o que há embaixo da que você usa.
+
+**Fora do escopo:** comandos, flags e ajustes de kernel específicos de uma distribuição.
+
+**Pergunta-chave:** Um serviço está lento e a CPU está ociosa. Onde você investiga?
+
+**Referências:**
+- Arpaci-Dusseau, *Operating Systems: Three Easy Pieces*
+- Gregg, *Systems Performance* (2ª ed., 2020)
+- Tanenbaum & Bos, *Modern Operating Systems*
+- IEEE 1003.1 (POSIX)
+
+**Usam mais:** Systems, Infrastructure, SRE, DevOps

package/skills/eng-platform/references/10-resiliencia-arquitetura.md

@@ -0,0 +1,24 @@
+# 10. Resiliência e Arquitetura de Infraestrutura
+
+**Nível:** IMPORTANTE · **Agnóstico de tecnologia:** ✅
+
+**Objetivo:** Projetar infraestrutura que continua útil quando partes falham.
+
+**Conhecimentos:** redundância e domínios de falha; alta disponibilidade vs. recuperação de desastres; RTO e RPO; backup/restore, pilot light, warm standby, active-active; escala vertical e horizontal; timeouts, retries com backoff, circuit breaker, bulkhead; degradação graciosa; backups testados; consistência em sistemas distribuídos (CAP/PACELC); dimensionamento de capacidade.
+
+**Princípios:**
+- Backup sem teste de restauração não é backup.
+- Retries sem limite viram a própria falha.
+- Custo de disponibilidade cresce de forma não linear.
+
+**Fora do escopo:** topologias proprietárias de um provedor ou produto.
+
+**Pergunta-chave:** Qual é o RPO real do seu sistema, e quando você o testou pela última vez?
+
+**Referências:**
+- Nygard, *Release It!* (2ª ed.)
+- Kleppmann, *Designing Data-Intensive Applications*
+- Hamilton, *On Designing and Deploying Internet-Scale Services* (LISA 2007)
+- ISO 22301 (continuidade de negócio)
+
+**Usam mais:** Architecture, SRE, Infrastructure, Systems

package/skills/eng-platform/references/11-plataforma-devex.md

@@ -0,0 +1,24 @@
+# 11. Plataforma como Produto e DevEx
+
+**Nível:** IMPORTANTE · **Agnóstico de tecnologia:** ✅
+
+**Objetivo:** Reduzir a carga cognitiva de quem entrega software, tratando a plataforma como produto.
+
+**Conhecimentos:** plataforma com clientes internos; golden paths e caminhos pavimentados; autoatendimento e abstrações no nível certo; carga cognitiva; tipos de times (stream-aligned, platform, enabling, complicated-subsystem); portal e catálogo de serviços; contratos e versionamento da plataforma; métricas de adoção e satisfação; produtividade do desenvolvedor (SPACE, DORA); documentação e onboarding; feedback contínuo.
+
+**Princípios:**
+- Adoção voluntária prova valor; obrigatoriedade esconde falhas.
+- Abstraia o que é comum, deixe saída para o que é diferente.
+- Medir DevEx exige percepção e fluxo, não só atividade.
+
+**Fora do escopo:** portais, templates e produtos de plataforma específicos.
+
+**Pergunta-chave:** Quem são os clientes da sua plataforma e como você sabe se ela os ajuda?
+
+**Referências:**
+- Skelton & Pais, *Team Topologies*
+- CNCF, *Platforms White Paper*
+- Forsgren et al., *The SPACE of Developer Productivity* (ACM Queue, 2021)
+- Noda et al., *DevEx: What Actually Drives Productivity* (ACM Queue, 2023)
+
+**Usam mais:** Platform, DevEx, Architecture, DevOps