[juanjose1234456787654]

---

name: Pull Request Definitivo
about: Plantilla profesional avanzada para equipos serios de desarrollo
labels: ""
assignees: ""

📌 Convención obligatoria del título

Usar uno de los siguientes prefijos:

• bug → Corrección de errores / incidentes
• feat → Nueva funcionalidad / mejora visible
• refactor → Mejora interna / deuda técnica / arquitectura
• sec → Seguridad / vulnerabilidades / hardening

Ejemplos válidos

• [bug]: corrige error al iniciar sesión
• [feat]: agrega filtro por categorías
• [refactor]: reorganiza módulo de autenticación
• [sec]: corrige vulnerabilidad XSS en formularios

---

📌 Resumen Ejecutivo

Este Pull Request incorpora la plantilla estandarizada para la gestión de solicitudes de cambio e integración de código dentro del repositorio. Era necesario para eliminar la falta de contexto técnico en las fusiones de ramas, establecer controles obligatorios de calidad y asegurar el cumplimiento de buenas prácticas de configuración. Como resultado esperado, todas las futuras integraciones hacia las ramas principales contarán con trazabilidad completa, análisis de riesgos y validación previa documentada.

---

🎯 Objetivo del cambio

• Estandarizar el proceso de revisión de código (Code Review) mediante la incorporación de una estructura formal y obligatoria de Pull Request en el repositorio.
• Asegurar la trazabilidad técnica de cada integración exigiendo contexto, análisis de impacto, riesgos y planes de mitigación antes de fusionar cambios a las ramas principales (develop / main).
• Reducir la introducción de errores, regresiones y deuda técnica mediante listas de verificación (checklists) previas de calidad, seguridad y pruebas locales.

---

🧩 Contexto / Problema detectado

• Reporte de usuario
• Issue interno
• Mejora técnica
• Vulnerabilidad detectada
• Optimización
• Solicitud académica / cliente
• Otro:

Detalle:

Se detectó la necesidad de formalizar el flujo de trabajo colaborativo en Git y el control de configuración del proyecto. Anteriormente, las integraciones carecían de una estructura uniforme que obligara a documentar qué componentes se afectaban, cómo probar los cambios localmente y qué plan de reversión (rollback) aplicar en caso de fallos.

---

🔧 Tipo de cambio

• 🐞 bug
• ✨ feat
• ♻️ refactor
• 🔒 sec

---

🛠 Cambios realizados

• Cambio 1: Creación y estructuración del archivo de plantilla .github/pull_request_template.md con formato Markdown estandarizado.
• Cambio 2: Definición de reglas de nomenclatura para títulos de PR basadas en prefijos semánticos ([bug], [feat], [refactor], [sec]).
• Cambio 3: Incorporación de secciones de análisis de impacto (funcional, técnico, rendimiento y seguridad) y matriz de riesgos con plan de mitigación.
• Cambio 4: Adición de protocolos de despliegue, instrucciones de prueba local y plan de contingencia (rollback).
• Cambio 5: Inclusión de checklists de verificación para el autor (código, calidad, seguridad, base de datos y documentación) y guía para revisores.

---

📂 Áreas / Componentes afectados

• Frontend
• Backend
• API REST / GraphQL
• Base de datos
• Autenticación / Autorización
• Seguridad
• UI / UX
• Performance
• DevOps / Deploy
• Infraestructura
• Documentación
• Testing
• Otro: Gestión de Configuración del Software (SCM) / Flujo de GitHub

---

⚠ Impacto del cambio

Impacto funcional

Transparente para el usuario final; no altera las vistas ni la lógica de negocio de la aplicación en ejecución. Impacta positivamente al equipo de desarrollo al abrir nuevos Pull Requests en GitHub.

Impacto técnico

Agrega metadatos y configuración en el directorio .github/ del repositorio, automatizando la carga de la plantilla por defecto cada vez que un colaborador solicita un merge.

Impacto en rendimiento

