Constructor de PRD para Plataforma

¿Qué hace Constructor de PRD para Plataforma?

Usa esta habilidad para convertir entradas informes en requisitos de producto estructurados y listos para implementación. No te limites a traducir. Comprende, reorganiza, enriquece y preserva el alcance preciso.

Modos Operativos

Elige el modo más ligero que satisfaga la solicitud:

• Construcción de PRD completo: crea un PRD completo para un requisito complejo o entre sistemas.
• Construcción de sección: escribe solo las secciones solicitadas, como antecedentes, alcance, flujo, cambios de API/datos o despliegue.
• Reescritura / pulido: mejora la estructura, claridad, inglés o redacción bilingüe sin cambiar las decisiones.
• Normalización de entrada: convierte notas dispersas en decisiones confirmadas, suposiciones, decisiones faltantes y lenguaje legible por ingeniería antes de redactar.
• Ajuste de plantilla: elige el tipo de artefacto correcto cuando la solicitud no es necesariamente un PRD completo.
• Borrador de alineación de dirección: crea un concepto/versión de alineación ligero antes de expandirlo a un PRD completo.

Primer Movimiento

Identifica brevemente:

• escenario de negocio
• capacidad de plataforma
• sistemas involucrados
• fase actual y exclusiones
• tipo de artefacto: PRD completo, sección de PRD, BRD de una página, borrador bilingüe, reescritura en inglés, tabla o descripción de flujo

Si el usuario solo solicita impacto o viabilidad, no redactes el PRD aún; utiliza primero el análisis de impacto.

Si el tipo de artefacto no está claro, propón el artefacto útil más pequeño y continúa a menos que esa elección genere riesgo de entrega.

Paso 0: Detección de Etapa

Antes de redactar, clasifica la etapa del usuario:

• Solo idea: crea primero un borrador de alineación de dirección.
• Notas dispersas: normaliza primero las decisiones, suposiciones y decisiones faltantes.
• Alcance no definido: deriva a platform-scope-checker antes de redactar los requisitos de la fase actual.
• Listo para redactar: construye el PRD o sección solicitado.
• Borrador existente: mejora la estructura o deriva a platform-prd-reviewer si el usuario quiere retroalimentación.
• Solicitud de detalle de RFC: mantén la semántica de producto en el PRD y deriva los detalles de implementación al seguimiento de ingeniería.

Portal de Desafío de Construcción

Antes de convertir una solicitud en un PRD pesado, desafía brevemente si el mismo objetivo comercial se puede lograr mediante:

• capacidad de plataforma existente
• configuración
• proceso operativo o manejo manual temporal
• cambio de flujo de trabajo más pequeño
• despliegue por fases
• marcador de posición de compatibilidad sin implementar el comportamiento completo de la fase actual

Si la respuesta no está clara o el riesgo de construcción es alto, recomienda una verificación de alcance antes de escribir un PRD completo.

Entrega en Dos Fases

Para requisitos ambiguos, de 0 a 1 o entre sistemas grandes, prefiere dos fases:

1. Borrador de alineación de dirección: problema, usuarios/operaciones objetivo, capacidad de plataforma, límite de alcance, flujo central, propiedad, suposiciones y decisiones abiertas.
2. PRD detallado: requisitos por sistema, cambios de campo/API/datos, estados/casos límite, despliegue/operaciones, criterios de aceptación y riesgos.

No saltes al PRD detallado cuando la dirección del producto principal, el límite del MVP o la fuente de verdad aún no estén definidos.

Cuándo NO Usar

No uses esta habilidad como primer movimiento cuando:

• el problema de negocio o el usuario objetivo aún están en disputa; primero aclara la dirección con platform-product-guide
• la pregunta es "¿deberíamos hacer esto ahora?"; primero usa platform-scope-checker
• el usuario solo quiere retroalimentación de revisión sobre un artefacto existente; usa platform-prd-reviewer
• la solicitud es un RFC de ingeniería puro, diseño de código o plan de implementación sin trabajo de requisitos de producto

Normalizador de Entrada de PM

Cuando la entrada es vaga, no técnica o está escrita como notas dispersas, primero tradúcela a decisiones de producto legibles por ingeniería antes de redactar. No obligues al usuario a usar vocabulario técnico.

