Artéfacts HTML

Que fait Artéfacts HTML ?

Produisez un fichier .html autonome, ouvrable depuis le disque et fonctionnant hors ligne. Utilisez l'adaptateur documentaire du système de design de l'Agence numérique japonaise (DADS) fourni en bundle, et non un CDN ou un framework. Gardez la source destinée à l'agent en Markdown. Il s'agit d'un adaptateur documentaire non officiel, pas d'une implémentation complète de chaque composant DADS.

Procédure

1. Comprendre le lecteur et la source

Identifiez le sujet, le public, l'objectif et les preuves avant de choisir la structure. Pour les plans, conservez les objectifs, les preuves d'achèvement, les contraintes, les points de contrôle et les risques. Incluez un titre descriptif, une courte orientation, et la provenance (source/date). Ajoutez une table des matières uniquement si utile ; n'imposez pas un nombre de sections ou de diagrammes.

Expliquez à partir de zéro : commencez par une situation concrète et ce que fait le sujet, puis introduisez les noms techniques. Définissez le jargon lors de sa première utilisation, donnez une idée par étape, et utilisez une image légendée uniquement lorsqu'elle explique plus clairement que le texte. N'utilisez des analogies que si leur lien et leurs limites sont explicites ; gardez un ton direct et adulte, sauf si vous écrivez pour des enfants. Un novice doit comprendre ce qui se passe, pourquoi et quoi faire ensuite.

2. Construire mécaniquement — ne jamais retaper le CSS

Lisez build.md. Résolvez le répertoire de la compétence à partir de l'emplacement de ce fichier, et non du répertoire de travail actuel du projet. Avec Python 3.10+ :

python /chemin/absolu/vers/html-artifacts/scripts/build.py /chemin/absolu/vers/sortie.html --title "Sujet"

Le constructeur lit assets/template.html, intègre tous les fichiers assets/dads.css et assets/print.js, et insère une politique de sécurité de contenu (CSP) hors ligne. Il refuse d'écraser un fichier existant. Aucun téléchargement, installation de paquet, serveur, bundler ou dossier de ressources adjacent n'est nécessaire. Dans ce dépôt, utilisez son exécuteur Python (uv run python fonctionne également).

3. Éditer le contenu, pas les fondations

Modifiez le fichier généré. Remplacez le contenu explicatif, la provenance et la table des matières du modèle ; supprimez les sections inutiles. Conservez intacts style#dads-css, script#dads-print, la CSP, le charset, le viewport et les métadonnées de color-scheme (uniquement light).

• SVG en ligne et images raster intégrées uniquement. Pas de feuille de style, script, police, image, iframe, import, fetch ou dépendance analytique distante ou locale. Les hyperliens sources ordinaires peuvent pointer vers le web ; étiquetez les fichiers source locaux comme du texte plutôt que des liens relatifs brisés.
• Utilisez du HTML sémantique et les classes/tokens fournis en bundle. Lisez dads.md pour l'API des classes, les sources officielles et les adaptations locales. Ne mélangez pas les API data-type/data-size en amont avec les modificateurs de cet adaptateur.
• Utilisez diagrams.md avant d'ajouter du SVG. Donnez à chaque diagramme significatif un titre, une description, des étiquettes et une alternative textuelle. Placez les diagrammes larges dans une région .dads-diagram-scroll étiquetée et accessible au clavier.
• Utilisez les polices de secours installées ; l'absence de Noto ne doit pas masquer le texte. Faites correspondre lang au contenu. Le corps est en 1rem/1.7 (16 px par défaut). Préservez le zoom du navigateur et le réarrangement (reflow).
• Par défaut, utilisez des liens et des éléments natifs de divulgation (<details>). Laissez les divulgations initialement open afin que l'impression sans script conserve le contenu ; le script fourni ouvre également toute divulgation fermée par le lecteur pour l'impression et la restaure ensuite. N'ajoutez pas d'onglets, de boutons inactifs, de JavaScript arbitraire ou d'attributs de gestionnaire d'événements.
• Restez clair dans les réglages système sombres : cet adaptateur n'a pas de palette sombre officielle vérifiée. N'inversez pas uniquement l'arrière-plan de la page et n'inventez pas un ensemble de tokens sombres. Respectez les couleurs forcées (forced-colors) et le mouvement réduit (prefers-reduced-motion).
• Préférez les composants existants. Si indispensable, placez des règles spécifiques au document dans une <style> en ligne distincte ; les nouvelles classes doivent être préfixées par artifact-* et définies à cet endroit. Utilisez des tokens connus, ne les redéfinissez jamais et ne modifiez pas le CSS en bundle. Vérifiez ces règles dans un navigateur ; une validation statique n'est pas un analyseur CSS ni un audit de contraste.

