Curso de Swamp

Instalación de Swamp CLI mediante el instalador oficial.

Verificación de la instalación mediante `swamp version`.

Configuración del PATH cuando la CLI no queda disponible automáticamente.

Diferencias de entorno entre macOS y Linux.

Inicialización de un repositorio mediante `swamp repo init`.

Estructura de un repositorio Swamp.

Función de `.swamp.yaml` como configuración compartida a nivel de repositorio.

Función del directorio `.swamp` como almacenamiento local de runtime.

Exclusión de `.swamp` del control de versiones cuando contiene datos locales de ejecución.

Organización de models dentro de un repositorio.

Organización de workflows.

Organización de vaults.

Organización de extensions y sus lockfiles.

Gestión de configuración global de usuario.

Variables de entorno con prefijo `SWAMP_`.

Flags de CLI para modificar comportamiento en una ejecución concreta.

Orden de precedencia entre configuración de repositorio, usuario, variables de entorno y CLI.

Configuración compartida frente a configuración específica de cada operador.

Uso de `swamp config set` para preferencias del usuario.

Shell completions para bash, zsh y fish.

Actualización de la CLI mediante `swamp update`.

Configuración de background autoupdating.

Diferencias entre actualización interactiva y automatizada.

Mantenimiento de repositorios reproducibles mediante Git.

Convenciones para estructurar repositorios destinados a equipos.

Model como unidad fundamental de trabajo en Swamp.

Separación entre model type y model definition.

Type como lógica reutilizable implementada en TypeScript.

Definition como configuración YAML específica de una instancia.

Ventajas de separar código reutilizable y configuración.

Model types orientados a sistemas externos.

Methods como operaciones disponibles dentro de un model type.

Inputs de un método.

Outputs producidos por la ejecución.

Uso de schemas para validar entradas y resultados.

Validación temprana antes de realizar operaciones externas.

Creación de múltiples definitions a partir del mismo type.

Modelado de distintos recursos utilizando una única capacidad reutilizable.

Ejecución mediante `swamp model method run`.

Resolución de un model antes de su ejecución.

Obtención de resultados estructurados.

Recursos producidos por un método.

Archivos producidos durante una ejecución.

Reports derivados de la información generada.

Auto-creation frente a definitions explícitas.

Factory Pattern para reutilizar un model con diferentes inputs.

Identificación estable de instancias creadas dinámicamente.

Ejecución model-to-model mediante `context.runModel()`.

Declaración de dependencias entre models.

Límites de profundidad en invocaciones encadenadas.

Diseño de models idempotentes.

Encapsulación de APIs y operaciones externas detrás de una interfaz tipada.

Criterios para determinar cuándo crear un nuevo model type y cuándo reutilizar uno existente.

La capa de datos como mecanismo de composición entre models y workflows.

Generación de datos en cada ejecución de un método.

Datos inmutables como mecanismo para preservar historial.

Versionado automático de resultados.

Metadata asociada al model que produjo cada dato.

Registro de timestamps, versiones y tags.

Diferencias entre resources, files y reports.

Recuperación de la última versión mediante `data.latest()`.

Consulta de datos históricos.

Uso de Common Expression Language en Swamp.

Sintaxis básica de expresiones CEL.

Operadores lógicos y comparaciones.

Navegación por atributos de datos.

Filtrado de resultados mediante `swamp data query`.

Selección y proyección de campos mediante consultas.

Uso de datos de ejecuciones anteriores como entrada de nuevas operaciones.

`data.query()` dentro de workflows.

`context.queryData()` desde extensions.

Consultas orientadas a humanos para inspeccionar el estado.

Consultas orientadas a agentes para razonar sobre datos acumulados.

Data chaining entre distintos models.

Version history como evidencia de lo ejecutado.

Forward references para preservar referencias cuando cambia un nombre.

Lifetime `ephemeral`.

Lifetime asociado a un job.

Lifetime asociado al workflow.

Lifetime basado en duración.

Lifetime infinito.

Garbage collection de datos antiguos.

Equilibrio entre conservación, capacidad de consulta y consumo de almacenamiento.

Provenance como elemento para comprender de dónde procede cada resultado.

Uso de datos inmutables como base para reproducibilidad y auditoría.

Qué es un workflow dentro de Swamp.

