Refinamiento de Requisitos (Discovery)

Descubrimiento (Discovery)

Convierta aportes no estructurados de partes interesadas en requisitos trazables mediante un examen socrático. Usted no es un transcriptor: capture lo que se dijo y lo que se implicó, señale ambigüedades y produzca historias candidatas que /refine-story lleve a la planificación del sprint. Lo que el aporte no respalda no ingresa; lo que sugiere ingresa como una inferencia fundamentada; lo que deja abierto se convierte en una pregunta.

Entrada: $ARGUMENTS

Antes de empezar

Lea docs/agents/refinement.md en el espacio de trabajo: define el modo de operación, el idioma (en-US o pt-BR, predeterminado en-US) y las rutas de publicación. Si falta, solicite /configure-refinement y deténgase. Si el argumento es una especificación con Status: open map (o Status: mapa aberto), salte directamente a "Reanudar mapa de decisiones". Si la entrada provino de /meeting-minutes, ya separa los hechos declarados de las presunciones: trate los acuerdos presuntos como no confirmados. El examen y las especificaciones generadas siguen el idioma del espacio de trabajo configurado.

Pasos

1. Cargar y triage. Lea la entrada, CONTEXT.md e invoque la herramienta Skill para requirements-rigor. Escanee en busca de antipatrones (lea ANTI-PATTERNS.md en requirements-rigor por separado) y términos que siempre activan preguntas: este escaneo fundamenta el triage. Clasifique contando fragmentos, no el volumen de texto: UTILIZABLE (cada fragmento estructura un requisito), PARCIALMENTE UTILIZABLE (al menos un fragmento estructura un requisito y al menos uno no), INUTILIZABLE (ningún fragmento estructura un requisito). INUTILIZABLE: indíquelo con una justificación fragmento por fragmento, enumere de 3 a 5 preguntas mínimas con destinatarios (quien haya proporcionado la entrada, a menos que se pueda identificar un rol de dominio en el glosario), redacte un cuestionario siguiendo QUESTIONNAIRE.md en requirements-rigor, informe al usuario que /requirements-discovery se volverá a ejecutar con las respuestas, y deténgase sin publicar más artefactos; las historias de relleno no ayudan a nadie. PARCIAL: proceda, y el artefacto final comienza con una lista de fragmentos no utilizados y lo que falta en cada uno. Completado cuando: la clasificación está indicada en una sola línea, seguida de una justificación fragmento por fragmento cuando no sea UTILIZABLE.

2. Mapeo en amplitud. Antes de generar cualquier historia, escanee la entrada completa: dominios de negocio con niveles de confianza (Alto, Medio, Bajo; Bajo marca donde el descubrimiento requiere una conversación de seguimiento), partes interesadas con tipo (negocio, técnico, usuario final) y lo que defiende cada uno, épicas con complejidad S, M, L o XL justificada en una sola línea; los fragmentos sin listas cerradas o criterios medibles no se convierten en épicas aún, permaneciendo en procesamiento parcial hasta que el examen los dimensione. Cuando la entrada es de segunda mano, el tomador de notas ingresa en la tabla de partes interesadas con el tipo "fuente". Dos voces en posiciones opuestas sobre el mismo requisito: agregue [CONFLICTO], registrando ambas posiciones sin resolver unilateralmente. Un requisito expresado por una sola voz recibe [VALIDAR CON EQUIPO] cuando la confirmación es crítica: necesidades de rol no cubiertas, decisiones de alcance tomadas por quienes no toman decisiones; no marque todo cuando dos voces abordan temas inconexos. Las necesidades de negocio y las restricciones técnicas se originan de diferentes partes interesadas y tienen diferente peso: distíngalas. Completado cuando: cada fragmento de entrada está mapeado a un dominio y una épica, o listado como no explotado.

3. Buscar hechos antes de preguntar. Consulte el glosario, historias anteriores en .scratch/, documentos del espacio de trabajo y, en modo código, la base de código: ¿la integración mencionada ya existe? ¿El umbral ya está implementado? Un hecho encontrado se convierte en una respuesta recomendada con la fuente citada. En modo sin código, la búsqueda se limita a archivos del espacio de trabajo sin subagentes; si no se encuentra nada, indíquelo en una sola línea al inicio de la ronda 1. Completado cuando: cada pregunta candidata está marcada como respondida por una fuente o abierta.