Usa esta salida ligera cuando falten decisiones:

Decisiones Conocidas
- ...

Decisiones Faltantes
- ...

Traducción Relevante para Ingeniería
- "Necesito un registro de aprobación" significa que se necesitan decisiones sobre campos de registro de auditoría, momento de escritura, acceso de consulta y retención.
- "Notificar a otro sistema" significa que se necesitan decisiones sobre el momento de la devolución de llamada, reintento, tiempo de espera, manejo de fallos y consistencia de estado.

Haz preguntas en lenguaje de negocio en lugar de preguntas técnicas:

• En lugar de "¿Cuál es la clave de idempotencia?", pregunta "Si se envía la misma solicitud dos veces, ¿debería el sistema crear un nuevo registro, rechazarlo o devolver el existente?"
• En lugar de "¿Cuál es la estrategia de reintento de la devolución de llamada?", pregunta "Si el sistema receptor no puede ser notificado, ¿qué deberían ver los usuarios, quién lo soluciona y cuánto tiempo puede permanecer sin resolver?"
• En lugar de "¿Quién es la fuente de verdad?", pregunta "Si dos sistemas muestran estados diferentes, ¿cuál se debe confiar?"
• En lugar de "¿Cuál es la estrategia de compatibilidad?", pregunta "¿Los registros existentes o los procesos en curso se verán afectados después del lanzamiento?"
• En lugar de "Define una máquina de estados", pregunta "¿Qué estados puede tener esta solicitud desde la creación hasta la finalización, y qué acciones están permitidas en cada estado?"

Libro de Suposiciones y Evidencia

Cuando las decisiones importantes se infieren de notas aproximadas, hazlas explícitas antes de finalizar:

Suposiciones
- A1: ...

Evidencia / Fuente
- E1: De nota de usuario / prototipo / PRD anterior / nota de reunión / instrucción explícita

Necesita Confirmación
- C1: ...

No conviertas silenciosamente suposiciones en requisitos. Si el usuario pide continuar, mantén los elementos no resueltos en Preguntas Abiertas con propietario/dependencia cuando se conozca.

Selección de Plantilla

Elige la plantilla según el tipo de artefacto en lugar de forzar una estructura pesada.

PRD de funcionalidad corta:

• Antecedentes
• Objetivo
• Alcance
• Requisitos
• API / Cambios de datos
• Casos límite
• Adjuntos / Enlaces

Nota de cambio de API / campo:

• Antecedentes
• Contrato modificado
• Tabla de campos
• Validación / Comportamiento predeterminado
• Compatibilidad hacia atrás
• Consumidores descendentes
• Ejemplos

PRD de UI de configuración:

• Antecedentes
• Objetivo
• Ruta de página / Entrada
• Campos de lista
• Comportamiento de filtro / consulta
• Comportamiento de creación / edición
• Reglas de validación
• Permisos / Auditoría
• Adjuntos / Prototipo

PRD de migración:

• Antecedentes
• Alcance
• Sistemas de origen / destino
• Flujo de migración
• Mapeo de datos
• Lista de verificación de validación / conciliación
• Migración / Reversión
• Preguntas abiertas

PRD de fórmula / lógica de reglas:

• Antecedentes
• Formato de regla
• Definiciones de campo
• Lógica de procesamiento
• Ejemplos
• Casos límite
• Compatibilidad hacia atrás

Estructura de PRD Predeterminada

Usa esta estructura a menos que el usuario proporcione una plantilla diferente:

1. Antecedentes
2. Objetivo
3. Alcance
4. Actores / Sistemas
5. Flujo General
6. Detalles del Flujo
7. Requisitos por Sistema
8. API / Cambios de Datos
9. Escenarios y Casos Límite
10. Despliegue / Operaciones
11. Preguntas Abiertas
12. Dependencias / Riesgos

Para secciones cortas, mantén solo los encabezados relevantes pero preserva el mismo orden de pensamiento.

Usa el Modelador de Flujo de Plataforma Cuando

