# ReqFlow: contexto vigente del producto (s03)

> Contexto de trabajo de s03: no es un caso nuevo. Es **tu producto** de los Días 1 y 2 con sus contratos y restricciones vigentes. Úsalo como referencia al verificar el workspace, re-verificar hallazgos y completar el backlog.

## De dónde viene

| Artefacto | Origen | Rol hoy |
| --- | --- | --- |
| `HALLAZGOS.md` (Id `H-xx`) | Día 1 | Discovery los re-verifica; solo lo revisado entra al backlog |
| `HU-01.md`, `HU-05.md` (sección Origen) | Día 2 | Reutiliza los issues existentes de backend y frontend; el recorrido guiado trabaja sobre backend |
| Project `ReqFlow` + issues | Día 2 | Se reutiliza, no se recrea |
| `docs/ENDPOINTS.md` | Día 1 | Baseline de comportamiento para las specs de s04 |
| `docs/TESTING.md` | Día 1 | Pruebas de caracterización que ya existen |

## Producto multi-repositorio

ReqFlow es el portal interno de requerimientos tecnológicos de la empresa ficticia Nuvexa Andina Digital S.A., formado por tres repositorios coordinados (tus copias propias bajo tu owner, publicadas el Día 1):

| Repositorio | Tecnología | Responsabilidad |
| --- | --- | --- |
| `workshop-login-frontend` | Angular / TypeScript | Login, sesión, dashboard y experiencia de usuario |
| `workshop-auth-backend` | Java / Quarkus | Credenciales, autenticación y emisión de token |
| `workshop-requirements-api` | Python / FastAPI | Tareas, resumen, autorización y carga de requerimientos |

## Contratos funcionales protegidos

Durante el workshop no deben romperse estos contratos sin una decisión explícita:

```text
POST /auth/login
GET/POST /api/tasks
GET /api/summary
POST /api/requirements
```

## Criterios funcionales mínimos

- un usuario válido puede iniciar sesión;
- el dashboard consume únicamente información permitida para la identidad autenticada;
- la API permite listar y crear tareas preservando identidad y autorización;
- el dashboard obtiene un resumen de estados coherente;
- el usuario puede adjuntar un archivo permitido dentro de límites controlados;
- todo cambio llega mediante `feature/* -> PR -> main/CERT -> tag/release` simulado.

## Guardrails

No se permite:

- reescribir la solución completa;
- utilizar datos, credenciales, secretos o archivos reales;
- realizar pruebas ofensivas fuera del laboratorio;
- desactivar tests, CodeQL, SCA o quality gates para forzar un merge;
- aceptar una solución generada por IA sin comprenderla y validarla.

## Discovery en el Día 3: re-verificación, no descubrimiento

Los hallazgos ya se descubrieron el Día 1. Aquí el agente Discovery los **re-verifica** contra el código actual antes de convertirlos en backlog. Un hallazgo entra al Project solo si pasa estas preguntas:

```text
¿Qué observaste?
¿Dónde está la evidencia?
¿Por qué importa?
¿Qué contrato podría afectar?
¿Cómo lo probarías?
```

Un buen resultado no es una lista genérica producida por el modelo: cada issue creado cita su `H-xx` y su evidencia `archivo:línea`.

## Definition of Done

La DoD operativa del día vive en el skill `reqflow-definition-of-done` y en el [cierre del día](../README.md#cierre-del-día-handoff-al-día-4) (specs aprobadas, agentes y skills versionados, PR con DoD, issue en `Todo`). La misión completa del caso (contratos preservados, CI en verde, cobertura crítica >= 85 %, dependencias controladas, secure coding, PR auditable con decisiones, trade-offs, riesgos residuales y rollback) se demuestra entre los Días 3 y 4: hoy se prepara el producto y se demuestra el ciclo SDD sobre `workshop-auth-backend`; el resto queda como challenge y harness del Día 4.