[diegosouzapw]

O quê

Fecha o último chatCore leaf que faltava no Stryker mutate: semanticCache.ts. Com isso, 15/15 leaves do chatCore/ passam a ser mutados na noturna.

Por quê estava de fora

O semanticCache.ts foi excluído do mutate no #4222 porque o bloco de cache-HIT (o grosso da lógica) não tinha teste — só os caminhos guard-false / cache-MISS eram exercitados, então a maioria dos mutantes do HIT sobreviveria (sem clean kill).

Como o fixture funciona (sem mock.module)

mock.module não está disponível sob o tap-runner do Stryker. O teste então semeia o cache real via setCachedResponse (o store em-memória que getCachedResponse checa primeiro) sob a assinatura exata que checkSemanticCache reconstrói (generateSignature com os mesmos model/messages/temperature/top_p/apiKeyId). Isso dispara o branch de HIT ponta-a-ponta.

3 testes de HIT novos:

• não-streaming → application/json, body = JSON do cached, headers X-OmniRoute-Cache: HIT + Cache-Hit: true, e os side-effects (persistAttemptLogs com status:200/cacheSource:"semantic", logConvertedResponse(cached), log.debug).
• streaming (stream:true) → text/event-stream, body SSE com frames data: + terminador [DONE].
• sem usage → cachedUsage resolve undefined → cachedCost = 0 → header responseCost no sentinel zero.

Matam os mutantes do bloco HIT (status / "semantic" / "HIT" / os ternários stream+content-type / o fallback de custo / as chamadas de side-effect).

Mudanças

• tests/unit/chatcore-semantic-cache.test.ts — +3 testes de HIT (os 5 guard/miss originais permanecem). 8/8 verde local.
• stryker.conf.json — semanticCache.ts → mutate (30→31), chatcore-semantic-cache.test.ts → tap.testFiles (137→138), comentário _mutate_godfiles_excluded_comment atualizado (15/15).
• .github/workflows/nightly-mutation.yml — semanticCache.ts → batch i (3 arquivos); comentário do header atualizado.

Notas

• Config/test-only — zero código de produção. Mutation testing segue advisory (noturna, continue-on-error).
• Run step do workflow injection-safe intacto (BATCH_MUTATE env → --mutate "$BATCH_MUTATE").
• União de todos os batches do matrix == conjunto mutate do conf (verificado).

QG v2 Fase 9 T5 — Fase 3 follow-up. Encerra a re-habilitação do mutation testing pela via unit-testável: mutate 6→31, 9 batches, 15/15 chatCore leaves + todos os combo leaves.

🤖 Generated with Claude Code

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[diegosouzapw]

Adendo: budget headroom para os 2 batches grandes (a/b)

Diagnóstico das runs do nightly-mutation: nenhuma jamais completou — todas cancelled. A causa não é concurrency (não há esse bloco), é o timeout-minutes: 180. Inspeção da run 27740840644:

• batch c (2 módulos) → SUCCESS em ~2h, mutation.json com killedBy 100% populado (atribuição por-teste funciona).
• batch a (auth) e batch b (accountFallback) → cancelled exatamente em 3h00 = bateram o cap de 180min.

Um cold run que nunca completa nunca escreve stryker-incremental.json → esses 2 batches ficam presos para sempre.

Fix (commit 2a3eca2c0): timeout-minutes por-batch via ${{ matrix.batch.timeout || 180 }}; a/b sobem para 350min (teto do runner é 360) para o 1º cold run completar e semear o incremental; as noturnas seguintes a 180min só re-testam mutantes alterados e cabem. Batches pequenos mantêm 180min. Run step segue injection-safe.

Run de validação forçada agora (27801579662) na config completa (31 módulos, 15/15 chatCore).