Backlog

# Backlog — [Nombre del proyecto]

> Creado en F4.4 del workflow. Revisado por el arquitecto antes de darse por finalizado.
> Si el backlog crece demasiado, dividirlo en múltiples archivos por fase o por dominio.

## Estado

| | |
|---|---|
| Ítems totales | |
| Completados | |
| En curso | |
| Revisión del arquitecto | ☐ Pendiente / ☑ Aprobada (fecha) |

## Convenciones

- **El prefijo del ID es del proyecto** (mayúsculas, 2–4 letras: `PRJ` acá es un marcador de posición) y se conserva en el nombre de la rama, en el artefacto de QA (Quality Assurance) y en el índice de changes archivados
- Cada ítem se desarrolla con un ciclo OpenSpec completo: apply → verify → qa → archive
- Las dependencias deben estar explícitas — ningún ítem arranca si sus dependencias no están archivadas
- Los dos primeros ítems son siempre: el design system consolidado del prototipo aprobado, y la configuración de CI/CD (Continuous Integration / Continuous Delivery)
- El **diagrama de dependencias** (abajo) es también el **mapa de progreso**: cada nodo refleja el estado de su ítem
- Si el proyecto se entrega **por hitos** (`../methodology/hitos.md`), cada ítem declara el suyo
  (`H-1`, `H-2`, …). La cola sigue siendo una sola: el hito es un atributo del ítem, no un backlog aparte
- Cada ítem declara su **`Origen`**: `inicial` (del backlog derivado de los PRDs —Product Requirements Document—) o, en evolución continua, `stakeholder` / `producción` / `deuda` / `auditoría` (ver workflow fase 6)

## Diagrama de dependencias y progreso

El grafo muestra qué ítem depende de cuál y, a la vez, en qué punto está el proyecto. La
flecha va del **prerrequisito** al ítem que lo necesita (orden de construcción, de arriba
hacia abajo). El color de cada nodo refleja el estado del ítem:

- 🟩 **archivado** (`done`) · 🟨 **en curso** (`wip`) · ⬜ **pendiente** (`pending`)

> **Artefacto vivo.** La fuente de verdad del estado es el campo **Estado** de cada ítem; el
> diagrama lo refleja. Se mantiene al día durante todo el proyecto: se **recolorea** cuando un
> ítem cambia de estado (paso de progreso del archive) y **crece** cuando se agregan nuevos
> epics/changes (nuevos nodos y aristas). Si el backlog se divide en varios archivos, este
> diagrama es la vista consolidada de todos.

```mermaid
flowchart TD
  PRJ-001["PRJ-001 · Design system"]
  PRJ-002["PRJ-002 · CI/CD"]
  PRJ-003["PRJ-003 · …"]
  PRJ-004["PRJ-004 · …"]

  PRJ-001 --> PRJ-003
  PRJ-002 --> PRJ-003
  PRJ-003 --> PRJ-004

  classDef done fill:#bbf7d0,stroke:#16a34a,color:#14532d;
  classDef wip fill:#fef9c3,stroke:#ca8a04,color:#713f12;
  classDef pending fill:#f1f5f9,stroke:#94a3b8,color:#475569;

  class PRJ-001,PRJ-002 done;
  class PRJ-003 wip;
  class PRJ-004 pending;
```

---

## Ítems

### PRJ-001 — Design system (consolidado del prototipo)

**Estado**: ☐ Pendiente
**Origen**: inicial
**Dependencias**: ninguna
**Descripción**: Consolidar el design system que venía creciendo en el prototipo: extraerlo del
prototipo aprobado a artefacto canónico —documento de referencia + tokens en código—. Evita
divergencias de apariencia entre lo aprobado y el producto final.
**Entregables**:
- Documento de referencia del design system
- Tokens implementados en código
**Criterios de aceptación**:
- [ ] Colores, tipografía, espaciado y componentes base extraídos del prototipo aprobado
- [ ] Tokens consumibles desde el frontend

---

### PRJ-002 — CI/CD

**Estado**: ☐ Pendiente
**Origen**: inicial
**Dependencias**: ninguna
**Descripción**: Configurar el pipeline de CI/CD del proyecto en etapa temprana, según el
estándar de despliegue continuo, **e instrumentar el monitoreo mínimo** (standards §9) y el
**audit de dependencias** (standards §11).
**Entregables**:
- Pipeline funcionando (build + tests + despliegue)
- Ambientes definidos (mínimo: desarrollo y producción)
- Endpoint `/health` (responde a `HEAD` y `GET`, expone versión + git SHA —el hash del commit—)
- Error tracker cableado, con etiqueta de release/SHA
- Logger configurado: JSON en producción, nivel por variable de entorno, enmascarado de datos
  sensibles e identificador de correlación por request (backend/API)
- Snippet de analítica privacy-first
- Monitor de uptime configurado (externo al repo)
- Audit de dependencias en dos disparadores: en cada PR (Pull Request) y programado semanalmente
  sobre la rama principal
- Chequeo del tope de líneas del CLAUDE.md (`wc -l`), que falla el build al pasarse
- Bot de actualizaciones configurado (Dependabot / Renovate), si el proyecto lo adopta
**Criterios de aceptación**:
- [ ] Todo merge dispara el pipeline
- [ ] El despliegue a cada ambiente sigue los criterios definidos en estándares
- [ ] `/health` responde a `HEAD`; el error tracker recibe excepciones etiquetadas por release
- [ ] Los logs de producción salen en JSON por `stdout` y un request se puede seguir por su
      identificador de correlación
- [ ] El audit **falla el build** con severidad ≥ alta, y corre también sin que nadie abra un PR

---

### PRJ-003 — [Nombre del ítem]

**Estado**: ☐ Pendiente / 🔄 En curso ([fase OpenSpec]) / ✅ Archivado
**Origen**: [inicial / stakeholder / producción / deuda / auditoría]
**Dependencias**: [PRJ-XXX, o "ninguna"]
**Descripción**: [Qué se construye y por qué]
**Entregables**:
- [Entregable concreto]
**Criterios de aceptación**:
- [ ] [Criterio verificable 1]
- [ ] [Criterio verificable 2]
**Notas del arquitecto**: [Si las hay — decisiones de diseño relevantes para este ítem]

---

### PRJ-004 — [Nombre del ítem]

[...]