AI-SDLC Pro

Objetivo:
Quiero que analices integralmente este repositorio y construyas un inventario técnico inicial del proyecto.

Actividades:
1. Revisa la estructura completa del repositorio.
2. Identifica:
   - componentes,
   - módulos,
   - capas,
   - servicios,
   - librerías internas,
   - scripts,
   - pipelines,
   - pruebas,
   - documentación,
   - archivos de configuración,
   - contenedores,
   - migraciones,
   - variables de entorno.
3. Detecta tecnologías utilizadas:
   - frontend,
   - backend,
   - base de datos,
   - infraestructura,
   - mensajería,
   - autenticación,
   - observabilidad.
4. Ubica los artefactos del ciclo de ingeniería:
   - análisis,
   - diseño,
   - casos de uso,
   - diagramas,
   - implementación,
   - pruebas,
   - CI/CD,
   - documentación.
5. Detecta vacíos o ausencias relevantes.

Formato de salida:
1. Resumen ejecutivo
2. Inventario de carpetas y propósito
3. Arquitectura detectada
4. Tecnologías y versiones encontradas
5. Procesos/documentación localizados
6. Riesgos o vacíos
7. Recomendación de orden de revisión

Objetivo:
Quiero que identifiques dentro del repositorio todos los documentos, archivos o secciones que correspondan a procesos, procedimientos, políticas, estándares, lineamientos, guías de codificación, flujos de trabajo, definición de ramas, estrategia QA, estrategia CI/CD y reglas de ingeniería de software.

Actividades:
1. Busca en README, docs, wiki exportada, carpetas de documentación, markdowns, ADRs, archivos de contribución y workflows.
2. Clasifica lo encontrado por categoría:
   - procesos,
   - procedimientos,
   - políticas,
   - estándares,
   - arquitectura,
   - QA,
   - seguridad,
   - branching,
   - despliegue,
   - operación.
3. Indica qué sí existe, qué está incompleto y qué no existe.

Formato de salida:
- matriz por categoría,
- archivo/ruta encontrada,
- descripción,
- nivel de completitud,
- observaciones.

Objetivo:
Analiza el requerimiento, issue o cambio solicitado y determina su alcance funcional y técnico dentro del proyecto.

Entradas:
- issue o requerimiento: [PEGAR]
- repositorio o módulo: [INDICAR]

Actividades:
1. Comprende el problema o necesidad.
2. Identifica:
   - flujo de negocio afectado,
   - actor(es),
   - caso(s) de uso,
   - comportamiento actual,
   - comportamiento esperado,
   - criterios de aceptación si existen.
3. Revisa si ya está documentado en el proyecto.
4. Relaciona el requerimiento con módulos, componentes y datos impactados.
5. Detecta dependencias y riesgos.

Salida:
1. Resumen funcional
2. Casos de uso impactados
3. Reglas de negocio detectadas
4. Componentes técnicos involucrados
5. Riesgos funcionales y técnicos
6. Recomendación de atención

Objetivo:
Analiza el código existente relacionado con el requerimiento o incidente y explica cómo funciona realmente hoy.

Actividades:
1. Ubica archivos, clases, funciones, endpoints, servicios, consultas, tablas y componentes UI involucrados.
2. Describe el flujo end-to-end actual.
3. Identifica:
   - acoplamientos,
   - dependencias,
   - deuda técnica,
   - validaciones faltantes,
   - riesgos de regresión,
   - problemas de diseño.
4. Señala exactamente qué archivos y módulos están involucrados.

Formato de salida:
1. Flujo actual
2. Componentes afectados
3. Archivos relevantes
4. Hallazgos técnicos
5. Riesgos de modificación

---

Objetivo:
Analiza el código existente relacionado con el requerimiento o incidente y explica cómo funciona realmente hoy.

Actividades:
1. Ubica archivos, clases, funciones, endpoints, servicios, consultas, tablas y componentes UI involucrados.
2. Describe el flujo end-to-end actual.
3. Identifica:
   - acoplamientos,
   - dependencias,
   - deuda técnica,
   - validaciones faltantes,
   - riesgos de regresión,
   - problemas de diseño.
4. Señala exactamente qué archivos y módulos están involucrados.

Formato de salida:
1. Flujo actual
2. Componentes afectados
3. Archivos relevantes
4. Hallazgos técnicos
5. Riesgos de modificación

