0xtan0/skills

Infra flow deck

Salida: un Artifact HTML privado, de aproximadamente 8 diapositivas, para una reunión donde el presentador habla. Los diagramas transmiten el significado. El texto es mínimo. Cada bloque, flecha y afirmación proviene del código; nada proviene de la memoria o solo de la documentación.

Orden de trabajo: Paso 0 configuración → Paso 1 investigación y escritura de los registros → Paso 2 construcción → Paso 3 verificar hasta 0 problema(s) → Paso 4 publicar e informar.

Paso 0 — Configuración

1. Copia assets/template.html a una ruta temporal. Cada revisión y cada publicación usa esa misma ruta, por lo que la URL del Artifact permanece igual.
2. Coloca los registros (Paso 1) en un ledger.txt junto a él. assets/ledger.example.txt muestra el formato; los ids y rutas que contiene son inventados.
3. Carga el skill artifact-diagramming antes de diseñar un SVG. Sigue el contrato de la página del Artifact (tokens de tema, sin doctype, gutter lateral).

La plantilla es un mazo funcional con un ejemplo trabajado: motor de diapositivas, lógica Play/Paso/Reinicio, azulejos estilo AWS, cuadros de cuenta y región, un flujo secundario punteado y un azulejo de logotipo de marca. Cambia los datos y las coordenadas; no reescribas el motor.

Hechos del motor:

