yizhiyanhua-ai/fireworks-open-eli5

Fireworks Open ELI5

Transformez un système complexe en une histoire visuelle véridique. Produisez d'abord un spec JSON portable, puis un explicateur HTML déterministe et autonome.

Limite non négociable

• Les preuves passent avant le polissage visuel. Étiquetez chaque élément de preuve comme verified, inferred ou analogy.
• Ne faites jamais passer une analogie pour une vérité d'implémentation.
• Un fichier HTML local généré est uniquement generated. Il n'est ni published, téléchargé, envoyé, ni vérifié comme destination.
• Ne publiez, téléchargez, envoyez ou modifiez l'accès sans la demande explicite de l'utilisateur et la propre vérification du flux de destination.
• Le rendu n'effectue aucun appel réseau. Une URL citée est un lien destiné au lecteur, pas une dépendance d'exécution. L'action optionnelle Pages native peut appeler uniquement l'assistance groupée de même origine sur 127.0.0.1 ; elle ne doit jamais contacter un service distant.
• L'historique local du navigateur, les favoris et les annotations sont désactivés jusqu'à ce que le lecteur y consente. Ils sont un état de commodité, pas une preuve et ne modifient jamais le spec source ou l'artefact généré.
• Décrivez l'historique précisément comme des explicateurs de même origine précédemment ouverts dans ce navigateur. Ne prétendez jamais qu'il énumère tous les fichiers générés.
• L'exportation PDF invoque la boîte de dialogue d'impression du navigateur. PNG exporte une scène ; PPTX et DOCX compatible Pages exportent une scène par diapositive ou page. La sortie native .pages est autorisée uniquement après que l'application Pages installée l'ait réellement enregistrée ; ne renommez jamais un DOCX en .pages. Les téléchargements générés sont uniquement des artefacts locaux.

Flux de travail

1. Identifiez le public, la question, la langue et une chose qui doit traverser l'histoire : une requête, un paquet, une décision, un événement ou une action utilisateur.

2. Choisissez exactement une grammaire narrative :

   • concept : intuition → mécanisme → limites.
   • module : point d'entrée → transformations → sorties/dépendances.
   • tradeoff : objectif commun → options concurrentes → conséquences/règle de décision.
   • incident : chemin normal → rupture et propagation → détection/rétablissement.

3. Rassemblez les preuves. Pour le travail sur un dépôt, inspectez les fichiers réels et utilisez les chemins locaux. Pour les affirmations externes, utilisez des sources faisant autorité lorsqu'elles sont disponibles. Enregistrez explicitement l'incertitude.

4. Créez un spec JSON version 1 en suivant references/spec-contract.md. Utilisez 3 à 7 scènes, 2 à 6 nœuds par scène, une échelle de vérité complète, une trace, un glossaire, un retour d'enseignement, une carte des preuves et le modeData spécifique au mode requis. Ajoutez des informations d'échec aux nœuds importants.

5. Validez avant le rendu :

   node scripts/validate.mjs path/to/spec.json
   

6. Effectuez le rendu vers un nouveau fichier local :

   node scripts/render.mjs path/to/spec.json path/to/explainer.html
   

   Le moteur de rendu refuse un chemin existant. Uniquement lorsque l'utilisateur souhaite explicitement remplacer un fichier normal connu, ajoutez --force. Le rendu forcé utilise un remplacement atomique et refuse toujours les liens symboliques et les chemins non-fichier.

7. Validez le spec et l'artefact ensemble :

   node scripts/validate.mjs path/to/spec.json path/to/explainer.html
   

8. Lorsque l'accès au navigateur est disponible, inspectez l'artefact local à la largeur du bureau et à 390 px. Confirmez un h1, des étiquettes lisibles, pas de débordement horizontal, le focus clavier, des tablistes indépendants, la lecture globale et par scène, le suivi de la fenêtre d'affichage, la synchronisation active des bords réels et des cartes de preuve, les phases d'animation entrée/maintien/sortie, la lentille d'échec, les révélations de réponse et zéro requête de ressource distante. Chaque carte de preuve de scène doit exposer son statut, sa base centrale concise, son périmètre de support et une URL ou une limite explicite sans localisateur.

9. Exercez l'espace de travail du lecteur : ouvrez et fermez le tiroir modal à la souris et au clavier ; confirmez le retour du focus ; activez intentionnellement la bibliothèque ; rechargez et vérifiez les favoris et une annotation en texte brut ; et confirmez que l'historique contient uniquement les explicateurs de même origine qui ont été réellement ouverts. Utilisez une annotation en forme de balisage pour vérifier qu'elle reste un texte inerte.

