Tres flujos de control internos en notación de actividades UML 2.5.1. No repiten lo que ya está en los diagramas BPMN: aquellos documentan procesos de negocio (quién habla con quién para cobrar, para dar acceso, para responder a un incidente); estos documentan algoritmos, que es donde esta notación aporta lo que BPMN no tiene tan a mano: la rama concurrente que nunca se vuelve a unir y el bucle de reintento.
El SVG se genera en el servidor desde un modelo tipado (src/data/actividades.ts); las posiciones, el ruteo y el corte de etiquetas los calcula src/lib/uml-activity.ts. Los tests no solo verifican el dibujo (nada encimado, ninguna transición atravesando una figura ajena): también verifican la notación - que toda decisión tenga al menos dos salidas y todas con guarda, que una unión tenga una sola salida, que ningún nodo final tenga transiciones salientes y que no queden nodos inalcanzables.
No se usó Mermaid a propósito: su flowchart no es notación de actividad (no tiene barra de bifurcación, ni particiones, ni distingue el final de flujo del final de actividad), y esas tres cosas son justo lo que estos diagramas afirman.
Notación
- Nodo inicialCírculo relleno. Donde arranca la actividad; no admite transiciones entrantes.
- AcciónRectángulo de esquinas redondeadas: un paso ejecutable.
- DecisiónRombo con una entrada y varias salidas, cada una con su guarda entre corchetes.
- Unión de decisiónEl mismo rombo al revés: varias entradas, una sola salida sin guarda.
- BifurcaciónBarra que reparte el control en ramas concurrentes.
- Unión concurrenteLa misma barra sincronizando: no sigue hasta que llegan todas las ramas.
- Envío de señalPentágono con la punta hacia fuera: el sistema notifica.
- Recepción de eventoPentágono con la muesca: el sistema espera algo de fuera.
- Final de actividadDiana. Termina la actividad completa, incluidas las ramas vivas.
- Final de flujoCírculo con aspa. Termina ESTA rama y deja la actividad corriendo.
Atención de una solicitud en el middleware
El camino completo de un request desde que entra al edge hasta que sale con sus cabeceras. Concentra en un solo punto la normalización de idioma, el chaos del LAB, la blocklist, el límite de peticiones y las dos autenticaciones, en ese orden.
src/middleware.ts · src/lib/security/{sensor,blocklist,ratelimit-durable}.ts · src/i18n/routing.ts
La ruta se normaliza con delocalizePath UNA sola vez, al principio, y todos los guardas posteriores comparan contra la ruta canónica. Si el prefijo de idioma sobreviviera hasta la comprobación de sesión, /en/admin sería una copia del panel sin vigilancia.
Integración, despliegue y verificación con rollback
Del push a main hasta producción verificada. Las dos ramas de verificación (pruebas y seguridad/accesibilidad) corren concurrentes y se sincronizan antes de desplegar; después del deploy hay una etapa más, la que decide si la versión nueva se queda o se revierte.
.github/workflows/{ci,security,a11y,dast}.yml · src/pages/api/health.ts · src/pages/docs/pipeline-en-vivo.astro
La barra de unión no es decorativa: si una sola de las dos ramas falla, el token de control nunca se completa y el despliegue no ocurre. El rollback se dispara desde el resultado del health check contra el deploy ya publicado, no desde el resultado de los tests.
Aplicación idempotente de un evento de la pasarela
Qué ocurre dentro del sistema cuando llega un webhook de pago. No es el proceso de cobro (ese está en BPMN): es el algoritmo que garantiza que un evento repetido, reenviado o simultáneo no cobre dos veces ni deje el pago a medias.
src/pages/api/payments/webhook.ts · src/lib/payments.ts · src/lib/payments-state.ts
La transición se calcula en un módulo puro (payments-state.ts) sin acceso a base de datos, para poder ejercitarla en pruebas y también en el navegador. La escritura es la única parte que toca Turso, y va condicionada a la versión leída.