Um caso que talvez valha a ferramenta reconhecer: projeto que tira a versão da própria tag, com setuptools-scm ou hatch-vcs no Python. Ali não tem string editada à mão, a versão sai do git na hora do build, então esse drift nem tem como acontecer. Se o closure_drift detectar isso no pyproject e responder limpo dizendo o motivo, evita cair no "não deu para decidir" à toa.
Gostei do achado do AGENTS.md, "suba a versão e faça commit" parece inofensivo até o agente seguir ao pé da letra.
Boa. Ela já reconhece setuptools-scm, hatch-vcs, versioneer e afins: o relatório diz "version from (the tag)" e explica que não há arquivo de versão para conferir. Mas você pegou uma coisa: a última linha ainda dizia "nada foi decidido", o que contradiz a explicação.
Corrigi agora. No --would-tag desses projetos ela passa a dizer de onde ainda pode vir drift (nome de tag reaproveitado ou movido, ou v1.0 e 1.0 em códigos diferentes), lista os rótulos já usados e diz para dar à tag nova um nome que nenhuma outra usa. Continua exit 2, porque a tag ainda não existe para ser conferida, mas o texto não diz mais "não deu".
Sai hoje na 1.3.1, com crédito a você no CHANGELOG: https://github.com/luizfnsilva/closure_drift/commit/ef7993af9b3b7dd32130bf8e332045a5ea41a0b1
Valeu pelo apontamento.
valeu pelo crédito no changelog! faz sentido continuar com exit 2 enquanto a tag não existe, o que confundia era só a frase do fim.
E se puder, passa para mais um amigo rodar no repositório dele. São dois comandos:
git clone -q https://github.com/luizfnsilva/closure_drift
python3 closure_drift/closure_drift.py /caminho/do/repo
Só lê o git e não manda nada para lugar nenhum. Cada repositório novo acha um caso que eu não tinha visto, como o seu de hoje.