Changelog da CLI do Latchkey

Cada entrada lista o que uma versão da CLI do Latchkey (@latchkeydev/cli e os binários latchkey independentes) mudou para você e seus agentes de codificação, datada do dia em que foi publicada, em UTC. Execute jobs avulsos pela CLI descreve os comandos como eles funcionam hoje.

0.17.0#

Lançada em 2026-11-13.

Adicionado#

• latchkey workflows rerun <run-id> --repository <owner/name> reexecuta os jobs de uma execução do Latchkey CI que não passaram, com todo job que precisa de um deles, como uma nova tentativa da mesma execução no mesmo commit, e imprime a tentativa e a página da execução. Os outros jobs que passaram não são rodados nem cobrados de novo, e o comando não espera a tentativa. Um job vinculado a um ambiente que exige aprovação espera por ela, a menos que fique retido em uma execução de ensaio ou em um pipeline em ensaio, ou que o ambiente dele não aceite a execução, e o comando nomeia esses ambientes no stderr, até onde o Latchkey ainda consegue lê-los de uma tentativa anterior. Com --output json ele imprime um objeto com run_id, attempt, allocated, run_url e waits_for_approval, e code RERUN_NEEDS_APPROVAL com a sua frase em message quando essa lista nomeia algum. Uma recusa imprime a sua frase no stderr e sai com 1. Ele precisa de uma chave com runs:control.
• latchkey workflows cancel <run-id> --repository <owner/name> cancela, na tentativa atual de uma execução do Latchkey CI, todo job que não terminou, pelo único caminho de cancelamento que latchkey cancel usa, e os jobs que ele ainda não tinha criado nunca são criados. Ele imprime a tentativa e a página da execução e, com --output json, um objeto com run_id, attempt, cancel_requested, not_created e run_url. Uma recusa imprime a sua frase no stderr e sai com 1. Ele precisa de uma chave com runs:control.
• latchkey run e latchkey preflight agora dizem no stderr quando o lote em que um job é iniciado, por --batch ou LATCHKEY_BATCH, não tem orçamento, com o comando que define um (latchkey budget set <batch> <dollars>), e o job começa mesmo assim. Nada é dito quando o Latchkey não conseguiu ler o orçamento ou o gasto do lote, já que o lote ainda pode ter um orçamento, e latchkey preflight --batch-budget nunca diz isso. Com --output json, latchkey run não imprime nenhuma linha: o evento created traz o novo batch_budget_status, que diz set, none ou unread, e é null quando o job não tem lote.

Alterado#

• A skill incluída no pacote agora cobre latchkey workflows rerun e latchkey workflows cancel, e as ferramentas MCP rerun_run e cancel_run, onde dizia que nenhum comando latchkey recebe o id de uma execução e que nenhuma chave pode cancelar uma execução inteira.
• A skill incluída no pacote agora diz que uma entrada de heals abaixo do stage 3 com category flaky_test é a reexecução de teste instável do autorreparo, que rodou de novo, sem mudança, o passo que falhou, então o seu outcome fixed significa que a reexecução passou, não que algo foi corrigido.

Corrigido#

• latchkey workflows --help e a skill incluída no pacote agora dizem que um job que latchkey workflows run inicia e que está vinculado a um ambiente que exige aprovação espera por ela, a menos que fique retido em uma execução de ensaio ou em um pipeline em ensaio, ou que o ambiente dele não aceite a execução, onde tratavam a execução de ensaio como a única exceção.

0.16.0#

Lançada em 2026-11-11.

Adicionado#

• latchkey preflight --workflow <file> --repository <owner/name> roda os jobs de um arquivo de workflow, como o Latchkey o compila, na sua árvore de trabalho como ela está agora, antes de você fazer o commit ou o push. O repositório é empacotado inteiro, a partir do nível mais alto, pelas regras de latchkey run, e a mudança é medida contra a base de merge entre HEAD e o branch padrão que origin/HEAD indica, como este clone o buscou por último. Antes de qualquer runner iniciar, cada job é julgado: ele roda como está escrito, roda o seu dry run, é pulado pela própria condição ou por um job de que precisa, falha antes de começar ou não roda, com um motivo, como um job que lê um segredo, já que um preflight não recebe nenhum. Um preflight não escreve nenhum check, não abre pull request, não inicia autorreparo e não salva nenhuma entrada de cache. Ele sai com 0 só quando nenhum job falhou, nenhum ficou sem rodar e algum job rodou, e com 195 só quando deixou um job sem rodar, ou não rodou nenhum, e todo job que rodou passou ou foi pulado pela própria condição ou por um job de que precisa; latchkey preflight --help lista o resto. Com --output json ele imprime um objeto quando a execução termina. Quando o git não consegue dizer qual é a mudança, ele é recusado com CLI_GIT_UNREADABLE e nada é enviado. Ele precisa de uma chave com jobs:run e de um repositório conectado ao Latchkey CI.

