PSPO Agent

Given el usuario ejecuta el flujo de descubrimiento o análisis por primera vez y no existe docs/vision.md

When el plugin detecta que falta la visión

Then muestra un mensaje explicando qué es la visión y por qué importa, con un ejemplo concreto

Then pide al usuario que describa la visión de su producto en 2-3 frases

Then no avanza al descubrimiento ni al análisis hasta que el usuario responda

Given el usuario ha escrito la visión de su producto

When el plugin la guarda

Then crea el directorio docs/ si no existe

Then escribe docs/vision.md con la visión del usuario en formato blockquote, fecha de última actualización y firma de PSPO Agent

Then en sesiones futuras, detecta que docs/vision.md ya existe y no vuelve a preguntar

Given docs/vision.md existe y el agente product-owner va a generar historias de usuario

When el agente lee el contexto del proyecto antes de generar

Then incluye la visión como contexto de alto nivel para alinear las historias

Then si una historia generada contradice la visión, el agente lo señala al usuario antes de presentarla

Then la visión aparece referenciada en docs/backlog.md como contexto del conjunto de historias

Given el plugin está instalado y no existe un fichero .env con las variables TRELLO_API_KEY y TRELLO_TOKEN

When el usuario ejecuta cualquier comando del plugin

Then el plugin detecta que falta la configuración

Then arranca automáticamente el asistente de onboarding

Then muestra un mensaje de bienvenida explicando que va a guiarle paso a paso

Given el asistente de onboarding está en ejecución

When llega al paso de obtener la API Key

Then explica al usuario que necesita crear un Power-Up en Trello

Then le indica que visite https://trello.com/power-ups/admin

Then le pide que pegue la API Key en el terminal

Then valida que el formato es correcto (32 caracteres hexadecimales)

Given el usuario ha proporcionado la API Key y el token

When el plugin verifica la conexión

Then hace una llamada a GET /1/members/me con las credenciales

Then si la respuesta es exitosa, muestra el nombre del usuario de Trello

Then si la respuesta es un error, identifica cuál credencial es incorrecta

Then NO almacena las credenciales inválidas

Given las credenciales de Trello están verificadas y no hay TRELLO_BOARD_ID configurado

When el asistente llega al paso de configuración del tablero

Then consulta los tableros del usuario vía la API de Trello

Then muestra la lista de tableros disponibles

Then ofrece seleccionar un tablero existente o crear uno nuevo

Given el usuario elige crear un tablero nuevo

When introduce el nombre del tablero

Then crea el tablero con columnas: Backlog, Sprint activo, Bloqueada, En progreso, En revision, Hecho

Then crea etiquetas de prioridad: Crítica (rojo), Alta (naranja), Media (amarillo), Baja (azul)

Then guarda el TRELLO_BOARD_ID en .env

Then muestra la URL del tablero creado

Given el usuario activa el plugin y describe una necesidad en lenguaje natural

When el agente recibe la descripción

Then NO genera historias de usuario inmediatamente

Then formula al menos 3 preguntas de descubrimiento

Then pregunta sobre el usuario final, el problema actual, las restricciones y el resultado esperado

Given el agente ha formulado preguntas y el usuario las ha respondido

When las respuestas revelan ambigüedades o contradicciones

Then hace preguntas de seguimiento para clarificar

Then no avanza a la generación hasta que el alcance esté definido

Given el usuario proporciona una descripción con usuario, problema, contexto y restricciones

When el agente analiza la descripción

Then puede reducir el número de preguntas de descubrimiento

Then confirma con el usuario los puntos clave antes de avanzar

Given el descubrimiento está completo y el alcance está definido

When el agente genera las historias de usuario

Then cada historia sigue el formato "Como [rol específico], quiero [acción concreta], para [beneficio medible]"

Then el rol nunca es genérico ("usuario"), siempre es específico

Then cada historia es independiente y se puede entregar por separado

Then las historias están ordenadas por prioridad de valor

