Skip to content

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

@CRangelP

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:

  1. 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.
  2. 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.
  3. 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_short sai, ou é reescrito para o que sobrar
  • custo por caso medido antes e depois, e registrado

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions