LogikeDev · Portal de Desenvolvimento

Bem-vindo ao

LogikeDev · Modelo de Desenvolvimento

Método de trabalho agnóstico de linguagem, orientado a processo e acelerado por IA. Equipe de backend em transição de sistemas legados para plataforma online unificada com PostgreSQL.

◎

As 6 Etapas

Do levantamento de requisitos aos testes — cada etapa com entradas, saídas e artefatos definidos.

Ver etapas →

□

Templates e Artefatos

BRS, FTS, AI Context Pack, API Contract YAML — templates prontos para copiar e usar.

Ver templates →

⚙

Ferramentas

Trello, Notion, PlantUML, GitHub — gratuitas, sem lock-in, com links diretos de acesso.

Ver ferramentas →

🎓

Trilha de Aprendizado

6 módulos de Engenharia de Software com vídeos, tarefas práticas e progresso sincronizado.

Abrir trilha →

Spec-Driven Development (SDD)

· Metodologia base

O Modelo Lógike é uma implementação do SDD adaptada para equipes com sistemas legados e uso de IA. Cada fase do SDD tem correspondência direta com as etapas e artefatos do modelo.

Constituição

constitution.md

→ AI Context Pack §5
→ Padrões da equipe
→ Stack tecnológica

Especificação

spec.md

→ BRS (negócio)
→ FTS (técnico)
→ API Contract YAML

Planejamento

tasks atômicas

→ FTS §2 fluxo
→ Test Plan
→ Cards no Trello

Implementação

IA + código

→ AI Context Pack
→ Codificação assistida
→ Etapa 4

Verificação

testes + review

→ Code Review
→ Test Report
→ Etapas 5 e 6

Ciclo completo do Modelo Lógike

1 · Análise de requisitos

→

2 · Modelagem e design

→

3 · Contexto para IA

→

4 · Codificação assistida

→

5 · Revisão e integração

→

6 · Testes e validação

Camada 1: Negócio · Camada 2: Execução com IA · Camada 3: Qualidade · Legado realimenta a Etapa 1 continuamente.

Modelo Lógike

Princípios fundamentais

Os princípios que guiam todas as decisões do modelo — do levantamento de requisitos ao uso de IA.

1

Agnóstico de linguagem

Os artefatos não dependem da linguagem de programação. A transição WLanguage → Python não exige refazer a documentação de negócio. Apenas o AI Context Pack e o Code Checklist precisam ser atualizados.

2

Conhecimento explícito, não tácito

O maior risco com sistemas legados é o conhecimento que existe apenas na cabeça de quem escreveu o código. O modelo exige que regras de negócio sejam registradas antes de qualquer codificação.

3

IA como acelerador, não como substituto

A IA entra apenas após análise e modelagem. Sem contexto adequado, produz código genérico. Com um AI Context Pack bem construído, torna-se um colaborador preciso e eficiente.

4

Burocracia mínima viável

Cada etapa produz exatamente um ou dois artefatos curtos. Um desenvolvedor deve conseguir preparar o contexto completo de uma feature em menos de uma hora.

5

Legado como fonte de verdade

Os sistemas WinDev, VFP e os bancos DBF/HFSQL guardam décadas de regras de negócio. Recursos já desenvolvidos são a primeira fonte de requisitos — não um obstáculo a contornar.

6

Postgres como banco central

Toda migração converge para PostgreSQL. O schema Postgres é a fonte de verdade para o AI Context Pack — exportar o DDL das tabelas é parte obrigatória da preparação de contexto para a IA.

Modelo Lógike

As 6 etapas

Cada etapa tem entradas definidas, atividades específicas, artefatos de saída e critério de conclusão claro.

1

Análise de requisitos

Camada 1 · Negócio · BRS + Glossário · 1–4 horas

Etapa 1▼

Fontes de requisito

Recursos já desenvolvidos no legado (WinDev/VFP)
Tickets do suporte técnico interno
Legislação e normas regulatórias
Decisão interna de produto

Protocolo de extração do legado

Ler o código como arqueólogo — descrever, não julgar
Mapear cada IF/CASE como regra de negócio
Registrar tabelas DBF/HFSQL e campos utilizados
Validar com tickets de suporte como proxy do usuário

📄 BRS📄 Glossário de domínio

🔍

Engenharia Reversa com Claude Code — quando há código legado

Legado WL/VFP

Quando a feature já existe nos sistemas legados (WinDev/WLanguage ou Visual FoxPro), o Claude Code pode fazer a leitura do código antigo e gerar automaticamente o rascunho do BRS e do FTS — eliminando o trabalho manual de decifrar código estruturado complexo. Para features novas (via suporte ou decisão de produto), o fluxo normal de análise se aplica.

Entradas para o Claude Code

→ Código .wl (WLanguage) ou .prg/.scx (VFP)
→ Estrutura das tabelas DBF ou HFSQL
→ Nome do módulo / funcionalidade

Saídas geradas

→ BRS rascunho com regras extraídas
→ FTS rascunho com entidades mapeadas
→ Sugestão de schema PostgreSQL
→ Glossário de domínio inicial

⚠ Artefatos gerados por engenharia reversa são sempre rascunhos — um desenvolvedor que conhece o sistema deve revisar e validar antes de usar como base para a nova implementação.

🔍 Ver prompt de engenharia reversa nos Artefatos →

Critério de saída: BRS com ao menos 3 critérios de aceite no formato Dado/Quando/Então e campo "Fonte da demanda" preenchido.

📋

SDD · Fase: Especificação — O BRS é a camada de negócio do spec.md. Define o comportamento esperado em linguagem natural antes de qualquer decisão técnica. No SDD puro, esta fase é imutável após aprovação.

2

Modelagem e design

Camada 1 · Negócio · FTS + API Contract · 2–4 horas

Etapa 2▼

Artefatos de saída

FTS — Feature Technical Sheet
API Contract YAML — contrato do endpoint
Glossário atualizado com termos técnicos
Fluxo técnico descritivo em Markdown

A mudança mais importante

Swagger YAML gerado ANTES do código
Frontend desenvolve em paralelo
IA recebe contrato preciso para gerar código
Integração sem surpresas na etapa 5

📄 FTS📄 API Contract YAML

Critério de saída: API Contract aprovado. FTS com entidades mapeadas no schema PostgreSQL.

📐

SDD · Fase: Especificação + Planejamento — O FTS é a camada técnica do spec.md. O API Contract YAML é a especificação executável do endpoint. O FTS §2 (fluxo técnico) equivale ao planejamento em tarefas atômicas do SDD.

3

Contexto para IA

Camada 2 · Execução · AI Context Pack · 30–60 min

Etapa 3▼

Por que esta etapa existe

A IA não tem memória entre conversas
Sem contexto, produz código genérico
Com Context Pack: colaborador preciso
DDL do Postgres = ouro para a IA

Seções do AI Context Pack

1. Identidade da feature
2. Contrato YAML do endpoint
3. DDL das tabelas Postgres
4. Regras de negócio do BRS
5. Padrões e convenções da equipe
6. Contexto do legado (se aplicável)

📄 AI Context Pack

Regra de ouro: A IA é tão boa quanto o contexto fornecido. Context Pack bem preenchido = código que precisa de poucos ajustes.

