quinotospec-create-proposal

Workflow: Create Proposal

Analiza exhaustivamente la información del Discovery (.quinoto-spec/discovery/), poniendo atención especial a 01-stack-profile.md para adaptar la arquitectura y el código al stack del proyecto, y a 08-product-and-agreements.md para alinear la propuesta con la visión de producto y los acuerdos de trabajo (DoR/DoD). También revisa otras propuestas existentes en .quinoto-spec/proposals/ para asegurar consistencia global y detectar posibles conflictos o solapamientos de alcance (mismos archivos, dominios o flujos afectados); si detectas alguno, documéntalo al inicio de la propuesta bajo **⚠️ Conflictos Detectados:**. El objetivo es generar una Propuesta Técnica específica para: "{{PROPOSAL_DESCRIPTION}}".

Flags:

• --party [agents]: Ejecuta Party Mode con los agentes especificados ANTES de generar la propuesta. El debate multi-agente enriquece la propuesta con perspectivas cruzadas. Si no se especifican agentes, se auto-seleccionan los mas relevantes segun el tema.
• --party-output <path>: Donde guardar la transcripcion del Party Mode (default: .quinoto-spec/proposals/{{DATE_PREFIX}}-{{PROPOSAL_SLUG}}/party-analysis.md)

PROPOSAL_NAME: deriva un nombre a partir de PROPOSAL_DESCRIPTION. Debe estar en español o inglés técnico, en Title Case, descriptivo y conciso (ej. Rewards Stabilization, Payment Timeout Fix, Refactor Auth Layer). PROPOSAL_SLUG: derivar de PROPOSAL_NAME en lowercase con palabras separadas por guión (ej. rewards-stabilization, payment-timeout-fix). DATE_PREFIX: fecha actual en formato YYYY-MM-DD. Tu objetivo es generar una Propuesta Técnica específica para este tema, INTEGRADA con el resto del sistema.

Contrato de artefactos — OBLIGATORIO: Antes de generar archivos, ejecuta python3 agent-dist/skills/quinotospec-contract/contract.py validate --root . --strict. El proposal debe incluir **ID:**, **Prefijo:**, **Fecha de Creación:**, **Estado:**, **Prioridad:**, **Complejidad:** y **Servicios Afectados:**. Si el validador devuelve un error, detén el workflow.

Paso Previo — Validación de Acuerdos de Producto (BLOQUEANTE):

1. Lee .quinoto-spec/discovery/08-product-and-agreements.md.
2. Si el archivo NO existe, contiene únicamente los títulos/placeholders originales, o está vacío de contenido sustantivo → DETÉN LA EJECUCIÓN INMEDIATAMENTE. No avances a los pasos siguientes ni generes ningún archivo.
3. Notifica al usuario exactamente:

   "No puedo crear la propuesta porque no se han definido los Acuerdos de Producto (DoR/DoD) en .quinoto-spec/discovery/08-product-and-agreements.md. Por favor complétalo primero (o indícame explícitamente que quieres continuar sin ellos como excepción documentada)."

4. Solo continúa al Paso 0 si el archivo tiene Definition of Ready (DoR) y Definition of Done (DoD) definidas con contenido real, o si el usuario confirmó explícitamente un override tras la advertencia anterior (en ese caso, documentar la excepción en proposal.md bajo **⚠️ Excepción DoR/DoD:** con el motivo dado por el usuario).

Paso Previo — Lectura dirigida del Discovery (OBLIGATORIA antes de redactar):

El Discovery no se limita a stack y acuerdos: cada sección técnica de la propuesta tiene un archivo de origen. Lee estos archivos antes de escribir, no solo 01 y 08:

Sección de proposal.md	Fuente en .quinoto-spec/discovery/
Resumen Ejecutivo, Beneficios	02-overview.md (contexto, comandos, riesgos rápidos)
Arquitectura y Diseño Técnico (diagrama de secuencia)	03-architecture.md
Especificación Técnica Detallada, Impacto en el Sistema (endpoints y contratos)	04-endpoints-and-openapi.md
Impacto en el Sistema (modelos de datos, integraciones externas)	05-data-and-services.md
Riesgos y Mitigaciones, Plan de Verificación (CI, secretos, dependencias)	06-devops-ci-security.md
Riesgos y Mitigaciones, Roadmap Futuro (deuda técnica ya conocida)	07-findings-and-recommendations.md