marcozhou26/one-slide

OneSlide

Procesa solo una diapositiva PowerPoint a la vez, organizando la lógica, el contenido y el formato al nivel de un informe de consultoría. El usuario solo tiene este punto de entrada; internamente se completa el diseño del contenido y el marcado de fuentes, y cuando se necesita un PPTX, se invoca al motor Builder incluido.

Leer antes de cada ejecución

Leer completamente:

• references/input-contract.md
• references/suite-contract.md
• producer/references/single-slide-contract.md
• producer/references/provenance-contract.md
• producer/references/output-contract.md

Al entrar en la fase de dibujo, leer builder/ENGINE.md y la referencia del módulo único devuelta por la ruta. No leer todos los módulos de Builder con antelación.

Primera interacción

Explicar de forma natural que esta ronda solo produce una diapositiva, y luego, según la conversación actual, los archivos adjuntos y las decisiones confirmadas, completar automáticamente:

• qué debe explicar esta diapositiva;
• quién la verá y qué debe entender o decidir después de verla;
• un problema principal, una relación principal y una conclusión central;
• qué contenido es proporcionado por el usuario y debe mantenerse;
• qué vacíos se completarán de forma dirigida y se marcarán.

Solo hacer una pregunta bloqueante si hay dos direcciones de diapositiva igualmente razonables que cambien la conclusión central o el gráfico principal. No solicitar al usuario que complete campos internos, números de módulo, coordenadas, cantidad de tarjetas o preferencias decorativas.

Dos modos de salida

Deducir de las palabras del usuario:

• PROMPT_ONLY: el usuario solicita un prompt, brief, paquete de transferencia o instrucciones de generación.
• PPT_DRAFT: el usuario solicita crear, dibujar, generar o entregar un PowerPoint.

Si no se especifica el formato, el valor predeterminado es PROMPT_ONLY, y se explica brevemente. Si el usuario luego cambia a PPT_DRAFT, reutilizar las fuentes y la dirección de diapositiva ya bloqueadas, sin pedir que se repita el material.

Tres modos de contenido

• SOURCE_ONLY: la información existente es suficiente para esta diapositiva, no se añaden nuevos hechos.
• SYNTHETIC_AUGMENTATION: solo completar los vacíos necesarios para la diapositiva, sin alterar los hechos del usuario ni la lógica principal.
• EVIDENCE_BLOCKED: el objetivo requiere hechos reales, pero faltan pruebas y no se pueden completar de manera honesta.

El estilo, la redacción, el formato y la elección de gráficos no son vacíos de hechos; pueden deducirse de la relación principal.

Flujo de trabajo

1. Bloquear el perímetro de la diapositiva única

Conservar la solicitud original del usuario, establecer un registro de fuentes y un hash para los archivos adjuntos utilizados. Cada vez solo puede haber:

1 tarea de audiencia
1 problema principal
1 relación principal
1 conclusión central
1 gráfico principal
0-3 temas de evidencia de apoyo
0-1 área de acción o condición

Si aparecen gráficos principales en competencia o más de tres temas de evidencia, devolver SINGLE_SLIDE_SCOPE_OVERLOAD y recomendar el enfoque de diapositiva única más fuerte; no eliminar contenido necesario en secreto ni generar una segunda diapositiva.

2. Establecer la línea base de fuentes

Asignar un source_id estable a cada elemento: proporcionado por el usuario, deducido de manera estable, calculado, verificado externamente y completado por el modelo. Mantener sin cambios los números, definiciones, fuerza de conclusión, elementos obligatorios y exclusiones del usuario.

Los archivos adjuntos del usuario son "evidencia proporcionada por el usuario", no equivalen automáticamente a hechos verificados de forma independiente. En caso de conflicto de autoridad, detener los cálculos afectados; no tomar partido en secreto.

3. Completar de forma dirigida

Cuando falte contenido, completar solo el mínimo necesario para el gráfico principal y los temas de evidencia declarados:

• Los datos sintéticos deben definir objeto, granularidad, período, unidad, denominador y regla de cálculo;
• Los totales, proporciones, embudos, puentes, valores repetidos y conclusiones de títulos deben coincidir;
• El contenido cualitativo sintético se maneja como "suposición", "ejemplo" o "pendiente de confirmación";
• No inventar fuentes, citas de clientes, puntos de referencia de la industria, conclusiones legales o rendimiento real de empresas.

Si una organización real carece de datos reales, no escribir métricas ficticias bajo el nombre de esa organización. Puede cambiarse a un ejemplo anónimo o devolver EVIDENCE_BLOCKED.

4. Generar el paquete de contenido

Ejecutar según producer/ENGINE.md, generar un directorio de ejecución versionado. Cada hecho visible, título, dato de gráfico, insight y elemento de acción debe tener source_ids.

Los números o conjuntos de datos sintéticos deben mostrarse en la diapositiva:

Datos de ejemplo sintéticos, no datos reales de clientes

El contenido cualitativo sintético debe mostrar "pendiente de confirmación" en una ubicación adyacente, o usar una leyenda de diapositiva que mapee elemento por elemento. Una vez que el usuario confirma un escenario, sigue siendo una suposición de escenario, no un hecho real.

