@maestro-ai/mcp-server 1.0.0 → 1.0.1

package/dist/content/guides/M/303/251tricas de Efici/303/252ncia do Desenvolvimento com IA.md"

@@ -1,93 +1,93 @@
-# Métricas de Eficiência do Desenvolvimento com IA
-
-Como medir o impacto do uso de IA no seu fluxo de desenvolvimento.
-
----
-
-## Por que Medir?
-
-- Justificar investimento em ferramentas de IA
-- Identificar onde IA agrega mais valor
-- Otimizar prompts e workflows
-- Treinar equipe em melhores práticas
-
----
-
-## Métricas Principais
-
-### 1. Tempo Economizado
-
-| Atividade | Sem IA | Com IA | Economia |
-|---|---|---|---|
-| Escrever testes | X min | Y min | Z% |
-| Documentar código | X min | Y min | Z% |
-| Debug de erro | X min | Y min | Z% |
-| Boilerplate/scaffolding | X min | Y min | Z% |
-
-**Como medir:** Time tracking em tarefas similares com/sem IA
-
-### 2. Taxa de Aceitação de Código
-
-```
-Taxa = (Código aceito da IA) / (Total gerado pela IA) × 100
-```
-
-- **> 80%**: IA bem calibrada, prompts eficientes
-- **50-80%**: Revisar qualidade dos prompts
-- **< 50%**: Repensar uso ou treinar equipe
-
-### 3. Qualidade do Código Gerado
-
-- **Bugs encontrados** em código gerado por IA vs. escrito manualmente
-- **Cobertura de testes** de código gerado
-- **Complexidade ciclomática** do código gerado
-
-### 4. Velocidade de Entrega
-
-- **Lead time** de features (início → produção)
-- **Cycle time** de tarefas individuais
-- **Throughput** (features entregues por sprint)
-
----
-
-## Template de Acompanhamento
-
-```markdown
-## Sprint X - Métricas de IA
-
-### Resumo
-- Tarefas com apoio de IA: X/Y
-- Tempo total economizado: ~X horas
-- Taxa de aceitação média: X%
-
-### Por Atividade
-| Atividade | Usos | Taxa Aceitação | Tempo Economizado |
-|---|---|---|---|
-| Geração de testes | X | X% | X min |
-| Debugging | X | X% | X min |
-| Documentação | X | X% | X min |
-
-### Observações
-- O que funcionou bem:
-- O que pode melhorar:
-- Prompts a documentar:
-```
-
----
-
-## Ferramentas de Medição
-
-- **Time tracking:** Toggl, Clockify, Harvest
-- **Métricas de código:** SonarQube, Code Climate
-- **Métricas de entrega:** Jira, Linear, GitHub Projects
-- **Logs de uso:** Salvar prompts úteis e resultados
-
----
-
-## Boas Práticas
-
-1. **Meça por um período** antes de tirar conclusões (mínimo 2-4 sprints)
-2. **Compare tarefas similares** para evitar viés
-3. **Inclua tempo de revisão** na conta - código gerado precisa ser revisado
-4. **Documente prompts eficientes** para reuso da equipe
-5. **Itere** - ajuste prompts baseado em métricas
+# Métricas de Eficiência do Desenvolvimento com IA
+
+Como medir o impacto do uso de IA no seu fluxo de desenvolvimento.
+
+---
+
+## Por que Medir?
+
+- Justificar investimento em ferramentas de IA
+- Identificar onde IA agrega mais valor
+- Otimizar prompts e workflows
+- Treinar equipe em melhores práticas
+
+---
+
+## Métricas Principais
+
+### 1. Tempo Economizado
+
+| Atividade | Sem IA | Com IA | Economia |
+|---|---|---|---|
+| Escrever testes | X min | Y min | Z% |
+| Documentar código | X min | Y min | Z% |
+| Debug de erro | X min | Y min | Z% |
+| Boilerplate/scaffolding | X min | Y min | Z% |
+
+**Como medir:** Time tracking em tarefas similares com/sem IA
+
+### 2. Taxa de Aceitação de Código
+
+```
+Taxa = (Código aceito da IA) / (Total gerado pela IA) × 100
+```
+
+- **> 80%**: IA bem calibrada, prompts eficientes
+- **50-80%**: Revisar qualidade dos prompts
+- **< 50%**: Repensar uso ou treinar equipe
+
+### 3. Qualidade do Código Gerado
+
+- **Bugs encontrados** em código gerado por IA vs. escrito manualmente
+- **Cobertura de testes** de código gerado
+- **Complexidade ciclomática** do código gerado
+
+### 4. Velocidade de Entrega
+
+- **Lead time** de features (início → produção)
+- **Cycle time** de tarefas individuais
+- **Throughput** (features entregues por sprint)
+
+---
+
+## Template de Acompanhamento
+
+```markdown
+## Sprint X - Métricas de IA
+
+### Resumo
+- Tarefas com apoio de IA: X/Y
+- Tempo total economizado: ~X horas
+- Taxa de aceitação média: X%
+
+### Por Atividade
+| Atividade | Usos | Taxa Aceitação | Tempo Economizado |
+|---|---|---|---|
+| Geração de testes | X | X% | X min |
+| Debugging | X | X% | X min |
+| Documentação | X | X% | X min |
+
+### Observações
+- O que funcionou bem:
+- O que pode melhorar:
+- Prompts a documentar:
+```
+
+---
+
+## Ferramentas de Medição
+
+- **Time tracking:** Toggl, Clockify, Harvest
+- **Métricas de código:** SonarQube, Code Climate
+- **Métricas de entrega:** Jira, Linear, GitHub Projects
+- **Logs de uso:** Salvar prompts úteis e resultados
+
+---
+
+## Boas Práticas
+
+1. **Meça por um período** antes de tirar conclusões (mínimo 2-4 sprints)
+2. **Compare tarefas similares** para evitar viés
+3. **Inclua tempo de revisão** na conta - código gerado precisa ser revisado
+4. **Documente prompts eficientes** para reuso da equipe
+5. **Itere** - ajuste prompts baseado em métricas