⚙

SDD · Fase: Constituição + Implementação — A seção 5 do AI Context Pack (Padrões da equipe) é o constitution.md do SDD — define as regras imutáveis de código, arquitetura e padrões. As seções 1–4 completam a spec para a IA implementar.

4

Codificação assistida

Camada 2 · Execução · Código + Change Log

Etapa 4▼

Fluxo dev + IA

Dev abre sessão com IA + AI Context Pack
IA gera o código do endpoint
Dev revisa e aplica o Code Checklist
Ciclo se repete até a feature estar completa

Code Checklist — verificar sempre

Nomes de tabelas/colunas corretos (schema PG)
Todas as RN do BRS implementadas
Tratamento de erros conforme padrão
Estrutura de resposta da API correta

Convenção de branch: feature/BRS-2025-014-nome-da-feature

🤖

SDD · Fase: Implementação — O agente de IA (Claude) recebe o AI Context Pack completo e executa as tarefas definidas no planejamento. O dev atua como verificador imediato — revisa cada geração antes de avançar.

5

Revisão e integração

Camada 3 · Qualidade · Review Log + Swagger validado

Etapa 5▼

Atividades de revisão

Code review via Pull Request no GitHub
Code Checklist aplicado pelo revisor
Atualização e publicação do Swagger YAML
Alinhamento com equipe de frontend

Quem revisa o quê

Dev sênior: lógica + arquitetura
Qualquer dev: padrões + nomenclatura
Frontend: contrato de API + comportamento

Gatilho: O Pull Request é o gatilho formal da Etapa 5. Nenhum código vai para a branch principal sem review.

🔍

SDD · Fase: Verificação (parte 1) — O code review verifica se a implementação está conforme a spec.md (BRS + FTS). O checklist de revisão deve incluir: "Todas as RN do BRS foram implementadas?" e "O contrato YAML está sendo respeitado?"

6

Testes e validação

Camada 3 · Qualidade · Test Plan + Test Report

Etapa 6▼

Tipos de teste

Unitário — funções e métodos isolados
Integração — módulos + banco Postgres
API — endpoints contra o contrato YAML
Homologação — critérios de aceite do BRS

Conexão BRS → Testes

Cada CA-XX do BRS vira um caso de teste
Test Plan derivado diretamente do BRS
Test Report fecha o ciclo da feature
Rastreabilidade: requisito → código → teste

📄 Test Plan📄 Test Report

Critério de saída: Todos os CA do BRS marcados como verificados no Test Report.

✅

SDD · Fase: Verificação (completo) — Os testes verificam que a implementação cumpre exatamente o que foi especificado no BRS. No SDD, a spec é o contrato — o Test Report confirma que o contrato foi cumprido. CA sem teste correspondente = spec não verificada.

Modelo Lógike

Artefatos e Templates

Todos os templates prontos para uso. Clique em cada card para expandir e copiar direto para o Notion ou editor de texto. Os artefatos seguem a ordem natural das etapas do modelo.

📄

BRS — Business Requirements Sheet

O QUÊ e POR QUÊ · Linguagem de negócio · Etapa 1

Etapa 1 ▼

· spec.md — camada de negócio

Responde: O QUÊ e POR QUÊ. Linguagem de negócio, sem tecnologia. Fonte pode ser legado, suporte, legislação ou produto. Cada feature tem exatamente um BRS.

Quando criar

Antes de qualquer modelagem ou código. O BRS é o ponto de partida de todas as etapas seguintes.

Fontes de entrada

Código legado (WL/VFP), tickets de suporte, legislação, decisão interna de produto.

Critério de saída da Etapa 1: BRS com ao menos 3 critérios de aceite no formato Dado/Quando/Então e campo "Fonte da demanda" preenchido.

BRS-template.md

# BRS — Business Requirements Sheet ID: BRS-[ano]-[sequencial] Feature: [nome curto e descritivo] Módulo: [módulo do sistema] Data: [dd/mm/aaaa] Responsável: [nome] Origem: Legado | Suporte | Legislação | Produto Status: Rascunho | Em revisão | Aprovado ## 1. Contexto [2-4 frases: qual problema resolve?] ## 2. Fonte da demanda - Ticket(s) de suporte: [número se houver] - Base legal / norma: [referência se aplicável] - Comportamento no legado: [sistema + o que faz hoje] ## 3. Atores | Ator | Papel | |------------|---------------------------------| | [perfil] | [o que faz com esta feature] | ## 4. Regras de negócio - RN-01: [regra] - RN-02: [regra] ## 5. Critérios de aceite - CA-01: Dado [ctx], quando [ação], então [resultado] - CA-02: Dado [ctx], quando [ação], então [resultado] ## 6. Fora do escopo - [o que esta feature NÃO faz] ## 7. Dependências - Tabelas Postgres afetadas: [nomes] --- Aprovado por: ___________ Data: ___/___/______

📄

FTS — Feature Technical Sheet

COMO implementar · Entidades, fluxo e arquitetura · Etapa 2

Etapa 2 ▼

· spec.md — camada técnica

Responde: COMO implementar. Entidades, fluxo técnico e decisões de arquitetura. Gerado a partir do BRS — é a ponte entre o requisito de negócio e o código.

Diferença do BRS

BRS = negócio (o quê). FTS = técnico (como). Um não substitui o outro — os dois são necessários.

Atenção à sigla

FTS = Feature Technical Sheet. Não confundir com TDD (Test-Driven Development), que é uma prática de testes.

FTS-template.md

# FTS — Feature Technical Sheet ID: FTS-[ano]-[sequencial] BRS de origem: BRS-[ano]-[sequencial] Feature: [nome] Data: [dd/mm/aaaa] ## 1. Entidades envolvidas | Tabela Postgres | Operações | Observações | |-----------------|-----------|----------------| | tb_[nome] | R, U | [observação] | ## 2. Fluxo técnico 1. API recebe [MÉTODO] /[rota] 2. Valida autenticação 3. [operação no banco] 4. Aplica RN-XX do BRS 5. Retorna [status] com [payload] ## 3. Decisões técnicas - Banco: PostgreSQL — schema [nome] - Migração do legado: [estratégia] - Tratamento de erros: [padrão da equipe] ## 4. Documentação complementar - Spec markdown: [link para o .md de especificação se houver] - Fluxo descritivo: [descreva o fluxo em texto se necessário] ## 5. API Contract - Arquivo: [link para o YAML]

📄

API Contract — YAML (Swagger/OpenAPI)

Contrato do endpoint · Gerado ANTES do código · Etapa 2

Etapa 2 ▼

· spec.md — especificação executável

Define rota, método HTTP, parâmetros, body e todas as respostas. Gerado ANTES do código — o frontend desenvolve em paralelo e a IA tem especificação precisa para implementar.

Regra do Modelo Lógike: nenhum endpoint é codificado sem ter um bloco YAML aprovado. O Swagger que a equipe já usa passa a ser gerado na Etapa 2 — não após a codificação.

api-contract.yaml

