# Descubrimiento y definición de alcance

Convierte una petición en un alcance que se pueda estimar, dotar de equipo y entregar — con todo lo que sigue siendo desconocido nombrado en lugar de rellenado.

## Entregable

Un documento Markdown, `scope-definition.md`, con la estructura fijada en **Salida** más abajo. Es la entrada de **Hoja de ruta y priorización**.

## Entradas obligatorias

- **La petición, en palabras de quien la hace** — un briefing, un correo, un ticket o la transcripción de una reunión. Con una basta; cuantas más, mejor.
- **Una persona aprobadora con nombre** — quien puede dar por bueno el enunciado del resultado. Sin ella lo que queda es una propuesta, no un alcance.

Si falta cualquiera de las dos, detente y repórtalo. Nunca deduzcas la petición del código: el código muestra qué se construyó, no qué se quería.

## Entradas opcionales

- Acceso al repositorio, documentación de sistemas, esquemas, contratos de API
- Descripciones de flujos de trabajo, tickets de soporte, entrevistas, analítica
- Presupuesto, plazo, restricciones regulatorias o contractuales
- Intentos anteriores sobre el mismo problema y por qué se detuvieron

Cada entrada opcional que falte pasa a **Preguntas abiertas**. Nunca se convierte en una conjetura.

## Ejecución

**1 — Separar la petición del problema.** Registra la petición literal con su fuente y su fecha. Enuncia el problema que implica: quién lo tiene, con qué frecuencia y qué le cuesta ahora. Si el problema no se puede enunciar sin nombrar una funcionalidad, el problema todavía no se conoce: déjalo escrito y continúa.

**2 — Inventariar el estado actual.** Solo a partir del material aportado, lista los sistemas, almacenes de datos, integraciones y apaños manuales del camino que se va a cambiar. Marca cada elemento como `observado` si aparece en un archivo o sistema al que se te dio acceso, o `reportado` si lo afirmó una persona. Un elemento que no sea ninguno de los dos no entra en la lista.

**3 — Redactar el resultado y su medida.** Una frase sobre qué debe ser observablemente distinto tras el lanzamiento; una métrica; su valor actual; su objetivo. Un valor actual que no se haya aportado se escribe `desconocido — necesario antes de aprobar`, nunca se estima.

**4 — Registrar las restricciones.** Presupuesto, fechas, regulación, sistemas que no se pueden cambiar, integraciones que deben seguir funcionando. Cada una con la fuente que la enunció. Una restricción sin fuente es una suposición y se archiva como tal.

**5 — Recortar el alcance en tres.** `Entra primero`, `Aplazado`, `Fuera de alcance`. Un elemento de `Entra primero` debe ser útil por sí solo y debe poder trazarse hasta el resultado del paso 3. El que no se trace a nada pasa a `Aplazado` o a `Fuera de alcance`, con el motivo por escrito.

**6 — Etiquetar cada afirmación.** `hecho` con su fuente, `suposición` con lo que la confirmaría, o `decisión` con quién la tomó y cuándo. Una afirmación sin etiqueta es un defecto del documento, no un atajo.

**7 — Reunir lo que falta.** Cada pregunta que los pasos anteriores no pudieron responder, con lo que bloquea y quién puede responderla.

## Salida

`scope-definition.md`, en este orden:

- **1. Petición tal como se recibió** — literal, con fuente y fecha
- **2. Enunciado del problema** — quién, con qué frecuencia, qué cuesta, etiquetado
- **3. Resultado y medida** — resultado, métrica, valor actual, objetivo, aprobador
- **4. Estado actual** — una línea por elemento: nombre, tipo, `observado` o `reportado`, y la evidencia
- **5. Restricciones** — una línea cada una: restricción, valor, fuente
- **6. Alcance** — las tres listas; cada elemento de `Entra primero` nombra el resultado al que sirve, cada `Aplazado` la condición que lo adelantaría, cada `Fuera de alcance` por qué queda fuera
- **7. Suposiciones y riesgos** — la afirmación, qué la confirmaría y qué cambia si resulta falsa
- **8. Decisiones** — la decisión, quién la tomó, cuándo y las alternativas descartadas
- **9. Preguntas abiertas** — la pregunta, qué bloquea, quién puede responderla

## Validación

El documento está listo cuando se cumple todo esto:

- La sección 3 nombra a un aprobador y una métrica; el objetivo puede decir `lo fijará <nombre>`
- Cada elemento de `Entra primero` se traza hasta el resultado de la sección 3
- Cada afirmación de las secciones 2 a 6 está etiquetada como `hecho`, `suposición` o `decisión`
- Ninguna cifra aparece sin fuente; `desconocido` es una entrada válida y esperada
- La sección 9 no está vacía, o declara explícitamente que no queda nada pendiente

Falla la ejecución si un elemento de `Entra primero` no se traza a nada, o si alguna cifra del documento no tiene fuente.

## Gestión de fallos

- **No hay petición** — detente. Informa de que el descubrimiento no tiene entrada y no puede deducirla.
- **No hay aprobador** — produce las nueve secciones y marca la sección 3 como `SIN APROBAR`. Un alcance en ese estado no se puede estimar.
- **Sin acceso al sistema existente** — la sección 4 queda solo como `reportado`. Declara con claridad que no se verificó nada y que toda estimación posterior hereda esa incertidumbre.
- **Entradas contradictorias** — registra las dos, nombra ambas fuentes y eleva la contradicción a la sección 9 como bloqueante. No la resuelvas eligiendo.
- **Material parcial** — produce cada sección que el material sostenga, marca el resto como `INCOMPLETO — pendiente de <pregunta>` y entrega. Un alcance parcial honesto sobre sus huecos es utilizable; uno que parece completo porque los rellenó, no.