marcozhou26/one-slide

OneSlide

Traite une seule diapositive à la fois, en organisant la logique, les sources et la mise en page selon des standards de rapport de conseil. L'utilisateur interagit uniquement avec ce point d'entrée ; en interne, la conception du contenu et l'annotation des sources sont d'abord réalisées, puis le moteur Builder intégré est appelé si nécessaire pour générer le PPTX.

À lire avant chaque exécution

Lecture complète de :

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

Lors de la phase de dessin, lire builder/ENGINE.md et la référence du module unique retourné par le routage. Ne pas pré-lire tous les modules du Builder.

Première interaction

Expliquer naturellement que cette session ne consiste qu'à réaliser une seule diapositive, puis pré-remplir en fonction de la conversation actuelle, des pièces jointes et des décisions déjà confirmées :

• Ce que cette diapositive doit expliquer ;
• Qui la verra et ce qu'il doit comprendre ou décider après l'avoir vue ;
• Un problème principal, une relation principale et une conclusion centrale ;
• Quels contenus sont fournis par l'utilisateur et doivent être conservés ;
• Quelles lacunes seront comblées de manière ciblée et marquées.

Ne poser une question bloquante que si deux directions de diapositive également raisonnables modifient la conclusion centrale ou le graphique principal. Ne pas demander à l'utilisateur de remplir des champs internes, des numéros de module, des coordonnées, des nombres de cartes ou des préférences de décoration.

Deux types de sortie

Déduire à partir des mots de l'utilisateur :

• PROMPT_ONLY : l'utilisateur demande un prompt, un brief, un kit de passation ou des instructions de génération.
• PPT_DRAFT : l'utilisateur demande la création, le dessin, la génération ou la livraison directe d'un PowerPoint.

Par défaut, si le support n'est pas précisé, choisir PROMPT_ONLY et le mentionner brièvement. Si l'utilisateur change ensuite pour PPT_DRAFT, réutiliser les sources et la direction de diapositive déjà verrouillées, sans demander de reformuler le matériel.

Trois modes de contenu

• SOURCE_ONLY : les informations existantes suffisent pour cette diapositive, aucun nouveau fait n'est ajouté.
• SYNTHETIC_AUGMENTATION : seules les lacunes nécessaires à la diapositive sont comblées, sans modifier les faits utilisateur ni la logique principale.
• EVIDENCE_BLOCKED : l'objectif nécessite des faits réels, mais les preuves manquent et ne peuvent pas être honnêtement complétées.

Le style, le choix des mots, la mise en page et les types de graphiques ne sont pas des lacunes factuelles ; ils peuvent être déduits de la relation principale.

Flux de travail

1. Verrouiller les limites de la diapositive unique

Conserver la demande originale de l'utilisateur, établir un enregistrement et un hachage des sources pour les pièces jointes utilisées. Chaque session ne peut contenir que :

1 tâche d'audience
1 problème principal
1 relation principale
1 conclusion centrale
1 graphique principal
0 à 3 thèmes de preuves à l'appui
0 à 1 zone d'action ou de condition

En cas de graphiques principaux concurrents ou de plus de trois thèmes de preuves, retourner SINGLE_SLIDE_SCOPE_OVERLOAD et recommander le focus le plus fort pour une seule diapositive ; ne pas supprimer discrètement du contenu essentiel ou générer une deuxième diapositive.

2. Établir une base de référence des sources

Attribuer un source_id stable pour : les éléments fournis par l'utilisateur, les déductions stables, les calculs, les vérifications externes et les complétions du modèle. Conserver intacts les nombres, définitions, forces de conclusion, éléments obligatoires et exclus de l'utilisateur.

Les pièces jointes de l'utilisateur sont des "preuves fournies par l'utilisateur", elles ne sont pas automatiquement équivalentes à des faits vérifiés indépendamment. En cas de conflit de niveaux d'autorité, arrêter les calculs concernés, sans prendre parti discrètement.

3. Complétion ciblée

Lorsque le contenu est insuffisant, ne combler que le minimum nécessaire pour le graphique principal et les thèmes de preuves déclarés :

• Les données synthétiques doivent définir l'objet, la granularité, la période, l'unité, le dénominateur et les règles de calcul ;
• Les totaux, proportions, entonnoirs, ponts, valeurs dupliquées et conclusions des titres doivent être cohérents ;
• Le contenu qualitatif synthétique est traité comme "hypothèse", "exemple" ou "à confirmer" ;
• Ne pas inventer de sources, de citations client, de benchmarks sectoriels, de conclusions juridiques ou de performances réelles d'entreprise.

Lorsque des données réelles manquent pour une organisation réelle, ne pas attribuer de métriques fictives à cette organisation. Peut être remplacé par un exemple anonyme, ou retourner EVIDENCE_BLOCKED.