openapi: "3.0.3" info: title: "[Nome do Sistema] API" version: "1.0.0" description: "API do sistema LogikeDev" servers: - url: "https://api.suaempresa.com.br/v1" description: "Produção" - url: "http://localhost:8080/api/v1" description: "Desenvolvimento local" # ───────────────────────────────────────────── # TEMPLATE DE ENDPOINT — duplique para cada rota # ───────────────────────────────────────────── paths: /[recurso]: get: summary: "Listar [recursos]" description: "Retorna lista de [recursos] com filtros opcionais" operationId: "listar[Recurso]" tags: - "[Módulo]" parameters: - name: pagina in: query required: false schema: type: integer default: 1 description: "Número da página" - name: limite in: query required: false schema: type: integer default: 20 description: "Itens por página" responses: "200": description: "Lista retornada com sucesso" content: application/json: schema: type: object properties: ok: type: boolean example: true dados: type: array items: $ref: "#/components/schemas/[Recurso]" total: type: integer example: 42 pagina: type: integer example: 1 "401": $ref: "#/components/responses/NaoAutenticado" "500": $ref: "#/components/responses/ErroInterno" post: summary: "Criar [recurso]" description: "Cria um novo [recurso] no sistema" operationId: "criar[Recurso]" tags: - "[Módulo]" requestBody: required: true content: application/json: schema: $ref: "#/components/schemas/[Recurso]Criar" responses: "201": description: "Recurso criado com sucesso" content: application/json: schema: type: object properties: ok: type: boolean example: true id: type: string format: uuid mensagem: type: string example: "[Recurso] criado com sucesso" "400": $ref: "#/components/responses/DadosInvalidos" "401": $ref: "#/components/responses/NaoAutenticado" "409": $ref: "#/components/responses/Conflito" "500": $ref: "#/components/responses/ErroInterno" /[recurso]/{id}: get: summary: "Buscar [recurso] por ID" operationId: "buscar[Recurso]" tags: - "[Módulo]" parameters: - name: id in: path required: true schema: type: string format: uuid description: "ID único do [recurso]" responses: "200": description: "Recurso encontrado" content: application/json: schema: $ref: "#/components/schemas/[Recurso]" "404": $ref: "#/components/responses/NaoEncontrado" put: summary: "Atualizar [recurso]" operationId: "atualizar[Recurso]" tags: - "[Módulo]" parameters: - name: id in: path required: true schema: type: string format: uuid requestBody: required: true content: application/json: schema: $ref: "#/components/schemas/[Recurso]Atualizar" responses: "200": description: "Atualizado com sucesso" content: application/json: schema: type: object properties: ok: type: boolean mensagem: type: string "400": $ref: "#/components/responses/DadosInvalidos" "404": $ref: "#/components/responses/NaoEncontrado" delete: summary: "Remover [recurso]" operationId: "remover[Recurso]" tags: - "[Módulo]" parameters: - name: id in: path required: true schema: type: string format: uuid responses: "200": description: "Removido com sucesso" content: application/json: schema: type: object properties: ok: type: boolean mensagem: type: string "404": $ref: "#/components/responses/NaoEncontrado" # ───────────────────────────────────────────── # SCHEMAS — modelos de dados reutilizáveis # ───────────────────────────────────────────── components: schemas: [Recurso]: type: object properties: id: type: string format: uuid readOnly: true example: "550e8400-e29b-41d4-a716-446655440000" [campo1]: type: string description: "[Descrição do campo — usar termos do Glossário de Domínio]" example: "[valor de exemplo]" [campo2]: type: integer description: "[Descrição]" example: 1 ativo: type: boolean default: true created_at: type: string format: date-time readOnly: true [Recurso]Criar: type: object required: - [campo1] - [campo2] properties: [campo1]: type: string [campo2]: type: integer [Recurso]Atualizar: type: object properties: [campo1]: type: string [campo2]: type: integer # ─── RESPOSTAS DE ERRO PADRONIZADAS ─────── responses: NaoAutenticado: description: "Token ausente ou inválido" content: application/json: schema: type: object properties: ok: type: boolean example: false erro: type: string example: "Não autenticado" DadosInvalidos: description: "Dados de entrada inválidos ou incompletos" content: application/json: schema: type: object properties: ok: type: boolean example: false erro: type: string example: "Campo [campo] é obrigatório" campos: type: array items: type: string example: ["campo1", "campo2"] NaoEncontrado: description: "Recurso não encontrado" content: application/json: schema: type: object properties: ok: type: boolean example: false erro: type: string example: "[Recurso] não encontrado" Conflito: description: "Conflito — recurso já existe" content: application/json: schema: type: object properties: ok: type: boolean example: false erro: type: string example: "[Recurso] já cadastrado" ErroInterno: description: "Erro interno do servidor" content: application/json: schema: type: object properties: ok: type: boolean example: false erro: type: string example: "Erro interno — contate o administrador" # ─── SEGURANÇA ──────────────────────────── securitySchemes: BearerToken: type: http scheme: bearer bearerFormat: JWT description: "Token retornado no login" security: - BearerToken: []

📄

AI Context Pack

Contexto completo para a IA · DDL + BRS + contrato · Etapa 3

Etapa 3 ▼

· constitution.md §5 + implementação IA

O artefato mais estratégico do modelo. Cole o DDL do Postgres — é o elemento mais valioso para a IA. Reúne tudo que a IA precisa para gerar código preciso: contrato, banco, regras e padrões.

Regra de ouro

A IA é tão boa quanto o contexto fornecido. Context Pack bem preenchido = código que precisa de poucos ajustes.

Na migração WL → Python

Apenas a seção 5 (Padrões) precisa ser atualizada. Todo o resto — BRS, FTS, DDL, regras — permanece idêntico.

ai-context-pack.md

# AI Context Pack Feature: [nome] BRS: BRS-[ano]-[sequencial] Linguagem: WLanguage (WinDev PCSOFT) ## 1. Identidade da feature [2 frases: o que faz, quem usa, qual problema resolve] ## 2. Contrato da operação (YAML) [Cole o trecho YAML do endpoint] ## 3. Schema do banco (DDL Postgres) CREATE TABLE tb_[nome] ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), [campo] [tipo] [constraints], created_at TIMESTAMPTZ DEFAULT NOW() ); ## 4. Regras de negócio (do BRS) - RN-01: [regra] - RN-02: [regra] ## 5. Padrões da equipe - Nomenclatura: [padrão] - Tratamento de erros: [padrão] - Resposta da API: [padrão JSON] ## 6. Contexto do legado - Sistema: [WinDev / VFP] - O que muda: [diferença] --- [PROMPT BASE] Você é dev sênior especialista em WLanguage (WinDev PCSOFT). Implemente o endpoint conforme o contrato acima. Respeite TODAS as regras de negócio. Use EXATAMENTE os nomes do schema fornecido. Siga os padrões da seção 5. Retorne apenas o código.

📄

Test Plan — Plano de Testes

Casos de teste derivados dos CA do BRS · Etapa 6

Etapa 6 ▼

· verificação — planejamento de testes

Define o que será testado e como. Cada caso de teste rastreia diretamente a um critério de aceite (CA-XX) do BRS. Um BRS bem escrito torna a escrita do Test Plan quase automática.

Rastreabilidade: CA-01 do BRS → CT-001 do Test Plan → linha no Test Report. Cadeia completa: requisito → implementação → resultado validado.

test-plan-template.md

