# Release Notes v4.0.0

Data de lançamento: 24/08/2026

## 🆕 Resumo

Versão com **mudanças incompatíveis** no `Tooark.Notifications`, `Tooark.Mediator`, `Tooark.Observability`, `Tooark.Validations`, `Tooark.Securities`, `Tooark.Exceptions`, `Tooark.Extensions`, `Tooark.Enums`, `Tooark.Attributes`, `Tooark.Utils` e `Tooark.Dtos`, com o **pipeline de behaviors** no Mediator e com os **novos pacotes `Tooark.Mediator.EntityFrameworkCore`**, que move a persistência do Entity Framework Core para a esteira do pipeline, **e `Tooark.AspNetCore`**, que concentra o que depende de ASP.NET Core e devolve os demais pacotes à condição de uso geral. No Validations, CPF e CNPJ passaram a exigir dígitos verificadores e o CNPJ passou a aceitar letras, acompanhando o formato alfanumérico vigente desde julho de 2026; validações que estouravam com valor nulo passaram a reprovar a entrada. No Notifications, criar e limpar notificações passou a ser operação protegida, impedindo que código externo fabrique erros em uma entidade ou apague o resultado de uma validação. No Mediator, as opções passaram a ser recebidas pelo padrão Options, requisições com mais de um manipulador falham no registro e `IPipelineBehavior` passou a permitir tratar preocupações transversais fora dos manipuladores. No Observability, o sinalizador global de dados sensíveis foi renomeado para eliminar a ambiguidade com as opções granulares de mesmo nome. Acompanha as correções de segurança do `Tooark.Securities`, que eliminam comportamentos silenciosos (fallback de chave, troca de algoritmo, quebra de round-trip no modo legado), categorizam corretamente os erros de validação JWT e modernizam o dispatch de tokens para o `JsonWebTokenHandler`, que passou a ser alcançável também por `ValidateAsync`, sem a espera bloqueante. No Utils, o idioma atual deixou de ser um estado global do processo, que fazia o idioma de uma requisição vazar para as demais, e a conversão de um upload para `MemoryStream` passou a copiar o conteúdo binário, que antes era lido como texto e devolvia nulo para qualquer arquivo real. O `FileConvert` também recebeu um endurecimento de segurança: a extensão extraída passou a ser validada como extensão, e a conversão passou a ter limite de tamanho, fechando um caminho de travessia de diretório e um de esgotamento de memória. No Attributes, os seis atributos deixaram de gravar a mensagem de erro no próprio atributo — estado que o framework de validação compartilha entre requisições concorrentes e que descartava a mensagem configurada pelo consumidor. No Extensions, os arquivos de tradução passaram a cobrir **todas** as mensagens emitidas pelos pacotes Tooark — antes 73 chaves saíam como texto cru — e o localizador deixou de fixar no cache os parâmetros da primeira consulta feita em um idioma sem arquivo próprio. No Dtos, a última página de uma listagem deixou de ser inalcançável pelos links de navegação, e o tamanho da página ganhou um teto — sem ele, uma única requisição podia pedir todos os registros. Inclui também a atualização das referências do repositório renomeado para `tooark-cs`.

Como esta versão já carrega quebras de compatibilidade, foram aplicadas as correções de design que dependiam de uma major e estavam represadas desde a v3.3.4.

---

## ⚠️ Mudanças Incompatíveis (Tooark.Mediator)

- **O `Mediator` recebe `IOptions<MediatorOptions>` no lugar de `MediatorOptions`**: o registro de `MediatorOptions` direto no container existia apenas para não quebrar o construtor na v3.3.4 e congelava as opções fora do pipeline de Options. Esse registro foi removido. **O que fazer**: configure por `AddTooarkMediator(options => ...)` ou `services.Configure<MediatorOptions>(...)`; para resolver as opções, use `IOptions<MediatorOptions>`. Registrar `MediatorOptions` diretamente no container deixou de ter efeito — inclusive silenciosamente, então vale conferir quem fazia isso.
- **Requisição com mais de um manipulador falha no registro**: uma requisição é processada por um único manipulador, resolvido do container no despacho. Com mais de um registrado, o container devolvia o último e os demais nunca executavam, sem qualquer aviso. `AddTooarkMediator` passa a lançar `Handler.Duplicated`, identificando a requisição e os manipuladores em conflito. **O que fazer**: remover o manipulador duplicado. Notificações seguem aceitando quantos manipuladores forem registrados.

## ⚠️ Mudanças Incompatíveis (Tooark.Validations)

- **CPF e CNPJ passaram a exigir dígitos verificadores**: `IsCpf`, `IsCnpj`, `IsCpfCnpj`, `IsCpfRg` e `IsCpfRgCnh` validavam apenas o formato, então `123.456.789-00` era aceito como CPF. Agora o documento precisa também conferir no cálculo do dígito. **O que fazer**: dados já gravados que passavam apenas pelo formato passam a ser reprovados na próxima validação — vale conferir a base antes de subir. Sequências de um único caractere repetido (`111.111.111-11`, `00.000.000/0000-00`) também são rejeitadas: elas satisfazem o módulo 11 e eram aceitas.
- **O CNPJ aceita letras**: o formato passou a admitir caracteres alfanuméricos nas doze primeiras posições, conforme o CNPJ alfanumérico vigente desde julho de 2026. Quem persiste CNPJ em coluna numérica ou aplica máscara apenas de dígitos precisa acomodar letras. A caixa é normalizada, então `12.abc.345/01DE-35` é aceito.
- **`IsRg` e `IsCnh` passaram a conferir o dígito verificador**, e não apenas o formato. O ecossistema estava dividido: o value object `Rg` reprovava dígito incorreto, por passar pelo `EDocumentType`, enquanto `new Validation().IsRg(...)` aprovava — duas APIs da mesma biblioteca com veredictos diferentes sobre o mesmo documento. **O que fazer**: RG e CNH gravados com dígito incorreto passam a ser reprovados. O dígito do RG continua opcional: informado sem ele, o documento é aceito.
- **`AreEquals` e `AreNotEquals` de listas passaram a comparar conteúdo**: comparavam referência, então duas listas de conteúdo idêntico eram reportadas como diferentes. Comparações que dependiam do comportamento antigo mudam de resultado.
- **Código de notificação dos documentos com dígito verificador** mudou de `T.VLD.RGX1` para `T.VLD.DOC1`, já que a validação deixou de ser apenas por expressão regular. Vale para todas as validações de documento — `IsCpf`, `IsCnpj`, `IsCnh`, `IsRg`, `IsCpfCnpj`, `IsCpfRg` e `IsCpfRgCnh`. **O que fazer**: ajustar quem filtra notificações por esse código.
- **IPv6 comprimido passou a ser válido**: `::1` e `2001:db8::1` eram reprovados porque o padrão exigia a forma completa. Validações que contavam com essa reprovação mudam de resultado. O padrão de `IP` composto acompanha a correção.
- **Padrão de URL ancorado no final**: sem a âncora, qualquer sufixo era aceito após uma URL válida. O padrão passou a aceitar explicitamente query string e fragmento, mantendo as URLs legítimas válidas.

## ⚠️ Mudanças Incompatíveis (Tooark.Observability)

- **`ObservabilityOptions.DataSensitive` renomeado para `AllowSensitiveData`**: o nome `DataSensitive` designava duas coisas diferentes na mesma árvore de configuração — na raiz, um `bool` que **desliga** a sanitização; em `Tracing`, um objeto cujo `HideQueryParameters` **liga** a sanitização. A chave antiga não é mais lida. **O que fazer**: renomear a chave em `appsettings.json` e no código. A migração esquecida falha para o lado seguro: sem o bind, a propriedade fica no default `false` e a sanitização passa a ser aplicada.

## ⚠️ Mudanças Incompatíveis (Tooark.Notifications)

- **Criar e limpar notificações passou a ser protegido**: `AddNotification` (todas as sobrecargas), `AddNotifications(ICollection<NotificationItem>)` e `Clear()` deixaram de ser públicos. Como `Notification` é a base de `BaseEntity`, `ValueObject` e `Validation`, qualquer código externo podia injetar erros em uma entidade e, principalmente, chamar `entidade.Clear()` e fazer uma entidade inválida parecer válida. Continuam **públicas** as sobrecargas de agregação `AddNotifications(Notification)` e `AddNotifications(params Notification[])`, que compõem notificações já existentes — o cenário legítimo de uso externo. **O que fazer**: mover a chamada para dentro do próprio objeto que notifica, ou agregar via `AddNotifications`.
- **`Count` mudou de `long` para `int`**: o valor vem de uma lista em memória e nunca ultrapassa `int.MaxValue`. **O que fazer**: ajustar atribuições explicitamente tipadas como `long` (a conversão implícita para `long` continua válida).
- **Mensagem nula, vazia ou em branco gera uma única mensagem**: antes, mensagem nula em `NotificationItem` gerava `Notifications.MessageUnknown` e mensagem vazia via `AddNotification` gerava `Notifications.MessageNullEmpty`. Agora todos os casos geram `Notifications.MessageNullEmpty`, e a constante `NotificationErrorMessages.MessageUnknown` foi **removida** — a biblioteca não emite mais essa chave, então mantê-la só acumularia API sem uso. **O que fazer**: substituir referências à constante por `MessageIsNullOrEmpty` e remover o mapeamento de `Notifications.MessageUnknown` dos arquivos de tradução.
- **Mensagem vazia deixou de existir**: `new NotificationItem("")` retornava `Message` vazia; agora retorna `Notifications.MessageNullEmpty`.

## ⚠️ Mudanças Incompatíveis (Tooark.Securities)

- **`IJwtTokenService` ganhou `ValidateAsync`**: o handler da Microsoft.IdentityModel expõe a validação apenas de forma assíncrona, então a única sobrecarga existente encapsulava uma espera bloqueante — sem alternativa para quem já está em fluxo assíncrono. `ValidateAsync` passou a ser o caminho direto ao handler e `Validate` virou o encapsulamento síncrono dele, com resultado idêntico. **O que fazer**: quem apenas consome o serviço não precisa mudar nada; quem **implementa** `IJwtTokenService` (dublês de teste artesanais, implementações próprias) precisa implementar o novo membro. Dublês criados com Moq ou similar seguem funcionando sem alteração.
  - Não há `CreateAsync`: o handler cria o token de forma síncrona, e uma sobrecarga assíncrona ali seria assíncrona apenas na aparência.
  - `ICryptographyService` segue somente síncrono: `Encrypt` e `Decrypt` são AES em memória, sem operação de I/O que justifique a assinatura assíncrona.

## 🆕 Novo pacote: Tooark.AspNetCore

O `Microsoft.AspNetCore.App` não é uma dependência NuGet comum: declará-lo faz a aplicação **exigir o runtime
do ASP.NET Core instalado**, e o requisito é contagioso — propaga para todo pacote que referencia, e para
quem referencia esses.

Até a v3 esse requisito vinha do `Tooark.Extensions`, por causa de **um único arquivo** de trinta linhas, o
`ModelStateExtension`. Um aplicativo de console que só usasse o `Tooark.ValueObjects` recebia
`Microsoft.AspNetCore.App` no próprio `runtimeconfig.json` e não subia em uma imagem
`mcr.microsoft.com/dotnet/runtime`.

O `ModelStateExtension` passou para o `Tooark.AspNetCore`, e o efeito foi medido em um aplicativo de console
que referencia apenas o `Tooark.ValueObjects`:

```json
// antes                                    // depois
"frameworks": [                             "framework": {
  { "name": "Microsoft.NETCore.App" },        "name": "Microsoft.NETCore.App"
  { "name": "Microsoft.AspNetCore.App" }    }
]
```

Situação por pacote a partir da v4.0.0:

| Pacote               | Exige o runtime do ASP.NET Core                                                    |
| -------------------- | ---------------------------------------------------------------------------------- |
| `Tooark.AspNetCore`  | **sim** — é o propósito dele                                                       |
| `Tooark.Dtos`        | **sim** — `SearchDto`, `PaginationDto` e `ResponseDto` usam tipos do MVC e do Http |
| `Tooark` (agregador) | **sim** — por referenciar os dois acima                                            |
| Todos os demais      | **não**                                                                            |

**O que fazer**: quem usa `ModelState.GetErrors()` precisa instalar o `Tooark.AspNetCore` e trocar o
`using Tooark.Extensions` por `using Tooark.AspNetCore.Extensions`. Quem usa o agregador `Tooark` não muda
nada. Os demais deixam de exigir o runtime do ASP.NET Core, o que só amplia onde os pacotes rodam.

O `Tooark.Dtos` passou a **declarar** o framework compartilhado, que antes chegava por transitividade do
`Tooark.Extensions` — era o caso de dependência usada sem declarar registrado na revisão. Com isso, o pacote
avulso `Microsoft.AspNetCore.Http` da linha 2.x saiu do `.csproj`. Se `SearchDto`, `PaginationDto` e
`ResponseDto` devem morar no `Tooark.AspNetCore` é decisão da revisão do `Tooark.Dtos`.

## ⚠️ Mudanças Incompatíveis (Tooark.Dtos)

- **`SearchDto.PageSize` passou a ter um teto**, definido por `PageSizeMax` e valendo 100 por padrão. Antes o valor era aceito sem limite: `PageSize = long.MaxValue` passava, e uma única requisição podia pedir a base inteira. **O que fazer**: um endpoint que precise de páginas maiores sobrescreve o limite no próprio DTO, com `protected override long PageSizeMax => 5000;`. Use a forma de expressão — uma propriedade automática com inicializador não serve, porque o limite é consultado pelo construtor da classe base.
- **`PaginationDto.Next` passou a alcançar a última página.** A condição de parada tinha um `+1` a mais, e a última página nunca aparecia na navegação: com `Total=100` e `PageSize=10`, a página 9 não apontava para a 10. **O que fazer**: nada, mas respostas de API existentes passam a trazer `next` e `nextLink` onde antes vinham nulos.
- **`ResponseDto.Errors` e `ResponseDto.Metadata` passaram a ser `IReadOnlyList<T>`**, com coleções que rejeitam alteração. Antes eram `IList<T>` e podiam ser alteradas de fora, inclusive depois da resposta pronta. **O que fazer**: use `SetMetadata` e `AddMetadata`; atribuições tipadas como `IList<T>` param de compilar.
- **`ResponseDto(T?, int, HttpRequest)` passou a receber `long`**, acompanhando o `Total` do `PaginationDto`. Compatível em código-fonte; exige recompilação.
- **`MetadataDto` deixou de descartar o valor quando a chave é vazia.** Chave e valor passaram a ser independentes: `new MetadataDto("", "azul")` guardava `Value` vazio e agora guarda `"azul"`.
- **`SearchOrderDto.OrderBy` passou a ser `string?`**, refletindo que ele nasce sem valor. Antes era declarado não anulável e inicializado com `null!`.
- **`AddTooarkDtos` deixou de registrar `IStringLocalizer` como `StringLocalizer<Dto>`.** O registro sobrescrevia o do `AddJsonStringLocalizer`, e o tipo resolvido passava a depender da ordem das chamadas. **O que fazer**: nada — o localizador resolvido continua sendo o do Tooark, agora independente da ordem.

## ⚠️ Mudanças Incompatíveis (Tooark.Extensions)

- **`ModelStateExtension` saiu do pacote** para o novo `Tooark.AspNetCore`. Ver a seção acima.
- **O `IDistributedCache` deixou de ser exigido.** `JsonStringLocalizerExtension` e `JsonStringLocalizerFactory` passaram a ter construtor sem parâmetros, e o `AddJsonStringLocalizer` não chama mais `AddDistributedMemoryCache()`. **Por quê**: as traduções passaram a ser indexadas por chave em memória, então a consulta ao cache distribuído virou uma camada na frente de uma busca em dicionário — com um cache remoto, como o Redis, era uma ida à rede por mensagem traduzida para buscar o que já estava no processo. **O que fazer**: quem construía o localizador manualmente remove o argumento; quem depende de `AddDistributedMemoryCache()` registrado como efeito colateral precisa chamá-lo por conta própria.

