0xtan0/skills – Présentation d'infrastructure animée

Présentation d'infrastructure (deck de flux)

Sortie : Un Artifact HTML privé, environ 8 slides, pour une réunion où le présentateur commente. Les diagrammes portent le sens. Le texte est minimal. Chaque bloc, flèche et affirmation provient du code ; rien ne vient de la mémoire ou des seuls documents.

Ordre de travail : Étape 0 configuration → Étape 1 recherche et rédaction des registres → Étape 2 construction → Étape 3 vérification jusqu'à 0 problème(s) → Étape 4 publication et rapport.

Étape 0 — Configuration

1. Copiez assets/template.html vers un chemin de travail unique. Chaque révision et chaque publication utilise ce même chemin, donc l'URL de l'Artifact reste identique.
2. Placez les registres (Étape 1) dans un fichier ledger.txt à côté. assets/ledger.example.txt montre le format ; les identifiants et chemins qu'il contient sont inventés.
3. Chargez le skill artifact-diagramming avant de dessiner un SVG. Suivez le contrat de la page Artifact (jetons de thème, pas de doctype, gouttière latérale).

Le modèle est un deck fonctionnel avec un exemple fonctionnel : moteur de slide, logique Play/Step/Reset, tuiles de style AWS, boîtes de compte et de région, un flux secondaire en pointillés et une tuile de logo de marque. Modifiez les données et les coordonnées ; ne réécrivez pas le moteur.

Faits sur le moteur :