Workflow como grafo dirigido acíclico de jobs.

Jobs como agrupadores de steps.

Ejecución de jobs según sus dependencias.

Paralelismo de steps dentro de un mismo job.

Dependencias explícitas como mecanismo para controlar el orden.

Ejecución de métodos de models desde un step.

Paso de datos entre etapas mediante CEL.

Validación del workflow antes de ejecutarlo.

Detección de dependencias inexistentes.

Validación de nombres de jobs.

Ejecución mediante `swamp workflow run`.

Workflows anidados.

Invocación de otro workflow desde un step.

Paso de inputs hacia workflows llamados.

`forEach` como primitiva para procesar colecciones.

Paralelización basada en elementos.

Creación de flujos fan-out y fan-in.

Condiciones basadas en datos existentes.

Fallos explícitos cuando los datos requeridos todavía no existen.

Diseño de workflows mantenibles evitando scripts monolíticos.

Separación de recopilación, análisis, decisión y acción.

Reutilización de los mismos models en diferentes workflows.

Encadenamiento de herramientas de distintos sistemas.

Modelado de procesos operativos repetibles mediante DAGs.

Validación previa como mecanismo de calidad antes de automatizar operaciones reales.

Ejecución manual de workflows.

Trigger basado en schedule.

Expresiones cron para automatizaciones periódicas.

Validación de schedules.

Registro de schedules mediante swamp serve.

Ejecuciones recurrentes sin intervención del agente.

Trigger basado en webhook.

Exposición de endpoints HTTP desde swamp serve.

Recepción de payloads de sistemas externos.

Acceso a `webhook.body` desde CEL.

Acceso a headers del webhook.

Acceso a parámetros de consulta.

Verificación de firmas HMAC.

Webhooks de GitHub.

Webhooks de Linear.

Webhooks de Stripe.

Webhooks genéricos para otros sistemas.

Gestión del secreto mediante variables de entorno.

Gestión mediante archivos montados.

Gestión mediante vaults.

Propagación W3C `traceparent` y `tracestate`.

Correlación de ejecuciones con trazas externas.

Steps `manual_approval`.

Suspensión de un workflow hasta recibir aprobación humana.

Persistencia del estado del workflow suspendido.

Aprobación o rechazo con motivo.

Separación conceptual entre aprobación y reanudación.

Guards para impedir repetir efectos ya completados.

Idempotencia en automatizaciones con operaciones irreversibles.

Reanudación mediante `resume --from`.

Cancelación de ejecuciones bloqueadas.

Assert steps para comprobar estados antes de continuar.

Severidades y códigos de salida utilizados en CI.

Generación de JUnit XML para sistemas de reporting.

Problema de introducir credenciales directamente en configuraciones de automatización.

Separación entre data path y secret path.

Vault como mecanismo para almacenar información sensible.

Resolución de secretos únicamente durante el runtime.

Uso de `vault.get()` desde configuraciones.

Prevención de almacenamiento de secretos en YAML.

Prevención de persistencia en `.swamp`.

Redacción automática de valores sensibles en outputs.

Campos marcados como sensitive dentro de schemas.

Redirección automática hacia almacenamiento seguro.

Creación de vaults `local_encryption`.

Cifrado local mediante la identidad disponible en el equipo.

Inserción de claves mediante `swamp vault put`.

Enumeración segura de nombres mediante `swamp vault list-keys`.

Metadata asociada a los secretos.

Anotación con URL de origen y notas de finalidad.

Inspección de metadata sin revelar valores.

Migración entre backends de vault.

Uso de AWS Secrets Manager.

Integración con Azure Key Vault.

Integración con 1Password mediante proveedores disponibles.

Dry-run antes de una migración.

Comprobación de salud mediante `swamp doctor vaults`.

Refresh hooks para credenciales rotatorias.

Auditoría de accesos de lectura.

Diseño de vaults para equipos.

Separación entre secretos de desarrollo y producción.

Eliminación de credenciales del contexto visible para el agente.

Principio de mínimo privilegio sobre los sistemas externos.

Rotación y ciclo de vida de credenciales utilizadas por automatizaciones.

Por qué Swamp está diseñado para ser operado por agentes.

Agente de IA como capa de interpretación de intención y Swamp como capa de ejecución estructurada.