- **O idioma `pt-PT` deixou de ser distribuído.** Ficam `en-US`, `es-ES` e `pt-BR`. O português europeu era idêntico ao brasileiro em todas as chaves, então mantê-lo dobrava o trabalho de tradução sem entregar diferença. **O que fazer**: nada, se `pt-PT` não era usado. Quem o usava passa a receber as mensagens em `en-US`, o idioma padrão, e pode restaurar o comportamento anterior colocando um `Resources/pt-PT.json` próprio na aplicação — o mecanismo de arquivo adicional continua valendo para qualquer idioma.
- **`LocalizedString.ResourceNotFound` passou a refletir a realidade.** Era sempre `false`, inclusive para chave inexistente, porque a comparação era feita contra um valor que nunca era nulo. Agora é `true` quando a chave não existe em nenhum dos dois idiomas consultados. **O que fazer**: código que ignorava a propriedade não muda; código que a usava recebia sempre `false` e passa a receber o valor correto.
- **Chave inexistente passou a devolver o texto recebido inteiro**, e não apenas o trecho anterior ao primeiro ponto e vírgula. É o comportamento do `ResourceManagerStringLocalizer` do framework, onde `Value` coincide com `Name` quando o recurso não existe. Na prática, um texto que não é chave do Tooark — como as mensagens que o model binding do ASP.NET Core gera — passa pelo localizador sem ser truncado.
- **Os conversores de caixa de `StringExtensions` deixaram de devolver nulo.** `FromSnakeToPascalCase`, `FromSnakeToCamelCase`, `FromSnakeToKebabCase`, `FromPascalToSnakeCase`, `FromCamelToSnakeCase` e `FromKebabToSnakeCase` devolviam o próprio valor recebido quando ele era nulo, apesar do retorno declarado como não anulável. Passam a devolver string vazia, e os parâmetros passaram a ser declarados como anuláveis.

- **O pacote passou a exigir o runtime do ASP.NET Core**: os tipos do ASP.NET Core vinham de pacotes NuGet avulsos da linha 2.x, que funcionavam em qualquer aplicação; agora vêm do framework compartilhado, declarado por `FrameworkReference`. A mudança elimina a árvore transitiva legada — incluindo o `Newtonsoft.Json` vulnerável — e alinha o pacote à orientação atual para bibliotecas de ASP.NET Core. **O que fazer**: aplicações de console ou worker que consomem o `Tooark.Extensions` (direta ou indiretamente, via `Tooark.ValueObjects`, `Tooark.Entities` ou o agregador `Tooark`) precisam do runtime do ASP.NET Core instalado. Compilação e execução seguem normais; o que muda é o pré-requisito registrado no `runtimeconfig.json`. Em imagens de contêiner, use a base `aspnet` em vez da `runtime`.

- **Os arquivos de idioma passaram a ser embutidos no assembly**, em vez de distribuídos como `contentFiles`. O alvo de MSBuild que os READMEs mandavam colar no `.csproj` **deve ser removido**: ele não é mais necessário e é ativamente nocivo, porque copia arquivos de versões antigas que ainda estejam no cache global do NuGet. **O que fazer**: apague o `Target Name="CopyNugetContentFiles"` do seu projeto. A sobrescrita por `Resources/{idioma}.json` continua funcionando igual, mesclada chave a chave sobre o arquivo embutido.

## ⚠️ Mudanças Incompatíveis (Tooark.Exceptions)

- **`GetErrorMessages()` e `GetNotifications()` passaram a devolver coleções somente leitura**: devolviam as listas internas, então `excecao.GetErrorMessages().Clear()` esvaziava o erro que a exceção carregava — uma falha desaparecia no meio do tratamento, e o `Message` ficava dessincronizado da lista. É o mesmo defeito de encapsulamento corrigido no `Tooark.Notifications`. O retorno mudou de `IList<T>` para `IReadOnlyList<T>`. **O que fazer**: leitura por índice, `Count` e `foreach` continuam iguais; quem atribuía o retorno a uma variável `IList<T>` precisa trocar o tipo, e quem alterava a coleção deve construir uma nova exceção.
- **`Microsoft.AspNetCore.Mvc` deixou de ser dependência**: o pacote não usava nada de ASP.NET Core — o código HTTP sempre veio de `System.Net.HttpStatusCode`, do próprio runtime. Como `Tooark.Exceptions` é dependência de quase todo o ecossistema, o meta-pacote legado do ASP.NET Core 2.x chegava em praticamente todo consumidor. **O que fazer**: aplicações que usavam tipos do ASP.NET Core contando com essa dependência transitiva precisam referenciá-lo explicitamente.

## ⚠️ Mudanças Incompatíveis (Tooark.Enums)

- **Conversão de instância nula passou a lançar**: `(int)` e `(string)` sobre um `ECloudProvider`, `EDocumentType` ou `EFileType` nulo estouravam `NullReferenceException` sem contexto. Passam a lançar `InternalServerErrorException` com `Invalid.Parameter;null`, o mesmo erro já usado pelos enums do `Tooark.Observability` — não existe id nem descrição correta para devolver, e devolver zero seria inventar um dado.
- **`ECloudProvider` deixou de diferenciar caixa**: `"aws"` resolvia para `None` enquanto `"AWS"` resolvia para `Amazon`, e os outros dois enums já normalizavam. Uma chave de `appsettings.json` escrita em minúsculo virava "nenhum provedor" sem aviso. Os três passaram a normalizar caixa e espaços das extremidades. **O que fazer**: configurações que dependiam da reprovação por caixa mudam de resultado.
- **`EDocumentType.RG` e `EDocumentType.CNH` passaram a usar o mesmo cálculo do `Tooark.Validations`**, e não mais implementações próprias. O comportamento de validade é o mesmo; o que muda é a origem do cálculo.
- **O pacote passou a depender do `Tooark.Exceptions`**, necessário para o erro de conversão de instância nula. O `Tooark.Exceptions` já chegava por transitividade em quem usa o `Tooark.Enums`, através do `Tooark.Validations`, então a árvore de dependências do consumidor não muda de tamanho.

## ⚠️ Mudanças Incompatíveis (Tooark.Attributes)

- **A mensagem de erro deixou de ser gravada em `ErrorMessage`** e passa a vir no `ValidationResult` de cada validação. O framework de validação reaproveita a mesma instância do atributo em todas as validações daquele campo, então gravar nela era escrever em estado compartilhado. **O que fazer**: código que lia `atributo.ErrorMessage` depois de chamar `IsValid` precisa usar `GetValidationResult(valor, contexto)?.ErrorMessage`. Quem consome pelo `Validator`, pelo ModelState ou pelo MVC não muda nada — passa a receber a mensagem correta.
- **`ErrorMessage` e `ErrorMessageResourceName` configurados no atributo passaram a ser respeitados.** Antes eram sobrescritos na primeira falha, e a mensagem do consumidor era descartada em definitivo — a instância é cacheada e nunca mais voltava ao valor original. **O que fazer**: quem configurou mensagem própria e se acostumou a receber `Field.Invalid;...` passa a receber a mensagem que configurou.
- **Tipo de documento não reconhecido passou a lançar.** `[DocumentValidation("CPFF")]`, um erro de digitação, virava `EDocumentType.None` e **aceitava qualquer valor**, desligando a validação inteira sem aviso. Agora lança `InternalServerErrorException` na primeira validação, com `Attributes.DocumentTypeUnknown;{tipo}`. `None` continua aceito quando pedido explicitamente. **O que fazer**: corrigir o tipo escrito no atributo.
- **Link de vídeo sem nenhum provedor habilitado passou a lançar**, em vez de reprovar todo valor. A configuração não tinha interpretação possível: nenhum link poderia ser aceito.
- **Os critérios do `PasswordValidationAttribute` passaram a valer como configurados.** Desabilitar todos aplicava silenciosamente a complexidade completa, e comprimento menor que 8 era elevado para 8. Agora "nenhum critério" significa exigir apenas o comprimento — política legítima de frase secreta — e o comprimento informado é respeitado. **O que fazer**: quem passava `length` abaixo de 8 contando com a elevação precisa informar 8; quem desabilitava todos os critérios contando com a complexidade completa precisa habilitá-los.
- **Valor composto apenas por espaços passou a ser tratado como ausente**, resultando em `Field.Required` em vez de `Field.Invalid`, acompanhando a mesma correção feita no `Tooark.Notifications`.
- **`DocumentValidationAttribute` passou a receber o tipo como texto**: o construtor recebia `EDocumentType`, que é uma classe e portanto **não é um tipo de parâmetro de atributo válido** — nenhuma forma de aplicar o atributo compilava, com `CS0181`. O recurso era público e inutilizável. **O que fazer**: use `[DocumentValidation("CPF")]`; os valores aceitos são `CPF`, `RG`, `CNH`, `CNPJ`, `CPF_CNPJ`, `CPF_RG` e `CPF_RG_CNH`, sem diferenciar caixa.

## ⚠️ Mudanças Incompatíveis (Tooark.Utils)

- **`Language.Current` e `Language.CurrentCulture` passaram a acompanhar o fluxo de execução**, e não mais um campo estático do processo. O idioma definido por uma requisição vazava para todas as outras: em uma API multi-idioma sob carga, uma requisição em `pt-BR` podia receber as mensagens no idioma de uma requisição concorrente. Como o `JsonStringLocalizerExtension` do `Tooark.Extensions` consome `Language.Current`, o vazamento alcançava as mensagens traduzidas de validações e notificações de todo o ecossistema. **O que fazer**: nada, se o idioma já era definido por requisição — passa a funcionar. Código que dependia do estado global (definir a cultura em um ponto e lê-la em outra thread, sem propagação de contexto) precisa passar o idioma explicitamente.
- **`ILanguage.SetCultureInfo` passou a aceitar nulo** (`string?` e `CultureInfo?`), acompanhando `Language.SetCulture`. **O que fazer**: implementações próprias da interface precisam ajustar a assinatura.
- **`Language.Default` deixou de ser campo e passou a ser propriedade**, para refletir a instância corrente de `ILanguage` em vez de congelar o valor da inicialização estática. Compatível em código-fonte; exige recompilação.
- **`FileConvert.ToMemoryStream(IFormFile)` passou a copiar o conteúdo binário do arquivo.** Antes, lia o arquivo com `StreamReader.ReadToEnd()` e procurava `"base64,"` no texto — o que devolvia nulo para qualquer upload real e só funcionava se o arquivo enviado fosse um texto contendo uma data URL. **O que fazer**: quem enviava data URL dentro de um arquivo de texto passa a receber os bytes do texto, e não o conteúdo decodificado; use `ToMemoryStream(string)` com o conteúdo do arquivo nesse caso.
- **`GetInfo` deixou de exigir que as propriedades sejam `string`**: os valores eram lidos com um cast direto, que estourava `InvalidCastException` para qualquer outro tipo. Passam a ser convertidos com `ToString()`, e valor nulo devolve string vazia em vez de nulo declarado como não anulável. **O que fazer**: nada, exceto para quem dependia de receber `null`.
- **`FileConvert.Extension` passou a validar o que devolve.** O retorno era o texto declarado pelo cliente, sem verificação: `data:image/..\..\..\web.config;base64,...` devolvia `..\..\..\WEB.CONFIG`, e um consumidor que montasse o caminho de gravação com esse valor escrevia fora do diretório pretendido. Passam apenas letras e dígitos ASCII, com no máximo dez caracteres. **O que fazer**: tipos MIME que não têm forma de extensão passam a resultar em `null` — `image/svg+xml` devolvia `SVG+XML` e `application/vnd.ms-excel` devolvia `VND.MS-EXCEL`, valores que já não serviam como extensão. Quem precisa mapear tipo MIME para extensão precisa fazer esse mapeamento no próprio consumidor.
- **As conversões passaram a ter limite de tamanho**, com o parâmetro `maxBytes` e o padrão `FileConvert.DefaultMaxBytes` (5MB, o mesmo do `FileValid`). Acima do limite é lançada uma `PayloadTooLargeException` (HTTP 413). **O que fazer**: quem converte arquivos maiores que 5MB precisa informar o limite; quem já tratava o retorno nulo precisa passar a tratar também a exceção.
- **`ToMemoryStream(string)` passou a exigir o marcador `;base64,` completo**, e lê o conteúdo logo depois dele. Antes bastava a string conter `base64,` em qualquer posição, e o conteúdo era lido a partir da **última** vírgula: `data:text/plain;base64,QUJD,WFla` decodificava `WFla`, e não o trecho que segue o marcador. **O que fazer**: strings que não seguem o formato de data URL passam a resultar em `null`.
- **`GenerateString.Hexadecimal` passou a devolver exatamente o tamanho solicitado.** Tamanhos ímpares devolviam um caractere a menos: `Hexadecimal(7)` retornava 6 caracteres. Por consequência, `Token` com comprimento ímpar também passou a bater o tamanho pedido.

## ⚠️ Mudanças Incompatíveis (Tooark.ValueObjects)

- **Objeto de valor reprovado passou a devolver string vazia, e não nulo.** Vinte e oito dos 33 objetos declaravam o campo interno como `= null!;` — uma promessa de não-nulo que a própria classe quebrava; os quatro de auditoria já usavam `Guid.Empty` e o `DelimitedString` já usava `string.Empty`. `new Cpf("111").Number` devolvia `null` em uma propriedade `string`, e `ToString()` também: `object.ToString()` é anotado como não anulável, então `$"documento: {cpf}"` e a serialização passavam a depender de sorte. **O que fazer**: código que testava `if (cpf.Number == null)` passa a testar `IsValid`, ou `Number.Length == 0`; comparações com nulo param de encontrar o caso.
- **A conversão implícita de saída passou a exigir uma instância.** `string numero = cpfNulo;` estourava `NullReferenceException` dentro do operador, sem indicar qual conversão falhou. Agora lança `InternalServerErrorException` com `Invalid.Parameter;null`, o mesmo contrato já adotado no `Tooark.Enums`. **O que fazer**: nada, se a referência nunca é nula; quem convertia referência possivelmente nula precisa verificar antes.
- **`Password` deixou de converter implicitamente para `string` e `ToString()` passou a mascarar.** A senha em texto puro saía sozinha em qualquer interpolação, log estruturado ou serialização — `logger.LogInformation("{Senha}", senha)` gravava `Senha@123` no arquivo de log. `ToString()` devolve `Password.Mask` (`********`) quando há valor, e o valor só sai por `Value`, explicitamente. **O que fazer**: onde a conversão implícita era usada de propósito, troque por `.Value` — a mudança torna o vazamento visível na revisão de código em vez de acidental.
- **Os critérios do `Password` passaram a valer como configurados**, pela mesma correção feita no `PasswordValidationAttribute`: os dois passaram a montar o padrão pelo `PasswordPattern` do `Tooark.Validations`, e antes discordavam sobre a mesma senha. **O que fazer**: ver a seção do `Tooark.Attributes` — as regras de migração são as mesmas.
- **`RegexValidation.Match` e `NotMatch` passaram a aceitar `string?`** (`Tooark.Validations`), nas quatro sobrecargas, acompanhando o que os objetos de valor já lhes entregavam. Compatível em código-fonte; exige recompilação.

## ⚠️ Mudanças Incompatíveis (conformidade de nulabilidade)

- **Dezoito assinaturas declaravam parâmetro não anulável e tratavam a ausência no corpo.** A assinatura mentia: quem passava um `string?` recebia aviso do compilador para um caminho que sempre funcionou, e ou desligava o aviso, ou escrevia um `!` que apagava a checagem em volta. Foram ampliadas para anulável, o que **não quebra chamada existente** — quem passa valor presente compila igual. Alcança `NotificationItem(message, key, code)`, `IsEmailOrEmpty`, `IsEmailDomainOrEmpty`, os construtores de `Email` e `LinkVideo`, e onze métodos privados ou internos.
- **A varredura foi feita por detector, não pela lista anterior**, que tinha sete entradas: onze casos faltavam e um era falso positivo. `DocumentDigit.IsRepeated` **não** trata nulo — todos os chamadores garantem valor —, então a assinatura dele estava certa e ficou como está.
- **`CryptographyService.Encrypt` e `Decrypt` também ficaram como estão.** Eles _lançam_ para nulo, convertendo-o em `BadRequestException`. Método que recusa nulo está corretamente declarado como não anulável: a guarda é defesa para chamador sem anotação, não tratamento de ausência.
- **Comparação textual com valor ausente mudou de resultado.** `StringValidation` tinha duas sobrecargas de `Validate`: a que compara tamanho tratava nulo como vazio, a que compara texto não. Alinhadas, `AreEquals(null, "")` passa a ser **válido** onde antes era inválido, e `AreNotEquals(null, "")` passa a ser inválido. **O que fazer**: nada, salvo para quem dependia de distinguir nulo de vazio nessas comparações — o pacote unifica os dois em todo o resto.