10. Exercez l'exportation : confirmez la feuille de style d'impression, la signature et les dimensions PNG, les signatures ZIP PPTX et DOCX et les parties OOXML requises, et le lien de téléchargement de secours lorsque les téléchargements automatiques sont supprimés. Confirmez visuellement que l'illustration de la scène comprend un pied de page de preuve délimité avec le statut, la base centrale et le localisateur de source ou la limite. Lorsque Pages natif est dans le périmètre, exécutez scripts/serve.mjs, vérifiez que le package .pages contient Index/Document.iwa, puis rouvrez-le dans Pages. Corrigez le spec ou le modèle et réexécutez les deux validateurs après toute modification.

Langue du rapport

• Par défaut, rédigez le rapport final de QA, de statut, de transfert et d'artefact généré dans la langue de la dernière demande substantielle de l'utilisateur.
• Une demande explicite de langue de rapport annule cette valeur par défaut.
• spec.language contrôle uniquement l'interface de l'explicateur généré ; il ne force pas la langue du rapport de conversation.
• Dans les conversations multilingues, ignorez les courts accusés de réception lors du choix de la langue du rapport. Préservez le code, les commandes, les chemins, les identifiants, les erreurs exactes et les titres de source lorsque la traduction réduirait la précision.

Lisez references/reporting.md pour le contrat complet de sélection de langue et de rapport de livraison.

Règles de construction de l'histoire

• Rédigez le titre comme une promesse concrète, pas une étiquette de catégorie.
• Limitez le résumé à une phrase et chaque nœud à une responsabilité.
• Préférez 3 à 5 scènes. Utilisez 6 à 7 uniquement lorsque l'omission d'une étape déformerait la causalité.
• Les arêtes sont des relations ou des actions. Utilisez des verbes courts sur les étiquettes.
• La trace doit visiter des identifiants de nœuds réels dans un ordre significatif.
• Utilisez les données d'échec uniquement lorsque l'impact, le symptôme visible et la solution de repli sont connus.
• Gardez la couche simple suffisamment précise pour survivre à la couche technique.
• Placez les limitations dans truthLadder.caveat, pas dans de minuscules avertissements.
• Utilisez les identifiants de source sur les scènes ou les nœuds qu'ils soutiennent.
• Ne citez pas une source simplement parce qu'elle est adjacente à l'affirmation.

Lisez references/story-grammars.md pour les modèles de mode, references/evidence-rules.md pour les limites des affirmations, et references/visual-system.md avant de modifier le langage visuel du moteur de rendu. Lisez references/library-and-export.md avant de modifier la persistance, la navigation, la lecture ou le comportement d'exportation.

Porte de qualité

Le travail est prêt en tant qu'artefact local uniquement lorsque :

• le validateur retourne ok: true pour le spec et le HTML rendu ;
• tous les identifiants et références se résolvent ;
• chaque section interactive requise a du contenu ;
• le mode narratif sélectionné réussit son propre contrat sémantique ;
• le HTML est déterministe et porte la balise meta SHA-256 du spec ;
• l'artefact correspond octet par octet au spec fourni et utilise des hachages CSP de confiance ;
• l'artefact n'a aucune ressource externe, API d'exécution dangereuse ou police à distance ;
• l'état persistant du lecteur est facultatif, limité à un espace de noms, borné, de même origine et conservé en dehors du hachage déterministe du spec ;
• les annotations sont rendues uniquement sous forme de texte et ne peuvent pas créer de balisage exécutable ;
• la lecture globale et locale partagent une seule machine d'état et ne s'exécutent jamais ensemble ;
• chaque étape de trace active le chemin de relation sortant réel (ou le chemin entrant d'un puits), maintient l'alignement de l'étiquette et de la flèche, et met en évidence uniquement les preuves qui soutiennent cette étape ;
• les cartes de preuve de scène préservent les limites vérifié/inféré/analogie et exposent le texte central plus un localisateur actionnable sans récupérer d'aperçus distants ;
• les packages PNG, PPTX et DOCX de scène ont les signatures et la structure attendues et contiennent leur pied de page de preuve ; une exportation Pages native revendiquée a également été rouverte dans Pages ;
• le mobile utilise le flux empilé plutôt que de réduire le SVG du bureau ;
• le rapport final suit la langue d'interaction actuelle de l'utilisateur, nomme les chemins du spec et du HTML générés, et indique si la QA du navigateur pour le bureau, le mobile, la persistance, la lecture, les preuves et l'exportation a été exécutée.

Si les preuves sont incomplètes, générez uniquement lorsque la carte des preuves et l'avertissement rendent la lacune indubitable. Sinon, arrêtez-vous et signalez les preuves manquantes.