Given el agente ha generado una historia de usuario

When presenta los criterios de aceptación

Then cada criterio usa formato Given/When/Then

Then incluye al menos un escenario positivo (happy path)

Then incluye al menos un escenario negativo (error, entrada inválida)

Then los valores son concretos, no genéricos

Given el agente genera historias de usuario

When una historia es demasiado grande (más de 16 horas efectivas de trabajo)

Then la descompone en historias más pequeñas

Then explica cómo se relacionan entre sí

Given el agente ha generado las historias de usuario y criterios

When presenta los artefactos al usuario

Then muestra un resumen estructurado con todas las historias

Then permite aprobar, rechazar o pedir cambios en cada historia individualmente

Given el usuario aprueba algunas historias pero no todas

When confirma la selección

Then solo las historias aprobadas se marcan como listas para publicar

Then las historias pendientes quedan en estado de revisión

Given el usuario tiene un tablero configurado y las historias están aprobadas

When confirma la publicación en Trello

Then publica cada historia como una tarjeta en la columna Backlog

Then NO duplica tarjetas que ya existan (comparación por título)

Given el plugin crea una tarjeta en Trello

When la tarjeta se publica

Then el título es la historia en formato corto

Then la descripción incluye la historia completa y los criterios Given/When/Then

Then la tarjeta tiene la etiqueta de prioridad correspondiente

Given las historias están aprobadas y listas para publicar

When el usuario da la orden de publicar

Then muestra una vista previa de las tarjetas a crear

Then pide confirmación final antes de ejecutar

Given el agente ha generado y el usuario ha aprobado los artefactos

When se guardan en el sistema de ficheros

Then crea docs/vision.md con la visión de producto

Then crea docs/historias/HU-XX-titulo.md para cada historia

Then crea docs/backlog.md con la lista priorizada

Then cada fichero usa formato Markdown limpio y legible

Given el usuario tiene historias aprobadas y no existe ningún CSV de equipo compatible en la raíz del proyecto ni en .pspo-agent/inbox

When solicita planificar un sprint o distribuir historias al equipo

Then detecta que no hay equipo definido

Then ofrece dos opciones: modo guiado (pregunta miembro a miembro) o importar desde CSV

Given el usuario elige añadir miembros de forma guiada

When el plugin inicia el asistente para cada miembro

Then pregunta en secuencia: nombre, email, rol (texto libre), categoría (Junior/Mid/Senior), dedicación (0-100%) y si usa agente de IA (sí/no)

Then si el miembro usa agente IA, informa del factor de corrección del 65% configurable en settings.json

Then tras cada miembro muestra un resumen y pregunta si quiere añadir otro

Given el usuario ha confirmado la composición del equipo

When el plugin guarda los datos

Then escribe o actualiza un CSV compatible con cabecera de 6 campos: nombre,email,rol,categoria,dedicacion,usa_agente_ia

Then valida el email (contiene @ y punto), la dedicación (entre 0 y 100) y usa_agente_ia (solo sí o no)

Then en futuras sesiones, lee ese CSV automáticamente y muestra el equipo con opciones de editar, añadir o eliminar

Given hay historias aprobadas en docs/historias/ y el usuario ejecuta la planificación de sprint

When el agente presenta las historias para estimar

Then muestra la tabla de conversión configurable en settings.json: XS=1 h, S=2 h, M=4 h, L=8 h, XL=16 h

Then permite asignar tallas en formato rápido (ej: "1=M 2=XL 3=S")

Then recalcula el total en horas efectivas tras cada ajuste y espera confirmación explícita

Given las historias están estimadas y el equipo está definido en un CSV compatible con dedicación y usa_agente_ia

When el PSPO calcula la capacidad del equipo para el sprint

Then calcula horas reales de foco por miembro según duración del sprint, dedicación y horas de foco por día

Then aplica el factor IA a los miembros que usan agente: capacidad_equiv = horas_reales / (1 - factor_ia)

Then compara el total de historias contra la capacidad equivalente y muestra el porcentaje de ocupación

Then si el sprint desborda, sugiere recortar las historias de menor prioridad o puntuación

Given el PSPO presenta la propuesta completa con tabla de capacidad y veredicto

When el usuario la revisa

Then puede aprobar la distribución tal como está

Then puede modificar asignaciones individuales o ajustar tallas

Then puede rechazar y pedir nuevo análisis con criterios distintos

Given hay al menos 3 historias aprobadas y el usuario acepta la priorización asistida durante la planificación de sprint

When el agente sprint-planner analiza cada historia

Then clasifica cada historia como Bloqueante (otras dependen de ella, peso 3), Independiente (sin relaciones, peso 2) o Dependiente (necesita que otra se complete, peso 1)

Then integra la clasificación en la matriz de priorización junto con Valor de negocio y Riesgo técnico

Then las historias bloqueantes suben automáticamente en la puntuación final

Given la priorización asistida está confirmada por el usuario

When el plugin guarda la planificación del sprint en docs/sprint-plan.md

Then genera un diagrama Mermaid en docs/dependencias.md con cada historia como nodo

Then las flechas indican la dirección de dependencia (A bloquea a B)

Then las historias bloqueantes se resaltan visualmente y aparecen primero en el orden del sprint

Given el mapa está confirmado y las historias están asignadas a miembros del equipo

When el usuario pregunta qué pasa si una historia concreta se retrasa

Then recorre la cadena de dependencias hacia abajo desde esa historia

Then muestra las historias afectadas directa e indirectamente con sus asignaciones

Then calcula el radio de impacto total en horas efectivas de trabajo bloqueado

Given las historias están aprobadas, la DoD está configurada en docs/dod.md y el usuario confirma la publicación

When el plugin crea cada tarjeta en Trello

Then crea la tarjeta con descripción resumida (historia + criterios + prioridad + estimación)

Then adjunta el fichero HU-XX-titulo.md completo como archivo adjunto usando attach-file

Then añade un checklist "Definition of Done" con los criterios de docs/dod.md usando add-checklist

Then la descripción termina con "Historia completa en el fichero adjunto"

Given las historias están publicadas y las asignaciones del sprint están aprobadas

When el plugin sincroniza con Trello

Then busca cada miembro asignado por email en los miembros del tablero

Then si existe, lo asigna a la tarjeta correspondiente

Then si no existe en el tablero, lo invita por email y reutiliza el memberId devuelto antes de dar la sincronización por completada

Given el mapa de dependencias está confirmado y las tarjetas existen en Trello

When el plugin sincroniza las dependencias

Then crea un checklist "Dependencias" en cada tarjeta afectada

Then cada ítem es un enlace a la tarjeta de la que depende (formato: "HU-XX: título - url")

Then muestra vista previa completa de los cambios y pide confirmación explícita antes de ejecutar

Given el usuario pega un documento de más de 50 palabras (brief, PRD, mensaje de Slack o lista de funcionalidades)

When el agente requirement-analyst lee el documento completo sin interrumpir

Then evalúa la claridad inicial de las 8 categorías con un porcentaje individual para cada una

Then muestra el indicador global (media de las 8 categorías) y el desglose por categoría

Then informa de cuántas preguntas estima necesarias para llegar al 80%

Given el indicador de claridad muestra categorías por debajo del 80%

When el agente formula preguntas al usuario

Then pregunta una sola pregunta por mensaje, empezando por la categoría con menor claridad

Then tras cada respuesta, actualiza el indicador mostrando solo las categorías que han cambiado (ej: "Restricciones técnicas: 45% -> 75% [+30]")

Then si una categoría ya está al 80% o más, no pregunta más sobre ella salvo contradicción

Given la claridad media alcanza el 80%

When el agente presenta el resumen de validación

Then muestra un resumen de una línea por cada una de las 8 categorías

Then pide confirmación explícita al usuario antes de avanzar a la generación de historias