## ⚠️ Mudanças Incompatíveis (Tooark.Validations — padrão de email)

- **O padrão de email passou a aceitar nick e rótulo de domínio de um único caractere.** O anterior exigia dois em cada parte, e reprovava endereços legítimos e existentes: `x@google.com`, `a@b.co` e `ab@b.co`. A mudança alcança de uma vez o `RegexPattern.Email`, o `EmailValidationAttribute` do `Tooark.Attributes` e o `Email` do `Tooark.ValueObjects`. **O que fazer**: nada — a validação afrouxou, então nenhum endereço antes aceito passa a ser reprovado. Quem dependia da recusa desses endereços precisa validar por conta própria.
- **`RegexPattern.EmailDomain` acompanhou**, pelo mesmo motivo: `@b.co` e `@a.b` eram reprovados.
- **O sinal de mais segue bloqueado**, por decisão. `nome+tag@exemplo.com` é válido pelo RFC 5322 e usado por Gmail e Outlook para rotular endereços, mas o pacote mantém a recusa — junto com os demais caracteres especiais no nick. Há teste fixando isso, para a escolha não se perder.
- **Efeito colateral resolvido**: `Email.MinLength` vale 6, e o padrão anterior exigia no mínimo sete caracteres (`ab@cd.e`), então a constante nunca era a regra que decidia. Agora ela é.

## ⚠️ Mudanças Incompatíveis (Tooark.Entities)

- **Chamada de escrita recusada deixou de sujar a entidade.** Todo `Set*` acumulava a validação na própria entidade antes de lançar, e a notificação nunca era limpa: depois de uma chamada recusada, a entidade ficava inválida em definitivo e **toda chamada seguinte era recusada com a mensagem da primeira**, mesmo estando correta. Uma entidade que falhasse uma vez ao ser excluída nunca mais podia ser excluída. A validação passou a ser feita sem tocar no estado, e a exceção continua sendo `BadRequestException` com as mesmas mensagens. **O que fazer**: código que lia `entidade.Notifications` depois de capturar a exceção precisa ler `ex.GetErrorMessages()`, ou `ex.GetNotifications()` quando precisar do código do erro — a exceção transporta a notificação completa, com o `T.ENT.*` preservado. `ValidateNotDeleted()` segue acumulando de propósito — é o método para checar sem interromper o fluxo.
- **`AuditableEntity.SetUpdatedBy` passou a ser `override`, e não `new`.** Declarado com `new`, ele apenas escondia o método virtual de `DetailedEntity`: uma chamada por referência da classe base — a de um repositório genérico, ou a do próprio Entity Framework — executava o método da base e **a versão não era incrementada**, em silêncio. A `VersionedEntity`, que faz a mesma coisa, sempre usou `override` e por isso as duas discordavam. **O que fazer**: nada, mas quem usa `Version` como token de concorrência otimista passa a detectar conflitos que antes escapavam.
- **Entidades de tipos diferentes com o mesmo `Id` deixaram de ser iguais.** `Equals` comparava apenas o identificador, então um `Pedido` e um `Produto` com o mesmo `Guid` eram iguais — e um `Distinct()` ou um `HashSet` sobre entidades de tipos diferentes descartava registros. A comparação passou a exigir compatibilidade de tipo, aceitando herança nos dois sentidos para não quebrar com os proxies de carregamento tardio do Entity Framework. **O que fazer**: nada, salvo para quem dependia da comparação apenas por identificador.
- **`AuditableEntity.SetDeleted` e `SetRestored` passaram a registrar quem alterou.** Os dois gravavam `DeletedById`/`RestoredById` mas não tocavam em `UpdatedById` nem em `UpdatedAt` — a entidade de auditoria _completa_ era justamente a que perdia o rastro da última alteração, enquanto a `SoftDeletableEntity` o registrava. **O que fazer**: nada; as colunas `updated_by` e `updated_at` passam a mudar também na exclusão e na restauração.
- **`FileEntity.FileName`, `Title` e `Link` deixaram de devolver nulo.** Eram declarados `string` com `= null!;`, então uma entidade materializada pelo Entity Framework ou criada pelo construtor vazio devolvia nulo em propriedade não anulável. **O que fazer**: verificações escritas como `== null` deixam de encontrar o caso; use `Length == 0`.
- **As chaves de mensagem do pacote mudaram de nome.** `Empty;Id` virou `Field.Empty;Id` e `ChangeBlocked;Id`/`ChangeBlocked;CreatedBy` viraram `Field.ChangeBlocked;Id`/`Field.ChangeBlocked;CreatedBy`, entrando na família `Field.*`. As antigas **não existiam em nenhum arquivo de idioma**, então a chave crua era exibida ao usuário final. **O que fazer**: quem comparava a mensagem pela chave antiga precisa ajustar; em troca, a mensagem passa a chegar traduzida.
- **Valor ausente passou a ser reportado como campo obrigatório.** `SetDeleted(null)` e equivalentes devolviam `Notifications.NotificationNull`, uma mensagem interna do framework de notificações. Agora devolvem `Field.Required;DeletedBy`, `Field.Required;UpdatedBy`, `Field.Required;CreatedBy` ou `Field.Required;RestoredBy`, conforme a operação.

## Correções (Tooark.Notifications)

- **`NullReferenceException` ao receber coleção nula**: `AddNotifications(ICollection<NotificationItem>)` e `AddNotifications(params Notification[])` iteravam o argumento sem verificação, quebrando com uma exceção sem contexto — enquanto todos os demais métodos tratavam nulo defensivamente. Agora seguem a mesma regra: argumento nulo registra `Notifications.NotificationNull`.
- **Item nulo dentro da coleção contaminava a lista**: um `null` na coleção era adicionado sem verificação e só estourava depois, na leitura de `Codes`/`Keys`/`Messages` ou na montagem do `ResponseDto`, longe da origem. Como `AddNotifications(Notification)` delega para essa sobrecarga, a contaminação se propagava entre notificações. Itens nulos passam a ser ignorados.
- **Mensagem composta apenas por espaços virava mensagem vazia**: a guarda usava `IsNullOrEmpty`, então `"   "` passava e o `Trim()` do `NotificationItem` produzia `Message` vazia — o consumidor recebia um erro sem texto. Agora `IsNullOrWhiteSpace` cobre o caso.
- **Conversão implícita `NotificationItem` → `string` lançava `NullReferenceException`** com instância nula (por exemplo `string texto = lista.FirstOrDefault();`). Passa a retornar string vazia.
- **Documentação XML incorreta**: as duas sobrecargas `AddNotification(Type, ...)` descreviam "adiciona uma coleção de notificações" quando adicionam uma única notificação, e `AddNotification(string, string)` documentava os parâmetros em ordem invertida à assinatura.
- **Exemplo do README invertia chave e mensagem**: o código de exemplo produzia `Message = "Error"` e `Key = "Ocorreuumerro."`, mas o comentário afirmava o contrário. Quem seguisse o exemplo trocaria os dois campos.

## Modificado (Tooark.Observability)

- **`Microsoft.AspNetCore.App` passou a ser declarado por `FrameworkReference`.** O pacote usa `HttpContext` e `HttpRequest` no filtro e no enriquecimento do rastreamento, e esses tipos chegavam por transitividade do `OpenTelemetry.Instrumentation.AspNetCore` — o build dependia do grafo de dependências de terceiro, e uma reorganização lá quebraria a compilação aqui sem alteração nossa. **Não há requisito novo**: verificado que o `runtimeconfig.json` de um consumidor já listava o `Microsoft.AspNetCore.App` antes da mudança, e segue idêntico depois.

## Modificado (Tooark.Notifications)

- **Instanciação por reflexão removida**: os itens de notificação eram criados com `Activator.CreateInstance` para um tipo do próprio assembly — boxing de `object[]` a cada notificação, sem verificação em tempo de compilação e com falha só em runtime caso o construtor mudasse. Substituído por `new NotificationItem(...)`.
- **Auto-adição deixou de duplicar notificações**: `notificacao.AddNotifications(notificacao)` copiava a própria lista sobre si mesma. Agora é uma operação sem efeito, protegida por `ReferenceEquals` — o que também elimina o risco de alterar a coleção durante a iteração.
- **Sanitização da chave completa**: `Key` removia apenas o espaço literal, mantendo tabulação e quebra de linha. Agora remove todos os espaços em branco, e o comportamento está documentado.
- **`Code` passou a ser normalizado**: era usado exatamente como recebido, então `" T.ERR "` virava um código com espaços nas pontas, que não casava com nenhum filtro por código. Agora sofre `Trim()`, como já acontecia com a mensagem. Os valores padrão `Unknown` e `T.ERR` viraram constantes, eliminando as strings repetidas entre a assinatura do construtor e a validação.
- **Alocações reduzidas na leitura**: `Notifications` reutiliza a mesma coleção somente leitura em vez de criar um wrapper a cada acesso; `Codes`, `Keys` e `Messages` passaram a alocar uma única lista; e a agregação de notificações deixou de fazer a cópia intermediária.
- Limpeza do `.csproj`: removido o `ItemGroup` de `Resources\**\*.json`, herdado de outro projeto e sem correspondência neste pacote.
- README reescrito para refletir o pacote: normalização de `message`/`key`/`code`, separação entre métodos públicos e protegidos, tratamento de valores nulos, documentação da classe `NotificationErrorMessages` (API pública que não aparecia) e correção do exemplo de uso.

## Adicionado (Tooark.Mediator.EntityFrameworkCore)

- **Novo pacote**: move a persistência do Entity Framework Core para o pipeline do Mediator, mantendo os manipuladores livres de `SaveChanges` — a linha repetida em cada manipulador de comando, cujo esquecimento produz um comando que aparenta funcionar sem gravar nada.
  - `AddTooarkMediatorUnitOfWork<TContext>()` registra o behavior na posição em que é chamado, respeitando a ordem de execução do pipeline. Duas estratégias: `SaveChanges` (padrão, com a transação implícita do Entity Framework Core) e `Transaction` (transação explícita, para manipuladores que persistem mais de uma vez ou combinam o contexto com outro recurso transacional).
  - A restrição a `ICommand<TResponse>` mantém as consultas fora da persistência, sem verificação de tipo em tempo de execução.
  - **Comandos aninhados participam da mesma unidade de trabalho**: apenas o comando mais externo persiste. Sem esse controle, o comando interno gravaria no meio da operação do externo e uma falha posterior deixaria o banco em estado parcial.
  - Na estratégia `Transaction`, a transação é aberta dentro da estratégia de resiliência do provedor — abrir por fora lança quando há retentativa configurada (`EnableRetryOnFailure`). Em contrapartida, a operação pode ser reexecutada em falha transitória e precisa ser idempotente.
  - `IUnitOfWork`, no namespace `Tooark.Mediator.EntityFrameworkCore.Interfaces`, não expõe tipos do Entity Framework, permitindo substituir a implementação em testes.
  - O pacote integra o agregador `Tooark`, coerente com a proposta de instalar todos os recursos de uma vez.

## Adicionado (Tooark.Mediator)

- **Pipeline de behaviors**: `IPipelineBehavior<TRequest, TResponse>` envolve a execução do manipulador, permitindo tratar preocupações transversais — validação, log, transação, cache, autorização — sem repeti-las em cada manipulador. Cada behavior decide se invoca a etapa seguinte; não invocar interrompe o pipeline e devolve a resposta do próprio behavior ao chamador.
  - Registro explícito por `AddTooarkMediatorBehavior<TBehavior>()` ou `AddTooarkMediatorBehavior(Type)`, aceitando behaviors fechados e genéricos abertos. Behaviors **não** são descobertos pelo scan de assemblies: a ordem de execução é semântica e a ordem devolvida pelo scan não é garantida.
  - Execução na ordem de registro — o primeiro registrado é o mais externo.
  - O `CancellationToken` é parâmetro obrigatório da etapa seguinte, e não opcional como no delegate equivalente de outras bibliotecas: descartar o token por engano é justamente o tipo de falha silenciosa que esta versão elimina.
  - Tipo registrado que não implementa a interface, ou behavior genérico aberto que o container não consegue fechar, falham no registro com `Behavior.NotSupported`; behavior que devolve tarefa nula falha com `Behavior.ExecutionFailed`, identificando o tipo.
  - Aplica-se apenas a requisições; notificações não passam pelo pipeline. O manipulador é resolvido antes da montagem da cadeia, então `Handler.NotFound` continua falhando antes de qualquer behavior executar. Sem behaviors registrados, o despacho permanece sendo a invocação direta do manipulador, sem montar a cadeia.
  - `IPipelineBehavior` e `RequestHandlerDelegate` ficam no namespace `Tooark.Mediator.Behaviors`, separado dos contratos de manipulador em `Tooark.Mediator.Handlers` — um behavior não é um manipulador, e agrupá-los no mesmo namespace confundiria os dois papéis logo na estreia do recurso.

## Correções (Tooark.Enums)

- **`FormatException` na validação de CNH e RG com entrada não numérica**: `EDocumentType.CNH.IsValid("ABCDEFGHIJK")` e `EDocumentType.RG.IsValid("AB.CDE.FGH")` convertiam caractere a caractere com `long.Parse` e `int.Parse` sem verificação. É o mesmo defeito corrigido no `ValidateCnpj` — corrigido no CNPJ e deixado para trás nos outros dois documentos da mesma classe.
- **`NullReferenceException` na validação com valor nulo**: `IsValid` de CNH e RG desreferenciava o argumento em `value.Length` e `value.Trim()`.
- **Documentação de classe do `EFileType` descrevia outro tipo**: "Representa as ações que podem ser realizadas em uma permissão", copiada de um enumerador de permissões. Os parâmetros das conversões implícitas também herdaram o nome `action`; em `ECloudProvider`, `document`.
- **README com exemplo factualmente errado**: afirmava que `EFileType.Image.ToInt()` devolve `1`. Devolve `2` — `Document` é que é 1.
- Limpeza do `.csproj`: removido o `ItemGroup` de `Resources\**\*.json`, sem correspondência neste pacote.

## Modificado (Tooark.Enums)

- **Cálculo de dígitos de CNH e RG centralizado** em `DocumentDigit`, no `Tooark.Validations`, junto com os de CPF e CNPJ. As implementações estavam duplicadas dentro do `EDocumentType`, que encolheu de 291 para 206 linhas.
- **Contrato de `ToRegex()` e `IsValid` documentado**: são camadas distintas e complementares — a primeira valida a forma, a segunda o conteúdo. Chamada isolada, `IsValid` aceita o valor com ou sem máscara e nunca lança para entrada inválida.
- **Arquivos organizados em regiões**, seguindo o padrão que o `EProcessorType` e o `EProtocolOtlp` do `Tooark.Observability` já usavam para esse mesmo formato de classe: valores, construtor, propriedades privadas, métodos privados e a região de métodos, sobrescritas e operadores implícitos. No `EFileType`, o construtor foi movido para antes das propriedades privadas, que era a única das três classes fora dessa ordem.
- Metadados NuGet: `PackageTags` ampliadas para melhorar a descoberta no nuget.org.
- README revisado: seções de instalação e de funcionamento, as conversões implícitas documentadas (são a API mais usada do pacote e não apareciam), tabelas de valores com id e descrição, o comportamento de valor não reconhecido explicitado, e os links relativos de licença e de dependência trocados por absolutos.