Alterado#

• latchkey wait agora pode imprimir que o autorreparo judged step 3's failure flaky and re-ran the step unchanged, e depois it passed, ou que ele re-ran step 3 unchanged in case its failure was flaky, e depois the re-run did not make the step pass, onde dizia que o autorreparo corrigiu o passo ou não conseguiu corrigi-lo, e a linha Self-heal de latchkey status pode dizer o mesmo.
• A skill incluída no pacote agora cobre latchkey preflight, incluindo a execução que ele devolve, que latchkey workflows list nunca lista, e diz que o check próprio de um job, como Latchkey / ci.yml / test, pode aparecer na fila ou em andamento enquanto o job espera ou roda, onde dizia que o Latchkey não escreve nenhum check pendente.
• Uma chave que começa com lk_dev_ é do ambiente de desenvolvimento do Latchkey e não é mais enviada para a API de produção (api.latchkey.dev ou latchkey.dev): o comando para antes de enviar qualquer coisa e sai com 1 e CLI_API_KEY_WRONG_ENVIRONMENT. Uma chave que não começa nem com lk_live_ nem com lk_dev_ continua apenas gerando um aviso.

Corrigido#

• Quando latchkey run lê os arquivos que o git rastreia, ele agora define o monitor do sistema de arquivos do git como vazio, e não como false: um git anterior à 2.36 roda false como um programa encontrado no PATH, onde uma entrada relativa pode encontrar um no repositório que está sendo empacotado. Um diretório chamado git no PATH não interrompe mais essa leitura, e no Windows toda variável cujo nome começa com GIT_ ou LATCHKEY_, em maiúsculas ou minúsculas, fica fora do ambiente do git.
• O README e a skill incluída no pacote agora dão o teto de tamanho comprimido como 200 MiB, o limite que a CLI sempre manteve, onde diziam 200 MB.
• A skill incluída no pacote agora diz que um job retido no grupo concurrency: do seu arquivo de workflow (JOB_HELD_IN_GROUP) pode terminar sem começar se uma execução mais nova entrar no grupo antes, onde dizia que ele termina sem começar: a execução mais nova cancelada antes de o Latchkey encerrar o job retido o deixa esperando.
• Uma chave de API vinda de --token, de LATCHKEY_TOKEN ou da configuração salva agora tem os espaços, tabulações e quebras de linha ao redor removidos antes de ser verificada e enviada, e latchkey login --token a salva sem eles, ou para com Empty API key. e sai com 2 quando a chave é só espaço em branco, onde saía com 1. Uma chave que termina em quebra de linha, como um LATCHKEY_TOKEN definido com uma quebra de linha no final, não faz mais o comando parar com invalid authorization header, e uma chave lk_live_ com espaço em branco antes dela não gera mais o aviso de que não começa com lk_live_.

0.15.0#

Lançada em 2026-11-09.

Adicionado#

• latchkey workflows list --repository <owner/name>, com --commit <sha> ou --pr <number>, lista as execuções do Latchkey CI de um commit, indicado pelo id completo, ou de um pull request nos últimos 90 dias, da mais nova para a mais antiga. Com --output json ela imprime um objeto com repository, runs e truncated, e cada execução é o objeto que a ferramenta MCP get_run_status devolve. Com mais de 50 execuções ela sai com 1 e LIST_TRUNCATED, a menos que --allow-truncated pegue as 50 mais novas. Ela precisa de uma chave com jobs:read.
• latchkey wait --commit <sha> e latchkey wait --pr <number>, com --repository <owner/name>, esperam por execuções do Latchkey CI em vez de jobs: as execuções de um commit, indicado pelo id completo, ou as execuções de um pull request no commit mais novo dele. Quando as execuções terminam, ele imprime uma tabela delas e sai com 0 se cada uma teve sucesso ou foi pulada, e com 1 caso contrário, e com --output json imprime um evento run_ended por execução e depois um evento summary. Ele sai com 194 e RUN_NOT_EXPECTED quando o repositório não está conectado ao Latchkey CI, ou quando toda execução que ele acompanha terminou sem nenhum job porque nenhum arquivo de workflow correspondeu, e com 197 e RUN_WAIT_LIMIT_REACHED quando a última consulta antes de desistir atingiu o limite de esperas que o Latchkey mantém ao mesmo tempo para um workspace.

