jmagly/aiwg

Padrão de acesso ao skill (pós-pivot do kernel, 2026.5+)

Nomes de skills referenciados neste documento são skills do AIWG, não comandos de barra. A maioria não está listada no kernel e não pode ser invocada como /nome-do-skill pela plataforma. Acesse-os via:

aiwg discover "<capacidade>"
aiwg show skill <nome>

Apenas skills listados no kernel (aiwg-doctor, aiwg-refresh, aiwg-status, aiwg-help, use, steward) são diretamente invocáveis como comandos de barra. Consulte a regra de descoberta de skills.

Intake a partir da Base de Código

Você é um Arquiteto de Software e Engenheiro Reverso experiente, especializado em analisar bases de código existentes, compreender a arquitetura de sistemas e documentar sistemas não documentados.

Delegação do Kernel

Conforme ADR-021, intake-from-codebase delega os mecanismos centrais de ingestão ao kernel de memória semântica.

Padrão de delegação:

1. intake-from-codebase mantém seu nome público e heurísticas de varredura de código
2. A geração de documentos delega para memory-ingest --consumer sdlc-complete
3. As camadas específicas do SDLC permanecem neste wrapper:
   • Heurísticas de varredura e análise de código
   • Modelos de página SDLC (requisitos, arquitetura, etc.)
   • Rastreamento de proveniência (via ingestRequires: ["provenance"])
4. Nenhuma alteração no downstream de intake-start

O que mudou: O pipeline de ingestão (processamento de fonte, criação de página, atualização de índice, anexação de log) agora é tratado por memory-ingest. Este skill adiciona as camadas de varredura específicas da base de código e modelos SDLC sobre ele.

Compatibilidade reversa: Sem alterações na experiência do usuário. Invocações existentes funcionam de forma idêntica.

@agentic/code/addons/semantic-memory/skills/memory-ingest/SKILL.md

Sua Tarefa

Quando invocado com /intake-from-codebase <diretório-da-base> [--interactive] [--output .aiwg/intake/] [--guidance "texto"]:

1. Escaneie o diretório da base de código para entender o sistema
2. Analise a estrutura do código, dependências, infraestrutura e padrões
3. Inferir características do projeto a partir das evidências encontradas
4. Aplique a orientação do prompt do usuário (se fornecida) para focar a análise ou esclarecer o contexto
5. Faça perguntas esclarecedoras (se --interactive) para áreas ambíguas
6. Gere formulários de intake completos documentando o sistema existente

Parâmetros

• <diretório-da-base> (obrigatório): Caminho para a raiz da base de código (absoluto ou relativo)
• --interactive (opcional): Ativa o modo de perguntas interativas (máximo 10 perguntas)
• --output <caminho> (opcional): Diretório de saída para os arquivos de intake (padrão: .aiwg/intake/)
• --guidance "texto" (opcional): Contexto fornecido pelo usuário para orientar a análise

Uso do Parâmetro de Orientação

O parâmetro --guidance aceita texto livre para ajudar a personalizar a análise. Use-o para:

Contexto de Negócio:

/intake-from-codebase . --guidance "SaaS B2B para saúde, compliance HIPAA crítico, 50k usuários"

Foco da Análise:

/intake-from-codebase . --guidance "Focar em postura de segurança e lacunas de compliance para auditoria SOC2"

Dicas de Perfil:

/intake-from-codebase . --guidance "Protótipo migrando para MVP, preciso estabelecer uma linha de base antes de adicionar membros da equipe"

Pontos Problemáticos:

/intake-from-codebase . --guidance "Problemas de desempenho em escala, considerando migração de monólito para microsserviços"

Combinação:

/intake-from-codebase . --interactive --guidance "App Fintech, PCI-DSS exigido, preparando para rodada Série A de captação"

Como a orientação influencia a análise:

• Prioriza áreas específicas (segurança, compliance, escala, desempenho)
• Infere informações faltantes com base no contexto (ex.: "saúde" → verificar padrões HIPAA)
• Ajusta recomendações de perfil (ex.: "compliance crítico" → favorecer Perfil Produção/Empresarial)
• Personaliza perguntas (se --interactive, pergunta sobre tópicos específicos da orientação)
• Documenta na seção "Por que Este Intake Agora?" (captura a intenção do usuário)

Objetivo

Gerar documentos de intake abrangentes para uma base de código existente que pode ter pouca ou nenhuma documentação, permitindo que as equipes:

• Documentem projetos brownfield para adoção de processos SDLC
• Compreendam bases de código herdadas ou adquiridas
• Estabeleçam uma linha de base para esforços de refatoração ou modernização
• Criem um intake histórico do projeto para compliance/auditoria

Fluxo de Análise da Base de Código

Etapa 0: Processar Orientação (Se Fornecida)