No aplica. Al tratarse de archivos de configuración y documentación en Markdown, el consumo de recursos en tiempo de ejecución es nulo.

Impacto en seguridad

Mejora los controles preventivos del proyecto al exigir una revisión explícita de validación de inputs, no exposición de secretos/credenciales y verificación de permisos antes de aprobar cualquier cambio.

---

🚨 Riesgos identificados

• Sin riesgos relevantes
• Puede afectar login
• Puede afectar sesiones
• Puede afectar base de datos
• Puede afectar rendimiento
• Puede generar regresiones
• Puede afectar UI responsive
• Puede romper integraciones externas
• Requiere validación extra
• Otro:

Plan de mitigación:

Al no modificar código fuente compilable ni esquemas de datos, el riesgo técnico es nulo. Para evitar fricción en el equipo por la longitud de la plantilla, se dejaron comentarios guía claros (<!-- ... -->) en cada bloque para facilitar su llenado rápido.

---

🔄 Compatibilidad

• No rompe compatibilidad
• Breaking Change

Si rompe compatibilidad, explicar:

No aplica. Es 100% compatible con la estructura actual de ramas y código del repositorio.

---

🧪 Validación / Testing

Tipos de prueba ejecutados

• Manuales
• Unitarias
• Integración
• End-to-End
• Seguridad
• Performance
• Smoke Test
• Cross-browser
• Responsive

Resultado obtenido

Se validó manualmente el renderizado completo del código Markdown en el visor de GitHub, comprobando que las casillas de verificación (checkboxes), encabezados, listas y bloques de comentarios ocultos se visualicen sin errores de sintaxis ni caracteres rotos.

---

🧪 Cómo probar localmente

1. Hacer git fetch y cambiar a la rama correspondiente a este cambio (git checkout <nombre-de-tu-rama>).
2. Verificar la existencia y ubicación correcta del archivo dentro de la estructura del proyecto (.github/pull_request_template.md).
3. Abrir el archivo en un previsualizador de Markdown (ej. en VS Code con Ctrl + Shift + V) para comprobar el formato visual.
4. Simular la creación de un nuevo Pull Request en GitHub apuntando a develop o main para confirmar que la plantilla se carga automáticamente.

---

📸 Evidencia visual

La vista previa de este mismo Pull Request renderizado en GitHub constituye la evidencia visual del funcionamiento de la plantilla.

---

📋 Issues relacionados

• Closes chore(repo): agrega estructura de carpetas base #1
• Related to #
• Depends on #
• Blocks #

---

🚀 Consideraciones para despliegue

• No requiere acciones adicionales
• Requiere migración BD
• Requiere variables de entorno
• Requiere reinicio de servicios
• Requiere limpieza de caché
• Requiere coordinación con frontend
• Requiere coordinación con backend
• Requiere ventana de mantenimiento

Detalles:

El cambio entra en vigor en el repositorio de GitHub inmediatamente después de realizar el merge a la rama principal/base, sin requerir acciones de despliegue en servidores.

---

🔙 Plan de rollback

• Revert simple
• Revert con migración inversa
• Restaurar backup
• No definido

Procedimiento:

En caso de requerir ajustes o deshacer la integración, ejecutar un git revert <hash-del-merge-commit> desde la interfaz de GitHub o por consola y subir el cambio para restaurar el estado previo sin afectar el historial.

---

📈 Métricas esperadas (si aplica)

• Mejor tiempo de carga
• Menos errores en logs
• Mejor conversión UX
• Menor consumo recursos
• Mayor seguridad
• Otro: Mejora en la calidad de las revisiones de código (Code Reviews) y trazabilidad completa de cambios en el repositorio.

---

👀 Checklist del autor

Código

• Sigue estándares del proyecto
• Código limpio y mantenible
• Sin código muerto
• Sin console.log / debug
• Sin conflictos de merge

Calidad

• Probado localmente
• Revisado manualmente
• Sin errores visibles
• Casos edge considerados

Seguridad

