Análisis previo al refresh
Úselo cuando se acerque una actualización de sandbox y alguien necesite saber qué se perderá. El análisis es de solo lectura. El juicio está en las preguntas, la revisión y la nota que se envía.
Paso 1: preguntar antes de actuar
Haga estas preguntas en un solo mensaje y espere las respuestas. No ejecute el análisis primero.
- ¿Cuál es la organización y cuál es su alias de CLI? Confirme que es un sandbox, no Producción. Producción nunca es analizada por esta skill.
- ¿Cuándo es el refresh y qué tipo (Full, Partial, Developer Pro, Developer)? Full y Partial reemplazan datos. Developer y Developer Pro no conservan ninguno.
- ¿Hay un proyecto de control de versiones para esta organización? Si es así, ¿dónde está en el disco? El análisis puede comparar la organización contra él.
- ¿Quién es el propietario de las integraciones? La lista de verificación asigna propietarios, por lo que los nombres (solo personal interno) ayudan.
- ¿Hay algo en este sandbox que se sepa que no existe en ningún otro lugar? Datos de prueba creados manualmente, un interruptor de funcionalidad, una configuración de demostración.
Paso 2: ejecutar el análisis
node scan.js --org <alias> --out ./out [--project <ruta al proyecto sfdx>] [--days 90]
El script escribe out/refresh-risk-checklist.md y out/refresh-risk.json. Si una verificación falla (un permiso que el usuario actual no tiene, un objeto que la organización no posee), lo indica en la lista de verificación y continúa. No reintente con más permisos sin preguntar.
Paso 3: revisar, no solo reenviar
Lea la lista de verificación y aplique el juicio que el script no puede:
- ¿Qué elementos están fuera de nuestro alcance pero aún en riesgo? Márquelos de todos modos. El cliente prefiere escucharlo dos veces que ninguna.
- ¿Qué elementos son ruido? Una aplicación conectada que nadie usa se puede eliminar a propósito. Dígalo en lugar de listarlo como trabajo.
- ¿Qué elementos se romperán silenciosamente? Los usuarios de integración y los tokens OAuth van primero en la nota.
- ¿Hay un script posterior a la copia? Si no, recomiende uno. Convierte la mayor parte de esta lista en código.
Edite la lista de verificación: tache el ruido, agregue propietarios, agregue cualquier cosa que las respuestas del Paso 1 hayan revelado.
Paso 4: redactar la nota
Redacte la nota para el cliente en palabras sencillas, de una pantalla de largo:
- La fecha y el tipo de refresh, en la primera línea.
- Lo que se perderá o reiniciará, agrupado: datos, credenciales e integraciones, trabajos programados, configuración solo de sandbox.
- Lo que necesitamos de ellos, con una fecha: propietarios para los elementos fuera de nuestro alcance, confirmación sobre cualquier cosa que planeemos eliminar.
- Lo que haremos, con una fecha: exportaciones antes, reingreso y reprogramación después, una prueba de humo el primer día.
Adjunte la lista de verificación. No envíe nada sin que el líder del compromiso lo lea primero.
Reglas
- Solo lectura. El script solo consulta y lista. Nunca agregue una escritura.
- Solo sandboxes. Si el alias resuelve a Producción, deténgase y dígalo.
- Nunca pegue secretos en la lista de verificación. Nombres de credenciales con nombre, sí. Valores, nunca.
- Sin nombres de clientes en nada que salga de la carpeta del compromiso.