🔒 MENTORIA FUNNEL LABS I.A. · MATERIAL EXCLUSIVO DOS MEMBROS · PROIBIDO COMPARTILHAR, REDISTRIBUIR OU REVENDER
Metodologia · v2.1

A engenharia 10x.

Lead único, decision tree de roteamento, 5 workflows canônicos, hooks de quality gate, princípios Karpathy. Software como deveria ser feito — não como é normalmente feito.

Princípios fundadores

PRINCÍPIO 01

Lead único é não-negociável

O @engineering-chief é a porta de entrada para TUDO. Análogo ao @theboss do MSE. Sem chief, sem entrega — porque sem chief não tem briefing, triage, review nem delivery padronizados.

PRINCÍPIO 02

Karpathy guidelines aplicados

Think Before Coding (premissas explícitas), Simplicity First (zero abstração especulativa), Surgical Changes (toca só o necessário), Goal-Driven Execution (critério de sucesso verificável antes de loopar).

PRINCÍPIO 03

YAGNI · KISS · DRY

You Aren't Gonna Need It (zero feature pra hipotético futuro). Keep It Simple Stupid (3 linhas similares vence abstração prematura). Don't Repeat Yourself (apenas se o repeat for o MESMO conceito, não a mesma sintaxe).

PRINCÍPIO 04

TDD em features novas

Skill tdd-mastery ativa por padrão. Em features novas, testes primeiro. Em bug fixes, teste que reproduz o bug primeiro. Cobertura mínima 70% — bloco se cair abaixo.

PRINCÍPIO 05

Security-first, não last

Hook secret-scanner HARD FAIL em commit. @security-auditor revisa código sensível ANTES de merge. Threat modeling pra novos endpoints. OWASP top 10 enforcement.

PRINCÍPIO 06

Observability nasce com a feature

Logs estruturados, métricas RED/USE, traces, SLOs definidos. Skill monitoring-observability guia. Alertas acionáveis (zero barulho).

Decision tree de roteamento

O @engineering-chief consulta esta árvore antes de delegar. Cada folha tem agente(s) responsáveis e command associado quando aplicável.

Tarefa de engineering?
├── Incidente prod (P0/P1)?      → /incident-triage + incident-responder
├── Deploy?                       → /deploy-check + deployment-engineer
├── Segurança/auditoria?          → /security-audit + security-auditor
├── Performance/lentidão?         → /perf-audit + performance-engineer + postgres-pro
├── Refactor/tech debt?           → /refactor-pass + code-simplifier + complexity-reducer
├── DB/queries/RLS?               → /db-optimize + postgres-pro
├── PR/merge/quality gate?        → /code-quality-gate + code-reviewer
├── Decisão complexa/tradeoffs?   → ultrathink + brainstormer
├── Validação cruzada?            → double-check
├── Cleanup pre-release?          → dead-code-finder
├── Feature nova:
│   ├── Next.js 16/App Router/RSC → nextjs-developer
│   ├── Node.js backend           → node-specialist
│   ├── Python/FastAPI            → fastapi-developer
│   ├── React Native/Expo         → expo-react-native-expert
│   ├── JS moderno/tooling        → javascript-pro
│   └── Genérico                  → planner → fullstack-developer
├── Infra:
│   ├── Cloud architecture        → cloud-architect
│   ├── Cloudflare/Vercel/AWS     → deployment-engineer
│   └── Docker/containers         → docker-expert
├── QA:
│   ├── Test strategy             → qa-expert
│   ├── Automação                 → test-automator
│   └── Resiliência/chaos         → chaos-engineer
├── AI/LLM:
│   ├── Sistema multi-LLM/RAG     → ai-engineer
│   ├── Arquitetura LLM           → llm-architect
│   └── Otimização de prompt      → prompt-engineer
├── Erro distribuído/correlação   → error-detective + error-coordinator
├── Multi-agente paralelo         → multi-agent-coordinator + context-manager
└── Síntese cross-agente          → knowledge-synthesizer

5 workflows canônicos

WORKFLOW 01

Feature Development

Pipeline: @engineering-chief → @planner → @researcher (paralelo) → specialist → @tester → @code-reviewer (+ @security-auditor se sensível) → @docs-manager → @git-manager.

Quando usar: features novas, mudanças não-triviais, código de produção.

WORKFLOW 02

Incidente Produção (P0/P1)

Pipeline: @incident-responder (lead) → @error-detective + @error-coordinator (paralelo correlação logs) → mitigation imediata → RCA → @journal-writer (postmortem blameless).

Quando usar: sistema fora do ar, alertas P0/P1, perda de dados.

WORKFLOW 03

Performance Audit

Pipeline: /perf-audit → @performance-engineer (CWV, latency, profiling) + @postgres-pro (queries, índices) em paralelo → relatório consolidado → fixes priorizados → re-medição.

Quando usar: latência alta, query lentas, p99 fora do SLO, Core Web Vitals ruim.

WORKFLOW 04

Security Hardening

Pipeline: /security-audit → @security-auditor (OWASP + CVEs + threat model) → fixes → @code-reviewer revalida → re-audit.

Quando usar: antes de release sensível, após incidente de segurança, audit periódico (trimestral).

WORKFLOW 05

Multi-Agent Parallel

Pipeline: @multi-agent-coordinator (orchestrator) → 3+ specialists em paralelo com context-manager → @knowledge-synthesizer agrega findings → @engineering-chief delivery.

Quando usar: tarefas grandes com partes independentes, audits cross-cutting, refactors em múltiplas camadas.

Hooks ativos automaticamente

20 hooks distribuídos em momentos estratégicos. 8 são ativos por padrão; 12 disponíveis pra ativação contextual.

HookTriggerSeverityO que faz
secret-scannerPre-commit / Pre-pushHARD FAILBloqueia se detectar API_KEY, SECRET, TOKEN, password hard-coded
commit-guardPre-commitHARD FAILValida conventional commit (feat/fix/docs/chore/etc)
type-checkPós-edit .ts/.tsxSOFTtsc --noEmit nos arquivos alterados
lint-fixPós-editSOFTESLint --fix / ruff format
auto-testPós-edit src/SOFTRoda testes relevantes ao diff
prompt-checkUserPromptSubmitSOFTDetecta prompts vagos e pede mais contexto
learning-logSessionEndSOFTLog diário de aprendizados em ~/.claude/learnings/
pre-compactPreCompactSOFTSalva contexto crítico antes do compact

Padrões enforcados (15 rules)

RULES OPERACIONAIS

Code quality

naming, error-handling, dependency-management, testing, performance.

RULES DE PRODUÇÃO

Production-ready

security, accessibility, monitoring, api-design, database.

RULES DE PROCESS

Workflow

karpathy-guidelines, surgical-changes, no-fake-data, accentuation-pt-br.

O que NÃO é

❌ Não é "AI pair programming"

Não é assistente passivo. É squad com autoridade — chief reprova entrega que não bate o quality gate, mesmo se você reclamar.

❌ Não pula testes "porque tá apertado"

Sem testes = sem merge. Testes "porque o cliente tá esperando" é a forma mais cara de economizar tempo.

❌ Não inventa solução

Se um framework/API/MCP não é conhecido, o squad faz research (Context7, docs-seeker, web search) ANTES de aplicar. Zero chute.

❌ Não silencia erro

Try/catch que engole erro e retorna sucesso = REPROVADO. Erro precisa ser logado, classificado e tratado — ou propagado.