---

Objetivo:
Analiza el impacto del cambio solicitado en otros módulos, procesos, datos, integraciones, ambientes y pipelines.

Actividades:
1. Evalúa impacto en:
   - frontend,
   - backend,
   - base de datos,
   - integraciones,
   - infraestructura,
   - CI/CD,
   - seguridad,
   - monitoreo,
   - documentación.
2. Detecta impactos directos e indirectos.
3. Evalúa afectación a otros casos de uso.

Salida:
- matriz de impacto,
- severidad,
- componente afectado,
- tipo de impacto,
- riesgo,
- recomendación.

Objetivo:
Analiza el impacto del cambio solicitado en otros módulos, procesos, datos, integraciones, ambientes y pipelines.

Actividades:
1. Evalúa impacto en:
   - frontend,
   - backend,
   - base de datos,
   - integraciones,
   - infraestructura,
   - CI/CD,
   - seguridad,
   - monitoreo,
   - documentación.
2. Detecta impactos directos e indirectos.
3. Evalúa afectación a otros casos de uso.

Salida:
- matriz de impacto,
- severidad,
- componente afectado,
- tipo de impacto,
- riesgo,
- recomendación.

Objetivo:
Analiza los incidentes reportados por testing y compáralos con los issues existentes en GitHub para determinar si ya existen, si están bien documentados y cuál es su estatus actual.

Actividades:
1. Normaliza cada incidente:
   - título,
   - descripción,
   - pasos para reproducir,
   - resultado actual,
   - resultado esperado,
   - severidad,
   - ambiente,
   - módulo.
2. Busca equivalentes en GitHub.
3. Clasifica cada incidente en:
   - existe y está correcto,
   - existe pero está incompleto,
   - existe pero está mal documentado,
   - no existe.
4. Propón acción:
   - comentar,
   - actualizar,
   - reabrir,
   - crear,
   - relacionar,
   - marcar duplicado.
5. Si no existe, redacta el issue completo con el estándar del proyecto.

Salida:
1. Resumen ejecutivo
2. Matriz QA vs GitHub
3. Issues a crear
4. Issues a actualizar
5. Issues con problemas de trazabilidad
6. Recomendaciones de mejora al proceso QA → GH

Objetivo:
Analiza un defecto o incidente y determina la causa raíz real, no solo el síntoma.

Actividades:
1. Define el síntoma observado.
2. Revisa evidencia:
   - logs,
   - código,
   - configuraciones,
   - consultas,
   - commits recientes,
   - despliegues recientes.
3. Formula hipótesis.
4. Valida hipótesis con evidencia.
5. Determina:
   - causa raíz,
   - factores contribuyentes,
   - impacto,
   - módulos afectados.
6. Si no se puede confirmar totalmente, indica evidencia faltante y nivel de confianza.

Salida:
1. Síntoma
2. Evidencia
3. Hipótesis
4. Causa raíz confirmada o probable
5. Factores contribuyentes
6. Riesgo asociado
7. Recomendación de remediación

Objetivo:
Diseña una solución completa, funcional y técnica, para el requerimiento o incidente analizado.

Incluye:
1. Objetivo de la solución
2. Alcance
3. Supuestos
4. Restricciones
5. Casos de uso impactados
6. Reglas de negocio
7. Cambios requeridos por componente
8. Riesgos
9. Dependencias
10. Estrategia de validación
11. Estrategia de rollback

Formato de salida:
1. Resumen de diseño
2. Diseño funcional
3. Diseño técnico
4. Componentes afectados
5. Riesgos y mitigaciones
6. Recomendación de implementación

Objetivo:
Con base en el análisis y diseño del cambio, genera diagramas Mermaid claros y útiles para documentar la solución.

Necesito:
1. Diagrama de flujo del proceso actual y propuesto
2. Diagrama de secuencia
3. Diagrama de componentes
4. Si aplica, diagrama entidad-relación simplificado

Reglas:
- Los diagramas deben ser consistentes con el código y la arquitectura real.
- No inventes componentes inexistentes.
- Etiqueta claramente actores, servicios, módulos y datos.

Entrega:
- bloque Mermaid por diagrama,
- breve explicación de cada uno.

Objetivo:
Documenta formalmente los casos de uso relacionados con el requerimiento o módulo analizado.