# Test Plan ID: TP-[ano]-[sequencial] BRS de origem: BRS-[ano]-[sequencial] FTS de origem: FTS-[ano]-[sequencial] Feature: [nome] Data: [dd/mm/aaaa] Responsável: [nome] Ambiente: Desenvolvimento | Homologação | Produção Status: Pendente | Em execução | Concluído --- ## 1. Objetivo [O que será testado e qual o critério de sucesso geral. Ex: Validar que o endpoint POST /competencia/calcular implementa corretamente as RN-01 a RN-03 do BRS-2025-014.] ## 2. Escopo ### Incluído - [o que será testado] - [endpoint / módulo / fluxo] ### Excluído - [o que NÃO será testado neste ciclo] ## 3. Casos de teste ### CT-001 — [nome descritivo do caso] - **Critério de aceite:** CA-01 do BRS-[id] - **Pré-condição:** [estado do sistema antes do teste] - **Entrada:** [dados de entrada / payload] - **Ação:** [o que será executado — ex: POST /competencia/calcular] - **Resultado esperado:** [o que deve acontecer] - **Resultado obtido:** [preencher durante execução] - **Status:** Pendente | Passou | Falhou ### CT-002 — [nome descritivo do caso] - **Critério de aceite:** CA-02 do BRS-[id] - **Pré-condição:** [estado] - **Entrada:** [dados] - **Ação:** [ação] - **Resultado esperado:** [resultado] - **Resultado obtido:** [preencher] - **Status:** Pendente | Passou | Falhou ### CT-003 — Caso de erro — [descrição] - **Critério de aceite:** CA-03 do BRS-[id] - **Pré-condição:** [estado] - **Entrada:** [dados inválidos / ausentes] - **Ação:** [ação] - **Resultado esperado:** HTTP 400 com mensagem "[mensagem esperada]" - **Resultado obtido:** [preencher] - **Status:** Pendente | Passou | Falhou ## 4. Ferramentas de teste - [ ] Postman / Insomnia (teste de API) - [ ] Teste manual via interface - [ ] Script automatizado ## 5. Critério de conclusão Todos os CTs com status "Passou" e nenhum CA do BRS sem caso de teste correspondente.

📄

Test Report — Relatório de Testes

Resultado dos testes · Fecha o ciclo da feature · Etapa 6

Etapa 6 ▼

· verificação — confirmação da spec

Registra o resultado de cada caso de teste e a decisão final sobre a feature. É o documento que autoriza a entrega. Sem Test Report aprovado, a feature não vai para produção.

Critério de saída da Etapa 6: todos os CA do BRS marcados como "Passou". Defeitos críticos abertos bloqueiam a entrega — devem ser corrigidos e retestados.

test-report-template.md

# Test Report ID: TR-[ano]-[sequencial] Test Plan: TP-[ano]-[sequencial] BRS de origem: BRS-[ano]-[sequencial] Feature: [nome] Data início: [dd/mm/aaaa] Data fim: [dd/mm/aaaa] Executado por: [nome] Ambiente: Desenvolvimento | Homologação | Produção --- ## 1. Resumo executivo | Métrica | Valor | |----------------------|----------| | Total de casos | [N] | | Passou | [N] | | Falhou | [N] | | Bloqueado | [N] | | Taxa de sucesso | [%] | | Feature aprovada? | Sim | Não| ## 2. Resultado por caso de teste | ID | Descrição | CA ref. | Status | Observação | |--------|----------------------------|----------|---------|-------------------------| | CT-001 | [descrição] | CA-01 | Passou | — | | CT-002 | [descrição] | CA-02 | Passou | — | | CT-003 | Caso de erro — [descrição] | CA-03 | Falhou | [descrever o que errou] | ## 3. Defeitos encontrados ### DEF-001 — [título do defeito] - **Caso de teste:** CT-003 - **Severidade:** Crítica | Alta | Média | Baixa - **Descrição:** [o que aconteceu] - **Evidência:** [print / log / request-response] - **Status:** Aberto | Em correção | Corrigido | Fechado - **BRS relacionado:** BRS-[id] · CA-[id] ## 4. Conclusão ### Feature pode ser entregue? - [ ] Sim — todos os critérios de aceite verificados - [ ] Não — defeitos críticos pendentes (ver seção 3) - [ ] Parcial — entrega com ressalvas documentadas ### Ressalvas (se houver) [Descrever funcionalidades com comportamento aceito provisoriamente e prazo para correção definitiva] ### Aprovação Testado por: ___________ Data: ___/___/______ Aprovado por: __________ Data: ___/___/______

📖

Glossário de Domínio

Termos do negócio com definições precisas · Documento vivo · Todas as etapas

Contínuo ▼

· constitution.md — vocabulário do domínio

Diferente do BRS — que é por feature — o glossário é da empresa e nunca termina. Cresce a cada nova feature. Evita que a mesma palavra signifique coisas diferentes para o dev, o usuário e a IA.

Por que importa para a IA

Cole os termos no AI Context Pack. A IA entende "competência" como mês de referência — não como habilidade profissional.

Fluxo de uso

Ao escrever um BRS, cada termo do domínio deve existir no glossário. Se não existir — adicione antes de continuar.

glossario-dominio.md

# Glossário de Domínio — [Nome do Sistema]

Documento vivo. Atualizar sempre que um novo termo surgir.
Última atualização: [dd/mm/aaaa]

---

## Tabela principal

| Termo           | Definição no sistema                        | Sinônimos no legado      | Tabela Postgres       | BRS relacionado  |
|-----------------|---------------------------------------------|--------------------------|-----------------------|------------------|
| Competência     | Mês e ano de referência dos cálculos        | Período, referência, mês | tb_competencia        | BRS-2025-001     |
| Lançamento      | Registro financeiro de um evento ocorrido   | Movimento, entrada       | tb_lancamento         | BRS-2025-003     |
| Beneficiário    | Pessoa física que recebe o serviço          | Cliente, usuário, titular| tb_beneficiario       | BRS-2025-002     |
| Proporcional    | Cálculo dividido pelos dias úteis do mês    | Fracionado, parcial      | —                     | BRS-2025-005     |
| Vigência        | Período em que uma regra está ativa         | Validade, período ativo  | —                     | BRS-2025-007     |
| Rubrica         | Categoria de um lançamento financeiro       | Tipo, código, verba      | tb_rubrica            | BRS-2025-003     |
| [Termo]         | [Definição precisa no contexto do sistema]  | [Nome no legado WL/VFP]  | [tb_nome ou —]        | [BRS-id]         |

---

## Orientações de preenchimento

DEFINIÇÃO NO SISTEMA
Escreva como se a pessoa lendo nunca tivesse visto o sistema.
Evite usar o próprio termo na definição.

Exemplo RUIM:  "Competência é a competência do mês"
Exemplo BOM:   "Competência é o mês e ano de referência usado nos
               cálculos. Ex: competência 03/2025 = março de 2025."

SINÔNIMOS NO LEGADO
Liste TODOS os nomes que esse conceito já teve nos sistemas
WinDev, VFP ou nas tabelas DBF/HFSQL. Cria a ponte entre
o vocabulário antigo e o novo sistema.

TABELA POSTGRES
Preencha quando o termo mapear diretamente para uma tabela.
Use — quando for um conceito sem tabela própria.