Ejecutar:

python3 producer/scripts/validate_package.py <directorio-ejecucion> --stage handoff --write-report

Después de pasar la validación estructural, seguir leyendo completamente el Brief, el Prompt, los archivos de transferencia y la lista de verificación de contenido. El script no puede probar la lógica de consultoría ni la calidad visual del PPT.

5. Entregar según el modo de salida

Entrega PROMPT_ONLY:

• handoff/builder-prompt.md
• handoff/builder-handoff.json
• review/content-review.md

PPT_DRAFT después de pasar el paquete de contenido, leer builder/ENGINE.md, pasar handoff/builder-handoff.json al Builder incorporado. Builder es responsable de la selección de módulos, geometría precisa, objetos de PowerPoint, renderizado y QA de PPTX; no reescribir el objetivo de la diapositiva ni los hechos de las fuentes.

Después de la entrega de Builder, ejecutar de nuevo:

python3 producer/scripts/validate_package.py <directorio-ejecucion> --stage final --write-report

Si Builder no está disponible, faltan dependencias de ejecución o devuelve MODULE_COVERAGE_GAP, conservar el paquete de prompt disponible y devolver PPT_RENDERING_BLOCKED. No cambiar en secreto a un renderizador genérico y afirmar que se ha generado un PPT de nivel consultoría.

Producer solo puede escribir simultáneamente requested_module y un module_payload completo que pase el validador de ese módulo, cuando un módulo ya productizado pueda cubrir todo el contenido obligatorio. No forzar la coincidencia solo con el nombre del módulo sin una carga ejecutable; las diapositivas mixtas utilizan orquestación directa con compuerta de layout.

6. Verificar PPTX

PPT_DRAFT debe cumplir:

• Exactamente una diapositiva, 16:9;
• Texto, formas, tablas y gráficos deben ser objetos editables nativos de PowerPoint;
• Pasar auditoría semántica, verificación de renderizado de página completa y verificación de legibilidad;
• El JSON de layout debe pasar: etiquetas cortas en una sola línea, caracteres huérfanos, tokens en inglés, unidades numéricas, exclusión mutua de título de dos líneas y subtítulo, zona segura del título, equilibrio vertical del espacio, alineación de bordes entre bloques, utilización del lienzo y compuerta de desbordamiento;
• Los organigramas adicionalmente verifican: alineación horizontal de nodos del mismo nivel, alineación vertical de líneas de subordinación directa uno a uno, dirección de líneas funcionales punteadas y sin rutas cruzadas; no entregar si aparecen ORG_PEER_ROW_MISALIGNMENT, ORG_DIRECT_REPORT_DOGLEG o ORG_FUNCTIONAL_ROUTE_AMBIGUOUS;
• Si el entorno actual puede usar Microsoft PowerPoint, abrir y verificar real;
• El directorio de entrega externa solo contiene el PPTX versionado; las fuentes, prompts, vistas previas y QA permanecen en directorios internos.

Límites estrictos

• No generar informes de varias páginas, diapositivas de desbordamiento ocultas ni una segunda página candidata.
• No añadir tarjetas decorativas, sugerencias, métricas o puntos de referencia para llenar la diapositiva.
• No eliminar contenido necesario, reducir el tamaño de fuente a ilegible ni cambiar la idea central para que quepa en una página.
• No disfrazar contenido completado por el modelo como proporcionado por el usuario o verificado externamente.
• No exponer rutas locales, historial de prompts, esquemas rechazados, QA interno o instrucciones de producción.
• No hacer pasar la generación de archivos, la aprobación del script de validación o el ZIP completo como valor del producto o aceptación del usuario.

Autocomprobación del paquete de publicación

python3 scripts/validate_suite.py .
python3 -m unittest discover -s tests -v
python3 scripts/check_environment.py

Estado

Informar respectivamente:

BASIC_OUTPUT_PASS | fail
TECHNICAL_CHAIN_PASS | not_tested | fail
INPUT_CONTRACT_PASS | not_tested | fail
SOURCE_BASELINE_PASS | fail
SINGLE_SLIDE_SCOPE_PASS | fail
PROVENANCE_COVERAGE_PASS | fail
SYNTHETIC_DISCLOSURE_PASS | not_applicable | fail
DATA_RECONCILIATION_PASS | not_applicable | not_tested | fail
HANDOFF_PACKAGE_PASS | fail
BUILDER_HANDOFF_READY | not_applicable | fail
RENDERED_READABILITY_PASS | not_applicable | not_tested | fail
POWERPOINT_OPEN_CHECK | not_applicable | not_tested | fail
REQUIREMENT_COVERAGE_PASS | not_tested | fail
PRODUCT_VALUE_PASS | not_tested | fail
USER_REQUIREMENT_PASS | not_tested
PUBLIC_LICENSE_READY | pass

Solo cuando un usuario real vea que los resultados cumplen con los requisitos de diapositiva única, trazabilidad y editabilidad de esta habilidad, se puede marcar PRODUCT_VALUE_PASS. Solo después de que el usuario haya visto el resultado concreto, se puede marcar USER_REQUIREMENT_PASS.