Rullst v12 release program

Reabertura da auditoria em 2026-09-05: o relatório CLIFIX.md e novas regressões identificaram lacunas na experiência gerada, no estado do ORM durante troca de DLL e em limites de segurança. A RC permanece NO-GO. Os percentuais e a conclusão de teto abaixo são a fotografia anterior, pendente de reavaliação; não representam a prontidão atual. A auditoria de release registra a revisão de todas as crates, com triagem leve de IoT, e as correções/gates restantes.

Status em 4 de setembro de 2026: programa de trabalho auditável, não anúncio de lançamento. A decisão atual é NO-GO para 12.0.0 estável e preparação de uma 12.0.0-rc.1 somente depois dos gates P0 abaixo.

Este documento transforma a ambição da versão 12 em tarefas verificáveis. Ele deve ser atualizado na mesma alteração que conclui uma tarefa. A especificação continua sendo a fonte normativa; o capability ledger registra o limite das capacidades, o hardening status registra evidências de validação e o roadmap preserva a visão de longo prazo. O comparativo técnico separa diferenciais já comprovados das prioridades competitivas sugeridas para a RC e a v13.

Como marcar o programa

• [x] concluído: há código ou documento, teste proporcional ao risco e uma afirmação pública compatível com a evidência;
• [~] parcial: existe uma base útil, mas a condição restante está escrita ao lado e ainda não deve ser anunciada como pronta;
• [ ] pendente: não foi implementado ou ainda não foi verificado;
• [!] bloqueador de release: a RC ou a estável não pode avançar enquanto o item estiver aberto.

Uma execução local verde prova apenas o commit e o ambiente executados. Ela não substitui CI multi-OS, ambientes reais de provedores, homologação, auditoria externa ou experiência de usuários independentes.

Fotografia de progresso

Em 2026-09-04, este documento contém 204 itens: 77 concluídos, 64 parciais e 63 abertos. A contagem estrita é 37,7%; atribuindo metade do peso aos parciais, o avanço mecânico é 53,4%. O inventário também inclui o programa Omni web-first/platform-enhanced, publicação irreversível, observação pós-RC e gates da versão estável que só podem ser fechados depois; por isso essa contagem não é a prontidão da RC. Depois de elevar o gate para A em todas as crates exceto IoT/B e esclarecer que 90 é piso, não alvo, a auditoria separou o piso da campanha de teto local. A estimativa de prontidão de engenharia/operacional da RC é agora cerca de 91,8%: 8,2% permanece. Essa estimativa inclui elevar cada crate ao melhor teto v12 local responsável, congelar e repetir os gates no SHA exato. A versão, a inspeção dos 16 pacotes e o consumidor externo passaram no commit limpo 27e81152; a revisão documental e a repetição no futuro SHA final da RC continuam abertas. Ela não inclui operar a RC por semanas, homologar provedores/fisco, testar hardware/lojas ou cumprir gates exclusivos da versão estável.

Essa estimativa não esconde os contadores objetivos: há 28 linhas marcadas [!] (oito parciais e vinte abertas), embora várias sejam repetições do mesmo gate em sua seção detalhada e no resumo da versão estável. No scorecard, Core, ORM, Security, Connect, Auth, Mail, Messaging, AI, Capital, Nexus, as duas crates de macros, cargo-rullst, Studio e a facade rullst já estão em A, e IoT satisfaz a exceção B. A lacuna até os pisos aprovados é agora zero e a campanha de tetos locais está completa; isso não substitui os gates do SHA candidato. A tabela de qualidade registra cada distância sem tratá-la como quantidade de tarefas. A campanha não parou no piso: os tetos locais das 15 crates ativas somados ao IoT/B aceito totalizam 1.509/1.600, exatamente os 1.509 pontos agora apoiados por evidência versionada. Assim, a campanha de teto local chegou a 100% e zero pontos de planejamento permanecem. A pontuação de um SHA ainda depende de todos os gates aplicáveis ficarem verdes e não é sinônimo dos 8,2% de prontidão operacional restantes.

O gate geral de cobertura foi alcançado no candidato sem testes artificiais. Com o trabalho restante agora delimitado, a previsão responsável é 1–2 dias de trabalho efetivo para concluir auditoria documental/semântica e eventuais correções, mais 1–3 dias de relógio para matrizes pesadas e repetição final. É uma faixa, não uma promessa: falhas nos testes pesados, dependências/advisories ou lacunas descobertas na auditoria podem ampliá-la. O piso A/IoT-B já foi alcançado no teto auditado, mas ainda precisa ser confirmado pelo conjunto de gates do SHA exato.

A estimativa de 91,8% usa uma régua explícita de planejamento, distinta do scorecard:

Os percentuais de estado das três últimas frentes são estimativas conservadoras e serão substituídos por 100% apenas quando a evidência do SHA candidato existir. Isso evita somar como pronto um workflow meramente configurado.

As porcentagens são uma fotografia manual, não uma métrica de segurança. Devem ser recalculadas quando itens mudarem de estado e nunca substituem a decisão GO/NO-GO.

1. Decisão de release

O fluxo permanente de integração é branch curta → main → tag. Durante o programa v12, main contém o trabalho ativo e a branch congelada v5 preserva o último baseline legado. A presença de código numa branch não o transforma em release: somente um pacote do crates.io e sua tag imutável correspondente são artefatos oficiais. Os critérios de desenvolvimento, prontidão e release estão separados no RELEASE_GUIDE.md.

• Tratar v12 como um programa de estabilização, e não como uma lista de superlativos.
• Manter a estável em NO-GO enquanto os gates obrigatórios estiverem abertos.
• [~] Congelar novas funcionalidades antes da RC. Até que o novo gate de notas seja alcançado, somente capacidades delimitadas que fechem uma lacuna auditada de qualidade podem entrar; depois disso, aceitar apenas correções, testes, documentação e mudanças indispensáveis à release.
• [!] Fazer uma revisão final deste checklist e registrar a decisão GO/NO-GO com data, commit e responsáveis.

A RC vai para o crates.io?

Sim. A proposta é publicar 12.0.0-rc.1 no crates.io, e não apenas criar uma tag privada. Uma prerelease é pública e permanente: ela pode ser yanked, mas o mesmo número de versão nunca pode ser substituído. Usuários precisam optar explicitamente por ela, por exemplo:

[dependencies]
rullst = "12.0.0-rc.1"

• Sincronizar todos os pacotes publicáveis e requisitos internos em 12.0.0-rc.1 numa alteração exclusiva de preparação da release. Os 16 manifests publicáveis, a facade, o CLI e o lockfile já formam um único trem de versão; o preflight de metadata com --locked passou localmente.
• [~] [!] Gerar, inspecionar e testar os pacotes exatos antes de qualquer upload irreversível. No commit limpo 27e81152, os 16 .crate registraram o mesmo SHA sem dirty state, passaram a auditoria de conteúdo, compilaram num consumidor externo all-feature e forneceram o CLI que gerou e compilou os seis blueprints. Falta repetir a prova sobre o futuro commit aprovado da tag.
• Criar a tag v12.0.0-rc.1 somente no commit aprovado.
• Publicar na ordem topológica documentada em AGENTS.md.
• Verificar indexação, documentação e instalação usando apenas crates.io.
• Corrigir os problemas encontrados em rc.2, rc.3, etc.; nunca republicar o mesmo número.
• Publicar 12.0.0 somente após uma janela real de uso da RC.

Referências oficiais: Publishing on crates.io e SemVer no Cargo.

2. Congelamento, versões e migração

• Os 16 pacotes publicáveis do workspace usam atualmente 12.0.0-rc.1 nos manifests locais.
• [~] [!] cargo metadata --locked confirmou 16 pacotes publicáveis em 12.0.0-rc.1, com dependências internas declarando path e requisito da mesma prerelease. O preflight topológico e a auditoria dos arquivos passaram no commit limpo 27e81152; falta repetir a prova no SHA hospedado aprovado da prerelease.
• Centralizar a ordem topológica em .github/release-order.json e validá-la contra o conjunto publicável, a versão da tag, os requisitos internos e o DAG antes de empacotar; o preflight positivo e a rejeição de versão divergente passaram localmente.
• [!] Manter o worktree da release limpo e associar toda evidência ao SHA da tag.
• Curar o changelog de v12 por impacto ao usuário: o topo agora resume migração/compatibilidade, fronteiras de segurança, contratos de IA e observabilidade, enquanto o inventário técnico detalhado permanece preservado e explicitamente separado para rastreabilidade.
• Criar guias de migração v5 → v12, v6 → v12 e dependências da era v11 → v12, preservando a evidência de que somente v5 tem tag entre essas baselines. O caminho também transformou cargo rullst upgrade numa transação assistida extensível: planejamento humano/JSON sem escrita, descoberta exata do workspace, edição TOML que preserva comentários e reconhece aliases, catálogo versionado de riscos v5, alvo preso à major da CLI, snapshot de manifests/lock/fontes, cargo fix/cargo check, rollback automático e restauração persistida após interrupção. Testes process-level cobrem plano, JSON, sucesso e falha com rollback. O comando não altera banco, segredo, autorização ou fronteiras de produção; esses gates continuam manuais e documentados no tutorial de upgrade assistido.
• Publicar a matriz de features da crate guarda-chuva e das outras 14 crates, incluindo defaults, aliases, integrações opcionais, seleção estrita de banco e limites dos simuladores.
• Documentar política de MSRV, depreciação, compatibilidade e suporte de patch/minor em compatibility-policy.md, incluindo limites de prerelease, janela suportada e exceção fail-closed para segurança.

3. CI reproduzível no commit exato

Evidência local atual no commit candidato limpo 27e81152, reexecutada em 2026-09-04 — útil para desenvolvimento, mas ainda não substitui os mesmos gates na futura tag:

• cargo test --workspace --all-features verde, incluindo testes de integração, dez projetos gerados e doc-tests.

• cargo clippy --workspace --all-features -- -D warnings verde, exatamente conforme a tríade normativa de AGENTS.md. O gate hospedado acrescenta --all-targets e também passou no mesmo candidato.

• cargo fmt --all -- --check e git diff --check verdes.

• [!] cargo fmt --all -- --check verde na tag.

• [!] cargo clippy --workspace --all-targets --all-features -- -D warnings verde na tag.

• [!] cargo test --workspace --all-features verde na tag.

• [!] CI principal verde em Linux, macOS e Windows no mesmo commit.

• [~] Testes reais de SQLite, PostgreSQL e MySQL, com isolamento e evidência da execução: as três matrizes exclusivas de rullst-orm passaram localmente em 2026-08-28, com PostgreSQL e MySQL em Testcontainers Docker. Isso prova o CRUD ORM delimitado nesse host, não o workspace/Academy inteiro nem o SHA da tag.

• [~] Matrizes --no-default-features, features mínimas, combinações críticas e MSRV verdes: .github/check-feature-boundaries.sh passou localmente em 2026-08-29 compilando as 16 crates publicáveis sem defaults, 32 fronteiras isoladas de adapters/facade e executando os testes de Core sem defaults. Além disso, cargo +1.96.0 check --workspace --all-features passou localmente no worktree atual. O gate é reutilizado pela CI principal e pela release; as matrizes estritas de banco e o job MSRV já existem, mas todos ainda precisam ficar verdes no SHA final da RC.

• Doc tests, Wasm/no_std, E2E, benchmarks, fuzzing delimitado, Miri, Kani, sanitizers e os gates Omni verdes para seus alvos declarados. A nova geração desktop executou localmente de ponta a ponta, incluindo npm e ícones, em 2026-08-30. O host não possui pkg-config/GLib, então o shell emitido também passou cargo check num contêiner Rust 1.96/Debian com os pré-requisitos oficiais do Tauri. Desktop Linux/macOS/Windows, Android aarch64 APK e iOS simulator passaram nos workflows hospedados do commit 755fbd61933bed04369e0eb5de50b11275db5e3d; o item agregado continua aberto pelos demais gates nomeados e porque compilação não prova aparelho/loja. No candidato intermediário 45fbdbe7, Miri, Kani e os sanitizers passaram; a campanha de fuzzing revelou três harnesses desatualizados e um panic real de fronteira UTF-8 no redator de URLs de banco. Os quatro achados foram corrigidos localmente, o caso Unicode virou regressão unitária e seed de corpus, e os alvos de parser ORM, redator e sanitizer passaram 100.000 execuções cada com libFuzzer/AddressSanitizer em 2026-09-05. A campanha completa ainda precisa passar novamente no SHA final, portanto o item permanece aberto. Para reduzir o ciclo de correção sem reduzir o gate, o workflow agora compila os 40 alvos em dez preflights antes das campanhas longas e separa um diagnóstico estrito de cinco minutos para exatamente um alvo; o resumo recusa explicitamente esse diagnóstico como evidência de RC. Mutations também aceita um único arquivo Rust de produção para feedback de correção, sem substituir a campanha completa. A tentativa de dezesseis shards usava a superfície default-feature, deixou testes opcionais fora da classificação e projetou 11–17 horas nos grupos mais lentos. O workflow agora exige --all-features e reparte o mesmo inventário medido de 14.380 mutantes em 80 shards de no máximo aproximadamente 180 candidatos. Antes de iniciar essa matriz, um --list --json barato exige a lista exata e única; o agregado final precisa corresponder aos mesmos nomes, além de classificar todos eles uma única vez. Isso é configuração validada, não resultado da campanha final. No SHA 36411ea1, 39 dos 40 alvos completaram integralmente 5h30; somente fuzz_parser encontrou uma terceira árvore válida que fazia a obtenção incondicional de Field::span() renderizar um tipo patológico por mais de dez segundos. Todos os diagnósticos do parser atingíveis por campos e tipos agora usam identificadores delimitados, o terceiro caso foi preservado no corpus e o reprodutor ASan exato caiu de cerca de 12,1 segundos para aproximadamente 30 milissegundos localmente. Uma nova campanha ASan local de cinco minutos completou 1.740.804 execuções sem achados. O diagnóstico hospedado 34495340300 completou mais 1.541.970 execuções em 301 segundos no commit de código corrigido 40c1b083, também sem achados. O resultado ainda não fecha este item: a campanha completa dos 40 alvos precisa passar no SHA candidato congelado.

• Auditar os dez doctests antes marcados ignore: nove agora compilam como testes ou no_run; o único ignore restante é o exemplo da crate proc-macro, justificado para evitar dependência circular e coberto pelo teste de integração da facade. Um doctest ignorado não é contado como exemplo compilado.

• Criar um harness Cargo-aware para os 52 tutoriais públicos: o módulo rullst/src/book_doctests.rs, habilitado somente por cfg(doctest), lê os Markdown originais em vez de manter cópias. Em 2026-09-05, cargo test --workspace --all-features identificou 106 blocos Rust, compilou/executou 88, registrou 18 fragmentos deliberadamente contextuais e terminou com zero falhas. Como o CI e a release já executam cargo test --workspace --all-features, a mesma verificação é bloqueante nesses gates; o SHA remoto ainda precisa repetir a evidência.

• Estender o mesmo harness aos 27 guias públicos não tutoriais que contêm Rust. Em 2026-09-05, rustdoc reconheceu 203 exemplos no livro: 177 compilados/executados e 26 fragmentos ignore com contexto declarado, zero falha. O recorte não tutorial corresponde a 97 exemplos, 89 compilados/executados e oito contextuais. Um teste de inventário descobre os arquivos Markdown na raiz e em docs/src/crates, impedindo que um novo guia com Rust fique fora do gate silenciosamente. A evidência remota ainda deve ser repetida no SHA congelado da RC.

• Auditoria, licenças, fontes, dependências duplicadas, typos e SemVer sem falhas ou com exceções datadas, justificadas e com prazo.

• Reexecutar no candidato todos os workflows que falharam ou ficaram sem evidência no commit-base; o nome de um workflow não conta como prova.

3.1 Programa Omni web-first, platform-enhanced

O web app é a experiência canônica e universal. Domínio, identidade, autorização, dados, realtime e segurança continuam sob autoridade do servidor. Omni empacota essa experiência e poderá acrescentar capacidades do dispositivo sem duplicar a regra de negócio nem confiar no cliente. Isso serve aplicativos ricos — colaboração, comunidade, mensagens ou educação no estilo Duolingo — mas não promete gerar o produto, conteúdo ou UX final com um clique. Para jogos, Rullst pode fornecer backend/web/contas/realtime; não substitui um motor gráfico.