---

## Termos a EVITAR — ambíguos sem qualificação

| Termo ambíguo   | Problema                                    | Use em vez disso         |
|-----------------|---------------------------------------------|--------------------------|
| Período         | Pode ser dia, mês, ano ou intervalo         | Competência / Vigência   |
| Valor           | Pode ser monetário, percentual ou quantidade| Valor bruto / Alíquota   |
| Usuário         | Pode ser o operador ou o beneficiário       | Operador / Beneficiário  |
| Tipo            | Genérico demais                             | Tipo de débito / Rubrica |

---

## Como usar com a IA

Cole a tabela principal no AI Context Pack (seção 1 — Identidade
da feature). A IA passa a interpretar os termos com o significado
correto do domínio — não com o sentido comum da palavra.

🔍

Engenharia Reversa com Claude Code

Extrai BRS e FTS automaticamente de código legado WL/VFP · Etapa 1 (legado)

Legado ▼

· pré-especificação — extração de spec implícita

Quando a feature já existe no legado (WinDev/VFP), o Claude Code faz a leitura e interpretação do código antigo para gerar automaticamente o BRS e o FTS iniciais — eliminando o trabalho manual de decifrar código estruturado complexo.

Quando usar: somente quando existir código legado correspondente. Para features novas (via suporte ou cliente), o fluxo normal da Etapa 1 se aplica.

Entradas para o Claude Code

→ Código WLanguage (.wl) ou Visual FoxPro (.prg/.scx)
→ Estrutura das tabelas DBF ou HFSQL
→ Nome do módulo / funcionalidade

Saídas geradas

→ BRS rascunho com regras extraídas do código
→ FTS rascunho com entidades mapeadas
→ Sugestão de schema PostgreSQL
→ Glossário de domínio inicial

Prompt base para engenharia reversa com Claude Code

prompt-engenharia-reversa.md

Você é um engenheiro de software sênior especialista em análise de sistemas legados. Analise o código abaixo escrito em [WLanguage / Visual FoxPro] e execute as seguintes tarefas: ## Código legado para análise: [Cole aqui o código WLanguage ou VFP] ## Estrutura das tabelas (DBF/HFSQL): [Cole aqui a estrutura das tabelas — nomes de campos e tipos] ## Tarefas: 1. BRS — Identifique e documente: - O que este código faz em linguagem de negócio (sem termos técnicos) - Quem usa esta funcionalidade e em qual contexto - TODAS as regras de negócio presentes (cada IF/CASE = uma regra) - Casos especiais e exceções tratados no código - O que o código NÃO faz (limites do escopo) 2. FTS — Identifique e documente: - Entidades de dados envolvidas - Fluxo técnico da operação (passo a passo) - Mapeamento das tabelas DBF/HFSQL para PostgreSQL (sugira nomes padronizados em snake_case com prefixo tb_) - Validações feitas no código que devem ir para o banco 3. GLOSSÁRIO — Liste os termos de domínio encontrados no código com suas definições no contexto do sistema 4. SCHEMA PostgreSQL — Sugira o CREATE TABLE para cada entidade identificada, com tipos PostgreSQL adequados ## Formato de saída esperado: Gere cada seção separadamente com os templates do Modelo Lógike. Marque com [VALIDAR] tudo que precisar de confirmação humana. Regras extraídas de condicionais devem ser marcadas com [EXTRAÍDA DO IF/CASE].

⚠ Importante: os artefatos gerados por engenharia reversa são sempre rascunhos. Um desenvolvedor que conhece o sistema deve revisar e validar antes de usar como base para a nova implementação.

Modelo Lógike

Glossário de siglas e termos

Todas as siglas e termos usados no Modelo Lógike e no Modelo Lógike de Desenvolvimento com definições precisas. Use a busca para encontrar rapidamente.

Sigla / Termo	Nome completo	Definição no Modelo Lógike
BRS	Business Requirements Sheet	Documento de uma página que descreve O QUÊ e POR QUÊ. Linguagem de negócio, sem tecnologia. Produzido na Etapa 1. No SDD equivale à camada de negócio do spec.md.
FTS	Feature Technical Sheet	Documento técnico que descreve COMO implementar. Entidades, fluxo técnico e arquitetura. Etapa 2. No SDD equivale à camada técnica do spec.md. Não confundir com TDD (Test-Driven Development).
ACP	AI Context Pack	Documento que reúne todo o contexto necessário para a IA gerar código preciso: contrato YAML, DDL, regras de negócio e padrões da equipe. Etapa 3. No SDD equivale ao constitution.md.
SDD	Spec-Driven Development	Metodologia onde a especificação é o artefato de primeira classe — escrita antes do código. O Modelo Lógike é uma implementação do SDD adaptada para equipes com legado e uso de IA.
UML	Unified Modeling Language	Linguagem visual padronizada para modelar sistemas. Agnóstica de linguagem de programação. Pode ser usada opcionalmente para complementar o FTS com diagramas de classes e sequência.
API	Application Programming Interface	Interface entre frontend e backend. No Modelo Lógike, definida antes de codificar via contrato YAML (Etapa 2).
YAML	YAML Ain't Markup Language	Formato de texto para contratos de API (Swagger/OpenAPI). Legível por humanos e máquinas. Gerado na Etapa 2 antes do código.
DDL	Data Definition Language	Comandos SQL que definem a estrutura do banco (CREATE TABLE, ALTER TABLE). Usado no AI Context Pack para contextualizar a IA sobre o schema PostgreSQL.
DBF	dBase File	Formato de tabelas do Visual FoxPro (legado). Fonte de regras de negócio a migrar para PostgreSQL. Entrada para a etapa de engenharia reversa.
HFSQL	Hyper File SQL	Banco de dados proprietário do WinDev (legado). Fonte de regras de negócio a migrar para PostgreSQL. Entrada para a etapa de engenharia reversa.
VFP	Visual FoxPro	Linguagem e banco de dados legado (Microsoft). Sistema de origem de regras de negócio. Código .prg e .scx são entradas para o Claude Code na engenharia reversa.
WL	WLanguage	Linguagem de programação proprietária do WinDev (PCSOFT). Stack atual do backend. Código .wl é entrada para o Claude Code na engenharia reversa.
PG	PostgreSQL	Banco relacional open source. Destino de toda a migração de banco. Schema exportado como DDL é fonte central de contexto para a IA no AI Context Pack.
CA	Critério de Aceite	Condição verificável que define quando uma feature está pronta. Formato: Dado [contexto] / Quando [ação] / Então [resultado esperado]. Escrita no BRS, validada nos testes da Etapa 6.
RN	Regra de Negócio	Comportamento que o sistema deve ter, definido pelo domínio de negócio. Extraída do legado, legislação ou suporte. Cada IF/CASE no código legado é uma RN tácita a documentar.
PR	Pull Request	Solicitação de merge no GitHub. Gatilho formal da Etapa 5 (code review). Nenhum código vai para a branch principal sem PR aprovado.
SDLC	Software Development Life Cycle	Ciclo de vida do desenvolvimento de software. O Modelo Lógike é uma implementação do SDLC para equipes pequenas com sistemas legados e uso de IA.
ER	Engenharia Reversa	Processo de leitura do código legado (WL/VFP) pelo Claude Code para gerar automaticamente rascunhos de BRS e FTS. Usado somente quando há código legado correspondente à feature.
Artefato	—	Documento ou diagrama produzido em uma etapa do modelo. Cada etapa tem artefatos de entrada e de saída bem definidos. Ex: BRS, FTS, ACP, API Contract.
Feature	—	Funcionalidade ou módulo sendo desenvolvido. Cada feature percorre as 6 etapas do Modelo Lógike e produz seus próprios artefatos rastreáveis.
Schema	—	Estrutura do banco de dados — tabelas, colunas, tipos e relacionamentos. Exportado como DDL do PostgreSQL. Elemento mais valioso do AI Context Pack para a geração de código.
Prateleira	—	Sistema comercial desenvolvido para múltiplos clientes, sem customização por encomenda. Contexto dos sistemas da Lógike — demandas chegam via suporte ou legislação.
Spec	Specification	Especificação formal do comportamento de uma feature. No SDD e no Modelo Lógike, a spec (BRS + FTS) é escrita antes do código e serve como fonte de verdade para a IA e para os testes.
Constitution	constitution.md (SDD)	Documento central do SDD que define regras imutáveis do projeto: stack tecnológica, padrões de arquitetura e convenções de código. No Modelo Lógike corresponde à seção 5 do ACP e ao Glossário de Domínio.
Competência	— (domínio jurídico)	Mês e ano de referência dos cálculos. Ex: competência 03/2025 = março de 2025. Sinônimos no legado: período, referência, mês. Tabela: tb_competencia.
Glossário de Domínio	—	Documento vivo e compartilhado pela equipe que registra os termos específicos do negócio com definições precisas. Diferente do BRS (por feature), o glossário é da empresa e nunca termina.