## Correções (Tooark.Validations)

- **`NullReferenceException` com valor nulo**: as validações de tamanho e conteúdo de string, as de tamanho de lista e as comparações de objeto desreferenciavam o valor sem verificação. Uma biblioteca de validação interrompia o fluxo justamente ao receber o valor inválido que deveria reprovar. Valor nulo passou a ser tratado como vazio e reprovado normalmente, e a comparação de objetos usa a igualdade estática, que aceita nulos dos dois lados.
- **`AreEquals` de listas comparava referência**: `AreEquals(new[] { 1, 2 }, new[] { 1, 2 }, "x")` reprovava duas listas idênticas. O teste existente passava a mesma instância nos dois argumentos, então a comparação por referência acertava por acidente e o defeito nunca aparecia. Passou a usar `SequenceEqual`.
- **`Join` estourava com elemento nulo**: verificava se a coleção era nula, mas não os elementos, e acessava `IsValid` de cada um. Elementos nulos passaram a ser ignorados, como já ocorria em `AddNotifications`.
- **`RegexMatchTimeoutException` escapava da validação**: o tempo limite de 300 ms protegia contra padrões suscetíveis a backtracking excessivo, mas convertia a proteção em exceção não tratada — uma entrada patológica derrubava a operação em vez de ser reprovada. O tempo limite atingido passou a significar "não corresponde ao padrão".
- **`ValidateCnpj` do `EDocumentType` estouraria com o CNPJ alfanumérico**: convertia caractere a caractere com `int.Parse`, então a primeira letra lançaria `FormatException` no lugar de reprovar o documento.

## Modificado (Tooark.Validations)

- **Cálculo de dígitos verificadores centralizado** em `DocumentDigit`, no `Tooark.Validations`: existiam duas implementações, uma no `Tooark.Enums` (usada pelos value objects, que já conferia os dígitos) e nenhuma no `Tooark.Validations`. Agora há uma só, pública, também utilizável fora da validação.
- **Expressões regulares em cache próprio**: o cache do `Regex` estático guarda 15 combinações e o pacote oferece 48 padrões — em uso real as entradas se expulsavam entre si e o padrão era recompilado a cada validação. O cache por padrão, opções e tempo limite elimina a recompilação e vale também para padrões da aplicação.
- `MatchFunc` deixou de ser campo de instância e virou método estático: era um delegate carregado por cada instância de `Validation`, que é a base de toda entidade e value object do ecossistema.
- README revisado: a família `LinkVideoValidation` — `IsLinkVideo`, `IsLinkVideoYouTube`, `IsLinkVideoVimeo` e `IsLinkVideoDailymotion` — **não aparecia em lugar nenhum** do README, sem seção, exemplo ou menção na lista de métodos; `IsNotNull` também faltava na lista. Ganharam seção própria, exemplo e entrada. A tabela de códigos de erro passou a listar os códigos reais com sufixo, incluir o `T.VLD.DOC1` e explicitar que as validações por expressão regular compartilham o `T.VLD.RGX1`. Foram acrescentadas a seção de instalação, a documentação da classe pública `ValidationErrorMessages` e as seções finais no índice; os links relativos de licença e de dependência viraram absolutos.
- Documentação XML: a classe parcial de `LinkVideoValidation` era descrita como "Classe de validação de Protocol", copiada do `ProtocolValidation`, e `ValidationErrorMessages` era o único tipo público do pacote sem `<summary>`.
- **`DocumentDigit` ganhou `IsRg` e `IsCnh`**, passando a concentrar o cálculo dos quatro documentos suportados. As implementações viviam no `Tooark.Enums`, o que fazia o mesmo documento ter dois veredictos possíveis dependendo da API usada.
- Arquivo `NetworklValidation.cs` renomeado para `NetworkValidation.cs`.

## Correções (Tooark.Mediator e Tooark.Mediator.Abstractions)

- **`Unit.Task` alocava uma tarefa a cada acesso**: a propriedade executava `Task.FromResult` em toda leitura, contrariando a própria documentação do membro, que prometia uma tarefa pré-construída. Como `Unit.Task` é o retorno recomendado de todo manipulador de comando sem resposta, a alocação acontecia por requisição. A tarefa passou a ser criada uma única vez.
- **Publicação paralela abandonava manipuladores já iniciados**: quando um manipulador falhava antes de devolver a tarefa (validação síncrona ou tarefa nula), a exceção interrompia a iteração — as tarefas já em execução ficavam sem observação, com a falha delas desaparecendo, e os manipuladores seguintes nem chegavam a iniciar, contrariando a semântica documentada da estratégia paralela. Agora todos são iniciados e aguardados, e a primeira falha continua sendo propagada ao chamador.
- Documentação XML: as variantes sem resposta de `ICommand` e `IRequest` usavam a tag `<typeparam>` sem o atributo `name`, inválida em interface não genérica — o conteúdo se perdia na documentação gerada.
- **Âncoras do índice do README do `Tooark.Mediator.Abstractions` não resolviam**: os títulos das seções têm emoji, então `#instalação`, `#componentes` e as demais apontavam para lugar nenhum. Corrigidas.
- Documentação do README do `Tooark.Mediator.Abstractions`: `PublishAsync` era documentado com o parâmetro `notification`, divergente da assinatura (`notify`); `Unit.Value` e `Unit.Task` apareciam sem descrição; a versão da dependência `Tooark.Exceptions` estava em branco; e o exemplo de uso do `Unit` foi reescrito para mostrar o curto-circuito síncrono, que é onde a tarefa reutilizada importa.
- Arquivo `Enums/ENotificationStrategy.cs` renomeado para `ENotifyStrategy.cs`, alinhando ao tipo que declara.

## Modificado (Tooark.Mediator e Tooark.Mediator.Abstractions)

- **Metadados NuGet revisados nos dois pacotes**: `Summary` e `PackageDescription` estavam em português enquanto o `Description` publicado estava em inglês; ficaram todos em inglês. As `PackageTags` foram ampliadas (`tooark`, `mediatr`, `command`, `query`, `notification` e, no `Tooark.Mediator`, `pipeline` e `behaviors`), melhorando a descoberta no nuget.org.

## Correções (Tooark.Observability)

- **Conversões implícitas de `EProcessorType` e `EProtocolOtlp` estouravam `NullReferenceException`** com instância nula. O caminho é alcançável no uso normal, já que `OtlpOverrideOptions.Protocol` e `OtlpOverrideOptions.ExportProcessorType` são anuláveis por design. Passam a lançar `Invalid.Parameter;null`, o mesmo erro que essas classes já emitiam para valores inválidos.
- Documentação de `DataSensitiveOptions.HideQueryParameters` atualizada: ainda descrevia a remoção do atributo `http.target`, comportamento substituído na v3.3.4 pela remoção de `url.query` e da query em `url.full`.
- **Opções de métricas não apareciam no README**: `ExportIntervalMilliseconds` e `ProcessMetricsEnabled` eram configuráveis, mas não estavam documentadas — quem lia o README não sabia que existiam. Incluídas, com o padrão de 60 s e a redução para 5 s quando o OTLP efetivo tem `ServerlessOptimized` habilitado.
- README do `Tooark.Observability` revisado: `AllowSensitiveData` na tabela de opções e nos exemplos de `appsettings.json`, descrição de `HideQueryParameters` corrigida também no texto e na tabela, e nota explícita de que `AllowSensitiveData = true` desliga a sanitização globalmente e faz as opções granulares de `Tracing.DataSensitive` serem ignoradas — precisamente a ambiguidade que motivou o rename.
- **`AddTooarkObservability` era descrito como se fizesse mais que `AddTooarkOpenTelemetry`**: a tabela dizia "Configura Observability + OpenTelemetry", sugerindo registros adicionais. O método apenas delega — são equivalentes, e a documentação passou a dizer isso. Na mesma tabela de `ObservabilityOptions` faltavam os sub-objetos (`Tracing`, `Metrics`, `Logging`, `Otlp`) e os três callbacks `ConfigureTracing`/`ConfigureMetrics`/`ConfigureLogging`, que só existiam nos exemplos.

## Correções (Tooark.Exceptions)

- **`NullReferenceException` com lista ou notificação nula**: os construtores desreferenciavam o argumento no inicializador da classe base, antes de qualquer verificação. Uma biblioteca de exceções estourava com NRE sem contexto justamente ao ser construída de forma incorreta. Entrada nula passou a registrar `Exceptions.ErrorsNullOrEmpty`.
- **Lista ou notificação vazia produzia exceção sem erro nenhum**: `GetErrorMessages()` vinha vazio e o `Message` caía no texto genérico do .NET (_"Exception of type '...' was thrown."_). Quem devolvia `ex.GetErrorMessages()` na resposta HTTP entregava um erro com corpo vazio. As coleções passaram a ter sempre ao menos um item.
- **Item nulo era tratado de dois jeitos na mesma exceção**: `GetErrorMessages()` guardava o `null` — que estourava no consumidor — enquanto `GetNotifications()` já convertia para a chave de mensagem ausente. As duas leituras passaram a coincidir posição a posição.
- **`FormatException` crua no construtor de formatação**: um formato incompatível com os parâmetros substituía a exceção pedida por uma `FormatException`, trocando o erro real por um erro de apresentação — mensagens com chaves literais, como JSON, caíam nesse caso. A mensagem passou a ser mantida como recebida.
- **Mensagem formatada duas vezes**: `string.Format` era executado no inicializador da base e novamente no corpo do construtor, para produzir a mesma string. Agora ocorre uma única vez.
- Documentação do `GetInfoException` dizia "Função virtual" para um método `override`, e destoava do padrão das demais exceções.

## Modificado (Tooark.Exceptions)

- **Construtores da classe base passaram de `public` para `protected`**: `TooarkException` é abstrata, então construtores públicos eram inalcançáveis e sugeriam uma instanciação que nunca existiu.
- **Suporte a exceção interna**: todas as exceções ganharam `(string message, Exception innerException)`, permitindo preservar a causa raiz ao traduzir um erro de infraestrutura. Atenção à resolução de sobrecarga: `new NotFoundException("Falha: {0}", umaExcecao)` passa a ligar ao construtor de exceção interna, e não ao de formatação — para formatar usando uma exceção como argumento, converta antes (por exemplo `ex.Message`).
- **Mensagens conhecidas centralizadas** em `ExceptionErrorMessages`, no mesmo formato de chave de tradução já usado pelo `Tooark.Notifications`: `Exceptions.MessageNullEmpty` e `Exceptions.ErrorsNullOrEmpty`.
- **Construção centralizada**: os cinco construtores públicos passaram a delegar para um único construtor privado, que é o único ponto que define o estado da exceção.
- Metadados NuGet: `PackageTags` ampliadas para melhorar a descoberta no nuget.org.
- README revisado: acrescentadas a seção de instalação e um exemplo de **extensão da hierarquia** — a classe base é abstrata com construtores protegidos, e criar uma exceção própria herdando dela é o ponto de extensão do pacote, que não estava documentado. O exemplo de uso com `Notification` **não compilava mais**, porque chamava `AddNotification` de fora do objeto e o método virou protegido nesta major; as garantias de coleção somente leitura e nunca vazia, o construtor de exceção interna, a tabela de tratamento de nulos e a classe `ExceptionErrorMessages` passaram a ser documentados; a linha do 413 passou a nomear `RequestEntityTooLarge`, que é o membro real de `HttpStatusCode`, com nota sobre o nome do RFC; e os links relativos de licença e de dependência foram trocados por absolutos, que resolvem no nuget.org.

## Correções (Tooark.Securities — Criptografia)

- **`Encrypt` com `CBCUnsafe` quebrava o round-trip**: o modo legado (IV zero) existe apenas para descriptografar dados antigos, mas o `Encrypt` caía silenciosamente em GCM — `Decrypt(Encrypt(x))` falhava sempre. Agora criptografar nesse modo lança `Options.Cryptography.AlgorithmDecryptOnly;CBCUnsafe`.
- **`SecretBase64` sozinho era impossível**: o construtor exigia `Secret` mesmo quando a chave Base64 (documentada como usada diretamente) estava configurada. A validação passou a ser condicional: `Secret` **ou** `SecretBase64` obrigatório; quando ambos são informados, `SecretBase64` tem prioridade (documentado).
- **Chave Base64 inválida trocava de chave silenciosamente**: `SecretBase64` fora de 32 bytes era ignorado e a chave era derivada do `Secret` — dados criptografados com chave diferente da configurada. Agora Base64 inválido (`Options.Cryptography.SecretBase64Invalid`) ou tamanho errado (`Options.Cryptography.SecretBase64InvalidSize`) falham no startup.
- **Exceções cruas no `Decrypt`**: Base64 inválido vazava `FormatException` e padding/tag incorretos vazavam `CryptographicException`. Uniformizado em `BadRequestException("Cryptography.InvalidCipherText")`, o que também elimina a distinção de erros que alimenta padding oracle no modo CBC.

## Correções (Tooark.Securities — JWT)

- **`NullReferenceException` no startup sem `Algorithm` configurado**: o campo interno era nulo; agora tem default real (`ES256`, documentado).
- **Algoritmo inválido caía silenciosamente em ES256**: um typo trocava a classe do algoritmo (simétrico → assimétrico) sem aviso. Valores desconhecidos agora lançam `Options.Jwt.AlgorithmNotSupported;{valor}`; doc atualizada com a lista completa (incluindo ES256/384/512, que faltavam).
- **`NullLoggerFactory` global podia desligar o logging da aplicação**: o registro `TryAddSingleton<ILoggerFactory, NullLoggerFactory>` no DI do JWT, se executado antes de `AddLogging` (console/worker), impedia o registro do logging real. Removido: o logger virou parâmetro opcional do construtor com `NullLogger` interno.
- **Audience/issuer inválidos reportavam `InternalServerError`**: faltava tratamento para `SecurityTokenException` — agora mapeiam para `Token.Invalid`, como todo token inválido.
- **Token válido sem as claims esperadas estourava como erro interno**: `UserTokenDto` usava `First()`; com `FirstOrDefault`, claims ausentes resultam em campos vazios, permitindo validar tokens emitidos por outros fluxos.

## Modificado (Tooark.Securities)

