claudient 0.1.0

package/skills/devops-infra/es/kubernetes.md

@@ -0,0 +1,129 @@
+> 🇪🇸 Esta es la traducción en español. [Versión en inglés](../kubernetes.md).
+
+# Skill de Kubernetes
+
+## Cuándo activar
+- Escribir manifiestos de Kubernetes (Deployments, Services, ConfigMaps, Secrets, Ingress)
+- Configurar charts de Helm o archivos de valores para una aplicación
+- Depurar un Pod fallido, CrashLoopBackOff o contenedor OOMKilled
+- Configurar escalado horizontal de pods (HPA) o escalado vertical (VPA)
+- Definir solicitudes y límites de recursos para contenedores
+- Escribir o revisar políticas RBAC (Roles, ClusterRoles, RoleBindings)
+- Configurar sondas de liveness, readiness y startup
+- Configurar volúmenes persistentes y reclamaciones de volúmenes persistentes
+- Escribir políticas de red para controlar el tráfico entre pods
+- Configurar namespaces y aislamiento multi-tenant
+
+## Cuándo NO usar
+- Configuraciones de Docker Compose que no se están migrando a Kubernetes
+- Serverless (Cloud Run, Lambda, Fargate) — modelo de despliegue diferente
+- Aplicaciones simples de un solo contenedor que no necesitan orquestación
+- Entornos de desarrollo local donde Docker solo es suficiente
+- Nomad, Mesos u otros orquestadores que no son Kubernetes
+
+## Instrucciones
+
+### Estructura del manifiesto
+Siempre establece estos campos en cada Deployment:
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: app-name
+  namespace: production          # Siempre explícito — nunca confiar en el namespace por defecto
+  labels:
+    app: app-name
+    version: "1.0.0"
+spec:
+  replicas: 3
+  selector:
+    matchLabels:
+      app: app-name
+  template:
+    metadata:
+      labels:
+        app: app-name
+        version: "1.0.0"
+    spec:
+      containers:
+        - name: app-name
+          image: registry/app-name:tag   # Nunca usar :latest en producción
+          resources:
+            requests:
+              cpu: "100m"
+              memory: "128Mi"
+            limits:
+              cpu: "500m"
+              memory: "512Mi"
+```
+
+### Solicitudes y límites de recursos
+- Siempre establece tanto `requests` como `limits` — nunca los omitas
+- `requests` = recursos garantizados (usados para la programación)
+- `limits` = máximo permitido (OOMKilled si se supera la memoria)
+- Los límites de CPU son opcionales en clústeres con throttling de CPU desactivado — pero los límites de memoria son obligatorios
+- Empieza de forma conservadora: requests al ~25% del esperado, limits al 2x del esperado, luego ajusta con métricas reales
+
+### Sondas de salud
+Todos los contenedores en producción deben tener sondas:
+```yaml
+livenessProbe:
+  httpGet:
+    path: /healthz
+    port: 8080
+  initialDelaySeconds: 15
+  periodSeconds: 20
+  failureThreshold: 3
+
+readinessProbe:
+  httpGet:
+    path: /ready
+    port: 8080
+  initialDelaySeconds: 5
+  periodSeconds: 10
+  failureThreshold: 3
+```
+- El fallo de `livenessProbe` → reinicio del contenedor
+- El fallo de `readinessProbe` → eliminado del balanceador de carga del Service (sin tráfico, sin reinicio)
+- Nunca apuntes ambas al mismo endpoint — la readiness debe verificar dependencias, la liveness no
+
+### Gestión de secretos
+- Nunca pongas secretos en ConfigMaps — usa Secrets
+- Nunca hagas commit de manifiestos Secret con valores reales — usa sealed-secrets, external-secrets-operator o Vault
+- Referencia los secretos como variables de entorno, no como volúmenes, a menos que la aplicación requiera específicamente secretos basados en archivos:
+```yaml
+env:
+  - name: DATABASE_URL
+    valueFrom:
+      secretKeyRef:
+        name: app-secrets
+        key: database-url
+```
+
+### Convenciones de namespaces
+- Namespace `default`: solo para dev/testing
+- Las cargas de trabajo de producción siempre en namespaces con nombre
+- Usa `ResourceQuota` y `LimitRange` en cada namespace de producción
+- RBAC: los desarrolladores obtienen edit en namespaces de dev, view en producción
+
+### Causas comunes de CrashLoopBackOff y soluciones
+1. Variable de entorno faltante → revisa la sección Events de `kubectl describe pod`
+2. Healthcheck fallido → los logs muestran el error real, la sonda solo lo detecta
+3. OOMKilled → aumenta el límite de memoria o soluciona la fuga de memoria
+4. Error al obtener la imagen → revisa imagePullPolicy y credenciales del registro
+5. Fallo del contenedor init → `kubectl logs pod-name -c init-container-name`
+
+## Ejemplo
+
+**Usuario:** Desplegar una aplicación FastAPI con conexión a PostgreSQL, 3 réplicas, límites de recursos y health checks.
+
+**Estructura de salida esperada:**
+- Manifiesto de Namespace
+- Secret para `DATABASE_URL`
+- Deployment con 3 réplicas, requests/limits de recursos, sondas liveness + readiness apuntando a `/healthz` y `/ready`
+- Service (ClusterIP) exponiendo el puerto 80 → puerto 8080 del contenedor
+- HorizontalPodAutoscaler con objetivo de 70% de utilización de CPU, mínimo 3 / máximo 10 réplicas
+
+---
+
+> **Trabaja con nosotros:** Claudient está respaldado por [Uitbreiden](https://uitbreiden.com/) — construimos productos de IA y soluciones B2B con comunidades de desarrolladores. ¿Construyendo infraestructura Kubernetes o productos de IA cloud-native? [uitbreiden.com](https://uitbreiden.com/)

package/skills/devops-infra/es/terraform.md

@@ -0,0 +1,130 @@
+> 🇪🇸 Esta es la traducción en español. [Versión en inglés](../terraform.md).
+
+# Skill de Terraform
+
+## Cuándo activar
+- Escribir módulos de Terraform para infraestructura en AWS, GCP o Azure
+- Definir VPCs, subredes, grupos de seguridad y recursos de red
+- Aprovisionar recursos de cómputo (EC2, GKE, AKS, ECS, Lambda)
+- Gestionar infraestructura de bases de datos (RDS, Cloud SQL, Aurora)
+- Configurar roles IAM, políticas y cuentas de servicio
+- Escribir configuración de estado remoto (backend S3, GCS, Terraform Cloud)
+- Refactorizar Terraform existente para usar módulos
+- Escribir pipelines de CI/CD para `terraform plan` y `terraform apply`
+- Importar infraestructura existente al estado de Terraform
+
+## Cuándo NO usar
+- Pulumi, CDK o Crossplane — herramientas IaC diferentes, patrones diferentes
+- Configuración de charts de Helm (usar el skill de Kubernetes en su lugar)
+- Configuración a nivel de aplicación (ConfigMaps de Kubernetes, variables de entorno de la app)
+- Operaciones CLI puntuales que no se van a repetir
+
+## Instrucciones
+
+### Estructura del módulo
+Cada proyecto de Terraform debe seguir esta estructura:
+```
+infrastructure/
+├── modules/
+│   ├── networking/
+│   │   ├── main.tf
+│   │   ├── variables.tf
+│   │   ├── outputs.tf
+│   │   └── versions.tf
+│   └── compute/
+│       ├── main.tf
+│       ├── variables.tf
+│       └── outputs.tf
+├── environments/
+│   ├── production/
+│   │   ├── main.tf          ← llama a los módulos
+│   │   ├── variables.tf
+│   │   ├── terraform.tfvars
+│   │   └── backend.tf
+│   └── staging/
+│       └── ...
+└── versions.tf              ← versiones del proveedor raíz
+```
+
+### Gestión de estado — siempre remoto
+```hcl
+# backend.tf
+terraform {
+  backend "s3" {
+    bucket         = "company-terraform-state"
+    key            = "production/networking/terraform.tfstate"
+    region         = "eu-west-1"
+    encrypt        = true
+    dynamodb_table = "terraform-state-lock"
+  }
+}
+```
+- Nunca uses estado local para nada compartido
+- Habilita el cifrado y el bloqueo de estado (DynamoDB para backend S3)
+- Archivos de estado separados por entorno y por módulo (no un estado gigante)
+
+### Disciplina de variables y outputs
+```hcl
+# variables.tf — siempre incluir descripción y tipo
+variable "environment" {
+  description = "Deployment environment (production, staging, development)"
+  type        = string
+  validation {
+    condition     = contains(["production", "staging", "development"], var.environment)
+    error_message = "Environment must be production, staging, or development."
+  }
+}
+
+# outputs.tf — exportar todo lo que un módulo consumidor pueda necesitar
+output "vpc_id" {
+  description = "The ID of the VPC"
+  value       = aws_vpc.main.id
+}
+```
+
+### Secretos — nunca en el estado ni en el código
+- Nunca pongas secretos en `terraform.tfvars` ni los hardcodees en archivos `.tf`
+- Usa `data "aws_secretsmanager_secret_version"` o `data "google_secret_manager_secret_version"` para leer secretos en el momento de apply
+- Outputs sensibles: márcalos con `sensitive = true` para suprimir en la salida del plan
+- `.gitignore` debe incluir: `*.tfvars`, `*.tfstate`, `*.tfstate.backup`, `.terraform/`
+
+### Convenciones de nomenclatura de recursos
+```hcl
+# Nomenclatura consistente: {proyecto}-{entorno}-{recurso}-{sufijo}
+resource "aws_vpc" "main" {
+  cidr_block = var.vpc_cidr
+  tags = {
+    Name        = "${var.project}-${var.environment}-vpc"
+    Environment = var.environment
+    ManagedBy   = "terraform"
+  }
+}
+```
+Siempre etiqueta cada recurso con `Environment` y `ManagedBy = "terraform"`.
+
+### Planificar antes de aplicar — siempre
+- Pipeline CI/CD: `terraform plan -out=tfplan` en el PR, `terraform apply tfplan` al hacer merge
+- Nunca ejecutes `terraform apply` sin un plan guardado en producción
+- Usa `-target` con moderación — crea deriva entre el estado real y el plan
+
+### Problemas comunes
+- `terraform destroy` sin `-target` destruye todo — siempre confirma el alcance
+- Cambiar un atributo de recurso que fuerza reemplazo (p.ej., CIDR de VPC) elimina y recrea — revisa el plan con cuidado
+- El versionado del proveedor es obligatorio: usa `~> 5.0` no `>= 5.0`
+- `count` vs `for_each`: usa `for_each` con mapas — `count` causa deriva de índice cuando se eliminan elementos
+
+## Ejemplo
+
+**Usuario:** Crear un módulo de Terraform para una instancia privada de RDS PostgreSQL en AWS con Multi-AZ, almacenamiento cifrado y un grupo de seguridad dedicado.
+
+**Estructura de salida esperada:**
+- `modules/rds/main.tf` — `aws_db_instance`, `aws_db_subnet_group`, `aws_security_group`
+- `modules/rds/variables.tf` — clase de instancia, versión del motor, nombre de la BD, IDs de VPC/subred, CIDR de entrada
+- `modules/rds/outputs.tf` — endpoint, puerto, ID del grupo de seguridad
+- Grupo de seguridad: permite PostgreSQL (5432) solo desde el grupo de seguridad de la app, sin acceso público
+- `storage_encrypted = true`, `multi_az = true`, `deletion_protection = true` para producción
+- Contraseña mediante referencia a `aws_secretsmanager_secret`, nunca hardcodeada
+
+---
+
+> **Trabaja con nosotros:** Claudient está respaldado por [Uitbreiden](https://uitbreiden.com/) — construimos productos de IA y soluciones B2B con comunidades de desarrolladores. ¿Construyendo infraestructura cloud o pipelines IaC? [uitbreiden.com](https://uitbreiden.com/)

package/skills/devops-infra/fr/docker.md

@@ -0,0 +1,133 @@
+> 🇫🇷 This is the French translation. [English version](../docker.md).
+
+# Compétence Docker
+
+## Quand activer
+- Rédiger ou optimiser des Dockerfiles pour la production
+- Configurer des builds multi-étapes pour réduire la taille des images
+- Rédiger des fichiers Docker Compose pour le développement local
+- Déboguer des échecs de démarrage de conteneurs ou des problèmes de cache de couches
+- Configurer des utilisateurs non-root, des health checks et la sécurité des images
+- Configurer .dockerignore pour des builds efficaces
+- Rédiger des scripts de build ou des pipelines CI/CD de build Docker
+
+## Quand NE PAS utiliser
+- Manifests Kubernetes (utiliser la compétence Kubernetes)
+- Buildpacks (Heroku, Cloud Native Buildpacks) — système de build différent
+- Provisionnement de machines virtuelles (niveau d'abstraction différent)
+- Builds reproductibles basés sur Nix
+
+## Instructions
+
+### Structure du Dockerfile de production
+Toujours utiliser des builds multi-étapes pour les langages compilés et Node.js :
+
+```dockerfile
+# Étape 1 : Build
+FROM node:20-alpine AS builder
+WORKDIR /app
+COPY package*.json ./
+RUN npm ci --only=production
+
+# Étape 2 : Runtime — image minimale
+FROM node:20-alpine AS runtime
+RUN addgroup -S appgroup && adduser -S appuser -G appgroup
+WORKDIR /app
+COPY --from=builder /app/node_modules ./node_modules
+COPY . .
+USER appuser
+EXPOSE 8080
+HEALTHCHECK --interval=30s --timeout=5s --start-period=10s --retries=3 \
+  CMD wget -qO- http://localhost:8080/healthz || exit 1
+CMD ["node", "server.js"]
+```
+
+### Règles de sécurité
+- Ne jamais s'exécuter en tant que root en production — toujours créer et basculer vers un utilisateur non-root
+- Ne jamais utiliser le tag `latest` — épingler à une version spécifique ou un digest
+- Préférer les images de base Alpine ou distroless plutôt que Debian/Ubuntu complet
+- Ne jamais copier des fichiers `.env` dans l'image — passer les secrets comme variables d'environnement à l'exécution
+- Scanner les images avec `docker scout` ou Trivy avant de pousser en production
+
+### Optimisation du cache de couches
+Ordonner les instructions Dockerfile du moins au plus fréquemment modifié :
+1. Image de base (change rarement)
+2. Dépendances système (`apt-get`, `apk add`)
+3. Fichiers du gestionnaire de paquets (`package.json`, `requirements.txt`)
+4. Installation des paquets (`npm ci`, `pip install`)
+5. Code applicatif (`COPY . .`) — change le plus souvent, doit être en dernier
+
+### .dockerignore — toujours inclure
+```
+node_modules/
+.git/
+.env
+.env.*
+*.md
+Dockerfile*
+docker-compose*
+.dockerignore
+coverage/
+.nyc_output/
+__pycache__/
+*.pyc
+.pytest_cache/
+```
+
+### Docker Compose pour le développement local
+```yaml
+services:
+  app:
+    build:
+      context: .
+      target: builder          # Utiliser l'étape de build, pas l'étape runtime en local
+    volumes:
+      - .:/app                 # Hot reload
+      - /app/node_modules      # Ne pas écraser les node_modules du conteneur
+    ports:
+      - "8080:8080"
+    environment:
+      - NODE_ENV=development
+    depends_on:
+      db:
+        condition: service_healthy
+
+  db:
+    image: postgres:16-alpine
+    environment:
+      POSTGRES_USER: app
+      POSTGRES_PASSWORD: dev_password   # Dev uniquement — jamais en production
+      POSTGRES_DB: appdb
+    ports:
+      - "5432:5432"
+    healthcheck:
+      test: ["CMD-SHELL", "pg_isready -U app -d appdb"]
+      interval: 5s
+      timeout: 5s
+      retries: 5
+    volumes:
+      - postgres_data:/var/lib/postgresql/data
+
+volumes:
+  postgres_data:
+```
+
+### Échecs de build courants
+- `COPY` échoue silencieusement si la source n'existe pas — vérifier que `.dockerignore` n'exclut pas les fichiers nécessaires
+- Cache de couche invalidé de façon inattendue — vérifier si un `COPY` avant les étapes d'installation récupère des fichiers modifiés
+- Permission refusée à l'exécution — vérifier la propriété des fichiers lors de l'utilisation de `COPY --from` avec un utilisateur non-root
+
+## Exemple
+
+**Utilisateur :** Rédiger un Dockerfile de production pour une application Python FastAPI avec build multi-étapes, utilisateur non-root et health check.
+
+**Sortie attendue :**
+- Étape 1 (builder) : `python:3.12-slim`, installer les dépendances avec `pip install --no-cache-dir`
+- Étape 2 (runtime) : `python:3.12-slim`, utilisateur non-root, copier uniquement les wheels/deps depuis le builder + code applicatif
+- `HEALTHCHECK` ciblant l'endpoint `/healthz`
+- `CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8080"]`
+- `.dockerignore` couvrant `__pycache__`, `.env`, `.git`, `*.pyc`
+
+---
+
+> **Travaillez avec nous :** Claudient est soutenu par [Uitbreiden](https://uitbreiden.com/) — nous construisons des produits IA et des solutions B2B avec des communautés de développeurs. Vous containerisez des workloads IA ou construisez des systèmes cloud-native ? [uitbreiden.com](https://uitbreiden.com/)

package/skills/devops-infra/fr/github-actions.md

@@ -0,0 +1,179 @@
+> 🇫🇷 This is the French translation. [English version](../github-actions.md).
+
+# Compétence GitHub Actions
+
+## Quand activer
+- Rédiger des pipelines CI/CD pour les tests, le lint, le build et le déploiement
+- Configurer des builds matrix sur plusieurs OS ou versions de langage
+- Configurer des règles de protection d'environnement et des gates de déploiement
+- Rédiger des workflows réutilisables ou des actions composites
+- Configurer le build Docker et le push vers un registre de conteneurs
+- Configurer l'authentification OIDC vers les fournisseurs cloud (pas de secrets longue durée)
+- Déboguer des workflows en échec ou comprendre des erreurs de syntaxe de workflow
+- Configurer le cache des dépendances (npm, pip, modules Go)
+
+## Quand NE PAS utiliser
+- GitLab CI, CircleCI, Jenkins — systèmes de pipeline différents
+- Automatisation du développement local (utiliser Makefile ou des scripts)
+- Tâches cron non liées à un dépôt (utiliser le planificateur cloud)
+
+## Instructions
+
+### Structure du fichier workflow
+```yaml
+name: CI
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+
+# Permissions explicites — ne jamais utiliser write-all par défaut
+permissions:
+  contents: read
+  pull-requests: write    # Uniquement si nécessaire (ex: poster des commentaires)
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - name: Set up Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: '20'
+          cache: 'npm'
+      - run: npm ci
+      - run: npm test
+```
+
+### Permissions — toujours explicites
+Ne jamais utiliser `permissions: write-all` par défaut. Toujours déclarer les permissions minimales requises :
+```yaml
+permissions:
+  contents: read          # Lire le dépôt
+  packages: write         # Pousser vers GitHub Container Registry
+  id-token: write         # OIDC pour l'auth cloud
+  pull-requests: write    # Commenter les PRs
+```
+
+### Secrets — OIDC plutôt que des credentials longue durée
+Utiliser OIDC (OpenID Connect) pour l'authentification cloud — pas de secrets stockés :
+
+```yaml
+# AWS OIDC — pas besoin de AWS_ACCESS_KEY_ID
+- name: Configure AWS credentials
+  uses: aws-actions/configure-aws-credentials@v4
+  with:
+    role-to-assume: arn:aws:iam::123456789:role/github-actions-role
+    aws-region: eu-west-1
+
+# GCP OIDC
+- name: Authenticate to GCP
+  uses: google-github-actions/auth@v2
+  with:
+    workload_identity_provider: projects/123/locations/global/workloadIdentityPools/pool/providers/github
+    service_account: deploy@project.iam.gserviceaccount.com
+```
+
+### Cache des dépendances
+Toujours mettre en cache les dépendances pour réduire le temps de build :
+```yaml
+# Node.js
+- uses: actions/setup-node@v4
+  with:
+    node-version: '20'
+    cache: 'npm'          # Cache intégré — pas d'étape de cache manuelle nécessaire
+
+# Python
+- uses: actions/setup-python@v5
+  with:
+    python-version: '3.12'
+    cache: 'pip'
+
+# Go
+- uses: actions/setup-go@v5
+  with:
+    go-version: '1.22'
+    cache: true
+```
+
+### Gates d'environnement pour les déploiements en production
+```yaml
+jobs:
+  deploy-production:
+    environment: production    # Référence l'environnement GitHub avec des règles de protection
+    needs: [test, build]
+    runs-on: ubuntu-latest
+    steps:
+      - name: Deploy
+        run: ./scripts/deploy.sh
+```
+
+Configurer des règles de protection d'environnement dans les paramètres GitHub :
+- Réviseurs requis pour les déploiements en production
+- Timer d'attente entre staging et production
+- Restreindre aux branches spécifiques (uniquement `main`)
+
+### Builds matrix
+```yaml
+jobs:
+  test:
+    strategy:
+      matrix:
+        node-version: [18, 20, 22]
+        os: [ubuntu-latest, windows-latest]
+      fail-fast: false    # Ne pas annuler tout au premier échec
+    runs-on: ${{ matrix.os }}
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version: ${{ matrix.node-version }}
+```
+
+### Workflows réutilisables
+```yaml
+# .github/workflows/deploy.yml — réutilisable
+on:
+  workflow_call:
+    inputs:
+      environment:
+        required: true
+        type: string
+    secrets:
+      deploy-token:
+        required: true
+
+# Appelant
+jobs:
+  deploy:
+    uses: ./.github/workflows/deploy.yml
+    with:
+      environment: production
+    secrets:
+      deploy-token: ${{ secrets.DEPLOY_TOKEN }}
+```
+
+### Échecs courants
+- `actions/checkout@v4` manquant — toujours la première étape
+- Secrets non accessibles dans les forks — utiliser `pull_request_target` avec précaution (risque de sécurité)
+- Cache non trouvé — la clé doit correspondre exactement ; utiliser `restore-keys` comme solution de repli
+- OIDC échoue — vérifier que la politique de confiance côté fournisseur cloud autorise le dépôt et la branche
+
+## Exemple
+
+**Utilisateur :** Rédiger un pipeline CI/CD pour une application Node.js : exécuter les tests sur les PRs, build et push de l'image Docker lors de la fusion sur main, déployer en production avec une gate d'approbation manuelle.
+
+**Sortie attendue :**
+- Déclencheurs `on: push/pull_request`
+- Job `test` : checkout, setup-node avec cache, `npm ci`, `npm test`
+- Job `build` (sur push vers main, dépend de test) : Docker build + push vers GHCR avec OIDC
+- Job `deploy` : `environment: production` (nécessite une approbation), appelle le script de déploiement
+- Bloc `permissions:` explicite — minimum requis
+- Pas de secrets codés en dur — OIDC pour l'auth au registre
+
+---
+
+> **Travaillez avec nous :** Claudient est soutenu par [Uitbreiden](https://uitbreiden.com/) — nous construisons des produits IA et des solutions B2B avec des communautés de développeurs. Vous construisez de la CI/CD pour des produits IA ou des déploiements cloud ? [uitbreiden.com](https://uitbreiden.com/)