4. Générer le paquet de contenu

Exécuter selon producer/ENGINE.md, produire un répertoire d'exécution versionné. Chaque fait, titre, donnée de graphique, insight et élément d'action visible doit avoir des source_ids.

Les chiffres ou ensembles de données synthétiques doivent être affichés sur la diapositive :

Exemple de données synthétiques, pas de données client réelles

Le contenu qualitatif synthétique doit afficher "À confirmer" à un endroit adjacent, ou utiliser une légende de diapositive qui peut être mappée élément par élément. Une fois qu'un scénario est confirmé par l'utilisateur, il reste une hypothèse de scénario, il ne devient pas un fait réel.

Exécuter :

python3 producer/scripts/validate_package.py <run-directory> --stage handoff --write-report

Après la validation structurelle, lire complètement le Brief, le Prompt, les documents de passation et la liste de vérification du contenu. Le script ne peut pas prouver la logique de conseil ou la qualité visuelle du PPT.

5. Livrer selon le mode de sortie

Livraison PROMPT_ONLY :

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

PPT_DRAFT : après validation du paquet de contenu, lire builder/ENGINE.md puis transmettre handoff/builder-handoff.json au Builder intégré. Le Builder est responsable de la sélection des modules, de la géométrie précise, des objets PowerPoint, du rendu et de l'assurance qualité PPTX ; il ne peut pas réécrire les objectifs de la diapositive ou les faits source.

Après la livraison du Builder, exécuter à nouveau :

python3 producer/scripts/validate_package.py <run-directory> --stage final --write-report

Si le Builder n'est pas disponible, si des dépendances d'exécution manquent, ou s'il retourne MODULE_COVERAGE_GAP, conserver le paquet de prompts utilisable et retourner PPT_RENDERING_BLOCKED. Ne pas remplacer discrètement par un rendu standard et déclarer avoir généré un PPT de niveau conseil.

Le Producer n'écrit à la fois requested_module et un module_payload complet et validable par le module correspondant que lorsqu'un module déjà industrialisé peut couvrir tout le contenu obligatoire. Ne pas forcer un module avec seulement son nom sans payload exécutable ; pour les diapositives mixtes, utiliser l'orchestration directe avec des garde-fous de mise en page.

6. Vérifier le PPTX

PPT_DRAFT doit satisfaire :

• Exactement une diapositive, format 16:9 ;
• Texte, formes, tableaux et graphiques sont des objets PowerPoint natifs modifiables ;
• Validation par audit sémantique, vérification du rendu complet de la diapositive et vérification de la lisibilité ;
• Le JSON de mise en page passe les contrôles : étiquette courte sur une seule ligne, orphelins, tokens anglais, unités numériques, titres et sous-titres mutuellement exclusifs, zone de sécurité du titre, équilibre vertical de l'espace, alignement des bords entre blocs, utilisation de la zone de dessin et respect des limites ;
• Pour les organigrammes : vérification supplémentaire de l'alignement horizontal des nœuds de même niveau, alignement vertical des lignes de report direct, direction des lignes fonctionnelles en pointillés et routage sans croisement ; en cas de ORG_PEER_ROW_MISALIGNMENT, ORG_DIRECT_REPORT_DOGLEG ou ORG_FUNCTIONAL_ROUTE_AMBIGUOUS, ne pas livrer ;
• Si l'environnement actuel permet d'utiliser Microsoft PowerPoint, ouvrir et vérifier le fichier ;
• Le répertoire de livraison externe ne doit contenir que le PPTX versionné ; les sources, prompts, aperçus et QA restent dans le répertoire interne.

Limites strictes

• Ne pas générer de rapport multi-pages, de page de débordement cachée ni de deuxième page candidate.
• Ne pas ajouter de cartes décoratives, de suggestions, de métriques ou de benchmarks pour remplir la page.
• Ne pas supprimer de contenu essentiel, réduire la police à une taille illisible ou changer l'idée centrale pour faire tenir le tout sur une page.
• Ne pas faire passer le contenu complété par le modèle pour fourni par l'utilisateur ou vérifié en externe.
• Ne pas exposer les chemins locaux, l'historique des prompts, les solutions rejetées, les QA internes ou les instructions de fabrication.
• Ne pas faire passer la génération de fichiers, la réussite des scripts de validation ou l'intégrité du ZIP pour la valeur du produit ou l'acceptation par l'utilisateur.

Auto-vérification du paquet de publication

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

Statut

Rapporter individuellement :

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

PRODUCT_VALUE_PASS ne peut être marqué que lorsque les résultats visibles par un utilisateur réel satisfont aux exigences de diapositive unique, de source et de modifiabilité de cette compétence. USER_REQUIREMENT_PASS ne peut être marqué qu'après que l'utilisateur a vu les résultats concrets.