- **`PublicKey` sem fallback para a chave privada**: atribuir `PublicKey = null` copiava a chave privada para o campo da pública (semanticamente inválido — PKCS#8 não é SPKI — e dependente da ordem de binding). Null agora significa "não configurado".
- **Fail-fast unificado para algoritmos assimétricos**: o check `Options.Jwt.KeysNotConfigured` valia só para RSA/PSS; com ECDsa, a configuração sem chaves passava pelo startup e falhava no primeiro uso. O check agora roda antes dos branches, para todas as famílias.
- **Tamanho mínimo de secret HMAC (RFC 7518)**: HS256 exige ≥32 bytes, HS384 ≥48, HS512 ≥64, validado no startup com `Options.Jwt.SecretTooShort;{mínimo}` — antes, secrets curtos passavam pela construção e falhavam na primeira assinatura com erro obscuro do IdentityModel. **Atenção**: configurações com secrets entre 16 e 31 bytes que funcionavam passam a falhar no startup — essas configurações são vulneráveis a força-bruta da chave HMAC (tokens forjáveis) e devem ser corrigidas. O README já documentava esses mínimos; o código passou a cumpri-los.
- **Dispatch de tokens modernizado para `JsonWebTokenHandler`** (handler atual da Microsoft.IdentityModel): `Create` e `Validate` usam instância estática reutilizável (sem alocação de handler por chamada), com mapeamento de falhas preservando os códigos existentes (`Token.Expired`, `Token.InvalidSignature`, `Token.Invalid`, `InternalServerError`). `UserTokenDto` ganhou a sobrecarga `UserTokenDto(JsonWebToken)`; o construtor legado `UserTokenDto(JwtSecurityToken)` permanece — API pública 100% compatível e interoperabilidade entre handlers coberta por teste.
- **README do `Tooark.Securities` complementado na revisão final**: `Issuers` e `Audiences` — os arrays que permitem aceitar múltiplos emissores e destinatários na validação — não apareciam em lugar nenhum, embora sejam lidos pelo serviço; `JwtOptions` e `CryptographyOptions` ganharam tabela de propriedades com os valores padrão reais (o `ExpirationTime` é 5 minutos, e os exemplos mostravam 60 sem dizer que era customização); ficou documentado que `PrivateKey` e `PublicKey` aceitam o PEM completo, já que o setter remove os delimitadores e as quebras de linha; e a versão da dependência `Tooark.Exceptions`, que estava em branco, foi preenchida.
- Decisões deliberadas (documentadas, sem mudança): derivação de chave via SHA256 mantida por compatibilidade de dados (recomendação: `SecretBase64` com chave aleatória); CBC sem HMAC mantido por compat (GCM é o default); migração completa do tipo público legado `JwtSecurityToken` fica para uma futura major.
- README do Tooark.Securities revisado para coerência com o pacote: chave de configuração corrigida de `Expires` para `ExpirationTime` (a chave documentada não fazia bind e a expiração caía no default silenciosamente), `SecretBase64` documentado, `CBCUnsafe` marcado como somente-descriptografia, mínimos HMAC em bytes com nota da RFC, nota do algoritmo padrão/validação, exemplos de criptografia usando `ICryptographyService` + `AddTooarkCryptography`, `ICryptographyService` na tabela de interfaces, tabela de códigos de erro completa com as novas mensagens e dependências multi-target.

## 🔒 Segurança (Tooark.Utils)

O `FileConvert` recebe conteúdo enviado pelo cliente e devolvia partes dele sem verificação. Três pontos foram
endurecidos, todos confirmados por execução contra o pacote compilado.

- **Travessia de diretório pela extensão**: `Extension` devolvia o texto entre a barra e o ponto e vírgula da
  data URL, tal como recebido. `data:image/..\..\..\inetpub\wwwroot\shell.aspx;base64,...` devolvia
  `..\..\..\INETPUB\WWWROOT\SHELL.ASPX`, e um `Path.Combine` com esse valor escapava do diretório do
  inquilino. Também passavam `B/C` (barra), `<SCRIPT>` (marcação) e um valor de 300 caracteres. A extensão
  passou a aceitar apenas letras e dígitos ASCII, com no máximo dez caracteres.
- **Esgotamento de memória por conversão sem limite**: uma requisição com 96MB de base64 alocava 352MB em
  318ms, tudo em Large Object Heap, e não havia limite algum. Parte disso era gratuita: o conteúdo era
  recortado com uma cópia da string inteira antes de decodificar. O limite passou a ser conferido a partir do
  comprimento do trecho base64, **antes de qualquer alocação**, e a decodificação usa `Convert.TryFromBase64Chars`
  sobre o próprio trecho, sem a cópia. O mesmo payload de 96MB agora aloca 2KB e falha em 0ms com HTTP 413.
  Na conversão de `IFormFile`, o limite é conferido no tamanho declarado e também bloco a bloco durante a
  leitura, para valer mesmo quando o tamanho declarado não corresponde ao conteúdo real.
- **Conteúdo lido a partir da última vírgula**: `data:text/plain;base64,QUJD,WFla` decodificava `WFla`, e não
  o trecho logo após o marcador. Uma inspeção que lesse depois de `base64,` veria um conteúdo e a biblioteca
  decodificaria outro. O conteúdo passou a ser lido a partir do marcador `;base64,`, que agora é exigido
  completo — `xxbase64,QQ==` e `BASE64,QQ==` deixaram de ser aceitos.

Continua valendo, e agora está documentado nos dois utilitários: **a extensão reflete o que o cliente
declarou, não o conteúdo do arquivo**. `data:image/png;base64,<conteúdo executável>` devolve `PNG`. O
`FileConvert` e o `FileValid` verificam formato e tamanho; a checagem do tipo real do conteúdo é
responsabilidade de quem recebe o arquivo.

## Correções (Tooark.Dtos)

- **A última página de uma listagem era inalcançável.** `SetNext` verificava `(index + 1) * PageSize < Total`, e o `+1` a mais fazia a penúltima página não apontar para a última. Com `Total=100` e `PageSize=10` — dez páginas — a página 9 vinha com `Next` nulo, e a página 10 só era acessível editando a URL na mão. Com total não múltiplo do tamanho o efeito é o mesmo: em `Total=95`, os registros de 91 a 95 ficavam fora da navegação. O teste que existia afirmava justamente `Assert.Null(Next)` nesse caso, fixando o defeito como se fosse regra.
- **`AddTooarkDtos` construía um segundo container dentro de si.** Chamava `BuildServiceProvider()` durante o registro — o anti-padrão que o SDK sinaliza com `ASP0000` —, criava uma cópia dos singletons e guardava em campo estático um localizador vindo desse container descartável. Qualquer registro feito depois ficava invisível para ele. O `Dto` passou a criar o próprio localizador sob demanda, o que eliminou o provedor descartável, o campo estático configurado de fora e a duplicata de registros.
- **A tradução dependia silenciosamente do registro no container.** Sem `AddTooarkDtos`, o localizador era nulo e as chaves passavam cruas. Agora a tradução funciona com ou sem injeção de dependência.
- **`ResponseDto` localizava a mensagem duas vezes** no construtor que recebe notificação com código: a mensagem era traduzida e o resultado era passado pelo tradutor de novo. Funcionava por acidente, já que o texto traduzido não é chave.
- **`MetadataDto` descartava o valor quando a chave era vazia**, sem documentar o porquê.
- **`GenerateLink` alterava o dicionário da query string compartilhado** entre a montagem dos links anterior e seguinte. Funcionava pela ordem das chamadas; passou a trabalhar sobre uma cópia.
- **Sem guarda de valor ausente** em `PaginationDto(request)`, `PaginationDto(total, searchDto, request)`, `ResponseDto(errors)`, `ResponseDto(exception)` e `SetMetadata`. Requisição e busca ausentes passam a lançar `ArgumentNullException`; as demais entradas ausentes são ignoradas.
- **Documentação divergente do código** em três lugares: `SearchDto.PageIndex` dizia que o valor 0 ignora o índice, quando 0 vira 1; e `PaginationDto.PageSize` e `PageIndex` declaravam padrão 0, enquanto os inicializadores dizem 10 e 1.

## Modificado (Tooark.Dtos)

- **`SearchNormalized` passou a usar `??=`**, o que também corrige o caso de a busca ser definida como nula depois de já normalizada.
- **`Dto` deixou de expor qualquer membro público.** O `Configure` continua existindo como `internal`, para substituir o localizador em testes.
- Arquivos organizados em regiões, nos sete arquivos do pacote.
- Metadados NuGet: `PackageTags` ampliadas e prefixadas com `tooark`.
- README reescrito no formato do `Tooark.Mediator`, com seção de instalação, tabelas de membros por DTO, a explicação do teto de página e uma seção sobre os links de paginação. O README anterior documentava `Dto.Configure`, que é `internal`, e declarava `PageIndex` com padrão 0. Os exemplos foram compilados antes de publicados, o que revelou o aviso `MVC1004`: nomear o parâmetro do endpoint de `search` colide com a propriedade `Search` do DTO, e isso agora está documentado.

## Correções (Tooark.Extensions)

- **As traduções não cobriam quase nada do que os pacotes emitem.** Um levantamento das chaves emitidas contra as presentes nos recursos apontou **73 chaves sem tradução**, entre elas as 30 do `Validation.*`, que o `ValidationErrorMessages` produz desde a criação do `Tooark.Validations`. Na prática, toda mensagem de validação do ecossistema saía como a chave crua — `Validation.IsNotNullOrEmpty` — e ainda **perdia o parâmetro**, porque `string.Format` sobre um texto sem marcador descarta os argumentos: o consumidor não sabia sequer qual campo havia falhado. Os recursos passaram de 62 para 135 chaves e cobrem todos os pacotes.
- **O idioma sem arquivo próprio fixava os parâmetros da primeira consulta.** No caminho de recurso ausente, o valor gravado no cache era o texto **já formatado**, e não o texto com os marcadores. A primeira consulta de `Field.Required;Email` gravava "Field Email is required", e a partir dali `Field.Required;Nome` e `Field.Required;Senha` devolviam a mesma frase, com o campo errado. Como o cache é compartilhado, o efeito atravessava instâncias e requisições. O cache passou a guardar o texto com os marcadores, e a formatação acontece depois.
- **Chave inexistente ia para o cache**, fixando a ausência mesmo depois de a tradução ser acrescentada. Agora só o que foi encontrado é armazenado.
- **`FromPascalToSnakeCase` usava `ToLower()` dependente de cultura**, em um pacote de localização. Com a cultura turca, `I` vira `ı` sem ponto e o resultado muda. Passou a usar `ToLowerInvariant`, como o restante do arquivo.
- **Documentação XML trocada em dois métodos**: `FromCamelToSnakeCase` dizia "Converte uma string de Pascal Case para Camel Case" e `FromKebabToSnakeCase` dizia "de Camel Case para Snake Case". As implementações estavam certas; a documentação, que é o que aparece no IntelliSense, estava deslocada.
- **`ToBase64` e `FromBase64` estouravam com valor nulo**, enquanto os demais métodos do arquivo tratavam ausência de valor. Passam a devolver string vazia.
- **Arquivo de tradução malformado derrubava a aplicação** com `JsonException` na primeira consulta. Agora o idioma fica sem traduções e a busca cai no padrão.
- Três `case` inalcançáveis no `ToSlug` (`Ø`, `Ð`, `Ł`), pelo mesmo motivo já corrigido no `Normalize`: o `switch` opera sobre o caractere já convertido para minúsculo.

## Modificado (Tooark.Extensions)

- Os arquivos de idioma passaram de `contentFiles` para recurso embutido no assembly, e a leitura passou a ser pelo manifesto. Verificado empacotando e consumindo de um projeto limpo: a tradução chega **sem** nenhum alvo de MSBuild, e o arquivo `Resources/{idioma}.json` do consumidor continua sobrescrevendo chave a chave.
- Chave `Field.ChangeBlocked` acrescentada aos três idiomas, para o `Tooark.Entities` — que emitia `ChangeBlocked;...` sem nenhuma tradução correspondente. O `Field.Empty`, que já existia sem emissor, passou a ter um.

- **Os arquivos de tradução são lidos uma vez por idioma**, e não a cada resolução do localizador. O serviço é registrado como transitório, então cada injeção criava uma instância nova que relia e reinterpretava os dois arquivos JSON do disco.
- **As traduções passaram a ser guardadas em dicionário**, e não em `JsonDocument`. A busca por chave virou consulta por hash, o que eliminou a razão de existir do cache distribuído na frente dela.
- **As chaves dos recursos passaram a ficar em ordem alfabética**, o que agrupa naturalmente os prefixos (`Validation.*`, `Options.Jwt.*`, `Handler.*`) e torna previsível onde acrescentar uma chave nova.
- **`Normalize.Value` do `Tooark.Utils` passou a declarar o parâmetro como anulável**, refletindo o que o método já fazia. Sem isso, o `ToNormalize` do Extensions não podia repassar um valor anulável.
- Quatro membros `public` dentro da classe interna `InternalEnumerableExtensions` viraram `private`, já que não eram usados fora do arquivo.
- Arquivos organizados em regiões. O auxiliar `AppendDiacritics` e o método interno `OrderByProperty` foram movidos para junto dos seus pares, o que era pré-requisito para as regiões.
- Metadados NuGet: `PackageTags` ampliadas e prefixadas com `tooark`.
- README revisado: seção de instalação, o `ModelStateExtension` que faltava no índice, e uma seção de catálogo de mensagens explicando o formato das chaves com parâmetros, a cobertura por idioma e como sobrescrever ou acrescentar traduções.

## 🔒 Segurança (Tooark.Dtos)

- **`PageSize` sem teto permitia pedir todos os registros em uma requisição.** O valor era aceito como veio, até `long.MaxValue`. É a alavanca real de coleta em massa em uma API de listagem — mais do que a existência dos links de navegação, que não concedem acesso algum: eles são montados a partir da própria requisição do chamador, e o `Total` já informa quantas páginas existem. O teto passou a ser 100 por padrão, ajustável por DTO.
- **Os links de paginação devolvem a query string inteira no corpo da resposta**, inclusive parâmetros que não são de paginação. Uma credencial ou um dado pessoal que trafegue na URL volta nos links, e daí para logs, cache e histórico do navegador. O comportamento foi mantido, porque descartar parâmetros desconhecidos quebraria a paginação de endpoints com filtro próprio, e está documentado no `PaginationDto` e no README: não trafegue credenciais na query string.

## 🔒 Segurança (Tooark.Attributes)

- **`RegexMatchTimeoutException` escapava de cinco dos seis atributos.** Só o de documento tinha a guarda, colocada na revisão do `Tooark.Enums`. E o estouro é alcançável: o padrão de email tem três classes quantificadas adjacentes com conjuntos sobrepostos, o formato clássico de retrocesso catastrófico. Com a entrada `'a'×64 + '@' + 'b'×64`, de 129 caracteres, o tempo cresce de 18 ms (65 caracteres) para 254 ms (113 caracteres) e estoura o limite de 300 ms. Em ASP.NET Core isso vira **500 em vez de 400**, e custa o tempo limite inteiro de CPU por requisição, em um campo de email comum e sem autenticação. Os seis atributos passaram a tratar o estouro como "não corresponde ao padrão".
- **Mensagem de erro trocada entre requisições concorrentes.** Com 20 000 validações simultâneas alternando entre campo vazio e formato inválido, 13 leram a mensagem de outra validação. A mensagem passou a ser devolvida por chamada, no `ValidationResult`, e o número de divergências caiu a zero — há um teste que exercita exatamente esse cenário.
- **Tipo de documento com erro de digitação desligava a validação.** `[DocumentValidation("CPFF")]` aprovava `"isso-nao-e-documento"`. Ver a seção de mudanças incompatíveis.

## 🔒 Segurança (Tooark.ValueObjects)

- **`Password` entregava a senha em texto puro sem que ninguém pedisse.** Havia conversão implícita para `string` e um `ToString()` que devolvia o valor — as duas formas pelas quais um objeto vaza sozinho, sem chamada explícita. Bastava a senha aparecer em uma mensagem de log estruturado, em uma interpolação de exceção ou em um objeto serializado para o valor ser gravado em claro. O caminho passou a ser único e explícito: `Value`. `ToString()` devolve a máscara e a conversão implícita de saída foi removida — a de entrada, `Password senha = "Senha@123";`, foi mantida, porque leva a senha _para dentro_ do objeto.
- **Objeto de valor reprovado devolvia nulo onde o tipo prometia texto.** Além do risco de `NullReferenceException` no consumidor, o efeito prático era pior no caminho de erro: um documento inválido gravado em log ou devolvido em uma resposta aparecia como campo ausente em vez de campo vazio, confundindo o diagnóstico exatamente quando ele é necessário.

## 🔒 Segurança (Tooark.Validations — padrão de email)

- **O padrão de email deixou de ser vulnerável a retrocesso catastrófico.** O anterior tinha três classes quantificadas adjacentes com conjuntos sobrepostos — o formato clássico do problema. Medido com a entrada hostil `'a'×n + '@' + 'b'×n`: 16 ms com 32 caracteres, 550 ms com 64, e **estouro do limite de 2 s** a partir de 96. O novo resolve em menos de 1 ms em todos os tamanhos, porque troca `A+B*A+` por `A(?:B*A)?`, sem sobreposição entre quantificadores adjacentes. A guarda de tempo limite acrescentada na revisão do `Tooark.Attributes` continua no lugar, agora como rede de segurança em vez de única defesa.

## 🔒 Segurança (Tooark.Entities)

- **Entidade que falhasse uma vez ficava impossível de excluir.** A notificação da chamada recusada ficava presa na entidade, e o `if (!IsValid) throw` de toda operação seguinte a encontrava. Em um endpoint de exclusão lógica, um primeiro pedido malformado bastava para que os pedidos corretos seguintes, sobre a mesma instância, fossem recusados — um negação de serviço por instância, disparado por entrada do próprio chamador.
- **Versão não incrementada silenciosamente no `AuditableEntity`.** Onde a `Version` é usada como token de concorrência otimista, a atualização por referência da classe base não a incrementava, e duas gravações concorrentes deixavam de ser detectadas: a última sobrescrevia a primeira sem conflito.

## 🔒 Segurança (Tooark.Extensions — entrega das traduções)

- **As traduções nunca chegavam a quem instala o pacote pelo NuGet.** Os arquivos de idioma eram publicados como `contentFiles/any/any/`, e `contentFiles` **não são copiados para a pasta de saída** com `PackageReference` — nem por referência transitiva, nem por referência direta. Verificado empacotando os pacotes em um feed local e consumindo de um projeto limpo: a pasta `Resources` não existia na saída e `Field.Empty;Id` saía como a própria chave. Isso alcançava **todas** as mensagens do ecossistema — validações, notificações e exceções de todos os pacotes.
- **O contorno documentado trazia arquivos de versões antigas.** O README mandava colar um alvo de MSBuild com o glob `$(NuGetPackageRoot)\**\Resources\**\*.json`, que varre o **cache global inteiro**: qualquer versão já restaurada de qualquer pacote entrava na cópia. Na verificação, o `pt-PT.default.json` — removido nesta versão — reapareceu na saída, vindo de uma instalação anterior. Um consumidor que subisse para a v4.0.0 continuaria recebendo tradução da v3, em silêncio e conforme a ordem dos arquivos.

## Correções (Tooark.Utils)

- **Idioma vazando entre requisições**: `InternalLanguage` guardava a cultura em um campo `static` e lia dela, então `Language.Current` era global ao processo mesmo com `CultureInfo.CurrentCulture` correto na thread. A leitura passou a vir direto do fluxo de execução, que o .NET propaga por requisição e por contexto assíncrono. Um teste cobre o cenário com duas execuções concorrentes e ordem forçada.
- **Upload convertido para `MemoryStream` sempre retornava nulo**: `ToMemoryStream(IFormFile)` decodificava bytes binários como texto UTF-8 e procurava `"base64,"` no resultado — condição que nenhum PDF, imagem ou documento real satisfaz. O teste existente passava porque montava o `IFormFile` com o **texto** de uma data URL, um caminho que nenhum consumidor usa. Agora o conteúdo é copiado byte a byte, e o teste usa bytes binários e confere o round-trip.
- **`Language.SetCulture(null)` estourava `ArgumentNullException`** vinda do `Regex`, em vez de aplicar a cultura padrão como faz com qualquer outro valor inválido. Nome nulo, vazio ou só com espaços passa a cair na cultura padrão.
- **`RegexMatchTimeoutException` escapava do `SetCulture`**: a validação do nome tem tempo limite de 250 ms, mas o estouro não era tratado — mesmo defeito já corrigido no `Tooark.Validations` e no atributo de documento. Agora resulta na cultura padrão.
- **Nome de cultura diferenciava caixa**: `"pt-br"` não passava na expressão regular e virava `en-US` silenciosamente, apesar de ser um nome de cultura válido. Passa a ser aceito e normalizado para `"pt-BR"` pelo próprio .NET.
- **`FileConvert.Extension` inventava extensão para base64 sem tipo**: a guarda comparava a posição da barra com `>= 0` depois de somar 1, então ela nunca era falsa. `"data:image;base64,QQ=="` devolvia `"DATA:IMAGE"`. A extração passa a exigir a barra e o ponto e vírgula depois dela.
- **`FileValid.IsCustom` exigia o ponto na extensão sem documentar**: `["pdf"]` reprovava e `[".pdf"]` aprovava o mesmo arquivo. As extensões passam a ser normalizadas, aceitas com ou sem o ponto, com espaços nas extremidades e em qualquer caixa; entradas em branco são descartadas e, se não sobrar nenhuma, valem as extensões padrão.
- **`GetInfo` estourava com lista nula**: a lista era percorrida sem verificação. Lista nula ou vazia passa a devolver string vazia, que já era o comportamento documentado para "nenhum item encontrado". A validação das propriedades continua acontecendo antes, para que o erro de tipo mal formado não seja mascarado.
- **`GenerateString.Password` embaralhava com `OrderBy` sobre chave aleatória**, que não produz permutação uniforme: chaves repetidas mantêm a ordem dos elementos empatados, preservando a distribuição cíclica dos tipos de caractere. Passou a usar Fisher-Yates com o gerador criptográfico.
- **Documentação divergente do código**: `Sequential` mostrava `"a"` no exemplo e devolve `"A"`; `Password` declarava `<exception cref="ArgumentException">` para um caso em que o código aplica os critérios padrão silenciosamente. Ambas alinhadas ao comportamento real.

## Correções (Tooark.Attributes)

- **Estado do atributo ficava sujo após o sucesso**: depois de uma validação que falhava, `ErrorMessage` continuava preenchido mesmo nas validações seguintes que passavam.
- **`LinkVideoValidationAttribute` usava `value as string`** enquanto os demais usavam `value?.ToString()`. Um `Uri` virava nulo e recebia `Field.Required`, mensagem errada para um campo que estava preenchido. Os seis passaram a converter da mesma forma.
- **O resultado da validação passou a apontar o membro validado** em `MemberNames`, que antes vinha vazio.

## Modificado (Tooark.Attributes)

- **`TooarkValidationAttribute` criado como base dos seis atributos**, concentrando valor ausente, montagem da mensagem, conversão do valor e execução da expressão regular com tempo limite. Os atributos concretos ficaram com a regra específica de cada um: o de email tem uma linha de lógica.
- **Todos os atributos aceitam `propertyName`**, que define o nome do campo na mensagem de erro. Antes só o de link de vídeo aceitava, e os outros cinco tinham o nome fixo no código. Os padrões continuam os mesmos, então as mensagens existentes não mudam.
- **`Tooark.Attributes.Messages.AttributeErrorMessages` criado**, seguindo o padrão dos demais pacotes, com as chaves `Field.Required`, `Field.Invalid`, `Attributes.DocumentTypeUnknown` e `Attributes.LinkVideoNoProvider`.
- **`Tooark.Exceptions` passou a ser declarado no `.csproj`**. Ele já chegava por transitividade através do `Tooark.Enums`; agora que o pacote o usa diretamente, a dependência é explícita.
- `partial` removido de cinco arquivos que não tinham outra parte, e o BOM ficou consistente entre os seis.
- Arquivos organizados em regiões.
- Metadados NuGet: `PackageTags` ampliadas e prefixadas com `tooark`, e removido o `ItemGroup` que copiava uma pasta `Resources` que não existe no pacote.
- README revisado: seção de instalação, o `LinkVideoValidationAttribute` que faltava (o pacote tem seis atributos e o README documentava cinco), o exemplo do atributo de documento corrigido — mostrava `[DocumentValidation(EDocumentType.CPF)]`, forma que nunca compilou —, seção de comportamento comum e links absolutos.

## Modificado (Tooark.Utils)

- **`FileConvert.ToMemoryStreamAsync` adicionado**, com `CancellationToken`, para a cópia do upload — que é operação de I/O e estava disponível apenas de forma síncrona.
- **`Tooark.Utils.Messages.UtilErrorMessages` criado**, seguindo o padrão do `Tooark.Exceptions` e do `Tooark.Validations`, com a chave `File.SizeExceeded` usada pelo limite de tamanho. A chave foi adicionada aos quatro recursos de tradução do `Tooark.Extensions` (`en-US`, `pt-BR`, `pt-PT` e `es-ES`).
- **Cópia do upload passou a ser feita em blocos**, com o destino já dimensionado pelo tamanho declarado, em vez de deixar o `MemoryStream` dobrar de tamanho durante a cópia.
- **Reflexão do `GetInfo` passou a ser cacheada** por tipo e nome de propriedade. Eram quatro buscas por reflexão a cada objeto renderizado, refeitas em toda chamada.
- **Argumentos anuláveis declarados como tais**: os métodos de `FileConvert`, `FileValid` e `GetInfo` já tratavam nulo internamente, mas anunciavam parâmetros não anuláveis. As assinaturas passaram a refletir o que o código faz.
- **`Language.Instance` passou a rejeitar nulo**, com `ArgumentNullException`, em vez de deixar a próxima leitura estourar sem contexto.
- **Arquivos organizados em regiões**, seguindo o padrão dos pacotes já revisados.
- `Normalize` deixou de ser `partial` sem outra parte, perdeu o `using` de expressões regulares que não usava e teve removidos três `case` inalcançáveis (`Ø`, `Ð`, `Ł`) — o `switch` opera sobre o caractere já convertido para minúsculo.
- `FileValid` documenta explicitamente que valida tamanho e extensão declarada no nome, sem inspecionar o conteúdo do arquivo.
- Metadados NuGet: `PackageTags` ampliadas para melhorar a descoberta no nuget.org, e removido o `ItemGroup` que copiava uma pasta `Resources` que não existe no pacote.
- README revisado: seção de instalação, seções de comportamento por utilitário (exigência de formato das culturas, extensões com ou sem ponto, retorno em maiúsculas de `Sequential`, tamanho exato do hexadecimal), exemplos corrigidos e links de licença e de pacotes agora absolutos.

## Correções (Tooark.ValueObjects)

- **`DelimitedString` estourava `NullReferenceException` nos dois construtores que recebem coleção** quando o argumento era nulo: `values.Length` e `values.Count` eram lidos dentro da própria montagem das validações, antes que qualquer verificação rodasse. O construtor que recebe texto já era seguro, porque validava antes de tocar no valor. Os três passaram a tratar o nulo como entrada vazia.
- **`DelimitedString` compartilhava a coleção com quem a construiu e com quem a lê.** A array recebida era guardada por referência e `Values` devolvia a mesma instância: alterar a array de fora alterava o objeto de valor, que por definição é imutável. Entrada e saída passaram a ser cópias.
- **`Password` duplicava a montagem do padrão de complexidade**, com uma implementação própria que divergia da do `PasswordValidationAttribute`: a mesma senha era aprovada por um e reprovada pelo outro. A montagem foi extraída para `PasswordPattern` no `Tooark.Validations`, e os dois passaram a usá-la.
- **Nomes de parâmetro trocados na documentação e na assinatura** — `Letter`, `LetterNumeric`, `Numeric` e `ZipCode` chamavam o próprio parâmetro de `email`, herança de cópia e colagem. A mensagem de erro de cada um já usava o campo certo; o que confundia era a assinatura vista pelo consumidor.

## Modificado (Tooark.ValueObjects)

- **Arquivos organizados em regiões**, seguindo o padrão dos pacotes já revisados.
- `Tooark.Exceptions` passou a ser referência direta do pacote, em vez de chegar por transitividade — é dele que vem a exceção lançada pelas conversões sem instância.
- Metadados NuGet: `PackageTags` ampliadas para melhorar a descoberta no nuget.org.
- README reescrito no formato dos demais pacotes: seção de instalação, o que `AddTooarkValueObjects` realmente faz, tabelas dos 33 objetos por família, o contrato de string vazia, o mascaramento do `Password` e a diferença entre as duas conversões implícitas. Todos os exemplos foram compilados e executados antes de publicar — o que corrigiu, entre outros, a afirmação de que as mensagens saem traduzidas: elas saem como chave (`Field.Invalid;Email`), e quem traduz é o `ResponseDto`.

## Correções (Tooark.Entities)

- **`SoftDeletableEntity` usava o código de notificação do `AuditableEntity`.** `ValidateNotDeleted` emitia `T.ENT.AUD1` nas duas classes, então o código não identificava o emissor. Passou a emitir `T.ENT.SOF1`, que é o valor que o README já documentava.
- **`EnsureNotDeleted` consultava o estado de notificação da entidade** em vez do próprio `Deleted`, e por isso recusava uma entidade íntegra quando havia qualquer notificação anterior registrada nela. Passou a verificar o estado diretamente.
- **O código do erro passou a ser transportado pela exceção.** Ao deixar de acumular a notificação na entidade, as três exceções que carregavam código — `T.ENT.INI1` na criação já registrada e `T.ENT.AUD1`/`T.ENT.SOF1` no `EnsureNotDeleted` — passariam a sair sem ele, porque o construtor de `BadRequestException` que recebe texto não guarda código. Um portador interno preserva a notificação completa sem registrá-la na entidade, e um teste exige o código das três.
- **`DetailedEntity.SetCreatedBy` atualizava `UpdatedById` mas não `UpdatedAt`**, que ficava com o valor da inicialização do campo. Chamado fora do construtor, o "quem" mudava e o "quando" ficava velho. As duas marcas passaram a nascer idênticas às da criação.

## Modificado (Tooark.Entities)

- Metadados NuGet: `PackageTags` passaram a começar por `tooark` e ganharam `audit`, `soft delete` e `versioning`. Removido o `ItemGroup` que copiava uma pasta `Resources` que não existe no pacote — o mesmo lixo já retirado do `Tooark.Utils`.
- A hierarquia foi mantida plana de propósito: `AuditableEntity`, `VersionedEntity` e `SoftDeletableEntity` herdam todas de `DetailedEntity`, e a duplicação entre elas é deliberada — C# não permite herança múltipla, e encadeá-las aumentaria a complexidade sem eliminar a repetição. No lugar da refatoração entraram testes de paridade, que exigem das implementações duplicadas o mesmo resultado para o mesmo roteiro.
- README corrigido contra o código: as dependências listavam o `Tooark.Utils`, que o pacote não referencia, e não listavam o `Tooark.Validations`, que ele usa; os value objects apareciam com o nome das propriedades (`CreatedById`) em vez do nome dos tipos (`CreatedBy`); `AuditableEntity.SetDeleted` era documentado recebendo `DeletedById` em vez de `DeletedBy`. Ganhou uma seção explicando como as operações de escrita reagem a valor inválido, uma tabela ligando cada código `T.ENT.*` ao seu emissor, e as quatro linhas do `FileEntity`, que emitia mensagens sem constar na tabela de erros. O link da licença virou absoluto. Os oito exemplos foram compilados, e as tabelas conferidas contra o código-fonte por um verificador que compara propriedades, métodos, colunas de banco, códigos, chaves de mensagem e dependências.

## Correções (Tooark)

- **O README não listava o `Tooark.AspNetCore`**, criado nesta versão. Quem lê o README do agregador não descobria que o pacote existe.
- **O agregador não registrava o mediador**, e quem instalava esperando "todos os recursos" só descobria em execução, com `Handler.NotFound`. `AddTooarkService` passou a registrá-lo, procurando os manipuladores no assembly que o chamou — e ganhou um `params Assembly[]` para quando eles estiverem em outro projeto, como é comum em aplicação em camadas. **O detalhe que faz a diferença**: o agregador captura o próprio chamador e o repassa. Chamar `AddTooarkMediator()` de dentro dele sem repassar faria o `GetCallingAssembly` devolver o assembly do agregador, que não tem manipulador algum — o mediador subiria registrado e vazio, pior do que não registrar. Chamar `AddTooarkMediator` depois continua seguro: o registro usa `TryAddEnumerable` e não duplica.
- **A unidade de trabalho segue fora do agregador**, porque `AddTooarkMediatorUnitOfWork` precisa do tipo do contexto do Entity Framework. Agora está documentado.

## Modificado (Tooark)

- Regiões aplicadas no `TooarkDependencyInjection`, último arquivo do repositório sem elas.
- Metadados NuGet: `PackageTags` passaram a começar por `tooark` — era o último pacote sem isso — e descrevem o que o agregador reúne. Removido o `ItemGroup` que copiava uma pasta `Resources` inexistente no projeto.
- README com seção de instalação própria, o link da licença absoluto e os exemplos compilados antes de publicar — o que já corrigiu o registro do mediador, que estava sem os `using` de `Tooark.Mediator.Injections` e `Tooark.Mediator.EntityFrameworkCore.Injections`.
- **`Tooark.Benchmarks` removido do repositório**: fora de uso, não publicado e ausente dos workflows. Saíram os oito arquivos, a entrada no `Tooark.sln` e a dependência `BenchmarkDotNet`, que ficou órfã no `Directory.Packages.props`.

## Modificado (Tooark.Notifications)

- **README ganhou a seção de instalação**, a última que faltava no repositório. Documenta também que o pacote não tem configuração, que os mutadores são protegidos de propósito — quem acumula a notificação é o próprio objeto — e que as mensagens são guardadas como chave, com a tradução ficando a cargo de quem monta a resposta.

## Modificado (Tooark.Tests)

- **Os 112 testes que faltavam ganharam o comentário de intenção**, convenção que o restante do projeto seguia: 110 no `Mediator`, um no `Tooark.AspNetCore` e um no `Tooark.Validations` que tinha o comentário separado do atributo por uma linha em branco. São 1854 atributos de teste, todos documentados, conferidos por um verificador que sobe do atributo ignorando `InlineData` e afins.
- **`TestException` existia em quinze cópias idênticas**, uma dentro de cada arquivo de teste das exceções. Consolidado em `Moq/Notifications/`, junto dos demais dublês compartilhados.
- **README do projeto criado**, com o que executar, como medir cobertura, o mapa de pastas por pacote, as convenções de nome, de comentário e de Arrange/Act/Assert, e o cuidado com os testes que alteram a cultura do processo. As afirmações foram conferidas contra o projeto por um verificador, e os comandos de exemplo executados.

## Outros

- **A solução migrou de `Tooark.sln` para `Tooark.slnx`**, o formato XML que o SDK do .NET adota desde a versão 9.0.200 e cria por padrão na 10. São 124 linhas a menos: saem os GUIDs, o `ProjectConfigurationPlatforms` e as quatro linhas de configuração por projeto, sobrando dezoito entradas de caminho. Era esse ruído que produzia diffs enormes ao acrescentar um projeto. **O que fazer**: quem clona precisa do SDK 9.0.200 ou superior — o `global.json` já exigia o 10 —, do Visual Studio 17.14+ ou do Rider 2024.3+. O `.sln` foi removido no mesmo commit de propósito: com os dois arquivos no mesmo diretório, `dotnet build` sem argumento falha com `MSB1011`, e é assim que o workflow constrói. Verificado que `dotnet build` e `dotnet test` sem argumento funcionam com apenas o `.slnx`.

- **Dependências do gerenciamento central**: entraram `Microsoft.EntityFrameworkCore` e `Microsoft.EntityFrameworkCore.Sqlite`, nas versões `8.0.30` e `10.0.11`, pelo novo `Tooark.Mediator.EntityFrameworkCore` e pelos testes de unidade de trabalho contra SQLite em memória. Saíram `Microsoft.AspNetCore.Mvc` e `Microsoft.AspNetCore.Mvc.Core`, substituídos pelo `FrameworkReference`, e o `BenchmarkDotNet`, com a remoção do `Tooark.Benchmarks`.
- **`PackageProjectUrl` passou a apontar para a pasta de cada pacote**, no `Directory.Build.props` — `.../tree/main/$(MSBuildProjectName)` —, em vez de todos os pacotes apontarem para a raiz do repositório. Quem chega pelo nuget.org cai direto no README do pacote que instalou. O `RepositoryUrl` segue apontando para a raiz, que é o que ele deve identificar.
- **Fim de linha normalizado no repositório**, com um `.gitattributes` (`* text=auto eol=lf`). O repositório estava misto — 361 arquivos com LF e 48 com CRLF, sem regra —, e qualquer ferramenta que reescrevesse um arquivo CRLF produzia um diff de arquivo inteiro. `*.sln` fica com `eol=crlf` na cópia de trabalho, porque o Visual Studio o reescreve assim, e imagens são marcadas como binárias. Não afeta o pacote publicado.
- **`.gitignore` revisado**: quatro arquivos versionados eram contraditos pelas próprias regras — `.vscode/settings.json`, `.vscode/tasks.json` e os dois scripts de exemplo do SonarQube, que tinham exceção declarada mas eram reignorados por `*.ps1` e `*.sh` vindo depois (a última regra que casa é a que vale). Acrescentadas as saídas de cobertura e do relatório HTML, e a regra `*.xml` — que escondia qualquer XML do repositório — foi restrita aos diretórios de build, seu propósito real.
- **`Tooark.AspNetCore` acrescentado à tabela de pacotes do README da raiz**, onde faltava desde a criação, embora já estivesse no workflow de publicação.
- **Links das seções de dependência passaram a apontar para o pacote no nuget.org**, e não para a pasta do projeto no GitHub: quem lê a lista de dependências quer instalar, não navegar no código. Os últimos links relativos dos READMEs também viraram absolutos, para resolverem quando renderizados fora da árvore do repositório.

- Referências do repositório atualizadas para [`Tooark/tooark-cs`](https://github.com/Tooark/tooark-cs) (renomeado; o sufixo `-cs` identifica o repositório C# na família Tooark). Metadados NuGet (`RepositoryUrl`/`PackageProjectUrl`) e links dos READMEs passam a ser publicados com a nova URL a partir desta versão; as URLs antigas seguem funcionando via redirect do GitHub.
- **Vulnerabilidade em dependência transitiva eliminada**: o `Tooark.Extensions` referenciava `Microsoft.AspNetCore.Mvc.Core` 2.3.12 — pacote avulso da linha 2.x do ASP.NET Core — que trazia `Microsoft.Extensions.DependencyModel` 2.1.0 e, por ele, `Newtonsoft.Json` 9.0.1, com vulnerabilidade de severidade alta ([GHSA-5crp-9r3c-p9vr](https://github.com/advisories/GHSA-5crp-9r3c-p9vr)). A árvore chegava ao `Tooark.Dtos`, `Tooark.Entities`, `Tooark.ValueObjects` e ao agregador `Tooark`. Nenhum código do repositório usava o Newtonsoft: onde há JSON, já era `System.Text.Json`. Os pacotes avulsos foram substituídos por `FrameworkReference` do `Microsoft.AspNetCore.App`, que fornece `ModelStateDictionary`, cache em memória e localização a partir do framework compartilhado — o `Newtonsoft.Json` saiu dos grafos de todos os projetos, e o `Tooark.Extensions` passou a declarar uma única dependência NuGet (`Tooark.Utils`), no lugar de três mais a árvore transitiva.
  - O defeito estava mascarado: o `Tooark.Exceptions` referenciava `Microsoft.AspNetCore.Mvc` sem usar, e o meta-pacote elevava o `Newtonsoft.Json` para uma versão corrigida. O mascaramento só valia dentro do repositório — quem instalava o `Tooark.Extensions` sem o `Tooark.Exceptions` já recebia a versão vulnerável. A remoção da referência inútil foi o que revelou o problema.
- **`PackageTags` uniformizadas nos pacotes revisados**: todos passaram a começar por `tooark`, que é o termo pelo qual a família é procurada no nuget.org e faltava em `Tooark.Notifications`, `Tooark.Observability` e `Tooark.Securities`. O `Tooark.Securities` ganhou `cryptography` e `token`; o `Tooark.Enums` perdeu as tags de documento (`cpf`, `cnpj`, `cnh`, `rg`), que descreviam o `Tooark.Validations` e não o pacote de enumeradores.
- **Workflow de publicação**: passa a empacotar e enviar o `Tooark.Mediator.EntityFrameworkCore`, antes do agregador `Tooark`, que depende dele. A criação da release deixou de ter o repositório fixo na URL e usa `${{ github.repository }}`: a API REST responde 301 para repositório renomeado e o `POST` não era repetido no novo endereço, então a release deixaria de ser criada — e, como o passo não checa o status HTTP, o job passaria mesmo assim.

## Testes

- Suite validada com sucesso em ambos os TFMs após as alterações:
  - `4000` testes aprovados (`net8.0`)
  - `4000` testes aprovados (`net10.0`)
  - `0` falhas, `0` ignorados
- Cobertura por pacote revisado (coverlet, `net10.0`):
  - `Tooark.Notifications`: **100%** linhas / **100%** branches / **100%** métodos
  - `Tooark.Mediator`: **100%** linhas / **97,22%** branches / **100%** métodos
  - `Tooark.Mediator.Abstractions`: **100%** linhas / **100%** branches / **100%** métodos
  - `Tooark.Mediator.EntityFrameworkCore`: **100%** linhas / **93,75%** branches / **100%** métodos
  - `Tooark.Validations`: **99,29%** linhas / **94%** branches / **100%** métodos
  - `Tooark.Enums`: **100%** linhas / **99%** branches / **100%** métodos
  - `Tooark.Observability`: **97,99%** linhas / **93,39%** branches / **100%** métodos
  - `Tooark.Exceptions`: **100%** linhas / **96,15%** branches / **100%** métodos
  - `Tooark.Securities`: **97,78%** linhas / **95,52%** branches / **100%** métodos
  - `Tooark.Utils`: **98,73%** linhas / **93,92%** branches / **100%** métodos
  - `Tooark.Attributes`: **100%** linhas / **96,29%** branches / **100%** métodos
  - `Tooark.Extensions`: **96,48%** linhas / **88,99%** branches / **100%** métodos
  - `Tooark.AspNetCore`: **100%** linhas / **100%** branches / **100%** métodos
  - `Tooark.Dtos`: **100%** linhas / **100%** branches / **100%** métodos
  - `Tooark.ValueObjects`: **100%** linhas / **100%** branches / **100%** métodos
  - `Tooark.Entities`: **100%** linhas / **100%** branches / **100%** métodos
  - `Tooark`: **100%** linhas / **100%** branches / **100%** métodos
- Testes atualizados que codificavam comportamento antigo: mensagem nula gerando `MessageUnknown` e mensagem vazia permanecendo vazia; fallback silencioso de chave → exceção no startup; `FormatException` crua → `BadRequestException`; claim ausente → campos vazios; asserts de `ThrowsAny<Exception>` estreitados para o contrato real.
- Dublês de teste que herdam de `Notification` passaram a expor explicitamente os mutadores protegidos, refletindo a nova superfície pública do pacote.
- Novos testes (Notifications): coleção e array nulos, itens nulos dentro das coleções, auto-adição sem efeito, mensagem em branco, chave com tabulação e quebra de linha, código nulo ou em branco, tipo nulo nas sobrecargas com `Type`, conversões implícitas com nulo e reutilização da coleção somente leitura.
- Novos testes (Mediator e Observability): requisição com dois manipuladores falhando no registro (por tipo e por fábrica), notificação com múltiplos manipuladores seguindo aceita, manipulador que falha ao iniciar não impedindo os demais na estratégia paralela, `Unit.Task` devolvendo sempre a mesma instância e conversões implícitas de `EProcessorType`/`EProtocolOtlp` a partir de nulo.
- Novos testes de documentos: CPF e CNPJ com dígitos corretos e incorretos, sequências de caractere repetido, o exemplo alfanumérico do material do Serpro, caixa das letras normalizada, documentos combinados e valores nulos ou vazios.
- Testes atualizados que fixavam comportamento antigo nas validações: documentos fictícios válidos apenas no formato substituídos por documentos reais, IPv6 comprimido movido do conjunto inválido para o válido.
- Novos testes da unidade de trabalho, contra SQLite em memória para exercitar transações reais: comando persistindo sem o manipulador chamar `SaveChanges`, exceção do manipulador impedindo a persistência, consulta fora da esteira mesmo com alteração pendente no contexto, comando aninhado persistindo junto com o externo e revertendo junto em caso de falha (nas duas estratégias), estratégia desconhecida e coleção de serviços nula falhando no registro, e unidade de trabalho registrada no escopo do contexto.
- Novos testes do pipeline de behaviors: envolvimento do manipulador, ordem de execução por registro, curto-circuito sem invocar o manipulador, alteração da resposta, propagação do token de cancelamento, behavior genérico aberto, registro idempotente do mesmo behavior, tipo inválido e genérico aberto sem correspondência falhando no registro, tarefa nula do behavior, `Handler.NotFound` antes de qualquer behavior executar, provedor que devolve os behaviors como enumerável preguiçoso e behavior genérico aberto com restrição aplicando-se apenas às requisições que a satisfazem.
- Testes do Mediator migrados do registro direto de `MediatorOptions` para `services.Configure<MediatorOptions>` e `IOptions<MediatorOptions>`, exercitando o mesmo caminho que os consumidores passam a usar.
- Novos testes (Enums): descrição em caixas diferentes e com espaços resolvendo para o mesmo valor nos três enumeradores, conversão de instância nula lançando `Invalid.Parameter;null`, `IsValid` devolvendo falso em vez de lançar para entrada nula, vazia ou não numérica, e dígitos verificadores de CNH e de RG, com o RG informado sem dígito seguindo aceito.
- Testes atualizados que fixavam comportamento antigo: RG e CNH fictícios, válidos apenas no formato, substituídos por documentos com dígito verificador correto.
- Novos testes (Exceptions): lista e notificação nulas, lista e notificação vazias, mensagem nula/vazia/em branco, item nulo dentro da lista mantendo as duas leituras alinhadas, coleções rejeitando alteração externa e reutilizadas a cada acesso, exceção interna preservada nas quinze exceções, formato incompatível mantendo a mensagem e lista de parâmetros vazia.
- Novos testes (Securities — validação assíncrona): token válido, expirado, com assinatura inválida, com audience incorreta, sem chave pública configurada e paridade de resultado entre `Validate` e `ValidateAsync`.
- Novos testes (Utils): idioma isolado entre dois fluxos de execução concorrentes com ordem forçada, idioma acompanhando `CultureInfo.CurrentCulture`, nome de cultura em caixas diferentes, cultura nula/vazia/em branco caindo no padrão, instância de `ILanguage` nula lançando, upload binário com round-trip de bytes na versão síncrona e na assíncrona, upload vazio, base64 sem tipo declarado, nome de arquivo terminado em ponto, extensões personalizadas com e sem ponto, lista nula e vazia no `GetInfo`, propriedade não textual e propriedade com valor nulo, hexadecimal de tamanho ímpar e alfabeto do hexadecimal, senha contendo cada tipo ativado, senha respeitando os tipos desativados e variação da sequência de tipos entre gerações.
- Novos testes (Dtos): tamanho de página limitado pelo teto padrão e pelo teto sobrescrito, inclusive quando informado pelo construtor, e valor negativo continuando a significar tamanho ignorado; última página alcançável em total múltiplo e não múltiplo do tamanho, e ausente de fato na última página; links anterior e seguinte sem interferência entre si e preservando os filtros; requisição e busca ausentes lançando; chave e valor do metadado independentes; coleções da resposta recusando alteração externa e reaproveitadas entre leituras; metadados copiados na atribuição; construtores aceitando argumentos ausentes; mensagem de notificação localizada uma única vez, com e sem código; tradução funcionando sem registro no container; e registro sem duplicatas resolvendo o localizador do Tooark.
- Testes atualizados que fixavam comportamento antigo (Dtos): o teste chamado `WithLimitNext` afirmava que a penúltima página não tem página seguinte, exatamente o defeito corrigido; e o teste do metadado com chave nula esperava que o valor fosse descartado.
- Novos testes (Extensions): os três idiomas com exatamente o mesmo conjunto de chaves, nenhum texto vazio, os mesmos marcadores de parâmetro em todos os idiomas, dezesseis chaves representativas de cada pacote traduzidas nos três idiomas sem sobrar marcador, idioma sem arquivo próprio não fixando os parâmetros da primeira consulta nem entre instâncias diferentes, chave inexistente sinalizada com os parâmetros preservados no nome, chave existente não sinalizada, e o `pt-PT` removido caindo no idioma padrão.
- Testes atualizados (Extensions): os casos de valor nulo dos conversores de caixa passaram a esperar string vazia, e o teste do `ToSlug` deixou de usar o operador de acesso condicional, que impedia o caminho nulo de ser exercitado.
- Novos testes (Attributes): mensagem configurada pelo consumidor preservada e mantida ao longo de validações repetidas, chave padrão usada quando não há configuração, atributo sem estado após falha e após sucesso, 20 000 validações concorrentes sem troca de mensagem, nome de campo personalizado, valor só com espaços tratado como ausente, entrada que estoura o tempo limite da expressão regular sendo reprovada em vez de lançar, tipo de documento não reconhecido lançando e `None` explícito continuando aceito, link de vídeo sem provedor lançando, senha sem critérios exigindo apenas o comprimento, comprimento configurado respeitado e valor não textual convertido.
- Testes atualizados que fixavam comportamento antigo (Attributes): as afirmações sobre `atributo.ErrorMessage` passaram a ler o `ValidationResult` da chamada; os casos de link de vídeo sem provedor saíram do conjunto de inválidos e viraram teste de exceção; e o caso de senha com `length: 7` mudou de conjunto, porque o comprimento configurado passou a ser respeitado em vez de elevado para 8.
- Novos testes (Utils — segurança do `FileConvert`): tipo declarado com travessia de diretório, com barra, com marcação, com byte nulo e com 300 caracteres, todos resultando em nulo; tipo MIME sem forma de extensão (`svg+xml`, `vnd.ms-excel`); tipo declarado com parâmetro (`charset`) ainda resolvendo a extensão; nome de arquivo hostil no `IFormFile`; extensão longa no nome do arquivo; marcador `base64,` fora do formato de data URL; conteúdo com vírgula extra; marcador aceito sem diferenciar caixa; limite padrão e limite informado excedidos na base64 e no upload; conteúdo exatamente no limite sendo aceito; upload que declara tamanho menor que o conteúdo real sendo barrado durante a leitura, nas versões síncrona e assíncrona; e limite ampliado permitindo o upload acima do padrão.
- Teste atualizado que validava um caminho inexistente: `ToMemoryStream(IFormFile)` era exercitado com o **texto** de uma data URL escrito em um `MemoryStream`, o único formato em que a implementação antiga funcionava; passou a usar bytes binários.
- Novos testes (ValueObjects): objeto reprovado devolvendo o vazio do próprio tipo em vez de nulo nos 33 tipos — string vazia em 29 deles, `Guid.Empty` nos quatro de auditoria —, `ToString()` de objeto reprovado, `Password` mascarando na interpolação e expondo o valor só por `Value`, senha reprovada não carregando valor, paridade de resultado entre `PasswordValidationAttribute` e `Password` sobre a mesma senha, `DelimitedString` com nulo nos três construtores, incluindo os dois que estouravam, coleção de entrada e de saída copiadas, e `Document` sem tipo aceitando texto alfanumérico enquanto `Document` com tipo reprova o mesmo valor.
- **Teste por reflexão das conversões de saída**: em vez de um caso por tipo, o teste enumera todos os `op_Implicit` que recebem o próprio objeto de valor e exige de cada um o mesmo contrato — `InternalServerErrorException` com `Invalid.Parameter;null`. Um objeto de valor novo, ou uma conversão nova em um objeto existente, entra no teste sem que ninguém precise lembrar de escrevê-lo.
- Testes atualizados que fixavam o comportamento antigo (ValueObjects): 26 arquivos afirmavam `Assert.Null(x.Y)` para objeto reprovado — a promessa de não-nulo que o tipo declarava e não cumpria — e passaram a afirmar `Assert.Equal(string.Empty, x.Y)`.
- Novos testes (Entities): versão incrementando também pela referência da classe base, nas duas implementações; entidade seguindo utilizável depois de uma chamada recusada, na exclusão e na atualização; `EnsureNotDeleted` indiferente a notificação anterior; argumento nulo reportado como campo obrigatório nas quatro operações; exclusão e restauração registrando quem alterou; criação nascendo com `CreatedAt` e `UpdatedAt` iguais; igualdade separando tipos diferentes com o mesmo identificador e o `Distinct` deixando de descartar registros; chaves emitidas presentes nos três idiomas; e repetição da exclusão e da restauração sendo ignorada sem alterar autor nem versão.
- Novo teste (Entities) do código do erro nas exceções: `T.ENT.INI1`, `T.ENT.AUD1` e `T.ENT.SOF1` conferidos na notificação transportada, junto com a entidade seguindo íntegra. Sem ele, a mudança para não sujar a entidade teria feito os três desaparecerem em silêncio.
- **Testes de paridade entre as implementações duplicadas** (Entities): como `AuditableEntity`, `VersionedEntity` e `SoftDeletableEntity` não podem herdar umas das outras, a duplicação é permanente — os testes exigem das cópias o mesmo resultado para o mesmo roteiro, de versionamento e de registro de autoria. Foi a divergência entre elas que produziu dois dos defeitos corrigidos.
- Testes atualizados que fixavam comportamento antigo (Entities): dezesseis casos afirmavam `Assert.False(entidade.IsValid)` depois de uma chamada recusada — exatamente o envenenamento corrigido — e passaram a afirmar que a entidade segue íntegra; as afirmações sobre `entidade.Notifications` depois da exceção passaram a ler `ex.GetErrorMessages()`; as chaves `Empty;Id` e `ChangeBlocked;CreatedBy` acompanharam a mudança para a família `Field.*`; e os `Assert.Null` do `FileEntity` passaram a esperar string vazia.
- Novos testes (Tooark): mediador registrado pelo agregador resolvendo o manipulador do assembly chamador e do assembly informado, ausência de duplicidade quando o `AddTooarkMediator` é chamado depois, configuração das opções ainda possível após o registro, e unidade de trabalho seguindo fora do agregador.
- **Teste da guarda de tempo limite refeito** (Attributes): ele usava o retrocesso catastrófico do padrão de email para provocar o estouro. Com o padrão corrigido, a entrada passou a ser reprovada por formato, e a guarda ficou sem cobertura — o teste continuava passando, pelo motivo errado. Passou a exercitar `Matches` com um padrão deliberadamente patológico, e o teste antigo foi renomeado para o que de fato verifica.
- Novo teste (Attributes): tipo de documento ausente tratado como desconhecido, cobrindo o caminho que a ampliação para anulável criou.
- Novos testes (Securities): `CBCUnsafe` decrypt-only, `SecretBase64` sozinho e com prioridade sobre `Secret`, Base64 inválido/tamanho errado no startup, algoritmo JWT inválido/nulo lança, default ES256, secrets HMAC no limite exato e abaixo do mínimo (HS256/384/512), ECDsa sem chaves fail-fast, `PublicKey` nula sem fallback, audience incorreta → `Token.Invalid`, token sem claims esperadas, serviço sem logger, e sobrecarga `UserTokenDto(JsonWebToken)` (com e sem claims).

## Impacto

- **Breaking change de API pública no `Tooark.Notifications`** — ver a seção de mudanças incompatíveis. Nenhum projeto do repositório precisou de ajuste: todo o código de produção já chamava os mutadores a partir do próprio objeto.
- **Pipeline de behaviors é aditivo**: quem não registra behavior nenhum não percebe diferença — o despacho continua sendo a invocação direta do manipulador, sem montagem de cadeia.
- **Novo pacote `Tooark.AspNetCore`** — quem usa `ModelState.GetErrors()` instala o pacote e troca o `using`. Em troca, `Tooark.Extensions`, `Tooark.Utils`, `Tooark.ValueObjects`, `Tooark.Entities`, `Tooark.Attributes` e os demais deixam de exigir o runtime do ASP.NET Core, e voltam a rodar em imagem `dotnet/runtime`, worker e função serverless.
- **Novo pacote `Tooark.Mediator.EntityFrameworkCore`**, também disponível pelo agregador `Tooark` — que passa a trazer o Entity Framework Core como dependência transitiva. Adotar a unidade de trabalho exige remover o `SaveChanges` dos manipuladores de comando: mantê-lo funciona, mas persiste duas vezes.
- **Breaking change no `Tooark.Mediator`** — quem configurava o mediador por `AddTooarkMediator` não é afetado. Quem registrava ou resolvia `MediatorOptions` diretamente no container precisa migrar para `services.Configure<MediatorOptions>` e `IOptions<MediatorOptions>`; sem a migração, a configuração passa a ser ignorada silenciosamente. Aplicações com mais de um manipulador para a mesma requisição deixam de subir — a configuração já estava errada e o manipulador excedente nunca executava.
- **Breaking change de configuração no `Tooark.Observability`** — `Observability:DataSensitive` passou a ser `Observability:AllowSensitiveData`. Migração esquecida não expõe dados: sem o bind, o default `false` mantém a sanitização ativa.
- **Breaking change no `Tooark.Exceptions`** — o retorno de `GetErrorMessages()` e `GetNotifications()` passou de `IList<T>` para `IReadOnlyList<T>`: leitura por índice, `Count` e `foreach` seguem iguais, mas atribuições tipadas como `IList<T>` param de compilar. O pacote também deixou de arrastar o `Microsoft.AspNetCore.Mvc`, que chegava por transitividade em quase todo consumidor do Tooark; aplicações que dependiam disso precisam referenciá-lo explicitamente. Em compensação, exceção construída sem mensagem utilizável deixou de produzir erro vazio, e lista ou notificação nula deixou de estourar `NullReferenceException`.
- **Breaking change no `Tooark.Enums` e no `Tooark.Validations`** — RG e CNH passam a ter o dígito verificador conferido pelas duas APIs, que antes discordavam entre si; documentos gravados com dígito incorreto são reprovados na próxima validação. A conversão de um enumerador nulo para `int` ou `string` deixou de estourar `NullReferenceException` e passou a lançar erro com contexto, e `ECloudProvider` deixou de diferenciar caixa.
- **Breaking change no `Tooark.Attributes`** — `DocumentValidationAttribute` passou a receber o tipo como texto. Não há código a migrar: o atributo era impossível de aplicar, então nenhum consumidor podia estar usando.
- **Breaking change no `Tooark.Dtos`** — o teto de `PageSize` é a mudança que mais aparece: um cliente que hoje pede 500 registros passa a receber 100, em silêncio, até o endpoint sobrescrever `PageSizeMax`. Vale revisar os endpoints de listagem antes de subir. Em compensação, a última página de qualquer listagem paginada passa a ser alcançável pelos links, o que corrige respostas que hoje escondem dados.
- **Correção de alcance amplo no `Tooark.Extensions`** — quem usa o `IStringLocalizer` do Tooark passa a receber mensagens traduzidas onde antes recebia chaves cruas, sem parâmetro. Isso vale para todas as validações, notificações e exceções do ecossistema. A migração exige atenção em dois pontos: aplicações que dependiam do `pt-PT` passam a responder em inglês até fornecerem o próprio arquivo, e textos que já eram exibidos ao usuário final mudam de conteúdo — de `Validation.IsNotNullOrEmpty` para a frase traduzida.
- **Correção de comportamento no `Tooark.Attributes`** — quem consome as validações pelo `Validator`, pelo ModelState ou pelo MVC só ganha correção: a mensagem passa a ser a da validação em curso, e a mensagem configurada no atributo passa a valer. Quem lia `atributo.ErrorMessage` diretamente precisa migrar para `GetValidationResult`. Três configurações que antes eram aceitas em silêncio passam a falhar alto: tipo de documento desconhecido, link de vídeo sem provedor, e — sem lançar, mas mudando de resultado — critérios de senha desabilitados e comprimento abaixo de 8, que agora valem como escritos.
- **Breaking change no `Tooark.Securities` restrito a quem implementa `IJwtTokenService`** — as assinaturas e os tipos existentes foram preservados e quem apenas consome o serviço não é afetado. A interface ganhou `ValidateAsync`, então implementações próprias precisam do novo membro; dublês gerados por framework de mock continuam compilando.
- **Mudanças de comportamento no `Tooark.Securities`** — configurações inválidas que antes falhavam silenciosamente ou em runtime passam a falhar no startup com erro claro: `SecretBase64` inválido/tamanho errado, algoritmo JWT desconhecido, secrets HMAC abaixo do mínimo da RFC 7518 e algoritmos assimétricos sem nenhuma chave.
- **Breaking change no `Tooark.ValueObjects`** — objeto reprovado devolve string vazia onde antes devolvia nulo, então verificações escritas como `== null` deixam de encontrar o caso e passam a tratar dado inválido como válido. É a mudança que exige revisão: procure por comparações com nulo sobre propriedades de objeto de valor e troque por `IsValid`. Em compensação, interpolação e serialização deixam de depender de sorte, e a conversão de uma referência nula passa a dizer qual conversão falhou em vez de estourar `NullReferenceException`. O `Password` deixou de sair em texto puro sozinho: onde a conversão implícita era intencional, troque por `.Value`.
- **Breaking change no `Tooark.Entities`** — a mudança que mais aparece é a entidade deixar de acumular notificação nas operações de escrita: quem lia `entidade.Notifications` depois de capturar a `BadRequestException` passa a ler `ex.GetErrorMessages()`, ou `ex.GetNotifications()` para chegar ao código do erro. Em compensação, some o pior efeito do modelo antigo, em que uma entidade recusada uma vez ficava inutilizável para sempre. A versão do `AuditableEntity` passa a incrementar por qualquer caminho de chamada, o que restaura a detecção de concorrência otimista onde ela estava desligada; a exclusão e a restauração passam a gravar `updated_by` e `updated_at`; e entidades de tipos diferentes com o mesmo identificador deixam de ser iguais, o que muda o resultado de `Distinct` e de `HashSet` sobre coleções heterogêneas. As chaves de mensagem do pacote mudaram de nome e, com isso, passaram a ter tradução — antes a chave crua chegava ao usuário final.
- **O agregador `Tooark` passou a registrar o mediador** — quem instala o agregador deixa de precisar do `AddTooarkMediator`. Em aplicação de projeto único não há nada a fazer; em aplicação em camadas, informe os assemblies dos manipuladores em `AddTooarkService(configuration, assemblies)`. Um `AddTooarkMediator` explícito já existente continua funcionando e não duplica registros. **Atenção**: aplicações com mais de um manipulador para a mesma requisição passam a falhar na subida, porque a validação do mediador agora roda — a configuração já estava errada e o manipulador excedente nunca executava.
- **Correção de alcance total na entrega das traduções** — quem instala qualquer pacote Tooark pelo NuGet passa a receber as mensagens traduzidas sem configurar nada. Antes elas chegavam como chave crua, a menos que o consumidor colasse um alvo de MSBuild que varria o cache global do NuGet e podia trazer arquivos de versões antigas. **Atenção na migração**: remova esse alvo do seu `.csproj` — mantê-lo agora só serve para reintroduzir traduções obsoletas.
- **Correção de segurança no `Tooark.Utils`** — o `FileConvert` deixou de devolver texto do cliente sem verificação e passou a limitar o tamanho convertido. Aplicações que usavam a extensão retornada para montar caminho de gravação estavam expostas a travessia de diretório; aplicações que convertiam base64 vindo do corpo da requisição estavam expostas a esgotamento de memória. **Atenção na migração**: a conversão agora lança `PayloadTooLargeException` acima de 5MB — quem trabalha com arquivos maiores precisa informar `maxBytes`, e quem tratava apenas o retorno nulo precisa tratar também a exceção.
- **Breaking change de comportamento no `Tooark.Utils`** — o idioma atual passou a ser por fluxo de execução. Aplicações web que definem a cultura por requisição (`RequestLocalizationMiddleware` ou `Language.SetCulture` no início do pipeline) só ganham correção. Processos em segundo plano que dependiam de definir a cultura em um ponto e lê-la em outra thread, sem propagação de contexto, precisam passar o idioma explicitamente. A conversão de upload para `MemoryStream` passou a devolver o conteúdo real do arquivo, onde antes devolvia nulo.
- Consumidores que capturavam `FormatException`/`CryptographicException` do `Decrypt` devem capturar `BadRequestException`; consumidores que tratavam `InternalServerError` para audience/issuer inválidos devem tratar `Token.Invalid`.

---

## Informações Adicionais

- Tag relacionada: `v4.0.0`
- Data de lançamento: **24/08/2026**
- Tipo de release: **Major — mudanças incompatíveis (Notifications, Mediator, Observability, Validations, Securities, Exceptions, Extensions, Enums, Attributes, Utils, Dtos, ValueObjects, Entities e Extensions) + novos pacotes (Mediator.EntityFrameworkCore e AspNetCore) + correções de segurança (Securities, Utils, Attributes, Dtos, ValueObjects e Entities)**