🌐 Idioma / Language: Português (pt-BR) · English
Um ERP completo — 23 módulos, 42 controllers REST, 31 telas, 961 testes automatizados — construído em ~4,5 dias corridos por uma pessoa supervisionando o Claude Code, usando Spec-Driven Development. Este repositório é a prova de conceito inteira: o código, as 33 especificações, os 23 ADRs, as 152 decisões registradas e o log de execução de cada fase. Nada foi escondido — os imprevistos estão documentados junto com o que deu certo (a verificação final da Fase 21 encontrou três defeitos, corrigidos e registrados; o primeiro PR revisado expôs um CI vermelho que o push direto escondia).
É um projeto de estudo, livre para qualquer uso: baixe, copie, modifique, comercialize — sem pedir permissão e sem obrigação de atribuição (licença 0BSD).
- 1. O que é o sistema
- 2. O resultado em números
- 3. O método: Spec-Driven Development
- 4. A história real — o que aconteceu, fase a fase
- 5. Processos de engenharia de software utilizados
- 6. Quanto tempo levaria sem IA?
- 7. Stack completa (com versões)
- 8. Como rodar
- 9. Mapa do repositório e da documentação
- 10. Licença e uso
O ERP Acme Travel é o sistema de gestão de uma GSA (General Sales Agent — representante comercial de marcas de turismo) fictícia. O domínio é real e denso: comissão de duas pontas (recebe do fornecedor, paga ao agente, vive do spread), câmbio congelado como promoção (com decomposição de subsídio × drift e hedge por forwards), conciliação multi-moeda, fechamento mensal vetado por documento fiscal (a "regra de ouro": não fecha sem a nota), NFS-e, repasses ao centavo, pós-venda com SLA, marketing sob LGPD, RH sobre ponto eletrônico (Portaria MTP 671/2021) e um DSS determinístico que aconselha — e nunca decide sozinho.
O documento de domínio completo (a "fonte da verdade" que alimentou tudo) está em docs/DOMAIN.md. O manual do usuário final está em docs/MANUAL.md (English).
Números medidos no repositório (develop após as Fases 22 e 23, versão 0.54.0 — 03/07/2026):
| Métrica | Valor |
|---|---|
| Tempo de construção | 2026-06-29 03:57 → 2026-07-03 10:30 (≈ 4,5 dias corridos) |
| Commits | 464 |
| Releases publicadas | 55 (SemVer 0.1.0 → 0.54.0, uma MINOR por fatia + PATCHes de correção — ADR-0015) · 59 tags |
| Código backend | 37.665 linhas de Java main (783 arquivos main + 158 de teste) |
| Código frontend | 16.856 linhas de TS/HTML/SCSS (31 telas, exclui specs) |
| Banco | 44 migrações Flyway (1.696 linhas de SQL), PostgreSQL 16 |
| Módulos verificados | 23 (Spring Modulith, grafo acíclico com gate de build) |
| API | 42 controllers REST · snapshot OpenAPI com gate de drift |
| Testes backend | 627 (unitários + integração Testcontainers + 18 regras ArchUnit + jqwik) |
| Testes frontend | 334 (Vitest) + 28 jornadas E2E (Playwright, stack isolada) |
| Cobertura (medida na Fase 21, v0.51.1) | JaCoCo 90,1% de instrução (piso 80%) · 68,8% de branch (piso 65%) |
| Mutation testing | PIT (última medição completa, Fase 20): 185 mutantes, 68% mortos, 89% de test strength (piso 60%) |
| Observabilidade | 5 dashboards Grafana provisionados · 10 alertas (entrega por e-mail opcional) — Fases 22b/22c |
| Especificações | 33 (SPEC-0001…0034 — não há 0030) — docs/specs/ |
| ADRs | 23 — docs/adr/ |
| Decisões autônomas registradas | 152 (DL-0001…0152, com confiança e reversibilidade) — docs/decision-log/ |
| Configuração | referência completa de variáveis de ambiente em docs/CONFIGURATION.md |
Cada número acima é verificável no próprio repo: o log de execução por fase (com horários e resultado do
./mvnw verifyde cada entrega) está em docs/ROADMAP-STATUS.md.
A tese da POC: a IA não inventa o produto — ela executa especificações sob regras inegociáveis, e ferramentas de build fazem as regras valerem. Três camadas:
1. Regras sempre carregadas — o CLAUDE.md define os invariantes de toda tarefa (Regra Zero contra overengineering, ordem de autoridade, "nunca inventar regra de negócio", Definition of Done) e roteia para as 12 regras detalhadas de docs/architecture/ (backend, frontend, testes, segurança, persistência…).
2. Especificações como contrato — nenhuma fatia começa sem spec (docs/specs/). Onde o negócio ainda não decidiu, a spec registra uma Open Question — que é decidida antes de codar (pelo dono, ou autonomamente com pesquisa e registro em docs/decision-log/, cada decisão com grau de confiança e custo de reversão).
3. Portões que quebram o build — ArchUnit (18 regras), Spring Modulith verify()
(fronteiras de módulo), Spotless/Checkstyle, pisos de cobertura, snapshot de contrato OpenAPI e
do diagrama de módulos. Regra que incomoda não se afrouxa — conserta-se o código.
O ciclo de cada fatia (detalhado em docs/TUTORIAL.md):
0 PERGUNTAS → 1 PLAN → 2 RED (teste que falha) → 3 SKELETON → 4 GREEN → 5 REFACTOR → 6 GATES + DoD
A partir da Fase 2, a execução virou autônoma: um prompt padrão
(docs/RUN-PHASE.md) instruía o Claude Code a implementar a fase inteira —
decidindo Open Questions com pesquisa, registrando DLs, seguindo gitflow e cortando release. Em
várias fases, um supervisor orquestrou builders em worktrees isolados do git,
reverificando cada entrega (git ls-remote, ./mvnw verify na develop mergeada) antes de
aceitar. O humano (dono) decidia produto: aprovava planos, respondia perguntas de negócio e
ocasionalmente interrompia e redirecionava (ver a história abaixo).
A linha do tempo completa, com horários e resultados, está em docs/ROADMAP-STATUS.md. O resumo honesto:
Dia 1 (29/06) — do zero ao ERP operante. Fase 0 (walking skeleton com CI e gates verdes em 1h), Fase 1 (núcleo comercial: 6 fatias em ~1h20 de backend + telas), Fases 2–7 (compliance, primeira integração ACL, cancelamento, exposição cambial, crawler de ponto, DSS) e o início do bloco 8 — 13 releases no primeiro dia. Cada fase levou 30–60 minutos de execução autônoma.
Dias 2–3 (30/06–01/07) — os genéricos e a profissionalização. Fases 8a–8l (política comercial, finance pleno, billing, payout, after-sales, marketing, portfólio, assets, people, platform, identity, admin), Fase 10 (UX profissional: PrimeNG + shell SaaS + tema + paleta de comandos), 11 (observabilidade), 12 (E2E + cobertura), 13 (SSO), 14 (upgrade Spring Boot 4), 15 (docs bilíngues), 16 (as 18 telas de operação que faltavam), 17 (fora Keycloak) e 18 (enums → cadastros editáveis).
Dia 4 (02/07) — maturidade e polimento. Fase 19, 12 fatias de production readiness em um dia (autorização default-deny, hardening, OpenAPI real, emuladores, multi-instância, hedge, QA hardening, CI supply-chain, postura de produção com TLS/backup/DR) e Fase 20 (teclado-first, Esc/Enter universais, DSS real, design 2026).
Dia 5 (03/07) — operação enterprise e governança de equipe. Fase 22 completa (5 fatias,
0.52.0→0.54.0): gates permanentes de paridade i18n (pt/en, 110 exceções de domínio nos dois
idiomas), monitoramento enterprise (5 dashboards Grafana, 10 alertas com entrega por
e-mail), log inteligente (Loki/Alloy com correlationId/username como metadados
estruturados), manual minucioso com 31 screenshots gerados por script versionado e guia de
instalação do zero. E a Fase 23 — governança de repositório para trabalho em equipe:
main/develop protegidas (PR obrigatório, sem push direto), trava do agente em
.claude/settings.json (merge/tag/force-push negados), varredura de segredos gitleaks
(CI bloqueante + pre-commit + allowlist dos dev-defaults), CODEOWNERS, SECURITY.md,
CONTRIBUTING.md. O primeiro ciclo PR-only (PR #14) pagou o investimento no mesmo dia — expôs
um CI vermelho que o push direto vinha escondendo (ver imprevistos). Na sequência nasceu o
toolkit de equipe .claude/ (10 skills + time de agentes com arquiteto coordenador;
PR #15, mergeado em 04/07 — ver docs/GUIA-TIME-CLAUDE.md).
- Os portões seguraram a IA. O gate do Spring Modulith pegou um ciclo de dependência entre módulos na Fase 5 (corrigido, não afrouxado). O snapshot de OpenAPI pegou drift de contrato na 19h. O piso de cobertura quebrou o build quando refactors deixaram código sem teste (19j, 20a, 20b) — e a resposta foi cobrir, não baixar o piso. É a diferença entre "confiar" na IA e verificar a IA.
- Teste primeiro encontrou bugs reais. A Fase 19i provou vermelho→verde uma corrida de
concorrência real (lançamento escapando para um período recém-fechado) e o 20c pegou um
listener que silenciosamente não persistia (transação read-only →
REQUIRES_NEW). - O decision log pagou o investimento. As 152 DLs (cada uma com lacuna, decisão, justificativa com fontes, alternativas descartadas e custo de reversão) permitiram revisar decisões em lote (Fase 19b) e reverter com segurança as que envelheceram mal.
- Specs vivas evitaram retrabalho. Regra mudou no meio? A spec foi atualizada no mesmo PR. A rastreabilidade spec → teste → código sobreviveu às 55 releases.
- Interrupção por rate-limit no meio de uma fatia (8d): o builder caiu com trabalho mergeado local e sem push; o supervisor inspecionou o estado e retomou o mesmo subagente, que terminou e cortou a release. Lição: estado em git + log de execução tornam a retomada barata.
- Um builder apagou um arquivo do dono — duas vezes (16b/16c): uma "limpeza" destrutiva de untracked levou junto um relatório pessoal do dono. O supervisor restaurou verbatim (o tinha lido antes) e o commitou para protegê-lo. Lição: arquivo importante se rastreia no git; subagente não roda limpeza global.
- Colisão de worktrees (8e): duas sessões paralelas (código + docs) colidiram na árvore de trabalho; resolvido finalizando uma delas em worktree isolado — que virou o padrão dali em diante.
- Keycloak entrou (Fase 13) e saiu (Fase 17): a decisão de usar um IdP externo foi revertida pelo dono por simplicidade operacional — o Spring Authorization Server embutido a substituiu, sem tocar o contrato (o Resource Server e o front OIDC ficaram intactos). Custo real de reverter: uma fatia.
- O scrape do Prometheus ficou quebrado da Fase 13 à 19k apontando para um endpoint de login removido — descoberto apenas na auditoria de observabilidade. Lição: monitoramento também precisa de teste (a cadeia token→scrape virou teste de integração).
- Herança do template Go: o layout inicial trouxe pacotes
internal/(convenção de Go, sem sentido em Java) — removidos na Fase 9 com refactor estrutural puro. - Atalhos de teclado divergentes do dicionário (20a): a derivação automática por primeira letra colidia em 26 telas e o dicionário exibia atalhos que não funcionavam — além de uma falha real de acessibilidade (WCAG 2.1.4, tecla única sem desligar). Refeito com mapa curado e único.
- Limite semanal de uso no meio da 18c: o builder parou com código commitado e docs pendentes; o supervisor concluiu a fatia de onde ela parou.
- Fase 1 preemptada pelo dono logo no início para instituir SemVer/versionamento (ADR-0015) antes de qualquer código de negócio — e reiniciada limpa em seguida.
- O CI estava vermelho desde a Fase 20b — e ninguém viu (03/07): com push direto, ninguém
olhava os checks; o primeiro PR revisado (Fase 23) os expôs. Eram dois problemas reais:
a action do gitleaks exigindo
GITHUB_TOKENem eventos de pull request (configuração — não era vazamento) e um teste de integração flaky — verde no Windows local, vermelho no runner Linux — por resíduo no Postgres singleton compartilhado (asserção de contagem absoluta sem limpeza@BeforeEach). Corrigidos no próprio PR, com a lição codificada como regra da casa (isolamento@BeforeEach+ repro Linux só com checkout limpo). Lição maior: branch protection + PR não é cerimônia — é o que faz os checks serem vistos.
| Processo | Como aparece neste repo |
|---|---|
| Spec-Driven Development | 33 specs com regras testáveis, exemplos e Open Questions; specs vivas atualizadas no PR da fatia |
| TDD (red→green→refactor) | O laço de 7 passos de toda fatia (TUTORIAL); bugs ganham teste de regressão que falha antes |
| DDD pragmático | 22 bounded contexts do domínio → 23 módulos; linguagem ubíqua; eventos como fatos de negócio |
| Monólito modular | Spring Modulith + ArchUnit como fitness functions (fronteiras quebram o build) — ADR-0001/0012 |
| Fatias verticais | Cada entrega atravessa migração → domínio → API → tela e sai demonstrável; walking skeleton primeiro |
| ADRs + decision log | 23 ADRs para arquitetura; 152 DLs para decisões autônomas com confiança/reversibilidade |
| Gitflow + Conventional Commits + SemVer | main/develop protegidas (PR obrigatório — Fase 23) + feature/*; 55 releases tagueadas de main; versão fonte no pom.xml (ADR-0015) |
| Governança de repo + secret scanning | Branch protection PR-only, CODEOWNERS, SECURITY/CONTRIBUTING, trava do agente (.claude/settings.json), gitleaks (CI bloqueante + pre-commit, allowlist de dev-defaults) — ADR-0023 |
| CI/CD com quality gates | GitHub Actions: build+testes+gates, E2E, CodeQL, gitleaks, Dependabot, npm audit, imagens GHCR por tag |
| Contract testing | Snapshot OpenAPI committado + teste de drift; diagrama de módulos idem |
| Property-based + mutation testing | jqwik (8 propriedades × 1000 casos na matemática de dinheiro); PIT com piso de 60% |
| E2E isolado | Playwright contra stack descartável (compose.e2e.yaml, Postgres em tmpfs) — nunca o banco de dev |
| Observabilidade | Micrometer/Prometheus/Loki/Grafana provisionados — 5 dashboards, 10 alertas (e-mail opcional), logs JSON com correlationId/username como metadados estruturados, /api/version |
| Security by default | Autorização default-deny com teste de completude, OIDC+PKCE, HMAC+anti-replay, fail-fast de segredos em prod, cofre AES-GCM |
| DR/backup | pg_dump diário + tar do cofre, retenção 30d/12m/7a, RPO 24h/RTO 4h, ensaio trimestral (ADR-0021) |
| i18n + a11y + LGPD | pt-BR/en-US de ponta a ponta; WCAG 2.1.4 (toggle de tecla única), prefers-reduced-motion; consentimento/erasure/mascaramento |
Estimativa honesta, por dois métodos, para as mesmas ~68 KLOC (Java + TS + SQL) com o mesmo nível de acabamento (testes, gates, observabilidade, docs bilíngues):
- COCOMO II (orgânico):
esforço = 2,4 × 67,7^1,05 ≈ 200 pessoas-mês(~16,7 pessoas-ano). O modelo clássico é pessimista para stacks modernas, mas dá a ordem de grandeza histórica. - Estimativa prática de mercado: um time enxuto e bom (2 backend + 1 frontend + 1 QA/DevOps) entregaria este escopo em 12–18 meses ≈ 48–72 pessoas-mês — assumindo requisitos já consolidados como estão em docs/DOMAIN.md.
O que levou de fato: ~4,5 dias corridos, com 1 pessoa supervisionando (aprovando planos, decidindo Open Questions de negócio, auditando entregas) e o Claude Code executando — frequentemente em fases autônomas de 30–90 minutos. Mesmo contando cada hora do dono, o esforço humano ficou na casa de dezenas de horas contra dezenas de milhares.
Caveats que precisam ser ditos: é uma POC — não passou por usuários reais, homologação fiscal, pentest externo nem operação em produção; o domínio chegou pré-consolidado num documento excepcional (isso é trabalho que normalmente consome meses de descoberta); e não houve os custos de coordenação de um time real. A comparação justa não é "IA substitui o time", e sim: para transformar uma especificação bem-feita em software verificado, o custo caiu ordens de magnitude.
| Camada | Tecnologia | Versão |
|---|---|---|
| Linguagem backend | Java (LTS) | 21 |
| Framework | Spring Boot | 4.1.0 |
| Modularidade | Spring Modulith | 2.1.0 |
| JSON | Jackson 3 (tools.jackson) |
BOM do Boot |
| Persistência | Spring Data JPA + PostgreSQL | Postgres 16 |
| Migrações | Flyway (starter modular) | BOM do Boot |
| Segurança | Spring Security + OAuth2 Resource Server + Spring Authorization Server embutido | BOM do Boot |
| Sessão/HA | Spring Session JDBC + JWK persistido | BOM do Boot |
| API docs | springdoc-openapi | 3.0.3 |
| Frontend | Angular (standalone, zoneless, signals) | 22.0.x |
| UI kit | PrimeNG (preset Aura) + primeicons + Angular CDK | 21.1.x / 7 / 22 |
| CSS utilitário | Tailwind CSS | 4.3.x |
| i18n front | @ngx-translate/core (loader em memória) | 18 |
| Auth front | angular-oauth2-oidc (Code + PKCE) | 20.0.x |
| Testes backend | JUnit 5 · Testcontainers · ArchUnit · jqwik · PIT | — / 1.21.4 / 1.4.2 / 1.9.2 / 1.17.3 |
| Testes frontend | Vitest (+coverage-v8) · Playwright | 4.x / 1.61.x |
| Qualidade | Spotless (google-java-format) · Checkstyle · JaCoCo · ESLint · Prettier | 3.7.0 / 10.21.4 / 0.8.12 / 10 / 3 |
| Observabilidade | Micrometer + Prometheus + Loki + Grafana Alloy + Grafana | imagens oficiais |
| Infra | Docker Compose (dev / E2E / prod com proxy nginx TLS) | nginx 1.27 |
| CI/CD | GitHub Actions (CI, E2E, CodeQL, GHCR publish) + Dependabot | — |
Guia passo a passo (do zero), para quem nunca instalou: docs/INSTALL.md (English) — pré-requisitos por sistema (Windows/WSL2, Linux, macOS), desenvolvimento, produção, nuvem e solução de problemas. Abaixo, o resumo.
Pré-requisitos: Docker, Node.js LTS (e JDK 21 só para rodar testes).
# 1. Backend + banco + observabilidade
docker compose up --build # servidor em http://localhost:8080
# 2. Frontend (outro terminal)
cd frontend && npm install && npm start # tela em http://localhost:4200Login — usuários de exemplo (senha dev12345, nunca em produção; dados de exemplo já vêm
carregados em dev):
| Usuário | Nome | Papéis | |
|---|---|---|---|
dev |
Dev Admin | todos os papéis | dev@acme-erp.local |
director |
Diana Diretora | Diretor | director@acme-erp.local |
finance |
Fabio Financeiro | Financeiro | finance@acme-erp.local |
ops |
Olivia Operacional | Operacional | ops@acme-erp.local |
it |
Ivo TI | TI | it@acme-erp.local |
policy |
Paula Curadora | Curador de Políticas | policy@acme-erp.local |
viewer |
Vera Leitora | Leitor | viewer@acme-erp.local |
Testes: cd backend && ./mvnw verify (Docker precisa estar de pé — Testcontainers) e
cd frontend && npm run lint && npm test. E2E: npm run e2e:up && npm run e2e.
O deploy de produção é Docker Compose com proxy TLS (compose.prod.yaml
— Postgres sem porta pública, app em perfil prod com fail-fast de segredos, Grafana em
loopback). O processo, em qualquer provedor:
git clone <este-repo> && cd fkerp-java-sdd
cp .env.prod.example .env.prod # preencha TODOS os segredos (instruções no arquivo)
# aponte PUBLIC_DOMAIN ao seu domínio e TLS_CERTS_DIR à pasta com fullchain.pem/privkey.pem
docker compose -f compose.prod.yaml --env-file .env.prod up -d
curl -fsS https://<seu-dominio>/actuator/healthOs segredos exigidos (senha do banco, chave JWK, master key do cofre, HMACs, senha do Grafana)
estão listados com o comando de geração de cada um em
docs/PRODUCTION-CHECKLIST.md; a referência completa de todas
as variáveis de ambiente (com default e onde se aplicam) está em
docs/CONFIGURATION.md. O app recusa subir em prod
com qualquer default de desenvolvimento. Imagens prontas por release estão no GHCR
(BACKEND_IMAGE/FRONTEND_IMAGE); sem elas, o compose builda localmente.
E-mail (opcional). O envio de e-mail (esqueci-senha, convite de usuário) é opcional: sem SMTP
o sistema sobe normalmente e avisa "e-mail não configurado — contate a TI"; a TI ainda cria e
redefine senhas manualmente. Para ligar o envio real, defina MAIL_PROVIDER=smtp +
SPRING_MAIL_HOST/PORT/USERNAME/PASSWORD + MAIL_FROM (tabela completa no
checklist de produção). Vale para qualquer ambiente.
- EC2 (Ubuntu LTS,
t3.large+ recomendado; libere as portas 80/443 no Security Group) — instale Docker (curl -fsSL https://get.docker.com | sh). - DNS: aponte um registro A do seu domínio (Route 53 ou outro) para o IP elástico.
- TLS: emita com Let's Encrypt (
certbot certonly --standalone -d seu.dominio) e aponteTLS_CERTS_DIRpara a pasta dos certificados. - Siga a seção 8.2.
- Opcional: RDS for PostgreSQL no lugar do container — remova o serviço
postgresdo compose e aponteSPRING_DATASOURCE_URL/USERNAME/PASSWORDpara o endpoint do RDS. Backups: aponte o destino offsite do ADR-0021 para um bucket S3 (com versionamento/immutability).
- Compute Engine (
e2-standard-2+, Ubuntu LTS; libere 80/443 com regras de firewall) — instale Docker. - DNS (Cloud DNS ou outro) → IP estático da VM; TLS via certbot, como acima.
- Siga a seção 8.2.
- Opcional: Cloud SQL for PostgreSQL no lugar do container (mesmo ajuste de
SPRING_DATASOURCE_*; use o Auth Proxy ou IP privado). Backups offsite: bucket GCS.
- Virtual Machine (
Standard_D2s_v5+, Ubuntu LTS; libere 80/443 no NSG) — instale Docker. - DNS (Azure DNS ou outro) → IP público; TLS via certbot, como acima.
- Siga a seção 8.2.
- Opcional: Azure Database for PostgreSQL (Flexible Server) no lugar do container (mesmo
ajuste de
SPRING_DATASOURCE_*). Backups offsite: Azure Blob Storage (com immutability).
Por que VM + Compose, e não Kubernetes/serviços gerenciados? Decisão registrada (ADR-0002/ADR-0020, Regra Zero): é um monólito modular com HA opcional por múltiplas instâncias — um orquestrador não resolve nenhum problema que o projeto tenha hoje. O código não depende de SDK de nuvem; migrar de provedor é mover o compose.
fkerp-java-sdd/
├── backend/ # Java 21 + Spring Boot 4.1 (monólito modular, 23 módulos)
├── frontend/ # Angular 22 + PrimeNG 21 + Tailwind 4 → frontend/README.md
├── infra/ # prometheus/ loki/ alloy/ grafana/ proxy/ backup/ wiremock/
├── docs/ # TODA a documentação → docs/README.md (índice-mestre)
├── .claude/ # toolkit do time: 10 skills + agentes (arquiteto, devs, QA) + guarda git
├── docker-compose.yml # dev: app + banco + observabilidade (+ profile emulators)
├── compose.e2e.yaml # stack E2E isolada (Postgres efêmero, frontend :4201)
├── compose.prod.yaml # produção: proxy TLS + perfil prod + rede interna
├── CLAUDE.md # regras operacionais do Claude Code (sempre carregadas)
└── LICENSE # 0BSD
Os documentos-chave, na nova organização:
| Quero… | Leia |
|---|---|
| Entender o negócio/domínio | docs/DOMAIN.md |
| Instalar do zero (passo a passo, leigo) | docs/INSTALL.md · en-US |
| Usar o sistema (manual do usuário) | docs/MANUAL.md · en-US |
| Ver as regras de arquitetura e a stack | docs/architecture/ |
| Ler as especificações | docs/specs/ |
| Ver as decisões (arquitetura / autônomas) | docs/adr/ · docs/decision-log/ |
| Reproduzir o método (o laço por fatia) | docs/TUTORIAL.md · docs/RUN-PHASE.md |
Operar o time de agentes e os comandos / |
docs/GUIA-TIME-CLAUDE.md (didático, do zero) |
| Ver o plano e o que foi executado (com resultados de teste) | docs/ROADMAP.md · docs/ROADMAP-STATUS.md |
| Ver o que mudou em cada versão | CHANGELOG · CHANGELOG en-US |
| Subir produção (pendências do dono) | docs/PRODUCTION-CHECKLIST.md |
| Configurar por variável de ambiente | docs/CONFIGURATION.md |
| Contribuir (fluxo de PR, gates) | CONTRIBUTING.md |
| Reportar vulnerabilidade / política de segredos | SECURITY.md |
| O índice completo da documentação | docs/README.md |
Contribuição e segurança.
mainedevelopsão branches protegidas — mudam só via Pull Request revisado (sem push direto). Veja CONTRIBUTING.md. Encontrou uma falha de segurança? Não abra issue pública — reporte em privado (ver SECURITY.md). Nenhum segredo é commitado (gitleaks +.gitignore); regras em ADR-0023.
Este projeto está sob a licença 0BSD (BSD Zero Clause): use como bem entender — copie, modifique, incorpore em projeto comercial, redistribua — sem nenhuma condição e sem obrigação de atribuição. É o equivalente funcional de domínio público, com validade jurídica sólida.
Sem garantia, sem suporte, sem responsabilidade do autor. O software é fornecido "NO ESTADO EM QUE SE ENCONTRA" (AS IS): a licença 0BSD exclui expressamente todas as garantias (inclusive de adequação a qualquer finalidade) e toda responsabilidade do autor por qualquer dano, de qualquer natureza, decorrente do uso ou do desempenho deste software. Quem usa, usa por sua própria conta e risco. Este repositório é publicado como estudo: não há suporte, não há manutenção prometida e não há atendimento a chamados.
Avisos honestos para quem for usar:
- É uma POC de estudo. Não passou por produção real, usuários reais, homologação fiscal (NFS-e/AFD) nem auditoria de segurança externa. As pendências que só o dono do negócio pode fechar estão em docs/PRODUCTION-CHECKLIST.md.
- Os nomes são fictícios. "Acme Travel" e os portais/fornecedores citados são placeholders.
- Issues e forks são bem-vindos; não há garantia de manutenção ativa (é um estudo publicado).