• Tornar o contrato web-first/platform-enhanced normativo no SST e manter segurança/autorização no servidor.
• Derivar nome/versão do host, aceitar overrides validados e exigir identificador reverse-DNS application-owned no Android/iOS.
• Remover placeholders publicáveis do caminho mobile e gerar JSON/CSP sem interpolação textual insegura.
• Negar navegação fora da origem exata no runtime nativo e não expor IPC privilegiado à página remota.
• Gerar bootstrap local acessível com estado inicial offline/retry, sem chamá-lo falsamente de sincronização offline.
• Fazer o backend desktop localhost falhar fechado em porta pré-ocupada, child exit ou timeout e encerrar somente o processo que iniciou.
• Workflow desktop Linux/macOS/Windows passou no SHA 755fbd61933bed04369e0eb5de50b11275db5e3d; ele verifica o crate gerado, não installers assinados nem uma sessão GUI/WebView.
• Workflow Android aarch64 compilou um APK debug no mesmo SHA; isso não equivale a aparelho, assinatura ou Play testing.
• Gate iOS compilou o simulador com identidade application-owned no mesmo SHA; ele continua sem evidência de aparelho, signing ou App Store.
• Implementar opener/deep-link OAuth com allowlists, state/nonce e callback single-use sem alargar a navegação para qualquer HTTPS.
• Definir perfis opt-in de push, biometria e armazenamento Keychain/Keystore com permissões mínimas, negativos de replay/cross-account e fallback web.
• Criar contrato tipado/versionado cliente-servidor compartilhável por web, shells e futuros frontends ricos sem tornar o cliente autoridade: rullst::client_contract define rullst.client v1, negociação positiva, envelopes privados tipados, IDs/chaves/códigos delimitados, tempo do servidor, JSON máximo de 2 MiB e rejeição de campos/versões desconhecidos; testes negativos e wasm32-unknown-unknown passam. O contrato não carrega role/tenant/autorização nem oferece idempotência durável ou sync offline.
• [~] Implementar perfil offline real: a feature nativa opt-in offline-sync agora fornece estado v1 ligado à conta, snapshots autenticados AES-256-GCM, fila FIFO idempotente, revisões/cursor do servidor, aplicação atômica, conflitos sem client-wins implícito, full resync, quotas, recovery e erasure lógico. Um coordinator por dispatch estático limita batches/páginas, exige timeout por request, interrompe retry sem progresso e rejeita cursor travado sobre transport autenticado da aplicação. Ainda faltam adapters Keychain/Keystore e persistência atômica por plataforma, browser/IndexedDB, HTTP concreto, retry/background, migrações concretas futuras, UX da aplicação e testes de processo/aparelho; portanto o shell não é anunciado como offline-first.
• [~] Criar um aplicativo de referência vertical rico — educação é um bom candidato — que prove mídia/áudio, progresso, gamificação e realtime E2E sem alegar que conteúdo/pedagogia são gerados pelo framework. O Academy gerado agora materializa a fatia web: modelo e migration distinguem vídeo/áudio, player SSR exige HTTPS ou origem local, vídeo exige WebVTT, toda aula exige transcrição/idioma delimitados e o teste executado prova escaping, nonce, ausência de autoplay e rejeições. Isso se integra ao progresso, avaliação/score, leaderboard, conquista, automação e realtime já testados no mesmo projeto. Ainda não é uma aplicação E2E rica: faltam playback/browser, conteúdo e pedagogia, fala/microfone, UX integrada, dispositivos e operação externa.
• Definir budgets e testes de startup, memória, tamanho, acessibilidade, rede ruim/reconexão e vazamento de segredos por plataforma.
• Executar contratos em aparelhos Android/iOS reais e registrar versões de SO/WebView, limitações e evidência reproduzível.
• Preparar assinatura, manifests de privacidade, beta tracks e checklist de submissão; aprovação das lojas permanece externa.
• Implementar atualização desktop assinada, rollback e política de canais antes de anunciar atualização automática do aplicativo.

4. Cobertura e qualidade dos testes

O número observado anteriormente foi aproximadamente 83%, mas não explicava seu escopo. A baseline oficial inicial, publicada pelo Codecov para o SHA 04006e82 em 2026-09-01, era:

• 79,37% (54.937/69.212) no agregado público de produção, incluindo CLI e proc-macros, mantido visível como indicador informativo;
• 84,40% (42.334/50.161) nas bibliotecas do framework selecionadas pelo status bloqueante da RC;
• 100% no patch do checkpoint, acima do gate de 90%.

O checkpoint completo usado por esta auditoria, publicado para o SHA 28e2cea9 em 2026-09-03, é:

• 84,97% (68.228/80.289) no agregado público de produção, incluindo CLI e proc-macros; esse agregado passa a ter gate próprio de 90%;
• 91,26% no componente público framework_libraries, acima do gate de 90%;
• 95,28% no componente rullst-auth, 93,09% em rullst-security, 62,93% no CLI e 91,28% nas proc-macros informativas.

O checkpoint predecessor completo mais recente, também publicado em 2026-09-03, avançou para 85,16% (70.026/82.227) no repositório inteiro e 91,32% (55.945/61.265) em framework_libraries; Auth ficou em 95,28%, Security em 92,51% e o CLI em 62,93%. O workflow de cobertura concluiu com sucesso, mas esse sucesso prova a geração e o upload do relatório, não o atendimento automático do status de projeto em 90%.

O lote candidato 704b6d4d acrescenta testes de processo com assertivas sobre scaffolds de controller/middleware/worker/LiveView/gRPC, inspeção, OpenAPI/SDK, empacotamento, deploy offline, diagnósticos, auditoria, Foundry, Omni, mail, chat, Academy, banco, migração automática com diferença real de schema e ejeção com backup. Codecov mediu 90,0337% (74.032/82.227) no repositório inteiro: 27 linhas cobertas acima do menor inteiro que satisfaz o corte exato de 90%. O componente framework_libraries ficou em 91,2952% (55.932/61.265), Auth em 95,28%, Security em 92,51%, CLI em 85,48% e proc-macros em 91,29%.

A comparação prévia por arquivo e linha havia encontrado 4.053 linhas de produção antes não cobertas e projetado 90,0908% mantendo o denominador do predecessor. O resultado oficial confirmou o gate, mas com o colapso LCOV em 74.032 hits, razão para nunca publicar a projeção como resultado. O artefato bruto retido pelo workflow registra 88,9181% (76.659/86.213) no resumo JSON do LLVM; o importador LCOV do Codecov registra as linhas únicas usadas pelos status públicos. As duas representações e seus denominadores são preservados, sem mistura ou média. O resultado precisa ser repetido no SHA congelado da RC; este checkpoint não autoriza antecipar a tag.

O candidato de release 27e81152 repetiu e ampliou o gate em 2026-09-04. O relatório oficial do Codecov registra 90,06% (74.219/82.408) no repositório inteiro e 91,33% (56.119/61.446) em framework_libraries; Auth ficou em 95,35%, Security em 92,54%, CLI em 85,48% e proc-macros em 91,29%. O patch medido ficou em 100%. O resumo bruto LLVM do mesmo artefato usa outra deduplicação de linhas e registrou 88,95% (76.858/86.401); ele não substitui nem é combinado com o modelo LCOV oficial usado pelos status públicos.

O primeiro recorte focado posterior a essa baseline elevou localmente rullst-messaging de 85,64% (1.962/2.291) para 90,22% (2.067/2.291). As novas regressões exercitam gramáticas e limites públicos, leases expirados em ACK/retry/dead-letter, teto de tentativas, retenção e inscrições duráveis, indisponibilidade do arquivo e corrupção individual de envelope, fingerprint, timestamp, tentativa, dead letter e versão do schema. Isso é evidência local do crate, não altera retroativamente o agregado oficial nem substitui o relatório do próximo SHA no Codecov.

O segundo recorte focado elevou localmente rullst-studio de 64,11% (1.926/3.004) para 90,28% (2.899/3.211). O relatório mescla os perfis SQLite, PostgreSQL, MySQL e MariaDB e exercita descoberta de schema, relações, dashboard, paginação, busca HTMX, mutações tipadas, feature flags, migrations e estados inválidos ou ausentes. Os testes revelaram e corrigiram descarte de links reais no dashboard, classificação incorreta de TINYINT(1) como inteiro, alias incompatível no diagrama ER do MySQL/MariaDB e chave primária TEXT inválida para feature flags nesses backends. Como no recorte anterior, esse é um resultado local que só se torna baseline oficial depois do upload do SHA.

Esses números são evidência de planejamento, não da futura tag. Line coverage não comprova adequadamente um gerador executado como processo nem o diagnóstico de uma proc-macro: cargo-rullst deve ser bloqueado por scaffolds gerados e compilados; macros, por testes compile-pass/compile-fail. Isso não autoriza ocultar sua cobertura — os componentes continuam publicados no Codecov como informativos. A meta deve ser perseguida por risco e em etapas, sem testes que apenas executem linhas sem validar comportamento.

O relatório total inclui o código de produção de todas as crates do workspace. O novo status bloqueante geral inclui toda a produção do workspace. O status separado framework_libraries seleciona as bibliotecas runtime e exclui somente cargo-rullst e as duas crates de proc-macros, que também mantêm gates funcionais próprios. Exemplos, benchmarks, documentação, artefatos gerados, fixtures auxiliares e arquivos de teste separados não entram no denominador. Testes inline ainda podem aparecer no mapeamento LLVM do mesmo arquivo de produção; o número oficial será o relatório final do Codecov no SHA da RC. O repositório usa um único codecov.yml; a CI autentica o upload pelo OIDC efêmero do GitHub, envia cobertura de linhas estável e produz semanalmente um artefato experimental de branches com Rust nightly. Enquanto a instrumentação de branches do Rust for instável, essa métrica é observacional e não bloqueia sozinha a release.

• [~] [!] Produzir relatório de cobertura válido e vinculado ao SHA da RC. O candidato 27e81152 é válido, público e passa os três gates; falta repetir a evidência no SHA congelado da RC.
• [~] [!] Configurar ≥90% de line coverage no agregado completo e nas bibliotecas do framework para RC e estável, sem tolerância. O componente de bibliotecas alcançou 91,33% e o agregado 90,06% no candidato 27e81152; a configuração declara ambos os gates. Falta repeti-los no SHA congelado da RC.
• Configurar ≥90% de patch coverage como status obrigatório; o candidato 27e81152 alcançou 100%, e falta reproduzi-lo no SHA da RC.
• Configurar componentes Codecov separados para framework_libraries, rullst-auth, rullst-security, CLI e proc-macros. As bibliotecas, Auth e Security bloqueiam a release em ≥90% de linhas; CLI e macros permanecem públicos e informativos porque seus gates principais são scaffolds e testes compile-pass/compile-fail.
• [~] Baseline oficial crítica acima da meta: rullst-auth 95,35% e rullst-security 92,54% no SHA 27e81152. Falta comprovar os mesmos componentes no SHA da RC.
• [~] Medir branch coverage e fazê-la crescer: a coleta semanal/manual em nightly e a retenção dos relatórios estão configuradas; falta estabelecer a primeira baseline válida e uma política de não regressão compatível com a estabilidade da instrumentação.
• [~] [!] Garantir que nenhum caminho crítico fique com 0% de cobertura. O recorte local agora cobre resolução fail-closed e persistência da APP_KEY, cookie Secure em produção, coordenadas WebAuthn ausentes, Origin WebSocket malformada, continuidade/tamper da audit chain, envelopes Vault inválidos e corpos RASP com encoding, UTF-8 ou tamanho não inspecionável. Ainda falta o inventário completo por threat model e a comprovação no SHA da RC.
• [~] [!] Derivar dos threat models e testar todos os casos negativos aplicáveis às fronteiras críticas de autenticação, autorização, parsing, criptografia, webhooks, tenancy, SQL e filesystem. O gate .github/check-threat-model-release-minimum.sh liga TM-12.10 a 67 linhas de evidência, 55 abuse-case IDs e 59 execuções de teste exatas em treze crates, cobrindo Core, ORM, Auth, Nexus, Studio, tenancy, Capital, AI, Mail, IoT, deploy e Academy, inclusive identificadores SQL dinâmicos e acesso a arquivos, e falha se um filtro passar a executar zero testes. O mínimo TM-12.10 completo passou localmente em 2026-09-03, inclusive o CAS concorrente e a recuperação do token store de Connect, o negativo de adulteração/rotação do journal SIEM e a compilação dos projetos gerados. A repetição integral no SHA hospedado da RC e os demais casos ainda não inventariados continuam abertos.
• [~] Cobrir ORM raw/migrations/pool, Core Redis/DB por feature/dylib, Mail facade/attachments, handlers de Nexus/Studio e Security schema/rate/RBAC/headers/timing/vault. A anotação #[orm(encrypted)] agora cobre String/Option<String> de ponta a ponta: insert/read/update parcial, rotação por keyring, contexto autenticado de tabela/coluna, tamper, nullable, pluck_string não-null e recusa de consultas incompatíveis com ciphertext aleatório. O FieldEncryptor emite o envelope normativo RULLST:v2 e ainda lê o prefixo de desenvolvimento ENC:v2; permanecem as demais superfícies listadas e a evidência do SHA final.
• [~] Cobrir timeouts, cancelamento, erros de provedores e políticas de tools em rullst-ai: os seis transports live agora aplicam deadline configurável de 30 segundos por padrão, ProviderCapabilities fixa o contrato e servidores loopback provam o timeout e o formato compatível (AI-06). O novo caminho OpenAI-compatible prova streaming delimitado e cancelamento explícito durante espera/leitura. Ainda faltam os protocolos diferentes, circuit breaker, concorrência e a matriz de erros reais dos provedores.
• [~] Cobrir a CLI por execução end-to-end e macros por testes de compilação e diagnósticos, mesmo quando instrumentos tradicionais não medirem bem esses processos. Os testes process-level de academy:doctor provam saída JSON, exit status fail-closed e o caminho completo evidenciado sem certificação; os macros mantêm trybuild. A matriz E2E dos demais comandos públicos continua aberta.
• Manter componentes informativos separados para CLI e proc-macros, sem misturá-los ao status bloqueante das bibliotecas nem omiti-los do relatório.
• Manter a matriz estrutural das 18 formas públicas da v12 e a compilação de projetos gerados como gate separado: ela mede validade dos artefatos, não line coverage. A matriz anterior de 270 combinações incluía labels de frontend e ORM que não possuíam paridade entre blueprints e foi substituída junto com esses seletores.
• Auditar “Hadouken code” em produção por profundidade e complexidade cognitiva. O único alerta acima do limite foi rullst-orm-macros::parser::parse (30/25): o parser foi separado em estados de atributos de modelo/campo, os arquivos resultantes ficaram abaixo de 500 linhas e o alvo de produção passou Clippy estrito com -W clippy::cognitive-complexity. A nova matriz também expôs e corrigiu a desserialização Redis que exigia Default e ocultava cache ausente/malformado.
• Tornar a gramática de rullst-orm-macros fail-closed: atributos agora usam syn::Attribute::parse_nested_meta; opções desconhecidas, duplicadas, órfãs ou incompatíveis falham em compilação. A derive valida identificadores, id persistido, alvos de tenant/soft-delete/embedding e invariantes de relações antes do codegen. Vinte e quatro fixtures trybuild, a suíte focada da proc-macro e as matrizes rullst-orm --all-features passaram localmente; compatibilidade de compilador/ecossistema além da matriz continua externa.

A meta não deve ser alcançada por testes sem assertivas úteis em funções triviais. A ordem é: caminhos negativos do threat model, fronteiras críticas, erros/cancelamento e, por fim, lacunas legítimas do restante do workspace.

5. Empacotamento e docs.rs

