Verificação de risco pré-atualização
Use isto quando uma atualização de sandbox estiver chegando e alguém precisar saber o que será perdido. A verificação é somente leitura. O julgamento está nas perguntas, na revisão e na nota que será enviada.
Etapa 1: pergunte antes de agir
Pergunte tudo em uma única mensagem e aguarde as respostas. Não execute a verificação primeiro.
- Qual org, e qual é seu alias na CLI? Confirme que é uma sandbox, não Produção. Produção nunca é verificada por esta skill.
- Quando é a atualização e qual o tipo (Full, Partial, Developer Pro, Developer)? Full e Partial substituem dados. Developer e Developer Pro não mantêm nenhum.
- Existe um projeto de controle de versão para esta org? Se sim, onde está no disco? A verificação pode comparar a org com ele.
- Quem é responsável pelas integrações? O checklist atribui proprietários, então nomes (apenas pessoas internas) ajudam.
- Há algo nesta sandbox que se sabe existir em nenhum outro lugar? Dados de teste construídos manualmente, uma feature switch, uma configuração de demonstração.
Etapa 2: execute a verificação
node scan.js --org <alias> --out ./out [--project <caminho para o projeto sfdx>] [--days 90]
O script escreve out/refresh-risk-checklist.md e out/refresh-risk.json. Se uma verificação falhar (uma permissão que o usuário em execução não possui, um objeto que a org não tem), ele informa no checklist e continua. Não tente novamente com mais permissões sem perguntar.
Etapa 3: revise, não apenas encaminhe
Leia o checklist e aplique o julgamento que o script não pode:
- Quais itens estão fora do nosso escopo, mas ainda em risco? Sinalize-os mesmo assim. O cliente prefere ouvir duas vezes do que nenhuma vez.
- Quais itens são ruído? Um aplicativo conectado que ninguém usa pode ser descartado de propósito. Diga isso em vez de listá-lo como trabalho.
- Quais itens quebrarão silenciosamente? Usuários de integração e tokens OAuth vão primeiro na nota.
- Existe um script pós-cópia? Se não, recomende um. Ele transforma a maior parte desta lista em código.
Edite o checklist: risque ruído, adicione proprietários, adicione qualquer coisa que as respostas da Etapa 1 trouxeram à tona.
Etapa 4: redija a nota
Escreva a nota do cliente em palavras simples, com o tamanho de uma tela:
- A data e o tipo de atualização, na primeira linha.
- O que será perdido ou redefinido, agrupado: dados, credenciais e integrações, jobs agendados, configuração exclusiva da sandbox.
- O que precisamos deles, com uma data: proprietários para os itens fora do nosso escopo, confirmação sobre qualquer coisa que planejamos descartar.
- O que faremos, com uma data: exportações antes, re-inserção e reagendamento depois, um teste de fumo no primeiro dia.
Anexe o checklist. Não envie nada sem que o líder do engajamento leia primeiro.
Regras
- Somente leitura. O script apenas consulta e lista. Nunca adicione uma escrita.
- Apenas sandboxes. Se o alias resolver para Produção, pare e diga isso.
- Nunca cole segredos no checklist. Nomes de credenciais nomeadas, sim. Valores, nunca.
- Nenhum nome de cliente em nada que saia da pasta do engajamento.