0xtan0/skills – Infra-Flow-Deck

Infra-Flow-Deck

Ausgabe: ein privates HTML-Artifact, etwa 8 Folien, für ein Meeting, in dem der Vortragende spricht. Die Diagramme tragen die Bedeutung. Der Text ist minimal. Jeder Block, Pfeil und jede Behauptung stammt aus dem Code; nichts stammt aus dem Gedächtnis oder allein aus Dokumenten.

Reihenfolge der Arbeit: Schritt 0 Einrichtung → Schritt 1 Recherche und Schreiben der Ledger → Schritt 2 Bauen → Schritt 3 Prüfen bis 0 problem(s) → Schritt 4 Veröffentlichen und Berichten.

Schritt 0 — Einrichtung

1. Kopiere assets/template.html in einen Scratch-Pfad. Jede Überarbeitung und jede Veröffentlichung verwendet denselben Pfad, damit die Artifact-URL gleich bleibt.
2. Lege die Ledger (Schritt 1) in eine ledger.txt daneben. assets/ledger.example.txt zeigt das Format; die darin enthaltenen IDs und Pfade sind erfunden.
3. Lade das artifact-diagramming-Skill, bevor du ein SVG layoutest. Folge dem Artifact-Seite- Vertrag (Theme-Tokens, kein Doctype, Seiten-Gutter).

Die Vorlage ist ein funktionierendes Deck mit einem ausgearbeiteten Beispiel: Slide-Engine, Play/Step/Reset-Logik, AWS-artige Kacheln, Account- und Region-Boxen, einen gepunkteten sekundären Fluss und ein Markenlogo-Kachel. Ändere die Daten und die Koordinaten; schreibe die Engine nicht neu.

Engine-Fakten:

• player(svgId, prefix, steps, idleCaption) führt eine Play-Folie aus. Präfix '' verwendet #play/#back/#next/#reset/#cap; 'n' verwendet #nplay/…/#ncap (Netzwerk), 'i' verwendet #iplay/…/#icap (IAM), 'r' verwendet #rplay/…/#rcap (Release). Schiebe seinen Rückgabewert in stops. Ein Schritt ist {n:[Knoten-IDs], a:[Pfeil-IDs], c:'Beschriftung'}; a kann leer sein. player() registriert sich selbst in window.__players; scripts/check.py liest das, also behalte die Zeile.
• tile(id,cx,cy,color,glyph,label,sub,side): side ist falsy (Label unten), 'l', 't' oder truthy (rechts). Ein Label unten blockiert jede vertikale Linie durch diese Spalte. Verschiebe es beiseite.
• chipRow(cy, items, x0) zeichnet Grant-Chips neben einer Rollen-Kachel. Jedes Item ist [text, Streifenfarbe, id, deny?]; jeder Chip ist ein .node, sodass ein Play-Schritt es beleuchten kann, und deny? fügt den roten Umriss hinzu. Ein Chip ist 360px breit; die Prüfung schlägt fehl bei Text, der darüber hinausläuft.
• Pfeilmarker leben in einem versteckten, aber gerenderten SVG am Anfang des body. Füge niemals defs() innerhalb einer Folie hinzu: ein Marker in einer display:none-Folie wird auf anderen Folien nicht gemalt.
• Linienklassen: .arr durchgehender Hauptfluss-Pfeil (jeder muss in einem Play-Schritt sein); .arr deny rot gestrichelt, für ein explizites Deny oder eine Berechtigungsgrenze; .mon gepunkteter sekundärer Fluss; .deploy Repo → Account; .uses Cross-Account-Nutzung. Pfade verwenden nur absolute M H V L.
• Glyphen in G: Core clock, ecs, lambda, ssm, kms, sqs, rpc, hash, cube, target; Netzwerk alb, nat, igw, ep, ec2, db, waf, r53, logs, user; Identität role, gcp; Release branch, cloud; AI brain; Marken github, vercel, discord, pagerduty, slack. Marken-Glyphen sind weiß: gib der Kachel die Markenfarbe (github #24292f, vercel #000000, discord #5865F2, pagerduty #06AC38; slack ist farbig, Kachel #ffffff). Füge eine Marke nur als ihren echten Logopfad hinzu.
• Die Netzwerk-, IAM-, Release- und Matrix-Folien sind in der Vorlage als auskommentierte Abschnitte. Kommentiere den Abschnitt aus, fülle #net, #iam, #rel oder die .mx-Tabelle aus und registriere jede Play mit player().

Schritt 1 — Recherchiere das System im Code (obligatorisch, vor dem Zeichnen)

Recherchiere auf dem Deploying-Branch: dem Branch, dessen Merge auf die Produktion angewendet wird. Vergleiche nur mit dem Standard-Branch, um Abweichungen festzustellen; zeichne, was die Produktion ausführt. Delegiere an einen Unteragenten, wenn das Repo groß ist. Bitte ihn um ein faktisches Briefing mit Dateipfaden.

1. Lese die AGENTS.md / README-Dateien des Repos, dann das IaC (Terraform, CDK usw.), den Service-Code, die Verträge und die Deploy-Dokumente. Folge Verweisen auf Schwester-Repos.
2. Entscheide, was das Diagramm zeigen muss. Beginne mit dem Hauptfluss, nach dem der Benutzer fragt. Liste die Elemente auf, die es berührt, Ende zu Ende, und behalte nur, was das Publikum braucht, um diesen Fluss zu verstehen. Typische Arten von Elementen:
   • Laufzeitkomponenten: Tasks, Funktionen, Services, Worker, Monitore, Jobs.
   • Trigger: Scheduler, Queues, Events, Webhooks, Benutzer.
   • Daten und Konfiguration: Parameter-Stores, Secrets, Datenbanken, Queues.
   • Vertrauen und Signieren: Key-Stores, Signierer, Rollen, die eine Grenze überschreiten.
   • Externe Parteien: RPC/API-Anbieter, Chat/Alerting-Tools, Chains, Drittanbieterdienste.
   • Grenzen: Accounts, Regionen, Netzwerke, On-Chain vs. Off-Chain. Sage, welche Elemente du weglässt und warum.
3. Finde für jedes erhaltene Element im Code, was für das Diagramm wichtig ist. Nur die Fakten, die zu einem Block, einem Pfeil oder einer Beschriftung werden: was es startet; was es liest; was es schreibt oder sendet; wer für es signiert oder autorisiert, und womit; wer dafür bezahlt (Gebühren, Gas, Kosteninhaber; suche nach Ausnahmen); in welcher Grenze es sich befindet.
4. Eigentümer. Erstelle eine Tabelle von Accounts × Regionen und von Repos → was jedes wo deployed, nur wenn das System mehr als einen Account oder mehr als eine Region hat. Wenn nicht, überspringe diese Tabelle und die Eigentümer-Folie.
5. Netzwerk. Lese das Netzwerk-IaC vollständig: VPC und Subnetze (CIDRs, AZ-Anzahl, in welcher Ebene sich jede Ressource befindet), Routentabellen, NAT- und Internet-Gateways, private Endpunkte (und ob Private DNS aktiv ist), jede Security Group und jede Regel (Quelle, Port, CIDR- oder SG- Referenz), Load Balancer (intern oder internetzugewandt, Listener-Standardaktion), CDN- Origin-Typ, Service Discovery, Bastion oder anderer menschlicher Zugang, Flow Logs. Notiere, was sich in den öffentlichen Subnetzen befindet. Notiere, welche Cloud-API-Aufrufe durch NAT gehen, weil kein Endpunkt existiert. Schreibe das Ergebnis als Edge-Ledger, bevor du zeichnest: eine Zeile pro Security-Group-Regel- Paar und pro Load-Balancer-Zielgruppe, als source → destination :port (datei:zeile). Greife nach jeder Regel-Ressource (für AWS: aws_vpc_security_group_ingress_rule, aws_vpc_security_group_egress_rule, ingress/egress-Blöcke, aws_lb_target_group, aws_lb_listener, aws_vpc_endpoint) durch das gesamte Root und jedes aufgerufene Modul. Baue das Ledger nicht aus einer Zusammenfassung oder aus dem Gedächtnis.
6. IAM. Durchsuche jede Rolle, Richtlinie, Richtlinienanbindung, Richtliniendokument, Vertrauensrichtlinie und Berechtigungsgrenze im Root und seinen Modulen. Schreibe ein IAM-Ledger, eine Zeile pro Rolle: rolle | vertraut von + jede Bedingung | Hauptberechtigungen | explizite Denys, Grenze | datei:zeile. Bedingungen sind Fakten, die das Publikum braucht: OIDC-Repo-ID, Ref, Umgebung, ExternalId, SourceAccount, Sitzungsname. Wähle dann:
   • Hauptrollen: Rollen, die eine Grenze überschreiten (ein anderer Account, CI, ein Kunde), die Infrastruktur ändern können oder Kundendaten berühren. Rollen, die nur ihre eigenen Logs schreiben, werden weggelassen (berichte sie).
   • Kritische Richtlinien (0–5): explizite Deny-Anweisungen, Berechtigungsgrenzen, * Ressourcen, iam:PassRole, Cross-Account sts:AssumeRole. Zitiere die Sid. Wenn keine existieren, sage das; erfinde keine.
7. Release-Pfad. Lese jeden CI-Workflow: Trigger (pull_request oder push, Branches, paths), die CI-Umgebung, die angenommene Rolle, Fork-PR-Schutz, Build-Schritte vor Apply und manuelles Dispatch. Lese die Repo-Regeln, wer Releases mergen darf. Für App-Images, lese die Deployer-Rollen (Trust-Ref, was sie pushen und aktualisieren können) und ob das IaC Task-Definitionsänderungen ignoriert. App-Repo-Workflows außerhalb dieses Repos sind UNCONFIRMED, es sei denn, du liest sie.
8. Datenspeicher. Liste jeden Speicher auf, der Kunden-, Audit- oder secret-Daten enthält: Datenbanken, Buckets, den IaC-Status, Log-Gruppen, Secret-Stores. Für jeden: Verschlüsselungsschlüssel (Kunden- KMS, cloud-verwaltet, speicherverwaltet) und TLS, Aufbewahrung (Backups, Object Lock, Versionierung, Lebenszyklus, Logtage, Löschschutz, Secret-Wiederherstellungsfenster), Verfügbarkeit (Multi-AZ, Kopien in einer anderen Region oder einem anderen Account), Exposition, wer die Daten lesen kann (nicht die Konfiguration) einschließlich CI nach seinen Denys, und Audit (Datenereignisse, Datenbanklogs). Bewerte jede Zelle stark, teilweise oder Lücke, mit einer datei:zeile.
9. Live-Zustand. Lese für jedes Compute-Element seine gewünschte Anzahl (oder Replicas, oder Zeitplan) und das Gate davor (WAF-Standardaktion, Listener-Regel, Feature-Flag). Ein Service bei Null oder am Rand blockiert ist geparkt; das Deck sagt das.
10. Öffentliche Exposition. Suche nach public_access_block, principals mit `