Alterado#

• Antes de um comando enviar a chave, ele imprime Latchkey API: <host> no stderr, com o host para onde a chave vai, uma vez por processo e também no modo json, para que uma chave apontada para o ambiente errado apareça antes de qualquer resposta. Em latchkey run e latchkey watch, --quiet omite essa linha.
• A skill incluída no pacote agora explica como encontrar as execuções de um commit ou de um pull request com latchkey workflows list e latchkey wait --commit ou --pr, e com as ferramentas MCP list_runs e wait_run.
• latchkey watch --help agora traz a exceção que a skill incluída no pacote já trazia: no GitHub Actions, a única nova execução de um teste com falha que o Latchkey permite enquanto o workflow tem uma descoberta de teste instável em aberto não é escalada quando o Latchkey conseguiu ler os testes com falha no relatório do executor de testes e a nova execução falhou da mesma forma, então a execução aparece uma vez só, com o seu único id.

0.14.0#

Lançada em 2026-11-06.

Alterado#

• latchkey migrate plan agora imprime um pipeline que já está em ensaio como On trial, onde imprimia Stays, e a ajuda não diz mais que latchkey migrate apply exige o repositório em modo consultivo: ele exige o repositório conectado ao Latchkey CI. O Latchkey abre essa aplicação para qualquer versão da CLI. A lista de recusas de migrate apply na skill incluída no pacote agora cita um plano que move um pipeline que já está em ensaio, no lugar de um repositório fora do modo consultivo.
• latchkey watch --help e a skill incluída no pacote agora dizem que latchkey watch consulta as falhas que o autorreparo registrou mas não corrigiu e entrega a primeira falha nova de cada job (de cada execução, no Latchkey on GH), e que uma falha cujo passo o autorreparo se recusou a ler não traz causa raiz nem arquivo com falha. O prompt que ele entrega ao seu agente agora diz que o autorreparo registrou a falha mas não a corrigiu, e que get_failure_bundle devolve o que o Latchkey guardou dela. Só as palavras mudaram: watch escolhe as falhas que entrega pela mesma regra que a 0.13.0, a partir da lista que o Latchkey devolve a qualquer versão da CLI.

0.13.0#

Lançada em 2026-11-04.

Adicionado#

• latchkey list --state active lista só os jobs que ainda não terminaram: todo job na fila, em provisionamento ou em execução, até 100, do mais novo para o mais antigo, por mais jobs mais novos que já tenham terminado. --batch restringe a lista, e --before e --limit são recusados, já que ela é lida inteira, não uma página por vez. Com --output json ela imprime jobs e truncated, true quando mais de 100 jobs ainda não tinham terminado, e em texto uma linha no stderr avisa isso. Uma API do Latchkey que não lê os jobs que ainda não terminaram responderia com jobs em todos os estados, então ela é recusada com CLI_LIST_FILTER_UNSUPPORTED e nada é listado. --state all, o padrão, lista todos os jobs como antes.

Alterado#

• A skill incluída no pacote agora explica como ler o que ainda não terminou com latchkey list --state active, e a linha de CLI_LIST_FILTER_UNSUPPORTED também cita --state active.

0.12.0#

Lançada em 2026-11-04.

Alterado#

• Quando latchkey run recusa um diretório vazio, agora diz o que fazer: rodar a partir do diretório do seu projeto ou passar --no-context para um comando que não precisa de arquivos. A linha de CLI_CONTEXT_EMPTY na skill incluída no pacote também cita essa flag.
• Com --output json, latchkey list, latchkey batch show e latchkey status sempre trazem run_id, a execução do Latchkey CI à qual o job pertence, e served_by, como ele conseguiu o runner (warm, parked ou cold_start), cada um null quando o Latchkey não envia um valor. Uma CLI a partir da 0.4.0 já imprime os dois quando o Latchkey os envia, e a saída em texto não mudou.
• A skill incluída no pacote agora diz para dividir uma suíte pelo próprio script test do pacote (npm test -- --shard=2/4), para que todo shard rode os passos de pretest do pacote, como o CI os roda. Ela também cobre a migração para o Latchkey CI: uma execução lê só os segredos definidos no Latchkey, nunca um segredo do GitHub com o mesmo nome, então um owner ou admin os transfere antes de o pull request de troca ser mesclado, e depois que ele é mesclado um pipeline que migrou é lido nos checks do Latchkey do commit, em get_run_status ou em latchkey list, porque o GitHub Actions não o roda mais.
• A skill incluída no pacote agora cita merge_group entre os eventos em que um arquivo de workflow roda: cada grupo que uma fila de merge cria, comparado pela branch de destino do grupo.