• RUSTDOCFLAGS="-D warnings" cargo doc --workspace --all-features --no-deps -j 2 passou em 2026-08-29; os doc tests também passaram no último cargo test --workspace --all-features. O mesmo gate continua obrigatório na tag pelo bloco de CI acima.
• [~] [!] Os 16 .crate de 12.0.0-rc.1 foram gerados e auditados localmente no commit limpo 27e81152; todos registraram esse SHA e dirty=false. O consumidor extraído compilou todos os recursos, instalou o CLI empacotado e compilou Blank, LMS, SaaS, Blog, Portfolio e ERP. O ensaio integral passou com jobs limitados, inclusive a construção nativa do DuckDB. Falta repetir o gate sobre o futuro commit aprovado da RC.
• [~] A primeira inspeção dos 15 arquivos .crate então existentes revelou licenças ausentes em 13 pacotes e um arquivo .env.test_autofix indevido na crate guarda-chuva. As licenças foram padronizadas, inclusive em rullst-messaging; o .env* foi excluído do pacote e o workflow agora bloqueia quantidade/nome/tamanho inesperados, caminhos inseguros, padrões de segredo, estado SQLite de runtime, conteúdo obrigatório ausente e licença divergente. O gate local passou nos 16 arquivos 12.0.0-rc.1 de 27e81152; falta repeti-lo nos artefatos do futuro commit aprovado da RC.
• O gate .github/test-packaged-distribution.sh extrai os 16 .crate em diretório temporário, compila offline um consumidor que referencia todos os pacotes e recusa dependências geradas por path antes de aplicar patches que apontam exclusivamente para o conteúdo extraído dos arquivos empacotados.
• O mesmo gate instala cargo-rullst a partir de seu .crate, usa o binário instalado para gerar Blank, LMS, SaaS, Blog, Portfolio e ERP de forma não-interativa e executa cargo check --offline --all-targets em cada projeto. As dependências internas geradas agora herdam CARGO_PKG_VERSION, inclusive prereleases, em vez de fixar auxiliares em 12.0.0.
• Confirmar a construção de todas as páginas no docs.rs.
• [~] Remover, atualizar ou isolar dependências opcionais obsoletas: a dependência Leptos sem uso foi eliminada, proc-macro-error3 foi atualizado e o lockfile substituiu o wnaf 0.14.0 yanked por 0.14.1. cargo audit passou localmente com somente a exceção já governada; falta reproduzir Cargo Audit/Cargo Deny e registrar a evidência no SHA final.

6. Bootstrap e publicação no crates.io

• [~] O workflow de release empacota antes do upload e publica na ordem topológica. Falta provar o bootstrap das crates ainda não registradas e o fluxo completo numa tag candidata.
• O validador de tag aceita versões estáveis e prereleases SemVer, incluindo v12.0.0-rc.1.
• [~] [!] O gate .github/check-crates-ownership.sh consulta o crates.io na verificação e novamente imediatamente antes do upload, exige venelouis nos nomes registrados e só aceita 404 para a allowlist revisada. Em 2026-08-29, seis nomes estavam registrados para o proprietário esperado e nove retornaram 404 dentro da allowlist de bootstrap; falta reexecutar e preservar a evidência no SHA final da RC.
• [~] [!] O job publish, protegido pelo ambiente GitHub crates-io, usa OIDC nos crates registrados e seleciona CRATES_IO_BOOTSTRAP_TOKEN somente nos nomes classificados como inéditos. O runbook limita o token a publish-new e exige Trusted Publishing, revogação e remoção do secret/allowlist após o bootstrap; faltam configurar os controles externos e executar/revogar a credencial na primeira RC real.
• [~] O workflow agora aguarda indexação e compara o checksum retornado pelo crates.io após cada publicação; falta observar o mecanismo numa RC real.
• Documentar recuperação de publicação parcial: inventário/checksum por crate, retomada apenas do prefixo ausente, uso obrigatório de nova prerelease para bytes alterados, yank, comprometimento de credencial e comunicação.
• [~] O job de publicação baixa os artefatos atestados, valida seus checksums, reproduz os 16 .crate a partir da tag e exige igualdade byte a byte antes do upload; depois confirma o checksum do registry. Falta a evidência de uma execução real e a proveniência continua limitada pelas fronteiras declaradas do GitHub Actions/crates.io.

7. Programa de segurança v12+

O objetivo não é apagar as ambições antigas. É convertê-las em contratos menores, testáveis e honestos. Controles criptográficos e afirmações de conformidade só recebem [x] após revisão especializada proporcional ao risco.

Baseline obrigatório

• Definir um production preset canônico: o contrato público tipado ProductionPreset::middleware_order() e a arquitetura documentam e testam a ordem externa→interna de proxy, limite de corpo, request ID, tracing, headers, CORS, WAF/RASP, CSRF, sessão, autenticação, tenant, autorização, rate limit e handler. Camadas de identidade continuam explicitamente pertencendo à aplicação, pois o framework não pode inventar sua política de domínio.
• Tornar readiness e shutdown um contrato executável do Core: ApplicationLifecycle registra no máximo 32 componentes imutáveis, mantém fases monotônicas, nega novas requisições antes de ready, sob dependência indisponível ou durante drain, e aguarda de forma limitada as requisições já aceitas. Server marca ready depois do bind, começa drain antes da espera do Axum, encerra como stopped e aceita um future de supervisor em run_with_shutdown. /ready revela somente fase/contagens; os testes CORE-01/02 cobrem startup, indisponibilidade, lock corrompido, timeout, corrida de admissão e listener real. Probes, auth de domínio, consenso entre réplicas, propagação do load balancer e deadline operacional continuam no host/deployment.
• Criar threat models versionados para autenticação, Nexus, Studio, tenancy, webhooks/pagamentos, AI/tools, atualização IoT, deploy e Academy: TM-12.10 define ativos, fronteiras, abuse-case IDs, controles, evidências e riscos residuais. A revisão independente do candidato exato continua no gate final.
• O scanner IDOR agora exige classificação adjacente public|owner|role|admin, recusa mutação classificada como pública e exige um guard reconhecido nas demais. O gate também recusa anotações sem justificativa e ausência de arquivos Rust. Sete negativos unitários, o inventário de rotas parametrizadas do workspace, os seis blueprints e as 18 variantes da matriz estrutural pública da v12 passaram. As mutações do ERP, antes públicas, agora reutilizam NexusAuthPolicy::protect_router; testes HTTP provam a fronteira administrativa (200 local, 403 remoto/sem peer) e ownership real (200 owner, 403 cross-owner, 200 moderator, 401 sem identidade). O ERP materializado passa cargo check --offline --all-targets. Isolamento multi-tenant completo continua no item específico abaixo e a prova deve ser repetida sobre o SHA da RC.
• Nexus falha fechado sem política explícita; o atalho local exige build de debug, peer loopback verificado e ConnectInfo.
• Nexus aceita tenant text opt-in por model, propaga o TenantContext confiável por toda rota built-in e recusa contexto ausente/input protegido. O audit opt-in obrigatório compartilha a transação da mutação e falha fechado; a documentação preserva que o storage é o mesmo banco, mutável e sem registro de tentativas negadas ou chave auto-gerada uniforme.
• Fazer revisão independente da política de acesso do Nexus e dos fluxos CRUD/batch/AI.
• [~] Implementar rate limit distribuído, idempotência durável e audit trail append-only para deploys com múltiplas instâncias. A feature rullst-security/redis-rate-limit fornece contador fixed-window atômico em Lua, namespace validado, chaves de cliente hasheadas, TTL/retry e erros tipados; o modo vazio/mock_* é explicitamente local e require_distributed() o rejeita em startup de produção. Um contrato opt-in passou localmente contra Redis real e roda em CI/release com duas instâncias independentes do limiter e imagem fixada por digest. Faltam cluster/failover, idempotência compartilhada e sink de auditoria durável.
• [~] Consolidar headers seguros, CSP nonce, CORS e CSRF numa baseline testada em navegador e proxy reais. Core agora expõe uma composição canônica única e o Server a utiliza: a configuração validada é instalada antes dos middlewares, e a ordem externa→interna é headers → CORS → WAF → CSRF → PII opcional → handler. A allowlist CORS aceita apenas origins HTTP(S) exatas, rejeita wildcard/path/query/credenciais/duplicatas, limita métodos/headers e habilita credenciais somente por opt-in sobre a lista explícita. O teste HTTP in-process prova nonce CSP igual ao renderer, cookie CSRF Secure/SameSite, POST negado/aceito, preflight permitido e origin estrangeira sem grant. Ainda faltam browser E2E e proxy/TLS reais, além das camadas de sessão/auth/tenant que permanecem contrato da aplicação.
• [~] Ampliar DAST representativo para os artefatos que o CLI realmente entrega. O workflow manual agora compila em release e migra um REST API e o LMS completo recém-gerados; alertas WARN/FAIL bloqueiam e nenhuma regra é ignorada. O showcase do blog é separado e informativo porque sua CSP relaxada e assets externos são um limite deliberado e documentado. A execução local de 2026-09-01 encontrou e corrigiu exposição de diagnóstico SQL no status do blank/API e acrescentou Cache-Control: no-store somente quando o handler não definiu política própria. Depois das correções, REST cobriu 3 URLs com 65 regras em PASS, 5 INFO, 0 WARN e 0 FAIL; LMS cobriu 25 URLs com 63 regras em PASS, 7 INFO, 0 WARN e 0 FAIL. Falta repetir a execução hospedada no SHA congelado da RC; três superfícies não provam todos os blueprints, papéis autenticados, browsers, proxies ou deployments. A passagem informativa do blog encontrou formulários sem o campo CSRF: o middleware Core passou a expor o mesmo token validado aos handlers, o blog passou a renderizar e testar esse valor, e a nova varredura já não reportou o alerta 10202. Com a triagem registrada sem nenhuma regra IGNORE, essa superfície cobriu 28 URLs com 61 regras em PASS, 7 INFO, 2 WARN deliberadamente visíveis para dependências CDN sem SRI e 0 FAIL. A auditoria de scaffolds estendeu o mesmo contrato aos POSTs/HTMX dos blueprints Blank e ERP; LMS, SaaS e Nexus já possuíam integração equivalente, enquanto Studio conserva sua fronteira debug-only de loopback e mesma origem.

Autenticação e criptografia

• Concluir WebAuthn/passkeys com biblioteca auditada, casos normativos e conformance suite; a fundação atual não deve ser anunciada como conformidade completa.
• [~] Implementar política JWT de aplicação, rotação/revogação, TOTP com recovery codes e gerenciamento de sessões/dispositivos. rullst-auth/jwt agora fornece claims versionadas obrigatórias, issuer/audience, TTL/scopes limitados, chaves fortes com rotação por kid e contrato estático de revogação por token/versão de sessão; o modo de produção rejeita o store de memória local. A feature sqlite acrescenta revogação JTI/versão de sessão compartilhada entre processos locais, quota/configuração persistidas, verify_async e inventário/rename/revogação de passkeys com CAS de counter. Reinício, replay, concorrência entre duas instâncias e quotas possuem testes. rullst-security também gera recovery codes de 80 bits subject-bound, guarda apenas verificadores HMAC com salt e remove o verificador consumido. Ainda faltam refresh tokens, consumo transacional persistido de recovery codes, challenge WebAuthn compartilhado, replicação multi-host e conformance normativa.
• Integrar KMS/HSM e rotação de chaves apenas por adapters reais e testes de falha; simuladores permanecem claramente experimentais.
• Pesquisar PQC apenas para um protocolo e threat model concretos, usando primitivas auditadas; não criar criptografia própria.

Runtime, pagamentos, dados e SOC

• Ampliar WAF/RASP/DLP com parsers corretos, limites explícitos, falsos positivos medidos e testes de bypass; nunca prometer cobertura total OWASP.
• Tornar entrega SIEM externa observável e com retry/dead-letter antes de chamá-la de integração operacional. A fundação local agora tem contrato LiveSecurityEvent v1 congelado, um DurableSiemSpool compatível unsigned e um AuthenticatedSiemSpool single-process que encadeia HMAC, sequência, chave ativa/histórica, predecessor e payload sob quotas e sync_data. Restart, forgery, substituição/ausência de chave, reorder, remoção interna e mudança externa falham fechados. Checkpoint confiável contra whole-tail rollback, transporte, compaction, retenção, retry, confirmação e dead-letter continuam deliberadamente em aberto.
• [~] Levar a NFS-e Nacional até um contrato pronto para homologação em uma campanha fiscal dedicada. O marco local agora fixa por SHA-256 os pacotes oficiais de produção v1.01-20260209 e produção restrita v1.01-20260727, modela uma DPS ordinária delimitada sem float, valida CPF/CNPJ/IBGE/limites, carrega apenas fontes XSD oficiais verificadas por hash em catálogo fechado em memória e valida a DPS gerada. Depois do hash, o perfil de produção recebe uma única normalização explícita: remove os anchors .NET ^...$ do padrão conhecido de série, pois eles seriam literais na gramática regex XSD. O certificado PKCS#12 fica em containers redigidos e zeroizados quando pertencentes ao Rullst; o signer produz XMLDSig envelopada RSA-SHA256 com C14N inclusiva 1.0 sobre infDPS/@Id, passa verificação criptográfica local e o XML assinado passa o XSD oficial fornecido. A mesma credencial constrói identidade/cliente mTLS rustls limitado a HTTPS, sem redirects e com timeouts. O codec offline agora valida a XMLDSig incorporada da DPS, gera deterministicamente o objeto JSON dpsXmlGZipB64 e distingue autorização HTTP 201 de rejeições 400/403/500 com limites estritos. Uma autorização só emerge quando ambiente, DPS submetida, chave de 50 dígitos, infNFSe/@Id e XMLDSig incorporada concordam; JSON/XML/Base64/GZip malformado, campos desconhecidos, tamper e expansão acima de 4 MiB falham fechados. Ainda faltam vínculo certificado-emissor e cadeia ICP-Brasil completos, idempotência/auditoria duráveis, fixtures oficiais retidas, teste com A1 real na produção restrita e revisão independente. Homologation e Production continuam Unsupported e sem I/O até essas evidências; parâmetros do contribuinte/município são dependências externas e nunca podem ser simulados como autorização.
• Manter Alipay RSA2 em Unsupported até assinatura/verificação interoperável e contract tests oficiais.
• Testar isolamento multi-tenant, SQL parametrizado, migrations, backups e restauração contra bancos reais.
• Obter uma auditoria de segurança externa e publicar escopo, versão, achados corrigidos e limitações — não um selo absoluto.

AI segura e útil