Separación entre razonamiento no determinista y operaciones tipadas.

Utilización de Swamp desde agentes que pueden ejecutar shell.

Flujo desde petición en lenguaje natural hasta model definition.

Generación de YAML conforme a schemas existentes.

Ejecución posterior mediante métodos predefinidos.

Uso de resultados versionados como nuevo contexto para el agente.

Diferencias entre un agente que llama directamente a una API y uno que utiliza un model Swamp.

Reducción de prompts repetitivos mediante automatizaciones persistentes.

Skills como documentos Markdown que enseñan capacidades al agente.

Skill principal `swamp`.

Skill `swamp-getting-started` para onboarding.

Routing desde una intención del usuario hacia la documentación operativa adecuada.

Sincronización de Skills durante actualizaciones de Swamp.

Built-in tools disponibles para agentes.

Custom tools.

Repositorios configurados para varios agentes.

Inicialización específica del repositorio según la herramienta de IA utilizada.

Reutilización de la misma automatización desde agentes distintos.

Agentes como autores de nuevos models y workflows.

Agentes como consumidores de automatizaciones preexistentes.

Control de acciones del agente mediante schemas y métodos restringidos.

Utilización de aprobaciones humanas antes de efectos críticos.

Registro de resultados para que otra persona o agente pueda continuar posteriormente.

Diseño de automatizaciones agent-friendly.

Criterios para decidir qué parte debe resolver el agente y qué parte debe codificarse en una extension.

Prevención de vendor lock-in manteniendo la automatización en Swamp.

Qué es una Swamp extension.

Casos donde una capacidad existente del registry es suficiente.

Casos donde resulta necesario construir una extension propia.

Extensions que proporcionan model types.

Extensions que proporcionan vault providers.

Extensions que proporcionan datastore providers.

Extensions que proporcionan reports.

Inclusión de workflows dentro de extensions.

Inclusión de Skills.

Implementación de model types en TypeScript.

Definición de schemas de entrada.

Definición de schemas de salida.

Uso de Zod para contratos de los models.

Implementación del comportamiento de cada método.

Acceso al execution context.

Consulta de datos desde una extension.

Invocación controlada de otros models.

Organización del código de extensions.

Archivo `manifest.yaml`.

Identidad y namespace de una extension.

Metadata y descripción.

Declaración de models.

Declaración de workflows.

Declaración de vaults y datastores.

Declaración de reports y Skills.

Archivos adicionales y binaries.

Declaración informativa de plataformas soportadas.

Dependencias entre extensions.

CalVer como estrategia de versionado utilizada en el registry.

Release notes.

Smoke testing antes de publicar.

Compatibilidad de una extension con diferentes repositorios.

Mantenimiento de una biblioteca interna de capacidades.

Función del Extension Registry dentro del ecosistema Swamp.

Instalación de extensions creadas por otras personas y organizaciones.

Namespaces de extensions.

Collectives como propietarios de paquetes compartidos.

Pull de extensions.

Lockfile para fijar las versiones exactas utilizadas por un repositorio.

Actualización controlada de extensions.

Identificación de versiones desactualizadas.

Desarrollo local antes de publicar.

Validación del manifest.

Publishing lifecycle como proceso con múltiples gates.

Separación entre authoring y publishing.

Extension Scorecard como indicador de calidad.

Criterios de calidad evaluados por el scorecard.

Diferencia entre puntuación de calidad y distintivo Verified by Swamp.

Protección de consumidores frente a packages deficientes.

Extension trust como frontera de seguridad.

Collective `swamp` como única fuente confiable de forma predeterminada.

Adición explícita de otros collectives confiables.

Eliminación de fuentes que dejan de ser de confianza.

Auto-trust para collectives de los que el usuario es miembro.

Riesgos de auto-trust en entornos CI.

Preferencia por trust explícito en pipelines sensibles.

Bloqueo de ejecución cuando una extension procede de un collective no confiable.

Revisión de código de extensions críticas.

Auditoría de dependencias.

Version pinning.

Gestión de private extensions.

Private Collectives para automatización empresarial.

Creación de una política corporativa de adopción de extensions.

Separación entre extensions públicas, privadas y administradas.

Evolución desde un repositorio local hacia un entorno compartido.

Limitaciones de `.swamp` como datastore de una única máquina.