Trilha de Aprendizado

Engenharia de Software

6 módulos do fundamento ao desenvolvimento assistido por IA.

⬤ 6 módulos ⬤ 15 vídeos ⬤ 18 tarefas · Spec-Driven Development

Meu progresso

0%

M1 · Fundamentos

M2 · BRS/FTS/Spec

M3 · API REST

M4 · Testes

M5 · Git

M6 · IA

1

Fundamentos de Engenharia de Software

Mês 1 · O que é ES, ciclo de vida, diferença entre codificar e desenvolver

Começar aqui

✓

▼

Por que é o primeiro

Cria o vocabulário comum da equipe
Explica por que etapas importam
Diferencia codificar de desenvolver
Contextualiza o Modelo Lógike

O que você vai aprender

Ciclo de vida de software (SDLC)
O que são requisitos e por que importam
O que é código limpo na prática
O que é dívida técnica

Alinha com o Modelo Lógike: fundamenta a visão geral, os princípios de processo e a razão pela qual documentamos antes de codificar — especialmente relevante para a extração de regras dos sistemas legados WinDev e VFP.

✓

Tarefa 1.1 — Mapeamento de um módulo legado

Escolha um módulo do sistema legado (WinDev ou VFP). Documente em linguagem natural o que ele faz, quem usa e quais as principais regras — incluindo recursos já desenvolvidos que servem como fonte de requisitos para o novo sistema.

Etapa 1 do Modelo Lógike

✓

Tarefa 1.2 — Primeiro BRS

Com base no mapeamento acima, escreva o BRS de uma funcionalidade usando o template do Modelo Lógike. Preencha o campo "Fonte da demanda" identificando se veio do legado, suporte ou legislação.

Artefato: BRS

✓

Tarefa 1.3 — Discussão em equipe

Na reunião quinzenal, cada membro apresenta seu BRS. A equipe discute: as regras estão claras? Os critérios de aceite são verificáveis? Alguma regra estava tácita e precisou ser explicitada?

Reunião de equipe

Clique para marcar como aprendido — salvo automaticamente no banco:

SDLC

Ciclo de vida

Código limpo

Dívida técnica

Requisitos

Critérios de aceite

Regras de negócio

Artefato

2

BRS, FTS e Documentação em Markdown

Mês 2 · Escrita técnica, artefatos do Modelo Lógike, Spec-Driven Development · Etapas 1 e 2

Etapas 1–2

✓

▼

O que é Spec-Driven Development

Especificação escrita ANTES do código
BRS = spec de negócio · FTS = spec técnica
IA gera código a partir da spec, não do vazio
Reduz retrabalho e ambiguidade no desenvolvimento

Por que Markdown no Modelo Lógike

BRS e FTS são escritos em .md
Versionados no GitHub junto com o código
Legível por humanos e pela IA
Notion renderiza .md nativamente

Alinhamento com o Modelo Lógike: este módulo é o coração do método. BRS e FTS são os artefatos mais usados no dia a dia — toda feature começa com um BRS e toda implementação começa com um FTS. Spec-Driven garante que a IA receba contexto rico antes de gerar qualquer código.

Spec-Driven Development — o ciclo completo

1. Escrever BRS

→

2. Escrever FTS

→

3. Montar AI Context Pack

→

4. IA gera código

→

5. Testes validam a spec

📺

SDD: a habilidade que vai separar quem SOBREVIVE à IA YouTube · Maio 2026 · Em português

Por que o Spec Driven Development voltou a ganhar relevância com a IA e como aplicá-lo no dia a dia do desenvolvimento. Contextualiza o SDD no cenário atual de ferramentas de IA assistida — como o Claude.

↗ YouTube

📺

SDD na prática — o que aprendi depois de 70 especificações Canal: Dev+Eficiente · Outubro 2025 · Em português

Experiência real aplicando Spec Driven Development na prática. Depois de escrever cerca de 70 especificações, o autor compartilha o que funciona e o que não funciona — especialmente valioso para equipes que estão começando com o método.

↗ YouTube

📺

Markdown na prática — Como escrever documentação técnica Canal: Código Fonte TV · Documentação como código

Markdown é a linguagem usada para escrever BRS, FTS e toda a documentação do Modelo Lógike. É simples, legível sem renderização, versionável no Git e interpretado nativamente pela IA.

↗ YouTube

📺

Como escrever boas especificações de software Canal: DevSuperior · Escrita técnica e documentação

Como transformar requisitos de negócio em especificações técnicas claras e acionáveis — o processo que o BRS e o FTS do Modelo Lógike formalizam.

↗ YouTube

✓

Tarefa 2.1 — BRS completo de uma feature legada

Usando o módulo legado mapeado no mês 1, escreva um BRS completo em Markdown seguindo o template do Modelo Lógike. Foque em extrair regras tácitas do código — cada IF/CASE é uma regra de negócio a documentar.

Artefato: BRS em Markdown

✓

Tarefa 2.2 — FTS derivado do BRS

A partir do BRS escrito na tarefa anterior, escreva o FTS correspondente em Markdown. Mapeie as entidades das tabelas DBF/HFSQL para nomes em snake_case do PostgreSQL e descreva o fluxo técnico da operação passo a passo.

Artefato: FTS em Markdown

✓

Tarefa 2.3 — Spec completa + AI Context Pack

Com o BRS e FTS prontos, monte o AI Context Pack da feature incluindo o DDL das tabelas PostgreSQL sugeridas. Use o Context Pack para pedir ao Claude que gere o endpoint correspondente. Avalie a qualidade do código gerado.

