Pedidos

O rastro: um step por linha

Os cinco status sao planejado → execucao → executado → testado → validado, e eles nao tem todos a mesma natureza. executado, testado e validado saem de um artefato no disco — evidencia. planejado e execucao saem da palavra do ESTADO do bloco — declaracao: nenhum arquivo sabe dizer "tem alguem trabalhando agora". Passe o mouse sobre o status para ver qual das duas decidiu aquela linha, e qual arquivo ou palavra foi.

validado nunca e carimbado por quem construiu: ele vem do veredito.md escrito pelo bloco validacao/01-conferir da crew, e o proprio bloco de validacao para em executado, que e o que ele fez. Pela mesma razao, testado nao alcanca o bloco teste/01-conferir.

agente e declarado, nao deduzido. O agente se apresenta com carimbar-estado.ps1 -Agente <nome>, que grava <bloco>/AGENTE. Quem nao se apresentou aparece como (nao declarado) e continua na lista: deduzir o nome a partir da pasta que o step ocupa seria medir a propriedade vizinha da que o operador pediu.

As crews que este ticket gerou

ligacao diz por onde a crew foi achada: crews.json (a etapa de criacao declarou), ORIGEM (a crew diz de onde veio) ou ambas. Crews criadas antes do arquivo ORIGEM existir aparecem so pelo crews.json -- e isso e a idade delas, nao um defeito. Uma crew declarada cuja pasta sumiu do disco continua na lista, com o estado vazio.

A linha do tempo

Duas fontes, e elas medem coisas diferentes. Os carimbos das etapas saem da primeira linha do ESTADO de cada bloco. O historico do par sai do ESTADO.log, que registra trocas da palavra de estado da caixinha -- ignicoes, reconciliacoes e substituicoes. Nenhuma das duas e a lista de acoes que o agente executou dentro do turno: isso mora nos .jsonl de sessao e nao e lido aqui.

Os blocos por papel

A contagem vem somada do leitor, na maquina da frota, e nao e refeita aqui. Ela conta os blocos que o crews.json declarou para cada crew deste ticket.