Shared datastore para permitir que varios miembros consulten los mismos datos.

Configuración de un datastore respaldado por Amazon S3.

Uso de `@swamp/s3-datastore`.

Bucket y prefix como destino de datos compartidos.

Migración de información local al nuevo backend.

Verificación del estado mediante `swamp datastore status`.

Permisos IAM necesarios para el bucket.

Compatibilidad con endpoints S3.

Uso de almacenamiento compatible con S3.

Lazy hydration desde backends remotos.

Locking distribuido.

Sincronización entre miembros del equipo.

Limitaciones de `local_encryption` para secretos compartidos.

Migración de vaults hacia AWS Secrets Manager.

Separación entre configuración versionada y credenciales.

Commit de `.swamp.yaml`.

Commit de la configuración de vaults.

Lock de versions de extensions.

Exclusión de runtime data del repositorio Git.

Onboarding de nuevos miembros.

Resolución de extensions desde el lockfile.

Resolución de vaults utilizando las credenciales propias del nuevo usuario.

Collectives como unidad de colaboración.

Private Extensions en planes para equipos.

Private Collectives.

Asientos portables para usuarios humanos.

Diferencia entre usuario humano, agente y runner de CI a efectos de licenciamiento.

Diseño de un repositorio compartido mantenible por varios equipos.

Objetivo de `swamp serve`.

Exposición remota de un repositorio Swamp.

Ejecución centralizada de models y workflows.

Acceso desde otros usuarios.

Acceso desde otros sistemas.

Ejecuciones lanzadas mediante API.

Webhooks como entrada.

Schedules como entrada.

Operación mediante WebSocket y HTTP.

Modos de autenticación disponibles.

OAuth y device grant flow.

Autenticación mediante tokens.

Control de admission basado en collectives.

Identificación de administradores.

Control de acceso a operaciones.

API keys personales.

Collective tokens para automatizaciones y CI/CD.

Diferencias entre ambas clases de credenciales.

Scopes para limitar capacidades.

Ciclo de creación, rotación y revocación de claves.

Uso de API keys desde sistemas no interactivos.

TLS mediante certificados directos.

TLS detrás de reverse proxies.

Integración con Caddy como patrón documentado.

Uso de `wss://` para conexiones cifradas.

Configuración remota mediante `--server`.

Ejecución de comandos contra un servidor remoto.

Administración sin necesidad de SSH.

Despliegue de swamp serve como servicio persistente.

Gestión del daemon de Swamp actualmente marcada como experimental.

launchd en macOS.

systemd en Linux.

Reinicio automático después de fallos.

Protección de secrets utilizados por el proceso.

Diseño de una instancia compartida para un equipo.

Diferencias entre ejecución local y remote execution.

Arquitectura orchestrator-worker.

Centralización de definitions y datos en el orchestrator.

Ejecución de steps en otras máquinas.

Creación de enrollment tokens.

Conexión mediante `swamp worker connect`.

Machine identity del worker.

Cache directory persistente.

Consecuencias de perder la identidad del worker.

Labels para describir capacidades y entornos.

Placement de steps hacia workers adecuados.

Capacity y slots.

Consulta de workers mediante `swamp worker list`.

Estado connected y disconnected.

Seguimiento de `last seen`.

Consulta de enrollment tokens.

Active step leases.

Inspección del estado interno mediante la misma data layer de Swamp.

Despliegue de workers mediante SSH.

Ejecución de workers en contenedores Docker.

Ejecución desde Kubernetes Jobs.

Utilización como step dentro de CI.

Cloud-init y aprovisionamiento automatizado.

Diagnóstico de fallos de enrollment.

Tokens expirados.

Tokens revocados.

Binding del token a una máquina.

Incompatibilidad de protocolo entre versiones.

Requisito de que orchestrator y workers ejecuten la misma versión.

Estrategia de actualización de la infraestructura remota.

Gestión de workloads que necesitan capacidades de hardware específicas.

Separación entre workers para producción, CI, análisis y otras funciones.

Qué es una worker fleet.

Diferencias entre aprovisionar workers individualmente y administrar fleets.

Fleet tokens.

Simplificación del onboarding de múltiples workers.

Diseño de pools según tipo de workload.

Fleet de ejecución general.

Fleet específica para CI.

