Hideki-Kobayashi/apply-digital-agency-design-system

Appliquer le système de design du gouvernement numérique

Sélectionner et appliquer uniquement les justifications nécessaires à la demande à partir d'un instantané Markdown officiel approuvé. Séparer le travail habituel de la vérification des mises à jour officielles, et ne pas activer les candidats à la mise à jour sans l'approbation de l'utilisateur. À partir de maintenant, <skill-root> sera remplacé par le chemin absolu du répertoire où se trouve ce SKILL.md. À partir de maintenant, <python> sera remplacé par la commande capable d'exécuter Python 3.10 ou supérieur. Sur macOS et Linux, utilisez généralement python3, sur Windows, utilisez généralement py -3.

Périmètre des informations

• Le active_snapshot.path indiqué par references/source-manifest.json est l'instantané valide à utiliser dans le travail habituel.
• Le source-index.json de l'instantané valide, references/task-index.md, et references/foundation-map.md sont des documents dérivés. Pour leur signification officielle, consultez le Markdown correspondant dans l'instantané valide.
• Le Markdown officiel est une reconstruction destinée à la consultation par IA et ne remplace pas complètement le site officiel. Si la documentation locale ne contient pas la description nécessaire, signalez-le comme une information non confirmée.
• Cette compétence est non officielle et n'implique aucune fourniture, approbation, partenariat ou recommandation de la part du gouvernement numérique.
• Les valeurs actuelles d'un projet existant sont vérifiées à partir des variables CSS, des paramètres de thème, des styles communs et des composants communs. Ne les dupliquez pas dans la compétence.
• La création, la modification et la révision sont des catégories de droits d'opération. La nouvelle création, la modification existante et les composants individuels sont des catégories de sélection de documentation, à ne pas confondre.

Vérification du délai de mise à jour au démarrage

Exécutez d'abord la commande suivante. Cette commande ne lit que les fichiers locaux et ne se connecte pas au réseau.

<python> <skill-root>/scripts/manage_upstream.py status

Conservez le status de la sortie en tant que status_at_start pendant toute la durée de la demande.

• fresh : ne pas afficher de notification de mise à jour, continuer le travail habituel.
• due, never_checked, unknown : ne pas arrêter le travail habituel, revérifier l'état à la fin.
• Si l'utilisateur indique explicitement dès le début "Vérifiez la dernière version", etc. : traiter la demande explicite comme un consentement à la vérification externe et passer à la procédure de maintenance.

Le délai est déterminé à partir de last_successful_check_at sur 30 jours. La date de proposition, la date d'échec, ou la prochaine date de vérification dérivée ne sont pas utilisées comme point de départ du délai.

Travail habituel

1. Classer la demande en création, modification ou révision, et déterminer la portée des opérations autorisées.
2. Vérifier la configuration technique cible, les styles existants, les contraintes de marque et la structure de l'écran.
3. Déterminer le chemin de sélection de la documentation selon l'ordre de priorité suivant.
   • Si la cible se limite à un seul composant d'interface utilisateur et à ses états, il s'agit d'un composant individuel.
   • Si un style commun existe déjà, il s'agit d'une modification existante.
   • Sinon, il s'agit d'une nouvelle création.
4. Sélectionner le document cible à partir de references/task-index.md. S'il n'y a pas de correspondance, rechercher dans l'instantané valide avec la commande suivante.

<python> <skill-root>/scripts/search_guidance.py \
  --query '<termes de recherche séparés par des espaces>' \
  --manifest-file <skill-root>/references/source-manifest.json

5. Selon le chemin de sélection de la documentation, utiliser references/foundation-map.md.
   • Nouvelle création : diviser en 8 catégories : adoptées, exclues, réservées ; lire le Markdown officiel pour les catégories dont les valeurs doivent être déterminées.
   • Modification existante : d'abord examiner les valeurs existantes, lire uniquement les catégories concernées, diviser en maintien, migration, ou écart intentionnel.
   • Composant individuel : lire uniquement les critères communs existants, le composant cible et la conception de base concernée. Ne pas redéfinir les valeurs communes à l'intérieur du composant.