• [~] Versionar evals de prompt injection, PII, jailbreak, tool selection, alucinação e regressão por provedor/modelo. O corpus rullst-ai-guardrails-v1 fixa casos determinísticos de injection, jailbreak e PII, é validado por schema/IDs/categorias e roda contra os seis transports offline no CI e na release. AdaptiveAiEvaluator<P> acrescenta estratégias multi-turn por dispatch estático, feedback bounded, deadline/cancelamento, estados pass/fail/inconclusive e relatório JSON sem prompt/response/error raw; o teste usa a saída de um turno para construir o seguinte. Corpora mantidos de tool selection, groundedness/alucinação e política de output, assim como execução/revisão contra cada modelo live exato, continuam responsabilidade operacional e não são alegados por um fixture offline.
• Criar uma matriz de capacidades por provedor para streaming, JSON/schema, vision, embeddings, tools, timeouts, retries e cancelamento. ProviderCapabilities, AiProvider::capabilities() e AiClient::capabilities() tornam o contrato verificável em código; testes fixam as seis implementações, as capacidades declaradas do adapter compatível e a restrição de schema por modelo no DeepSeek.
• Implementar streaming/cancelamento no primeiro protocolo delimitado: StreamingAiClient<P> mantém dispatch estático, guarda o input e impõe limites independentes de chunks/bytes; o adapter OpenAI-compatible só anuncia SSE após opt-in explícito, exige text/event-stream/[DONE] e disputa o sinal AiCancellation contra request e cada leitura. Testes loopback cobrem fragmentação LF/CRLF, content type, truncamento, overflow e cancelamento em voo. Protocolos diferentes e calls não-streaming continuam corretamente abertos, e cancelar localmente não prova cancelamento/billing upstream.
• Implementar export remoto autenticado de auditoria AI sem prometer um SIEM: AuditDeliveryClient limita o envelope JSON, assina seus bytes exatos com HMAC-SHA256/key ID/timestamp, preserva um event ID em retries transitórios delimitados, aceita apenas ACK fechado vinculado ao evento e disputa cancelamento contra request, response e espera. Cloud exige HTTPS; HTTP(S) local exige IP literal de loopback; credenciais vazias/mock_* são offline. O caller minimiza o evento e o receiver valida freshness/deduplicação e opera autorização, persistência, retenção e chaves; não há outbox/SIEM distribuído implícito.
• Exigir autorização explícita, schema, allowlist, limites e audit trail em chamadas de tools: ToolRegistry::execute agora requer política e contexto do principal, valida JSON fechado e limitado, consome budget e falha fechado sem audit sink. Operações destrutivas/financeiras exigem aprovação de uso único vinculada ao payload exato; identidade e auditoria durável continuam contratos da aplicação, documentados em Guarded Local AI Tools.
• [~] Bloquear SSRF e exfiltração em fetchers/RAG/conectores com egress policy, resolução segura e limites de conteúdo. EgressPolicy::strict() exige HTTPS, allowlist exata de host (vazia por padrão), porta permitida, host não local/metadata e resolução inteira para IPs públicos. EgressFetcher resolve sob deadline, fixa todas as respostas num client sem proxy/redirect automático, verifica o peer conectado, revalida cada redirect e limita tamanho declarado e chunks em streaming. Testes negam DNS privado/misto antes do transporte e cobrem formatos IPv4/IPv6, redirect privado, allowlist e overflow. O fetcher é opt-in; AiClient::prompt_with_image_url agora o exige explicitamente para imagens remotas e ainda valida assinatura/MIME, enquanto arquivos locais exigem raiz canônica allowlisted. Ele não envolve transports de provider, RAG ou clientes arbitrários; autorização tenant-aware do destino, decodificação segura e contrato live de sucesso/redirect continuam abertos.
• Separar filtros heurísticos de garantias: GuardrailReport agora expõe passed_heuristics, mantém is_safe somente como alias depreciado e a integração de IA declara que filtros, schema e similaridade não tornam prompt, resposta, tool ou decisão confiável por definição.

Supply chain

• Workflows usam actions pinadas por SHA e a release gera SBOM/evidência delimitada.
• Provar o pipeline completo de provenance e Trusted Publishing na RC.
• Definir SLA por severidade para advisories e política de exceções com owner, controle compensatório e expiração; dois ignores obsoletos foram removidos dos workflows junto com suas dependências.
• Manter fuzzing, Kani, Miri, sanitizers e mutation testing com alvos e resultados descritos precisamente; nenhum deles prova segurança universal. As matrizes agora distinguem diagnóstico rápido, achado informativo e falha de infraestrutura/baseline, mas ainda faltam os resultados do SHA final.

8. Experiência local: Nexus e Studio em um clique

A conveniência deve existir sem transformar uma configuração esquecida em uma porta administrativa de produção.