Fleets destinadas a infraestructura.

Separación de workloads por labels.

Workers dentro de una imagen Docker.

Configuración de TLS entre worker y orchestrator.

Persistencia del cache directory.

Docker Compose para levantar múltiples workers.

Configuración del grado de concurrencia.

Graceful shutdown de workers.

Ejecución paralela de varios steps.

Workers desplegados como Kubernetes Deployment.

Workers desplegados como Kubernetes Job.

Secrets de Kubernetes para enrollment.

Resource requests y limits.

Escalado horizontal del pool.

Uso de minikube o clúster equivalente para laboratorios.

Scale from zero.

Envío de trabajo cuando todavía no existe ningún worker disponible.

Queueing de steps.

Dispatch automático cuando aparece capacidad.

Drain policies.

Elastic queueing.

Estrategias de aislamiento.

Actualización coordinada del fleet.

Observación de utilización y capacidad disponible.

Diseño de una plataforma de ejecución compartida.

Problema de compartir un único datastore entre múltiples repositorios.

Concepto de Giga-Swamp.

Namespaces como mecanismo para mantener provenance.

Diferencia entre namespace y aislamiento de seguridad.

Creación de un datastore común para varios repositorios.

Asignación de namespace a un repositorio.

Migración de datos existentes al namespace.

Listado de namespaces.

Inspección de repositorios conectados.

Consulta de datos del namespace propio.

Consultas entre namespaces.

CEL aplicado a datos de otros espacios.

Acceso a metadata de catálogos externos.

Foreign catalog metadata.

Descubrimiento de models disponibles en otros namespaces.

Referencias a información generada por otros equipos.

Eliminación de un namespace.

Regreso de un repositorio a modo independiente.

Fusión de dos repositorios locales en un datastore común.

Prevención de colisiones durante migraciones.

Diseño de namespaces por equipo.

Diseño de namespaces por producto.

Diseño por entorno.

Trazabilidad cuando los datos atraviesan distintos repositorios.

Limitaciones de los namespaces como frontera organizativa.

Estrategias para grandes organizaciones con múltiples automatizaciones.

Gobierno del acceso a un datastore compartido.

Evolución desde repositorios individuales hacia una plataforma común.

Diferencia entre datos funcionales y telemetría operacional.

Run history como registro de ejecuciones.

Inspección del historial de un workflow.

Inputs y outputs asociados a cada run.

Registro de los steps intermedios.

Inmutabilidad del historial.

Run Tracker para ejecuciones activas.

Base local SQLite utilizada para seguimiento de runs en progreso.

Heartbeats para determinar liveness.

Detección de ejecuciones huérfanas.

`swamp run history`.

`swamp run doctor`.

`swamp run gc`.

`swamp audit`.

`swamp summarise`.

`swamp telemetry stats`.

`swamp source`.

Audit timeline del repositorio.

Registro de comandos ejecutados.

Audit hooks para diferentes agentes.

Diferencias entre auditoría de comandos y auditoría de lectura de vaults.

Filtrado de auditoría por ventanas temporales.

Filtrado por sesiones.

Inspección de actividad reciente del repositorio.

Detección de cambios de datos.

OpenTelemetry integrado con Swamp.

Exportación de traces.

Span hierarchy de model y workflow runs.

Propagación de contexto.

Exportación hacia un OpenTelemetry Collector.

Headers específicos para vendors.

Correlación con sistemas externos.

Uso de `swamp doctor`.

Diagnóstico de instalación.

Diagnóstico de audit hooks.

Detección de extensions no saludables.

Comprobación de datastores.

Detección de contaminación entre namespaces.

Detección de workflows mal formados.

Identificación de secrets en texto claro.

Identificación de vaults ausentes.

Desarrollo de runbooks de diagnóstico y recuperación.

Threat model de una plataforma donde agentes pueden ejecutar acciones reales.

Separación entre capacidad de razonar y autorización para actuar.

Least privilege aplicado a models.

Least privilege aplicado a workflows.

Least privilege aplicado a workers.

Control de secrets mediante vaults.

Evitación de credenciales en prompts.

Redacción de información sensible.

Audit trail de operaciones.

Audit trail de accesos a secretos.

API key scoping.

Personal API keys para usuarios.

Collective tokens para CI/CD.

Rotación y revocación.

