product-capability

Capacidad de Producto

Esta habilidad convierte la intención del producto en restricciones de ingeniería explícitas.

Úsala cuando la brecha no sea "¿qué deberíamos construir?" sino "¿qué debe ser exactamente cierto antes de que comience la implementación?"

Cuándo Usarla

• Existe un PRD, elemento de roadmap, discusión o nota del fundador, pero las restricciones de implementación aún son implícitas
• Una función abarca múltiples servicios, repositorios o equipos y necesita un contrato de capacidad antes de codificar
• La intención del producto es clara, pero las implicaciones de arquitectura, datos, ciclo de vida o políticas aún son difusas
• Ingenieros seniors siguen repitiendo las mismas suposiciones ocultas durante las revisiones
• Necesitas un artefacto reutilizable que pueda sobrevivir a través de plataformas y sesiones

Artefacto Canónico

Si el repositorio tiene un archivo de contexto de producto duradero como PRODUCT.md, docs/product/, o un directorio de especificaciones de programa, actualízalo allí.

Si aún no existe un manifiesto de capacidad, crea uno usando la plantilla en:

• docs/examples/product-capability-template.md

El objetivo no es crear otra pila de planificación. El objetivo es hacer que las restricciones de capacidad ocultas sean duraderas y reutilizables.

Reglas No Negociables

• No inventes verdades de producto. Marca las preguntas no resueltas explícitamente.
• Separa las promesas visibles para el usuario de los detalles de implementación.
• Señala qué es política fija, qué es preferencia de arquitectura y qué sigue abierto.
• Si la solicitud entra en conflicto con restricciones existentes del repositorio, dilo claramente en lugar de suavizarlo.
• Prefiere un artefacto de capacidad reutilizable sobre notas ad hoc dispersas.

Entradas

Lee solo lo necesario:

1. Intención del producto
   • issue, discusión, PRD, nota de roadmap, mensaje del fundador
2. Arquitectura actual
   • documentos del repositorio relevantes, contratos, esquemas, rutas, flujos de trabajo existentes
3. Contexto de capacidad existente
   • PRODUCT.md, documentos de diseño, RFC, notas de migración, documentos del modelo operativo
4. Restricciones de entrega
   • autenticación, facturación, cumplimiento normativo, despliegue, retrocompatibilidad, rendimiento, política de revisión

Flujo de Trabajo Principal

1. Reafirmar la capacidad

Comprime la solicitud en una declaración precisa:

• quién es el usuario u operador
• qué nueva capacidad existe después de que esto se lance
• qué resultado cambia debido a ello

Si esta declaración es débil, la implementación derivará.

2. Resolver las restricciones de capacidad

Extrae las restricciones que deben cumplirse antes de la implementación:

• reglas de negocio
• límites de alcance
• invariantes
• límites de confianza
• propiedad de datos
• transiciones de ciclo de vida
• requisitos de despliegue / migración
• expectativas de fallo y recuperación

Estas son las cosas que a menudo viven solo en la memoria del ingeniero senior.

3. Definir el contrato orientado a la implementación

Produce un plan de capacidad al estilo SRS con:

• resumen de capacidad
• no-objetivos explícitos
• actores y superficies
• estados y transiciones requeridos
• interfaces / entradas / salidas
• implicaciones del modelo de datos
• restricciones de seguridad / facturación / políticas
• requisitos de observabilidad y operador
• preguntas abiertas que bloquean la implementación

4. Traducir a ejecución

Termina con la entrega exacta:

• listo para implementación directa
• necesita revisión de arquitectura primero
• necesita aclaración de producto primero

Si es útil, apunta al siguiente carril nativo de ECC:

• project-flow-ops
• workspace-surface-audit
• api-connector-builder
• dashboard-builder
• tdd-workflow
• verification-loop

Formato de Salida

Devuelve el resultado en este orden:

CAPACIDAD
- reafirmación de un párrafo

RESTRICCIONES
- reglas fijas, invariantes y límites

CONTRATO DE IMPLEMENTACIÓN
- actores
- superficies
- estados y transiciones
- implicaciones de interfaz/datos

NO-OBJETIVOS
- lo que este carril explícitamente no posee

PREGUNTAS ABIERTAS
- bloqueadores o decisiones de producto aún requeridas

ENTREGA
- qué debería suceder a continuación y qué carril de ECC debería tomarlo

Buenos Resultados

• La intención del producto ahora es lo suficientemente concreta como para implementarla sin redescubrir restricciones ocultas a mitad de un PR.
• La revisión de ingeniería tiene un artefacto duradero en lugar de depender de la memoria o el contexto de Slack.
• El plan resultante es reutilizable en Claude Code, Codex, Cursor, OpenCode y las superficies de planificación de ECC 2.0.