feat: testes do auditoria controller

[Pr3d4dor]

Descrição

Cobre a tela de auditoria (GET /index.php/auditoria) e a limpeza de logs (auditoria/clean), que estavam sem nenhum teste, e conserta o que esses testes revelaram. O caminho passa por dois defeitos na própria página de erro do CI3, que aparecia como um 500 em cima de toda rota inexistente.

A página de erro morria antes de renderizar. O index.php precisa carregar os escapadores antes de o CI3 conseguir desenhar uma página de erro, e não depois: o Exceptions::show_404() inclui a view por include num ponto em que o Loader ainda não rodou — Loader::initialize(), que executa o autoload e carrega o helper general, só acontece no construtor de CI_Controller, e o 404 do Router acontece antes de existir qualquer controller. Uma rota inexistente respondia 500 com Call to undefined function esc() em vez de 404, ou seja, o usuário recebia um erro fatal dentro da página que existe para explicar a falha. error_exception.php e error_php.php passam a escapar com htmlspecialchars((string) $x, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8'): as mesmas flags de esc(), mas PHP core, que funciona em qualquer ponto do boot e não depende de nada já carregado. Um require_once do helper no index.php resolveria também, e foi descartado — só vale enquanto general_helper.php for nada além de definições de função sob function_exists, nada obriga isso, e a quebra cairia no único arquivo por onde passa toda requisição.

Escapar a mensagem das três views que a imprimem sozinha quebrava a página. O show_error() embrulha $message em <p> antes de incluir a view, e o DB_driver::display_error() junta um array de erros com </p><p> — o que chega na view já é markup, e é do CodeIgniter. Escapado, o usuário lia <p>The page you requested was not found.</p> como texto literal. Tirar as tags de parágrafo seria a outra opção e é pior: um display_error() de verdade entrega um erro de SQL de verdade, e o strip_tags() come o x<3 de um WHERE x<3. Essas três views passam a imprimir a mensagem crua dentro de uma div#body, e a decisão fica registrada: são as seis entradas unescaped do tools/xss-baseline.txt, com o que sobra exposto escrito no header do arquivo — a mensagem do próprio framework, restando o caso de um erro de banco que repetisse um valor vindo da query. error_exception.php e error_php.php seguem escapando cada valor e são a referência do que as outras três seriam se a entrada delas um dia virasse controlada por quem fez a requisição. As três views de cli/ seguem sem escaper desde sempre: o destino delas é um terminal, não markup.

clean() era intestável. O redirect() do CI3 chama exit(), e no caminho de sucesso ele encerrava o processo do PHPUnit inteiro — sem summary e sem dizer qual caso morreu. Hoje sai por respond_redirect() (o mesmo que o Login::sair() usa), que emite o Location pelo CI_Output sem encerrar o processo. O status continua sendo o que o redirect() escolheria, porque respond_redirect() resolve o número por redirect_status_for(): 303 num POST, 302 fora de HTTP/1.1, regra que já é coberta em GeneralHelperTest.

A tela lia o controller errado na segunda vez. O Loader::_ci_load() dá vida ao $this de uma view copiando as propriedades do controller para o Loader — mas só copia as que ainda não existem (isset($this->$chave)). Como o Loader é singleton, a primeira view do processo congela ali o retrato do primeiro controller, e todas as outras leem aquele objeto, que não existe mais. O sintoma é sutil e nada no controller o explica: uma library carregada no meio do método (o pagination do Auditoria::index()) ganha a propriedade nova no controller e funciona lá, mas a view renderizada logo depois lê o retrato velho, com o total_rows de um caso que já virou. Quem exercita a tela pela segunda vez no processo vê os links de página sumirem.

resetLoaderViewAliases() roda em resetSharedState(), antes de cada controller, e unseta no Loader tudo que não for _ci_*. O guard não é defesa teórica: Closure::call() reajusta o escopo para a classe do objeto, então o get_object_vars() enxerga as propriedades protegidas do Loader — sem o filtro o unset levaria junto _ci_models e _ci_classes.

O filho da fronteira de teste nascia sem a configuração que o .env guarda. O FrontendBoundaryTest sobe um php -S como production — é a única forma de ter o roteamento de verdade — e o routes.php só exige o routes_api.php quando $_ENV['API_ENABLED'] é verdadeiro. Essa chave mora no application/.env, que é ignorado pelo git, então o caso que deveria medir o 401 da API media um 404 — em toda máquina sem .env, que é o CI inteiro. O .env local mascara isso. O mesmo valia para APP_ENCRYPTION_KEY e GLOBAL_XSS_FILTERING, lidas pelo config.php sem valor padrão: a ausência delas é um aviso, e um aviso é uma linha de log em nível ERROR. O filho agora recebe as chaves explicitamente em childEnvironment(), e o WhoopsHook::extractEnvNames() parou de fazer file() no .env incondicionalmente. Um sexto item, APP_LOG_PATH, existe pelo motivo oposto: não para impedir a escrita, mas para mandá-la para outro lugar. O show_404() grava em log_message('error', …) antes de renderizar, então o caso do 404 escreve log de propósito, e um arquivo em application/logs/ faz o composer format:check falhar — aquela checagem não honra .gitignore.

O novo AGENTS.md registra os dois achados na lista de reentrância que o harness conserta, a regra sobre as páginas de erro, e a regra 5 de padrão: identificadores em inglês, comentário em português, texto de tela em português.

Issue relacionada

(nenhuma)

Tipo de mudança

• Correção de bug (fix)
• Nova funcionalidade (feat)
• Documentação (docs)
• Refatoração sem mudança de comportamento (refactor)
• Dependências / manutenção (chore)

Como testar

composer test          # 325 testes, 990 asserções, 2 skips pré-existentes
composer format:check  # 0 de 321 arquivos
composer xss:check     # 19 achados = 19 do baseline, 0 novos

Para confirmar que a cobertura da paginação é carga de verdade e não tautologia, desligue a linha em TestApplication::resetSharedState():

// Ci3Introspection::resetLoaderViewAliases(self::superObject()->load);

testIndexRendersPaginationReflectingCurrentData fica vermelho ao afirmar que o create_links() renderizou. Com a linha de volta, a suíte fecha verde.

O mesmo vale para o caso do 404, pelo outro lado. testAnUnknownRouteRendersTheErrorPage pede uma rota inexistente ao filho real e afirma o 404, o texto 404 Page Not Found no corpo e a ausência de undefined function. Ponha um esc() de volta no error_404.php e ele vira o único caso vermelho da classe, com Failed asserting that 500 is identical to 404 — que é exatamente o defeito que o commit anterior corrigiu.

Capturas de tela

(não se aplica — a página de erro sai com o mesmo texto de antes; o que mudou foi o <p> deixar de aparecer escapado dentro dela, e clean() continuar emitindo o mesmo flashdata e o mesmo destino)

Checklist

• O PR resolve um assunto (as correções e a refatoração são consequência do mesmo trabalho de cobertura).
• O código foi formatado com composer format.
• Testei manualmente o fluxo afetado. (a suíte automatizada é a verificação deste PR)
• Não há .env, credenciais, dumps de banco ou arquivos de IDE no diff.
• A pasta application/vendor/ não foi commitada.
• Entrada do usuário é validada e a saída é escapada nas views. (a exceção são três páginas de erro do framework, sem escaper por decisão registrada no baseline — ver a Descrição)
• Consultas ao banco usam Query Builder ou query bindings (sem concatenação de SQL).

Banco de dados

Nenhuma mudança de schema — nenhuma migration, nenhum banco.sql. As escritas dos novos testes ficam em logs e a TransactsDatabase desfaz cada caso.