Extension trust.

Trusted collectives explícitos.

Riesgos de auto-trust.

Lockfiles como mecanismo para preservar versiones.

Validación de dependencias.

Supply-chain auditing.

Scorecard de extensions.

Verified by Swamp como señal independiente de la puntuación.

Uso de private extensions.

Gobierno de private collectives.

Autenticación de swamp serve.

TLS para comunicaciones remotas.

Verificación de webhooks.

Aprobaciones humanas antes de cambios críticos.

Idempotencia para reducir daños durante reintentos.

Assert steps como controles de estado.

Separación de entornos.

Diseño de workers especializados con permisos distintos.

Integración documentada con Okta SAML SSO cuando el entorno empresarial lo requiere.

AWS SSO para acceso a recursos y backends AWS.

Registro de provenance para reconstruir cómo se produjo una decisión o resultado.

Políticas para extensions aprobadas.

Revisión de nuevas automatizaciones antes de publicación.

Gestión del ciclo de vida de models, workflows y credenciales.

Controles antes de utilizar agentes sobre sistemas de producción.

Swamp como capa para encapsular operaciones cloud reutilizables.

Models para consultar y administrar recursos AWS.

Automatizaciones de infraestructura basadas en estado observado.

Drift detection.

Automatización sobre Cloudflare.

Gestión de DNS.

Gestión de WAF.

Automatización de CDN y Workers.

Integración con Proxmox VE.

Gestión de máquinas virtuales y contenedores.

Observación versionada de infraestructura.

Construcción de incident dossiers.

Integración de información de alertas.

Consulta de métricas.

Recuperación de logs.

Incorporación de conversaciones operativas.

Automatización del flujo alerta → métricas → logs → hipótesis → actuación.

Preservación del juicio humano en on-call.

Automatización del daily infrastructure pulse.

Reliability y validation scoring.

FinOps con información de AWS Cost Explorer.

Desglose de gasto por servicio.

Desglose por usage type.

Seguimiento del gasto de IA.

Consolidación de consumo de Amazon Bedrock.

Consolidación con Vertex AI y Azure OpenAI mediante extensions disponibles.

Análisis de cobertura de reservas.

Automatización de secretos con HashiCorp Vault.

Integraciones con OpenBao.

Vaults basados en SOPS y age.

Automatización de redes y dispositivos.

Gestión de Cisco IOS mediante models.

Integración con MikroTik RouterOS.

Automatización de identidad y políticas.

Gestión de FreeIPA.

Workload identity federation entre plataformas.

Diseño de operaciones seguras donde la automatización codifica el conocimiento que el agente no debe improvisar.

Automatización del ciclo de desarrollo mediante Swamp.

Issue lifecycle como state machine.

Flujo desde triage hasta planificación.

Ejecución de tareas de implementación.

Uso desde pipelines CI/CD.

Collective tokens para runners automatizados.

Validaciones mediante assert steps.

Salidas JUnit para integración con herramientas de CI.

Human approval gates antes de despliegues.

Code review asistido por IA.

Independent adversarial review.

Incorporación de múltiples review lenses.

Validación de código TypeScript.

Revisión de merge requests.

Human approval gate en revisiones automatizadas.

Automatizaciones que contrastan hechos generados por agentes.

Aplicación de revisores independientes para reducir errores.

Uso de Swamp como infraestructura para sandboxing de agentes.

Ejecución de agentes dentro de entornos aislados.

Firecracker microVMs.

Contenedores como sandbox.

Captura del coste de ejecución de agentes.

Reproducible data science.

Ejecución determinista de R y Python.

Entornos versionados mediante Nix o Docker.

Provenance por cada unidad de ejecución.

Registros inmutables de sesiones.

Sellos SHA-256 para evidencia de integridad.

Automatización de Databricks.

Gestión de jobs y clusters.

Consultas SQL como models.

Automatización de plataformas self-hosted.

Storage compatible con S3.

Git forges.

Sistemas de correo.

Automatización de contenido generado mediante IA.

Pipelines CAD y generación de outputs técnicos.

Procesamiento local donde los datos permanecen en el equipo.

Migración de flujos existentes de otras plataformas hacia workflows Swamp.

Identificación de nuevos procesos que pueden convertirse en extensiones reutilizables.