package/dist/content/guides/Rules base.md

@@ -1,90 +1,90 @@
-# Regras do Cursor (Template Padrão Universal)
-
-Arquivo `.cursor-rules` para configuração do ambiente de desenvolvimento
-quando estiver usando um assistente de código/IA como "engenheiro sênior virtual".
-
-## 🎯 Persona
-Engenheiro de Software Sênior/Tech Lead focado em código production-ready:
-limpo, escalável, seguro e testado.
-
-### Comportamento Esperado
-- Pragmático, com foco em soluções robustas.
-- Antecipa edge cases.
-- Comunicação clara e direta.
-
----
-
-## 💻 Stack Técnica
-
-Este template é **agnóstico de stack**, mas traz exemplos para
-um cenário comum de front-end Web com TypeScript/React.
-
-- **Linguagens/Frameworks**: definidos no Tech Spec do projeto.
-- **Frontend (exemplo)**: React/Next.js com TypeScript.
-- **Backend (exemplo)**: Node/Nest, Java/Spring, .NET, ou outro definido no projeto.
-- **Banco/ORM (exemplo)**: PostgreSQL, Prisma/TypeORM/JPA, etc.
-- **Estilo/UI**: Design System definido (ex.: Tailwind, shadcn/ui, Material UI etc.).
-
-> Adapte estes exemplos para a stack concreta do projeto antes de iniciar.
-
----
-
-## ✍️ Diretrizes de Código
-
-1. **Clean Code**: legibilidade, SRP, manutenibilidade.
-2. **SOLID**: aplicar onde fizer sentido (sem over-engineering).
-3. **Separação de Responsabilidades** (para Web, como exemplo):
-   - Componentes: UI pura (sem lógica complexa de negócio).
-   - Hooks/Serviços: lógica de estado e de aplicação.
-4. **Padrões gerais**:
-   - Prefira `async/await` a `.then()`
-   - Evite `any` em TypeScript; use tipagem explícita.
-   - Nomenclatura consistente:
-     - Componentes React: `MeuComponente.tsx` (PascalCase)
-     - Hooks: `useMeuHook.ts` (camelCase)
-     - Demais arquivos: `meu-arquivo.ts` (kebab-case) ou convenção local do projeto.
-
----
-
-## 🧪 Estratégia de Testes
-
-Os nomes abaixo são **exemplos**; troque pelas ferramentas da sua stack.
-
-### 1. Componentes Visuais (Dumb)
-- **O que testar**: variações de estado (default, hover, disabled, error).
-- **Ferramentas típicas**: Storybook ou equivalente para documentação interativa.
-- **Exemplo**: `Button.stories.tsx` (ou similar na sua stack).
-
-### 2. Lógica de Estado / Domínio (Smart)
-- **O que testar**: hooks, serviços, regras de negócio.
-- **Ferramentas típicas**:
-  - JavaScript/TypeScript: Jest/Vitest + Testing Library.
-  - Python: pytest.
-  - Java: JUnit.
-- **Abordagem**: TDD sempre que possível em regras críticas.
-
-### 3. Fluxos de Usuário (E2E)
-- **O que testar**: jornadas completas (Login, Cadastro, Checkout etc.).
-- **Ferramentas típicas**: Playwright, Cypress, Selenium, etc.
-- **Abordagem**: documentar cenários críticos e evitar excesso de flakiness.
-
----
-
-## 🗂️ Estrutura de Arquivos (exemplo)
-
-Ajuste os caminhos de acordo com o framework real:
-
-- **API**: `[caminho/para/openapi.yaml]`
-- **Banco**: `[caminho/para/schema.prisma ou migrations/]`
-- **UI**: `[src/components/ui/]`
-- **Rotas**: `[src/app/api/ ou equivalente]`
-
----
-
-## 💬 Comportamento de Resposta da IA
-
-1. **Autonomia**: resolver em uma resposta quando possível, sem depender de múltiplas idas e vindas desnecessárias.
-2. **Clareza**: pedir esclarecimentos em casos ambíguos ao invés de supor demais.
-3. **Justificativa**: explicar decisões arquiteturais importantes com prós e contras.
-4. **Contexto**: sempre considerar o Tech Spec, o Playbook de Desenvolvimento com IA
-   e os especialistas relevantes ao responder.
+# Regras do Cursor (Template Padrão Universal)
+
+Arquivo `.cursor-rules` para configuração do ambiente de desenvolvimento
+quando estiver usando um assistente de código/IA como "engenheiro sênior virtual".
+
+## 🎯 Persona
+Engenheiro de Software Sênior/Tech Lead focado em código production-ready:
+limpo, escalável, seguro e testado.
+
+### Comportamento Esperado
+- Pragmático, com foco em soluções robustas.
+- Antecipa edge cases.
+- Comunicação clara e direta.
+
+---
+
+## 💻 Stack Técnica
+
+Este template é **agnóstico de stack**, mas traz exemplos para
+um cenário comum de front-end Web com TypeScript/React.
+
+- **Linguagens/Frameworks**: definidos no Tech Spec do projeto.
+- **Frontend (exemplo)**: React/Next.js com TypeScript.
+- **Backend (exemplo)**: Node/Nest, Java/Spring, .NET, ou outro definido no projeto.
+- **Banco/ORM (exemplo)**: PostgreSQL, Prisma/TypeORM/JPA, etc.
+- **Estilo/UI**: Design System definido (ex.: Tailwind, shadcn/ui, Material UI etc.).
+
+> Adapte estes exemplos para a stack concreta do projeto antes de iniciar.
+
+---
+
+## ✍️ Diretrizes de Código
+
+1. **Clean Code**: legibilidade, SRP, manutenibilidade.
+2. **SOLID**: aplicar onde fizer sentido (sem over-engineering).
+3. **Separação de Responsabilidades** (para Web, como exemplo):
+   - Componentes: UI pura (sem lógica complexa de negócio).
+   - Hooks/Serviços: lógica de estado e de aplicação.
+4. **Padrões gerais**:
+   - Prefira `async/await` a `.then()`
+   - Evite `any` em TypeScript; use tipagem explícita.
+   - Nomenclatura consistente:
+     - Componentes React: `MeuComponente.tsx` (PascalCase)
+     - Hooks: `useMeuHook.ts` (camelCase)
+     - Demais arquivos: `meu-arquivo.ts` (kebab-case) ou convenção local do projeto.
+
+---
+
+## 🧪 Estratégia de Testes
+
+Os nomes abaixo são **exemplos**; troque pelas ferramentas da sua stack.
+
+### 1. Componentes Visuais (Dumb)
+- **O que testar**: variações de estado (default, hover, disabled, error).
+- **Ferramentas típicas**: Storybook ou equivalente para documentação interativa.
+- **Exemplo**: `Button.stories.tsx` (ou similar na sua stack).
+
+### 2. Lógica de Estado / Domínio (Smart)
+- **O que testar**: hooks, serviços, regras de negócio.
+- **Ferramentas típicas**:
+  - JavaScript/TypeScript: Jest/Vitest + Testing Library.
+  - Python: pytest.
+  - Java: JUnit.
+- **Abordagem**: TDD sempre que possível em regras críticas.
+
+### 3. Fluxos de Usuário (E2E)
+- **O que testar**: jornadas completas (Login, Cadastro, Checkout etc.).
+- **Ferramentas típicas**: Playwright, Cypress, Selenium, etc.
+- **Abordagem**: documentar cenários críticos e evitar excesso de flakiness.
+
+---
+
+## 🗂️ Estrutura de Arquivos (exemplo)
+
+Ajuste os caminhos de acordo com o framework real:
+
+- **API**: `[caminho/para/openapi.yaml]`
+- **Banco**: `[caminho/para/schema.prisma ou migrations/]`
+- **UI**: `[src/components/ui/]`
+- **Rotas**: `[src/app/api/ ou equivalente]`
+
+---
+
+## 💬 Comportamento de Resposta da IA
+
+1. **Autonomia**: resolver em uma resposta quando possível, sem depender de múltiplas idas e vindas desnecessárias.
+2. **Clareza**: pedir esclarecimentos em casos ambíguos ao invés de supor demais.
+3. **Justificativa**: explicar decisões arquiteturais importantes com prós e contras.
+4. **Contexto**: sempre considerar o Tech Spec, o Playbook de Desenvolvimento com IA
+   e os especialistas relevantes ao responder.