Para cada caso de uso incluye:
- nombre,
- objetivo,
- actores,
- disparador,
- precondiciones,
- flujo principal,
- flujos alternos,
- postcondiciones,
- reglas de negocio,
- criterios de aceptación,
- componentes técnicos relacionados.

Objetivo:
Elabora un plan de implementación detallado, ejecutable y trazable para la solución propuesta.

Incluye:
1. actividades previas,
2. cambios por componente,
3. ajustes de datos o migraciones,
4. pruebas requeridas,
5. validaciones en ambiente,
6. integración con ramas,
7. despliegue,
8. rollback,
9. evidencias esperadas.

Formato:
| Paso | Actividad | Componente | Dependencia | Riesgo | Evidencia esperada |

Objetivo:
Identifica y analiza los riesgos de implementación y el impacto potencial del cambio en otros módulos, procesos, servicios, pipelines, integraciones y usuarios.

Clasifica riesgos por:
- funcional,
- técnico,
- datos,
- seguridad,
- operación,
- concurrencia de agentes,
- integración,
- despliegue.

Entrega:
- matriz de riesgos,
- probabilidad,
- impacto,
- mitigación,
- contingencia.

Modo: ejecución controlada

Objetivo:
Implementa la solución aprobada respetando un entorno multi-agente con cambios concurrentes.

Reglas:
1. Revisa cambios recientes antes de editar.
2. Trabaja con cambios mínimos y controlados.
3. No modifiques archivos fuera del alcance.
4. Haz commits atómicos por unidad lógica.
5. Si detectas cambios ajenos en la misma zona, detén y documenta.

Actividades:
1. Identificar archivos a modificar
2. Aplicar cambios por componente
3. Mantener compatibilidad con contratos y flujos existentes
4. Actualizar pruebas y documentación relacionadas
5. Preparar propuesta de commit

Entrega:
- archivos modificados,
- resumen de cambio por archivo,
- riesgos residuales,
- mensaje de commit sugerido.

Objetivo:
Genera mensajes de commit pequeños, claros, trazables y alineados al estándar del proyecto.

Entradas:
- issue,
- tipo de cambio,
- componente,
- descripción breve.

Entrega:
1. commit principal sugerido
2. commits alternativos si el cambio debe dividirse
3. justificación de por qué conviene dividir el trabajo

Objetivo:
Diseña las pruebas unitarias necesarias para validar los cambios propuestos o implementados.

Incluye:
- función o unidad bajo prueba,
- escenario,
- entrada,
- resultado esperado,
- casos positivos,
- casos negativos,
- casos borde.

Entrega:
- matriz de pruebas unitarias,
- recomendación de cobertura.

Objetivo:
Define las pruebas de integración necesarias para validar la interacción entre módulos, servicios, APIs, base de datos e integraciones involucradas.

Incluye:
- flujo,
- componentes integrados,
- datos de prueba,
- resultado esperado,
- validación de errores.

Objetivo:
Diseña pruebas end-to-end para los casos de uso impactados por el cambio.

Incluye:
- actor,
- flujo principal,
- precondiciones,
- pasos,
- resultado esperado,
- evidencia requerida,
- regresiones relacionadas.

Objetivo:
Define un plan de pruebas de humo para validar rápidamente que el sistema sigue operativo después del cambio.

Incluye:
- login/autenticación si aplica,
- flujo crítico principal,
- acceso a módulos,
- operaciones básicas,
- integraciones mínimas,
- errores visibles.

Objetivo:
Diseña y documenta una estrategia de pruebas automatizadas en navegador usando Chrome Antigravity para validar los flujos impactados.

Incluye:
- escenario,
- navegación,
- selectors esperados,
- datos de prueba,
- validaciones visuales y funcionales,
- capturas o evidencia esperada,
- posibles puntos frágiles del flujo.

Objetivo:
Realiza una revisión estática del código relacionado con el cambio y evalúa calidad, mantenibilidad, seguridad y consistencia con estándares del proyecto.

Revisa:
- estructura,
- claridad,
- duplicación,
- complejidad,
- manejo de errores,
- validaciones,
- logging,
- seguridad,
- consistencia de nombres,
- alineación con arquitectura.

Entrega:
1. hallazgos críticos
2. hallazgos medios
3. observaciones menores
4. deuda técnica detectada
5. recomendaciones puntuales

Objetivo:
Valida si la implementación realmente cumple con el issue, requerimiento, caso de uso y criterios de aceptación.