0.11.0#

Lançada em 2026-11-03.

Alterado#

• latchkey migrate plan agora diz que um job que migra e está vinculado a um ambiente espera a aprovação de um owner ou admin quando o pipeline dele passa a rodar como real; antes dizia que esperava em uma execução real. Em um repositório no Latchkey CI, um pipeline fica em ensaio, mesmo dentro de uma execução real, enquanto o arquivo do GitHub Actions que ele substitui ainda está no commit.
• A skill incluída no pacote agora diz que failure_explanation nomeia o primeiro passo que falhou, e o código de saída desse passo quando ele tem um, em um job de arquivo de workflow que falhou com failure_reason null, e que uma saída que a CLI não consegue escrever nunca muda o código de saída dela. Ela também cobre pipelines em ensaio dentro de uma execução real: o que advisory: faz nos jobs deles, o failure_explanation que começa com Held on trial: de um job retido, list_trial_verdicts nomeando em workflow_path o pipeline em ensaio que cada entrada compara, e get_run_status dizendo em trial por que alguns pipelines de uma execução rodaram em ensaio.

Corrigido#

• Um disco cheio sob um stdout ou stderr redirecionado não faz mais a CLI sair com 1, o que se lê como um job que falhou: quando um dos dois fluxos não pode ser escrito, a CLI sai com o código que teria dado. Ela descarta o resto do stdout e, a menos que quem lia tenha ido embora (| head), avisa isso uma vez no stderr, e descarta sem avisar o que não consegue escrever no stderr. Um log que ela não conseguiu escrever continua no job, e latchkey logs <id> o lê de novo.

0.10.0#

Lançada em 2026-11-02.

Adicionado#

• latchkey workflows run <workflow> --repository <owner/name> inicia uma execução de um arquivo de workflow do Latchkey CI que declara on: workflow_dispatch, no branch padrão do repositório ou no branch ou tag que --ref indicar, com as entradas do arquivo passadas como --input <name=value>. Ele imprime um link para a página da execução sem esperar a execução terminar, e rodá-lo de novo inicia uma segunda execução, cobrada à parte. A chave precisa do escopo workflows:run. Uma entrada fica registrada na execução e aparece na página dela, e o log de um job não a esconde, então nunca coloque um token ou uma senha em uma entrada.
• latchkey budget set <batch> <dollars> --max-concurrent <n> limita quantos jobs de um lote rodam ao mesmo tempo, com um número inteiro de 1 a 1000. Os demais esperam na fila e começam quando o lote tem espaço. Uma chave de API pode definir o primeiro limite de um lote ou reduzi-lo, nunca aumentá-lo nem removê-lo, e latchkey budget show mostra o limite.

Alterado#

• latchkey status mostra uma linha Self-heal para cada tentativa de autorreparo no job que corrigiu uma falha ou não conseguiu corrigi-la, e latchkey run e latchkey wait mostram cada uma em uma linha depois do resultado do job. Quando o agente do autorreparo relatou uma correção mas o job terminou sem passar, a linha diz que a correção foi relatada, não feita. Com --output json, em run o evento complete e em wait os eventos ended e summary trazem a lista heals do job como status a imprime.
• A skill incluída no pacote agora cobre como iniciar um arquivo de workflow com latchkey workflows run ou com a ferramenta MCP run_workflow, como dosar uma rajada de jobs com o limite do lote dela, por que um job de lote pode esperar atrás de jobs do Latchkey CI perto do limite do workspace, como ler por MCP os registros de autorreparo e os veredictos das execuções de ensaio (list_heals, get_heal e list_trial_verdicts), como dividir uma suíte de testes entre as pernas de uma matriz e o que o autorreparo lê de uma árvore de trabalho enviada.
• A página inicial do pacote no npm agora é a página de documentação da CLI do Latchkey, e o README dele traz um link para este changelog.

0.9.0#

Lançada em 2026-10-28.

