Pr description

Flujo de ramas del equipo

El equipo usa el siguiente modelo de branching:

• feature/*: Ramas creadas desde develop o main/master. Agrupan varios PBIs relacionados.
• pbi/*: Ramas creadas desde la rama feature correspondiente. El PR va de pbi → feature.
  • Si hay varios PBIs en un feature, se mergea el primero y los siguientes PBIs se basan en el feature actualizado.
• bug/, hotfix/: Van directo a main/master/develop.

Pasos

Al escribir una descripción de PR:

1. Ejecutar git branch --show-current para obtener el nombre del branch actual.
2. Preguntar al usuario: a. Plataforma del PR: ¿Azure DevOps o GitHub?
   • Si es Azure DevOps: la descripción tiene un límite de 4000 caracteres. Ser conciso.
   • Si es GitHub: sin límite de caracteres. Se puede ser más detallado. b. Rama base contra la cual se compararán los cambios. Sugerir la más probable:
   • Si el branch actual es pbi/* → sugerir la rama feature/* correspondiente.
   • Si el branch actual es feature/* → sugerir develop o main/master.
   • Si el branch actual es bug/* o hotfix/* → sugerir main/master/develop.
   • Dejar que el usuario confirme o cambie la sugerencia. c. ¿Hay cambios de UI/frontend? Si sí, pedir al usuario que proporcione screenshots.
   • En GitHub: se embeben directamente en la descripción con ![descripcion](url).
   • En Azure DevOps: mencionar que se adjuntarán como archivos al PR o incluir como link.
3. Ejecutar git log --oneline [rama-base]..HEAD para ver todos los commits del branch.
4. Si el PR es de feature → develop/main/master (PR agregado):
   • Ejecutar git log --oneline --merges [rama-base]..HEAD para identificar los merge commits de PBIs.
   • Ejecutar git log --oneline [rama-base]..HEAD | grep -iE "pbi|merge" para extraer los PBIs incluidos.
   • Listar todos los PBIs/branches que se mergearon en el feature.
5. Ejecutar git diff [rama-base]...HEAD --stat para ver el resumen de archivos cambiados.
6. Ejecutar git diff [rama-base]...HEAD para ver todos los cambios en detalle.
7. Identificar el número de PBI/ticket del nombre del branch (si existe).
8. Detectar si hay endpoints nuevos o modificados (buscar en el diff controllers, rutas HTTP, [HttpPost], [HttpGet], etc.). Si los hay, documentarlos en la sección de Endpoints.

Formato de salida

Generar primero el título del PR y luego la descripción, siguiendo este template:

**Título del PR:** [Título corto y descriptivo, máximo 70 caracteres, en español]

# Resumen

[1-2 oraciones describiendo el alcance completo del cambio. Ser específico sobre qué se implementó.]

---

## Endpoints

### [N]. [Nombre descriptivo]

`[MÉTODO] [ruta/del/endpoint]` -- descripción breve de qué hace.
Stack: `FilterVM` -> `Business` -> `Controller`.
[Breve explicación del flujo interno: qué datos obtiene, qué valida, qué retorna.]

**Request:**

\```json
{
  "Campo1": valor_ejemplo,
  "Campo2": "valor_ejemplo"
}
\```

| Campo | Tipo | Requerido | Descripción |
|-------|------|-----------|-------------|
| Campo1 | long | Sí | Descripción del campo |
| Campo2 | string | No | Descripción del campo |

**Response:**

\```json
[
  {
    "Propiedad1": "valor_ejemplo",
    "Propiedad2": 123
  }
]
\```

---

## Funcionalidades implementadas

### 1. [Nombre de la funcionalidad]

- Detalle específico del comportamiento implementado
- Componentes o módulos involucrados
- Lógica relevante (cascadas, validaciones, cálculos, etc.)

### 2. [Siguiente funcionalidad]

- ...

---

## Cambios de UI

[Screenshots proporcionados por el usuario. En GitHub embeber con ![descripcion](url). En Azure DevOps indicar que están adjuntos al PR.]

---

## Archivos modificados

- **[Capa/Área]** ([cantidad]): breve descripción del tipo de cambios (ej: "Business (3): nueva lógica de cálculo de bonos")
- **[Capa/Área]** ([cantidad]): ...
- **Archivos nuevos:** [cantidad] | **Archivos modificados:** [cantidad]

---

## Deuda técnica conocida

| Item | Estado | Notas |
|------|--------|-------|
| [Descripción del item] | [PENDIENTE/BLOQUEADO/EN PROGRESO] | [Contexto adicional] |

Template para PR agregado (feature → develop/main/master)

Cuando el PR es de un feature hacia develop/main/master, usar este template en su lugar:

**Título del PR:** [Título corto y descriptivo, máximo 70 caracteres, en español]

# Resumen

[1-2 oraciones describiendo el alcance completo del feature. Ser específico sobre qué se implementó en conjunto.]

---

## PBIs incluidos

| PBI | PR | Descripción |
|-----|-----|-------------|
| #[número] | PR [número] | Breve descripción de lo que implementó ese PBI |
| #[número] | PR [número] | ... |

---

## Endpoints

### [N]. [Nombre descriptivo]

`[MÉTODO] [ruta/del/endpoint]` -- descripción breve de qué hace.
Stack: `FilterVM` -> `Business` -> `Controller`.
[Breve explicación del flujo interno.]

**Request:**

\```json
{
  "Campo1": valor_ejemplo,
  "Campo2": "valor_ejemplo"
}
\```

| Campo | Tipo | Requerido | Descripción |
|-------|------|-----------|-------------|
| Campo1 | long | Sí | Descripción del campo |

**Response:**

\```json
[
  {
    "Propiedad1": "valor_ejemplo",
    "Propiedad2": 123
  }
]
\```

---

## Funcionalidades implementadas

### 1. [Nombre de la funcionalidad]

- Detalle específico del comportamiento implementado
- Componentes o módulos involucrados
- Lógica relevante (cascadas, validaciones, cálculos, etc.)

### 2. [Siguiente funcionalidad]

- ...

---

## Cambios de UI

[Screenshots proporcionados por el usuario]

---

## Archivos modificados

- **[Capa/Área]** ([cantidad]): breve descripción
- **Archivos nuevos:** [cantidad] | **Archivos modificados:** [cantidad]

---

## Deuda técnica conocida

| Item | Estado | Notas |
|------|--------|-------|
| [Descripción del item] | [PENDIENTE/BLOQUEADO/EN PROGRESO] | [Contexto adicional] |

Reglas

• SIEMPRE generar el título del PR antes de la descripción. El título debe ser corto (máximo 70 caracteres), descriptivo y en español.
• Si no hay endpoints nuevos/modificados, omitir la sección "Endpoints"
• Si no hay cambios de UI, omitir la sección "Cambios de UI"
• Si no hay deuda técnica, omitir esa sección
• Agrupar las funcionalidades por área lógica (filtros, UI, backend, etc.)
• El idioma de la descripción debe ser español
• Si hay archivos de recursos/localización modificados, agruparlos (ej: SharedResource.*.resx (x4))
• Azure DevOps: La descripción tiene un límite de 4000 caracteres. Si la descripción excede este límite, comprimir las secciones menos críticas (archivos modificados, deuda técnica). Si aún no cabe, mover los detalles de endpoints a un comentario separado del PR.
• GitHub: Sin límite de caracteres. Se puede ser más detallado en todas las secciones.
• Archivos modificados: NO listar cada archivo individual en una tabla. Agrupar por capa/área con cantidad y descripción breve del tipo de cambio. Esto ahorra espacio significativo.
• Endpoints: Usar JSON de ejemplo con valores realistas, no genéricos. Los valores deben reflejar el dominio del proyecto.

Formato de entrega

• IMPORTANTE: La descripción generada DEBE guardarse en un archivo markdown (.md) en el directorio raíz del repositorio con el nombre pr-description.md. Esto permite al usuario abrir el archivo y copiar el contenido sin problemas de formato.
• Usar la herramienta Write para crear el archivo con el contenido completo de la descripción.
• Después de crear el archivo, indicar al usuario: "Descripción del PR guardada en pr-description.md. Puedes copiar el contenido desde ahí."
• El archivo pr-description.md NO debe commitearse. Si existe un .gitignore, agregar pr-description.md si no está incluido.
• No incluir explicaciones adicionales después de crear el archivo a menos que el usuario lo pida.