@vibe2founder/tests2dialects 0.1.0

package/podcast/critica2.md

@@ -0,0 +1 @@
+Hoje a gente analisa o Readme da One Proof for All, uma biblioteca de testes que propõe dialetos diferentes para cada tipo de problema. O material já faz um ótimo trabalho. Ele apresenta um conceito que é complexo de uma forma bem segmentada. Sim, a clareza é um ponto alto, sem dúvida. A estrutura é bem lógica. Mas eu sinto que dá para ir além. Vamos ver como a gente pode, talvez, elevar a narrativa para que a adoção da ferramenta se torne não só interessante, mas meio que inevitável para o leitor certo. Perfeito. O ponto de partida já me chamou a atenção. A primeira sessão do documento captura o leitor na hora, com a pergunta cansado de descrever quando quer provar, e logo em seguida já joga um quick start de 5 minutos na tela. É uma abordagem que, tipo, valoriza o tempo do desenvolvedor, né? É direta, e eu aprecio isso. Mas, ao pular direto para o como, eu me pergunto se a gente não está perdendo a chance de solidificar o porquê. Principalmente para um público mais sênior, mais cético. O porquê, certo? Exato. O maior diferencial, a tal da filosofia aditiva, que ataca de frente o maior medo de qualquer time. O código legado. Isso, o código legado. Essa filosofia é mencionada quase de passagem e jogada para um link externo. Entendi o que você quer dizer. É como dizer, a solução para o seu maior problema está aqui, mas aí você coloca um obstáculo, mesmo que seja só um clique, na frente dela. Exatamente. Você pede para o leitor sair da página principal para se convencer do argumento mais importante bem no momento em que o ceticismo dele está no auge. Perfeito. A fraqueza, para mim, é que a promessa de segurança e compatibilidade ela não é estabelecida com força suficiente antes de se pedir para o usuário, bom, está lá e rodar um novo pacote. A confiança não foi totalmente construída. O argumento de venda mais poderoso, que é a coexistência pacífica com o legado, ele é mencionado, mas não é provado ali na cara na sessão de abertura. O que é uma chance de ouro perdida? Então a sugestão é trazer a essência da filosofia aditiva para o centro do palco logo no início, transformar a principal objeção do leitor na sua maior fortaleza, tantes mesmo de apresentar a solução técnica. Mas como fazer isso sem deixar a introdução pesada e longa? A gente corre o risco de assustar o leitor com muito texto teórico antes do código. É um equilíbrio delicado, concordo. Não se trata de copiar e colar o documento inteiro da filosofia ali. A chave é mostrar, não contar. Em vez de só dizer que o legado funciona, mostra, traz aquele exemplo de código de coexistência que talvez esteja escondido em outra página para o topo. Ah, boa! Imagina um bloco de código com o Describe do Jest, que todo mundo conhece, e o novo Axion da OneSpecForAll lado a lado, rodando num mesmo arquivo, com um cheque verde gigante em cada um. Isso prova visualmente em três segundos que não tem quebra. A mensagem é instantânea. Não viemos para destruir seu trabalho, viemos para complementar. Exatamente. Gosto muito disso. É visual, é imediato. Elimina a necessidade de um parágrafo longo de explicação. O código fala por si. E para a parte conceitual, a ideia de que o framework é poliglota, mas o deve não precisa ser Isso pode ser uma chamada de uma linha poderosa e tranquilizadora logo depois do exemplo visual Algo como a proposta n que todos aprendam tr idiomas A proposta que seu cientista de dados foque no dialeto matemático e ignore o resto. O framework é poliglota para que seu time não precise ser. Nossa, essa frase muda tudo. Muda. Combinada com a prova visual, muda completamente o enquadramento psicológico. O leitor passa de Ah, é mais uma coisa para aprender para Nossa, isso foi feito para simplificar a vida do meu time. Só então, com essa confiança estabelecida, você apresenta o Quick Start. E a chance dele rodar o NPM em install aumenta exponencialmente. Com certeza. Faz todo sentido. É uma pequena inversão na ordem que tem um impacto enorme na percepção. Primeiro você acalma o medo, depois você apresenta a novidade. Ok, isso resolve a abertura. Mas essa ideia de sobrecarga me leva ao segundo ponto. O documento introduz o conceito dos três dialetes com um diagrama claro de qual dialeto é para você. Eu adorei essa parte. O diagrama é fantástico. É uma ferramenta de navegação brilhante. Ele cria a expectativa de uma jornada personalizada. Tipo, um escolha a sua própria aventura. Sim. O problema é que logo depois de você escolher a sua aventura, o livro te força a ler todos os finais possíveis, um atrás do outro. É uma ótima analogia. Exatamente. Depois do diagrama, o documento descarrega o conteúdo completo dos três caminhos. Cada dialeto vem com sua filosofia, exemplos e uma tabela de API gigantesca. A instrução, você não precisa aprender os três, está lá, mas ela briga diretamente com o layout da página, que te força a rolar por tudo. É uma dissonância cognitiva. A mensagem de simplicidade e especialização é contradita por uma parede de texto que grita complexidade. A riqueza de detalhes apresentada de uma só vez gera o efeito paradoxal de fazer a ferramenta parecer muito mais complicada do que ela realmente é por causa de uso de um único leitor. Com certeza. O David Frontiand, que só precisa do dialeto imperativo, olha para as tabelas do matemático e do narrativo e pensa meu Deus, olha o tamanho dessa ferramenta. Exato. Certo. Então, a fraqueza é a sobrecarga de informação que sabota a própria proposta de valor da ferramenta. A sugestão, imagino, é alinhar a estrutura da documentação com a promessa do diagrama. Aplicar o princípio de revelação progressiva. Na mosca, dê ao leitor o controle para explorar só o que é relevante para ele. E tem várias maneiras de fazer isso, umas mais simples, outras mais elegantes. Tipo? A mais comum e eficaz seria usar componentes interativos. Imagine, logo após o diagrama, três abas. Matemático, narrativo e imperativo. Por padrão, tudo fechado. O leitor clica no dialeto que lhe interessa e só essa seção se expande. As outras, ocultas. Ah, sim. Isso limpa a interface, reduz a ansiedade e dá ao usuário uma sensação de controle e foco. Isso. Eu já vi isso funcionar muito bem em documentações como a do Vue.js, por exemplo. mas também já vi falhar quando o conteúdo dentro de cada aba ainda é muito denso. O segredo talvez não seja só esconder, mas também garantir o que é mostrado inicialmente seja o essencial. Exato Uma alternativa talvez at mais simples de implementar num Readme de GitHub seria usar o QuickStart como fio condutor Certo Como o primeiro exemplo pr usa o dialeto imperativo por que não expandir completamente essa seção no Readme principal? Ela dá continuidade à jornada do leitor. Entendi. E os outros dois? Para os outros dois, você mostra só o aperitivo, a dor que ele resolve, um exemplo de código matador e então um linte claro. Fascinado pelo dialeto matemático, explore sua API completa e exemplos avançados aqui. Isso move a complexidade para uma camada secundária. A página principal fica enxuta, focada na jornada mais comum, mas sem perder a riqueza para quem quer se aprofundar. Gosto dessa segunda opção porque ela cria um caminho feliz bem definido. O leitor iniciante é guiado de ponta a ponta sem distrações, enquanto explorador avançado tem as portas de saída claramente sinalizadas. Ambas as sugestões, no fundo, respeitam o foco e o tempo do leitor, o que é sempre uma boa prática. E essa ideia de respeitar diferentes leitores me leva a pensar. A gente está focando muito no desenvolvedor que vai escrever o código. E o documento faz isso brilhantemente. As sessões A Dor que Resolvemos para cada dialeto criam uma empatia enorme. Sim, elas são ótimas. Mas, e a outra persona? Talvez a mais importante para a adoção da ferramenta. O tomador de decisão, o tech lead, o arquiteto, o gerente de engenharia que precisa aprovar a inclusão de uma nova dependência no package.json. Você tem razão, não tem nada ali para ele. Exato. O documento fala a língua do executor, mas ignora a língua do estrategista. Em muitas equipes, a adoção de uma nova dependência de teste não é uma decisão individual. E essa pessoa que aprova tem um conjunto diferente de perguntas na cabeça. Não é qual sintaxe dessa função, mas sim qual o custo de manutenção disso. Isso vai acelerar ou atrasar meu time? Como isso se alinha com nossos objetivos de negócio? O Readme atual não tem uma sessão que responda essas perguntas de forma concisa. É uma falha crítica. A ausência de um sumário executivo que traduz os benefícios técnicos individuais em vantagens estratégicas para a equipe. Isso pode ser um obstáculo intransponível para a adoção em organizações maiores. Um desenvolvedor pode amar a ferramenta, mas se ele não souber vender a ideia para a liderança, a ferramenta morre na praia. Lembro de uma vez que tentei convencer o meu time a adotar uma ferramenta de LinkedIn nova. Eu passei uma hora na reunião falando sobre como a sentasse era elegante e como as regras eram melhores para mim. No final, meu gerente perguntou, ok, mas como isso nos ajuda a entregar o projeto X mais rápido? E aí? Eu gaguejei. Não tinha resposta. Eu não tinha o argumento estratégico. É uma história clássica. A gente se apaixona pela ferramenta e esquece de construir a ponte para o valor de negócio. Então, a sugestão é clara. Criar uma sessão dedicada a essa persona. Talvez algo como por que adotar no seu time ou o valor estratégico do One Proof for All. Isso. Uma sessão concisa e direta, talvez logo após o Quick Start, que sirva como um arsenal de argumentos. O desenvolvedor que amou a ferramenta pode simplesmente copiar e colar esses pontos no e-mail para o seu líder. E o conteúdo precisa falar a língua da gestão. ROI, risco, produtividade, alinhamento. Exato. Certo Vamos rascunhar como seriam esses argumentos Que tipo de pilares a gente poderia ter nessa sess Eu imagino tr pilares principais O primeiro o ROI de comunica Em vez de s dizer que os testes são legíveis por PMs, enquadra isso como um benefício de negócio. Reduza o ciclo de validação de regras. Com o dialeto narrativo, seus testes se tornam a especificação viva que o time de produto pode aprovar de forma síncrona. Menos reuniões, menos ambiguidade, menos retrabalho. Isso, direto ao ponto. O benefício é quantificável, tempo economizado. O segundo pilar poderia ser sobre a eficiência do time. Exato, produtividade e on-board. Poderíamos falar sobre o custo de capacitação, aceleré à contribuição de novos membros do time. Um cientista de dados júnior pode escrever provas matemáticas robustas em uma semana com o dialeto matemático, sem precisar gastar um mês aprendendo todo o ecossistema de moxistubs do seu front-end. A mensagem é, especialização da ferramenta gera especialização e foco no time, o que leva à produtividade. Perfeito. E o terceiro pilar, para fechar, tem que ser sobre o maior medo de qualquer líder, o risco. Perfeito. O pilar da saúde do código e risco zero. Aqui a gente conecta com o nosso primeiro ponto, a filosofia aditiva, e dá a ela um verniz estratégico. Boa. Adote com risco zero e custo zero. A integração incremental significa que você melhora a clareza de novas funcionalidades imediatamente, sem acumular dívida técnica ou embarcar numa reescrita cara e arriscada dos seus 5 mil testes existentes. Isso é música para os ouvidos de qualquer gerente de engenharia. Sem dúvida. Fantástico. Com uma sessão dessas, o Readme deixa de ser só uma documentação técnica e se torna também uma poderosa ferramenta de vendas internas. Ele equipa o desenvolvedor para ser um campeão da ferramenta dentro da sua organização. É essa a transformação. Um bom Readme ensina a usar. Um ótimo Readme convence a adotar. Para resumir nossa conversa de hoje, então, a estrutura e o conteúdo do Readme da OneSpec for All já são muito fortes. Nossas sugestões focam em refinar a narrativa para maximizar o impacto e principalmente a taxa de adoção. Exato! Primeiro, fortalecer o porquê antes de apresentar o como. Isso significa trazer a prova da filosofia aditiva para o início do documento de forma visual e imediata, em vez de delegá-la a um link. É construir confiança antes de pedir uma ação. Segundo, reduzir a carga cognitiva na apresentação dos dialetos. Alinhar o design da informação com a promessa de especialização, usando um padrão de revelação progressiva para não sobrecarregar o leitor com o conteúdo que é irrelevante para ele. E por fim, adicionar uma nova sessão com foco nos benefícios estratégicos para o time. Criar um argumento poderoso para os tomadores de decisão, falando a língua deles e abordando diretamente suas preocupações com custo, risco e produtividade. São três mudanças que, juntas, podem transformar um ótimo Readme em uma ferramenta de conversão irresistível. Adoraríamos ver a próxima versão deste material e analisar os resultados.