4. Auto-vérification finale — corrigez les échecs avant la livraison

Exécutez après la dernière modification :

python /chemin/absolu/vers/html-artifacts/scripts/check.py /chemin/absolu/vers/sortie.html

Ensuite, vérifiez le fichier réel dans un navigateur, avec le réseau désactivé si possible :

1. Contenu : le texte d'introduction et les espaces réservés du modèle ont disparu ; les preuves, sources, dates et actions suivantes demandées restent. Lisez les descriptions des diagrammes indépendamment ; elles doivent transmettre le sens.
2. Hors ligne : aucune requête de ressource, échec d'actif, violation CSP ou erreur console. Les hyperliens sources sont de la navigation, pas des dépendances intégrées.
3. Mobile/desktop : inspectez les captures d'écran à 390 px et 1280 px ; vérifiez également le réarrangement à 320 px avec une taille de texte à 200 %. Pas de débordement horizontal sur toute la page ; seules les régions étiquetées et accessibles (code/tableau/diagramme) peuvent défiler. Inspectez les glyphes japonais réels et les longues URL.
4. Clavier/états : suivez le lien de saut et la table des matières, tabulez jusqu'aux régions de défilement, basculez les divulgations, et inspectez le focus visible et le contraste des boutons/liens (y compris visited/hover). Pas de signification basée uniquement sur la couleur.
5. Sombre/impression : émulez la préférence sombre (la page doit rester lisible en clair), imprimez avec une divulgation fermée, vérifiez que son corps s'imprime, et vérifiez les grands tableaux/code ainsi que les sauts de page. Préservez le contenu sans JavaScript en laissant les divulgations ouvertes initialement.

Le vérificateur applique le contrat des actifs/politiques en bundle, les classes/tokens connus, et les règles restrictives de ressources hors ligne. Il ne prouve pas la syntaxe CSS, la mise en page, le contraste, l'accessibilité ou l'exactitude du HTML arbitraire. Si aucun navigateur n'est disponible, indiquez quelles vérifications visuelles et interactives restent non vérifiées ; ne prétendez jamais avoir des captures d'écran à partir de seules vérifications statiques.

5. Livrer

Enregistrez le fichier à côté de la source ou dans le répertoire de travail, nommé d'après le sujet (PLAN.html pour un plan). Renvoyez le lien vers l'artéfact et les limitations matérielles, pas une copie du document ni un second audit générique.

Pour SSH/un autre appareil, suivez remote-preview.md. Un chemin distant ou xdg-open n'est pas une remise visuelle utilisable. Servez uniquement une copie isolée, utilisez un tunnel public uniquement pour du contenu autorisé à être partagé publiquement, sinon utilisez un transfert SSH/contrôle d'accès, et fournissez des instructions de nettoyage. Gardez le HTML original sûr pour une utilisation hors ligne.

Ressources

• assets/template.html, assets/dads.css, assets/print.js : sources intégrées mécaniquement.
• scripts/build.py, scripts/check.py : constructeur et vérification finale via la bibliothèque standard.
• build.md : modèles d'édition et dépannage.
• dads.md : provenance officielle, tokens, API des composants de l'adaptateur.
• diagrams.md : modèles de SVG en ligne lisibles.
• remote-preview.md : remise sécurisée à distance.

L'approche "expliquer à partir de zéro" est inspirée de la compétence ELI5.