Spec-Driven na prática

Clique para marcar como aprendido:

Spec-Driven Development

BRS — Business Requirements Sheet

FTS — Feature Technical Sheet

Markdown

Especificação antes do código

Critérios de aceite

Regras de negócio

Engenharia reversa de legado

Glossário de domínio

3

Design de API REST e Contratos

Mês 3 · Princípios REST, Swagger/OpenAPI, contrato antes do código · Etapa 2

Etapa 2

✓

▼

A mudança mais impactante

Swagger YAML gerado ANTES do código
Frontend desenvolve em paralelo
IA recebe contrato preciso para codificar
Redução de retrabalho na integração

O API Contract no Lógike

Arquivo YAML com rota, método, parâmetros
Respostas esperadas por cenário
Códigos de status corretos
Versionado no GitHub junto ao código

O API Contract gerado neste módulo é o artefato central da Etapa 2 e a principal entrada do AI Context Pack na Etapa 3. É também a fonte do Swagger publicado na Etapa 5 para o frontend.

✓

Tarefa 3.1 — Revisão do Swagger atual

Pegue um endpoint do Swagger existente da equipe. Verifique: segue os princípios REST? O status code está correto? A nomenclatura da rota faz sentido? Documente as inconsistências encontradas.

Análise crítica

✓

Tarefa 3.2 — API Contract antecipado

Para a feature trabalhada nos meses 1 e 2, escreva o API Contract YAML antes de qualquer código. Inclua rota, método HTTP, parâmetros, body, respostas de sucesso e de erro.

Artefato: API Contract

✓

Tarefa 3.3 — Apresentação ao frontend

Compartilhe o contrato YAML com a equipe de frontend antes de codificar. Quantos ajustes foram necessários? Registre as mudanças — isso demonstra o valor do contrato antecipado.

Integração front-back

REST

HTTP verbs

Status codes

OpenAPI

Swagger YAML

Endpoint

Contrato de API

Versionamento

4

Testes de Software

Mês 4 · Pirâmide de testes, unitários, integração, API · Etapa 6

Etapa 6

✓

▼

A conexão testes → BRS

Cada CA do BRS vira um caso de teste
Test Plan derivado diretamente do BRS
Test Report fecha o ciclo da feature
Rastreabilidade total: requisito → código → teste

Tipos de teste no Lógike

Unitário — funções isoladas
Integração — módulos + banco
API — endpoints vs contrato YAML
Homologação — critérios de aceite do BRS

Os critérios de aceite escritos no BRS (Etapa 1) são a entrada direta para o Test Plan (Etapa 6). Um bom BRS torna a escrita de testes óbvia — e um Test Plan sem BRS correspondente indica que a Etapa 1 foi pulada.

✓

Tarefa 4.1 — Test Plan da feature piloto

Para a feature trabalhada nos meses 1 a 3, escreva o Test Plan usando o template do Modelo Lógike. Cada caso de teste deve rastrear diretamente a um critério de aceite (CA-XX) do BRS.

Artefato: Test Plan

✓

Tarefa 4.2 — Teste de API com Postman/Insomnia

Execute os casos de teste do Test Plan contra o endpoint correspondente. Registre os resultados no Test Report — passou, falhou, observações.

Artefato: Test Report

✓

Tarefa 4.3 — Mapeamento de gaps

Para os endpoints existentes no sistema atual: quantos critérios de aceite têm teste correspondente? Quantos não têm? Isso revela a cobertura real e prioriza o que precisa ser testado primeiro.

Análise de cobertura

Pirâmide de testes

Teste unitário

Teste de integração

Teste de API

Test Plan

Test Report

Caso de teste

Cobertura de testes

5

Git e Fluxo de Equipe

Mês 5 · Branches, commits semânticos, code review, GitHub privado · Etapas 4–5

Etapas 4–5

✓

▼

Convenção de branches no Lógike

feature/BRS-2025-014-nome-da-feature
bugfix/BRS-2025-015-descricao
docs/BRS-2025-014-atualiza-fts
Rastreabilidade BRS → branch → PR

Commits semânticos

feat: nova funcionalidade [BRS-id]
fix: correção de bug [BRS-id]
docs: atualização de documentação
test: adição ou ajuste de testes

O GitHub privado versiona código e documentação juntos. Cada feature branch conecta ao BRS correspondente. O Pull Request é o gatilho para a Etapa 5 (code review). Repositórios privados são gratuitos no GitHub.

✓

Tarefa 5.1 — Repositório privado no GitHub

Criar o repositório privado no GitHub para o projeto. Estruturar a pasta /docs com os primeiros artefatos do Modelo Lógike (BRS e FTS da feature piloto). Configurar acesso apenas para a equipe.

Infraestrutura

✓

Tarefa 5.2 — Primeiro Pull Request com review

Criar uma branch feature/BRS-[id]-[nome], fazer uma alteração de código ou documentação e abrir um Pull Request. Outro membro faz o code review usando o Code Checklist. Praticar o ciclo completo.

Etapa 5 do Modelo Lógike

✓

Tarefa 5.3 — Commits semânticos por 2 semanas

Durante duas semanas, toda a equipe usa commits semânticos com referência ao BRS. Na reunião do final do mês: o histórico ficou mais legível? Foi mais fácil rastrear o que foi implementado?

Hábito de equipe

Git

Branch

Commit semântico

Pull Request

Code review

Git Flow

Repositório privado

Merge

6

Desenvolvimento Assistido por IA

Mês 6 · AI Context Pack, prompt engineering, avaliação de código gerado · Etapas 3–4

Etapas 3–4

✓

▼

Por que é o último módulo

IA amplifica quem tem base sólida
Sem base, o código gerado não é avaliável
Módulos 1–5 são o pré-requisito real
Context Pack sem UML e BRS é vazio

O que o AI Context Pack inclui

Contrato YAML do endpoint
DDL das tabelas Postgres
Regras de negócio do BRS
Padrões e convenções da equipe

Este módulo é construído internamente com base na experiência real da equipe. Os prompts, Context Packs e padrões desenvolvidos aqui são propriedade intelectual da equipe — o material mais valioso de toda a trilha.

✓

Tarefa 6.1 — Primeiro AI Context Pack real

Montar o ACP completo de uma feature real: schema Postgres (DDL), regras de negócio do BRS, padrões da equipe e contrato YAML. Usar com Claude para gerar o código do endpoint. Registrar o prompt usado.

Artefato: AI Context Pack

✓

Tarefa 6.2 — Avaliação crítica do código gerado

Após gerar o código com a IA: quantos ajustes foram necessários? O que a IA acertou? O que ela errou? O código seguia o schema Postgres corretamente? As regras de negócio foram respeitadas? Registrar no Review Log.

Artefato: Review Log

✓

Tarefa 6.3 — Refinamento do prompt base

Com base nas tarefas 6.1 e 6.2, refinar o prompt base do AI Context Pack. A versão refinada se torna o padrão da equipe — versionada no GitHub e usada em todas as features futuras.

Padrão de equipe

Prompt engineering

AI Context Pack

Contexto de IA

Avaliação de código gerado

DDL como contexto

Claude Code

Prompt base

Iteração de prompt

Independência tecnológica

Migração WLanguage → Python