Diseño de un catálogo corporativo de automatizaciones.

Clasificación por dominio, equipo y criticidad.

Ownership de models.

Ownership de workflows.

Ownership de extensions.

Ownership de vaults y credentials.

Convenciones de nombres.

Versionado de definitions mediante Git.

Code review sobre cambios de automatización.

Versionado de extensions mediante CalVer.

Lockfiles para controlar actualizaciones.

Pruebas antes de adoptar una nueva versión.

Gestión de breaking changes.

Revisión periódica de trusted collectives.

Revisión del acceso a private extensions.

Estrategia de shared datastores.

Elección de namespaces.

Estrategia de retención y garbage collection.

Separación de repositorios según responsabilidad.

Centralización selectiva mediante Giga-Swamp.

Diseño de swamp serve en alta disponibilidad según necesidades de la organización.

Dimensionamiento de worker fleets.

Escalado desde cero para cargas esporádicas.

Fleets persistentes para workloads constantes.

Política de actualización coordinada de orchestrator y workers.

Background autoupdating en estaciones controladas.

Decisión entre actualización automática y gestión centralizada de versiones.

Revisión del daemon experimental antes de utilizarlo en entornos críticos.

TLS y reverse proxy.

Modelo de autenticación corporativa.

Integración con observabilidad existente mediante OpenTelemetry.

Alertas sobre workflows fallidos.

Seguimiento de capacidad de workers.

Auditoría periódica de comandos y accesos.

Gestión de incidencias relacionadas con automatizaciones.

Uso de `swamp doctor` como control de salud.

Runbooks para errores recurrentes.

Métricas de utilización, duración, fallos y ahorro de trabajo manual.

Evaluación de cuándo convertir una automatización individual en un componente compartido.

Criterios para publicar una extension interna.

Criterios para retirar models y workflows obsoletos.

Evolución desde automatizaciones personales hacia una plataforma agéntica gobernada.

Identificación de un proceso empresarial u operativo que actualmente dependa de pasos manuales o prompts repetitivos.

Definición del objetivo y resultado verificable de la automatización.

Identificación de sistemas externos necesarios.

Selección de extensions existentes antes de desarrollar nuevas integraciones.

Diseño de los model types requeridos.

Creación de definitions YAML.

Definición de schemas para inputs y outputs.

Creación de methods con responsabilidades acotadas.

Diseño de la información que debe persistirse como data.

Definición de lifetimes.

Incorporación de tags y metadata.

Diseño de consultas CEL.

Construcción del workflow completo como DAG.

Definición de dependencias entre jobs.

Incorporación de paralelismo.

Encadenamiento de outputs entre models.

Incorporación de `forEach` cuando existan colecciones de recursos.

Configuración de guards para preservar idempotencia.

Incorporación de assert steps.

Diseño de tratamiento de fallos.

Incorporación de manual approval en acciones de alto impacto.

Configuración de un schedule o webhook como trigger.

Protección del webhook mediante firma o secret.

Creación de vaults para todas las credenciales.

Eliminación de información sensible de definitions y datos.

Migración del vault hacia AWS Secrets Manager para colaboración.

Migración del datastore hacia Amazon S3.

Configuración del repositorio para trabajo compartido.

Definición del Collective correspondiente.

Creación de una private extension cuando exista funcionalidad propia.

Preparación del manifest.

Validación y scorecard de la extension.

Configuración del modelo de extension trust.

Versionado y lock de dependencias.

Despliegue de swamp serve.

Configuración de autenticación.

Protección de comunicaciones mediante TLS.

Generación de API keys o collective tokens con scopes mínimos.

Conexión de un worker remoto.

Creación de una worker fleet mediante Docker Compose o Kubernetes.

Configuración del placement de los steps.

Validación del comportamiento cuando no existe capacidad de workers.

Configuración de observabilidad mediante OpenTelemetry.

Revisión del audit timeline.

Validación del run history y provenance.

Ejecución de `swamp doctor`.

Definición de política de actualización.

Elaboración de un runbook de incidencias.

Documentación de ownership y responsabilidades.

Evaluación de seguridad y supply chain.

Evaluación de repetibilidad y capacidad de recuperación.

Medición del valor aportado frente al proceso original.

Definición de una hoja de ruta para extender la plataforma a otros equipos y procesos.