tbc-joaovitor · Aug 7, 2026 · Aug 7, 2026 · Aug 7, 2026
diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json
@@ -13,7 +13,7 @@
       "name": "fluig",
       "source": "./fluig",
       "description": "Plugin para desenvolvimento TOTVS Fluig — ciclo completo: design (brainstorm), scaffolding (widget/dataset/form/workflow), revisão estática + testes (review) e deploy (verify).",
-      "version": "2.1.1",
+      "version": "2.2.0",
       "author": {
         "name": "DataAgile"
       },
@@ -30,7 +30,7 @@
       "name": "protheus",
       "source": "./protheus",
       "description": "Plugin para desenvolvimento TOTVS Protheus — ciclo completo: brainstorm → plan → implement (Agent Teams) → deploy TDS-CLI → qa E2E → verify, geradores MVC/REST/query, dicionário de dados, SmartView/TReports e Knowledge Base remota (155k+ registros).",
-      "version": "2.14.1",
+      "version": "2.15.0",
       "author": {
         "name": "DataAgile"
       },

diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -4,6 +4,39 @@ Histórico das versões públicas do `dataagile-agent-kit`.
 
 ---
 
+## [2.7.0] — 2026-08-07
+
+### Brainstorm em opus, implementação em sonnet, haiku só no deploy (protheus 2.15.0 · fluig 2.2.0)
+
+A regra anterior — haiku implementava, sonnet revisava, opus só a pedido — economizava, mas
+degradava a qualidade do código: implementar ADVPL/TLPP ou Fluig é decidir regra de negócio a
+cada linha, não preencher template.
+
+Agora: **opus no brainstorm/design**, **sonnet na implementação e no review/QA**, **haiku só em
+deploy/compilação** (`protheus-deployer`, `fluig-deployer`). Nenhum agente troca de modelo por
+conta própria — quem escala é o dev, com `/model`.
+
+O `/protheus:brainstorm` e o `/fluig:brainstorm` ganharam **gate duro**: param se a sessão não
+estiver em opus e mandam o dev rodar `/model opus`, em vez de seguir e produzir design no
+modelo errado.
+
+### Teto de fontes — SOLID deixou de virar enxurrada de arquivo
+
+Um fonte gigante é problema; vinte fontes minúsculos também. Cada `.tlpp` entra no patch,
+compila, versiona e é conferido na documentação de customizações.
+
+O `/protheus:clean-architecture` e o `/fluig:clean-architecture` ganharam a regra
+**camada ≠ arquivo**, com orçamento por porte (ajuste: 1 fonte · rotina média: até 3 ·
+desenvolvimento grande: 1 por camada por contexto), piso e teto de tamanho (~800 linhas por
+fonte, ~500 por classe) e o registro de que **TLPP aceita mais de uma classe no mesmo fonte** —
+classes coesas do mesmo papel ficam juntas. No Fluig a regra é por consumidor: service extraído
+só com 2+ consumidores ou quando o teste exige o dublê, já que o Angular obriga multi-arquivo.
+
+A lista de artefatos virou **gate**: fechada no `plan`, os implementers não criam arquivo fora
+da task (reportam `BLOCKED`) e os spec-reviewers tratam arquivo não previsto como **CRÍTICO**,
+com `arquivo:linha`.
+
+
 ## [2.6.1] — 2026-07-21
 
 ### O implementer parou de adivinhar e de "melhorar" código alheio (protheus 2.14.1 · fluig 2.1.1)

diff --git a/README.md b/README.md
@@ -5,7 +5,7 @@
 
 # DA DataAgile Agent Kit
 