Adicionado#

• latchkey oidc request-token --audience <audience> obtém um token de identidade de curta duração para a sua nuvem de dentro de um job de uma execução do Latchkey CI. Ele imprime o token ou, com --out <file>, o grava em um arquivo que só o dono do arquivo pode ler. Como o latchkey cache, ele fala com o runner do job e não precisa de chave de API.
• latchkey validate <file> verifica um arquivo de workflow do jeito que o Latchkey o compila para uma execução, sem iniciar nada. Um arquivo recusado imprime a primeira recusa com a linha dela; um arquivo que compila imprime os jobs dele e o máximo que uma execução do arquivo pode custar a preços de tabela. Ele sai com 0 quando o arquivo compila e com 1 quando é recusado.

Alterado#

• Os binários independentes agora embutem o Node 24, então os binários para macOS exigem o macOS 13.5 ou mais recente. Em um macOS mais antigo, instale com npm.
• latchkey environments list ganha a coluna Approval, que diz se os jobs de um ambiente esperam que um owner ou admin os aprove.
• latchkey migrate plan diz quando um job que migra e está vinculado a um ambiente vai esperar uma aprovação em uma execução real e, para um pipeline que fica no GitHub Actions mas roda depois de um que migra, se ele para de rodar ou passa a rodar menos vezes quando o pull request de troca é mesclado.
• Um lote cujo nome é apenas . ou .. é recusado por todo comando que recebe um nome de lote (exit 2).

Corrigido#

• Uma variável de --env chamada __proto__ agora é enviada com o job em vez de ser descartada.

0.8.0#

Lançada em 2026-10-27.

Alterado#

• Um nome de lote não pode mais conter / nem %. latchkey run, latchkey list e latchkey wait agora recusam um nome assim, inclusive um definido em LATCHKEY_BATCH, antes de chegar ao Latchkey (exit 2), como latchkey budget e latchkey batch show já faziam.

0.7.0#

Lançada em 2026-10-26.

Alterado#

• latchkey migrate plan marca um passo cujo comando de dry run o plano recusou: a linha "Needs a person" dele dá o motivo, e o item fica em aberto até você responder com um comando que o arquivo de workflow consiga rodar.
• O arquivo de respostas de latchkey migrate plan --answers <file> pode dar uma resposta dry_run com um dry_run_command, que o plano escreve como um passo de execução de ensaio no lugar do passo respondido.
• A skill incluída no pacote agora cobre as execuções de ensaio (advisory: em jobs e passos), os grupos concurrency: em arquivos de workflow e os passos latchkey/artifact-upload e latchkey/artifact-download.

0.6.0#

Lançada em 2026-10-24.

Adicionado#

• latchkey wait espera até que os jobs que você nomear, ou todos os jobs de um lote com --batch <name>, terminem, imprimindo o desfecho de cada job quando ele termina e depois uma tabela com estado, código de saída, tempo de execução, custo e lote. Ele sai com 0 só quando todos os jobs saíram com 0, e o Ctrl-C interrompe a espera, nunca um job.
• latchkey batch show <name> mostra um lote: o orçamento dele, quanto os jobs dele custaram a preços de tabela, os jobs dele por estado e por que os jobs dele na fila esperam. latchkey budget show <batch> imprime só o orçamento e o gasto.
• latchkey environments list --repository <owner/name> lista as branches que cada ambiente de um repositório aceita.
• latchkey list aceita --batch <name> para os jobs de um lote e --before <value> para voltar a páginas mais antigas, mostra a coluna COST, e latchkey status mostra o custo de um job que terminou.
• Quando há uma CLI mais nova, um comando que imprime texto avisa no stderr, no máximo uma vez por dia e nunca no CI. Defina LATCHKEY_NO_UPDATE_NOTICE para desligar esse aviso.

Alterado#

• Dentro de uma árvore de trabalho do git, latchkey run empacota todo arquivo que o git rastreia, mesmo um que corresponde a um padrão do .gitignore, do jeito que um clone novo o teria. A lista de bloqueio de credenciais, --exclude e .latchkeyignore continuam valendo, e --no-git-index empacota só pelos arquivos .gitignore.
• Toda recusa traz um código. Com --output json, um comando recusado imprime um único objeto com o código da recusa, e a skill incluída no pacote lista todos os códigos.
• latchkey run recusa um bash -c ou sh -c no início (exit 2), já que esse shell executaria só a primeira palavra do script. Passe o script como um único argumento entre aspas.

