Squad AI-Augmented

Documento canônico: 04-operations/ai-augmented-squad.md

Status: ✅ APROVADO — Fernando Parreiras, 18 Abril 2026
Arquivo: 04-operations/ai-augmented-squad.md

O Squad AI-augmented da Tech Human não é uma fábrica de software. É um time pequeno e sênior que entrega com JARVIS — custo marginal tendendo a zero por produto, critério de aceite claro em cada fase, e o mesmo padrão de qualidade independente de qual porta de entrada ativou o projeto.

O que diferencia este squad de qualquer outro

Time convencional: 4–6 engenheiros, 6–9 meses, débito técnico acumulado, código que só o criador entende.

Squad AI-augmented TH: 2–3 humanos sênior + JARVIS (16 agentes IA), 6–10 semanas, Clean Architecture desde o dia zero, TDD 80%, código que qualquer engenheiro sênior mantém.

A diferença não é velocidade. É velocidade com qualidade — o que o mercado diz que é impossível. O JARVIS é a prova de que não é.

Papéis do Squad

Papéis humanos

Papel	Responsabilidade principal	Quem ocupa
Tech Human Lead	Arquitetura, decisões técnicas, critério de aceite por fase, interface com o cliente	Engenheiro sênior TH
Squad Engineer	Execução com JARVIS, testes, revisão de código dos agentes	Engenheiro PJ / parceiro
PM / Estrategista	Backlog, comunicação com cliente, documentação de decisões, relatório de entrega	Fernando ou PM contratado

Para projetos via Porta C (CTO aaS):
O CTO aaS gerencia o Squad diretamente — faz o briefing, define critério de aceite com o cliente (em linguagem de negócio), e valida cada fase antes de avançar. O cliente não precisa entender de tecnologia para cobrar resultado.

Papéis dos agentes JARVIS (IA)

Agente	O que faz no processo
Architecture Agent	Propõe estrutura de módulos, Bounded Contexts, interfaces principais
Code Generator	Gera implementações por módulo seguindo o padrão Clean Architecture
Test Writer	Escreve testes unitários e de integração para cada módulo gerado
Refactor Agent	Revisa e refatora código gerado para atingir padrão de qualidade
Documentation Agent	Gera documentação inline e README de cada módulo
Security Reviewer	Verifica cada PR por padrões de segurança antes do merge
DevOps Configurator	Configura CI/CD, pipelines, variáveis de ambiente
Schema Agent	Projeta banco de dados, migrações, seeders
API Designer	Define contratos de API, validação de inputs, tratamento de erros
Multi-tenancy Guard	Garante isolamento de dados por tenant em cada operação de banco

Os 16 agentes são especializados — cada um tem um domínio e não opera fora dele. O Tech Human Lead define o que cada agente recebe e valida o que cada um entrega.

O JARVIS no processo de entrega

O que o JARVIS entrega que um dev solo não entrega

Foundation herdada: todo projeto começa com a base pronta — autenticação, multi-tenancy, CI/CD, estrutura de pastas, configuração de ambiente. Não parte do zero.

Critério de aceite automático: o JARVIS verifica cobertura de testes (mínimo 80%) antes de qualquer avanço de fase. Se não atingir, bloqueia.

Efeito composto: o primeiro produto custou 100% de esforço para configurar o JARVIS para aquele domínio. O segundo produto no mesmo domínio custa ~20%. O terceiro, ~8%. O custo marginal tende a zero.

O que o JARVIS NÃO faz (e precisa de humano)

Decisões de arquitetura que impactam o negócio do cliente (escolha de módulos, trade-offs de escala)
Comunicação com o cliente (todas as interfaces são humanas)
Validação de produto com usuário real
Revisão final de segurança (JARVIS alerta, humano decide)
Onboarding do time do cliente no sistema entregue

As 6 Fases JARVIS (P1–P6)

Cada fase tem um critério de aceite claro. Não existe “quase pronto”. Não se avança sem o critério ser atingido.

P1 — Discovery

Duração: 3–5 dias
O que acontece: workshop com o cliente para mapear o problema real, os usuários, o fluxo principal e as restrições de negócio.

Critério de aceite:

Problema central descrito em 2 frases sem jargão técnico
Quem usa o sistema e qual o job principal de cada tipo de usuário
Fluxo principal desenhado (não código — rascunho de tela ou diagrama)
Restrições de negócio mapeadas (LGPD, integrações obrigatórias, performance mínima)
“Definition of Done” aprovado pelo cliente e pelo Tech Human Lead

Entregável: documento P1 + aprovação do cliente por escrito (ou email)

P2 — Architecture

Duração: 3–5 dias
O que acontece: Tech Human Lead projeta a arquitetura com suporte do Architecture Agent. Define Bounded Contexts, módulos, contratos de API principais, modelo de dados.

Critério de aceite:

Bounded Contexts classificados e aprovados
Módulos definidos com responsabilidade única
Contrato das APIs principais (inputs, outputs, erros)
Modelo de dados com multi-tenancy por design
Decisões de arquitetura documentadas com justificativa (ADR — Architecture Decision Records)
Tech Human Lead aprova a arquitetura por escrito

Entregável: documento P2 de arquitetura + ADRs iniciais

P3 — Bootstrap

Duração: 2–3 dias
O que acontece: JARVIS configura o projeto completo — Foundation, CI/CD, banco de dados, ambiente de desenvolvimento e produção.

Critério de aceite:

Repositório criado com estrutura Clean Architecture validada
CI/CD rodando: push para main → deploy automático em produção
Health check em produção retornando 200 OK
Banco de dados com migrações rodando em produção
Multi-tenancy estrutural funcionando (schema ou row-level, conforme projeto)
Cobertura de testes do bootstrap: 100% (é código de configuração, não tem desculpa)

Entregável: URL de produção funcionando + link do repositório

P4 — MVP

Duração: 3–4 semanas
O que acontece: Squad executa o fluxo principal definido em P1. JARVIS gera implementações, Squad revisa, testa e integra.

Critério de aceite:

Fluxo principal funcionando end-to-end em produção com dados reais
TDD: cobertura de testes ≥ 80% (verificado automaticamente pelo JARVIS)
Zero critical issues de segurança (Security Reviewer validou)
Multi-tenancy funcionando: tenant A não vê dados do tenant B
Design partner (usuário real do cliente) usou o sistema sem assistência
Tech Human Lead executou code review final e aprovou

Entregável: acesso ao sistema + relatório de P4 para o cliente

P5 — Validation

Duração: 1–2 semanas
O que acontece: sistema rodando com usuários reais. Squad monitora, corrige bugs, ajusta performance.

Critério de aceite:

48h sem incidente crítico (uptime ≥ 99.5% no período)
P95 de tempo de resposta ≤ critério definido em P1
Zero dados de um tenant acessíveis por outro
Todos os fluxos de erro tratados (não 500 genérico)
Monitoramento e alertas configurados e testados
Documentação de onboarding para o time do cliente completa

Entregável: relatório de P5 + acesso ao dashboard de monitoramento

P6 — Launch

Duração: 1–3 dias
O que acontece: go-live oficial, onboarding do time do cliente, handoff formal.

Critério de aceite:

Primeiro pagamento recebido pelo produto (ou go-live oficial em produção com usuários reais)
Time do cliente operando o sistema sem assistência do Squad
Runbook de operação entregue (como fazer deploy, rollback, monitoramento)
Trust Score interno calculado (o próprio produto auditado pelo método TH)
Acordo de suporte pós-entrega assinado (ou Governança Contínua contratada)

Entregável: handoff formal + Trust Score do sistema entregue

Ritmos e cerimônias

Daily (assíncrono — NeedyU.ai)

Como: cada membro grava um loom de 2 min ou escreve 3 linhas no canal do projeto
O que cobre: o que foi feito, o que vai ser feito, bloqueadores
NeedyU.ai: todas as reuniões síncronas são gravadas e transcritas. Decisões ficam registradas automaticamente.
Quando: não existe daily presencial ou síncrona na Tech Human por padrão. O assíncrono é a norma.

Sprint Review com o cliente (a cada 2 semanas)

Duração: 45 minutos
Formato: demo do que foi entregue + próximos critérios de aceite apresentados
Quem participa: Tech Human Lead, PM, decisor do cliente (CEO ou gestor técnico)
Saída: aprovação explícita para continuar ou lista de ajustes antes de avançar
Registro: NeedyU.ai grava e transcreve. Decisões ficam como fonte de verdade.

Trust Score interno (a cada entrega de fase)

Antes de avançar de fase, o Tech Human Lead executa um mini-Trust Score interno:
- Cobertura de testes atingida?
- Segurança verificada?
- Multi-tenancy validado?
- Documentação em dia?
Se qualquer item vermelho: não avança.

Retrospectiva de projeto (ao final de P6)

Duração: 1 hora interna
O que cobre: o que o JARVIS entregou bem, onde houve retrabalho, o que ajustar no template para o próximo projeto
Saída: atualização do Foundation herdado (melhoria permanente para todos os projetos futuros)

Estrutura de custo e margem

Custo por projeto (estimativa Fase 1)

Componente	Tipo	Custo estimado
Tech Human Lead (P1→P6 ~8 semanas)	Salário / Pró-labore	R$20–28k
Squad Engineer PJ	Diária × dias trabalhados	R$12–18k
PM (parcial)	Horas × tarifa	R$6–10k
JARVIS (licença + infra)	Fixo por projeto	R$3k
Infra de produção (cloud)	Por mês	R$1–2k
Total de custo		R$42–61k

Margem por tier de projeto

Produto	Receita	Custo estimado	Margem bruta
Trust Score Laudo	R$5–12k	R$4–7k (audit only)	~40–50%
Trust Score Completo	R$20–50k	R$8–15k	~55–65%
TH Build / Squad Specialist (P1–P6)	R$60–150k	R$42–61k	~50–65%
Governança Contínua	R$15–35k/mês	R$8–14k/mês	~55–60%
CTO aaS retainer	R$8–20k/mês	R$4–8k/mês	~55–65%