Compara:
- lo solicitado,
- lo diseñado,
- lo implementado,
- lo probado.

Entrega:
- cumplimiento total/parcial/no cumple,
- diferencias detectadas,
- riesgos por incumplimiento,
- acciones requeridas.

Actúa como un Ingeniero de Software Senior, Arquitecto de Soluciones, QA Lead y DevOps Engineer con experiencia en PSP, RUP, DevSecOps, CI/CD y revisión de código en sistemas productivos.

Contexto:
Estoy trabajando en un entorno multi-agente con Open Agent Manager. Otros agentes pueden estar modificando el repositorio en paralelo.

Entrada:
Te proporciono un reporte de revisión estática de código con hallazgos críticos, medios, menores y deuda técnica.

Documento:
[PEGAR REPORTE COMPLETO AQUÍ]

Objetivo:
Quiero que analices este reporte y generes una solución integral, controlada y de calidad para corregir los hallazgos sin afectar la estabilidad del sistema.

---

REGLAS CRÍTICAS:
1. NO implementar directamente.
2. Primero analizar, luego diseñar, luego planificar.
3. Considerar impacto en:
   - arquitectura
   - base de datos
   - frontend/backend
   - integraciones
   - CI/CD
   - otros agentes trabajando en paralelo
4. No proponer cambios sin justificar.
5. Detectar dependencias entre hallazgos.
6. Priorizar estabilidad del sistema sobre velocidad.

---

FASE 1 — ANÁLISIS DEL REPORTE:
Para cada hallazgo:
1. Validar si aplica realmente al código
2. Clasificar: crítico / medio / menor / deuda técnica
3. Identificar: causa raíz, componente afectado, riesgo
4. Detectar: duplicidades y dependencias entre hallazgos

---

FASE 2 — DISEÑO DE SOLUCIÓN:
Para cada hallazgo:
- solución propuesta
- alternativa (si aplica)
- impacto técnico
- impacto en otros módulos
- riesgos de implementación

Además:
1. Proponer refactorizaciones globales si hay problemas estructurales
2. Proponer centralización (ej: constantes duplicadas)
3. Proponer mejoras de arquitectura si aplica

---

FASE 3 — ESTRATEGIA DE CALIDAD:
Definir:
1. Pruebas unitarias necesarias
2. Pruebas de integración
3. Pruebas E2E
4. Pruebas de regresión
5. Casos negativos

Incluir: qué validar, cómo validar, riesgo cubierto

---

FASE 4 — PLAN DE IMPLEMENTACIÓN CONTROLADO:
Generar plan detallado:
| Paso | Cambio | Archivo | Riesgo | Validación |

Considerar:
- orden correcto de cambios
- dependencias entre fixes
- concurrencia con otros agentes
- commits atómicos
- rollback

---

FASE 5 — ESTRATEGIA DE INTEGRACIÓN:
Definir:
- estrategia de ramas
- manejo de conflictos
- validación en CI
- validación en PR
- condiciones de merge

---

FASE 6 — ANÁLISIS DE RIESGOS:
Generar matriz:
| Riesgo | Probabilidad | Impacto | Mitigación |

---

FORMATO DE SALIDA OBLIGATORIO:
1. Resumen ejecutivo
2. Validación del reporte (qué sí aplica y qué no)
3. Análisis por hallazgo
4. Causa raíz
5. Diseño de solución
6. Estrategia de calidad
7. Plan de implementación
8. Estrategia de integración
9. Riesgos y mitigación
10. Recomendación final

REGLAS DE CALIDAD:
- No soluciones superficiales
- No cambios aislados sin contexto
- No ignorar impacto en otros módulos
- No asumir comportamiento sin evidencia
- Si algo no está claro → declararlo

---

Con base en el análisis y plan generado previamente:

Objetivo:
Implementar los cambios de forma controlada en entorno multi-agente.

Reglas:
- cambios mínimos por commit
- un hallazgo por commit
- no modificar fuera del alcance
- validar antes de cada commit

Para cada cambio:
1. archivo afectado
2. cambio exacto
3. validación
4. commit sugerido

Si detectas conflicto:
DETENER ejecución y documentar el conflicto antes de continuar.

Objetivo:
Analiza cómo integrar los cambios con otras ramas activas, evitando conflictos y asegurando consistencia funcional y técnica.