-[![Versão](https://img.shields.io/badge/versão-2.6.1-1a4d5c?style=flat-square&logoColor=white)](https://github.com/tbc-servicos/dataagile-agent-kit/releases)
+[![Versão](https://img.shields.io/badge/versão-2.7.0-1a4d5c?style=flat-square&logoColor=white)](https://github.com/tbc-servicos/dataagile-agent-kit/releases)
 [![Claude Code](https://img.shields.io/badge/Claude_Code-plugin-CC785C?style=flat-square&logoColor=white)](https://claude.ai/code)
 [![Protheus](https://img.shields.io/badge/Protheus-ADVPL%2FTLPP-1a4d5c?style=flat-square&logoColor=white)](https://dataagile-agent-kit.dataagile.com.br)
 [![PO--UI MCP](https://img.shields.io/badge/PO--UI-MCP-22C55E?style=flat-square&logoColor=white)](https://po-ui.io)
@@ -160,7 +160,7 @@ mkdir -p ~/.config/dataagile && echo '{"api_key":"SUA_CHAVE"}' > ~/.config/dataa
 /protheus:plan
         ↓
 /protheus:implement   ←── Agent Team (worktree isolado)
-        ↓                  implementer (haiku)
+        ↓                  implementer (sonnet)
 /protheus:deploy           spec-reviewer (sonnet)
         ↓                  reviewer (sonnet)
 /protheus:qa

diff --git a/fluig/.claude-plugin/plugin.json b/fluig/.claude-plugin/plugin.json
@@ -1,7 +1,7 @@
 {
   "name": "fluig",
   "description": "Plugin Claude Code para desenvolvimento TOTVS Fluig — ciclo completo: brainstorm, planejamento, implementação com teammates (TDD), deploy, QA (E2E Playwright), verificação. Scaffolding de formulários, datasets, widgets Angular 19 + PO-UI, workflows BPM.",
-  "version": "2.1.1",
+  "version": "2.2.0",
   "author": {
     "name": "TBC - Time de Desenvolvimento"
   },

diff --git a/fluig/CLAUDE.md b/fluig/CLAUDE.md
@@ -23,12 +23,13 @@ claude --plugin-dir /home/jv/developments/tbc/claude_skills/fluig
 
 | Papel | Modelo | Regra |
 |-------|--------|-------|
-| **Dev (implementer)** | haiku | Implementação mecânica, scaffolding |
+| **Brainstorm / design** | opus | `/fluig:brainstorm` para se a sessão não estiver em opus |
+| **Dev (implementer)** | sonnet | Implementação carrega regra de negócio |
 | **Review (spec + quality)** | sonnet | Análise qualitativa, padrões |
 | **QA (testes + análise)** | sonnet | Riscos, edge cases |
-| **Opus** | **NUNCA automático** | Só quando o dev solicitar explicitamente. Se a task for complexa, o orquestrador SUGERE mas a decisão é do dev |
+| **Deploy** | haiku | Upload/restart — mecânico, sem decisão de código |
 
-**O plugin NUNCA deve escalar para opus por conta própria. Sempre perguntar.**
+**Nenhum agente troca de modelo por conta própria.** Quem escala é o dev, com `/model`. O opus entra no brainstorm, não no meio da implementação.
 
 ## Agent Teams (v2.0.5)
 
@@ -90,7 +91,7 @@ export CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=50
     ↓
 /fluig:plan        →  plano de implementação
     ↓
-/fluig:implement   →  Agent Team (implementer haiku, worktree + reviewers sonnet)
+/fluig:implement   →  Agent Team (implementer sonnet, worktree + reviewers sonnet)
     ↓
 /fluig:deploy      →  deploy no servidor Fluig
     ↓
@@ -105,7 +106,7 @@ Cada skill guia para a próxima — o dev é conduzido pelo fluxo completo.
 
 | Teammate | Modelo | Papel | Isolamento |
 |----------|--------|-------|------------|
-| `fluig-implementer` | haiku | Implementa tasks do plano (TDD) | worktree |
+| `fluig-implementer` | sonnet | Implementa tasks do plano (TDD) | worktree |
 | `fluig-spec-reviewer` | sonnet | Verifica spec compliance | — |
 | `fluig-reviewer` | sonnet | Verifica code quality | — |
 | `fluig-qa` | sonnet | Análise de riscos e QA | — |

diff --git a/fluig/README.md b/fluig/README.md
@@ -50,7 +50,7 @@ source ~/.zshrc
   │
   ├─ TeamCreate("fluig-impl-team")
   │
-  ├─ fluig-implementer (haiku, worktree isolado)
+  ├─ fluig-implementer (sonnet, worktree isolado)
   │   ├── Recebe task → consulta MCP → implementa TDD → testa
   │   ├── Reporta DONE/BLOCKED/NEEDS_CONTEXT
   │   └── Recebe feedback dos reviewers → corrige → re-reporta
@@ -84,7 +84,7 @@ source ~/.zshrc
         ↓
 /fluig:plan        →  plano de implementação com tasks TDD
         ↓
-/fluig:implement   →  Agent Team (haiku dev + sonnet review, worktree)
+/fluig:implement   →  Agent Team (sonnet dev + sonnet review, worktree)
         ↓
 /fluig:deploy      →  deploy no servidor Fluig de teste
         ↓
@@ -132,7 +132,7 @@ Cada skill termina com **"Próximo passo:"** guiando o dev para a etapa seguinte
 
 | Teammate | Modelo | Papel | Isolamento |
 |----------|--------|-------|------------|
-| `fluig-implementer` | haiku | Implementa tasks do plano seguindo TDD | worktree |
+| `fluig-implementer` | sonnet | Implementa tasks do plano seguindo TDD | worktree |
 | `fluig-spec-reviewer` | sonnet | Verifica conformidade com a spec | — |
 | `fluig-reviewer` | sonnet | Verifica qualidade de código Fluig | — |
 | `fluig-qa` | sonnet | Análise de riscos e edge cases | — |
@@ -142,11 +142,12 @@ Cada skill termina com **"Próximo passo:"** guiando o dev para a etapa seguinte
 
 | Papel | Modelo |
 |-------|--------|
-| Dev (implementer) | **haiku** |
+| Brainstorm / design | **opus** |
+| Dev (implementer) | **sonnet** |
 | Review e QA | **sonnet** |
-| Opus | **NUNCA automático** — só quando o dev solicitar explicitamente |
+| Deploy | **haiku** |
 
-O plugin nunca escala para opus por conta própria. Se a task for complexa, sugere ao dev mas a decisão é dele.
+Nenhum agente troca de modelo por conta própria. O `/fluig:brainstorm` exige opus e para se a sessão não estiver nele — quem troca é o dev, com `/model opus`. Decisão de design que aparece no meio da implementação volta ao brainstorm; não vira escalada ad-hoc.
 
 ## Hooks
 
@@ -183,7 +184,7 @@ fluig/
 │   ├── init-project/   # Setup projeto cliente
 │   └── feedback/       # Registra aprendizado pós-correção
 ├── agents/             # 5 teammates (Agent Teams)
-│   ├── fluig-implementer.md   # Dev (haiku, worktree)
+│   ├── fluig-implementer.md   # Dev (sonnet, worktree)
 │   ├── fluig-spec-reviewer.md # Spec review (sonnet)
 │   ├── fluig-reviewer.md      # Code quality (sonnet)
 │   ├── fluig-qa.md            # QA (sonnet)

diff --git a/fluig/agents/fluig-implementer.md b/fluig/agents/fluig-implementer.md
@@ -1,14 +1,14 @@
 ---
 name: fluig-implementer
-description: Implementa tarefas do plano Fluig seguindo TDD. Recebe task via SendMessage, implementa, testa, faz self-review e reporta status. Modelo haiku para execução mecânica. Comunicação bidirecional com reviewers. Use proactively após /fluig:plan.
+description: Implementa tarefas do plano Fluig seguindo TDD. Recebe task via SendMessage, implementa, testa, faz self-review e reporta status. Modelo sonnet — implementação exige raciocínio sobre regra de negócio. Comunicação bidirecional com reviewers. Use proactively após /fluig:plan.
 tools:
   - Read
   - Edit
   - Write
   - Bash
   - Glob
   - Grep
-model: haiku
+model: sonnet
 ---
 
 # Fluig Implementer Agent

diff --git a/fluig/agents/fluig-spec-reviewer.md b/fluig/agents/fluig-spec-reviewer.md
@@ -53,6 +53,7 @@ Você faz parte de um **Agent Team** com comunicação bidirecional:
 - [ ] Comportamento esperado em happy path?
 - [ ] Edge cases cobertos?
 - [ ] Integração com dependências correta?
+- [ ] Nenhum arquivo fora da lista de artefatos do plano? (arquivo não previsto = ❌ CRÍTICO)
 
 #### 4b. Validação Fluig
 

diff --git a/fluig/hooks/session-context.cjs b/fluig/hooks/session-context.cjs
@@ -18,6 +18,6 @@ emitSessionContext({
   ],
   notes: [
     'MCP tools disponiveis: searchFluigPatterns, searchFluigApi, searchKnowledge (plugin fluig tbc-knowledge)',
-    'Regra de modelos TBC: haiku para implementacao, sonnet para review/QA, opus somente se o dev pedir.',
+    'Regra de modelos: opus para brainstorm/design, sonnet para implementacao e review/QA, haiku somente para deploy/compilacao.',
   ],
 });
diff --git a/fluig/skills/brainstorm/SKILL.md b/fluig/skills/brainstorm/SKILL.md
@@ -10,6 +10,18 @@ Você está iniciando o planejamento de uma funcionalidade Fluig. Nenhum código
 
 Não invoque nenhuma skill de scaffolding (`fluig-widget`, `fluig-form`, `fluig-dataset`, `fluig-workflow`) antes de ter o design aprovado pelo usuário nesta skill.
 
+## HARD GATE — modelo opus
+
+Brainstorm é design, e design roda em **opus**. Antes do Passo 1, verifique qual modelo está
+atendendo esta sessão. Se **não** for opus, PARE e responda exatamente:
+
+> ⚠️ O brainstorm exige o modelo **opus**.
+> Sessão atual: `<modelo>`. Rode `/model opus` e chame `/fluig:brainstorm` de novo.
+
+Não faça as perguntas do Passo 1 e não gere design fora do opus. Só siga em outro modelo se o
+desenvolvedor mandar seguir mesmo assim, por escrito, nesta conversa — e registre isso no
+design aprovado.
+
 ## Passo 1 — Entender o artefato
 
 Use `AskUserQuestion` com as perguntas abaixo em uma única chamada com múltiplas questões:

diff --git a/fluig/skills/clean-architecture/SKILL.md b/fluig/skills/clean-architecture/SKILL.md
@@ -94,6 +94,21 @@ constraint parsing + REST + regra + montagem de dataset. A refatoração guiada
 
 Não crie `domain/` para um widget que só lista um dataset — sobre-engenharia também é dívida.
 
+### Camada ≠ arquivo (o SOLID não é para virar enxurrada de arquivos)
+
+Um arquivo gigante é problema; **vinte arquivos de dez linhas também são** — cada um entra no
+bundle, no review e no `.zip` do widget. Separe por **motivo de mudança**, não por contagem de
+classes. O Angular já obriga multi-arquivo por componente; a camada extra tem que se pagar:
+
+- **Extraia um service quando houver 2+ consumidores** ou quando a testabilidade exigir
+  (dublê no lugar de HTTP/Dataset). Service com um consumidor só é indireção, não arquitetura.
+- **Interface com uma implementação só:** só se o teste precisa do dublê.
+- No dataset/evento (Rhino, sem `import`), o "arquivo por camada" **não existe** — separe em
+  funções puras no mesmo fonte, como já diz o mapa de camadas acima.
+- **A lista de artefatos é fechada no `/fluig:plan`.** Arquivo que não está no plano não é
+  criado na implementação — se a necessidade apareceu, é decisão de design e volta ao
+  `/fluig:brainstorm`.
+
 ## Fluxo de uso
 
 1. **Design** (`/fluig:brainstorm` / `/fluig:plan`): por caso de uso, defina os artefatos

diff --git a/fluig/skills/implement/SKILL.md b/fluig/skills/implement/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: implement
-description: Orquestra Agent Team para executar plano Fluig — fluig-implementer (haiku) implementa em worktree isolado, fluig-spec-reviewer (sonnet) verifica spec, fluig-reviewer (sonnet) revisa qualidade. Comunicação bidirecional entre teammates. Próximo passo obrigatório: /fluig:deploy.
+description: Orquestra Agent Team para executar plano Fluig — fluig-implementer (sonnet) implementa em worktree isolado, fluig-spec-reviewer (sonnet) verifica spec, fluig-reviewer (sonnet) revisa qualidade. Comunicação bidirecional entre teammates. Próximo passo obrigatório: /fluig:deploy.
 disable-model-invocation: true
 ---
 
@@ -26,10 +26,11 @@ Se Agent Teams não estiver habilitado, informe o usuário e caia no fallback (s
 
 | Papel | Modelo | Uso |
 |-------|--------|-----|
-| fluig-implementer | **haiku** | Implementação mecânica, TDD |
+| fluig-implementer | **sonnet** | Implementação — exige raciocínio sobre regra de negócio |
 | fluig-spec-reviewer | **sonnet** | Verificação de conformidade com spec |
 | fluig-reviewer | **sonnet** | Qualidade de código Fluig |
-| Opus | **NUNCA automático** | Se complexo, sugerir ao dev — decisão é dele |
+| Opus | **só no brainstorm** | O design já foi feito em opus (`/fluig:brainstorm`). Nenhum teammate escala sozinho |
+| Haiku | **não usar aqui** | Haiku só em deploy (`fluig-deployer`) |
 
 
 ## Artefato de estado dos gates (gates.json)
@@ -51,7 +52,7 @@ TeamCreate({
 ```
 
 Os teammates serão despachados via Agent tool com:
-- `subagent_type: "fluig:fluig-implementer"` (haiku)
+- `subagent_type: "fluig:fluig-implementer"` (sonnet)
 - `subagent_type: "fluig:fluig-spec-reviewer"` (sonnet)
 - `subagent_type: "fluig:fluig-reviewer"` (sonnet)
 - `isolation: "worktree"` para implementador (trabalha em cópia isolada)
@@ -69,14 +70,14 @@ Leia o arquivo e extraia:
 
 Para cada task na ordem de dependência:
 
-### 2a. Dispatch para fluig-implementer (haiku, worktree isolado)
+### 2a. Dispatch para fluig-implementer (sonnet, worktree isolado)
 
 ```
 Agent({
   subagent_type: "fluig:fluig-implementer",
   name: "impl-task-N",
   isolation: "worktree",
-  model: "haiku",
+  model: "sonnet",
   prompt: "<conteúdo de implementer-prompt.md preenchido>"
 })
 ```
@@ -170,7 +171,7 @@ Próximo passo: /fluig:deploy
 - **Nunca skip reviews** — implementação sempre passa por spec-reviewer E code-reviewer
 - **Nunca prossiga com itens CRÍTICOS** — espere correção ou escale ao usuário
 - **Nunca ignore falhas de teste** — 100% testes passam antes de review
-- **Nunca escale para opus automaticamente** — sugerir mas decisão é do dev
+- **Nunca escale de modelo por conta própria** — implementação e review são sonnet; decisão de design volta ao `/fluig:brainstorm` (opus), com o dev
 
 ## Fallback (sem Agent Teams)
 
@@ -184,7 +185,7 @@ Se Agent Teams não estiver disponível:
 ## Templates de dispatch
 
 Veja os arquivos:
-- `skills/implement/implementer-prompt.md` — template para haiku
+- `skills/implement/implementer-prompt.md` — template para o implementer (sonnet)
 - `skills/implement/spec-reviewer-prompt.md` — template para sonnet validação spec
 - `skills/implement/code-reviewer-prompt.md` — template para sonnet validação código
 

diff --git a/fluig/skills/implement/code-reviewer-prompt.md b/fluig/skills/implement/code-reviewer-prompt.md
@@ -5,7 +5,7 @@ Você é `fluig-reviewer` (modelo: sonnet). Sua tarefa é validar QUALIDADE de c
 ## Contexto
 
 - **Task número:** [N]
-- **Implementador:** fluig-implementer (haiku)
+- **Implementador:** fluig-implementer (sonnet)
 - **Spec reviewer:** já validou conformidade com design ✅
 
 ## Artefatos a revisar
@@ -61,7 +61,7 @@ Aplique TODAS as regras retornadas ao código sendo revisado.
 ## Próximo passo
 
 - ✅ APROVADO / COM AVISOS → task concluída, prossegue para task seguinte
-- ❌ CRÍTICO → `fluig-implementer` (haiku) corrige e re-valida
+- ❌ CRÍTICO → `fluig-implementer` (sonnet) corrige e re-valida
 
 ---
 

diff --git a/fluig/skills/implement/implementer-prompt.md b/fluig/skills/implement/implementer-prompt.md
@@ -1,13 +1,13 @@
 # Implementer Prompt Template
 
-Você é `fluig-implementer` (modelo: haiku). Sua tarefa é executar uma task de implementação Fluig seguindo ciclo TDD rigoroso.
+Você é `fluig-implementer` (modelo: sonnet). Sua tarefa é executar uma task de implementação Fluig seguindo ciclo TDD rigoroso.
 
 ## Contexto
 
 - **Design aprovado:** [inserir resumo do design ou link para spec]
 - **Plano:** [inserir caminho do plano ou resumo]
 - **Task número:** [N]
-- **Modelo esperado:** haiku (você)
+- **Modelo esperado:** sonnet (você)
 
 ## Task a executar
 
@@ -47,6 +47,9 @@ npm run lint
 - **Tecnologias:** [ex: Angular 8, Jasmine, Java]
 - **Integração com:** [ex: Protheus REST, dataset X, workflow Y]
 - **URL Protheus:** [ler de CLAUDE.md — nunca hardcode]
+- **Lista de arquivos fechada:** não crie arquivo que não esteja nesta task. Se achar que
+  falta um, reporte BLOCKED — arquivo novo é decisão de design e volta ao `/fluig:brainstorm`.
+  Não extraia service/camada especulativa: só com 2+ consumidores ou dublê de teste.
 
 ## Status esperado ao fim
 

diff --git a/fluig/skills/implement/spec-reviewer-prompt.md b/fluig/skills/implement/spec-reviewer-prompt.md
@@ -6,7 +6,7 @@ Você é `fluig-spec-reviewer` (modelo: sonnet). Sua tarefa é validar se a impl
 
 - **Design aprovado:** [inserir resumo do design ou link para spec]
 - **Task número:** [N]
-- **Implementador:** fluig-implementer (haiku)
+- **Implementador:** fluig-implementer (sonnet)
 
 ## Task implementada
 
@@ -24,6 +24,9 @@ Você é `fluig-spec-reviewer` (modelo: sonnet). Sua tarefa é validar se a impl
 - [ ] Integrações esperadas estão implementadas?
 - [ ] Fluxo do usuário respeita o design?
 - [ ] Dependências entre artefatos respeitadas?
+- [ ] **Nenhum arquivo fora do plano?** Compare os arquivos criados com a lista de artefatos
+      do plano. Arquivo não previsto é ❌ CRÍTICO — reporte com `arquivo:linha` e devolva ao
+      plano/brainstorm (service extraído sem 2+ consumidores conta como não previsto)
 
 ✅ **Lógica de negócio:**
 - [ ] Comportamento está conforme descrito na spec?
@@ -51,7 +54,7 @@ Você é `fluig-spec-reviewer` (modelo: sonnet). Sua tarefa é validar se a impl
 ## Próximo passo após validação
 
 - ✅ CONFORME → `fluig-reviewer` (sonnet) valida qualidade de código
-- ❌ NÃO CONFORME → `fluig-implementer` (haiku) corrige e re-valida
+- ❌ NÃO CONFORME → `fluig-implementer` (sonnet) corrige e re-valida
 
 ---