4. Decidir el tamaño del alcance. Invoque la herramienta Skill para socratic-examination y examine en amplitud: el resultado objetivo (lo que este descubrimiento entrega), los límites del alcance, los conflictos y los factores que afectan el tamaño de la épica. Los SLA, canales y casos extremos representan profundidad y se posponen al paso 5. Si al final de esta ronda la frontera cabe en una sola sesión, proceda al paso 5. Si queda niebla sustancial (decisiones anticipadas pero aún no formulables porque dependen de respuestas pendientes), abra el mapa: publique la especificación siguiendo TEMPLATE.md con Status: open map, una decisión pendiente por archivo en issues/NN-decision-<slug>.md para cada pregunta formulable, marcando Blocked by: cuando dependa de otra, y la niebla no formulable en "Aún no especificado". La distinción entre una decisión y la niebla es si puede formular la pregunta con precisión ahora mismo, no si puede responderla. Mapear la niebla es el objetivo de una sesión: deténgase e informe al usuario que /requirements-discovery <spec-path> resuelve una decisión por sesión. Completado cuando: la frontera de preguntas cabe en una sola sesión, o existe la especificación con un mapa abierto y archivos de decisión pendientes.

5. Examinar. Continúe rondas de socratic-examination en profundidad, épica por épica: roles, capacidades, resultados, casos extremos sugeridos por la entrada, dependencias. Los términos del dominio resueltos se agregan a CONTEXT.md de inmediato. Un hecho que ningún asistente conoce recibe [TO CONFIRM: a quién] (o [A CONFIRMAR: quem]) y deja la frontera. Completado cuando: la frontera está vacía, o el usuario solicita cerrar.

6. Sintetizar. Redacte la especificación de descubrimiento siguiendo TEMPLATE.md y una historia candidata por archivo siguiendo skills/refine-story/TEMPLATE.md, con Status: candidate (o Status: candidata) y una tarjeta de puntuación INVEST preliminar. Una historia que falla INVEST no se convierte en una tarjeta limpia: permanece como candidata con [INVEST-FAIL] y orientación para resolverla. Incluya dependencias no declaradas: integraciones, servicios externos y decisiones arquitectónicas necesarias para que las historias sean implementables, cada una emparejada con la historia bloqueada y la acción requerida. Cada línea en las historias candidatas coincide con la entrada o una [INFERENCE: base] válida; las adiciones no respaldadas son "plata" y deben eliminarse. Completado cuando: la especificación y las historias candidatas existen en la ruta definida en docs/agents/refinement.md, con el descargo de responsabilidad final.

7. Enrutar elementos abiertos. Elementos [TO CONFIRM] abiertos con destinatarios fuera de la sesión: redacte un cuestionario por destinatario siguiendo QUESTIONNAIRE.md en requirements-rigor, junto con la especificación. Completado cuando: no queda ninguna pregunta abierta sin destinatario o cuestionario.

8. Informar. Épicas creadas, cantidad de historias candidatas, conflictos abiertos y próximos pasos: /refine-story por historia, o /requirements-discovery <spec-path> si el mapa está abierto.

Reanudar mapa de decisiones

Cuando el argumento es una especificación con Status: open map:

1. Lea la especificación completa y las decisiones pendientes en issues/. Una decisión está desbloqueada cuando está abierta y todas las decisiones en Blocked by: están resueltas. Completado cuando: sepa qué decisiones están desbloqueadas.
2. Seleccione la decisión: nombrada por el usuario, o la primera desbloqueada por número. Marque Status: in examination en el archivo antes de comenzar, evitando que sesiones concurrentes la tomen. Completado cuando: el estado del archivo esté actualizado.
3. Resuélvala con socratic-examination, una decisión por sesión. Las decisiones de tipo investigación se resuelven leyendo fuentes externas con citas, sin rondas de examen. Registre la respuesta directamente en el archivo bajo ## Answer, marque Status: resolved, y agregue una línea con resumen y ruta en la sección "Decisiones de examen" de la especificación. Completado cuando: la decisión está resuelta y vinculada desde la especificación.
4. La respuesta puede despejar la niebla circundante: los elementos recién formulables salen de "Aún no especificado" y se convierten en nuevas decisiones pendientes; los elementos fuera del alcance pasan a "Fuera de alcance". Cualquier decisión invalidada por la respuesta se cierra con una justificación de una línea. Completado cuando: ninguna decisión pendiente contradice la respuesta y la niebla se reevalúa.
5. Sin decisiones pendientes abiertas: actualice la especificación a Status: in progress y proceda al paso 5 de los pasos principales, en la misma sesión si el contexto lo permite, o en la siguiente sesión usando el mismo comando. Completado cuando: la especificación sale del estado de mapa abierto, o informa cuántas decisiones quedan.

Formato de decisión pendiente:

# Decisión NN: <pregunta en una oración>

Status: <open | in examination | resolved | closed>
Blocked by: <NN, NN or none>
Type: <examination | research>

## Pregunta

<qué debe decidirse y por qué bloquea el progreso>

## Respuesta

<al resolverse: decisión, quién decidió, fecha>

Aviso final

⚠️ Esta salida es un borrador analítico. Requiere revisión humana antes de ingresar a un sprint. Valide: viabilidad técnica, cumplimiento normativo y dependencias no mapeadas.