# Changelog da CLI do Latchkey > O que cada versão da CLI do Latchkey adicionou, alterou e corrigiu, da mais recente para a mais antiga, a partir da 0.3.0. Source: https://latchkey.dev/pt/documentation/latchkey-cli-changelog ## Summary - Todas as versões da CLI do Latchkey a partir da 0.3.0, da mais recente para a mais antiga, com o que cada uma adicionou, alterou e corrigiu. - `latchkey version` mostra a versão que você tem, e `npm install -g @latchkeydev/cli` atualiza para a mais recente. 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](https://latchkey.dev/pt/documentation/latchkey-cli) descreve os comandos como eles funcionam hoje. ## 0.17.0 Lançada em 2026-11-13. ### Adicionado - `latchkey workflows rerun --repository ` 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 --repository ` 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 `), 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 --repository ` 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 `, com `--commit ` ou `--pr `, 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 ` e `latchkey wait --pr `, com `--repository `, 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: ` 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 ` o lê de novo. ## 0.10.0 Lançada em 2026-11-02. ### Adicionado - `latchkey workflows run --repository ` 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 `. 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 --max-concurrent ` 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 ` 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 `, 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 ` 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 ` 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 `, 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 ` 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 ` imprime só o orçamento e o gasto. - `latchkey environments list --repository ` lista as branches que cada ambiente de um repositório aceita. - `latchkey list` aceita `--batch ` para os jobs de um lote e `--before ` 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 ` 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/@`, 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 ` empacota outro diretório em vez do atual, e `--exclude ` 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 ` interrompe um job assim que ele custar esse valor (exit 3), e `--batch ` ou `LATCHKEY_BATCH` coloca jobs em um lote. - `latchkey budget set ` 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 ` 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. --- Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt