Guía del PO / funcional

Tu trabajo en una frase: defines el QUÉ y el porqué. Nunca el CÓMO. Trabajas donde ya trabajas (el gestor de proyectos), nunca entras al código.

Lo que eres dueño

• El contenido funcional de cada US: el problema, el usuario, el valor.
• Los criterios de aceptación (qué tiene que cumplirse para aceptar).
• La prioridad y el spec_version (subes la versión cuando el QUÉ cambia).
• La aceptación en la demo.

Lo que NO tocas

• Tablas, endpoints, framework, arquitectura → eso es el CÓMO, del dev.
• El código, las ramas, el implements.yaml.
• El "cómo se construye". Si te metes ahí, detente: no es tu terreno (Art. 1).

Tu día a día

1. Nace una idea — o llega un documento → creas el ticket en el gestor (nace con ID, aunque sea vago). Si en cambio partes de un documento de análisis (PDF, Word), /doc-to-backlog lo convierte en un backlog candidato de épicas + US para que priorices y valides. Y si algo es demasiado grande para una sola US, /grill-epic lo parte en varias.
2. Pulir el QUÉ → ejecutas /grill-user-story. La IA te interroga hasta que la US es testeable (INVEST + Gherkin) y la publica en el gestor. La IA no inventa requerimientos: te los saca a preguntas. Tú respondes y decides.
3. Gate 0 → ejecutas /grill-intent sobre la US ya formada. La IA te desafía el problema: ¿es el correcto? ¿quién lo sufre? ¿qué pasa si no lo hacemos? Un veredicto válido es "no lo construyas" — eso es el gate haciendo su trabajo (Art. 4).
4. Verificas el DoR → antes de que entre al sprint, la US cumple el definition-of-ready.md.
5. Editas una US que ya existe → dai edit-us ABC-482. La baja del gestor, te la abre en tu editor, valida el formato cuando guardas, te muestra qué cambia y recién ahí la sube. Ver Cuando el QUÉ cambia abajo.
6. Demo → aceptas o rechazas contra los mismos criterios que ya eran tests.

Cuando el QUÉ cambia

Un criterio que faltaba, una regla que aparece a mitad del sprint. La US vive en el gestor, no en un .md que alguien tiene que acordarse de sincronizar — así que dai la trae, te deja editarla y la devuelve:

dai edit-us ABC-482

1. Baja la US del gestor (Jira / ClickUp) a un .md.

2. La abre en tu $EDITOR. Escribes en markdown, con el molde canónico delante.

3. Valida el formato al guardar: que tenga título, que tenga criterios, y que cada criterio sea Gherkin completo (Dado / Cuando / Entonces). Si algo no da, te devuelve al editor — no te tira lo escrito.

4. Te muestra qué cambia allá arriba: título, cuántos criterios, el ac_hash.

5. Te pregunta si subir el spec_version — y esta es la decisión tuya, no de dai:

   Tu cambio	Respondes	Qué pasa
   Un criterio nuevo, una regla distinta (material)	s → v1 → v2	los repos que implementaron v1 se marcan atrasados solos
   Un typo, redacción más clara (editorial)	n → se queda en v1	nadie se marca atrasado

   dai no puede distinguir las dos cosas mirando el hash: sabe que cambió, no si importa. Eso lo sabes tú.

6. Confirmas y recién ahí escribe en el gestor. Sin confirmación no se toca nada.

--dry-run te muestra todo el preview sin escribir. Úsalo la primera vez.

Solo dos cosas te frenan: que la US no tenga título, o que no tenga criterios. Sin criterios no hay ac_hash, y sin ac_hash la US no se puede linkear a ningún repo — no es una regla de estilo, es lo que sostiene la trazabilidad. Todo lo demás (un criterio que no es Gherkin, un título largo) es un aviso: dai te lo dice y sigue.

La trampa a evitar

Criterios no testeables. "El usuario tiene una buena experiencia" no es un criterio: no se puede volver un test. La skill te va a frenar ahí — déjala. Un buen criterio es "un carrito vacío no se puede finalizar" (Art. 3).

Lo que ganas

Cuando cambias el QUÉ (subes a v2), todos los repos que implementaron la versión vieja se marcan atrasados solos. No tienes que perseguir a nadie: el @version lo grita (Art. 11). Y ves en el ticket quién ya lo implementó, sin preguntar — lo puso el CI (Art. 10).

Tus herramientas

• /doc-to-backlog — un documento (PDF/Word) → backlog candidato de épicas + US
• /grill-epic — algo grande → una épica partida en varias US
• /grill-user-story — una US funcional y testeable
• /grill-intent — Gate 0: desafía el problema de la US antes del spec
• dai edit-us <ID> — traes una US del gestor, la editas, dai valida y la devuelve
• el gestor de proyectos
• definition-of-ready.md