From 443e1417fded94d82bea2beb884dac17f54948aa Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jo=C3=A3o=20Vitor=20Ribeiro=20Santos?= <60783014+tbc-joaovitor@users.noreply.github.com> Date: Fri, 7 Aug 2026 10:44:28 -0300 Subject: [PATCH] =?UTF-8?q?feat:=20brainstorm=20em=20opus,=20implementa?= =?UTF-8?q?=C3=A7=C3=A3o=20em=20sonnet,=20haiku=20s=C3=B3=20no=20deploy=20?= =?UTF-8?q?+=20teto=20de=20fontes?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Regra de modelos revisada. A anterior (haiku implementa, sonnet revisa, opus só a pedido) economizava, mas degradava a qualidade: implementar ADVPL/TLPP ou Fluig é decidir regra de negócio a cada linha, não preencher template. - opus: brainstorm/design, com gate duro — as skills brainstorm param se a sessão não estiver em opus e mandam o dev rodar /model opus - sonnet: implementação e review/QA - haiku: só deploy/compilação (protheus-deployer, fluig-deployer) Nenhum agente troca de modelo por conta própria; quem escala é o dev. Também adiciona o teto de fontes ao SOLID/clean-architecture dos dois plugins: camada != arquivo, orçamento de fontes por porte, piso e teto de tamanho, e o registro de que TLPP aceita mais de uma classe no mesmo fonte (verificado em código compilado em produção). No Fluig a regra é por consumidor, não por linha — o Angular já obriga multi-arquivo por componente. A lista de artefatos passa a ser 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. Bump: protheus 2.15.0, fluig 2.2.0, rollup do kit 2.7.0 (CHANGELOG + badge do README, que estava defasado em 2.1.0). Validado local: tests/run-all.sh verde e a checagem de consistência plugin.json <-> marketplace.json (portada no PR #15) passando. Co-Authored-By: Claude Opus 5 (1M context) --- .claude-plugin/marketplace.json | 4 +-- CHANGELOG.md | 33 +++++++++++++++++++ README.md | 4 +-- fluig/.claude-plugin/plugin.json | 2 +- fluig/CLAUDE.md | 11 ++++--- fluig/README.md | 15 +++++---- fluig/agents/fluig-implementer.md | 4 +-- fluig/agents/fluig-spec-reviewer.md | 1 + fluig/hooks/session-context.cjs | 2 +- fluig/skills/brainstorm/SKILL.md | 12 +++++++ fluig/skills/clean-architecture/SKILL.md | 15 +++++++++ fluig/skills/implement/SKILL.md | 17 +++++----- .../skills/implement/code-reviewer-prompt.md | 4 +-- fluig/skills/implement/implementer-prompt.md | 7 ++-- .../skills/implement/spec-reviewer-prompt.md | 7 ++-- fluig/skills/init-project/SKILL.md | 9 ++--- fluig/skills/plan/SKILL.md | 12 ++++--- fluig/skills/review/SKILL.md | 2 +- protheus/.claude-plugin/plugin.json | 4 +-- protheus/CLAUDE.md | 11 ++++--- protheus/README.md | 15 +++++---- protheus/agents/protheus-implementer.md | 4 +-- protheus/agents/protheus-spec-reviewer.md | 3 ++ protheus/hooks/session-context.cjs | 2 +- protheus/skills/brainstorm/SKILL.md | 12 +++++++ protheus/skills/clean-architecture/SKILL.md | 29 +++++++++++++--- protheus/skills/implement/SKILL.md | 21 +++++++----- .../skills/implement/implementer-prompt.md | 8 ++++- protheus/skills/init-project/SKILL.md | 2 +- protheus/skills/plan/SKILL.md | 23 +++++++++++-- protheus/skills/smartview-relatorio/SKILL.md | 2 +- protheus/skills/verify/SKILL.md | 2 +- 32 files changed, 219 insertions(+), 80 deletions(-) diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json index e78fdd8..581e998 100644 --- 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 index 1b12c0b..0ffaeac 100644 --- 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 index 83c436e..131ecea 100644 --- a/README.md +++ b/README.md @@ -5,7 +5,7 @@ # DA DataAgile Agent Kit -[![Versão](https://img.shields.io/badge/versão-2.1.0-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 index 9b88ee6..9fc7a08 100644 --- 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 index 23f7e52..fb9e2bd 100644 --- 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 index cdf0fed..1f3e566 100644 --- 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 index 6f1e9c0..fae3269 100644 --- a/fluig/agents/fluig-implementer.md +++ b/fluig/agents/fluig-implementer.md @@ -1,6 +1,6 @@ --- 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 @@ -8,7 +8,7 @@ tools: - 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 index 88eadef..cb4c158 100644 --- 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 index 33cf37d..cfab586 100755 --- 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 index 0acd01f..4762249 100644 --- 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: ``. 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 index 7086f86..31634ef 100644 --- 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 index 7bc9dab..3781f1e 100644 --- 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: "" }) ``` @@ -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 index 6685b4a..ed4fbd4 100644 --- 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 index 7706362..4e116b2 100644 --- 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 index 511d501..703bd75 100644 --- 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 --- diff --git a/fluig/skills/init-project/SKILL.md b/fluig/skills/init-project/SKILL.md index 4950f34..531b6a2 100644 --- a/fluig/skills/init-project/SKILL.md +++ b/fluig/skills/init-project/SKILL.md @@ -103,16 +103,17 @@ Prefixo do cliente: `[PREFIXO]` — usado em `wg_[PREFIXO]_`, `ds_[PREFIXO]_`, ` | 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 e QA | **sonnet** | Análise qualitativa, padrões, riscos | -| Opus | **NUNCA automático** | Só quando o dev solicitar. Se complexo, sugerir mas NÃO escalar | +| Deploy | **haiku** | Upload/restart — mecânico | ## Ciclo de Desenvolvimento ``` /fluig:brainstorm → design /fluig:plan → plano de implementação -/fluig:implement → teammates (implementer haiku + reviewers sonnet) +/fluig:implement → teammates (implementer sonnet + reviewers sonnet) /fluig:deploy → deploy servidor teste /fluig:qa → testes E2E + análise QA /fluig:verify → checklist + deploy produção @@ -140,7 +141,7 @@ claude plugin update fluig@claude-skills-dataagile Para iniciar o desenvolvimento: /fluig:brainstorm → planejar o design (SEMPRE primeiro) /fluig:plan → criar plano de implementação - /fluig:implement → executar com teammates (haiku dev + sonnet review) + /fluig:implement → executar com teammates (sonnet dev + sonnet review) /fluig:deploy → deploy no servidor de teste /fluig:qa → testes E2E + análise de qualidade /fluig:verify → deploy final com checklist diff --git a/fluig/skills/plan/SKILL.md b/fluig/skills/plan/SKILL.md index 6b95d65..b5fe95e 100644 --- a/fluig/skills/plan/SKILL.md +++ b/fluig/skills/plan/SKILL.md @@ -109,14 +109,15 @@ O arquivo deve conter: | Fase | Modelo | Razão | |------|--------|-------| -| Implementação (dev) | haiku | velocidade e contexto local | +| Brainstorm / design | opus | decisão de arquitetura — feito antes, no `/fluig:brainstorm` | +| Implementação (dev) | sonnet | implementação carrega regra de negócio, não é mecânica | | Review + QA | sonnet | validação semântica e conformidade | -| Opus | somente se dev solicitar explicitamente | complexidade extrema | +| Deploy | haiku | mecânico (upload/restart), sem decisão de código | ## Próximos passos Após aprovação deste plano: -1. Agente `fluig-implementer` (haiku) executa tasks 1-N +1. Agente `fluig-implementer` (sonnet) executa tasks 1-N 2. Agente `fluig-spec-reviewer` (sonnet) valida conformidade com spec 3. Agente `fluig-reviewer` (sonnet) valida qualidade de código 4. Resultado: `/fluig:deploy` @@ -140,8 +141,11 @@ Inclua o caminho exato do arquivo salvo. - TDD em cada task: teste falha → implementa → teste passa - Caminhos de arquivo sempre qualificados (relativos ao raiz do projeto) - Comandos sempre explícitos (ng test, npm test, ng build, etc.) -- Modelo haiku para implementação, sonnet para reviews +- Modelo sonnet para implementação e reviews; haiku só no deploy; opus só no brainstorm - Plano salvo em git antes de acionar `/fluig:implement` +- **Lista de artefatos fechada:** o implementer não cria arquivo fora da lista do Passo 2. + Arquivo novo = volta ao plano. Não crie service/camada especulativa: só extraia quando + houver **2+ consumidores** ou a testabilidade exigir o dublê. --- diff --git a/fluig/skills/review/SKILL.md b/fluig/skills/review/SKILL.md index c059fb8..6d4f543 100644 --- a/fluig/skills/review/SKILL.md +++ b/fluig/skills/review/SKILL.md @@ -14,7 +14,7 @@ Não declare o artefato "aprovado" ou "pronto para produção" sem completar os ## Regra de Modelos -Teammates de review e QA usam **sonnet**. Nunca escalar para opus automaticamente — se necessário, sugerir ao dev. +Teammates de review e QA usam **sonnet**. Nenhum agente troca de modelo sozinho — opus é do brainstorm, e quem escala é o dev com `/model`. ## Passo 1 — Revisão Estática (fluig-reviewer) diff --git a/protheus/.claude-plugin/plugin.json b/protheus/.claude-plugin/plugin.json index ffd1565..6718d60 100644 --- a/protheus/.claude-plugin/plugin.json +++ b/protheus/.claude-plugin/plugin.json @@ -1,7 +1,7 @@ { "name": "protheus", - "description": "Plugin Claude Code para desenvolvimento TOTVS Protheus — ciclo completo: brainstorm → plan → implement (teammates haiku/sonnet) → deploy (TDS-CLI) → qa (E2E Playwright) → verify. Geração ADVPL/TLPP, SQL embarcado, migração TLPP, diagnóstico, compilação, revisão, testes E2E Playwright (test-web), Knowledge Base MCP, integração TDN, geradores MVC/REST/query, dicionário de dados e geração de relatórios SmartView/TReports (smartview-relatorio).", - "version": "2.14.1", + "description": "Plugin Claude Code para desenvolvimento TOTVS Protheus — ciclo completo: brainstorm → plan → implement (teammates sonnet) → deploy (TDS-CLI) → qa (E2E Playwright) → verify. Geração ADVPL/TLPP, SQL embarcado, migração TLPP, diagnóstico, compilação, revisão, testes E2E Playwright (test-web), Knowledge Base MCP, integração TDN, geradores MVC/REST/query, dicionário de dados e geração de relatórios SmartView/TReports (smartview-relatorio).", + "version": "2.15.0", "author": { "name": "TBC - Time de Desenvolvimento" }, diff --git a/protheus/CLAUDE.md b/protheus/CLAUDE.md index c870ca1..174be57 100644 --- a/protheus/CLAUDE.md +++ b/protheus/CLAUDE.md @@ -43,9 +43,12 @@ Custo de código fora do padrão: alto (retrabalho, code review, manutenção). | Papel | Modelo | Regra | |-------|--------|-------| -| Dev (implementer) | **haiku** | Implementação mecânica, scaffolding, TDD | +| Brainstorm / design | **opus** | `/protheus:brainstorm` para se a sessão não estiver em opus | +| Dev (implementer) | **sonnet** | Implementação carrega regra de negócio; não é mecânica | | Review e QA | **sonnet** | Análise qualitativa, padrões, riscos | -| Opus | **NUNCA automático** | Só quando o dev solicitar. Se complexo, sugerir mas NÃO escalar | +| Deploy / compilação | **haiku** | Compilar, gerar patch — mecânico, sem decisão de código | + +Nenhum agente troca de modelo por conta própria: quem escala é o dev, com `/model`. ## Agent Teams (v2.0.1) @@ -105,7 +108,7 @@ export CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=50 ``` /protheus:brainstorm → MIT044/design aprovado /protheus:plan → plano de implementação com tasks tipadas -/protheus:implement → Agent Team (implementer haiku + reviewers sonnet, worktree) +/protheus:implement → Agent Team (implementer sonnet + reviewers sonnet, worktree) /protheus:deploy → lint + compilação AppServer + patch .ptm /protheus:qa → testes E2E Playwright + análise qualidade /protheus:verify → checklist TOTVS + deploy produção @@ -123,7 +126,7 @@ export CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=50 | Teammate | Modelo | Papel | Isolamento | |----------|--------|-------|------------| -| protheus-implementer | haiku | Implementa tasks do plano via TDD | worktree | +| protheus-implementer | sonnet | Implementa tasks do plano via TDD | worktree | | protheus-spec-reviewer | sonnet | Verifica conformidade com spec | — | | protheus-reviewer | sonnet | Qualidade de código ADVPL/TLPP | — | | protheus-deployer | haiku | Compila via advpls cli + gera patch | — | diff --git a/protheus/README.md b/protheus/README.md index 2bc2ab6..26c5766 100644 --- a/protheus/README.md +++ b/protheus/README.md @@ -2,7 +2,7 @@ Plugin Claude Code para desenvolvimento **TOTVS Protheus** (ADVPL/TLPP). -Ciclo completo: brainstorm → plan → implement (Agent Team haiku/sonnet, worktree) → deploy (TDS-CLI) → qa (TIR E2E) → verify. +Ciclo completo: brainstorm → plan → implement (Agent Team sonnet, worktree) → deploy (TDS-CLI) → qa (TIR E2E) → verify. Conecta automaticamente ao **MCP Server remoto** com a Knowledge Base ADVPL/TLPP da TBC. @@ -174,7 +174,7 @@ Reinicie o Claude Desktop depois de salvar. │ ├─ TeamCreate("protheus-impl-team") │ - ├─ protheus-implementer (haiku, worktree isolado) + ├─ protheus-implementer (sonnet, worktree isolado) │ ├── Recebe task → consulta MCP → implementa → lint │ ├── Reporta DONE/BLOCKED/NEEDS_CONTEXT │ └── Recebe feedback dos reviewers → corrige → re-reporta @@ -208,7 +208,7 @@ Reinicie o Claude Desktop depois de salvar. /protheus:brainstorm → MIT044 (opcional) + perguntas + design aprovado /protheus:plan → decompõe design em tasks ADVPL-tipadas /protheus:implement → Agent Team (worktree + feedback bidirecional): - ├── protheus-implementer (haiku) → implementa cada artefato via TDD + ├── protheus-implementer (sonnet) → implementa cada artefato via TDD ├── protheus-spec-reviewer (sonnet) → verifica conformidade com spec ├── protheus-reviewer (sonnet) → qualidade de código ADVPL/TLPP └── lint gate (advpls appre) → validação local antes de deploy @@ -221,9 +221,10 @@ Reinicie o Claude Desktop depois de salvar. | Papel | Modelo | Regra | |-------|--------|-------| -| Dev (implementer) | **haiku** | Implementação mecânica, scaffolding, TDD | +| Brainstorm / design | **opus** | `/protheus:brainstorm` para se a sessão não estiver em opus | +| Dev (implementer) | **sonnet** | Implementação carrega regra de negócio | | Review e QA | **sonnet** | Análise qualitativa, padrões, riscos | -| Opus | **NUNCA automático** | Só quando o dev solicitar explicitamente | +| Deploy / compilação | **haiku** | Compilar e gerar patch — mecânico | ## Skills Disponíveis (17) @@ -274,7 +275,7 @@ Esteira do código ao artefato renderizando dados num SmartView (TReports) self- | Teammate | Modelo | Papel | Isolamento | |----------|--------|-------|------------| -| `protheus-implementer` | haiku | Implementa tasks do plano via TDD | worktree | +| `protheus-implementer` | sonnet | Implementa tasks do plano via TDD | worktree | | `protheus-spec-reviewer` | sonnet | Verifica conformidade com spec | — | | `protheus-reviewer` | sonnet | Qualidade de código ADVPL/TLPP | — | | `protheus-deployer` | haiku | Compila via `advpls cli` + gera patch .ptm | — | @@ -382,7 +383,7 @@ protheus/ │ ├── references/recipe.md # receita do ambiente (env-driven) │ └── assets/VENDASIA.tlpp # BO de exemplo (dados literais) ├── agents/ # 5 teammates (Agent Teams) -│ ├── protheus-implementer.md # haiku — implementa tasks (worktree) +│ ├── protheus-implementer.md # sonnet — implementa tasks (worktree) │ ├── protheus-spec-reviewer.md # sonnet — verifica spec │ ├── protheus-reviewer.md # sonnet — qualidade código │ ├── protheus-deployer.md # haiku — compila + patch diff --git a/protheus/agents/protheus-implementer.md b/protheus/agents/protheus-implementer.md index 3b7a33c..ad67eff 100644 --- a/protheus/agents/protheus-implementer.md +++ b/protheus/agents/protheus-implementer.md @@ -1,6 +1,6 @@ --- name: protheus-implementer -description: Implementa tasks do plano ADVPL/TLPP seguindo TDD. Recebe task via SendMessage, consulta MCP para convenções, implementa, testa com lint (advpls appre), auto-revisa e reporta status. Modelo haiku — implementação mecânica e scaffolding. Use proactively após /protheus:plan. +description: Implementa tasks do plano ADVPL/TLPP seguindo TDD. Recebe task via SendMessage, consulta MCP para convenções, implementa, testa com lint (advpls appre), auto-revisa e reporta status. Modelo sonnet — implementação exige raciocínio sobre regra de negócio. Use proactively após /protheus:plan. tools: - Read - Grep @@ -8,7 +8,7 @@ tools: - Bash - Edit - Write -model: haiku +model: sonnet --- Você é o implementador de tasks ADVPL/TLPP para TOTVS Protheus, operando como **teammate** em um Agent Team. diff --git a/protheus/agents/protheus-spec-reviewer.md b/protheus/agents/protheus-spec-reviewer.md index 9ee3075..31db99f 100644 --- a/protheus/agents/protheus-spec-reviewer.md +++ b/protheus/agents/protheus-spec-reviewer.md @@ -47,6 +47,9 @@ Para cada item da especificação: - [ ] Campos especificados estão sendo lidos/gravados - [ ] Retorno do PE está correto (se aplicável) - [ ] Fluxo de dados está correto +- [ ] **Nenhum fonte fora do plano.** Compare a lista de fontes criados/alterados com a + tabela de tasks do plano. Fonte que não está no plano é ❌ CRÍTICO — reporte com + `arquivo:linha` e mande voltar ao plano/brainstorm, não aprove "porque ficou bom" ### 4. Reportar diff --git a/protheus/hooks/session-context.cjs b/protheus/hooks/session-context.cjs index 534d487..60b8fde 100755 --- a/protheus/hooks/session-context.cjs +++ b/protheus/hooks/session-context.cjs @@ -19,6 +19,6 @@ emitSessionContext({ ], notes: [ 'MCP tools disponiveis: searchFunction, findEndpoint, findSmartView, listModules (catalogo) + ragSearchKnowledge, ragSearchDocs (busca semantica) — plugin protheus 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/protheus/skills/brainstorm/SKILL.md b/protheus/skills/brainstorm/SKILL.md index 0670117..4b0e18b 100644 --- a/protheus/skills/brainstorm/SKILL.md +++ b/protheus/skills/brainstorm/SKILL.md @@ -7,6 +7,18 @@ description: Planejamento de desenvolvimento ADVPL/TLPP — intake de MIT044, ex Não gere nenhum código ADVPL/TLPP, não crie arquivos .prw/.tlpp e não invoque nenhum skill de implementação antes de apresentar o design e obter aprovação do desenvolvedor. + +Brainstorm é design, e design roda em **opus**. Antes do Passo 0, 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: ``. Rode `/model opus` e chame `/protheus:brainstorm` de novo. + +Não explore o projeto, não faça as perguntas do Passo 2 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 doc. + + ## Passo 0 — Documento de desenvolvimento Antes de qualquer exploração, pergunte: diff --git a/protheus/skills/clean-architecture/SKILL.md b/protheus/skills/clean-architecture/SKILL.md index d0cf3dc..571372b 100644 --- a/protheus/skills/clean-architecture/SKILL.md +++ b/protheus/skills/clean-architecture/SKILL.md @@ -63,15 +63,34 @@ regra pura sem sufixo. A nomenclatura de arquivo segue a convenção do projeto; ## Quando aplicar (pragmatismo) -| Tamanho da mudança | Estrutura mínima | -|---|---| -| PE trivial, ajuste de 1 função | Só a regra de sempre: PE delega para User Function | -| Rotina nova média (1–3 fontes) | Separar ao menos **regra pura** × **acesso a dados** (2 funções/classes) — o suficiente para testar a regra por unidade, sem banco | -| Desenvolvimento grande (módulo, integração, N fontes) | Camadas completas: adaptador → caso de uso → domínio + repositórios, 1 namespace por contexto | +| Tamanho da mudança | Estrutura mínima | Orçamento de fontes (fora os de teste) | +|---|---|---| +| PE trivial, ajuste de 1 função | Só a regra de sempre: PE delega para User Function | 1 | +| Rotina nova média | Separar ao menos **regra pura** × **acesso a dados** (2 funções/classes) — o suficiente para testar a regra por unidade, sem banco | até 3 | +| Desenvolvimento grande (módulo, integração) | Camadas completas: adaptador → caso de uso → domínio + repositórios, 1 namespace por contexto | 1 fonte por camada por contexto; acima disso, justifique fonte a fonte no plano | Sobre-engenharia também é dívida: **não** crie interface + repositório + service para encapsular um `Posicione()`. O critério é: a regra de negócio merece viver isolada e testada. +### Camada ≠ arquivo (o SOLID não é para virar enxurrada de fontes) + +Um fonte gigante é problema; **vinte fontes minúsculos também são** — cada `.tlpp` entra no +patch, precisa compilar, versionar e ser conferido na documentação de customizações. Separe +por **motivo de mudança**, não por contagem de classes. + +- **TLPP aceita mais de uma classe no mesmo fonte** (verificado em código compilado em + produção: adapter + service convivendo no mesmo arquivo, sob o mesmo `namespace`). Classes + coesas — mesmo papel, mesmo contexto, que mudam pelo mesmo motivo — ficam juntas. +- **Piso:** classe pequena que existe só "para ficar SOLID" volta para o fonte do seu papel. + Interface com uma implementação só: só crie se o teste precisa do dublê. +- **Teto:** fonte passando de ~800 linhas, ou classe de ~500, é sinal de divisão real. +- **A lista de fontes é fechada no `/protheus:plan`.** Fonte que não está no plano não é + criado na implementação — se apareceu a necessidade, ela é decisão de design e volta ao + `/protheus:brainstorm`. + +> Os números são ponto de partida calibrado em desenvolvimento real. Ajuste no seu projeto se +> o padrão local for outro — mas mantenha um teto **declarado**, não "o quanto sair". + ## Fluxo de uso 1. **No design** (`/protheus:brainstorm` / `/protheus:plan` / `/protheus:advpl-tlpp-sdd`): diff --git a/protheus/skills/implement/SKILL.md b/protheus/skills/implement/SKILL.md index f417a31..205eeb6 100644 --- a/protheus/skills/implement/SKILL.md +++ b/protheus/skills/implement/SKILL.md @@ -1,6 +1,6 @@ --- name: implement -description: Orquestra Agent Team para executar o plano ADVPL/TLPP — protheus-implementer (haiku) implementa em worktree isolado, protheus-spec-reviewer (sonnet) verifica spec, protheus-reviewer (sonnet) revisa qualidade. Comunicação bidirecional entre teammates. Gate de compilação via lint. Use após /protheus:plan. Próximo passo: /protheus:deploy. +description: Orquestra Agent Team para executar o plano ADVPL/TLPP — protheus-implementer (sonnet) implementa em worktree isolado, protheus-spec-reviewer (sonnet) verifica spec, protheus-reviewer (sonnet) revisa qualidade. Comunicação bidirecional entre teammates. Gate de compilação via lint. Use após /protheus:plan. Próximo passo: /protheus:deploy. disable-model-invocation: true --- @@ -25,10 +25,11 @@ Se Agent Teams não estiver habilitado, informe o usuário e caia no fallback (E | Papel | Modelo | Uso | |-------|--------|-----| -| protheus-implementer | **haiku** | Implementação mecânica, TDD | +| protheus-implementer | **sonnet** | Implementação — exige raciocínio sobre regra de negócio | | protheus-spec-reviewer | **sonnet** | Verificação de conformidade com spec | | protheus-reviewer | **sonnet** | Qualidade de código ADVPL/TLPP | -| Opus | **NUNCA automático** | Se complexo, sugerir ao dev — decisão é dele | +| Opus | **só no brainstorm** | O design já foi feito em opus (`/protheus:brainstorm`). Nenhum teammate escala sozinho | +| Haiku | **não usar aqui** | Haiku só em deploy/compilação (`protheus-deployer`) | --- @@ -52,14 +53,14 @@ TeamCreate({ ``` Os teammates serão despachados via Agent tool com: -- `subagent_type: "protheus:protheus-implementer"` (haiku) +- `subagent_type: "protheus:protheus-implementer"` (sonnet) - `subagent_type: "protheus:protheus-spec-reviewer"` (sonnet) - `subagent_type: "protheus:protheus-reviewer"` (sonnet) - `isolation: "worktree"` para implementador (trabalha em cópia isolada) --- -## Estágio 1 — Implementação (teammate haiku, worktree isolado) +## Estágio 1 — Implementação (teammate sonnet, worktree isolado) Para cada task de implementação do plano, despache o teammate `protheus-implementer`: @@ -68,7 +69,7 @@ Agent({ subagent_type: "protheus:protheus-implementer", name: "impl-task-N", isolation: "worktree", - model: "haiku", + model: "sonnet", prompt: "" }) ``` @@ -198,10 +199,12 @@ Próximo passo: /protheus:deploy ### Sobre complexidade -Se durante a implementação identificar que uma task é complexa demais para haiku: +Se durante a implementação aparecer uma decisão de **design** que o brainstorm não +resolveu (nova camada, novo fonte, contrato diferente do aprovado), **pare** — isso não se +resolve na implementação: ``` -⚠️ Task [N] pode se beneficiar do modelo opus para [motivo]. -Deseja escalar este task para opus? (decisão do dev) +⚠️ Task [N] esbarra em decisão de design não coberta pelo design aprovado: [motivo]. +Volte ao /protheus:brainstorm (opus) antes de continuar. ``` **Nunca escalar automaticamente.** A decisão é sempre do desenvolvedor. diff --git a/protheus/skills/implement/implementer-prompt.md b/protheus/skills/implement/implementer-prompt.md index c0b1c70..3107e8c 100644 --- a/protheus/skills/implement/implementer-prompt.md +++ b/protheus/skills/implement/implementer-prompt.md @@ -22,5 +22,11 @@ Implemente a seguinte task do plano: ## Instruções 1. Consulte o MCP para convenções e templates antes de codificar 2. Siga TDD: implemente → lint → auto-review -3. Reporte DONE, BLOCKED ou NEEDS_CONTEXT ao final +3. Não crie fonte (.prw/.tlpp) que não esteja nesta task. A lista de fontes do + plano é fechada. Se achar que falta um, reporte BLOCKED com o motivo — fonte + novo é decisão de design e volta ao /protheus:brainstorm. + Classes coesas do mesmo papel e contexto ficam no MESMO fonte (TLPP aceita + mais de uma classe por arquivo); só divida quando mudarem por motivos + diferentes ou o fonte passar de ~800 linhas. +4. Reporte DONE, BLOCKED ou NEEDS_CONTEXT ao final ``` diff --git a/protheus/skills/init-project/SKILL.md b/protheus/skills/init-project/SKILL.md index 9637284..f27c98d 100644 --- a/protheus/skills/init-project/SKILL.md +++ b/protheus/skills/init-project/SKILL.md @@ -112,7 +112,7 @@ ls -la .git/hooks/pre-commit Para iniciar o desenvolvimento: /protheus:brainstorm → planejar o design (SEMPRE primeiro) /protheus:plan → criar plano de implementação - /protheus:implement → executar com teammates (haiku dev + sonnet review) + /protheus:implement → executar com teammates (sonnet dev + sonnet review) /protheus:deploy → lint + compilação AppServer + patch .ptm /protheus:qa → testes E2E Playwright + análise qualidade /protheus:verify → checklist TOTVS + deploy produção diff --git a/protheus/skills/plan/SKILL.md b/protheus/skills/plan/SKILL.md index 71fc895..5ff1d2e 100644 --- a/protheus/skills/plan/SKILL.md +++ b/protheus/skills/plan/SKILL.md @@ -31,7 +31,7 @@ Para cada artefato identificado no design, crie uma task com: ``` Task N: Implementar [NOME_ARQUIVO] -Teammate: protheus-implementer (haiku) +Teammate: protheus-implementer (sonnet) Artefato: R[MOD][TYPE][SEQ].prw (ou .tlpp) Tipo: [User Function | MVC | Ponto de Entrada | Relatório] Responsabilidade: [descrição funcional] @@ -45,6 +45,23 @@ Contexto para o teammate: Tasks de implementação **podem rodar em paralelo** quando os artefatos forem independentes (PE em arquivo próprio, funções sem dependência mútua). +### Fechar a lista de fontes (orçamento de arquivos) + +A lista de fontes do plano é **fechada**: o implementer não cria fonte que não esteja na +tabela de tasks. Fonte novo = volta ao plano (e, se for decisão de design, ao +`/protheus:brainstorm`). + +| Tamanho do desenvolvimento | Orçamento de fontes (fora os de teste) | +|---|---| +| Ajuste pontual / PE | 1 | +| Rotina nova média | até 3 | +| Desenvolvimento grande | 1 fonte por camada por contexto — acima disso, justifique no plano | + +- **Camada ≠ arquivo.** TLPP aceita mais de uma classe no mesmo fonte; classes coesas do mesmo + papel e contexto ficam juntas, e só se separam quando mudam por motivos diferentes. +- **Teto:** fonte acima de ~800 linhas (ou classe de ~500) é sinal de divisão real. +- Sobre-engenharia é dívida igual a monólito: **os dois** custam manutenção e patch. + --- ## Passo 3 — Adicionar tasks fixas de qualidade (sempre nesta ordem) @@ -122,8 +139,8 @@ Formato do plano: | # | Artefato | Tipo | Teammate | Paralelo? | |---|---------|------|----------|-----------| -| 1 | RFATA001.prw | User Function | protheus-implementer (haiku) | sim | -| 2 | PE_MATA010.prw | Ponto de Entrada MVC | protheus-implementer (haiku) | sim | +| 1 | RFATA001.prw | User Function | protheus-implementer (sonnet) | sim | +| 2 | PE_MATA010.prw | Ponto de Entrada MVC | protheus-implementer (sonnet) | sim | ## Tasks de Qualidade e Deploy diff --git a/protheus/skills/smartview-relatorio/SKILL.md b/protheus/skills/smartview-relatorio/SKILL.md index 1f889ce..a276fb9 100644 --- a/protheus/skills/smartview-relatorio/SKILL.md +++ b/protheus/skills/smartview-relatorio/SKILL.md @@ -89,7 +89,7 @@ para Grid/Pivot; para Report, ler o screenshot do viewer. "Existir" ≠ "renderi ## Regras de modelo (TBC) - Tarefas com **Playwright** (montar artefato na UI, screenshots) → SEMPRE `model: sonnet`. -- Geração de código/scaffolding → `haiku`. +- Geração de código/scaffolding → `sonnet` (haiku só em deploy/compilação). ## Recursos - `scripts/generate_bo.py` + `scripts/templates/integratedprovider.tlpp.j2` — gerador do BO. diff --git a/protheus/skills/verify/SKILL.md b/protheus/skills/verify/SKILL.md index 7bf43bc..77ca6a0 100644 --- a/protheus/skills/verify/SKILL.md +++ b/protheus/skills/verify/SKILL.md @@ -82,7 +82,7 @@ Próximos passos para produção: Ciclo de desenvolvimento concluído. Todos os gates passaram: - ✅ Implementação (teammates haiku + sonnet) + ✅ Implementação (teammates sonnet) ✅ Review spec + qualidade ✅ Lint gate (advpls appre) ✅ Deploy compilado (patch .ptm)