Falha encadeada silenciosa depois da suíte vazia é lida como cap

[CRangelP]

Achado numa revisão do PR #33.

"test": "runner; comando-que-falha-sem-imprimir" com rc=1: a linha de suíte
vazia casa, nada é impresso depois, e o gate reporta no test files found (exit 1) como cap.

O comentário no código promete mais do que entrega — ele diz que "qualquer
comando encadeado que falhou permanece RED", e um comando que falha calado
não permanece.

Não é bloqueante: o cap marca uncounted=1, então o run nunca chega a GREEN;
o pior caso é YELLOW onde RED seria mais honesto. Mas o comentário deveria
descrever a regra real, ou a regra deveria alcançar o caso.

Relacionado: o cap ganhou em #33 (commit 9a2b459) o caminho do código inline
(exiting with code N), que é ortogonal a este — aqui não há cauda nenhuma
para julgar.

[CRangelP]

Fechada pelo PR #47, mergeado em main (6675cf6).

A issue oferecia uma escolha — "ou o comentário descreve a regra real, ou a regra alcança o
caso". A resposta foi as duas, porque só metade do caso é decidível.

A metade decidível não precisa de cauda

"test": "runner; comando-que-falha-calado" não imprime nada depois, então toda guarda baseada
em cauda é cega nele por construção. Mas quando o runner anuncia o próprio código e o
processo sai com outro, algo depois dele definiu o status — e isso se decide em dois números.

caso	antes	agora
anuncia code 0, sai 1	cap	RED
vários códigos, nenhum bate com o exit	cap	RED
suíte vazia legítima, indecidível, sem código anunciado	cap	cap

A metade que não dá para decidir, agora dita em voz alta

Se o runner anuncia code 1 e o comando calado também falha com 1, os bytes são idênticos aos
de uma suíte legitimamente vazia. Esses capam por falta de evidência na saída, não por
perdão — e o cap marca uncounted, então o run nunca alcança GREEN.

E o limite é uma escolha sobre qual evidência é segura, não ausência de evidência: o gate lê
o package.json, e em A; B o status é o de B por definição, então o texto de scripts.test
prova que houve comando encadeado. Não é lido de propósito, porque parsear shell e errar cobra
RED de um repo apenas vazio — o erro mais caro que este código comete. Isso está no comentário
agora, que era o que a issue pedia.

Dois falsos RED evitados no caminho

Ambos achados durante a correção, não depois:

• comparar os códigos como string faria code 01 discordar de um exit 1; deixar o shell
  comparar sozinho leria 010 como octal 8;
• parar no primeiro código anunciado quebraria monorepo, onde a linha que explica o exit
  pode ser a última.

Os quatro comportamentos e os dois falsos positivos viraram fixture, para que o limite seja
documentação executável.

140/140 gate · 42/42 guarda · 5/5 rollback · 35/35 métricas · 296/296 invariantes

Versão 0.2.2. Fecha o milestone.