@vibe2founder/tests2dialects 0.1.0 → 0.2.0

package/podcast/critica2.md

@@ -1 +0,0 @@
-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/reports/01-01-2026_00-45.md

@@ -1,40 +0,0 @@
-# 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

@@ -1,37 +0,0 @@
-# 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

@@ -1,8 +0,0 @@
-# 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

@@ -1,13 +0,0 @@
-# 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

@@ -1,10 +0,0 @@
-# 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

@@ -1,31 +0,0 @@
-# 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

@@ -1,27 +0,0 @@
-# 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

@@ -1,25 +0,0 @@
-# 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

@@ -1,15 +0,0 @@
-# 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.

package/tabela.html

@@ -1,350 +0,0 @@
-<!DOCTYPE html>
-<html lang="pt-BR">
-  <head>
-    <meta charset="UTF-8" />
-    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
-    <title>tests2dialects Testing Framework - Rosetta Stone</title>
-    <script src="https://cdn.tailwindcss.com"></script>
-    <link
-      href="https://fonts.googleapis.com/css2?family=Inter:wght@400;600;700&family=JetBrains+Mono:wght@400;700&display=swap"
-      rel="stylesheet"
-    />
-    <style>
-      body {
-        font-family: "Inter", sans-serif;
-      }
-      .mono {
-        font-family: "JetBrains Mono", monospace;
-      }
-    </style>
-  </head>
-  <body class="bg-slate-50 text-slate-800 p-4 md:p-8">
-    <div class="max-w-7xl mx-auto">
-      <header class="mb-10 text-center">
-        <h1 class="text-3xl md:text-4xl font-bold text-slate-900 mb-2">
-          tests2dialects Testing Framework
-        </h1>
-        <p class="text-lg text-slate-600">Matriz de Tradução Semântica</p>
-      </header>
-
-      <!-- Tabela Principal -->
-      <div class="overflow-x-auto shadow-xl rounded-lg border border-slate-200">
-        <table class="w-full text-left text-sm bg-white">
-          <thead class="bg-slate-900 text-slate-50 uppercase tracking-wider">
-            <tr>
-              <th class="px-6 py-4 font-bold border-r border-slate-700 w-1/5">
-                Conceito / Jest
-              </th>
-              <th
-                class="px-6 py-4 font-bold bg-indigo-900 border-r border-indigo-800 w-1/4"
-              >
-                <div class="flex items-center gap-2">
-                  <span>📐 Matemático</span>
-                  <span class="text-xs opacity-75 font-normal normal-case"
-                    >(Lógico/Funcional)</span
-                  >
-                </div>
-              </th>
-              <th
-                class="px-6 py-4 font-bold bg-emerald-900 border-r border-emerald-800 w-1/4"
-              >
-                <div class="flex items-center gap-2">
-                  <span>📖 Narrativo</span>
-                  <span class="text-xs opacity-75 font-normal normal-case"
-                    >(BDD/Humano)</span
-                  >
-                </div>
-              </th>
-              <th class="px-6 py-4 font-bold bg-amber-900 w-1/4">
-                <div class="flex items-center gap-2">
-                  <span>🛡️ Imperativo</span>
-                  <span class="text-xs opacity-75 font-normal normal-case"
-                    >(Técnico/Contrato)</span
-                  >
-                </div>
-              </th>
-            </tr>
-          </thead>
-          <tbody class="divide-y divide-slate-200">
-            <!-- SEÇÃO: ESTRUTURA BÁSICA -->
-            <tr class="bg-slate-100">
-              <td
-                colspan="4"
-                class="px-6 py-2 font-bold text-xs text-slate-500 uppercase tracking-widest"
-              >
-                Estrutura & Execução
-              </td>
-            </tr>
-            <tr class="hover:bg-slate-50 transition-colors">
-              <td class="px-6 py-4 font-semibold text-slate-700 mono">
-                describe()
-              </td>
-              <td class="px-6 py-4 text-indigo-700 mono font-bold">axiom()</td>
-              <td class="px-6 py-4 text-emerald-700 mono font-bold">
-                intend() / story()
-              </td>
-              <td class="px-6 py-4 text-amber-700 mono font-bold">
-                ensure() / suite()
-              </td>
-            </tr>
-            <tr class="hover:bg-slate-50 transition-colors">
-              <td class="px-6 py-4 font-semibold text-slate-700 mono">
-                it() / test()
-              </td>
-              <td class="px-6 py-4 text-indigo-700 mono font-bold">
-                proof() / lemma()
-              </td>
-              <td class="px-6 py-4 text-emerald-700 mono font-bold">
-                detail() / scenario()
-              </td>
-              <td class="px-6 py-4 text-amber-700 mono font-bold">
-                check() / verify()
-              </td>
-            </tr>
-            <tr class="hover:bg-slate-50 transition-colors">
-              <td class="px-6 py-4 font-semibold text-slate-700 mono">
-                expect(x)
-              </td>
-              <td class="px-6 py-4 text-indigo-700 mono font-bold">
-                implies(x)
-              </td>
-              <td class="px-6 py-4 text-emerald-700 mono font-bold">
-                to(x) / expect(x)
-              </td>
-              <td class="px-6 py-4 text-amber-700 mono font-bold">that(x)</td>
-            </tr>
-
-            <!-- SEÇÃO: MOCKS - CRIAÇÃO -->
-            <tr class="bg-slate-100">
-              <td
-                colspan="4"
-                class="px-6 py-2 font-bold text-xs text-slate-500 uppercase tracking-widest"
-              >
-                Criação de Mocks
-              </td>
-            </tr>
-            <tr class="hover:bg-slate-50 transition-colors">
-              <td class="px-6 py-4 font-semibold text-slate-700 mono">
-                jest.fn()
-              </td>
-              <td class="px-6 py-4 text-indigo-700 mono font-bold">
-                arbitrary() / lambda()
-              </td>
-              <td class="px-6 py-4 text-emerald-700 mono font-bold">
-                dummy() / standIn()
-              </td>
-              <td class="px-6 py-4 text-amber-700 mono font-bold">
-                stub() / mock()
-              </td>
-            </tr>
-            <tr class="hover:bg-slate-50 transition-colors">
-              <td class="px-6 py-4 font-semibold text-slate-700 mono">
-                jest.spyOn()
-              </td>
-              <td class="px-6 py-4 text-indigo-700 mono font-bold">
-                monitor()
-              </td>
-              <td class="px-6 py-4 text-emerald-700 mono font-bold">
-                watch() / shadow()
-              </td>
-              <td class="px-6 py-4 text-amber-700 mono font-bold">
-                inspect() / spy()
-              </td>
-            </tr>
-
-            <!-- SEÇÃO: MOCKS - COMPORTAMENTO -->
-            <tr class="bg-slate-100">
-              <td
-                colspan="4"
-                class="px-6 py-2 font-bold text-xs text-slate-500 uppercase tracking-widest"
-              >
-                Configuração de Mocks
-              </td>
-            </tr>
-            <tr class="hover:bg-slate-50 transition-colors">
-              <td class="px-6 py-4 font-semibold text-slate-700 mono">
-                mockReturnValue(v)
-              </td>
-              <td class="px-6 py-4 text-indigo-700 mono font-bold">
-                yields(v) / mapsTo(v)
-              </td>
-              <td class="px-6 py-4 text-emerald-700 mono font-bold">
-                respondsWith(v)
-              </td>
-              <td class="px-6 py-4 text-amber-700 mono font-bold">
-                forceReturn(v)
-              </td>
-            </tr>
-            <tr class="hover:bg-slate-50 transition-colors">
-              <td class="px-6 py-4 font-semibold text-slate-700 mono">
-                mockResolvedValue(v)
-              </td>
-              <td class="px-6 py-4 text-indigo-700 mono font-bold">
-                convergesTo(v)
-              </td>
-              <td class="px-6 py-4 text-emerald-700 mono font-bold">
-                eventuallyGives(v)
-              </td>
-              <td class="px-6 py-4 text-amber-700 mono font-bold">
-                resolveWith(v)
-              </td>
-            </tr>
-            <tr class="hover:bg-slate-50 transition-colors">
-              <td class="px-6 py-4 font-semibold text-slate-700 mono">
-                mockImplementation(fn)
-              </td>
-              <td class="px-6 py-4 text-indigo-700 mono font-bold">
-                derive(fn)
-              </td>
-              <td class="px-6 py-4 text-emerald-700 mono font-bold">
-                actsLike(fn)
-              </td>
-              <td class="px-6 py-4 text-amber-700 mono font-bold">
-                executes(fn)
-              </td>
-            </tr>
-
-            <!-- SEÇÃO: MOCKS - ASSERÇÕES -->
-            <tr class="bg-slate-100">
-              <td
-                colspan="4"
-                class="px-6 py-2 font-bold text-xs text-slate-500 uppercase tracking-widest"
-              >
-                Validação de Chamadas
-              </td>
-            </tr>
-            <tr class="hover:bg-slate-50 transition-colors">
-              <td class="px-6 py-4 font-semibold text-slate-700 mono">
-                toHaveBeenCalled()
-              </td>
-              <td class="px-6 py-4 text-indigo-700 mono font-bold">
-                .wasEvaluated()
-              </td>
-              <td class="px-6 py-4 text-emerald-700 mono font-bold">
-                .wasCalled()
-              </td>
-              <td class="px-6 py-4 text-amber-700 mono font-bold">
-                .triggered()
-              </td>
-            </tr>
-            <tr class="hover:bg-slate-50 transition-colors">
-              <td class="px-6 py-4 font-semibold text-slate-700 mono">
-                toHaveBeenCalledWith(x)
-              </td>
-              <td class="px-6 py-4 text-indigo-700 mono font-bold">
-                .appliedTo(x)
-              </td>
-              <td class="px-6 py-4 text-emerald-700 mono font-bold">
-                .received(x)
-              </td>
-              <td class="px-6 py-4 text-amber-700 mono font-bold">
-                .calledWith(x)
-              </td>
-            </tr>
-            <tr class="hover:bg-slate-50 transition-colors">
-              <td class="px-6 py-4 font-semibold text-slate-700 mono">
-                toHaveBeenCalledTimes(n)
-              </td>
-              <td class="px-6 py-4 text-indigo-700 mono font-bold">
-                .evaluated(n).times
-              </td>
-              <td class="px-6 py-4 text-emerald-700 mono font-bold">
-                .called(n).times
-              </td>
-              <td class="px-6 py-4 text-amber-700 mono font-bold">
-                .triggeredCount(n)
-              </td>
-            </tr>
-
-            <!-- SEÇÃO: LIFECYCLE -->
-            <tr class="bg-slate-100">
-              <td
-                colspan="4"
-                class="px-6 py-2 font-bold text-xs text-slate-500 uppercase tracking-widest"
-              >
-                Ciclo de Vida (Lifecycle)
-              </td>
-            </tr>
-            <tr class="hover:bg-slate-50 transition-colors">
-              <td class="px-6 py-4 font-semibold text-slate-700 mono">
-                beforeAll()
-              </td>
-              <td class="px-6 py-4 text-indigo-700 mono font-bold">
-                postulate() / setup()
-              </td>
-              <td class="px-6 py-4 text-emerald-700 mono font-bold">
-                background()
-              </td>
-              <td class="px-6 py-4 text-amber-700 mono font-bold">initAll()</td>
-            </tr>
-            <tr class="hover:bg-slate-50 transition-colors">
-              <td class="px-6 py-4 font-semibold text-slate-700 mono">
-                afterAll()
-              </td>
-              <td class="px-6 py-4 text-indigo-700 mono font-bold">
-                conclude()
-              </td>
-              <td class="px-6 py-4 text-emerald-700 mono font-bold">
-                cleanup()
-              </td>
-              <td class="px-6 py-4 text-amber-700 mono font-bold">
-                disposeAll()
-              </td>
-            </tr>
-            <tr class="hover:bg-slate-50 transition-colors">
-              <td class="px-6 py-4 font-semibold text-slate-700 mono">
-                beforeEach()
-              </td>
-              <td class="px-6 py-4 text-indigo-700 mono font-bold">given()</td>
-              <td class="px-6 py-4 text-emerald-700 mono font-bold">
-                before()
-              </td>
-              <td class="px-6 py-4 text-amber-700 mono font-bold">reset()</td>
-            </tr>
-          </tbody>
-        </table>
-      </div>
-
-      <div class="mt-8 grid grid-cols-1 md:grid-cols-3 gap-6">
-        <div class="bg-indigo-50 p-6 rounded-lg border border-indigo-100">
-          <h3 class="font-bold text-indigo-900 mb-2">Exemplo Matemático</h3>
-          <pre class="text-xs text-indigo-800 mono overflow-x-auto">
-const f = arbitrary();
-f.yields(10);
-
-proof("f map", () => {
-  f();
-  implies(f).wasEvaluated();
-});</pre
-          >
-        </div>
-
-        <div class="bg-emerald-50 p-6 rounded-lg border border-emerald-100">
-          <h3 class="font-bold text-emerald-900 mb-2">Exemplo Narrativo</h3>
-          <pre class="text-xs text-emerald-800 mono overflow-x-auto">
-const login = standIn();
-login.respondsWith(true);
-
-scenario("Login", () => {
-  login();
-  to(login).wasCalled();
-});</pre
-          >
-        </div>
-
-        <div class="bg-amber-50 p-6 rounded-lg border border-amber-100">
-          <h3 class="font-bold text-amber-900 mb-2">Exemplo Imperativo</h3>
-          <pre class="text-xs text-amber-800 mono overflow-x-auto">
-const api = stub();
-api.forceReturn(200);
-
-check("API status", () => {
-  api();
-  that(api).triggered();
-});</pre
-          >
-        </div>
-      </div>
-    </div>
-  </body>
-</html>

package/tsconfig.json

@@ -1,22 +0,0 @@
-{
-  "compilerOptions": {
-    "target": "ES2022",
-    "module": "NodeNext",
-    "moduleResolution": "NodeNext",
-    "lib": ["ES2022", "dom"],
-    "types": ["node"],
-    "outDir": "./dist",
-    "strict": true,
-    "noImplicitAny": true,
-    "esModuleInterop": true,
-    "skipLibCheck": true,
-    "forceConsistentCasingInFileNames": true,
-    "declaration": true,
-    "baseUrl": ".",
-    "paths": {
-      "@vibe2founder/tests2dialects": ["./src/index.ts"]
-    }
-  },
-  "include": ["src/**/*", "examples/**/*", "packages/**/*", "types/**/*"],
-  "exclude": ["node_modules"]
-}