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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

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