O efeito composto do JARVIS na margem

# do produto no domínio	Esforço relativo	Custo relativo	Margem estimada
Produto 1	100%	R$55k	~50%
Produto 2	~20%	R$18k	~75%
Produto 3	~8%	R$10k	~85%
Produto N	→0%	→R$5k	→90%+

Implicação: cada produto Trustyu (co-build com equity) aumenta a margem de todos os projetos futuros no mesmo domínio. O moat cresce a cada entrega.

Como o Squad opera por tipo de engajamento

Diferença entre TH Build, Squad Specialist, Trustyu Forge e JARVIS

Camada	O que é	Quando aparece
TH Build	execução pós Trust Score ou Blueprint	produto/projeto Tech Human
Squad Specialist	time de execução puxado pelo CTO aaS	dentro da Porta C
Trustyu Forge	modelo operacional da Trustyu para validar sistemas, padrões e SaaS	venture client, co-build, M&A, equity
JARVIS	método técnico de execução com agentes, templates e critérios de aceite	por baixo de TH Build, Squad e Forge

Regra: Forge não substitui o Squad AI-augmented da Tech Human. Forge usa a mesma capacidade técnica e o JARVIS, mas com outro objetivo de negócio: transformar dores repetíveis em ativos escaláveis da Trustyu.

Trust Score (Porta A — audit only)

Quem: Tech Human Lead + analista de auditoria
JARVIS: não é usado para construir — é usado para analisar (documentação, comparação com padrões)
Duração: 5–21 dias
Entregável: relatório dual-audience + Trust Score 0–100

AI-First Blueprint (Porta B — framework)

Quem: PM + Tech Human Lead (consultoria, não engenharia)
JARVIS: não é usado para construir — é usado para gerar documentação de políticas e templates
Duração: 5–45 dias
Entregável: política publicável + roadmap + treinamento

TH Build (Porta A/B — execução pós-diagnóstico)

Quem: Tech Human Lead + Squad Engineer + PM
JARVIS: pleno — todas as 6 fases
Duração: 6–10 semanas por produto
Entregável: produto em produção com Trust Score interno ≥ 70/100

CTO aaS + Squad Specialist (Porta C)

Quem: CTO aaS (Fernando ou CTO Sênior) + Squad quando acionado
JARVIS: acionado na fase de execução (após diagnóstico)
Duração: CTO aaS = 6+ meses. Squad = por projeto dentro do engagement
Entregável: diagnóstico + roadmap + execução (quando cliente pede “vocês não têm uma equipe?”)

Trustyu Forge / co-build (equity)

Quem: Tech Human Lead + Squad Engineer + PM + founder do produto
JARVIS: pleno — Foundation customizado para o produto
Diferença: o Forge usa a Foundation herdada de produtos anteriores. O custo cai drasticamente.
Entregável: sistema operacional validado, produto SaaS P1→P6, PoC Venture Client ou ativo preparado para equity / exit

Onboarding de novo membro do squad

Semana 1 — Contexto

Acesso ao repositório do projeto e à documentação P1/P2
NeedyU.ai instalado e rodando (vai usar em todas as reuniões)
Leitura de todos os ADRs do projeto (Architecture Decision Records)
Assistir às gravações das últimas 2 Sprint Reviews via NeedyU.ai
Pair programming com Tech Human Lead por 2 dias antes de commitar

Critério de prontidão

Consegue explicar a arquitetura do projeto para um terceiro sem consultar documentação
Consegue rodar os testes localmente e fazer o CI/CD funcionar
Entende o critério de aceite da fase atual

Nota importante: em projetos via CTO aaS, o novo membro também recebe o contexto de negócio do cliente — não só o técnico. O NeedyU.ai garante que o histórico de decisões e reuniões está disponível desde o primeiro dia.

NeedyU.ai no Squad — como e quando usar

Situação	Como usar
Sprint Review com cliente	Gravar e transcrever automaticamente — nunca confiar em anotações manuais
Decisão de arquitetura	Registrar no canal + transcrição da reunião vira referência
Onboarding de novo membro	Acesso às gravações anteriores = ramp-up em dias, não semanas
Retrospectiva	Transcrição alimenta o relatório de retrospectiva automaticamente
CTO aaS com cliente	Todas as reuniões gravadas = histórico do engagement completo

Regra: se foi decidido numa reunião e não está no NeedyU.ai, não foi decidido.

Qualidade mínima inegociável

Independente do prazo, do cliente, do escopo ou da porta de entrada — estes itens nunca são negociáveis:

TDD ≥ 80% de cobertura de testes antes de qualquer entrega de fase
Multi-tenancy por design desde P3 — nunca retrofitado depois
Zero segredos no código — API keys, tokens, senhas sempre em variáveis de ambiente
CI/CD desde o primeiro commit — não existe “vamos configurar depois”
Trust Score interno ≥ 70/100 na entrega de P6 — o produto entregue passa pelo próprio método TH

Se um desses itens não for atingido, o projeto não avança para a próxima fase. Não existe exceção para prazo ou pressão do cliente.

Squad AI-augmented — v1.0 — 18 Abril 2026