O Modelo Lógike foi projetado para que a troca de linguagem seja cirúrgica. Como os artefatos seguem o princípio Spec-Driven Development — especificação antes do código — toda a camada de negócio e qualidade permanece intacta. Apenas os artefatos que contêm padrões de código precisam ser atualizados.

Custo real da migração: atualizar a seção 5 do AI Context Pack (Padrões da equipe), o Code Checklist e o prompt base. Todos os outros artefatos — BRS, FTS, Glossário, API Contract, Test Plan, Test Report — permanecem 100% válidos e não precisam ser reescritos.

Artefato	Etapa	Muda?	Motivo
BRS	Etapa 1	Não muda	Requisitos de negócio são agnósticos de linguagem — o QUÊ não depende do COMO
Glossário de Domínio	Contínuo	Não muda	Termos do domínio de negócio não dependem da linguagem de implementação
FTS	Etapa 2	Não muda	Entidades, fluxo técnico e mapeamento PostgreSQL são agnósticos de linguagem
API Contract YAML	Etapa 2	Não muda	O contrato da API (rotas, parâmetros, respostas) é independente da implementação
Schema PostgreSQL	Etapa 2	Não muda	O banco de dados é o mesmo — DDL, tabelas e relacionamentos permanecem idênticos
Test Plan / Test Report	Etapa 6	Não muda	Os critérios de aceite do BRS são os mesmos — os testes validam o comportamento, não o código
ACP — seção 1 a 4	Etapa 3	Não muda	Identidade da feature, contrato YAML, DDL e regras de negócio são agnósticos
ACP — seção 5 (Padrões)	Etapa 3	Muda	Padrões e convenções são específicos da linguagem — reescrever para Python (PEP 8, type hints, estrutura de projeto)
Code Checklist	Etapa 4–5	Muda	Revisado para convenções Python: PEP 8, type hints, docstrings, estrutura de módulos
Prompt base da IA	Etapa 3	Muda	De "especialista em WLanguage (WinDev PCSOFT)" para "especialista em Python" — único ajuste no ACP

· Por que o SDD torna a migração mais simples

No Spec-Driven Development, a especificação (spec.md = BRS + FTS) é separada da implementação. Isso significa que ao migrar de WLanguage para Python, você não está reescrevendo o sistema — está reimplementando uma spec já aprovada em uma linguagem diferente. A spec continua válida, os testes continuam válidos, o banco continua o mesmo. Só o código muda.

Fluxo sugerido para a migração endpoint por endpoint

Garantir BRS aprovado

→

Confirmar schema Postgres

→

Atualizar ACP §5 para Python

→

Claude reimplementa em Python

→

Test Plan existente valida

→

Test Report confirma entrega

Atualização do prompt base — seção 5 do ACP para Python

acp-secao5-python.md

## 5. Padrões e convenções da equipe (Python) - Linguagem: Python 3.11+ - Framework de API: [FastAPI / Django REST / Flask — definir] - Nomenclatura: snake_case para variáveis e funções, PascalCase para classes - Type hints: obrigatório em todas as funções e métodos - Docstrings: Google style em funções públicas - Tratamento de erros: HTTPException com código e mensagem padronizados - Estrutura de resposta: {"ok": true/false, "data": ..., "erro": "..."} - ORM: SQLAlchemy (ou psycopg2 direto — definir) - Validação: Pydantic models para request/response - Variáveis de ambiente: python-dotenv --- [PROMPT BASE — PYTHON] Você é um desenvolvedor sênior especialista em Python. Implemente o endpoint conforme o contrato YAML acima. Respeite TODAS as regras de negócio listadas na seção 4. Use EXATAMENTE os nomes de tabelas e colunas do schema PostgreSQL fornecido. Siga os padrões da seção 5 (type hints, Pydantic, snake_case). Retorne apenas o código, sem explicações adicionais.

Recursos

Ferramentas da equipe

Stack sem lock-in, custo mínimo, integração com Claude. Papéis distintos, sem sobreposição.

📋

Trello

Gestão de tasks e kanban. Cards das features com link para o BRS no Notion. Visualiza o status de cada feature no ciclo do Lógike.

✓ Gratuito (plano básico suficiente)↗ Abrir Trello

📝

Notion

Repositório de conhecimento. BRS, FTS, Glossário, AI Context Pack, decisões técnicas. Complementa o Trello — não compete.

✓ Gratuito (plano Free — suficiente para 10 devs)↗ Abrir Notion

📝

Markdown — Documentação como código

Formato de escrita dos artefatos BRS, FTS, AI Context Pack e Glossário de Domínio. Legível por humanos, interpretado pela IA e versionado no GitHub junto com o código. Renderizado nativamente no Notion e GitHub.

✓ Gratuito · Sem instalação · Suportado em todas as ferramentas da stack↗ Guia de sintaxe ↗ Editor online

🐙

GitHub

Código e documentação versionados juntos. Repositórios privados gratuitos. PRs como gatilho formal da Etapa 5.

✓ Repositórios privados gratuitos para qualquer conta↗ Abrir GitHub

🤖

Claude (Anthropic)

Motor central de IA. Geração de código com AI Context Pack, revisão, geração de testes e documentação.

→ Plano Pro ou API↗ Claude.ai ↗ Documentação

🧪

Postman / Insomnia

Teste de endpoints de API. Usa o contrato YAML da Etapa 2 para validar os endpoints na Etapa 6.

✓ Ambos gratuitos para uso básico↗ Postman ↗ Insomnia

Onboarding

Guia para novo membro

Seja bem-vindo à equipe LogikeDev. Este guia resume o que você precisa entender para começar a trabalhar dentro do nosso método.

1

Comece pelos princípios

Antes de qualquer ferramenta, entenda os 6 princípios fundamentais do Modelo Lógike. Eles explicam por que fazemos as coisas desta forma.

→ Ver princípios

2

Leia o glossário

A equipe usa siglas específicas (BRS, FTS, ACP, RN, CA). Familiarize-se antes da primeira reunião de equipe.

→ Ver glossário

3

Entenda as 6 etapas

Todo desenvolvimento passa pelas 6 etapas. Nenhuma feature vai para produção sem percorrer o ciclo completo.

→ Ver etapas

4

Configure as ferramentas

Você precisará de acesso ao Trello, Notion, GitHub (solicite ao admin), PlantUML e Claude.

→ Ver ferramentas

5

Inicie a Trilha de Aprendizado

6 módulos de Engenharia de Software com vídeos em português e tarefas práticas no sistema real. Comece pelo Módulo 1 e avance um módulo por mês.

→ Abrir Trilha LogikeDev ↗

6

Primeiro BRS na primeira semana

Escolha um módulo do sistema legado, mapeie o que ele faz e escreva um BRS usando o template. Apresente na reunião quinzenal da equipe.

→ Ver template BRS

Minha área

Meu progresso

Progresso salvo automaticamente no banco SQLite do servidor — disponível em qualquer dispositivo.

Progresso por módulo

Administração

Gerenciar membros

Cadastre e gerencie os membros da equipe. Dados salvos no banco LogikeDev.db (SQLite).

Administração

Progresso da equipe

Visão em tempo real do progresso de todos os membros na Trilha LogikeDev — lido diretamente do banco SQLite.