Usa platform-flow-modeler antes de escribir las secciones de Flujo General, Detalles del Flujo, Escenarios y Casos Límite, Transición de Estados u Operaciones cuando el requisito involucre 3+ sistemas, cambios de ciclo de vida/estado, devolución de llamada/reintento/tiempo de espera, reversión/cancelación/reenvío, conciliación, liquidación, migración o respaldo manual.

Permite que primero dé forma a las tablas de flujo, luego convierte esas tablas en prosa de PRD, requisitos por sistema, escenarios, criterios de aceptación y preguntas abiertas.

Contrato de Salida

Cada salida con estilo PRD debe hacer que estas cosas sean comprobables:

• Problema y "por qué ahora"
• Objetivo de la fase actual
• Límites del alcance
• Flujo principal y flujos de excepción clave
• Decisiones de producto aún abiertas
• Criterios de aceptación o matriz de escenarios
• Propietario/fuente de verdad para el comportamiento entre sistemas
• Despliegue, reversión o manejo manual temporal cuando sea relevante

Forma de respuesta predeterminada:

1. Breve nota sobre el tipo de artefacto seleccionado, cuando sea útil
2. Contenido del PRD redactado o sección solicitada
3. Suposiciones y decisiones abiertas, si las hay
4. Sugerencia de la próxima ruta de revisión: verificación de alcance, revisión de PRD, seguimiento de RFC o confirmación de las partes interesadas

Esta habilidad debe producir un artefacto, no solo consejo. Si el artefacto no se puede producir de manera segura, genera el libro de decisiones faltantes y la siguiente acción.

Para plantillas de PRD detalladas y contratos de salida específicos de artefactos, lee references/prd-output-contract.md cuando la tarea implique un PRD completo, un PRD de plataforma de 0 a 1, un PRD de migración, un PRD de UI de configuración o una nota de cambio de API/datos.

Escenarios y Criterios de Aceptación

Para las secciones de Escenarios y Casos Límite, usa criterios de aceptación Dado/Cuando/Entonces cuando mejore la alineación de QA e ingeniería:

**Escenario: [nombre]**
- Dado: [precondición: estado del sistema, actor, datos, configuración]
- Cuando: [acción desencadenante]
- Entonces: [resultado esperado: estado final, resultado visible para el usuario/operaciones, sincronización descendente, registro de auditoría]

Cubre estos tipos de escenarios cuando sea relevante:

• Camino feliz
• Falla de validación: campo faltante, valor no válido, envío duplicado
• Falla del sistema descendente: tiempo de espera de devolución de llamada, error de API, falla parcial
• Envío concurrente o duplicado
• Caso límite de transición de estado: reenvío desde estado terminal, cancelación en medio del flujo
• Reversión o restauración
• Respaldo manual: intervención de operaciones o entrada en cola de excepción
• Límite de permiso: actor no permitido o falta de coincidencia del sistema de origen

Haz que cada cláusula Entonces sea comprobable. Nombra el estado final, el resultado visible para el usuario/operaciones, si los sistemas descendentes son notificados y si se crea un registro de auditoría/evento.

Si la matriz de escenarios es grande, usa una tabla compacta:

Escenario	Precondición	Desencadenante	Estado Final	Resultado para Usuario/Operaciones	Descendente	Auditoría

Estilo de Tabla de API / Datos

Para cambios de API o datos, usa por defecto tablas con:

• Campo
• Tipo de Dato / Tipo
• Obligatorio
• Valor / Validación
• Descripción
• Ejemplo
• Tipo de Cambio: nuevo / existente / eliminado, cuando sea relevante
• Propietario / Consumidor, cuando la propiedad sea importante

Adiciones para PRD de Plataforma de 0 a 1

Para nuevas capacidades de plataforma/infraestructura, agrega:

• dirección de plataforma y principios de diseño
• objetos de configuración vs objetos de ejecución
• tabla de propiedad/fuente de verdad
• ciclo de vida/máquina de estados
• comportamiento de versionado y snapshot
• comportamiento de devolución de llamada, reintento, tiempo de espera e idempotencia
• registro de auditoría/eventos
• permisos y aislamiento del sistema de origen
• exclusiones del MVP e iteración futura
• modelo de UI/espacio de trabajo por rol, ámbito de datos y región operativa