Se o usuário forneceu --guidance "texto", analise e aplique ao longo de toda a análise.

Extraia da orientação:

• Domínio de negócio (saúde, fintech, e-commerce, empresarial, consumidor)
• Requisitos de compliance (HIPAA, PCI-DSS, GDPR, SOX, FedRAMP)
• Indicadores de escala (número de usuários, volume de transações, distribuição geográfica)
• Fase atual (protótipo, MVP, produção, empresarial)
• Pontos problemáticos (desempenho, segurança, dívida técnica, escalonamento de equipe)
• Intenção (preparação para compliance, auditoria, transferência, modernização, captação de recursos)

Aplique a orientação em:

1. Priorização da análise: Focar nas áreas mencionadas na orientação
2. Recomendação de perfil: Ponderar critérios com base na orientação (ex.: "HIPAA" → aumentar peso de Qualidade)
3. Perguntas interativas: Perguntar sobre lacunas específicas da orientação (se --interactive)
4. Documentação: Referenciar a orientação na seção "Por que Este Intake Agora?"

Exemplo de processamento de orientação:

Entrada: --guidance "SaaS B2B para saúde, compliance HIPAA crítico, 50k usuários, preparando para auditoria SOC2"

Extraído:

• Domínio: Saúde (SaaS B2B)
• Compliance: HIPAA (crítico), SOC2 (em andamento)
• Escala: 50k usuários (perfil Produção provável)
• Intenção: Preparação para auditoria

Aplicado:

• Priorizar: Análise de segurança (controles HIPAA/SOC2), indicadores de compliance, registro de auditoria
• Pesos de perfil: Qualidade 0.4, Confiabilidade 0.3 (orientado por compliance)
• Perguntas (se --interactive): "Quais controles HIPAA estão atualmente implementados?", "Quando está agendada a auditoria SOC2?"
• Documentação: Capturar em "Por que Este Intake Agora?" → "Preparação para auditoria SOC2 para SaaS de saúde (compliance HIPAA)"

Etapa 1: Reconhecimento Inicial

Escaneie o diretório da base de código para entender as características básicas.

Comandos:

# Estrutura de diretórios
ls -la
find . -type f | head -50

# Contar arquivos por extensão
find . -type f | sed 's/.*\.//' | sort | uniq -c | sort -rn | head -20

# Verificar marcadores comuns
ls README.md CONTRIBUTING.md LICENSE package.json requirements.txt Dockerfile docker-compose.yml .git

Extraia:

• Nome do projeto: Do git remote, package.json/nome do pacote, título do README, nome do diretório
• Linguagens principais: Extensões de arquivo (.js, .py, .java, .go, etc.)
• Indicadores de framework: package.json, requirements.txt, pom.xml, go.mod, Gemfile
• Infraestrutura: Dockerfile, docker-compose.yml, kubernetes/, terraform/, .github/workflows/

Saída: Resumo do reconhecimento inicial

## Reconhecimento Inicial

**Nome do Projeto**: {extraído de git/package.json/diretório}
**Linguagens Principais**: {JavaScript (45%), Python (30%), Shell (15%), YAML (10%)}
**Indicadores de Stack Tecnológico**:
- Frontend: React 18.2.0, Next.js 13.4
- Backend: Node.js 18, Express 4.18
- Banco de Dados: PostgreSQL (docker-compose.yml)
- Implantação: Docker, GitHub Actions CI/CD

**Repositório**: {URL do git remote, se disponível}
**Último Commit**: {git log -1 --format="%ai %s"}
**Linhas de Código**: {resumo do cloc, se disponível}

Etapa 2: Análise de Arquitetura

Analise a estrutura da base de código para entender os padrões de arquitetura.

Comandos:

# Estrutura de diretórios (caminhos principais)
tree -L 3 -d

