@girardelli/architect 6.0.0 → 8.1.0

package/.agent/workflows/new-feature.md

@@ -1,311 +0,0 @@
----
-antigravity:
-  trigger: 'on_demand'
-  description: 'Workflow completo para nova feature em @girardelli/architect'
----
-
-# 🚀 Workflow: Nova Feature
-
-> **Este workflow é OBRIGATÓRIO para qualquer nova funcionalidade.**
-> Cada step tem um gate de aprovação. Pular steps é violação do protocolo.
-
----
-
-## Pré-requisitos
-
-```
-□ Li INDEX.md e entendi a estrutura do framework
-□ Li 00-general.md (Regras de Ouro)
-□ Li PREFLIGHT.md e completei TODAS as fases
-□ Li QUALITY-GATES.md e sei quais métricas atender
-□ Estou em uma branch feature/ (NUNCA main/develop)
-```
-
----
-
-## FASE 0: AÇÃO ZERO — Diagnóstico
-
-> **ANTES de qualquer coisa, fazer diagnóstico do estado atual.**
-
-```bash
-# Estado do projeto
-git branch --show-current
-git status
-
-# Build e testes ANTES de começar
-npm run build && npm run test
-
-# Score atual
-npx @girardelli/architect score .
-
-# Ler lições aprendidas (se existir)
-cat LESSONS-LEARNED.md 2>/dev/null || echo "Sem lessons learned"
-
-# Regras de negócio (se existir)
-cat BUSINESS-RULES.md 2>/dev/null || echo "Sem business rules"
-```
-
-```
-□ Build passando ✓
-□ Testes passando ✓
-□ Score anotado: ___/100 (não pode regredir)
-□ Lessons learned lidos
-```
-
----
-
-## FASE 1: Diagnóstico da Feature
-
-```
-Quero implementar [NOME DA FEATURE].
-
-Contexto:
-- Quem usa: [usuário / admin / sistema externo / ...]
-- Tem UI: [sim/não]
-- Tem API: [sim/não]
-- Tem banco: [sim/não]
-- Repo: [@girardelli/architect / monorepo path / ...]
-
-Descrição:
-[2-3 frases do ponto de vista do usuário]
-
-Critérios de aceite:
-- CA1: [critério mensurável]
-- CA2: [critério mensurável]
-- CA3: [critério mensurável]
-```
-
----
-
-## Step 1: MOCKUP (se tem UI)
-
-> **Gate 1 — Primeiro artefato. Nada começa sem mockup aprovado (quando tem UI).**
-
-```
-╔══════════════════════════════════════════════════════╗
-║  O MOCKUP DEVE CONTER:                               ║
-║                                                       ║
-║  ✓ TODAS as telas/páginas envolvidas                 ║
-║  ✓ Estado: com dados (normal)                        ║
-║  ✓ Estado: vazio (empty state)                       ║
-║  ✓ Estado: carregando (loading)                      ║
-║  ✓ Estado: erro (error state)                        ║
-║  ✓ TODOS os modais / dialogs                         ║
-║  ✓ Mensagens de sucesso                              ║
-║  ✓ Mensagens de erro                                 ║
-║  ✓ Fluxo completo (passo a passo)                    ║
-║  ✓ Padrão visual do sistema (cores, fontes, layout)  ║
-║                                                       ║
-║  Formato: HTML interativo ou imagens anotadas        ║
-╚══════════════════════════════════════════════════════╝
-```
-
-**Apresentar ao humano → Aguardar `/approved`**
-
----
-
-## Step 2: User Stories
-
-> **Gate 2 — Histórias de usuário com critérios de aceite mensuráveis.**
-
-Formato:
-
-```markdown
-## US-001: [Título]
-
-**Como** [ator],
-**Quero** [ação],
-**Para** [benefício].
-
-### Critérios de Aceite
-- CA1: [critério mensurável]
-- CA2: [critério mensurável]
-
-### Regras de Negócio
-- RN1: [regra]
-
-### Exceções
-- E1: Se [condição], então [comportamento]
-```
-
-**Apresentar ao humano → Aguardar `/approved`**
-
----
-
-## Step 3: Arquitetura (C4)
-
-> **Gate 3 — Visão técnica da implementação.**
-
-Usar template [C4.md](../templates/C4.md):
-
-```
-Nível 1 — Contexto: Quem são os atores e sistemas externos?
-Nível 2 — Container: Quais serviços/apps são afetados?
-Nível 3 — Componente: Quais módulos/classes são criados/modificados?
-Nível 4 — Código: Interfaces, DTOs, entidades (se complexo)
-```
-
-Se a decisão é significativa → criar ADR (template [ADR.md](../templates/ADR.md))
-
-**Apresentar ao humano → Aguardar `/approved`**
-
----
-
-## Step 4: Task Breakdown
-
-> **Gate 4 — Lista de tarefas com estimativa.**
-
-Formato:
-
-```markdown
-## TASK-001: [Título]
-- **US:** US-001
-- **Camada:** Backend / Frontend / App / Database
-- **Estimativa:** XS / S / M / L / XL
-- **Agente:** [quem executa]
-- **Deps:** [depende de TASK-XXX, se houver]
-```
-
-Ordenar por dependência. Backend SEMPRE primeiro.
-
-**Apresentar ao humano → Aguardar `/approved`**
-
----
-
-## Step 5: BDD (Cenários)
-
-> **Gate 5 — Cenários de comportamento para cada critério de aceite.**
-
-Formato (Gherkin):
-
-```gherkin
-Feature: [Nome da Feature]
-
-  Scenario: [cenário happy path]
-    Given [contexto]
-    When [ação do usuário]
-    Then [resultado esperado]
-
-  Scenario: [cenário de erro]
-    Given [contexto]
-    When [ação inválida]
-    Then [mensagem de erro esperada]
-
-  Scenario: [cenário edge case]
-    Given [contexto específico]
-    When [ação]
-    Then [comportamento esperado]
-```
-
-**Apresentar ao humano → Aguardar `/approved`**
-
----
-
-## Step 6: TDD (Casos de Teste)
-
-> **Gate 6 — Casos de teste ANTES do código.**
-
-```
-Para cada TASK:
-  1. Listar os testes que serão escritos
-  2. Descrever input → output esperado
-  3. Incluir testes de erro/exceção
-  4. Incluir testes de boundary
-
-Meta: Cobertura ≥ 80% (INEGOCIÁVEL)
-```
-
-**Apresentar ao humano → Aguardar `/approved`**
-
----
-
-## Step 7: Implementação — Backend
-
-> **SOMENTE após TODOS os 6 gates aprovados.**
-
-```
-□ Criar/modificar entities e DTOs
-□ Criar/modificar services (lógica de negócio)
-□ Criar/modificar controllers (endpoints)
-□ Criar migrations (se houver alteração de banco)
-□ Escrever testes (RED → GREEN → REFACTOR)
-□ Rodar: build ✓ + tests ✓ + coverage ≥ 80% ✓
-```
-
----
-
-## Step 8: Documento de Integração
-
-> **OBRIGATÓRIO se tem frontend/app. Gerado APÓS backend completo.**
-
-```markdown
-# Documento de Integração: [Feature]
-
-## Endpoints
-
-### [METHOD] /api/v1/[recurso]
-
-**Request:**
-\`\`\`json
-{
-  "campo": "tipo — descrição"
-}
-\`\`\`
-
-**Response (200):**
-\`\`\`json
-{
-  "campo": "tipo — descrição"
-}
-\`\`\`
-
-**Erros:**
-| Código | Mensagem | Quando |
-|--------|----------|--------|
-| 400 | Validation error | Input inválido |
-| 404 | Not found | Recurso inexistente |
-
-## Regras
-- [regra 1]
-- [regra 2]
-```
-
----
-
-## Step 9: Implementação — Frontend / App
-
-> **Baseado no Documento de Integração.**
-
-```
-□ Criar/modificar componentes (seguir mockup)
-□ Implementar state management
-□ Integrar com endpoints (conforme doc de integração)
-□ Implementar TODOS os estados (loading, error, empty, data)
-□ Escrever testes (unitários + e2e se aplicável)
-□ Rodar: build ✓ + tests ✓ + coverage ≥ 80% ✓
-```
-
----
-
-## Step 10: Verificação Final
-
-```
-╔════════════════════════════════════════════════╗
-║  CHECKLIST FINAL — TODOS devem ser ✓          ║
-║                                                ║
-║  □ Build compila sem erros                     ║
-║  □ TODOS os testes passam                      ║
-║  □ Cobertura ≥ 80 %                         ║
-║  □ Score ≥ 70 /100 (sem regressão)        ║
-║  □ Lint sem errors                             ║
-║  □ Zero anti-patterns CRITICAL novos           ║
-║  □ Todos os critérios de aceite cobertos       ║
-║  □ Documentação atualizada                     ║
-║  □ LESSONS-LEARNED atualizado (se aplicável)   ║
-║  □ PR criado com descrição completa            ║
-╚════════════════════════════════════════════════╝
-```
-
----
-
-**Gerado por Architect v3.1 · Score: 94/100 · 2026-03-30**