6. Distinguer les options officielles, les valeurs par défaut, les exemples, les principes, les exigences et les valeurs fixes, et faire correspondre les valeurs adoptées avec leurs justifications.
7. Implémenter avec la configuration technique existante. Ne pas appliquer les exemples officiels comme des valeurs fixes uniformes, et ne pas assouplir les exigences officielles comme des préférences esthétiques.
8. Selon la cible, vérifier plusieurs largeurs d'écran, la navigation au clavier, le focus, les changements d'état, le zoom et le réécoulement.
9. Pour une demande de révision, ne pas modifier les fichiers, mais retourner uniquement des remarques avec justifications.

Rapport d'achèvement du travail habituel

Rapporter brièvement ce qui suit :

• Version de référence : ID de l'instantané du source-manifest.json, version du système de design du gouvernement numérique, date de publication du Markdown.
• Périmètre vérifié : documents officiels lus et vérifications effectuées.
• Éléments non vérifiés : périmètre non vérifié, comme l'appareil réel, les technologies d'assistance, les pages actuelles externes, etc.
• Écarts : modifications apportées par rapport à l'exemple ou à la recommandation officielle pour des raisons spécifiques au projet.

Réexécuter status juste avant le rapport uniquement si l'état au démarrage était due, never_checked ou unknown. S'il n'est pas devenu fresh suite à un autre traitement, proposer une seule fois une vérification de mise à jour à la fin du rapport final.

Plus de 30 jours se sont écoulés depuis la dernière vérification de mise à jour officielle. Ce travail a été réalisé avec la version actuelle approuvée. Souhaitez-vous également effectuer une vérification de mise à jour ?

Pour never_checked ou unknown, ne pas préciser le nombre de jours écoulés mais indiquer la raison. La proposition seule n'effectue ni communication externe ni mise à jour d'état. Même si l'utilisateur refuse, la date de refus n'est pas enregistrée, donc la proposition sera renouvelée jusqu'à ce qu'une vérification réussie ait eu lieu.

Vérification des mises à jour officielles

Exécuter ce qui suit uniquement après avoir obtenu le consentement de l'utilisateur. --network-approved n'est ajouté qu'après confirmation du consentement de l'utilisateur. Ajouter --force si la dernière version doit être vérifiée explicitement même si moins de 30 jours se sont écoulés.

Laisser le backend de récupération par défaut auto. auto délègue à ax la récupération des pages officielles, l'extraction des liens et la sauvegarde ZIP si ax est trouvé ; sinon, il utilise la bibliothèque standard Python. ax est recommandé mais optionnel, et son installation n'est pas un prérequis pour la vérification des mises à jour. Le chemin ax vérifie l'URL finale après redirection, mais il ne peut pas valider les destinations intermédiaires avant la communication. Si un contrôle préalable des destinations de transfert est nécessaire, utilisez --fetch-backend stdlib. Même en cas d'échec du backend initial, ne passez pas implicitement à un autre backend. La vérification de l'URL, de la taille et du format ZIP, le calcul de hachage, la création de diff et la sauvegarde d'état sont effectués en Python après la récupération. Ajoutez --fetch-backend ax ou --fetch-backend stdlib uniquement pour fixer la méthode lors des tests de fonctionnement, etc.

<python> <skill-root>/scripts/manage_upstream.py check \
  --network-approved

• unchanged : mettre à jour la date et l'heure de la vérification réussie, rapporter le backend de récupération et l'absence de changement.
• candidate_created ou candidate_exists : rapporter le backend de récupération, l'ID du candidat, la source de la récupération, le hachage, et les nombres d'ajouts, de modifications et de suppressions.
• skipped_fresh : rapporter que la vérification externe a été ignorée car moins de 30 jours se sont écoulés.
• Échec : ne pas modifier last_successful_check_at ni l'instantané valide ; rapporter la source de récupération ayant échoué et la raison.

Le consentement à la vérification externe n'est pas considéré comme une approbation pour l'adoption du candidat. Même si un candidat est trouvé, si la vérification de la source officielle et la sauvegarde du candidat sont terminées, la date et l'heure de la vérification réussie sont mises à jour.

Récupération manuelle du ZIP

Proposer cette procédure en dernier recours uniquement si la récupération automatique a finalement échoué et que check a pu identifier l'URL du ZIP officiel et guider une récupération manuelle. En cas d'échec avant l'identification de l'URL, ne pas deviner la source de récupération à partir de l'URL ou du nom de fichier, et signaler uniquement l'échec.