Then guarda el documento original y el análisis completo en docs/analisis-requisitos.md para trazabilidad

Given hay historias aprobadas en docs/historias/ y el usuario ejecuta la planificación de sprint

When el agente presenta las historias para estimar

Then muestra la tabla de conversión actual (XS=1, S=2, M=4, L=8, XL=16 horas por defecto)

Then permite asignar tallas en formato rápido con una sola línea (ej: "1=M 2=XL 3=S")

Then calcula el total en horas efectivas y muestra una tabla resumen con historia, talla, horas y prioridad

Given el usuario ha modificado los valores de conversión en settings.json (ej: XS=2, S=3, M=6, L=10, XL=16)

When el agente lee la configuración al iniciar la estimación

Then usa los valores personalizados del usuario en lugar de los valores por defecto

Then muestra la tabla de conversión activa para que el usuario sepa qué escala se está aplicando

Then si settings.json no existe o no tiene el campo stories.estimation_sizes, usa los valores por defecto sin error

Given las tallas están asignadas y confirmadas, y el equipo está definido en un CSV compatible

When el agente calcula el veredicto del sprint

Then compara el total de horas efectivas de las historias contra la capacidad equivalente del equipo (con factor IA aplicado)

Then muestra el porcentaje de ocupación del sprint

Then si la ocupación supera el 100%, sugiere recortar las historias de menor prioridad o puntuación hasta que el sprint sea viable

Given el agente product-owner ha generado historias de usuario con sus criterios de aceptación

When el contenido pasa por el agente culture-guardian antes de presentarse

Then corrige acentos y eñes (configuracion -> configuración, pequeno -> pequeño)

Then aplica títulos en minúsculas según la RAE (solo primera letra mayúscula)

Then verifica que los criterios de aceptación usan valores concretos (no "formato válido", sino "32 caracteres hexadecimales")

Then si faltan escenarios negativos, lo señala al usuario sin inventar contenido

Given las historias aprobadas van a publicarse como tarjetas en Trello

When el plugin prepara las descripciones de las tarjetas

Then pasa cada descripción por el culture-guardian para asegurar tono profesional y ortografía correcta

Then verifica que no hay muros de texto: la información clave debe ser visible de un vistazo

Then los comentarios de código se mantienen sin acentos por compatibilidad, pero el contenido visible sí los lleva

Given el usuario corrige un texto generado por el plugin durante la sesión (ej: "no uses X, prefiero Y")

When el culture-guardian detecta la corrección

Then registra el aprendizaje en la memoria de Claude Code como tipo feedback

Then en sesiones futuras, lee los aprendizajes almacenados antes de revisar cualquier contenido

Then aplica automáticamente las preferencias del usuario sin que tenga que repetir la corrección

Given el agente product-owner ha generado una historia con sus escenarios positivos y negativos

When ejecuta el análisis de edge cases

Then analiza la historia buscando edge cases en: límites de datos (strings vacíos, valores nulos, textos de 10000 caracteres), concurrencia (dos usuarios haciendo lo mismo a la vez), estado inconsistente (proceso interrumpido a mitad), permisos (acceso sin autorización) e integraciones (servicio externo no responde)

Then genera una lista de edge cases detectados con nombre descriptivo para cada uno

Given se han detectado edge cases para una historia

When el agente los presenta al usuario

Then muestra una tabla con columnas: número, descripción del edge case, impacto (Alto/Medio/Bajo) y recomendación de cobertura (Sí/No para el MVP)

Then los edge cases de impacto Alto se recomiendan siempre

Then los de impacto Bajo se sugieren para futuras iteraciones

Given el usuario selecciona los edge cases que quiere cubrir

When confirma la selección

Then genera criterios de aceptación adicionales en formato Given/When/Then para cada edge case seleccionado

Then los edge cases no seleccionados se documentan como nota al final de la historia para futuras iteraciones

Then si el usuario rechaza todos, no se añade nada pero quedan registrados en las notas