• player(svgId, prefix, steps, idleCaption) exécute un slide Play. Le préfixe '' utilise #play/#back/#next/#reset/#cap ; 'n' utilise #nplay/…/#ncap (réseau), 'i' utilise #iplay/…/#icap (IAM), 'r' utilise #rplay/…/#rcap (release). Poussez sa valeur de retour dans stops. Une étape est {n:[id nœud], a:[id flèche], c:'légende'} ; a peut être vide. player() s'enregistre dans window.__players ; scripts/check.py le lit, donc gardez cette ligne.
• tile(id,cx,cy,color,glyph,label,sub,side) : side est faux (légende en dessous), 'l', 't' ou vrai (droite). Une légende en dessous bloque toute ligne verticale traversant cette colonne. Déplacez-la sur le côté.
• chipRow(cy, items, x0) dessine des pastilles d'autorisation à côté d'une tuile de rôle. Chaque élément est [texte, couleur de bande, id, deny?] ; chaque pastille est un .node, donc une étape Play peut l'illuminer, et deny? ajoute le contour rouge. Une pastille mesure 360 px de large ; la vérification échoue si le texte dépasse.
• Les marqueurs de flèche résident dans un seul SVG caché mais rendu en haut du body. N'ajoutez jamais defs() dans un slide : un marqueur dans un slide display:none ne s'affiche pas sur les autres slides.
• Classes de ligne : .arr flèche de flux principal continue (chaque flèche doit être dans une étape Play) ; .arr deny rouge en tiretés, pour un Deny explicite ou une limite d'autorisations ; .mon flux secondaire en pointillés ; .deploy dépôt → compte ; .uses utilisation inter-comptes. Les chemins utilisent uniquement M H V L absolus.
• Glyphes dans G : cœur clock, ecs, lambda, ssm, kms, sqs, rpc, hash, cube, target ; réseau alb, nat, igw, ep, ec2, db, waf, r53, logs, user ; identité role, gcp ; release branch, cloud ; IA brain ; marques github, vercel, discord, pagerduty, slack. Les glyphes de marque sont blancs : donnez à la tuile la couleur de la marque (github #24292f, vercel #000000, discord #5865F2, pagerduty #06AC38 ; slack est en couleur, tuile #ffffff). N'ajoutez une marque que sous son véritable chemin de logo.
• Les slides réseau, IAM, release et matrice sont dans le modèle sous forme de sections commentées. Décommentez la section, remplissez #net, #iam, #rel ou la table .mx, et enregistrez chaque Play avec player().

Étape 1 — Recherche du système dans le code (obligatoire, avant de dessiner)

Recherche sur la branche de déploiement : la branche dont le merge s'applique à la production. Comparez avec la branche par défaut uniquement pour noter les écarts ; dessinez ce que la production exécute. Déléguez à un sous-agent si le dépôt est volumineux. Demandez-lui un brief factuel avec les chemins de fichiers.

1. Lisez les fichiers AGENTS.md / README du dépôt, puis l'IaC (Terraform, CDK, etc.), le code du service, les contrats et les documents de déploiement. Suivez les références vers les dépôts frères.
2. Décidez ce que le diagramme doit montrer. Partez du flux principal demandé par l'utilisateur. Listez les éléments qu'il touche, de bout en bout, et ne gardez que ce dont le public a besoin pour comprendre ce flux. Types d'éléments typiques :
   • Composants d'exécution : tâches, fonctions, services, workers, moniteurs, jobs.
   • Déclencheurs : planificateurs, files d'attente, événements, webhooks, utilisateurs.
   • Données et configuration : magasins de paramètres, secrets, bases de données, files d'attente.
   • Confiance et signature : magasins de clés, signataires, rôles qui traversent une frontière.
   • Parties externes : fournisseurs RPC/API, outils de chat/alertes, chaînes, services tiers.
   • Frontières : comptes, régions, réseaux, on-chain vs off-chain. Dites quels éléments vous laissez de côté, et pourquoi.
3. Pour chaque élément que vous gardez, trouvez dans le code ce qui compte pour le diagramme. Seuls les faits qui deviennent un bloc, une flèche ou une légende : ce qui le démarre ; ce qu'il lit ; ce qu'il écrit ou envoie ; qui signe ou autorise pour lui, et avec quoi ; qui paie pour lui (frais, gas, propriétaire des coûts ; cherchez les exceptions) ; dans quelle frontière il se trouve.
4. Propriété. Faites un tableau des comptes × régions, et des dépôts → ce que chacun déploie où, uniquement si le système a plus d'un compte ou plus d'une région. Si ce n'est pas le cas, sautez ce tableau et le slide de propriété.
5. Réseau. Lisez l'IaC réseau en entier : VPC et sous-réseaux (CIDR, nombre d'AZ, dans quel niveau se trouve chaque ressource), tables de routage, NAT et passerelles Internet, points de terminaison privés (et si le DNS privé est activé), chaque groupe de sécurité et chaque règle (source, port, référence CIDR ou SG), équilibreurs de charge (interne ou face à Internet, action par défaut de l'écouteur), type d'origine CDN, découverte de services, bastion ou autre accès humain, journaux de flux. Notez ce qui se trouve dans les sous-réseaux publics. Notez quels appels API cloud sortent via NAT car aucun point de terminaison n'existe. Rédigez le résultat sous forme de registre d'arêtes avant de dessiner : une ligne par paire de règle de groupe de sécurité et par groupe cible d'équilibreur de charge, sous la forme source → destination :port (fichier:ligne). Greppez chaque ressource de règle (pour AWS : aws_vpc_security_group_ingress_rule, aws_vpc_security_group_egress_rule, blocs ingress/egress, aws_lb_target_group, aws_lb_listener, aws_vpc_endpoint) dans la racine et chaque module qu'elle appelle. Ne construisez pas le registre à partir d'un résumé ou de mémoire.
6. IAM. Greppez chaque rôle, politique, attachement de politique, document de politique, politique de confiance et limite d'autorisations dans la racine et ses modules. Rédigez un registre IAM, une ligne par rôle : rôle | approuvé par + chaque condition | autorisations principales | deny explicites, limite | fichier:ligne. Les conditions sont les faits dont le public a besoin : identifiant du dépôt OIDC, référence, environnement, ExternalId, SourceAccount, nom de session. Ensuite choisissez :
   • Rôles principaux : rôles qui traversent une frontière (un autre compte, CI, un client), peuvent modifier l'infrastructure, ou touchent des données client. Les rôles qui écrivent uniquement leurs propres logs sont laissés de côté (signalez-les).
   • Politiques critiques (0–5) : instructions Deny explicites, limites d'autorisations, ressources *, iam:PassRole, sts:AssumeRole inter-comptes. Citez le sid. S'il n'y en a pas, dites-le ; n'en inventez pas.
7. Chemin de release. Lisez chaque workflow CI : déclencheur (pull_request ou push, branches, paths), l'environnement CI, le rôle qu'il assume, les gardes fork-PR, les étapes de construction avant apply, et le dispatch manuel. Lisez les règles du dépôt pour savoir qui merge les releases. Pour les images d'application, lisez les rôles de déploiement (référence de confiance, ce qu'ils peuvent pousser et mettre à jour) et si l'IaC ignore les modifications de définition de tâche. Les workflows de dépôt d'application en dehors de ce dépôt sont NON CONFIRMÉS sauf si vous les lisez.
8. Magasins de données. Listez chaque magasin qui contient des données client, d'audit ou des secrets : bases de données, buckets, état IaC, groupes de logs, magasins de secrets. Pour chacun : clé de chiffrement (KMS client, géré par le cloud, géré par le stockage) et TLS, rétention (sauvegardes, Object Lock, versioning, cycle de vie, jours de log, protection contre la suppression, fenêtre de récupération des secrets), disponibilité (Multi-AZ, copies dans une autre région ou un autre compte), exposition, qui peut lire les données (pas la configuration) y compris CI après ses deny, et audit (événements de données, logs de base de données). Évaluez chaque cellule comme forte, partielle ou lacune, avec un fichier:ligne.
9. État en direct. Pour chaque élément de calcul, lisez son nombre souhaité (ou réplicas, ou planification) et la porte devant lui (action par défaut WAF, règle d'écouteur, fanion de fonctionnalité). Un service à zéro, ou bloqué à la périphérie, est en sommeil ; le deck le dit.
10. Exposition publique. Greppez public_access_block, principals avec "*", acl, publicly_accessible, associate_public_ip_address, internal = false, CIDR de groupes de sécurité ouverts. Listez chaque objet public, point de terminaison ou assouplissement au niveau du compte, et son coût (par exemple, un bucket qui perd une couche de protection).
11. Fait à la main. Greppez les recherches de données pour les ancres de confiance (zones DNS, fournisseurs OIDC, buckets d'état, connexions, paramètres de compte) et pour "console", "à la main", "hors bande", "apply manuel" dans les commentaires et les guides de déploiement. Gardez une liste : "fait à la main, en dehors de l'IaC".
12. Marquez tout ce que vous ne pouvez pas confirmer dans le code comme NON CONFIRMÉ. Informez-en l'utilisateur. Ne le dessinez pas comme un fait.
13. Obtenez l'ordre des étapes à partir du code, pas de la liste de l'utilisateur. Si l'ordre du code diffère, utilisez-le et dites-le.

Ensuite écrivez ledger.txt pour la vérification à partir des registres d'arêtes et IAM : arrowId | source -> destination :port | fichier:ligne, ou - | laissé de côté : raison | fichier:ligne.

Étape 2 — Construction du deck

Slides :

1. Titre.
2. Diagramme du flux principal avec Play. Blocs du premier déclencheur à l'effet final. Boutons Play, Pas en arrière, Pas suivant et Reset, plus une légende par étape.
3. Diagramme du flux réseau avec Play. Un VPC, dessiné une fois (pas une fois par AZ ; écrivez le nombre d'AZ et les CIDR des sous-réseaux dans les titres des boîtes). Bandes : sous-réseaux publics, sous-réseaux privés. Hors du VPC : le CDN ou le client, l'opérateur, Internet. Étapes Play, dans cet ordre : trafic entrant (origine CDN, SG de l'équilibreur de charge, SG des tâches), application vers données (SG des bases de données, équilibreurs de charge internes), trafic sortant (egress des tâches, routage vers NAT, passerelle Internet), chemins isolés (fonctions sans route Internet, points de terminaison), accès humain (bastion, transferts de ports). Mettez le port à côté de chaque flèche comme texte .tag (:443, :5432). Les journaux de flux et autres observateurs sont en pointillés et pas dans le Play. Sautez ce slide si le système n'a pas de réseau propre (par exemple, uniquement des services serverless gérés), et dites-le dans le rapport.
4. Rôles IAM principaux avec Play. Trois colonnes : qui peut assumer (dépôt et branche, service cloud, un autre compte) → tuile de rôle (Sécurité #DD344C) → ce qu'il atteint (tuiles de ressource ou pastilles). Mettez les conditions de confiance comme texte .tag sur la flèche de confiance (ref: main, ExternalId). Dessinez chaque politique critique comme une ligne .arr deny rouge vers ce qu'elle bloque, avec le sid ou l'action comme étiquette (Deny ssm:*). Une étape Play par groupe de rôles (CI, déployeurs, runtime, inter-comptes), puis une étape par politique critique. Utilisez les mêmes noms que les autres slides.
5. Comment un changement atteint la prod, avec Play. Tuiles de branche sur la rangée du haut (étiquettes au-dessus), une tuile de compte sous chaque branche à laquelle elle s'applique, dépôts d'application et rôles de déploiement sur une voie du bas. Les étiquettes de flèche disent la porte (PR + plan, merge: apply, push to main). Les étapes suivent l'ordre réel ; dites quelles étapes sont faites à la main par une personne.
6. Où vivent les données (matrice). Un tableau HTML (.mx), pas un SVG. Une ligne par magasin, colonnes : chiffrement, rétention, disponibilité, exposition, qui peut lire les données, audit. Chaque cellule commence par une icône d'état et un libellé (✓ fort, ◐ partiel, ✕ lacune) et utilise les jetons d'état --good/--warn/--crit, jamais les couleurs de série. Chaque cellule a un title avec sa source. Un pied de page énonce les lacunes transversales (pas de copie dans une autre région, CI qui peut modifier ses propres deny). La matrice conserve ses propres tailles de police ; elle doit tenir dans le slide sans défilement.
7. Comptes, régions et dépôts. Un diagramme statique. Uniquement si l'Étape 1, Propriété, s'applique.
8. Points clés, 3–5 courtes lignes. Utilisez uniquement les affirmations vérifiées à l'Étape 1. Incluez une affirmation réseau si elle est vraie (par exemple, ce qui se trouve dans les sous-réseaux publics). La liste "fait à la main" va ici ou sur le slide des comptes.

Règles (apprises de la relecture ; suivez-les toutes)

Précision

• Dessinez chaque relation de signature que le code possède. Lorsqu'un magasin de clés (par exemple KMS) effectue la signature, chaque composant qui l'utilise a sa propre flèche vers lui. Cherchez plus d'un signataire.
• N'écrivez pas d'affirmation absolue ("X ne paie jamais", "Y ne détient aucun secret", "Z toujours…") avant d'avoir cherché des exceptions dans le code. Si une exception existe, dites-le ou abandonnez l'affirmation.
• Chaque propriété de sécurité ou de fiabilité sur un slide doit provenir du code ou de la configuration. N'ajoutez pas de garanties plausibles (quorums, tentatives, redondance) que vous n'avez pas trouvées.
• Dessinez chaque déclencheur et chaque lecture/écriture pour chaque élément que vous gardez. Ne dessinez pas uniquement ceux du chemin principal.

Périmètre et bruit

• Ne copiez pas le même diagramme une fois par environnement (dev/staging/prod côte à côte). Montrez un environnement, par défaut celui de production, et dites-le.
• Si la production est multi-région, montrez-la. Placez les boîtes de région à l'intérieur de chaque compte, et étiquetez chaque région avec son rôle (primaire, réplica, standby, sauvegarde).
• Flux principal vs flux secondaires. Les étapes Play couvrent uniquement le flux principal demandé par l'utilisateur. Dessinez les autres flux qui partagent la même infrastructure (supervision, alertes, admin ou jobs batch) sous forme de lignes pointillées. Gardez-les hors des étapes Play, et donnez-leur une courte légende.

Couverture (vérifiez avant chaque publication)

• Sur un slide qui couvre plusieurs environnements (chemin de release, comptes), lisez chaque racine, pas seulement celle de production. Un chemin de déploiement créé par un module que chaque racine appelle (un rôle de déploiement, un pipeline, une confiance) atteint chaque environnement : dessinez une flèche par environnement, avec la branche ou la condition que chacun approuve. "Prod only" nécessite la preuve que les autres racines ne l'appellent pas.
• Un équilibreur de charge, proxy, passerelle, point de terminaison ou file d'attente n'est jamais la fin d'une flèche. Dessinez-le ainsi que le composant derrière lui, avec le deuxième saut comme sa propre flèche et étape.

…

[Le contenu complet est trop long pour cette réponse, mais suit les mêmes principes. La traduction est effectuée selon les règles ci-dessus.]