0.5.0#

Lançada em 2026-10-24.

Adicionado#

• latchkey artifact upload e latchkey artifact download passam arquivos entre os jobs de uma execução do Latchkey CI. Um envio ou download que falha sai com 1, então o passo falha, e um envio deixa de fora arquivos que começam com ponto, como .env, a menos que você passe --include-hidden-files.
• latchkey migrate plan <owner/name> lê os arquivos de workflow do GitHub Actions de um repositório e imprime o plano para a migração dele para o Latchkey CI, com cada item que precisa da sua resposta. latchkey migrate apply abre o único pull request que adiciona os arquivos de workflow do Latchkey CI, e latchkey migrate status mostra a situação dele.
• latchkey steps lista os passos do Latchkey que um arquivo de workflow pode nomear com uses: latchkey/<name>@<version>, com as entradas deles e os valores padrão.

Alterado#

• Um job cuja execução um owner ou admin rejeitou para o ambiente dele sai com 130 no latchkey run e no latchkey logs --follow, como uma parada, e não como uma falha a corrigir.

0.4.1#

Lançada em 2026-10-19.

Corrigido#

• O texto de ajuda, o README e a skill incluída no pacote agora correspondem ao comportamento da 0.4.0: a lista de códigos de saída traz skipped (exit 1), os logs ficam legíveis por 7 dias a partir do início do job, e latchkey cache só funciona dentro de um job do Latchkey CI ou de um job de latchkey run.
• A ajuda de latchkey budget set diz que uma chave de API pode definir o primeiro orçamento de um lote até o limite de gastos do workspace, e que um owner ou admin aumenta um orçamento na página Billing.

0.4.0#

Lançada em 2026-10-19.

Adicionado#

• latchkey run --context <dir> empacota outro diretório em vez do atual, e --exclude <pattern> retém caminhos sem editar nenhum arquivo. Nenhum padrão de --exclude pode enviar um arquivo que a lista de bloqueio de credenciais retém.
• latchkey run --budget <dollars> interrompe um job assim que ele custar esse valor (exit 3), e --batch <name> ou LATCHKEY_BATCH coloca jobs em um lote.
• latchkey budget set <batch> <dollars> limita um lote. Um latchkey run recusado no orçamento do lote dele sai com 193 e não cria nenhum job.
• latchkey cache restore e latchkey cache save restauram e salvam uma entrada de cache de dentro de um job. Nenhuma condição do cache faz o job falhar.
• latchkey secrets set <name> define um segredo que um passo de workflow pode ler, para o workspace ou para um repositório. O valor vem de um pipe ou de um prompt oculto, nunca da linha de comando.

Alterado#

• latchkey run imprime um link para a página de cada job no dashboard, e latchkey watch liga uma falha à página da execução dela no Latchkey.
• latchkey status mostra mais quando o Latchkey envia: os jobs em execução e na fila em relação ao limite do workspace, os jobs à frente de um job na fila e por que ele espera, o custo até agora, o lote, a chave e o orçamento do job, quando ele escreveu saída pela última vez e o que o encerrou. latchkey list ganha as colunas BATCH e KEY.
• --timeout aceita até 3 horas, e os logs de um job ficam legíveis por 7 dias a partir do início dele.
• latchkey run --detach sai com o código mapeado do job quando o envio já encerrou o job, um job skipped sai com 1, e todo evento de --output json traz at.

Corrigido#

• Os caracteres de controle, de direção do texto e de formatação invisíveis são removidos do texto do Latchkey que chega ao seu terminal, e um motivo de falha que o próprio job relatou aparece como palavras do próprio job.

0.3.0#

Lançada em 2026-08-15.

Adicionado#

• latchkey list lista os jobs recentes do seu workspace, do mais novo para o mais antigo, incluindo os que ainda estão em execução, para que você recupere um id de job que sumiu do terminal.

Alterado#

• latchkey watch também informa os jobs de latchkey run que o autorreparo registrou mas não corrigiu, e toda falha que ele imprime traz a causa raiz e o arquivo com falha quando foram registrados.

Corrigido#

• Quando o acompanhamento do log de latchkey run ou latchkey logs --follow desiste depois de erros de rede repetidos, a CLI verifica o job mais uma vez e sai com o código do próprio job se ele terminou, em vez de sair com 1 como antes.
• O acompanhamento do log se atualiza mais rápido quando há um acúmulo de saída colorida ou não ASCII.