claudient 0.1.0

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

@@ -0,0 +1,129 @@
+> 🇫🇷 This is the French translation. [English version](../kubernetes.md).
+
+# Compétence Kubernetes
+
+## Quand activer
+- Rédiger des manifests Kubernetes (Deployments, Services, ConfigMaps, Secrets, Ingress)
+- Configurer des charts Helm ou des fichiers de valeurs pour une application
+- Déboguer un Pod en échec, CrashLoopBackOff, ou un conteneur OOMKilled
+- Mettre en place un autoscaling horizontal (HPA) ou vertical (VPA) des pods
+- Définir les requests et limits de ressources pour les conteneurs
+- Rédiger ou réviser des politiques RBAC (Roles, ClusterRoles, RoleBindings)
+- Configurer des sondes liveness, readiness et startup
+- Configurer des volumes persistants et des revendications de volumes persistants
+- Rédiger des politiques réseau pour contrôler le trafic entre pods
+- Configurer des namespaces et l'isolation multi-tenant
+
+## Quand NE PAS utiliser
+- Configurations Docker Compose qui ne migrent pas vers Kubernetes
+- Serverless (Cloud Run, Lambda, Fargate) — modèle de déploiement différent
+- Applications mono-conteneur simples qui n'ont pas besoin d'orchestration
+- Environnements de développement local où Docker seul suffit
+- Nomad, Mesos, ou autres orchestrateurs non-Kubernetes
+
+## Instructions
+
+### Structure des manifests
+Toujours définir ces champs dans chaque Deployment :
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: app-name
+  namespace: production          # Toujours explicite — ne jamais se fier au namespace par défaut
+  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   # Ne jamais utiliser :latest en production
+          resources:
+            requests:
+              cpu: "100m"
+              memory: "128Mi"
+            limits:
+              cpu: "500m"
+              memory: "512Mi"
+```
+
+### Requests et limits de ressources
+- Toujours définir `requests` et `limits` — ne jamais les omettre
+- `requests` = ressources garanties (utilisées pour la planification)
+- `limits` = maximum autorisé (OOMKilled si la mémoire est dépassée)
+- Les limites CPU sont optionnelles dans les clusters avec limitation CPU désactivée — mais les limites mémoire sont obligatoires
+- Commencer prudemment : requests à ~25% de l'attendu, limits à 2x l'attendu, puis ajuster avec les métriques réelles
+
+### Sondes de santé
+Tous les conteneurs de production doivent avoir des sondes :
+```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
+```
+- Échec de `livenessProbe` → redémarrage du conteneur
+- Échec de `readinessProbe` → retiré du load balancer du Service (pas de trafic, pas de redémarrage)
+- Ne jamais pointer les deux vers le même endpoint — la readiness doit vérifier les dépendances, pas la liveness
+
+### Gestion des secrets
+- Ne jamais mettre des secrets dans des ConfigMaps — utiliser des Secrets
+- Ne jamais committer des manifests Secret avec de vraies valeurs — utiliser sealed-secrets, external-secrets-operator, ou Vault
+- Référencer les secrets comme variables d'environnement, pas comme volumes, sauf si l'application requiert spécifiquement des secrets basés sur des fichiers :
+```yaml
+env:
+  - name: DATABASE_URL
+    valueFrom:
+      secretKeyRef:
+        name: app-secrets
+        key: database-url
+```
+
+### Conventions des namespaces
+- Namespace `default` : dev/test uniquement
+- Les workloads de production toujours dans des namespaces nommés
+- Utiliser `ResourceQuota` et `LimitRange` sur chaque namespace de production
+- RBAC : les développeurs ont edit dans les namespaces dev, view en production
+
+### Causes courantes de CrashLoopBackOff et corrections
+1. Variable d'environnement manquante → vérifier la section Events de `kubectl describe pod`
+2. Healthcheck échoué → les logs montrent la vraie erreur, la sonde la détecte seulement
+3. OOMKilled → augmenter la limit mémoire ou corriger la fuite mémoire
+4. Erreur de récupération d'image → vérifier imagePullPolicy et les credentials du registre
+5. Échec d'un init container → `kubectl logs pod-name -c init-container-name`
+
+## Exemple
+
+**Utilisateur :** Déployer une application FastAPI avec une connexion PostgreSQL, 3 réplicas, des limits de ressources et des health checks.
+
+**Structure de sortie attendue :**
+- Manifest Namespace
+- Secret pour `DATABASE_URL`
+- Deployment avec 3 réplicas, requests/limits de ressources, sondes liveness + readiness pointant vers `/healthz` et `/ready`
+- Service (ClusterIP) exposant le port 80 → port conteneur 8080
+- HorizontalPodAutoscaler ciblant 70% d'utilisation CPU, min 3 / max 10 réplicas
+
+---
+
+> **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 une infrastructure Kubernetes ou des produits IA cloud-native ? [uitbreiden.com](https://uitbreiden.com/)

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

@@ -0,0 +1,130 @@
+> 🇫🇷 This is the French translation. [English version](../terraform.md).
+
+# Compétence Terraform
+
+## Quand activer
+- Rédiger des modules Terraform pour l'infrastructure AWS, GCP, ou Azure
+- Définir des VPCs, sous-réseaux, groupes de sécurité et ressources réseau
+- Provisionner des ressources de calcul (EC2, GKE, AKS, ECS, Lambda)
+- Gérer l'infrastructure de bases de données (RDS, Cloud SQL, Aurora)
+- Configurer des rôles IAM, des politiques et des comptes de service
+- Rédiger la configuration de l'état distant (backend S3, GCS, Terraform Cloud)
+- Refactoriser du Terraform existant pour utiliser des modules
+- Rédiger des pipelines CI/CD pour `terraform plan` et `terraform apply`
+- Importer de l'infrastructure existante dans l'état Terraform
+
+## Quand NE PAS utiliser
+- Pulumi, CDK, ou Crossplane — outils IaC différents, patterns différents
+- Configuration de charts Helm (utiliser la compétence Kubernetes à la place)
+- Configuration au niveau applicatif (Kubernetes ConfigMaps, variables d'environnement d'app)
+- Opérations CLI ponctuelles qui ne seront pas répétées
+
+## Instructions
+
+### Structure des modules
+Chaque projet Terraform doit suivre cette structure :
+```
+infrastructure/
+├── modules/
+│   ├── networking/
+│   │   ├── main.tf
+│   │   ├── variables.tf
+│   │   ├── outputs.tf
+│   │   └── versions.tf
+│   └── compute/
+│       ├── main.tf
+│       ├── variables.tf
+│       └── outputs.tf
+├── environments/
+│   ├── production/
+│   │   ├── main.tf          ← appelle les modules
+│   │   ├── variables.tf
+│   │   ├── terraform.tfvars
+│   │   └── backend.tf
+│   └── staging/
+│       └── ...
+└── versions.tf              ← versions des providers à la racine
+```
+
+### Gestion de l'état — toujours distant
+```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"
+  }
+}
+```
+- Ne jamais utiliser l'état local pour quelque chose de partagé
+- Activer le chiffrement et le verrouillage de l'état (DynamoDB pour le backend S3)
+- Séparer les fichiers d'état par environnement et par module (pas un état géant unique)
+
+### Discipline des variables et des outputs
+```hcl
+# variables.tf — toujours inclure description et type
+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 — exporter tout ce qu'un module consommateur pourrait avoir besoin
+output "vpc_id" {
+  description = "The ID of the VPC"
+  value       = aws_vpc.main.id
+}
+```
+
+### Secrets — jamais dans l'état ou le code
+- Ne jamais mettre des secrets dans `terraform.tfvars` ou les coder en dur dans des fichiers `.tf`
+- Utiliser `data "aws_secretsmanager_secret_version"` ou `data "google_secret_manager_secret_version"` pour lire les secrets au moment de l'application
+- Outputs sensibles : marquer avec `sensitive = true` pour les supprimer de la sortie du plan
+- `.gitignore` doit inclure : `*.tfvars`, `*.tfstate`, `*.tfstate.backup`, `.terraform/`
+
+### Conventions de nommage des ressources
+```hcl
+# Nommage cohérent : {project}-{environment}-{resource}-{suffix}
+resource "aws_vpc" "main" {
+  cidr_block = var.vpc_cidr
+  tags = {
+    Name        = "${var.project}-${var.environment}-vpc"
+    Environment = var.environment
+    ManagedBy   = "terraform"
+  }
+}
+```
+Toujours taguer chaque ressource avec `Environment` et `ManagedBy = "terraform"`.
+
+### Planifier avant d'appliquer — toujours
+- Pipeline CI/CD : `terraform plan -out=tfplan` sur PR, `terraform apply tfplan` lors de la fusion
+- Ne jamais exécuter `terraform apply` sans plan sauvegardé en production
+- Utiliser `-target` avec parcimonie — cela crée de la dérive entre l'état réel et le plan
+
+### Pièges courants
+- `terraform destroy` sans `-target` détruit tout — toujours confirmer la portée
+- Changer un attribut de ressource qui force le remplacement (ex: CIDR VPC) supprime et recrée — vérifier attentivement le plan
+- L'épinglage des versions de provider est obligatoire : utiliser `~> 5.0` et non `>= 5.0`
+- `count` vs `for_each` : utiliser `for_each` avec des maps — `count` provoque une dérive d'index quand des éléments sont supprimés
+
+## Exemple
+
+**Utilisateur :** Créer un module Terraform pour une instance RDS PostgreSQL privée sur AWS avec Multi-AZ, stockage chiffré et un groupe de sécurité dédié.
+
+**Structure de sortie attendue :**
+- `modules/rds/main.tf` — `aws_db_instance`, `aws_db_subnet_group`, `aws_security_group`
+- `modules/rds/variables.tf` — classe d'instance, version du moteur, nom de la DB, IDs VPC/sous-réseau, CIDR d'entrée
+- `modules/rds/outputs.tf` — endpoint, port, ID du groupe de sécurité
+- Groupe de sécurité : autorise PostgreSQL (5432) uniquement depuis le groupe de sécurité de l'app, pas d'accès public
+- `storage_encrypted = true`, `multi_az = true`, `deletion_protection = true` pour la production
+- Mot de passe via référence `aws_secretsmanager_secret`, jamais codé en dur
+
+---
+
+> **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 l'infrastructure cloud ou des pipelines IaC ? [uitbreiden.com](https://uitbreiden.com/)

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

@@ -0,0 +1,177 @@
+# GitHub Actions Skill
+
+## When to activate
+- Writing CI/CD pipelines for test, lint, build, and deploy
+- Setting up matrix builds across multiple OS or language versions
+- Configuring environment protection rules and deployment gates
+- Writing reusable workflows or composite actions
+- Setting up Docker build and push to a container registry
+- Configuring OIDC authentication to cloud providers (no long-lived secrets)
+- Debugging failing workflows or understanding workflow syntax errors
+- Setting up caching for dependencies (npm, pip, Go modules)
+
+## When NOT to use
+- GitLab CI, CircleCI, Jenkins — different pipeline systems
+- Local development automation (use Makefile or scripts)
+- Cron jobs that aren't tied to a repository (use cloud scheduler)
+
+## Instructions
+
+### Workflow file structure
+```yaml
+name: CI
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+
+# Explicit permissions — never use default write-all
+permissions:
+  contents: read
+  pull-requests: write    # Only if needed (e.g., posting comments)
+
+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 — always explicit
+Never use the default `permissions: write-all`. Always declare minimum required permissions:
+```yaml
+permissions:
+  contents: read          # Read repo
+  packages: write         # Push to GitHub Container Registry
+  id-token: write         # OIDC for cloud auth
+  pull-requests: write    # Comment on PRs
+```
+
+### Secrets — OIDC over long-lived credentials
+Use OIDC (OpenID Connect) for cloud authentication — no stored secrets:
+
+```yaml
+# AWS OIDC — no AWS_ACCESS_KEY_ID needed
+- 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
+```
+
+### Dependency caching
+Always cache dependencies to cut build time:
+```yaml
+# Node.js
+- uses: actions/setup-node@v4
+  with:
+    node-version: '20'
+    cache: 'npm'          # Built-in cache — no manual cache step needed
+
+# 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
+```
+
+### Environment gates for production deployments
+```yaml
+jobs:
+  deploy-production:
+    environment: production    # References GitHub Environment with protection rules
+    needs: [test, build]
+    runs-on: ubuntu-latest
+    steps:
+      - name: Deploy
+        run: ./scripts/deploy.sh
+```
+
+Set up Environment protection rules in GitHub Settings:
+- Required reviewers for production deployments
+- Wait timer between staging and production
+- Restrict to specific branches (`main` only)
+
+### Matrix builds
+```yaml
+jobs:
+  test:
+    strategy:
+      matrix:
+        node-version: [18, 20, 22]
+        os: [ubuntu-latest, windows-latest]
+      fail-fast: false    # Don't cancel all on first failure
+    runs-on: ${{ matrix.os }}
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version: ${{ matrix.node-version }}
+```
+
+### Reusable workflows
+```yaml
+# .github/workflows/deploy.yml — reusable
+on:
+  workflow_call:
+    inputs:
+      environment:
+        required: true
+        type: string
+    secrets:
+      deploy-token:
+        required: true
+
+# Caller
+jobs:
+  deploy:
+    uses: ./.github/workflows/deploy.yml
+    with:
+      environment: production
+    secrets:
+      deploy-token: ${{ secrets.DEPLOY_TOKEN }}
+```
+
+### Common failures
+- `actions/checkout@v4` missing — always the first step
+- Secrets not accessible in forks — use `pull_request_target` carefully (security risk)
+- Cache not hit — key must match exactly; use `restore-keys` for fallback
+- OIDC fails — check trust policy on the cloud provider side allows the repo and branch
+
+## Example
+
+**User:** Write a CI/CD pipeline for a Node.js app: run tests on PRs, build and push Docker image on merge to main, deploy to production with a manual approval gate.
+
+**Expected output:**
+- `on: push/pull_request` triggers
+- `test` job: checkout, setup-node with cache, `npm ci`, `npm test`
+- `build` job (on push to main, needs test): Docker build + push to GHCR using OIDC
+- `deploy` job: `environment: production` (requires approval), calls deploy script
+- Explicit `permissions:` block — minimum required
+- No hardcoded secrets — OIDC for registry auth
+
+---
+
+> **Work with us:** Claudient is backed by [Uitbreiden](https://uitbreiden.com/) — we build AI products and B2B solutions with developer communities. Building CI/CD for AI products or cloud deployments? [uitbreiden.com](https://uitbreiden.com/)

package/skills/devops-infra/kubernetes.md

@@ -0,0 +1,127 @@
+# Kubernetes Skill
+
+## When to activate
+- Writing Kubernetes manifests (Deployments, Services, ConfigMaps, Secrets, Ingress)
+- Configuring Helm charts or values files for an application
+- Debugging a failing Pod, CrashLoopBackOff, or OOMKilled container
+- Setting up horizontal pod autoscaling (HPA) or vertical pod autoscaling (VPA)
+- Defining resource requests and limits for containers
+- Writing or reviewing RBAC policies (Roles, ClusterRoles, RoleBindings)
+- Setting up liveness, readiness, and startup probes
+- Configuring persistent volumes and persistent volume claims
+- Writing network policies to control pod-to-pod traffic
+- Setting up namespaces and multi-tenant isolation
+
+## When NOT to use
+- Docker Compose setups that aren't being migrated to Kubernetes
+- Serverless (Cloud Run, Lambda, Fargate) — different deployment model
+- Simple single-container apps that don't need orchestration
+- Local development environments where Docker alone suffices
+- Nomad, Mesos, or other non-Kubernetes orchestrators
+
+## Instructions
+
+### Manifest structure
+Always set these fields in every Deployment:
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: app-name
+  namespace: production          # Always explicit — never rely on default namespace
+  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   # Never use :latest in production
+          resources:
+            requests:
+              cpu: "100m"
+              memory: "128Mi"
+            limits:
+              cpu: "500m"
+              memory: "512Mi"
+```
+
+### Resource requests and limits
+- Always set both `requests` and `limits` — never omit
+- `requests` = guaranteed resources (used for scheduling)
+- `limits` = maximum allowed (OOMKilled if memory exceeded)
+- CPU limits are optional in clusters with CPU throttling disabled — but memory limits are mandatory
+- Start conservative: requests at ~25% of expected, limits at 2x expected, then tune with actual metrics
+
+### Health probes
+All production containers must have probes:
+```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
+```
+- `livenessProbe` failure → container restart
+- `readinessProbe` failure → removed from Service load balancer (no traffic, no restart)
+- Never point both at the same endpoint — readiness should check dependencies, liveness should not
+
+### Secrets management
+- Never put secrets in ConfigMaps — use Secrets
+- Never commit Secret manifests with real values — use sealed-secrets, external-secrets-operator, or Vault
+- Reference secrets as env vars, not volumes, unless the app specifically requires file-based secrets:
+```yaml
+env:
+  - name: DATABASE_URL
+    valueFrom:
+      secretKeyRef:
+        name: app-secrets
+        key: database-url
+```
+
+### Namespace conventions
+- `default` namespace: dev/testing only
+- Production workloads always in named namespaces
+- Use `ResourceQuota` and `LimitRange` on every production namespace
+- RBAC: developers get edit in dev namespaces, view in production
+
+### Common CrashLoopBackOff causes and fixes
+1. Missing env var → check `kubectl describe pod` Events section
+2. Failed healthcheck → logs show the real error, probe just detects it
+3. OOMKilled → increase memory limit or fix memory leak
+4. Image pull error → check imagePullPolicy and registry credentials
+5. Init container failure → `kubectl logs pod-name -c init-container-name`
+
+## Example
+
+**User:** Deploy a FastAPI app with PostgreSQL connection, 3 replicas, resource limits, and health checks.
+
+**Expected output structure:**
+- Namespace manifest
+- Secret for `DATABASE_URL`
+- Deployment with 3 replicas, resource requests/limits, liveness + readiness probes pointing to `/healthz` and `/ready`
+- Service (ClusterIP) exposing port 80 → container port 8080
+- HorizontalPodAutoscaler targeting 70% CPU utilization, min 3 / max 10 replicas
+
+---
+
+> **Work with us:** Claudient is backed by [Uitbreiden](https://uitbreiden.com/) — we build AI products and B2B solutions with developer communities. Building Kubernetes infrastructure or cloud-native AI products? [uitbreiden.com](https://uitbreiden.com/)

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

@@ -0,0 +1,133 @@
+> 🇳🇱 Dit is de Nederlandse vertaling. [Engelse versie](../docker.md).
+
+# Docker Skill
+
+## Wanneer te activeren
+- Dockerfiles schrijven of optimaliseren voor productie
+- Multi-stage builds instellen om de image-grootte te verkleinen
+- Docker Compose-bestanden schrijven voor lokale ontwikkeling
+- Container-opstartfouten of layer cache-problemen debuggen
+- Niet-root gebruikers, health checks en image-beveiliging configureren
+- .dockerignore instellen voor efficiënte builds
+- Build-scripts of CI/CD Docker build-pipelines schrijven
+
+## Wanneer NIET te gebruiken
+- Kubernetes-manifests (gebruik de Kubernetes skill)
+- Buildpacks (Heroku, Cloud Native Buildpacks) — ander build-systeem
+- Virtual machine-inrichting (ander abstractieniveau)
+- Op Nix gebaseerde reproduceerbare builds
+
+## Instructies
+
+### Productie Dockerfile-structuur
+Gebruik altijd multi-stage builds voor gecompileerde talen en Node.js:
+
+```dockerfile
+# Stage 1: Build
+FROM node:20-alpine AS builder
+WORKDIR /app
+COPY package*.json ./
+RUN npm ci --only=production
+
+# Stage 2: Runtime — minimale image
+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"]
+```
+
+### Beveiligingsregels
+- Draai nooit als root in productie — maak altijd een niet-root gebruiker aan en schakel er naar over
+- Gebruik nooit de `latest`-tag — pin op een specifieke versie of digest
+- Geef de voorkeur aan Alpine- of distroless-basisimages boven volledige Debian/Ubuntu
+- Kopieer nooit `.env`-bestanden in de image — geef secrets door als runtime-omgevingsvariabelen
+- Scan images met `docker scout` of Trivy voordat ze naar productie worden gepusht
+
+### Optimalisatie van layer-caching
+Orden Dockerfile-instructies van minst-naar-meest frequent wisselend:
+1. Basisimage (verandert zelden)
+2. Systeemafhankelijkheden (`apt-get`, `apk add`)
+3. Pakketbeheerderbestanden (`package.json`, `requirements.txt`)
+4. Pakketinstallatie (`npm ci`, `pip install`)
+5. Applicatiecode (`COPY . .`) — verandert het vaakst, moet als laatste staan
+
+### .dockerignore — altijd opnemen
+```
+node_modules/
+.git/
+.env
+.env.*
+*.md
+Dockerfile*
+docker-compose*
+.dockerignore
+coverage/
+.nyc_output/
+__pycache__/
+*.pyc
+.pytest_cache/
+```
+
+### Docker Compose voor lokale ontwikkeling
+```yaml
+services:
+  app:
+    build:
+      context: .
+      target: builder          # Gebruik build stage, niet runtime stage lokaal
+    volumes:
+      - .:/app                 # Hot reload
+      - /app/node_modules      # Overschrijf container node_modules niet
+    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   # Alleen dev — nooit productie
+      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:
+```
+
+### Veelvoorkomende build-fouten
+- `COPY` mislukt stilletjes als de bron niet bestaat — controleer of `.dockerignore` benodigde bestanden niet uitsluit
+- Layer-cache onverwacht ongeldig — controleer of een `COPY` vóór installatiestappen gewijzigde bestanden meeneemt
+- Toegang geweigerd tijdens runtime — controleer bestandseigendom bij gebruik van `COPY --from` met een niet-root gebruiker
+
+## Voorbeeld
+
+**Gebruiker:** Schrijf een productie-Dockerfile voor een Python FastAPI-app met multi-stage build, niet-root gebruiker en health check.
+
+**Verwachte output:**
+- Stage 1 (builder): `python:3.12-slim`, afhankelijkheden installeren met `pip install --no-cache-dir`
+- Stage 2 (runtime): `python:3.12-slim`, niet-root gebruiker, alleen wheels/deps van builder + app-code kopiëren
+- `HEALTHCHECK` die het `/healthz`-endpoint raakt
+- `CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8080"]`
+- `.dockerignore` die `__pycache__`, `.env`, `.git`, `*.pyc` afdekt
+
+---
+
+> **Werk met ons:** Claudient wordt ondersteund door [Uitbreiden](https://uitbreiden.com/) — we bouwen AI-producten en B2B-oplossingen met ontwikkelaarsgemeenschappen. AI-workloads containeriseren of cloud-native systemen bouwen? [uitbreiden.com](https://uitbreiden.com/)