package/.agent/workflows/review.md

@@ -1,95 +0,0 @@
----
-antigravity:
-  trigger: 'on_demand'
-  description: 'Workflow de code review estruturado para @girardelli/architect'
----
-
-# 🔍 Workflow: Code Review
-
-> **Code review não é "LGTM".**
-> É uma verificação sistemática em 6 dimensões.
-
----
-
-## Dimensão 1: Correção Funcional
-
-```
-□ O código faz o que a US/task pede?
-□ Todos os critérios de aceite estão cobertos?
-□ Edge cases foram tratados?
-□ Erros são tratados adequadamente?
-□ Regras de negócio estão corretas?
-```
-
-## Dimensão 2: Qualidade de Código
-
-```
-□ Código legível sem comentários explicativos?
-□ Naming é descritivo e consistente?
-□ Sem duplicação (DRY)?
-□ Funções/métodos com responsabilidade única?
-□ Sem magic numbers (extrair para constantes)?
-□ Tipos corretos (sem `any` / `type: ignore` injustificado)?
-□ Sem código morto / comentado?
-```
-
-## Dimensão 3: Testes
-
-```
-□ Testes existem para o novo código?
-□ Cobertura ≥ 80%?
-□ Testes são significativos (não apenas `expect(true).toBe(true)`)?
-□ Happy path coberto?
-□ Error path coberto?
-□ Edge cases cobertos?
-□ Nenhum teste com .skip() injustificado?
-```
-
-## Dimensão 4: Segurança
-
-```
-□ Sem secrets hardcoded?
-□ Input validado e sanitizado?
-□ SQL injection prevenido (parameterized queries)?
-□ XSS prevenido (output encoding)?
-□ Autenticação/autorização verificada?
-□ Dados sensíveis não logados?
-□ Rate limiting em endpoints novos?
-```
-
-## Dimensão 5: Performance
-
-```
-□ Sem N+1 queries?
-□ Queries com índice adequado?
-□ Sem loops desnecessários sobre coleções grandes?
-□ Lazy loading onde aplicável?
-□ Sem memory leaks óbvios (subscriptions, listeners)?
-□ Caching considerado onde faz sentido?
-```
-
-## Dimensão 6: Arquitetura
-
-```
-□ Segue os padrões do projeto (rules/)?
-□ Camada correta (controller ≠ service ≠ entity)?
-□ Sem violações de layer (data layer acessando UI)?
-□ Score não regrediu: architect score ≥ 70/100
-□ Sem novos anti-patterns CRITICAL?
-□ Imports organizados, sem circulares?
-```
-
----
-
-## Resultado do Review
-
-| Resultado | Ação |
-|-----------|------|
-| ✅ Aprovado | Merge permitido |
-| ⚠️ Aprovado com observações | Merge permitido, fix no próximo PR |
-| ❌ Mudanças necessárias | Bloquear merge até resolver |
-| 🔴 Bloqueado | Issue de segurança ou regressão — resolver imediatamente |
-
----
-
-**Gerado por Architect v3.1 · Score: 94/100 · 2026-03-30**

