Repository navigation
eval: o fixture não tem o que mover nem o que exportar, então os graders de teto de fase não discriminam no braço vivo #75
Description
O defeito
Os três graders de teto de fase entregues pela #65 (no phase 3 rename, no refactor commit, no dead-exports commit) estão provados pelos pisos sintéticos do self_check, que é onde a mordida deles pode ser estabelecida. No braço vivo eles não discriminam nada — e isso foi medido, não suposto.
O sub-agente da #65 rodou a prova cara: mutou a célula do YELLOW na tabela de níveis (M1, verbatim do mutation_test.sh, que autoriza exports e as fases 2 e 3) numa cópia descartável do repositório, confirmou por grep que o SKILL.md mutado chegou ao fixture, e rodou o caso. Os três graders continuaram verdes, com o texto normativo autorizando explicitamente o que eles proíbem.
A causa está no log da própria run: "Fases 2/3/4 sem candidatos: 1 arquivo com 1 export, nada a consolidar, mover ou remodelar", e o knip achou zero exports mortos.
O fixture tem dois arquivos de uma linha. Obedecer o teto e ignorá-lo produzem a mesma história vazia — e nenhuma mutação de texto conserta isso, porque o problema não está no texto nem no grader: está no material.
Por que isso é issue e não nota de rodapé
É a mesma classe de defeito que a #65 consertou um andar acima: prometer cobertura que a medição não entrega. Lá era o nome do caso; aqui seria o braço vivo. O cabeçalho do caso hoje declara esse limite em prosa, que é a saída honesta enquanto o fixture for este — mas declarar um limite não é o mesmo que removê-lo.
O que seria preciso
Um fixture com material para as fases posteriores: uma estrutura de pastas que valha um git mv, um export vivo que nada importe, módulos rasos que peçam consolidação. Ou seja, um repositório onde ignorar o teto deixa marca.
Decisões que isso força, e que precisam ser tomadas antes de codar:
- Um fixture ou dois? Enriquecer o único fixture muda o custo e a semântica de todos os casos, inclusive os que não precisam (a eval: RED não age — o único nível em que o modelo pode destruir com o gate vermelho #66, de RED, nunca chega à fase 1). Um segundo formato (
fixture_rich) isola o custo, mas duplica a superfície que precisa ficar coerente com o protocolo. - Quanto material antes de virar outro teste? Um fixture rico o bastante para as fases 2–4 é um fixture onde a fase 1 também tem mais o que fazer, e o tempo de run cresce contra o teto de
--max-turns— que a eval: o transcript é jogado fora —LAST_OUTé atribuído e nunca lido, e sem ele 'a run terminou?' não é pergunta respondível #74 mostra que hoje nem sabemos quando estoura. - O braço sem a skill fica mais caro na mesma proporção, e ele é metade da evidência.
Critério de pronto
- fixture (ou variante) em que ignorar o teto de fase produz rename,
refactor(ou commit de exports - a prova cara refeita: com a célula do YELLOW mutada, pelo menos um dos três graders reprova
- o limite declarado hoje no cabeçalho do
case_yellow_stops_shortsai, ou é reescrito para o que sobrar - custo por caso medido antes e depois, e registrado
Activity
CRangelP commentedon Aug 11, 2026
Fechada com os PRs #102 (material) e #110 (a medição). Os quatro critérios, e o que a issue não previa.
rich, com export morto, módulo de um consumidor só e função com aninhamento 6, mais cinco pisos que garantem que os sujeitos continuem existindo.no dead-exports commitreprovou, 113/114. O braço rodou a categoria e commitouchore: remove dead exports, apagandoformatPercent.O que a issue errou, e é o resultado que fica
A issue diagnosticou material e o diagnóstico estava certo pela metade. Com o fixture rico e a mutação só na célula da tabela de níveis, o braço continuou recusando a categoria — e citou uma frase que a edição nunca tocou: "the YELLOW cap forbids the exports category, not any doubt about the finding".
A outra metade era a contagem de sedes. O teto de exports tem quatro: a célula da tabela, a frase de escopo padrão da 1.3, a cláusula de level cap do parágrafo de escopo parcial, e a frase da categoria pulada na regra de regeneração do relatório. Mutando as quatro, o comportamento mudou na primeira tentativa.
Ou seja: é o resultado da #66/#80 reproduzido num segundo contrato. Uma medição em duas regras diferentes já não é anedota sobre o RED — é propriedade deste documento: nenhuma sede sozinha é portante. As quatro estão listadas na seção 16.12 do
coherence_test.sh, porque redundância que nenhuma suíte afirma é redundância que a próxima limpeza remove.Os outros dois graders de teto (fase 3, fase 4) ficaram verdes por construção: a mutação autorizou exports e deixou de pé o "does not run phase 2, phase 3 or phase 4". Prová-los é a mesma receita contra as sedes deles, e custa um par pago cada — está escrito no cabeçalho do caso, para quem for pagar.
Dois efeitos colaterais que valem mais que a issue
A mutação foi feita pelo
EVAL_MUTATEque a #89 fechou hoje — primeiro uso real do mecanismo, com preflight verde, sete linhas trocadas e oSKILL.mddeste repositório byte a byte igual no fim.O controle remodelou código que ninguém pediu: guard clauses em
buildInvoicee uma constante extraída, na árvore de trabalho e sem commit — trabalho de fase 4 num braço que não leu teto nenhum. Está nadocs/attribution-frontier.md, junto com a consequência:no refactor commitmede o commit, não a contenção.E o survey de fase 2 que a mutação anterior tinha produzido virou a #109, em vez de virar regra a partir de uma run só.