Incluye:
1. ramas relacionadas,
2. cambios potencialmente conflictivos,
3. estrategia recomendada:
   - merge,
   - rebase,
   - cherry-pick,
   - espera controlada,
   - integración por fases.
4. riesgos de integración.

Objetivo:
Revisa el estado del pipeline de CI tanto localmente como en GitHub y determina si los cambios están listos para integrarse.

Valida:
- lint,
- build,
- pruebas,
- quality gates,
- workflows,
- artefactos,
- checks del PR.

Entrega:
1. estatus general,
2. fallas detectadas,
3. causa probable,
4. acción recomendada,
5. criterio de aprobación o rechazo.

Objetivo:
Analiza los workflows del repositorio y determina si cubren adecuadamente validación, pruebas, seguridad, despliegue y calidad.

Incluye:
- inventario de workflows,
- disparadores,
- jobs,
- validaciones existentes,
- faltantes,
- riesgos,
- mejoras recomendadas.

Objetivo:
Actualiza o propone actualización de la documentación técnica afectada por el cambio.

Revisa y actualiza:
- README,
- docs,
- arquitectura,
- diagramas,
- contratos,
- casos de uso,
- notas de despliegue,
- troubleshooting.

Entrega:
- documentos a actualizar,
- contenido propuesto,
- razón del cambio.

Objetivo:
Genera una memoria técnica clara y ejecutiva del cambio realizado.

Incluye:
1. contexto
2. problema o requerimiento
3. análisis
4. causa raíz si aplica
5. solución implementada
6. componentes modificados
7. pruebas ejecutadas
8. riesgos
9. resultados
10. puntos pendientes

Objetivo:
Redacta las notas de release o changelog del cambio con enfoque técnico y funcional.

Incluye:
- resumen del cambio,
- módulos impactados,
- correcciones,
- mejoras,
- riesgos,
- consideraciones de despliegue,
- notas de compatibilidad.

Objetivo:
Analiza un problema de ambiente, despliegue, servicio, contenedor, pipeline o configuración y determina posibles causas, validaciones necesarias y ruta de solución.

Incluye:
- síntoma,
- servicios involucrados,
- revisión sugerida,
- comandos o evidencias a revisar,
- hipótesis,
- ruta de resolución.

Objetivo:
Analiza el repositorio y la configuración operativa para detectar oportunidades de fortalecimiento de seguridad, hardening, manejo de secretos, permisos, exposición de servicios y riesgos de despliegue.

Entrega:
- hallazgos,
- criticidad,
- mitigación,
- prioridad.

Objetivo:
Identifica deuda técnica en el repositorio y propón un backlog priorizado de mejoras.

Clasifica por:
- arquitectura,
- código,
- pruebas,
- documentación,
- seguridad,
- CI/CD,
- observabilidad,
- datos,
- performance.

Entrega:
- matriz de deuda técnica,
- prioridad,
- impacto,
- esfuerzo estimado,
- recomendación de atención.

Objetivo:
Coordina el ciclo completo de ingeniería de software para esta asignación dentro del repositorio.

Entrada:
- issue/requerimiento/incidente: [PEGAR]
- rama objetivo: [INDICAR]
- ambiente: [INDICAR]
- componentes: [INDICAR]

Quiero que trabajes por fases:

Fase 1. Comprensión e inventario
- revisar documentación, procesos, políticas y estructura del repo.

Fase 2. Análisis
- funcional,
- técnico,
- impacto,
- riesgos,
- concurrencia con otros agentes.

Fase 3. Diseño
- solución funcional,
- solución técnica,
- casos de uso,
- diagramas mermaid,
- plan de implementación.

Fase 4. Ejecución controlada
- propuesta de cambios por archivo,
- estrategia de commits,
- validaciones.

Fase 5. Calidad
- pruebas unitarias,
- integración,
- E2E,
- humo,
- automatización navegador,
- revisión estática.

Fase 6. Integración
- ramas,
- CI local,
- GitHub Actions,
- riesgos de integración.

Fase 7. Documentación
- memoria técnica,
- actualización documental,
- release notes.

Formato de salida obligatorio:
1. Resumen ejecutivo
2. Hallazgos
3. Riesgos
4. Diseño propuesto
5. Plan de implementación
6. Estrategia de pruebas
7. Estrategia de integración
8. Documentación requerida
9. Recomendación final