package/.github/workflows/ci.yml

@@ -1,43 +0,0 @@
-name: Architect CI
-
-on:
-  push:
-    branches:
-      - main
-      - staging
-      - develop
-  pull_request:
-    branches:
-      - main
-      - staging
-      - develop
-
-jobs:
-  build-and-test:
-    name: Build & Test
-    runs-on: ubuntu-latest
-    
-    strategy:
-      matrix:
-        node-version: [18.x, 20.x]
-        
-    steps:
-      - name: Checkout Repository
-        uses: actions/checkout@v4
-        with:
-          fetch-depth: 0 # Required for analyzers like git-history
-
-      - name: Setup Node.js ${{ matrix.node-version }}
-        uses: actions/setup-node@v4
-        with:
-          node-version: ${{ matrix.node-version }}
-          cache: 'npm'
-
-      - name: Install Dependencies
-        run: npm ci
-
-      - name: Type Check & Compilation
-        run: npm run build
-
-      - name: Execute Test Suite
-        run: npm test

package/.github/workflows/publish.yml

@@ -1,40 +0,0 @@
-name: Automatically Publish Plugin to NPM
-
-on:
-  release:
-    types: [created]
-  workflow_dispatch:
-    inputs:
-      tag:
-        description: 'Publish manually (Override Release trigger)'
-        required: false
-
-jobs:
-  publish-npm:
-    name: Publish to NPM Registry
-    runs-on: ubuntu-latest
-    steps:
-      - name: Checkout Repository
-        uses: actions/checkout@v4
-        with:
-          fetch-depth: 0
-
-      - name: Setup Node.js 20.x
-        uses: actions/setup-node@v4
-        with:
-          node-version: '20.x'
-          registry-url: 'https://registry.npmjs.org'
-
-      - name: Install Dependencies
-        run: npm ci
-
-      - name: Build and Transpile
-        run: npm run build
-
-      - name: Run Test Suites
-        run: npm test
-
-      - name: Publish Package
-        run: npm publish --access public
-        env:
-          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

