Verificação segura para ciclo de vida

O que Verificação segura para ciclo de vida faz?

Gatilho e limites

Use antes da conclusão de uma tarefa, transferência de revisão, desmontagem de workspace ou outra transição autorizada que possa excluir ou realocar o diretório de trabalho atual. Esta skill não autoriza limpeza, transições de ciclo de vida, mudanças de estado, encerramento de processos ou repetições. Siga o contrato real de ciclo de vida da plataforma; nem toda transição remove uma árvore de trabalho, e uma transição bem-sucedida não precisa parar um processo de trabalho.

Antes da transição

1. Estabeleça identidade exata: ID de tarefa/registro, board ou namespace, perfil/conta, repositório e estado esperado. Não confie na tarefa atual implícita de uma ferramenta após alterar diretórios. Use seletores explícitos suportados pela plataforma.
2. Inspecione as semânticas de limpeza e identifique locais de propriedade da tarefa versus persistentes. Escolha um diretório estável existente fora de todos os workspaces que a transição pode remover. Um caminho pai é seguro apenas se também sobreviver à limpeza; um link simbólico para o workspace descartável não é um local durável. Resolva caminhos reais.
3. Conclua as verificações de aceitação primeiro. Preserve relatórios, checksums, commits e anexos necessários por meio do mecanismo suportado de artefato durável da plataforma, ou outro local persistente aprovado pelo usuário. Leia de volta a identidade e o conteúdo exatos do artefato. Uma string de caminho em um comentário não preserva o arquivo que nomeia.
4. Registre um recibo compacto pré-transição fora do diretório descartável: identidade exata, transição esperada, locais de evidências, comandos de verificação e quaisquer limitações não resolvidas. Nunca marque uma aceitação incompleta como completa meramente para preservar evidências; use o estado de checkpoint/transferência autorizado apropriado.
5. Planeje a verificação pós-transição de modo que não exija o checkout antigo, seu virtualenv, arquivos relativos, descoberta de board dependente de ambiente ou scripts auxiliares. Resolva executáveis e caminhos duráveis necessários antes da transição.

Transição e leitura exata

1. Execute a transição já autorizada uma vez. Capture seu recibo sem tratar o sucesso como prova do estado durável desejado.
2. Inicie a leitura com o parâmetro explícito de diretório de trabalho estável da ferramenta de execução. Um cd dentro do comando pode nunca executar se a ferramenta falhar ao entrar em seu cwd excluído lembrado. Se a ferramenta não tiver uma substituição de diretório de trabalho, use uma sessão independente enraizada em um local sobrevivente. Não repita a mutação de ciclo de vida para reparar uma leitura falha.
3. Leia a tarefa/registro exato e o evento de transição usando uma interface somente leitura suportada. Verifique status esperado, ID de execução/evento relevante e conteúdo do artefato durável. Se a própria remoção foi solicitada, verifique separadamente a ausência no sistema de arquivos e o cancelamento do registro do worktree Git. Não presuma que a ausência de diretório significa que um branch ou anexo foi removido.
4. Se a plataforma transformou o estado solicitado (por exemplo, encaminhou-o para revisão), relate o estado real. Se um worker permanecer ativo, reporte isso separadamente; não o pare sem autorização.
5. Em caso de erro, inspecione stderr e qual estágio falhou. Um wrapper retornando 126 com cd: ... No such file or directory não é evidência de que o executável alvo precisa de chmod. Repita apenas a verificação somente leitura a partir de um diretório estável. Se o registro não puder ser lido, reporte transição reconhecida, mas verificação incompleta.

Fixture de regressão descartável

O fixture cria seu próprio repositório Git temporário e worktree vinculado, preserva um recibo sintético em um diretório durável irmão, remove apenas aquele worktree do fixture, então prova que o lançamento a partir do cwd removido falha enquanto o lançamento do diretório durável tem sucesso. Ele também verifica a lista de worktrees do Git e o conteúdo do recibo. Nunca toca em uma tarefa real, remoto, workspace de usuário ou API de plataforma.

Execute a partir do diretório do pacote instalado:

python -m unittest discover -s scripts -p 'test_*.py' -v

Isso testa o comportamento do sistema de arquivos/subprocesso/Git, não uma promessa universal de limpeza da plataforma. Semânticas de conclusão reais e leitura de artefatos remotos ainda exigem verificação específica da plataforma. Não execute comandos de remoção contra o workspace de um usuário como demonstração.

Fontes e proveniência

Autorado independentemente a partir de falhas recorrentes de verificação de cwd removido; nenhum log privado, caminho ou identificador de tarefa está incluído. A documentação de subprocess do Python documenta cwd, códigos de retorno e falhas de inicialização de filhos. O manual do Git worktree documenta criação, remoção e listagem de worktrees vinculados. Esses primitivos suportam o fixture, não uma inferência sobre a implementação de qualquer agendador de tarefas específico.