package/readme.md

@@ -0,0 +1,58 @@
+# 🔬 tests2dialects
+
+[![TypeScript](https://img.shields.io/badge/TypeScript-007ACC?logo=typescript&logoColor=white)](https://www.typescriptlang.org/)
+[![Zero Dependencies](https://img.shields.io/badge/Deps-Zero-00d4aa?logo=checkmarx&logoColor=white)](.)
+[![License](https://img.shields.io/badge/License-MIT-purple)](LICENSE)
+[![Bun](https://img.shields.io/badge/Runtime-Bun-f9f1e1?logo=bun&logoColor=black)](https://bun.sh)
+[![Event Sourcing](https://img.shields.io/badge/Pattern-Event_Sourcing-ff6b6b)](.)
+[![Proxy](https://img.shields.io/badge/Engine-ES6_Proxy-ffd93d)](.)
+
+> *@vibe2founder/one-spec-4-all (Polyglot Tester)* — Adoção zero-risco! O framework que unifica diferentes dialetos de TDD e BDD num só lugar e em 1 só runner universal compatível com Jest e Bun!
+
+[🔗 Veja o nosso CHANGELOG.md](CHANGELOG.md) para acompanhar as atualizações mais recentes.
+
+---
+
+## 🚀 Como Funciona
+
+Por conta da segregação de times de uma empresa (Cientistas de Dados, DevOps, Produto, Desenvolvedores Node), unificar as nomenclaturas de "testes" é incômodo e doloroso.
+
+O `tests2dialects` abraça o sistema permitindo multiplos _Dialetos_ no mesmo teste:
+- 📐 **Matemático:** Axiomas e implicações, focado em provas puras (`axiom`, `proof`, `implies`);
+- 📖 **Narrativo:** Contexto focado em regras de negócio para Produto (`intend`, `scenario`, `to_be`);
+- 🛡️ **Imperativo:** Testagem estrita para Contratos e Infra (`ensure`, `verify`, `check`);
+- 🌐 **API:** Declarações de testes para Requests.
+
+```javascript
+import { ensure, check, that, stub } from "@vibe2founder/one-spec-4-all";
+
+ensure("Minhas Regras API - Dialeto Imperativo", () => {
+  const api = stub();
+  
+  check("Criação de usuários correta", () => {
+    that(api.statusCode).is(200);
+  });
+});
+```
+
+---
+
+## 🛠️ Como foi feito
+
+Nosso core foi elaborado na essência *Evidence-first*. Se um código gera bugs mascarados, não usamos! Todo o *mocking* gerado internamente não afunda dependências complexas. Nós empoderamos a ponte base do NodeJS e unificamos num mesmo namespace (`os4all`).
+
+A compatibilidade cross-engine injeta no interpretador global asserções polimórficas. Rodando `bun test` ou rodando sob `npx jest`, as chamadas funcionam lado a lado (sendo o código legado totalmente suportado sem fricção e reescritas longas). 
+
+- Os Eventos e Outputs são roteados centralmente mantendo os Relatórios unificados (One-Evidence-4-All). 
+
+---
+
+## 🧪 Como testar
+
+A ferramenta conta com um runner próprio que delega ações ao motor preferido (Jest/Bun).
+
+1. Exclusivo para testadores de WSL, certifique-se da tipagem.
+2. Inicie via `npx one-spec-4-all` (ou alis `npx os4all` / `bun run os4all`) passando na raíz dos diretórios do seu código principal.
+3. Não use abstrações mágicas! Seu teste deve criar stub seguro de banco e rotas declaratórias.
+
+Para testar **o próprio módulo local**: navegue até o repósitorio raiz, use as regras bases de `$ wsl bun test`, garantindo os comportamentos determinísticos implementados na nossa suite.

package/reports/01-01-2026_00-45.md

@@ -0,0 +1,40 @@
+# Relatório de Reestruturação do README
+
+**Data:** 01/01/2026
+**Hora:** 00:45
+
+## O que foi feito
+
+Reestruturação completa do `readme.md` seguindo as três ações recomendadas no podcast de crítica:
+
+### 1. Unificação da Filosofia com a Prática
+
+- Adicionei uma **nova seção de abertura** ("Cansado de Descrever Quando Quer Provar?") que conecta imediatamente a frustração real do desenvolvedor com a solução do framework.
+- A mensagem da **Filosofia Aditiva** foi trazida do `critica.md` para o topo do README, garantindo que o usuário entenda o "porquê" antes do "como".
+
+### 2. Articulação da Dor Que Cada Dialeto Resolve
+
+Cada dialeto agora começa com uma seção **"A Dor Que Resolvemos"**, que enquadra o problema antes de apresentar a solução:
+
+- **📐 Matemático:** "Você está testando uma função de criptografia pura... Escrever `describe` e `it` soa informal e impreciso."
+- **📖 Narrativo:** "Seu PM precisa validar as regras de negócio, mas não consegue ler seus testes."
+- **🛡️ Imperativo:** "A linguagem do teste não impõe o respeito que o contrato exige."
+
+Isso cria um **gancho emocional** e faz o leitor pensar: "Nossa, sim, eu odeio fazer isso!"
+
+### 3. Caminho de Onboarding Guiado
+
+- **Quick Start em 5 minutos:** Adicionei uma seção no topo para uma "primeira vitória" imediata. O usuário copia, cola, roda e passa. Em 5 minutos ele já está usando o framework.
+- **Fluxograma "Qual Dialeto é Para Você?":** Um diagrama ASCII visual que guia a escolha do dialeto de forma simples.
+- **Tópicos Avançados no final:** A Tabela Rosetta e o Modo Poliglota foram movidos para o final, numa seção de "Tópicos Avançados", limpando o caminho principal para o novato.
+- **Seção de Migração:** Um guia mostrando como adotar o framework gradualmente em uma codebase existente com testes Jest/Mocha.
+
+## Por que foi feito
+
+O podcast de crítica (`critica-Unificar_filosofia_e_prática_na_documentação_...`) identificou três pontos cruciais:
+
+1.  A filosofia do Crítica e Esclarecimento estava desconectada do README.
+2.  Os dialetos eram apresentados sem articular a "dor" que resolvem.
+3.  O README funcionava como enciclopédia, não como tutor de onboarding.
+
+A nova estrutura transforma a documentação de um **manual de referência** para uma **ferramenta de conversão**, guiando o usuário do interesse à adoção de forma fluida e gratificante.

package/reports/01-01-2026_02-30.md

@@ -0,0 +1,37 @@
+# Relatório de Finalização: Core Engine & Exemplos Poliglotas
+
+## O que foi feito?
+
+1.  **Aprimoramento do Motor de Mocks (AtomicMock):**
+
+    - Implementação de **Deep Proxies**: Agora os mocks criados com `standIn`, `stub` ou `arbitrary` suportam acesso automático a propriedades e métodos inexistentes, criando sub-mocks sob demanda.
+    - **Call Bubbling**: Chamadas a métodos de um objeto-mock (ex: `cart.add()`) agora notificam o mock pai, permitindo asserções genéricas como `to(cart).wasCalled()`.
+    - **Data Object Mocking**: O Proxy agora respeita retornos configurados via `respondsWith`/`forceReturn`. Se o mock retornar um objeto real, o acesso a propriedades desse objeto funciona normalmente antes de tentar criar um sub-mock.
+
+2.  **Correção do Ciclo de Vida (AtomicCore):**
+
+    - Corrigida a execução dos hooks `beforeAll` (`initAll`, `background`, `postulate`) e `afterAll`. Antes, o runner simplificado ignorava esses blocos de configuração persistente.
+
+3.  **Refinação da API de Asserções:**
+
+    - Adição de aliases solicitados e implícitos nos exemplos: `.be()` (Narrativo) e `.uploaded()` (Narrativo).
+    - Implementação de `.clear()` (limpar chamadas) vs `.reset()` (limpar tudo) para permitir limpeza de histórico entre testes sem perder configurações de baseline feitas no `initAll`.
+
+4.  **Estabilização dos Exemplos:**
+    - Todos os exemplos na pasta `/examples` foram atualizados para usar caminhos relativos, permitindo a execução local imediata via CLI.
+    - O exemplo poliglota de carrinho de compras foi logicamente conectado para garantir que as interações entre mocks (ex: `cart` chamando `coupon`) sejam verificadas corretamente.
+    - **Resultado**: 100% de sucesso na execução dos testes (5 arquivos, 28 testes).
+
+## Por que foi feito?
+
+Para garantir que a promessa da documentação ("Simple, Semantic, Polyglot") seja sustentada por uma implementação técnica robusta. Os usuários esperam que mocks de objetos funcionem intuitivamente (Deep Mocking) e que o modo poliglota seja prático e confiável.
+
+## Como testar?
+
+Execute o comando no terminal (via WSL):
+
+```bash
+bun run src/cli.ts
+```
+
+Você verá o output estilo Vitest com todos os testes passando com sucesso.

package/reports/03-02-2026_10-55.md

@@ -0,0 +1,8 @@
+# Relatório de Execução
+
+## O que foi feito
+- Adicionada seção "Running API Tests" no `README.md` detalhando como criar e executar testes de API usando o dialeto específico.
+- Atualizado `CHANGELOG.md` com a nova versão `v0.4.1`.
+
+## Por que foi feito
+- Para atender à solicitação de documentar claramente a forma de testar APIs no projeto, facilitando o uso do `ApiSpec`.

package/reports/03-02-2026_11-45.md

@@ -0,0 +1,13 @@
+# Relatório de Execução - Showcase de Funcionalidades
+
+## O que foi feito
+- Criado o arquivo `examples/showcase-api.spec.ts` que demonstra o uso completo do Dialeto de API.
+- Testadas e validadas as seguintes funcionalidades:
+    - Métodos HTTP: `GET`, `POST`, `PUT`, `DELETE`.
+    - Envio de `Headers` customizados.
+    - Validação de `Status Code`.
+    - Validação de `Schema` (cheking de tipos e existência de chaves).
+- Execução realizada com sucesso via `bun` contra a API pública JSONPlaceholder.
+
+## Por que foi feito
+- Para fornecer um exemplo prático "fim-a-fim" que serve tanto como teste de sanidade para o dialeto quanto como documentação viva para o usuário final.

package/reports/03-02-2026_11-50.md

@@ -0,0 +1,10 @@
+# Relatório de Execução - Padronização da Documentação
+
+## O que foi feito
+- Criado o arquivo `docs/api-api.md` contendo a especificação completa do Dialeto de API.
+- O conteúdo foi expandido para incluir tabelas de estrutura, configuração, asserções e um exemplo completo, seguindo o padrão visual e de profundidade dos outros dialetos (`api-matematico`, `api-narrativo`, `api-imperativo`).
+- O arquivo anterior `docs/api-teste-api.md` foi removido (renomeado).
+- Todas as referências no `README.md` foram atualizadas para apontar para `docs/api-api.md`.
+
+## Por que foi feito
+- Para garantir a consistência técnica e visual da documentação do projeto, tratando o Dialeto de API com o mesmo nível de detalhamento dos demais.

package/reports/26-01-2026_16-25.md

@@ -0,0 +1,31 @@
+# Relatório Técnico: Dialeto de Testes de API
+
+**Data:** 26-01-2026
+**Objetivo:** Implementação de um dialeto (DSL) fluído para testes de API utilizando padrões @vibe2founder.
+
+## O que foi feito
+1. **Tipagem Semântica Nominal**: Criação de tipos específicos em `types/api-types.ts` para garantir que primitivos não sejam usados arbitrariamente.
+2. **Implementação do @vibe2founder/request2http (Local)**: Wrapper minimalista sobre o `fetch` nativo do Bun, evitando dependências externas como Axios, conforme as regras do projeto.
+3. **DSL de Testes (ApiSpec)**: Implementação da classe `ApiTestDialect` que permite a definição de testes de forma declarativa e legível (Given/When/Then pattern).
+4. **Validação de Schema**: Sistema local básico para validação de estrutura de resposta sem bibliotecas externas.
+5. **Demonstração**: Script em `examples/test-api.ts` validando o funcionamento contra a API JSONPlaceholder.
+
+## Por que foi feito
+A criação de um dialeto específico simplifica a escrita de testes de integração, tornando-os autodocumentados e garantindo que sigam as premissas de invariantes do sistema. O uso de implementações locais e tipos nominais reforça a segurança e a manutenibilidade do código, evitando "leakage" de dependências externas e garantindo que os dados trafegados nas APIs sejam semanticamente corretos.
+
+## Como funciona
+O dialeto utiliza encadeamento de métodos (chaining):
+```typescript
+await ApiSpec.define("Nome do Teste")
+  .from("URL_BASE")
+  .get("/rota")
+  .shouldReturn(200)
+  .matchingSchema({ chave: "tipo" })
+  .run();
+```
+
+## Como testar
+Execute o comando via WSL:
+```bash
+bun run examples/test-api.ts
+```

package/reports/26-01-2026_19-20.md

@@ -0,0 +1,27 @@
+# Relatório de Refatoração: One Proof for All
+
+**Data:** 26-01-2026
+**Objetivo:** Refatoração completa do nome do projeto e estabilização do ambiente de testes ESM.
+
+## O que foi feito
+1. **Renaming de Marca**: O projeto foi renomeado de `@vibe2founder/one-spec-4-all` para `@vibe2founder/tests2dialects` em todos os arquivos de configuração (`package.json`, `tsconfig.json`).
+2. **Correção de Módulos ESM**:
+   - Adicionada extensão `.js` em todos os imports relativos conforme exigido pelo modo `NodeNext` do TypeScript.
+   - Corrigido o tipo `Timer` para `ReturnType<typeof setInterval>` no CLI para compatibilidade com tipos de ambiente variados.
+3. **Isolamento de Testes**:
+   - Implementado o m├©todo `resetAtomicCore()` para garantir que o estado do singleton `AtomicCore` seja limpo entre a execu├º├úo de diferentes arquivos de especifica├º├úo no CLI.
+   - O CLI agora importa e reseta o motor antes de cada arquivo, evitando vazamento de nomes de grupos e testes.
+4. **Melhoria no Report do CLI**:
+   - Logs de passagem/falha agora incluem o caminho completo (`Grupo > Teste`), permitindo que o CLI extraia nomes precisos mesmo em execu├º├Áes ass├¡ncronas.
+5. **Tipagem Semàntica de Mocks**:
+   - Criada a interface `AtomicMock` que integra todos os m├©todos dos dialetos (Matem├itico, Narrativo, Imperativo) via Proxy, resolvendo todos os erros de lint nos arquivos de exemplo.
+
+## Por que foi feito
+A mudan├ºa para "One Proof for All" reflete melhor a natureza axiom├itica e de "prova de conceito" (proof) dos dialetos. As corre├º├Áes t├©cnicas foram necess├irias para garantir um fluxo de desenvolvimento fluido e sem erros de build, respeitando as regras de tipagem nominal do vibe2founder.
+
+## Como testar
+Para validar a instalação e refatoração, execute:
+```bash
+wsl bun run src/cli.ts
+```
+O resultado deve listar 5 arquivos de teste e 28 testes passando com nomes isolados.

package/reports/31-12-2025_22-35.md

@@ -0,0 +1,25 @@
+# Relatório de Atualização de Documentação
+
+**Data:** 31/12/2025
+**Hora:** 22:35
+
+## O que foi feito
+
+1.  **Refatoração do Código Fonte (`src/index.ts`):**
+
+    - Adicionadas exportações de nível superior (top-level exports) para todas as funções dos dialetos (Matemático, Narrativo, Imperativo).
+    - Isso permite importar funções diretamente (ex: `import { axiom } from ...`) em vez de desestruturar de um objeto exportado.
+
+2.  **Atualização do README:**
+
+    - Expandida a descrição filosófica de cada dialeto para fornecer mais contexto sobre _quando_ e _por que_ usar cada um.
+    - Substituídos os exemplos antigos e simples por **exemplos completos e realistas**.
+    - Os novos exemplos demonstram uso de mocks, lifecycle hooks (`given`, `background`, `initAll`) e asserções mais complexas.
+    - Corrigidos os `import` nos exemplos para usar o nome correto do pacote (`@vibe2founder/tests2dialects`) e a nova sintaxe de exportação direta.
+
+3.  **Documentação de Mudanças:**
+    - Criado o arquivo `CHANGELOG.md` para rastrear as alterações.
+
+## Por que foi feito
+
+O usuário solicitou descrições mais detalhadas e exemplos mais completos para cada seção do README. Para atender a isso com qualidade, percebeu-se que a API exposta no código (`src/index.ts`) não correspondia à ergonomia desejada nos exemplos (importações diretas). Portanto, o código foi ajustado para suportar a documentação melhorada, garantindo que os usuários possam copiar e colar os exemplos e ter um código funcional.

package/reports/31-12-2025_22-45.md

@@ -0,0 +1,15 @@
+# Relatório de Conversão de Tabela
+
+**Data:** 31/12/2025
+**Hora:** 22:45
+
+## O que foi feito
+
+1.  **Conversão de Tabela HTML para Markdown (`readme.md`):**
+    - A tabela de comparação ("Rosetta Stone"), que estava em formato HTML puro dentro do README, foi convertida manualmente para o formato de tabela Markdown nativo do GitHub.
+    - Mantive a estrutura de colunas e categorização.
+    - Utilizei separadores visuais nas linhas (`--- Estrutura ---`) para emular as seções que existiam na tabela HTML.
+
+## Por que foi feito
+
+O usuário solicitou explicitamente a transformação do bloco HTML inserido anteriormente para Markdown (`transforme em md`). Tabelas em Markdown são mais "portáveis", fáceis de editar diretamente no código-fonte e renderizam de forma mais consistente em diferentes visualizadores de Markdown, além de manter o arquivo `readme.md` mais limpo e sem mistura excessiva de HTML e Markdown.