package/CONTRIBUTING.md

@@ -1,140 +0,0 @@
-# Contributing to Architect
-
-Thank you for considering a contribution to Architect! This document provides guidelines and instructions for contributing.
-
-## Code of Conduct
-
-- Be respectful and inclusive
-- Welcome people of all backgrounds and experience levels
-- Focus on constructive feedback
-- Assume good intent
-
-## Getting Started
-
-1. Fork the repository
-2. Clone your fork: `git clone https://github.com/yourusername/architect.git`
-3. Install dependencies: `npm install`
-4. Create a feature branch: `git checkout -b feature/your-feature-name`
-
-## Development
-
-### Build
-
-```bash
-npm run build
-```
-
-### Test
-
-```bash
-npm test
-npm run test:watch
-```
-
-### Linting
-
-```bash
-npm run lint
-```
-
-## Commit Guidelines
-
-- Use clear, descriptive commit messages
-- Reference issues when applicable: "Fixes #123"
-- Keep commits focused on a single change
-- Use present tense: "Add feature" not "Added feature"
-
-## Pull Request Process
-
-1. Update documentation for any new features
-2. Add or update tests for your changes
-3. Ensure all tests pass: `npm test`
-4. Ensure linting passes: `npm run lint`
-5. Write a clear PR description:
-   - What problem does this solve?
-   - How does it solve the problem?
-   - Are there any breaking changes?
-
-## Architecture Guidelines
-
-The codebase follows a modular architecture with clear separation of concerns:
-
-- **Scanner**: Project discovery and analysis
-- **Analyzer**: Dependency and layer analysis
-- **Anti-Pattern Detector**: Code quality issues
-- **Scorer**: Quantitative evaluation
-- **Diagram Generator**: Visualization
-- **Reporter**: Output formatting
-
-Maintain these boundaries when adding new features.
-
-## Adding New Anti-Patterns
-
-To add a new anti-pattern detector:
-
-1. Add detection logic to `src/anti-patterns.ts`
-2. Add unit tests in `tests/anti-patterns.test.ts`
-3. Update README.md with the new pattern
-4. Update sample report if needed
-
-Example:
-
-```typescript
-private detectNewPattern(node: FileNode): AntiPattern[] {
-  const patterns: AntiPattern[] = [];
-  // Detection logic
-  return patterns;
-}
-```
-
-## Reporting Bugs
-
-Use GitHub Issues with:
-
-- Clear title describing the bug
-- Steps to reproduce
-- Expected vs actual behavior
-- TypeScript/Node version
-- Operating system
-
-## Feature Requests
-
-Describe:
-
-- Problem statement (what is missing?)
-- Proposed solution
-- Alternative solutions considered
-- Examples or use cases
-
-## Documentation
-
-- Update README.md for user-facing changes
-- Add JSDoc comments to new functions
-- Include examples for new features
-- Keep comments current with code changes
-
-## Areas for Contribution
-
-- New anti-pattern detectors
-- Improved dependency graph analysis
-- Additional diagram types
-- Better framework detection
-- Performance optimizations
-- Test coverage expansion
-- Documentation improvements
-- Example projects
-
-## Questions?
-
-- Open a GitHub Discussion
-- Check existing issues
-- Read the documentation
-- Contact the maintainers
-
-## License
-
-By contributing, you agree that your contributions will be licensed under the MIT License.
-
----
-
-Thank you for helping make Architect better!

package/LICENSE

@@ -1,21 +0,0 @@
-MIT License
-
-Copyright (c) 2026 Camilo Girardelli, Girardelli Tecnologia
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.