• Inputs validados
• Sin exposición de secretos
• Permisos revisados
• Dependencias seguras

Base de datos

• Queries optimizadas
• Índices revisados
• Migraciones verificadas
• No pérdida de datos

Documentación

• README actualizado
• Comentarios agregados si aplica
• Documentación técnica actualizada

---

🧠 Notas para reviewers

Revisar especialmente:

• Que los criterios incluidos en el Checklist del autor y en Áreas afectadas cubran todas las necesidades actuales de nuestro proyecto.
• La claridad de las convenciones obligatorias del título al inicio del documento.

Preguntas abiertas:

• ¿Consideran necesario agregar algún prefijo adicional en la convención de títulos (por ejemplo, [docs] o [chore]), o mantenemos únicamente los 4 principales (bug, feat, refactor, sec)?

---

✅ Resultado esperado tras merge

Una vez aprobado y fusionado este PR con la rama base (develop / main), el repositorio adoptará oficialmente este estándar y todo nuevo Pull Request creado por cualquier integrante del equipo cargará esta estructura por defecto.

---

🏁 Aprobación sugerida

• Ready for Review
• Draft PR
• Requires Changes

[The-Fabry]

Revisión de PR: Aprobado (LGTM)

¡Excelente trabajo, @juanjose1234456787654 ! He revisado a detalle la propuesta y me parece que está increíble.

Puntos que destaco

• Estructura súper completa: La plantilla es muy clara y fácil de seguir. Me gusta mucho que cubra todo el ciclo de vida del cambio, desde el contexto hasta el plan de rollback.
• Estandarización: La "Convención obligatoria del título" y el uso de Markdown/HTML5 van a ayudar muchísimo a mantener el orden en el repositorio.
• Enfoque en calidad: La inclusión de las secciones de Riesgos identificados, Plan de mitigación y el Checklist del autor demuestran un gran nivel de detalle y buenas prácticas.
• Documentación: La sección de "Cómo probar localmente" y la evidencia visual hacen que sea muy fácil para los reviewers entender el cambio.

✅ Checklist de mi revisión

• Cumple perfectamente con el objetivo de estandarizar el flujo de trabajo.
• La estructura y documentación son muy claras.
• No rompe la compatibilidad actual ni genera conflictos.
• Sigue las buenas prácticas de integración continua (CI).

Aprobado para merge. ¡Gracias por el esfuerzo y por elevar el estándar de calidad del proyecto! Este tipo de aportes nos sirven un montón a todos. 👍

[AnahiM2025]

Revisión de PR: Aprobado (LGTM)

¡Gran trabajo @juanjose1234456787654! Le di una buena leída y la plantilla quedó espectacular.

Puntos que destaco

Cobertura total: Me parece genial que la plantilla abarque todo el proceso, desde el contexto inicial hasta cómo deshacer los cambios si algo sale mal. No dejaron cabos sueltos.

Orden y reglas claras: La parte de los prefijos obligatorios en los títulos y el uso de Markdown van a ser clave para que el repositorio no se vuelva un caos.

Nivel de exigencia: Las secciones de riesgos, mitigación y el checklist para el autor demuestran que buscan un estándar muy alto. Eso habla muy bien del equipo.

Pensada para el revisor: Las instrucciones de cómo probar localmente y la evidencia visual son un lujo. Nos van a ahorrar muchísimo tiempo al momento de revisar.

✅ Checklist de mi revisión

☑️ Cumple al 100% con la meta de ordenar nuestro flujo de trabajo.
☑️ Todo está súper bien redactado y es fácil de seguir.
☑️ No genera problemas con lo que ya tenemos armado ni habrá conflictos.
☑️ Aplica buenas prácticas de integración continua (CI).

Respecto a tu duda de los prefijos: yo iría por mantener solo los 4 principales por ahora para no marear al equipo, pero lo podemos charlar luego.

Aprobado para fusionar. ¡Gracias por el curro y por subir el nivel del proyecto! Estos aportes nos suman muchísimo a todos. 💪