• player(svgId, prefix, steps, idleCaption) ejecuta una diapositiva Play. El prefijo '' usa #play/#back/#next/#reset/#cap; 'n' usa #nplay/…/#ncap (red), 'i' usa #iplay/…/#icap (IAM), 'r' usa #rplay/…/#rcap (publicación). Agrega su valor de retorno a stops. Un paso es {n:[ids de nodos], a:[ids de flechas], c:'caption'}; a puede estar vacío. player() se registra a sí mismo en window.__players; scripts/check.py lo lee, así que mantén la línea.
• tile(id,cx,cy,color,glyph,label,sub,side): side es falso (etiqueta debajo), 'l', 't' o verdadero (derecha). Una etiqueta debajo bloquea cualquier línea vertical que pase por esa columna. Muévela a un lado.
• chipRow(cy, items, x0) dibuja chips de concesión junto a un azulejo de rol. Cada elemento es [texto, color de raya, id, ¿denegar?]; cada chip es un .node, por lo que un paso Play puede iluminarlo, y ¿denegar? agrega el contorno rojo. Un chip tiene 360px de ancho; la verificación falla si el texto lo sobrepasa.
• Los marcadores de flecha viven en un svg oculto pero renderizado al principio de body. Nunca agregues defs() dentro de una diapositiva: un marcador en una diapositiva display:none no se pinta en otras diapositivas.
• Clases de línea: .arr flecha de flujo principal sólida (cada una debe estar en un paso Play); .arr deny roja discontinua, para una Denegación explícita o un límite de permisos; .mon flujo secundario punteado; .deploy repo → cuenta; .uses uso entre cuentas. Las rutas usan solo M H V L absolutas.
• Glifos en G: núcleo clock, ecs, lambda, ssm, kms, sqs, rpc, hash, cube, target; red alb, nat, igw, ep, ec2, db, waf, r53, logs, user; identidad role, gcp; publicación branch, cloud; IA brain; marcas github, vercel, discord, pagerduty, slack. Los glifos de marca son blancos: dale al azulejo el color de la marca (github #24292f, vercel #000000, discord #5865F2, pagerduty #06AC38; slack está en color, azulejo #ffffff). Agrega una marca solo como su ruta de logotipo real.
• Las diapositivas de red, IAM, publicación y matriz están en la plantilla como secciones comentadas. Descomenta la sección, llena #net, #iam, #rel o la tabla .mx, y registra cada Play con player().

Paso 1 — Investigar el sistema en el código (obligatorio, antes de dibujar)

Investiga en la rama de despliegue: la rama cuya fusión se aplica a producción. Compara con la rama predeterminada solo para notar desviaciones; dibuja lo que ejecuta producción. Delega a un subagente si el repositorio es grande. Pídele un resumen factual con rutas de archivo.

1. Lee los archivos AGENTS.md / README del repositorio, luego el IaC (Terraform, CDK, etc.), el código del servicio, los contratos y los documentos de despliegue. Sigue las referencias a repositorios hermanos.
2. Decide qué debe mostrar el gráfico. Comienza desde el flujo principal que el usuario pregunta. Enumera los elementos que toca, de principio a fin, y conserva solo lo que la audiencia necesita para entender ese flujo. Tipos típicos de elemento:
   • Componentes de ejecución: tareas, funciones, servicios, trabajadores, monitores, trabajos.
   • Desencadenadores: programadores, colas, eventos, webhooks, usuarios.
   • Datos y configuración: almacenes de parámetros, secretos, bases de datos, colas.
   • Confianza y firma: almacenes de claves, firmantes, roles que cruzan un límite.
   • Partes externas: proveedores de RPC/API, herramientas de chat/alertas, cadenas, servicios de terceros.
   • Límites: cuentas, regiones, redes, en-cadena vs fuera-de-cadena. Di qué elementos dejas fuera y por qué.
3. Para cada elemento que conservas, encuentra en el código lo que importa para el gráfico. Solo los hechos que se convierten en un bloque, una flecha o un caption: qué lo inicia; qué lee; qué escribe o envía; quién firma o autoriza por él, y con qué; quién paga por él (tarifas, gas, propietario del costo; busca excepciones); en qué límite se encuentra.
4. Propiedad. Haz una tabla de cuentas × regiones, y de repos → qué despliega cada uno dónde, solo si el sistema tiene más de una cuenta o más de una región. Si no es así, omite esta tabla y la diapositiva de propiedad.
5. Red. Lee el IaC de red completo: VPC y subredes (CIDRs, cantidad de AZ, en qué nivel se encuentra cada recurso), tablas de ruta, gateways NAT e Internet, puntos finales privados (y si el DNS privado está activado), cada grupo de seguridad y cada regla (origen, puerto, referencia CIDR o SG ), balanceadores de carga (interno o orientado a Internet, acción predeterminada del listener), origen CDN, descubrimiento de servicios, bastión u otro acceso humano, registros de flujo. Anota qué se encuentra en las subredes públicas. Anota qué llamadas a la API de la nube salen a través de NAT porque no existe ningún punto final. Escribe el resultado como un registro de bordes antes de dibujar: una línea por par de reglas de grupo de seguridad y por grupo de destino del balanceador de carga, como origen → destino :puerto (archivo:línea). Busca cada recurso de regla (para AWS: aws_vpc_security_group_ingress_rule, aws_vpc_security_group_egress_rule, bloques ingress/egress, aws_lb_target_group, aws_lb_listener, aws_vpc_endpoint) en la raíz y en cada módulo que llama. No construyas el registro a partir de un resumen o de memoria.
6. IAM. Busca cada rol, política, adjunto de política, documento de política, política de confianza y límite de permisos en la raíz y sus módulos. Escribe un registro IAM, una línea por rol: rol | confiado por + cada condición | concesiones principales | denegaciones explícitas, límite | archivo:línea. Las condiciones son hechos que la audiencia necesita: id del repo OIDC, ref, entorno, ExternalId, SourceAccount, nombre de sesión. Luego elige:
   • Roles principales: roles que cruzan un límite (otra cuenta, CI, un cliente), pueden cambiar infraestructura o tocan datos del cliente. Los roles que solo escriben sus propios registros se dejan fuera (repórtalos).
   • Políticas críticas (0–5): declaraciones de Denegación explícita, límites de permisos, recursos * , iam:PassRole, sts:AssumeRole entre cuentas. Cita el sid. Si no existe ninguna, dilo; no inventes una.
7. Ruta de publicación. Lee cada flujo de trabajo de CI: desencadenador (pull_request o push, ramas, paths), el entorno de CI, el rol que asume, protecciones de fork-PR, pasos de construcción antes de aplicar y despacho manual. Lee las reglas del repositorio sobre quién fusiona publicaciones. Para imágenes de aplicación, lee los roles del desplegador (referencia de confianza, qué pueden enviar y actualizar) y si el IaC ignora los cambios en la definición de tarea. Los flujos de trabajo del repositorio de la aplicación fuera de este repositorio son NO CONFIRMADOS a menos que los leas.
8. Almacenes de datos. Enumera cada almacén que contiene datos de clientes, auditoría o secretos: bases de datos, buckets, el estado del IaC, grupos de registros, almacenes de secretos. Para cada uno: clave de cifrado (KMS del cliente, gestionado por la nube, gestionado por el almacenamiento) y TLS, retención (copias de seguridad, Object Lock, versionado, ciclo de vida, días de registro, protección contra eliminación, ventana de recuperación de secretos), disponibilidad (Multi-AZ, copias en otra región o cuenta), exposición, quién puede leer los datos (no la configuración) incluido el CI después de sus denegaciones, y auditoría (eventos de datos, registros de base de datos). Califica cada celda como fuerte, parcial o brecha, con un archivo:línea.
9. Estado en vivo. Para cada elemento de cómputo, lee su recuento deseado (o réplicas, o programación) y la puerta delante de él (acción predeterminada de WAF, regla de listener, flag de característica). Un servicio en cero, o bloqueado en el borde, está estacionado; el mazo lo dice.
10. Exposición pública. Busca public_access_block, principals con "*", acl, publicly_accessible, associate_public_ip_address, internal = false, CIDRs de grupo de seguridad abiertos. Enumera cada objeto público, punto final o relajación en toda la cuenta, y qué cuesta (por ejemplo, un bucket que pierde una capa de protección).
11. Hecho a mano. Busca búsquedas de datos de anclajes de confianza (zonas DNS, proveedores OIDC, buckets de estado, conexiones, configuraciones de cuenta) y por "consola", "a mano", "fuera de banda", "aplicación manual" en comentarios y guías de despliegue. Mantén una lista: "hecho a mano, fuera del IaC".
12. Marca todo lo que no puedas confirmar en el código como NO CONFIRMADO. Informa al usuario sobre ello. No lo dibujes como un hecho.
13. Obtén el orden de los pasos del código, no de la lista del usuario. Si el orden del código difiere, úsalo y dilo.

Luego escribe ledger.txt para la verificación a partir de los registros de bordes e IAM: arrowId | origen -> destino :puerto | archivo:línea, o - | omitido: razón | archivo:línea.

Paso 2 — Construir el mazo

Diapositivas:

1. Título.
2. Diagrama de flujo principal con Play. Bloques desde el primer desencadenador hasta el efecto final. Botones Play, Paso atrás, Paso siguiente y Reiniciar, más un caption por paso.
3. Diagrama de flujo de red con Play. Una VPC, dibujada una vez (no una vez por AZ; escribe la cantidad de AZ y los CIDRs de subred en los títulos de los cuadros). Bandas: subredes públicas, subredes privadas. Fuera de la VPC: el CDN o cliente, el operador, Internet. Pasos Play, en este orden: tráfico entrante (origen CDN, SG del balanceador de carga, SGs de tarea), aplicación a datos (SGs de base de datos, balanceadores de carga internos), tráfico saliente (egreso de tarea, ruta a NAT, gateway de Internet), rutas aisladas (funciones sin ruta a Internet, puntos finales), acceso humano (bastión, reenvíos de puerto). Coloca el puerto junto a cada flecha como texto .tag (:443, :5432). Los registros de flujo y otros observadores van punteados y no están en el Play. Omite esta diapositiva si el sistema no tiene red propia (por ejemplo, solo servicios serverless gestionados) y dilo en el informe.
4. Roles IAM principales con Play. Tres columnas: quién puede asumir (repositorio y rama, servicio en la nube, otra cuenta) → azulejo de rol (Seguridad #DD344C) → qué alcanza (azulejos de recurso o chips). Coloca las condiciones de confianza como texto .tag en la flecha de confianza (ref: main, ExternalId). Dibuja cada política crítica como una línea roja .arr deny hacia lo que bloquea, con el sid o la acción como una etiqueta (Deny ssm:*). Un paso Play por grupo de roles (CI, desplegadores, ejecución, entre cuentas), luego un paso por política crítica. Usa los mismos nombres que las otras diapositivas.
5. Cómo un cambio llega a producción, con Play. Azulejos de rama en la fila superior (etiquetas arriba), un azulejo de cuenta debajo de cada rama a la que aplica, repositorios de aplicación y roles de desplegador en un carril inferior. Las etiquetas de flecha dicen la puerta (PR + plan, merge: apply, push to main). Los pasos siguen el orden real; di qué pasos realiza una persona a mano.
6. Dónde viven los datos (matriz). Una tabla HTML (.mx), no un SVG. Una fila por almacén, columnas: cifrado, retención, disponibilidad, exposición, quién puede leer los datos, auditoría. Cada celda comienza con un icono de estado y una etiqueta (✓ fuerte, ◐ parcial, ✕ brecha) y usa los tokens de estado --good/--warn/--crit, nunca colores de serie. Cada celda tiene un title con su fuente. Un pie de página indica brechas transversales (sin copia en otra región, CI que puede editar sus propias denegaciones). La matriz mantiene sus propios tamaños de fuente; debe caber en la diapositiva sin desplazamiento.
7. Cuentas, regiones y repositorios. Un diagrama estático. Solo si aplica el Paso 1, Propiedad.
8. Puntos clave, 3–5 líneas cortas. Usa solo afirmaciones que verificaste en el Paso 1. Incluye una afirmación de red si es verdadera (por ejemplo, qué está en las subredes públicas). La lista "hecho a mano" va aquí o en la diapositiva de cuentas.

Reglas (aprendidas de revisiones; cumple todas)

Precisión

• Dibuja cada relación de firma que el código tiene. Cuando un almacén de claves (por ejemplo KMS) realiza la firma, cada componente que lo usa obtiene su propia flecha hacia él. Busca más de un firmante.
• No escribas una afirmación absoluta ("X nunca paga", "Y no guarda secretos", "Z siempre…") hasta que busques excepciones en el código. Si existe una excepción, dilo o retira la afirmación.
• Cada propiedad de seguridad o fiabilidad en una diapositiva debe provenir del código o la configuración. No agregues garantías que suenen plausibles (quórums, reintentos, redundancia) que no hayas encontrado.
• Dibuja cada desencadenador y cada lectura/escritura para cada elemento que conserves. No dibujes solo los que están en la ruta principal.

Alcance y ruido

• No copies el mismo diagrama una vez por entorno (dev/staging/prod lado a lado). Muestra un entorno, por defecto el de producción, y dilo.
• Si la producción es multi-región, muéstralo. Coloca cuadros de región dentro de cada cuenta y etiqueta cada región con su rol (primaria, réplica, en espera, copia de seguridad).
• Flujo principal vs flujos secundarios. Los pasos Play cubren solo el flujo principal que el usuario preguntó. Dibuja otros flujos que comparten la misma infraestructura (monitoreo, alertas, administración o trabajos por lotes) como líneas punteadas. Mantenlos fuera de los pasos Play y dales una leyenda corta.

Cobertura (verificar antes de cada publicación)

• En una diapositiva que abarca entornos (ruta de publicación, cuentas), lee cada raíz, no solo la de producción. Una ruta de despliegue creada por un módulo que cada raíz llama (un rol de desplegador, un pipeline, una confianza) alcanza cada entorno: dibuja una flecha por entorno, con la rama o condición que cada uno confía. "Solo producción" necesita prueba de que las otras raíces no lo llaman.
• Un balanceador de carga, proxy, gateway, punto final o cola nunca es el final de una flecha. Dibújalo y el componente detrás de él, con el segundo salto como su propia flecha y paso.

…

[truncado para la traducción]