Présenter le contenu suivant à l'utilisateur.

La récupération automatique du ZIP a échoué. Vous pouvez le récupérer manuellement à partir de l'URL officielle suivante.
<URL du ZIP officiel>

Veuillez enregistrer le ZIP dans le dossier de votre choix. Après l'enregistrement, fournissez-moi le chemin absolu incluant le nom du fichier.
Le ZIP reçu sera vérifié sans connexion réseau et enregistré comme candidat à la mise à jour. Le basculement vers la version active sera confirmé séparément.

Après avoir reçu le chemin absolu de l'utilisateur, exécutez ce qui suit. Si seul un chemin relatif est connu, confirmez d'abord le chemin absolu avant d'exécuter la commande.

<python> <skill-root>/scripts/manage_upstream.py import-archive \
  --archive-file '<chemin absolu du ZIP>'

import-archive lie le ZIP local à l'URL officielle enregistrée en cas d'échec, et procède à la vérification et à la création du candidat (taille normale, format ZIP, chemins internes, ensemble Markdown, hachage) sans connexion réseau. Il ne modifie ni ne supprime le ZIP d'origine. L'importation locale n'est pas considérée comme une vérification externe réussie et ne met pas à jour last_successful_check_at ni la version contractuelle vérifiée. Même si le résultat est candidate_created ou candidate_exists, il n'est pas automatiquement promu ; passer à "Évaluation et promotion des candidats à la mise à jour".

Si plus de 30 jours se sont écoulés depuis l'identification de l'URL officielle, ou si le contrat de mise à jour a changé, ne pas contourner l'importation et demander un nouveau consentement pour la vérification de mise à jour. Même en cas d'échec de la récupération manuelle ou de l'importation locale, ne pas modifier last_successful_check_at ni l'instantané valide.

Évaluation et promotion des candidats à la mise à jour

1. Lire candidate-manifest.json et diff-summary.json dans le candidat.
2. Vérifier le candidat avec verify_snapshot.py.

Le dossier de sauvegarde par défaut du candidat est candidates dans le répertoire d'état de l'utilisateur.

<python> <skill-root>/scripts/verify_snapshot.py \
  --snapshot-dir <state-dir>/candidates/<ID du candidat>/snapshot \
  --index-file <state-dir>/candidates/<ID du candidat>/source-index.json

3. Lire les documents officiels ajoutés, modifiés ou supprimés, et vérifier l'impact sur task-index.md et foundation-map.md.
4. Tester des demandes représentatives de création, modification et révision avec l'ancienne version et la version candidate.
5. Présenter à l'utilisateur l'ID du candidat, les changements de sens, les modifications des documents dérivés et les résultats de vérification, et confirmer explicitement l'adoption.
6. Après que l'utilisateur a approuvé en spécifiant l'ID du candidat, exécuter ce qui suit.

<python> <skill-root>/scripts/manage_upstream.py promote \
  --candidate-id '<ID du candidat>' \
  --human-approved

Après la promotion, ne pas supprimer l'instantané précédent. L'opération de promotion ne modifie pas last_successful_check_at.

Règles de décision

• Ne pas utiliser MANIFEST.md comme document de référence pour la liste des fichiers. Parcourir tous les fichiers Markdown.
• Utiliser source_url normalisé comme ID de document. slug étant dupliqué dans le texte et l'historique des modifications, ne pas l'utiliser comme ID unique.
• Ne pas créer de composants, jetons ou noms de classe non trouvés comme spécifications officielles.
• En cas de conflit entre une valeur existante et une exigence officielle, ne pas conserver ou remplacer silencieusement, mais indiquer l'impact et la portée de la modification.
• Ne pas déclarer une conformité complète au système de design du gouvernement numérique ou aux WCAG sur la seule base d'une vérification visuelle.
• Pour citer des sources dans des documents publics, lire introduction/notices/index.md de l'instantané valide.
• Enregistrer l'état des mises à jour et les candidats dans une zone locale propre à l'utilisateur, et ne pas les mélanger avec les fichiers de distribution de la compétence elle-même. Utiliser la variable d'environnement DADS_SKILL_STATE_DIR uniquement pour modifier le dossier de sauvegarde.