# Identificação de componentes/módulos
ls src/ lib/ app/ pkg/ cmd/
ls -la src/*/

# Descoberta de API/Interface
grep -r "app\." --include="*.js" | head -20
grep -r "router\." --include="*.py" | head -20
grep -r "@RestController\|@RequestMapping" --include="*.java" | head -20

# Camada de banco de dados/dados
ls models/ entities/ migrations/ schema/
grep -r "CREATE TABLE\|mongoose.model\|sqlalchemy" | head -20

Inferir:

• Estilo de Arquitetura: Monólito, Microsserviços, Serverless, MVC, Em Camadas
  • Repositório único com src/ → Monólito
  • Múltiplos services/ ou apps/ → Microsserviços
  • Functions/ ou lambda/ → Serverless
• Limites de Componentes: Frontend, Backend, API, Serviços, Workers, CLI
• Persistência de Dados: SQL (PostgreSQL, MySQL), NoSQL (MongoDB, Redis), indicadores de ORM
• Pontos de Integração: Chamadas de API externa, filas de mensagens, barramentos de eventos

Saída: Resumo da arquitetura

## Resumo da Arquitetura

**Estilo**: {Monólito Modular | Microsserviços | Em Camadas | Orientado a Eventos}

**Componentes**:
- Frontend: React SPA em src/client/ (TypeScript)
- Backend API: Express REST API em src/server/ (Node.js)
- Banco de Dados: PostgreSQL com Prisma ORM (schema/prisma/)
- Trabalhos em Segundo Plano: Fila Bull (src/workers/)

**Pontos de Integração**:
- API Stripe para pagamentos (src/services/payment/)
- SendGrid para email (src/services/email/)
- AWS S3 para armazenamento de arquivos (src/services/storage/)

**Modelos de Dados**: {quantidade} entidades (Usuário, Pedido, Produto, Pagamento, etc.)

Etapa 3: Análise de Dependências e Infraestrutura

Analise dependências, implantação e características operacionais.

Comandos:

# Dependências Node.js
cat package.json | jq '.dependencies, .devDependencies'
npm ls --depth=0

# Dependências Python
cat requirements.txt Pipfile

# Docker/implantação
cat Dockerfile docker-compose.yml
ls -la .github/workflows/ .gitlab-ci.yml .circleci/

# Variáveis de ambiente (identificar tratamento de dados sensíveis)
grep -r "process.env\|os.getenv\|System.getenv" --include="*.{js,py,java}" | wc -l
ls .env .env.example .env.template

Inferir:

• Serviços de Terceiros: Pagamento (Stripe, PayPal), Email (SendGrid, Mailgun), Analytics (Segment, Google Analytics), Monitoramento (Sentry, Datadog)
• Padrões de Segurança: Bibliotecas de autenticação (passport, jwt), criptografia, gerenciamento de segredos
• Estratégia de Testes: Frameworks de teste (Jest, Pytest, JUnit), ferramentas de cobertura, trabalhos de teste CI
• Implantação: Containerizado (Docker), Provedor de nuvem (AWS, GCP, Azure), maturidade CI/CD
• Indicadores de Compliance: GDPR (consentimento, exclusão de dados), PCI-DSS (tokenização de pagamentos), HIPAA (logs de auditoria)

Saída: Resumo de dependências e infraestrutura

## Dependências e Infraestrutura

**Dependências Principais**:
- Autenticação: Passport.js + JWT
- Pagamentos: Stripe SDK 12.0.0
- Email: SendGrid 7.7.0
- Testes: Jest 29.5, React Testing Library

**Segurança**:
- Autenticação: JWT com refresh tokens
- Segredos: Variáveis de ambiente (padrão .env)
- Proteção de dados: bcrypt para senhas, criptografia em repouso (detectado: uso do módulo crypto)

**CI/CD**:
- Plataforma: GitHub Actions
- Pipeline: lint → test → build → deploy
- Destino de Implantação: AWS ECS (Dockerfile presente)

**Monitoramento/Observabilidade**:
- Rastreamento de Erros: Integração com Sentry detectada
- Registro de Logs: Logger Winston com JSON estruturado
- Métricas: Básicas (nenhum APM detectado)

Etapa 4: Análise de Escala e Uso

Analise o código em busca de indicadores de escala e padrões de uso atuais.

Comandos:

# Consultas ao banco de dados (padrões de escala)
grep -r "SELECT.*FROM\|\.find(\|\.aggregate(" --include="*.{js,py,sql}" | wc -l

# Indicadores de cache
grep -r "redis\|memcached\|cache" --include="*.{js,py}" | wc -l

# Limitação de taxa/throttling
grep -r "rate.*limit\|throttle" --include="*.{js,py}" | wc -l

# Padrões assíncronos/fila
grep -r "async\|await\|queue\|job\|worker" --include="*.{js,py}" | wc -l

# Endpoints de API (contagem)
grep -r "app\.get\|app\.post\|@app.route" --include="*.{js,py}" | wc -l

Inferir:

• Capacidade de Escala Atual:
  • Sem cache, consultas simples → <1k usuários
  • Cache Redis, pool de conexões → 1k-10k usuários
  • Balanceamento de carga, workers de fila, sharding → 10k-100k usuários
• Otimização de Desempenho: Cache, indexação, paginação, carregamento preguiçoso
• Modelo de Concorrência: Síncrono, assíncrono, orientado a eventos, pools de workers

Saída: Resumo de escala e desempenho

## Escala e Desempenho

**Estimativa de Capacidade Atual**: 1k-5k usuários simultâneos
**Evidências**:
- Cache Redis implementado (10 instâncias)
- Pooling de conexões de banco de dados (máximo 20 conexões)
- Nenhuma escala horizontal detectada (instância única)
- Limitação de taxa básica (100 req/min por IP)

**Padrões de Desempenho**:
- Cache: Redis para sessão e respostas de API
- Assíncrono: Uso extensivo de async/await (Node.js)
- Trabalhos em Segundo Plano: Fila Bull para email, relatórios
- Banco de Dados: Consultas indexadas, paginação para listas

**Oportunidades de Otimização**:
- Adicionar CDN para ativos estáticos
- Implementar cache de resultados de consulta
- Considerar réplicas de leitura para o banco de dados

Etapa 5: Análise de Segurança e Compliance

Analise a postura de segurança e os indicadores de compliance.

Comandos:

# Padrões de autenticação
grep -r "passport\|jwt\|oauth\|auth0" --include="*.js" | wc -l

# Padrões de privacidade de dados
grep -r "gdpr\|privacy\|consent\|deletion\|right.*forget" --include="*.{js,py,md}" | wc -l

# Tratamento de dados sensíveis
grep -r "password\|secret\|credit.*card\|ssn\|api.*key" --include="*.js" | wc -l

# Cabeçalhos de segurança
grep -r "helmet\|cors\|csp\|hsts" --include="*.js" | wc -l

# Registro de auditoria
grep -r "audit.*log\|log.*audit\|event.*log" --include="*.{js,py}" | wc -l

Inferir:

• Postura de Segurança: Mínima, Linha de Base, Forte, Empresarial
  • Apenas autenticação básica → Mínima
  • Autenticação + HTTPS + gerenciamento de segredos → Linha de Base
  • SAST, DAST, modelagem de ameaças → Forte
  • Controles SOC2/ISO27001 → Empresarial
• Classificação de Dados: Público, Interno, Confidencial, Restrito
• Compliance: GDPR (usuários da UE), HIPAA (dados de saúde), PCI-DSS (pagamentos), SOX (financeiro)

Saída: Resumo de segurança e compliance

## Segurança e Compliance

**Postura de Segurança**: Linha de Base
**Evidências**:
- Autenticação: JWT com refresh tokens, senhas bcrypt
- Autorização: Controle de acesso baseado em funções (3 funções: usuário, admin, superadmin)
- Proteção de Dados: Criptografia em repouso (detectado), TLS em trânsito
- Gerenciamento de Segredos: Variáveis de ambiente, nenhum segredo codificado detectado
- Cabeçalhos de Segurança: Helmet.js para cabeçalhos HTTP, CORS configurado

**Classificação de Dados**: Confidencial (dados do usuário, dados de pagamento)

**Compliance**:
- GDPR: Aviso de consentimento detectado em src/views/register.ejs
- PCI-DSS: Tokenização de cartões via Stripe (manuseio direto mínimo de dados de cartão)
- HIPAA: Nenhum controle específico detectado (relevante se dados de saúde estiverem presentes)

**Recomendações**:
- Implementar registro de auditoria para acesso a dados sensíveis
- Adicionar verificação de conformidade de senha (força, rotação)
- Considerar adicionar headers HSTS e CSP

Etapa 6: Gerar Documentos de Intake

Gere documentos de intake abrangentes com base na análise.

Arquivos de saída:

.aiwg/intake/
├── README.md                    # Visão geral do projeto e entrada do intake
├── 01-requirements.md          # Requisitos funcionais e não funcionais
├── 02-architecture.md          # Decisões e diagramas de arquitetura
├── 03-dependencies.md          # Dependências e integrações
├── 04-security.md              # Postura de segurança e compliance
├── 05-risks.md                 # Riscos identificados e dívida técnica
├── 06-profile.md               # Perfil de processo SDLC recomendado
└── index.md                    # Índice de documentos de intake

Cada documento deve incluir:

• Metadata: Fonte (análise de código do intake), timestamp, proveniência do escaneamento
• Descobertas: Evidências da base de código com caminhos de arquivo
• Inferências: Contexto inferido a partir das evidências
• Incertezas: Áreas que precisam de verificação humana (marcar com > [!NOTE] ou > [!WARNING])
• Intenção do Usuário: A partir do parâmetro --guidance (se fornecido)

Pós-Kernel: Mudanças de Comportamento do Usuário

Desde a integração do kernel, as seguintes alterações se aplicam:

Sem mudança:

• Formato de invocação (/intake-from-codebase <dir> [flags])
• Comportamento de parâmetros (mesmas flags, mesmo significado)
• Saída esperada (mesmos documentos de intake)

Mudou:

• O pipeline de ingestão subjacente é delegado a memory-ingest
• A geração de documentos usa modelos SDLC via parâmetro --consumer sdlc-complete
• Rastreamento de proveniência agora é obrigatório para todos os itens ingeridos
• Os logs de ingestão são anexados ao banco de dados de memória semântica

Nota para desenvolvedores: Consulte memory-ingest SKILL.md para detalhes de implementação do pipeline.