• Criar NexusAuthPolicy::local_development_or_basic_from_env(): desenvolvimento usa loopback verificado; release exige credenciais válidas do ambiente.
• Reutilizar LocalNexusAccess, que recusa peers não-loopback e requests sem ConnectInfo.
• Ligar o helper nos blueprints Blog, Portfolio, LMS, ERP e SaaS.
• Iniciar o Studio standalone em 127.0.0.1:5555 apenas em builds de debug geradas pelos blueprints; Studio::into_router exige agora a capability explícita LocalStudioAccess, recusa builds release e cada request sem peer loopback verificado por ConnectInfo. A capability também valida Host local, exige Origin de mesma origem nos métodos mutáveis e rejeita mutações sem Origin, cobrindo o limite local contra DNS rebinding e CSRF.
• Remover estados operacionais fabricados do Studio: AI sem transporte conectado fica indisponível; segurança não deduz guardas ativos ou alcance de provider por variáveis de ambiente; receita só exibe métricas fornecidas pela aplicação; filas propagam operação não suportada; e as ações HTTP legadas de migration/seed retornam 501 porque o servidor standalone não recebe um registry executável.
• Tornar purge_failed_jobs o nome canônico da operação da fila e fazer os defaults de listagem/retry/purge falharem com Unsupported, em vez de retornarem sucesso vazio. O alias legado purge_completed_jobs permanece depreciado apenas para compatibilidade de fonte.
• Fixar o asset CDN do Scalar, escapar a URL OpenAPI, tornar seu fallback status-only e recusar documento ausente/malformado com 503; corrigir build:client para falhar fechado quando o toolchain Wasm falta, mesclar cdylib via TOML estruturado, respeitar lib.name, localizar apenas um artefato real e gerar um hidratador separado que aguarda a inicialização do wasm-bindgen.
• Exibir botões claros para Studio local e Nexus nos dashboards aplicáveis.
• Atualizar examples/blog: Studio standalone local, Nexus de um clique em debug e sem credenciais fictícias obrigatórias no setup. A auditoria do showcase também adicionou CPU real do processo no Windows, atualização dos KPIs por /api/radar, corrigiu a dupla contagem de prompts e removeu selos HMAC positivos quando a fonte contém somente eventos locais não assinados. Os seis botões do sandbox de segurança e o /wp-admin agora têm regressão que prova a execução das primitivas locais instrumentadas; a interface deixou de transformar uma detecção em falso 403, chamada de provider, garantia universal de timing ou nota de scanner.
• Remover da interface do Studio a sugestão incorreta de que STUDIO_PASSWORD já fornecia autenticação embutida.
• Remover os aliases legados /tools/*; todas as páginas do Studio usam as rotas limpas /studio/* exigidas pela especificação.
• Acrescentar ingestão distribuída sem abrir o painel remotamente: cada produtor recebe um router push-only separado, vinculado ao seu nome e chave, que aceita lotes v1 sem atributos sob 128 KiB/128 spans, autentica corpo/source/timestamp/nonce por HMAC-SHA256, rejeita replay atomicamente e alimenta um store in-process limitado e idempotente. O viewer local sinaliza operações SQL de 100 ms e três labels repetidos por trace como heurísticas, sem receber SQL, bindings, headers, bodies ou erros. TLS, rotação da chave, relógio, autorização do produtor e durabilidade continuam responsabilidades da aplicação/operação.
• Concluir o inspetor de cache no limite seguro: Core fornece snapshots metadata-only de no máximo 200 entradas para Memory/Redis, com contrato Redis live pinado; Studio exibe no máximo 100 fingerprints HMAC process-local, tamanho e TTL, nunca valor ou chave lógica, e permite somente invalidação individual atrás da marker local verificada. flush all não é exposto e drivers custom falham explicitamente sem opt-in.
• Padronizar novos .env, Kubernetes e Foundry em RULLST_ENV, corrigir a precedência do template de billing e manter APP_ENV apenas como alias legado testado para aplicações existentes.
• Tornar o Foundry fail-closed nas etapas de build, provisionamento, upload, configuração e health check: TOML e identificadores são validados, segredos seguem por stdin, curl, systemd e Caddy precisam estar previamente instalados, a configuração candidata é validada e os arquivos da aplicação ficam isolados em /opt/rullst/<app>. O sucesso local não é apresentado como prova de DNS/TLS público. A versão atual substitui o Caddyfile global e ainda exige root ou sudo não interativo; não promete migrations, checksum remoto, rollback automático nem zero downtime.
• Rodar a matriz estrutural das 18 formas públicas da v12, materializar os seis blueprints públicos em diretórios temporários e compilar os projetos representativos SaaS e Blank/hot. A antiga matriz de 270 variantes permanece apenas como evidência histórica da fase anterior à simplificação.
• [~] [!] Os gates lentos materializam dez casos que cobrem os seis blueprints, Active Record, SSR html!/HTMX, API, banco e hot reload. Seis executam cargo check --offline --all-targets; o LMS executa cargo test --offline --all-targets, inclusive o negativo owner/cross-user embutido no scaffold, e os perfis LMS separados auth, auth,learning e auth,learning,assessment também passam seus testes gerados. O último prova apresentação sem gabarito, owner boundary, correção autoritativa, replay, conflito de idempotência e limite de tentativas em SQLite, sem materializar gamificação, automação, outbox ou notificações. O middleware JWT injetado usa a mesma major 11 do workspace, permitindo a resolução offline num runner limpo; relatórios de upgrade e chaves de storage também preservam / canônico no Windows. Todos passaram localmente em 2026-08-29, mas ainda falta CI verde no SHA final da RC.
• [~] Um dos dez projetos gerados passa cargo check --release; testes release focados provam que Nexus nunca escolhe a política sem credenciais e que Studio recusa sua capability local. O job generated-release-access está configurado; falta a evidência de CI no SHA final e um E2E do processo gerado sem variáveis.
• Criar E2E de navegador para os dois botões e para a rejeição de peer externo.
• Medir tempo até a primeira página, primeiro CRUD e primeiro diagnóstico de erro com usuários novos.

9. Correção responsável do changelog

O changelog é registro histórico; apagar silenciosamente alegações extraordinárias seria tão ruim quanto mantê-las como fatos atuais. A correção adotada é preservar a alegação original e acrescentar imediatamente o escopo auditado:

- **Alegação original de desenvolvimento:** descrição histórica.
  - **Escopo auditado na v12:** o que o código e os testes realmente sustentam.
  - **Ambição restante:** o que falta e se vale implementar.
  - **Evidência:** teste, workflow, issue ou documento vinculado à versão/commit.

• Adicionar no topo de v12 um aviso de que o inventário não é certificação nem evidência congelada de testes.
• Corrigir ao lado, sem apagar, as alegações de latência zero, Alipay RSA2, Kani universal e imunidade a DoS por fuzzing.
• Todas as afirmações históricas de 100% test pass rate agora trazem ao lado que são alegações de execução histórica cujo commit/artefato exato não foi retido nessa entrada; não são tratadas como cobertura nem prova da RC.
• [~] As entradas atuais de SECURITY.md, headers, DLP, RASP, compliance, Kani, SLSA e inventário TLS foram delimitadas sem apagar os controles; ainda falta concluir a mesma revisão de linguagem absoluta em toda a documentação histórica.
• [~] As páginas canônicas de Capital e IoT agora distinguem adapters/helpers implementados, mocks offline, homologação e hardware/boot/transporte pendentes. A auditoria item a item de SIEM, OpenAPI/SDK, deploy, replicação e de cada método/fee/provedor continua aberta.
• Manter correções também nas seções de versões já lançadas; o cabeçalho de v12 não deve reescrever silenciosamente a história.
• Ligar cada claim de segurança de v12 a código, teste e limite conhecido no ledger canônico de alegações e evidências; o documento também declara que uma afirmação ausente não é garantia da release.

9.1. Preservação da documentação original

• Identificar por histórico Git o snapshot imediatamente anterior à criação de gpt.md: 96222fbd31bec3d20bc50db68c41bb85ca595779.
• Criar um índice de preservação com o snapshot exato, as famílias de ambições recuperadas, estado atual, opinião e destino canônico.
• Manter as ideias nos roadmaps e manter spec/tutoriais copiáveis limitados ao comportamento atual.
• Excluir tutoriais antigos da reconstrução por decisão do mantenedor; eles permanecem apenas em sua versão atual e segura.
• Classificar individualmente as 190 alegações históricas deduplicadas dos roadmaps; os quadros auditados abaixo prevalecem sobre [x] antigos e medem classificação, não implementação integral.
• Revisar toda remoção futura de conteúdo contra o snapshot e registrar no índice quando houver valor de visão ou de decisão.

10. Prova operacional

• Publicar a RC e criar uma aplicação de referência que dependa apenas de crates.io.
• Operar deploy, migration, backup, restore, rotação de segredo e rollback num ambiente semelhante à produção.
• Executar testes de carga reproduzíveis e publicar hardware, configuração, dataset, percentis e limites; evitar “o mais rápido” sem comparação válida.
• Ter usuários externos construindo aplicações sem acesso ao monorepo e registrar problemas de onboarding.
• Ter ao menos um ciclo de RC com correções observadas em uso real.
• Definir manutenção, triagem de vulnerabilidades, resposta a incidentes e suporte para a linha v12.

11. Gates para 12.0.0 estável

A versão estável só recebe GO quando todos estes itens estiverem fechados:

• [!] Trifecta local e CI multi-OS verdes no mesmo SHA.
• [!] Pacotes e aplicação crates-only reproduzidos.
• [!] Sem advisory crítico/alto sem exceção governada e sem segredo no pacote.
• [!] Baseline de produção e threat models revisados.
• [!] ZAP hospedado verde no SHA da RC para REST API e LMS gerados, com os relatórios do showcase informativo revisados e sem transformar achados reais em exclusões.
• [!] Scorecard no SHA da RC com A (90) ou mais em todas as crates, salvo a exceção aprovada de B (80) ou mais para rullst-iot. A+ só pode ser publicado quando a evidência objetiva alcançar 97. No estado atual, Core tem 96/A, ORM tem 96/A, ORM Macros, Auth, Mail e Nexus têm 95/A, Macros tem 94/A, Messaging e Security têm 96/A, Connect e AI têm 95/A, a facade rullst tem 90/A, e IoT tem 83/B. Capital alcançou seu teto local de 93/A com o ledger relacional de webhook, o contrato compartilhado de egress/falhas dos gateways e o journal fiscal local autenticado. cargo-rullst alcançou seu teto local de 95/A com a matriz estrutural pública, oito aplicações geradas executando testes e construindo os routers hot selecionados, perfis pelo binário público e fixtures transacionais de upgrade v5/v6/v11 com rollback, retenção/restauração e rejeição de symlink. Studio alcançou seu teto local de 94/A com ingestão de traces push-only autenticada/replay-bound, profiler de labels limitado, inspeção metadata-only de cache Memory/Redis e invalidação individual opaca. ORM alcançou seu teto local de 96/A com snapshots documentais autenticados e limitados, verificação fail-closed de inventário e ensaio live bidirecional MongoDB → SurrealDB → MongoDB, sem prometer snapshot online, PITR ou operação gerenciada. Security alcançou seu teto local de 96/A com journal SIEM local opcional HMAC-chained, rotação explícita por chave ativa/histórica e negativos exatos de forgery, substituição de chave, reorder, remoção interna e restart, sem prometer checkpoint externo, entrega/ack remotos, SOC ou certificação. Assim, todos os pisos atuais estão atendidos. Esses valores são tetos atuais, não metas finais: a campanha v12 pretende alcançar os tetos locais provisionais documentados no scorecard (93–96/A nas 15 crates ativas); IoT permanece na exceção aceita de 83/B, sem fabricar os pontos que dependem de hardware, homologação, operação live ou auditoria externa. O gate permanece aberto até haver implementação real e o artefato do SHA candidato comprovar todos os gates condicionantes.
• [!] Na estável, line coverage das bibliotecas do framework ≥90%, patch coverage ≥90%, componentes Auth e Security ≥90%, cobertura total do código de produção publicada sem omissões, nenhum caminho crítico com 0% e baseline de branches publicada. 95% permanece meta de excelência, não gate artificial.
• [!] Changelog, spec, capability ledger, README e exemplos concordam sobre o que existe e o que não existe.
• [!] Concluir a auditoria documental da RC: o mdbook build já passa e o scan Lychee repository-wide verificou 1.228 referências, 695 únicas, com 769 válidas, 459 exclusões offline intencionais e zero erro em 2026-09-01. O workflow documentation.yml torna o build e os links/anchors locais bloqueantes, mantendo o scan externo periódico/manual como evidência informativa. Os 52 tutoriais contêm exatamente 106 exemplos Rust: o harness Cargo-aware compilou/executou 88 e os 18 ignore restantes declaram a dependência contextual (módulo/arquivo gerado, adapter da aplicação ou dependência circular), sem serem contados como exemplos compilados. O livro completo contém 203 exemplos reconhecidos pelo rustdoc — incluindo três blocos indentados no spec.md que a contagem anterior de fences omitia — e o mesmo gate compilou/executou 177, classificou 26 como contextuais e terminou sem falhas. No recorte fora dos tutoriais, são 97 exemplos: 89 verificados e oito contextuais. Repetir a evidência no SHA congelado e validar também comandos, versões, caminhos e toda alegação semântica contra spec.md e as APIs reais.
• [!] RC operada por tempo suficiente e sem bloqueadores conhecidos.
• [!] Plano de publicação parcial, rollback operacional e resposta a incidentes ensaiados.
• [!] Aprovação humana final registrada.

12. Rullst Academy: fronteira externa futura

O plano do produto separado está em Rullst Academy product programme. Esta seção preserva o inventário de capacidades reutilizáveis do framework; não transforma conteúdo, sandbox, operação ou UX da aplicação em escopo implícito da crate rullst.

O objetivo vertical de longo prazo é permitir que uma equipe pequena construa um LMS excelente, divertido e seguro sem remontar autenticação, progresso, ranking, automações e operação a partir de primitivas desconectadas. Este inventário não amplia a v12 nem cria trabalho de Academy neste repositório: o produto será desenvolvido em outro repositório e outra conversa. Nenhum item desta seção bloqueia a RC ou a estável; quando o projeto externo existir, seu link poderá ser acrescentado à documentação do framework.

Os estados abaixo são um registro arquivado do que já existe e do que caberá ao futuro produto externo. Caixas abertas nesta seção não são tarefas do workspace, não entram no percentual de prontidão da v12 e não devem ser implementadas aqui.

“Superar Laravel” significa vencer uma aplicação de referência equivalente em tempo até o primeiro fluxo seguro, clareza de código, consumo de recursos, falhas fechadas, cobertura adversarial e facilidade de operação. Não significa declarar superioridade universal nem comparar benchmarks, hardware ou escopos diferentes. Recursos verticais devem permanecer em módulos opcionais ou numa aplicação de referência; somente abstrações comprovadamente reutilizáveis devem entrar no Core.

Produto de referência e fronteira arquitetural

• [~] O blueprint LMS gera as fundações de currículo, identidade, matrícula, progresso, avaliação, atividade, conquista, leaderboard e automação, além de catálogo público, cadastro/login, matrícula idempotente, entitlement de aula, progresso monotônico com histórico/correção auditada, player protegido com variantes de vídeo/áudio, legenda WebVTT obrigatória no vídeo, transcrição e idioma delimitados, e administração Nexus. O projeto materializado passa cargo test --offline --all-targets, inclusive owner/cross-user. O starter agora possui uma fronteira escolar persistida e testada nas mutações críticas, ainda deliberadamente incompleta nos demais subsistemas; os arquivos WebVTT de demonstração são locais, mas a mídia seed continua remota apenas para desenvolvimento e exige política CSP explícita. O quiz single-choice já é avaliado no servidor, inclusive com início/expiração e ordem aleatória persistidos quando temporizado. O worker possui loop supervisionado, shutdown explícito e métricas locais; conclusão é derivada do snapshot fixado e emite certificado público revogável; tarefas textuais e rubricas persistidas já têm submissão/feedback autenticados e limites do servidor. Jogos, canais externos, billing, UI de autoria e tenancy transversal não são fluxos completos.
• Manter a aplicação oficial Rullst Academy em repositório separado, dependente somente dos pacotes publicados e sem paths do monorepo, e operá-la como consumidor real durante a RC/estável. O checkout, os artefatos e a matriz E2E da Academy não pertencem ao workspace nem aos pacotes do framework; o monorepo conserva apenas contratos reutilizáveis, scaffolds pequenos e testes de compatibilidade proporcionais.
• [~] Manter o blueprint LMS pequeno e rápido, permitindo selecionar módulos opcionais (auth, learning, assessment, gamification, automation, realtime, billing) em vez de incorporar um produto monolítico ao Core. O CLI aceita agora --lms-modules auth, --lms-modules auth,learning ou --lms-modules auth,learning,assessment com o blueprint LMS. O primeiro gera uma fronteira de identidade com menos de 15 arquivos — usuário, sessão, login/registro, CSRF/headers, middleware e Nexus — sem modelos de curso/matrícula. O segundo gera um perfil foundation real com menos de 30 arquivos: autenticação, catálogo, matrícula, player protegido e progresso monotônico/idempotente, sem arquivos de quiz, conquista, automação ou notificação. O terceiro fica abaixo de 40 arquivos e acrescenta somente quiz, questão, opção, tentativa/resposta, endpoints owner-only e correção transacional autoritativa com regras versionadas, chave idempotente e teto de tentativas; ele não inclui score, leaderboard, conquista, outbox, automação ou notificação. Cada seleção fica registrada em rullst-lms-modules.json e os três projetos materializados passam cargo test --offline --all-targets. O starter completo continua sendo o default. Gamification, automation, realtime e billing ainda não estão desacoplados em combinações independentes; combinações não suportadas e hot reload desses perfis falham explicitamente em vez de incluir módulos silenciosamente.
• [~] Versionar uma jornada de aceitação completa: professor publica, aluno se registra e matricula, autorização protege conteúdo, progresso é salvo, uma avaliação gera pontuação idempotente, ranking muda, conquista dispara automação e notificação, e o administrador audita o fluxo. O teste SQLite materializado já cobre publicação versionada e pin de matrícula, além do slice score → leaderboard → outbox → claim → regra rederivada → conquista transacional → redelivery idempotente → ACK, poison retry/dead-letter e correção administrativa. O mesmo teste cobre avaliação autoritativa e sua projeção transacional em ScoreEvent, leaderboard e outbox, conquista e notificação in-app entregue. O mesmo fluxo deriva conclusão apenas depois dos requisitos da versão fixada, emite certificado opaco sem PII pública, prova replay e entrega os envelopes de conclusão/revogação pelo worker. Uma continuação cobre tarefa textual → submissão owner-only → avaliação humana limitada pela rubrica persistida → feedback/notas por critério → outbox, com prazo, replay, adulteração de pontos e fronteira HTTP. A autoria agora possui handlers autenticados para draft, envio a revisão, revisão/agendamento e rollback administrativo auditado, sempre usando ator e relógio do servidor. O rollback publica uma nova revisão a partir de um snapshot histórico sem mover matrículas existentes. Registro, autoria visual no Nexus e player/quiz no navegador ainda não formam uma única jornada E2E.
• Publicar, fora do monorepo do framework, uma implementação Laravel de referência com o mesmo domínio, dataset, frontend, banco, cache, hardware e testes para comparar DX, latência, throughput, memória, segurança e operação sem cherry-picking. Nenhuma das duas aplicações de benchmark integra o pacote ou o gate cotidiano da RC.

Domínio de aprendizagem e autoria

• [~] Modelar organização/escola, tenant, usuário, instrutor, aluno, curso, módulo, aula, turma/coorte, matrícula e entitlement com migrations reversíveis, constraints e políticas de ownership explícitas. O starter agora gera School, membership com janela/default, vínculo único curso→escola, coorte, membership de coorte e entitlement temporal, com índices de unicidade/consulta e down migration. O middleware resolve X-School-ID somente como seletor contra memberships persistidas, vincula o tenant ao UserContext e falha fechado em membership ausente/ambígua; papéis são persistidos e consultados por escola. Curso aberto ou entitlement ativo controla matrícula. Ainda faltam provisionamento/invites, políticas de responsável, constraints FK portáveis, ciclo de entitlement pago e a aplicação Academy separada.
• [~] Implementar progresso transacional e idempotente por aula/atividade, com retomada, percentual, histórico, correções administrativas auditadas e concorrência testada. O starter usa chave explícita de idempotência, upsert monotônico por banco, histórico append-only, correção exclusiva de admin e evento lesson_completed no mesmo commit. O teste materializado cobre replay, regressão ignorada, conclusão e correção; faltam atividade além de aula e contenção contra os três bancos reais.
• [~] Implementar pré-requisitos, liberação gradual, datas, expiração, certificados verificáveis e conclusão derivada de regras versionadas. O starter agora exige exatamente uma política ativa versionada por aula, aplica liberação/expiração pelo relógio do servidor e valida progresso do pré-requisito no mesmo curso. Política ausente, duplicada, inconsistente ou cross-course falha fechada; o teste materializado cobre bloqueio, liberação, janela e conflito. Versões publicadas são snapshots imutáveis e matrículas criadas pelo serviço fixam a versão corrente. A conclusão agora lê uma regra v1 fechada do snapshot fixado, exige todo progresso persistido e grava evidência/certificado/outbox atomicamente; replay reutiliza o mesmo certificado. Verificação por chave opaca não expõe o aluno, e revogação exige admin, motivo, relógio do servidor e chave idempotente. O teste cobre incompletude, cross-user, replay, verificação, revogação conflitante e entrega. Ainda faltam servir todo conteúdo pelo snapshot, regras mais ricas e contenção nos três bancos reais.
• [~] Implementar questionários, banco de questões, tentativas, limites de tempo, embaralhamento, rubricas, tarefas, submissões e feedback sem confiar em resultados calculados apenas no navegador. O starter persiste quiz, questões, opções, tentativas e respostas; autoriza o aluno matriculado, calcula a nota pela chave do servidor, limita tentativas, vincula replay a quiz/aluno/ruleset e grava tentativa, respostas, ScoreEvent, atualização do leaderboard, score_recorded e quiz_graded no mesmo commit. O teste rejeita cross-user e opção inexistente e comprova as contagens/replay da projeção. Quizzes temporizados exigem início persistido no relógio do servidor; replay não estende o prazo, tentativa iniciada consome o limite, e submissão ausente ou expirada falha fechada. O início temporizado persiste uma ordem de questões/opções derivada de seed aleatório do servidor e vinculada ao ruleset; replay devolve a mesma ordem e alteração silenciosa de IDs falha no grading. Rotas autenticadas de início e submissão derivam quiz/aluno da path/sessão e nunca aceitam pontos do cliente. O starter também persiste tarefas, critérios de rubrica, submissões, avaliações e notas por critério. A submissão exige o owner matriculado, prazo/tentativas do servidor e chave idempotente; a avaliação exige evaluator/instructor/admin distinto do aluno, cobre exatamente os critérios persistidos, rejeita pontos acima do máximo, guarda feedback e vincula replay ao request canônico. Submissão e avaliação emitem outbox na mesma transação. Correções administrativas são append-only: preservam a nota original, revalidam a mesma rubrica, registram before/after, motivo, ator, relógio, request canônico e outbox, e effective_grade retorna a correção mais recente. O teste materializado cobre prazo, cross-user, replay/conflito, nota impossível, negação de evaluator na correção, HTTP e evidência rubricada. Ainda faltam anexos, autoria visual, UI e contenção multi-banco.
• [~] Implementar rascunho, revisão, publicação, agendamento e versionamento de conteúdo sem alterar silenciosamente a experiência de alunos já matriculados. O starter fornece snapshots CourseVersion append-only, transições draft → review → scheduled/published, revisor admin distinto do autor, arquivamento atômico da versão anterior, course_published transacional e pin imutável da versão na matrícula. O teste prova pin antes/depois da publicação e entrega FIFO dos eventos. Handlers autenticados expõem draft, submissão e revisão/agendamento, derivando ator e relógio no servidor, e o teste materializado percorre essa fronteira até published. Um loop supervisionado agora ativa versões vencidas em lotes limitados sob lease compartilhada, renova/libera o token exato, preserva o revisor independente, emite o ator da ativação e expõe shutdown e contadores locais. O teste SQLite prova espera sob contenção, ativação no relógio do servidor e replay sem nova publicação. Rollback administrativo exige motivo e chave idempotente, cria uma nova revisão imutável a partir de uma versão histórica, arquiva a versão corrente e grava auditoria/outbox na mesma transação. Replay exato não duplica; pins já existentes permanecem na versão anterior e novas matrículas recebem a revisão restaurada. O teste cobre negação de instrutor, conflito de chave, fronteira HTTP e evidência durável. Ainda faltam autoria visual no Nexus, snapshot relacional completo de módulos/aulas/avaliações, métricas exportadas/alertas e contenção nos bancos reais.
• [~] Entregar busca, filtros, navegação por teclado, contraste, legendas, transcrições, localização e critérios WCAG testados na aplicação de referência. Os perfis LMS completo, auth,learning e auth,learning,assessment agora geram catálogo SSR com busca de título e categoria parametrizadas pelo ORM, entrada limitada, ordenação e limite de resultados. O shell remove fontes/scripts/imagens externas, consome o CspNonce da baseline, não usa estilos inline ou HTMX remoto e inclui skip link, landmarks, foco visível, layout responsivo, contraste explícito e redução de movimento; aula e autenticação também recebem o nonce, e o player não inicia mídia automaticamente. O modelo de aula distingue vídeo/áudio; o renderer aceita somente HTTPS ou path absoluto same-origin, exige track WebVTT em vídeos e uma transcrição delimitada para ambos. A regressão materializada cobre filtro, valor com formato de SQL injection, limite, escaping de HTML, identidade do nonce, vídeo/áudio e rejeição de source, idioma, legenda ou transcrição inválidos. Ainda faltam busca textual avançada, localização do catálogo, revisão humana da qualidade de legendas/transcrições, testes automatizados WCAG/browser/teclado e a aplicação de referência externa operada com usuários reais.
• [~] Implementar mídia remota real com S3/R2, uploads multipart limitados, allowlist de tipos, URLs assinadas, CDN e processamento assíncrono. Core agora fornece o contrato reutilizável de admissão/quarentena com limite rígido, allowlist, assinatura real versus MIME/extensão, chave aleatória por tenant, digest SHA-256 e liberação somente após verdict limpo. Ainda não existem streaming multipart, driver S3/R2, URL assinada, CDN, transcode ou pipeline assíncrono; o storage local continua apropriado apenas para desenvolvimento e instalações simples.

Jogos, gamificação e ranking confiável

• [~] Definir um contrato de atividades/jogos com estado, versão, tentativa, regras, resultado e evidência de conclusão; começar por quizzes e minigames assíncronos antes de prometer multiplayer de baixa latência. O scaffold gera ActivityAttempt/ActivityResult v1 para quiz, exercício e jogo, vinculando owner, activity, attempt, ruleset, ordem temporal, estado limitado, score e digest SHA-256 de evidência. evaluate_activity usa dispatch estático e não recebe pontos do cliente: um ActivityEvaluator confiável transforma apenas a submissão em outcome e o contrato constrói o resultado. O primeiro SingleChoiceEvaluator cobre exercício correto/incorreto; o MatchingEvaluator exige uma permutação completa de até oito pares, normaliza sua ordem e calcula pontuação parcial a partir do mapa do servidor; e o TypedAnswerEvaluator compara um conjunto fechado após trim/lowercase Unicode opcional, limita a entrada a 512 bytes sem controles e persiste somente um digest SHA-256 ligado à política. Ele não promete NFC, tolerância de acento ou fuzzy matching. A regressão materializada prova owner, kind, JSON, relógio, limites e rejeições. No starter completo, record_activity_result aceita somente o resultado validado opaco, rederiva curso, kind, máximo, ruleset, temporada e digest da atividade persistida e grava ScoreEvent v2, leaderboard e score_recorded na mesma transação. A mesma transação agora conserva a tentativa/resultados delimitados e exige replay exato, revalidando sob lock a configuração exata usada pelo avaliador. POST /activities/{id}/attempts aceita apenas chave idempotente/opção e POST /activities/{id}/attempts/matching apenas a chave e IDs dos pares; ambos se somam a /activities/{id}/attempts/typed, que recebe texto delimitado sem retê-lo em claro. Todos derivam aluno/activity do contexto/path e mantêm respostas, pontos, ruleset, digest e relógio no servidor. A regressão rejeita ator, digest, IDs duplicados ou retry divergente e prova owner/cross-user no boundary HTTP. O estado retido continua sujeito à política de privacidade da aplicação. O avaliador de quiz persistido permanece separado; ainda faltam listening e jogos.
• Tornar explícita a fronteira do cliente para jogos: o scaffold gera ActivityClientManifest, cujo default ssr_htmx não aceita bundle e cujo opt-in canvas_wasm exige paths same-origin, artefato .wasm, SHA-256 canônico e tamanho máximo de 16 MiB. Ambos continuam subordinados à validação autoritativa do resultado no servidor; nenhum bundle pesado é dependência do LMS padrão.
• [~] Criar ScoreEvent autenticado, versionado e idempotente, com origem, tentativa, regra, pontos, timestamp e chave de deduplicação. O scaffold deriva o ator de UserContext, autoriza owner/admin, valida schema, origem, IDs, chaves e limites server-side, grava o evento append-only e atualiza a fonte de verdade do leaderboard na mesma transação. O avaliador autoritativo de quiz agora cria um ScoreEvent v2 por tentativa e a mesma projeção transacional, sem aceitar pontos do cliente. O exercício single-choice também chega a essa projeção somente por um ValidatedActivityResult não construível pelo chamador; a ponte revalida a política persistida e vincula o digest canônico. Índices únicos tornam replay exato de evento/tentativa no-op e um retry com outra opção/pareamento falha fechado. Os endpoints autoritativos de quiz, single-choice, matching e typed answer já existem; ainda faltam endpoint/recomputadores para jogo/listening e testes de concorrência contra os três bancos reais.
• [~] Fornecer revisão espaçada durável sem transformar heurística em alegação pedagógica. Atividades podem habilitar a política versionada rullst-box-v1: na entrada de um score autoritativo novo, a mesma transação trava e valida política/estado, calcula uma transição determinística de aprovação ou lapso e grava o próximo vencimento. Replay exato retorna antes da transição e não avança a agenda. GET /reviews/due deriva usuário e tempo no servidor, limita a fila a 50 e revalida escola, escopo do curso e matrícula ativa. A regressão SQLite materializada cobre single-choice, matching, typed, persistência, ordenação futura, replay e cross-user. Ainda faltam UX visual, migração/experimentação de algoritmos, integração completa ao ciclo de privacidade, listening/speech e contenção PostgreSQL/MySQL; não alegamos compatibilidade FSRS/SM-2, eficácia ou personalização por IA.
• [~] Implementar leaderboard com fonte de verdade no banco, temporadas, escopos, desempate determinístico, correção auditada e cache Redis opcional reconstruível. O scaffold atualiza a tabela autoritativa somente quando um ScoreEvent novo entra na transação e consulta curso/temporada com limite 100 e ordem total score DESC, updated_at ASC, user_id ASC. Uma projeção local reconstruível usa TenantCache, valida o escopo do payload e é invalidada depois de score, quiz e correção; o banco continua autoritativo. Correções exigem admin, motivo e ruleset, têm chave idempotente e gravam ator/before/after na mesma transação. Mutações de score/correção e a leitura do ranking validam o school scope autenticado, com negação materializada para escola estrangeira; ainda faltam Redis distribuído/failover e testes nos bancos reais.
• [~] Implementar XP, níveis, badges, conquistas, streaks, desafios e recompensas por regras versionadas, evitando incentivos manipuláveis ou inacessíveis. O starter agora aplica award_achievement a partir de uma regra v1 e de um outbox claimado, com unicidade learner/achievement, ator/evento registrados e execução idempotente na mesma transação. XP acumulado, níveis, streaks, desafios, recompensas, acessibilidade e políticas antifarming continuam abertos.
• [~] Criar testes de replay, concorrência, adulteração, relógio, pontuação impossível, automação duplicada e abuso de múltiplas contas antes de anunciar ranking competitivo ou premiação. As regressões geradas já cobrem replay de score/correção/outbox, owner cross-user, schema futuro, pontuação impossível, chaves idempotentes, perda de ACK/redelivery sem conquista duplicada e poison-event dead-letter. Ainda faltam contenção real nos três bancos, relógio adversarial e cenários de farming/múltiplas contas.
• Tratar multiplayer em tempo real como capability separada: autenticação de canal, servidor autoritativo, presença distribuída, reconexão, ordenação, backpressure e testes de carga são obrigatórios antes de suporte público.

Automações, eventos e notificações

• [~] Core já possui scheduler e filas SQLite/Redis com leases, retry e dead-letter, e Mail oferece entrega em background. Falta uni-los numa jornada de domínio LMS com semântica operacional documentada; o starter fornece iteração DB claim→plan→execute→ACK/fail e um loop supervisionado com shutdown, métricas locais e entrega in-app com projeção realtime local tenant-scoped. A publicação agendada também possui loop supervisionado próprio, com lote limitado e liderança por lease exata. Integração com Mail/push, realtime distribuído e telemetria operacional permanece aberta.
• [~] Criar eventos de domínio e transactional outbox para que conclusão, pontuação, conquista, matrícula e publicação não sejam perdidas entre o commit do banco e a fila; handlers devem assumir entrega ao menos uma vez. A gravação de ScoreEvent agora inclui um score_recorded v2 estrito no academy_outbox dentro da mesma transação; chave única impede duplicação no replay, seu digest liga a evidência à política persistida e Nexus expõe o estado somente leitura. Progresso concluído também grava lesson_completed transacionalmente. O serviço gerado usa lease limitado, vincula ACK/falha à claim exata, agenda backoff limitado, recupera claim expirada, rejeita token obsoleto, incrementa tentativas e move para dead_letter no limite; o teste SQLite materializado cobre esses estados. Matrícula, conquista, publicação, rollback editorial, submissão/avaliação/correção de tarefa, conclusão e revogação de certificado também emitem eventos no mesmo commit, e o worker valida/entrega esses envelopes versionados, inclusive lesson_completed. Cada evento carrega school_id; eventos derivados, regras, execuções e conquistas preservam o escopo, e uma regra fixture de outra escola não reage ao evento. Faltam transporte externo, eventos de alterações editoriais intermediárias e telemetria durável.
• [~] Criar regras de automação trigger/condition/action com schema, versão, dry-run, limites, idempotência, autorização, audit trail e aprovação humana para ações destrutivas ou financeiras. O starter agora transforma o outbox score_recorded v2 e regras v1 estritas em planos puros, ordenados e com execution_key determinística, aceitando somente award_achievement e falhando em campos, versões, scores ou ações desconhecidas. Um threshold global válido acima do máximo de uma atividade agora produz zero ações, sem envenenar o evento. O executor exige a claim exata, busca somente regras da escola do evento, rederiva o plano atual e grava execução/conquista no mesmo school_id; redelivery vira no-op. Ainda faltam transporte, backoff/reaper de claims, auditoria externa e envelopes de autorização/aprovação para novas ações. Lease, backoff e recuperação de claim abandonada pertencem ao outbox. O loop supervisionado usa configuração validada, tokens de claim únicos, shutdown aguardável, aborto seguro no drop e contadores locais; ainda faltam exportação de métricas/alertas, transporte e prova de contenção multi-instância nos três bancos.
• [~] Unificar notificações in-app/database, realtime, e-mail e push sob um contrato por usuário/tenant, com preferências, localização, opt-out, retry e estado de leitura. O starter emite achievement_awarded no mesmo commit da conquista e o worker cria uma notificação in-app idempotente a partir da claim exata, com chave de localização, locale/preferência, estado unread/suppressed/read e leitura owner/admin. Rotas autenticadas oferecem listagem filtrada/paginada, leitura idempotente e preferência/locale/opt-out, sempre derivando o sujeito da sessão. Tabelas, consultas e preferências levam school_id; o teste materializado prova que o mesmo usuário em duas escolas não observa a notificação alheia e mantém preferências independentes. Uma assinatura autenticada usa TenantRealtime; após o commit de uma notificação nova e não suprimida, o processo publica um envelope limitado na sala do tenant/usuário, e a jornada materializada valida o recebimento. O banco continua fonte de verdade; o broadcast é uma projeção best-effort local. O evento de conquista usa um catálogo fechado/versionado com renderização em português, espanhol e inglês, fallback determinístico para inglês e texto projetado tanto na listagem quanto no realtime; payload ou chave desconhecida falha explicitamente. Ainda faltam catálogos para os demais eventos, transporte realtime distribuído/replay, Mail, push e operação.
• [~] Impedir execução duplicada do scheduler em múltiplas instâncias por lock distribuído/lease, e expor atraso, falha, retry e dead-letter no Studio. O starter agora fornece lease compartilhada no banco com chave/holder/token, expiração, renovação e liberação compare-and-set; o teste bloqueia concorrente, rejeita token obsoleto e permite takeover somente após expirar. O snapshot é consultável/Nexus readonly. O scheduler de publicação usa essa lease em cada ciclo, renova antes de toda mutação, falha fechado se perder liderança, limita lote e oferece shutdown aguardável, abort seguro e contadores locais; o teste materializado prova standby sob contenção, ativação única e replay vazio. Ainda faltam Studio, métricas/alertas exportados e contenção PostgreSQL/MySQL.

Segurança nativa específica para educação e jogos

• [~] Rullst já oferece sessões criptografadas, RBAC/ownership, CSRF, headers, WAF/RASP/DLP, Login Jail, guardas de AI e telemetria versionada. Isso é uma fundação de defesa em profundidade, não prova a segurança do domínio LMS.
• Criar threat model versionado para aluno, professor, moderador, escola, conteúdo, avaliação, ranking, automação, pagamento e administração: o TM-ACADEMY-1 em TM-12.10 registra 12 abuse cases, evidência atual, mínimos negativos e riscos residuais sem promover fundações a garantias de produto.
• [~] Exigir entitlement e ownership em toda rota de curso, aula, tentativa, progresso, submissão, certificado e mídia. O starter protege matrícula, player, progresso, início e submissão de quiz com identidade de sessão, enrollment ativo e RbacGuard; quiz/aluno são derivados da path/sessão e o teste materializado nega contexto cross-user. A rota de conclusão deriva o sujeito da sessão e da matrícula/version pin, a verificação pública aceita somente chave opaca e não serializa identidade do aluno, e revogação exige admin. A fronteira escolar persistida agora abrange matrícula, aula/progresso, score/correção, submissão/avaliação, conclusão/revogação, autoria/rollback, scheduler e papéis; o teste materializado nega um admin de outra escola na fronteira HTTP e nos serviços antes de efeitos. Ainda faltam mídia real e a enumeração independente de toda rota da aplicação separada.
• [~] Provar isolamento multi-tenant também no banco, cache, filas, realtime, arquivos, buscas, métricas, exports e Nexus; prefixos sem testes de não-interferência não constituem isolamento. O scaffold agora prova em SQLite que escola vem de membership autenticada, seleção arbitrária/ambígua falha, IDs de curso/aula não atravessam a escola, entitlement é school-scoped e um admin estrangeiro não causa efeitos em matrícula, autoria, rollback, avaliação, score, certificado, scheduler ou revogação de papel. A prova é Outbox, regras/execuções de automação, conquistas derivadas e notificações agora preservam school_id, inclusive para o mesmo usuário em duas escolas e com uma regra estrangeira habilitada. A prova continua deliberadamente parcial: Core possui wrappers de storage, cache, realtime e presence imutavelmente ligados a TenantContext, com provas da mesma chave/canal entre dois tenants, sem flush global no wrapper de cache e com nomes/payload realtime limitados. O leaderboard Academy usa agora esse cache tenant-scoped como projeção reconstruível, valida o payload e invalida após score, quiz e correção; a regressão materializada prova cache/invalidations. Anexos/mídia, demais caches, autorização de salas além da assinatura de notificação owner/admin e realtime distribuído, cache distribuído, bucket remoto, busca, métricas, exports, Nexus e PostgreSQL/MySQL continuam sem claim integral.
• [~] Criar papéis e separação de deveres para owner da escola, administrador, instrutor, avaliador, moderador, suporte, responsável e aluno, com elevação temporária auditada e nenhuma mutação autônoma por AI. O starter agora gera assignments duráveis para os oito papéis, registra grantor, motivo e janela, exige expiração para suporte, reserva grants de owner/admin ao owner da escola sem autoelevação, vincula replay à requisição exata e reconstrói no middleware apenas papéis ativos. Endpoints autenticados vinculam o alvo à path e oferecem grant/revoke; revogação usa chave própria, compare-and-set e preserva ator, motivo e instante, com replay exato como no-op. O teste materializado cobre o ciclo HTTP, expiração, revogação, replay conflitante e nega que admin conceda ou revogue papel privilegiado. Assignments e consultas agora carregam school_id, e revogação de outra escola retorna not-found. Ainda faltam cerimônia de step-up, trilha externa compartilhada e ferramentas AI limitadas por esse contexto.
• [~] Proteger uploads e conteúdo ativo com tamanho/tipo reais, nome de arquivo, parsing isolado, quarentena e adapter de malware scanning. O contrato UploadPolicy valida tenant/nome/tamanho, compara MIME e extensão com assinaturas reconhecidas, rejeita texto ativo, gera chave de quarentena aleatória e tenant-scoped, vincula SHA-256 e falha fechado sem verdict limpo do UploadScanner; o scanner offline é explicitamente apenas um mock determinístico. Ainda faltam streaming multipart, persistência/movimentação remota, parsers/transcoding em sandbox, scanner de produção e políticas profundas separadas para SVG, HTML, mídia, arquivos compactados e documentos.
• [~] Implementar privacidade por design para menores e adultos: o scaffold agora persiste age_band em vez de data de nascimento, política de retenção versionada e school-scoped, consentimento de responsável por finalidade com revogação e pedidos idempotentes de exportação/exclusão. Uma varredura administrativa limitada e school-scoped marca políticas vencidas por CAS e agenda pedidos duráveis/idempotentes de exclusão, sem apagar dados silenciosamente. O protocolo de fulfillment school-scoped fornece claim com lease, recuperação de abandono, token exato, retry atrasado, limite/dead-letter e finalização vinculada a ator e digest SHA-256 do resultado. Um executor supervisionado de dispatch estático aplica timeout menor que a lease, shutdown explícito e métricas locais sobre um adapter de fulfillment pertencente ao produto; o mock determinístico é explicitamente apenas protocolo e nunca exporta, exclui ou anonimiza dados. A regressão SQLite falha fechado para menor sem consentimento/depois da revogação, nega responsável de outra escola, prova não interferência da varredura/worker entre escolas, replay sem duplicação, lease expirada, token obsoleto, retry e dead-letter; claims abandonadas no teto rígido de dez tentativas são movidas por CAS para dead-letter em vez de serem recuperadas indefinidamente, e também percorre sucesso supervisionado e falha de adapter até dead-letter. Ainda faltam implementar no produto o adapter que executa export/delete/anonymize em todas as tabelas, comprovar identidade do responsável, observabilidade sem PII e revisão legal do produto/deploy; conformidade nunca será inferida apenas do framework.
• [~] Implementar rate limit/abuse control distribuído por identidade e origem, revogação de sessão/dispositivo, MFA com recovery codes e trilha durável para ações administrativas e alterações de nota/pontuação. O adapter Redis atômico aceita chaves derivadas de identidade/origem sem armazená-las em claro, e as correções de score do starter são append-only; o contrato live prova duas instâncias do limiter contra Redis real. Ainda faltam a composição HTTP Academy, revogação/dispositivos, persistência transacional dos recovery codes, cluster/failover e auditoria durável compartilhada.
• Publicar um ProductionPreset::academy() fail-closed e um diagnóstico CLI que reporte PASS, FAIL, SKIPPED ou NOT_EVALUATED para as fronteiras verificáveis, sem emitir certificação ou nota de segurança fabricada. O preset tipado rejeita requisitos ausentes/duplicados/não aprovados; cargo rullst academy:doctor normaliza as 12 fronteiras, exige evidência declarada não vazia para PASS, suporta JSON e termina com erro enquanto o contrato não estiver integralmente satisfeito, sempre com certification: false.
• Submeter a aplicação Academy e suas integrações críticas a revisão externa, corrigir achados e publicar versão, escopo, metodologia e limitações antes de usar alegações comparativas de segurança.

DX, operação e prova de superioridade vertical

• Adicionar scaffolds coerentes para curso/módulo/aula, matrícula, quiz, atividade, conquista, leaderboard, automação, conclusão e certificado. Os modelos, migrations, constraints/índices, registros Nexus e repositories opcionais são gerados; o projeto LMS materializado passa cargo test --offline --all-targets, com pontuação derivada somente leitura no admin. Fluxos verticais completos e a prova sobre pacotes publicados permanecem itens separados deste programa.
• Evoluir Nexus para autoria educacional: ordenação de módulos/aulas, preview, revisão, publicação, coortes, matrículas, rubricas, moderação e visão de progresso, sempre com políticas de campo/ação no servidor.
• [~] Fornecer fixtures offline determinísticas e um seed Academy divertido que exercite toda a jornada sem credenciais externas nem dados apresentados como produção real. As migrations agora semeiam módulo, quiz, o jogo offline Borrow Checker Rescue, conquista e regra de automação com JSON versionado, sem a função datetime() específica de SQLite. Ainda faltam usuário/sessão, tentativas, pontuação/entrega e mídia local para uma jornada E2E completa.
• Criar E2E de navegador para aluno, professor e administrador, incluindo acessibilidade, perda de conexão, retries, concorrência e todos os casos negativos definidos pelo threat model.
• Operar a referência com PostgreSQL/MySQL/SQLite conforme suporte declarado, Redis opcional, backup/restore, migrations, rotação de segredo, deploy e rollback ensaiados; publicar limites e combinações realmente verificadas.
• Medir tempo até primeiro curso seguro, primeiro quiz, primeiro ranking e primeiro diagnóstico com usuários novos, além de benchmarks reproduzíveis e perfis de CPU/memória; resultados devem incluir falhas e custo operacional.
• Documentar uma trilha única “zero ao LMS em produção”, receitas de extensão, escape hatches Axum/Tokio e migrações SemVer, mantendo exemplos compilados e links válidos como gates de release.

O que significa “10/10”

Nota 10 não significa ter todos os recursos imagináveis. Significa ser excepcional dentro de uma fronteira declarada:

• Segurança: defaults fortes, limites explícitos, threat models, testes adversariais e revisão externa.
• IA: integração útil com autorização, evals, observabilidade e controle humano.
• Experiência: primeiro sucesso rápido, erros acionáveis, blueprints que compilam e uma rota clara de desenvolvimento para produção.
• Release: artefatos reproduzíveis, proveniência, SemVer e documentação honesta.
• Confiança real: aplicações independentes operadas, atualizadas e recuperadas com sucesso.
• Validação externa futura: uma Academy independente poderá demonstrar a jornada segura de aluno, professor e administrador usando somente APIs e pacotes públicos, sem se tornar condição de qualidade ou lançamento da v12.

O caminho mais curto para tornar o Rullst extraordinário agora não é acrescentar mais uma promessa: é tornar cada fronteira já escolhida previsível, comprovável e agradável de usar.

Auditoria dos roadmaps anteriores ao gpt.md

Esta seção registra a classificação solicitada para todos os roadmaps que existiam imediatamente antes da criação de gpt.md. Ela impede que uma caixa histórica marcada como concluída volte a ser interpretada como prova de uma capacidade end-to-end ou como obrigação de acrescentar escopo à v12 RC.

Corte histórico, método e regra de decisão

• O gpt.md foi criado no commit ecf3ecb6; a fotografia imediatamente anterior e imutável é 96222fbd, de 24 de agosto de 2026.
• Nessa fotografia existiam 12 arquivos chamados ROADMAP.md ou roadmap.md: um roadmap mestre, uma cópia divergente no mdBook e dez roadmaps de crates.
• Usando o ROADMAP.md da raiz como cópia canônica, havia 226 caixas [x] e 88 caixas abertas. Várias caixas agregavam muitas capacidades diferentes; a contagem não representa 226 implementações comprovadas.
• Das 226 linhas marcadas, 36 são repetições textualmente idênticas dentro do roadmap do ORM. A auditoria preserva as 226 linhas históricas para não apagar o registro, mas usa também 190 alegações exatas deduplicadas para que uma cópia documental não conte duas vezes como engenharia entregue.
• A classificação abaixo foi feita contra código, testes e a SST atuais. Um nome de módulo, trait, scaffold, mock ou teste unitário isolado não basta para promover a alegação inteira a implementada.
• A evidência e os limites de maior risco permanecem no capability ledger; a preservação do texto original e os links para a fotografia histórica estão em Preservação da documentação anterior ao gpt.md.

As decisões de release usadas nesta seção são:

• v12 obrigatória: superfície que a v12 pretende suportar sem o rótulo experimental. Precisa de implementação delimitada, teste negativo, docs honestas e todos os gates da release.
• v12 experimental: fundação útil que pode permanecer apenas atrás de uma feature, simulador ou aviso explícito, desabilitada por padrão quando houver risco. Não bloqueia a RC e não recebe promessa de produção.
• v13+: trabalho valioso, porém grande, dependente de novo contrato, infraestrutura, hardware, provedor ou mudança arquitetural. Não deve ampliar o escopo da v12 RC.
• não recomendar/prometer: a redação absoluta ou a automação autônoma não é um contrato tecnicamente honesto. Quando existir um núcleo útil, ele deve ser substituído por uma meta menor, mensurável e revisável.

Inventário documental anterior ao gpt.md

Reclassificação integral do roadmap mestre M1–M32

Quando um milestone histórico misturava uma base real com uma visão futura, a decisão é deliberadamente dividida. Isso é mais preciso que trocar apenas [x] por [ ].

Classificação dos dez roadmaps detalhados por crate

Esta tabela fecha as alegações que os milestones compostos não enumeravam individualmente. O status sempre se refere ao contrato inteiro da frase histórica, não apenas à existência de um arquivo com nome parecido.

Decisão final de escopo da v12 RC

Esta auditoria não presume que um antigo [x] esteja implementado. Ela o transforma em entrada obrigatória da campanha, mas o resultado possível pode ser integral, parcial, ausente, dependência externa/hardware ou não recomendada. Para a RC, a ordem correta é:

1. deduplicar e classificar cada alegação, mantendo as 226 linhas originais rastreáveis;
2. implementar e testar por risco e valor toda parcela localmente executável que pertença a uma fronteira coerente do framework;
3. manter fundações incompletas atrás de limites experimentais explícitos, sem apresentá-las como garantias estáveis;
4. registrar providers, certificação, hardware e operações externas como tais, usando mocks somente quando forem determinísticos e inequivocamente rotulados;
5. congelar a superfície somente depois da campanha executável e manter verdes os gates, pacotes, upgrades e blueprints; rejeitar absolutos de marketing e automação autônoma sem preview, aprovação, auditoria e rollback.

Em resumo: a documentação histórica realmente dava a entender que muito mais estava concluído. A campanha solicitada passa por todas as 190 alegações deduplicadas e tenta fechar o máximo tecnicamente honesto e localmente executável. Isso não autoriza fabricar integrações live, certificação, hardware ou garantias absolutas: tais parcelas precisam ser classificadas com sua dependência externa e mantidas fora da superfície estável até existir evidência. Cada ampliação da v12 continua subordinada aos mesmos gates e limites públicos.

Painel rastreável da campanha de implementação

Este painel mede o esforço solicitado para transformar em contratos reais as capacidades que apareciam marcadas como concluídas antes de gpt.md. Ele não é uma porcentagem de “todo software imaginável” nem uma previsão de prazo.

Camada de macroentregas — estado em 2026-09-01

O denominador provisório contém as 24 macroentregas historicamente marcadas [x] no roadmap mestre mais o lote Polyglot acrescentado durante esta auditoria:

Um item só muda para integral quando código, testes relevantes, documentação e gates aplicáveis estiverem fechados. O lote de persistência tornou-se a sexta macroentrega integral depois das matrizes live, testes completos, Clippy estrito, formato, fronteiras de features e mdBook passarem em 29 de agosto de 2026. Essa é evidência do worktree local; os mesmos gates ainda precisam passar no futuro SHA imutável da RC.

Na régua das 190 alegações históricas exatas, o fechamento dos dois scaffolds fiscais/dunning, da ponte autenticada/failover tipado e do scheduling durável de Mail, do proxy explícito de Connect, da invalidação imediata de feature flags/histórico opt-in de jobs do Studio e do RAG tenant-aware auditado mais o lifecycle state/PKCE/nonce de sessão do Connect, os adapters canônicos de webhook Axum/Actix do Capital, o scaffold de billing SQLx/Turso, o handle delimitado de subscription/grace period, a mutação relacional delimitada do Studio, a política JSON Schema/OpenAPI explícita do Security e a memória de chat SQL tenant-aware/CAS do AI e o Sentinel determinístico/PoW delimitado do Security, o harness Criterion equivalente Rullst/Diesel/SeaORM, o Mock IdP OIDC local assinado, os widgets semânticos Nexus validados e a cobrança imediata segura/delimitada do Billable, o billing medido tipado/delimitado e as quotas compartilhadas concorrentes/duráveis do Capital e os contratos delimitados de cupons/trial, o refresh OAuth concorrente delimitado e o transporte AWS SES v2 nativo assinado pelo SDK oficial e o contrato bounded de attachments/CID comum aos transports nomeados levam o inventário a 102 integrais, 86 parciais e 2 ausentes. O fechamento delimitado de ORM-31 — ator/tenant obrigatório, revisão restaurável e recusas transacionais — leva o inventário a 103 integrais, 85 parciais e 2 ausentes. O fechamento de IOT-03 como codecs bounded MQTT 5 PUBLISH e CoAP request, sem alegar transporte, levou a régua a 104/84/2. O fechamento de AI-05 com entradas explícitas de bytes, arquivo allowlisted e URL sob egress policy levou a régua a 105/83/2. O fechamento delimitado de ORM-41 — codecs derivados, ENUM nativa nos perfis suportados, constraint SQLite, recusa fail-closed de PostgreSQL via SQLx Any e matrizes live — leva o estado atual a 106 integrais, 82 parciais e 2 ausentes: 55,8% estrito ou 77,4% ponderado. Essa régua inclui as 24 macroalegações históricas e as 166 alegações dos roadmaps de crates, portanto não deve ser somada à camada de 25 macroentregas acima. Dependências externas, hardware, certificações e absolutos tecnicamente não recomendáveis continuam parciais/ausentes em vez de receber crédito artificial.

Horizonte ampliado — backlog canônico até a v13

Esta é uma segunda pergunta, separada da campanha das 190 alegações antigas: quanto falta se também mantivermos no programa todo milestone canônico ainda sem [x] e planejado até a v13?

O denominador é o tracker M1–M39 do ROADMAP.md, recalculado em 4 de setembro de 2026. Entram hardening v12, manutenção corretiva 12.0.x, o próximo ciclo SemVer, trabalho contínuo, v13 e pesquisa v13. M31 não entra, pois o próprio roadmap destina aeroespacial/autônomos/defesa a um programa futuro separado, com outra governança. As caixas dos roadmaps detalhados de crates não são somadas: elas repetem ou decompõem esses milestones e produziriam dupla contagem.

• Na régua estrita, 33/38 ainda não estão fechados: faltam 86,8%.
• Na régua de maturidade ponderada, (5 + 24 × 0,5) / 38 resulta em 44,7% implementado e 55,3% faltando. Esses 55,3 pontos equivalentes são os nove itens ainda vazios (23,7 pontos) mais a metade não concluída dos 24 parciais (31,6 pontos).

Portanto, a resposta operacional para o horizonte ampliado é aproximadamente 55,3% de engenharia restante, sem esconder que 86,8% dos milestones ainda não têm fechamento integral. Isso não é prazo: contas de provedores, hardware, lojas, homologação fiscal, auditorias independentes e criptografia de pesquisa exigem evidência externa. Também não se soma esta porcentagem aos 22,9% restantes da campanha histórica nem aos cerca de 30% da preparação da RC, pois os três denominadores se sobrepõem fortemente.

Lote concluído localmente: fundação de mensageria por contrato

rullst-messaging passa a ser a fronteira separada de OAuth/OIDC para eventos brokered. O escopo v12 implementado é propositalmente delimitado: envelope rullst.messaging.v1, nomes/headers/payloads/batches/retenção limitados, publicação idempotente por tópico com conflito fail-closed, fan-out entre grupos, consumidores concorrentes, leases de ACK expiráveis e de uso único, retry com teto de tentativas, dead-letter, purge terminal explícito, tempo injetável e broker em memória. O adapter opt-in SQLite persiste publicação, inscrição, claim, ACK/retry/DLQ, idempotência e purge sob transações de escrita serializadas. Testes provam restart com lease expirado, duas instâncias concorrentes, configuração imutável por namespace e corrupção fail-closed seguida de reparo. O lote também congela um codec binário canônico v1 para o envelope com fixture de digest determinística, rejeição de versão desconhecida, truncamento, oversize, ordem não canônica e namespace incorreto. traceparent W3C v00 e um subconjunto conservador de tracestate podem atravessar somente esses dois headers; baggage, sampling e exportação continuam sob responsabilidade do host.

O perfil SQLite padrão continua plaintext; o perfil explícito encrypted usa AES-256-GCM com nonce aleatório e prende namespace, tópico, sequência, ID, evento/content-type, timestamp e key-id na AAD. Ele protege valores de headers e payload, prova raw-state/restart/tamper/row-swap/rotação/symlink e exige chaves anteriores enquanto houver registros que as referenciam. Metadados de rota, idempotência e delivery continuam visíveis; custody, backups protegidos, rollback e migração de perfil são do host.

O perfil opt-in orm-outbox liga um stream relacional exato a um tópico por static dispatch. Ele valida o claim JSON, publica usando event_key como idempotência e só então reconhece o lease ORM. A regressão interrompe após o primeiro publish, recupera o claim expirado e prova replay com o mesmo ID e uma única mensagem. Isso não transforma commit, publish e ACK numa transação distribuída atômica; supervisão, cleanup, autorização e idempotência no destino permanecem da aplicação.

Isso melhora M15, mas não o fecha: a entrega continua at least once, e autorização/tenant, backup, retenção e idempotência do efeito externo pertencem ao host. O codec de envelope não é um transporte, não preserva sozinho a chave de publicação nem mapeia ACKs de provedor. Replicação/failover, Kafka, RabbitMQ, Redis Streams, NATS/JetStream, SQS/SNS, Google Pub/Sub, Pulsar e suas matrizes live continuam abertos. A porcentagem do horizonte não muda porque M15 permanece [~], agora com evidência mais forte.

Camada detalhada

As 226 marcações históricas canônicas permanecem preservadas e suas 190 alegações exatas deduplicadas estão 100% classificadas abaixo como integral, parcial, ausente, dependência externa/hardware ou não recomendada, com arquivo/teste de evidência quando aplicável. A leitura mantém dois denominadores:

1. visão histórica total, preservando tudo que foi prometido;
2. engenharia executável localmente, que orienta implementação e exclui apenas certificação, hardware, contas/credenciais e mudanças de estado externas que este repositório não pode honestamente fabricar.

Lote concluído localmente: matriz de persistência

Implementação, matrizes live e gates completos foram concluídos no worktree atual:

• contratos separados para SQLite, PostgreSQL, MySQL e MariaDB;
• Turso/libSQL remoto pelo protocolo oficial Hrana HTTP v3, com parâmetros, batch transacional atômico, deadline, redirects recusados, resposta e resultados limitados, migrations reversíveis com detecção de drift e fallback persistente de SQL real; a matriz live também prova rollback após falha intermediária;
• perfil Turso-primary blank/API com #[derive(Orm)], CRUD/query tipados, make:model, make:migration, migrate/status/rollback e provas local/remota;
• MongoDB documental, DuckDB analítico e SurrealDB documental/grafo por APIs de capacidade explícitas;
• inventário documental estável e recuperação portátil MongoDB/SurrealDB em envelope AES-256-GCM versionado, ligado a aplicação/coleção/key ID, com scan duplo, limites de páginas/documentos/plaintext, restauração idempotente sem overwrite e ensaio live MongoDB → SurrealDB → MongoDB; writers devem ser pausados e schema/backup gerenciado continuam externos;
• assistente cargo rullst new dividido entre banco relacional principal e integrações opcionais, inclusive flags determinísticas; a seleção interativa agora explicita zero ou mais add-ons, omite capacidades já escolhidas e não oferece Turso-primary aos blueprints ainda específicos de SQLx;
• CLI pré-release compilado do source checkout conserva esse mesmo checkout versionado como origem de dependências quando invocado fora do repositório; falhas da migração inicial preservam o scaffold e exibem status/comando de repetição, em vez de esconder o diagnóstico atrás de um aviso genérico;
• matrizes live em containers onde existe servidor redistribuível adequado, seguidas pelos gates completos de teste, Clippy, formato, docs, fronteiras de features, empacotamento e inspeção do conteúdo/licença dos pacotes.

Evidência local de fechamento:

• cargo test --workspace --all-features passou, incluindo testes unitários, integração, projetos gerados e doctests;
• cargo clippy --workspace --all-features -- -D warnings passou sem avisos;
• cargo fmt --all -- --check e git diff --check passaram;
• .github/check-feature-boundaries.sh passou para todos os pacotes mínimos e features isoladas declaradas, e mdbook build docs construiu o livro;
• PostgreSQL, MySQL, MariaDB, MongoDB, SurrealDB 3.2.4 e Turso/libSQL passaram suas matrizes com containers reais e com RULLST_REQUIRE_TESTCONTAINERS=true. No CI/release, falha de inicialização agora é fatal; somente execuções locais sem essa variável podem pular Docker;
• os 16 arquivos .crate de 12.0.0 foram gerados localmente sem upload e passaram .github/audit-packages.sh 12.0.0: nomes e quantidade exatos, caminhos seguros, Cargo.toml/LICENSE/README/src presentes, licença idêntica à raiz, nenhum padrão de segredo e nenhum pacote acima de 10 MiB. Esse resultado não substitui o empacotamento verificável no SHA limpo da RC.

Apoio de MariaDB não significa um driver Rust distinto: ele usa corretamente o protocolo MySQL do SQLx, mas só é anunciado depois de passar um contrato live em imagem MariaDB. Turso/libSQL também é relacional e pode ser a única fonte de dados no perfil primary delimitado; o derive comum exige #[orm(backend = "turso")] para não trocar o driver implicitamente. MongoDB, DuckDB e SurrealDB não fingem implementar a mesma semântica do Active Record relacional.

Fechamento delimitado do M6: Turso como primary

cargo rullst new --database turso agora gera um blank/API que compila, usa TursoOrm, executa migrations checksummed/reversíveis e não conserva um DATABASE_URL SQLx fictício. A matriz cobre o fallback persistente offline e o contrato tipado no servidor libSQL oficial; os generators posteriores mantêm o backend. --turso continua corretamente aditivo quando existe outro primary. Os demais blueprints ainda são SQLx-specific e rejeitam a seleção, em vez de simular paridade. Replica sync transparente também permanece fora do contrato.

Inventário item a item — rullst-ai histórico

Com o roadmap mestre já individualizado acima, esta primeira tabela detalhada levou o inventário exato a 31 alegações; as tabelas Auth, Capital, Connect, IoT, Mail, Nexus, Studio, Security e ORM seguintes elevam o total a 190/190 alegações classificadas individualmente (24 do mestre, 7 de AI, 2 de Auth, 13 de Capital, 23 de Connect, 15 de IoT, 18 de Mail, 4 de Nexus, 7 de Studio, 32 de Security e 45 de ORM), isto é, 100% do inventário deduplicado. Esse número mede conclusão da auditoria, não implementação integral: no ORM, por exemplo, 25 itens têm contrato integral delimitado, 19 são parciais e um está ausente. “Integral” continua significando somente o limite descrito na evidência; não herda os absolutos da frase antiga.

O fechamento de AI-07 também corrigiu uma caixa que antes era apenas nominal: o generator antigo usava tipo de chave e métodos incompatíveis com o ORM, chamava utilitários inexistentes, não criava migrations e descartava os dois erros de persistência. A classificação acima usa o novo contrato executado, não a mera existência anterior do subcomando.

O fechamento delimitado de AI-05 move uma alegação de parcial para integral sem fingir descoberta universal de modelos: os três formatos de origem agora existem, mas capability declarada e aceitação real do modelo continuam coisas distintas. A régua global correspondente é 105/83/2, ou 55,3% estrito e 77,1% ponderado.

Inventário item a item — rullst-auth histórico

Hardening posterior ao snapshot, fora do denominador histórico de 190 alegações: a feature sqlite agora habilita SqliteJwtRevocationStore, com JTI expirável, versão monotônica por subject, quota/configuração persistida, transações BEGIN IMMEDIATE e verify_async; e SqlitePasskeyStore, com cadastro/listagem/rename/revogação, reinício e CAS do signature counter após cerimônia ES256 válida. Testes exercitam duas instâncias no mesmo arquivo, concorrência, replay, quota e corrupção/configuração. Esse contrato é integral somente no escopo SQLite local delimitado: challenge state permanece process-local; identidade/ownership, cifragem/permissões/backup do arquivo, replicação multi-host, refresh workflow e conformance WebAuthn continuam externos.

Inventário item a item — rullst-capital histórico

O lote Capital também fechou cinco lacunas locais sem ampliar artificialmente o contrato: o derive genérico passou a compilar pela fachada pública, o renderer de fatura passou a escapar ID, e-mail, descrição e moeda, e Axum/Actix passaram a compartilhar a mesma fronteira de webhook testada. O scaffold de billing agora seleciona SQLx/Turso-primary, ativa features exatas, preserva arquivos e nega conflito de ownership antes de vincular customer. O ledger relacional opt-in agora cobre idempotência compartilhada limitada de webhook sem armazenar payload/ID em claro. Orquestração automática por webhook, exactly-once entre sistemas, reconciliação e operações live sem contract test continuam explicitamente fora da classificação integral; PDF e a ponte de entrega pós-pagamento já existem no limite descrito em CAP-04. O grace period agora é um valor tipado/derivável, não uma alegação de persistência ou automação do provider.

O hardening posterior dos gateways unificou todos os métodos HTTP live revisados numa única fronteira: pool compartilhado, timeouts finitos de conexão e request, redirects e proxy ambiente desabilitados, JSON limitado a 1 MiB e URL de checkout absoluta/HTTPS/sem credenciais ou fragmento. Request inválido, falha de transporte, status HTTP, rate limit com Retry-After numérico limitado, corpo excessivo, JSON inválido e resposta semanticamente incompatível agora produzem ProviderFailure redigido com classe permanente/transiente/rate-limited. Fixtures reais cobrem redirect, desconexão, 429, 4xx, 5xx, oversize, JSON e vazamento negativo de segredos. O framework não faz retry automático de mutação financeira; idempotência encaminhada pelo provider, backoff e reconciliação continuam obrigatórios no host. Essa evidência elevou Capital de 89/B para 92/A.

O cluster fiscal local subsequente passou a exigir e expor o tpAmb dentro da DPS assinada, impedindo reinterpretação entre homologação e produção. O FiscalCommandJournal registra antes de qualquer transporte do host um comando opaco e depois exatamente um resultado autorizado/rejeitado já vinculado pelo parser. A cadeia HMAC nomeada, os limites de 4.096 eventos/16 MiB, replay exato, conflito de chave, reinício, recuperação de pendentes, symlink, adulteração, writer concorrente, quota e checkpoint externo têm regressões executáveis; XML, chave de acesso, mensagens, corpo e certificado não entram no arquivo. Isso alcança honestamente o teto Capital de 93/A, a sétima das 15 crates ativas a fechar sua meta local. Transporte, retry, request/outbox autoritativo, reconciliação multi-writer, confiança ICP-Brasil e homologação SEFIN continuam fora da alegação.

O avanço de CAP-04 não alterou sozinho os totais anteriores: a alegação histórica inclui orquestração automática após qualquer pagamento, enquanto o contrato entregue exige recibo final explícito e deixa o claim durável/exactly-once fora da biblioteca. A classificação só sobe para integral se essa lacuna for fechada sem inventar garantias de transporte.

CAP-06, em contraste, descrevia a API de reporte nos dois providers. O contrato provider-specific, os parsers vinculados e as fixtures de protocolo fecharam esse escopo delimitado sem transformar fixture em aceitação por conta live nem fornecer a outbox da aplicação. CAP-10/CAP-11 agora acrescentam uma identidade de billing compartilhada, uma reserva idempotente que bloqueia o callback antes do over-limit e um store SQL transacional exercitado em quatro protocolos. Isso atualizou o inventário para 97/91/2, 51,1% estrito e 75,0% ponderado; membership, tier/reconciliação, migrations e writes que não usam a fronteira continuam deliberadamente pertencendo ao host. CAP-12/CAP-13 acrescentam valores delimitados, protocolos e binding de resposta para cupons/trial, levando o total a 99/89/2, 52,1% estrito e 75,5% ponderado, sem inventar paridade entre gateways ou aceitação por conta live. CONNECT-10 adiciona o coordenador process-local de refresh com binding de identidade e troca de estado pós-validação, atualizando a régua para 100/88/2, 52,6% estrito e 75,8% ponderado; persistência cifrada e coordenação distribuída continuam fronteiras explícitas. MAIL-06 substitui o antigo falso caminho bearer direto por SES v2 nativo opt-in no SDK oficial, SigV4, credenciais temporárias ou provider/config do chamador e paridade local de payload/attachments/RFC 8058, levando a régua a 101/87/2, 53,2% estrito e 76,1% ponderado. O contract loopback prova protocolo e assinatura; conta AWS live, identidade, sandbox, quotas, reputação e entrega continuam evidência externa. MAIL-08 acrescenta limites comuns antes do encoding, metadata inequívoca, Content-ID único e referenciado, Debug sem bytes e a árvore MIME SMTP mixed/alternative/related, levando o total a 102/86/2, 53,7% estrito e 76,3% ponderado. O contrato histórico “zero-copy” é refutado: os bytes são owned e os transports copiam/Base64-encodam conforme o protocolo; limites de provider e inspeção do conteúdo opaco continuam fora. ORM-31 fecha depois o contrato histórico delimitado de revisões auditáveis e leva o total a 103/85/2, 54,2% estrito e 76,6% ponderado. Isso não transforma auditoria relacional em backup, histórico bulk ou export durável.

Inventário item a item — rullst-connect histórico

Os fechamentos de CONNECT-16 e CONNECT-19 corrigiram duas contradições: o primeiro impede que a projeção normalizada reexponha credenciais; o segundo substitui o antigo token opaco por um fluxo OIDC criptograficamente verificável, mas rejeita a palavra “perfeitamente” e permanece estritamente local. Antes, SecretString escondia tokens em Debug, mas serializadores custom voltavam a expor as credenciais em JSON. A serialização agora omite ambos os tokens e a projeção pública exclui também payload bruto e metadados de credencial.

Inventário item a item — rullst-iot histórico

O lote IoT removeu três falsos sinais locais sem fabricar integrações externas: nomes perigosos não escapam mais do projeto pelo generator, labels de telemetria não entram cruas no HTML e um snapshot não é rotulado como dispositivo online. Drivers, redes, flash, HSM e PQC permanecem deliberadamente fora do resultado integral até existirem implementação e provas proporcionais em hardware real.

Inventário item a item — rullst-mail histórico

O hardening Mail fechou o generator que antes parecia pronto mas emitia imports ausentes e templates vulneráveis a markup injection. Os dois comandos que só existiam na documentação agora também são código materializado, com proveniência fiscal e dunning explícitos. O caminho enganoso que tentava falar com AWS sem SigV4 foi removido e o caminho nativo opt-in agora delega assinatura, transporte e credenciais ao SDK AWS oficial. Isso melhora a segurança local sem promover mocks, bearer proxy, fixture SigV4, HMAC ou heurísticas a conta live, deliverability, privacidade legal, autorização fiscal ou inbox delivery. O fechamento delimitado de MAIL-08 adiciona uma fronteira comum antes do transporte e corrige a árvore MIME SMTP sem renomear cópias como zero-copy. A validação base de metadata não se transforma sozinha em inspeção do arquivo nem em prova de aceitação por contas live.

O lote de teto local posterior adicionou três controles opt-in sem ampliar essas promessas: AttachmentInspectionGuard executa um inspector estático antes do transport; SuppressionGuard consulta estado manual/hard-bounce/spam complaint process-local ou SQLite compartilhado-local, com replay exato, quotas imutáveis, restart e concorrência de duas instâncias; e ObservedMailDriver emite somente provider/outcome/latência/contagem e flags de scheduling/tenant. Eventos do provider ainda precisam ser autenticados antes de entrar no store, o scanner local continua heurístico e operação distribuída/inbox delivery continuam externas. Essas evidências elevam rullst-mail ao teto local 95/A, não a certificação nem a uma garantia de entrega.

Inventário item a item — rullst-nexus histórico

O lote Nexus também fechou uma divergência de segurança: labels, nomes de tabela/campo e ícones registrados são escapados ou estritamente normalizados nas telas CRUD, sidebar, dashboard e fallback do assistente; falhas SQL não são devolvidas ao navegador. O tenant opt-in protege todas as rotas built-in e o audit obrigatório registra actor/tenant/table/action/key opcional/count/outcome/ correlation/time/version ou desfaz a mutação. Isso não transforma metadata em identity/membership, não autoriza models globais/custom routes e não torna a tabela do mesmo banco append-only, tamper-evident ou separada.

Inventário item a item — rullst-studio histórico

Os dois itens que estavam abertos no roadmap histórico foram implementados depois desta classificação sem reescrever o snapshot: o profiler SQL usa somente labels redigidos de spans v1 autenticados e chama repetição de possível N+1; o inspetor Memory/Redis é metadata-only, mascara a chave por HMAC e não fornece conteúdo nem flush global. Esses limites são parte da capacidade v12 atual, não prova de diagnóstico perfeito ou administração remota segura.

O hardening Studio corrigiu ainda um falso positivo de teste: a antiga consulta SELECT * podia falhar ao mapear BOOLEAN do SQLite via SQLx Any e o erro era silenciosamente convertido em tabela vazia com HTTP 200. A projeção agora faz casts explícitos, propaga a falha e o teste exige os registros reais. A busca de metadata do ER deixou de interpolar nomes em SQL e a fronteira Mermaid deixou de aceitar identifiers brutos ou securityLevel: loose. A nova escrita local não reutiliza o router bruto como autoridade: sem a marker privada produzida pelo access middleware, o handler retorna 403 antes de consultar o banco.

Inventário item a item — rullst-security histórico

O lote Security acrescentou hardening verificável sem inventar integrações: inputs de fingerprint/traps/MFA passaram a falhar fechados, o Schema Guard recusa JSON inválido/chaves duplicadas e aplica uma política 2020-12/OpenAPI 3.1 explicitamente montada sem resolução externa, o redator cobre valores repetidos e JSON, o firewall alcança prompts aninhados e o Login Guard oferece uma API que aplica o atraso. O QR de MFA e o SRI file-backed são artefatos reais; o SBOM e o doctor deixaram de aceitar identificadores/versões apenas aparentes. No gate focado passaram 129 testes unitários e 36 testes de integração, robustez e concorrência em rullst-security, além de 148 testes de biblioteca no CLI e Clippy estrito nos dois pacotes. Isso continua sendo evidência local do worktree; Redis distribuído, providers, certificação e deployment exigem suas próprias provas.

Inventário item a item — rullst-orm histórico

O inventário deduplicado está agora 190/190 (100%) classificado, mas o resultado honesto não é “190 funcionalidades prontas”. Neste lote ORM há 28 contratos/evidências integrais delimitados e 17 fundações parciais: 62,2% estrito ou 81,1% ponderado atribuindo metade do peso aos parciais. O benchmark comparativo conta como evidência entregue, não como confirmação da antiga conclusão de performance, que seus primeiros resultados contradizem. O hardening associado fechou o bypass tenant/policy em mutações, operadores de join injetáveis, inputs inválidos de paginação/chunk/vector e o tracking de migration anterior a uma falha posterior. O keyset chunking também impede offset drift quando o callback remove linhas já processadas. Os gates focados e o cache .remember deixou de atravessar a fronteira transacional, ganhou isolamento application/tenant sem expor o tenant bruto e invalidação por tabela após commit, preservada em rollback. O contrato after_commit também separa falha do efeito posterior à persistência. O Outbox relacional opt-in agora acrescenta durabilidade at-least-once verificável sem fingir que callbacks arbitrários podem ser serializados automaticamente ou entregues exactly-once. Os gates focados e o trifecta final continuam sendo registrados como evidência do worktree, nunca como certificação de uma aplicação ou deployment.