Reglas de Escritura

• Convierte notas aproximadas en inglés profesional cuando se solicite salida en inglés.
• Preserva la terminología mixta chino/inglés cuando refleje nombres de sistemas reales o artefactos de equipo.
• Agrega la explicación faltante necesaria para que los lectores comprendan e implementen, pero no inventes decisiones de negocio.
• Si la calidad de la entrada es desigual, normalízala en capa de negocio y capa de colaboración de ingeniería antes de escribir el PRD final.
• Usa jerarquía numerada para la revisabilidad.
• Usa tablas para campos, API, propiedad, escenarios, cálculos, transiciones de estado y preguntas abiertas.
• Separa los requisitos por sistema cuando cambien múltiples sistemas.
• Mantén las secciones legibles por producto; mueve los detalles de bajo nivel a las secciones de API/datos o preguntas abiertas.
• Sigue los prototipos proporcionados o la estructura de PRD existente cuando el usuario diga que se base en ellos.

Disciplina de Alcance

Siempre separa:

• Dentro del Alcance
• Fuera del Alcance
• No Compatible en Esta Fase
• Iteración Futura

No incluyas características de fases futuras en los requisitos de la fase actual, excepto como exclusiones explícitas, notas de compatibilidad o iteración futura.

Requisitos de Flujo y Datos

Para trabajo entre sistemas:

• describe los flujos de creación/consulta/devolución de llamada/actualización/liquidación/conciliación por separado cuando sea relevante
• identifica los puntos de persistencia y los cambios de estado
• define los campos de tiempo de configuración por separado de los campos de tiempo de ejecución
• distingue los campos de snapshot de los campos resueltos dinámicamente
• usa los nombres de campo con cuidado; la nomenclatura singular/plural puede codificar el alcance, como portalCode vs portalCodes

Barreras de Seguridad

• Trata los PRD históricos como material de aprendizaje/referencia a menos que el usuario pida reescribirlos.
• No inyectes contexto no relacionado de proyectos anteriores.
• No generes código cuando el usuario solicite requisitos.
• No sobrepulir con lenguaje de marketing.
• No ocultes decisiones abiertas; enuméralas claramente con propietario/dependencia cuando se conozca.

Errores Comunes a Señalar

• Redactar requisitos detallados antes de que la alineación de dirección esté lista.
• Convertir suposiciones en requisitos sin etiquetarlas.
• Mezclar el MVP actual con el comportamiento de iteración futura.
• Escribir solo comportamiento de página/botón mientras se dejan implícitos los estados, la propiedad y el manejo de excepciones.
• Sobre-prescribir el diseño de base de datos, cola, trabajo de reintento o servicio en el PRD.
• Tratar una solicitud de implementación como lista para producto sin verificar el objetivo de negocio y el límite del alcance.

Enrutamiento

• Deriva a platform-product-guide cuando la dirección del negocio, la abstracción de plataforma o el marco de decisiones no estén listos.
• Deriva las secciones con muchos flujos a platform-flow-modeler antes de convertirlas en contenido de PRD.
• Deriva a platform-scope-checker cuando la inclusión de la fase actual, el tamaño del MVP o la complejidad oculta no estén resueltos.
• Deriva a platform-prd-reviewer después de redactar cuando el usuario quiera preparación, brechas o puntuación.
• Deriva las preguntas de implementación a nivel de RFC al seguimiento de ingeniería mientras mantienes la semántica del producto en el PRD.

Lista de Verificación de Calidad

Antes de finalizar, verifica:

• El documento explica qué construir y por qué.
• El alcance es explícito: dentro del alcance, fuera del alcance, no compatible ahora, futuro.
• Los requisitos son suficientemente comprobables para QA o revisión de ingeniería.
• La propiedad entre sistemas y la fuente de verdad son visibles.
• Las suposiciones están separadas de las decisiones confirmadas.
• Las consideraciones técnicas se presentan sin sobre-prescribir la implementación.
• La próxima ruta o paso de revisión es explícito.

Referencias

• references/prd-output-contract.md: cárgalo cuando se necesite una plantilla detallada, un contrato específico de artefacto o una lista de verificación de calidad.