Ingeniería de software
Planifique una decisión de arquitectura de software
Una decisión de arquitectura registrada que compara opciones con restricciones explícitas, registra consecuencias y asigna un punto de verificación antes de la implementación.
El proceso
Hazlo en este orden.
- Define la decisión, el contexto, los usuarios afectados, los requisitos de importancia arquitectónica, el horizonte temporal y quién puede aprobar la elección.
- Recopila las restricciones pertinentes de producto, repositorio, fiabilidad, seguridad, coste y cumplimiento, separando los hechos verificados de las premisas y lo desconocido.
- Define al menos dos opciones viables, además de no hacer nada, y compáralas con criterios explícitos en lugar de elegir por familiaridad.
- Somete cada opción a una prueba de esfuerzo ante modos de fallo, esfuerzo de migración, carga operativa, reversibilidad, exposición de seguridad y coste de cambio a largo plazo.
- Elige una recomendación o registra un aplazamiento deliberado, con justificación, disenso, alternativas rechazadas y las condiciones que cambiarían la decisión.
- Escribe el registro de decisión con estado, contexto, decisión, consecuencias, enlaces de evidencia, responsables y desencadenantes de revisión antes de comenzar la implementación.
- Revisa el registro con los responsables, anota la aprobación o las condiciones necesarias y devuelve al solicitante el artefacto, las evidencias y los riesgos no resueltos.
Trae esto
Datos que el gato va a pedir.
- decisión de arquitectura y responsable de la decisión
- requisitos y restricciones
- sistema actual y revisión
- evidencias disponibles y partes interesadas en la revisión
Router + un playbook
Enruta primero. Elige uno.
Cat Paw carga un playbook por tarea, no mezcla varios. Empieza por este router; el resto son candidatos específicos del workflow.
- Router:
software-delivery-pack skills/software-delivery-pack/software-architecture-decision-gate/SKILL.md
Límites
Los límites viajan con el prompt.
- Verifica las herramientas, cuentas, permisos y el espacio de trabajo reales antes de empezar; nunca afirmes que exista una herramienta, cuenta, fuente o capacidad no disponible.
- Usa Latch/target-workspace para código privado, artefactos, sondeos en vivo o datos no públicos; si ese acceso no está disponible, detente en el límite e informa del bloqueo en lugar de sustituirlo por una suposición.
- Pausa para obtener aprobación explícita antes de acciones externas con consecuencias; devuelve evidencias, riesgos no resueltos, supuestos y cualquier acción que aún esté esperando aprobación.
Listo significa
Un cierre que se puede comprobar.
Un registro de decisión de arquitectura aprobado o aplazado explícitamente contiene el contexto, las opciones, la justificación, las consecuencias, los responsables, las evidencias y los desencadenantes de revisión.
Fuentes
De dónde sale este proceso.
Las fuentes fijan el patrón del workflow. Los posts de Reddit y de la comunidad, cuando aparecen, se tratan como anécdotas de quien lo practica, no como hechos universales.
