diff --git a/aero/roles/sarex_stack/defaults/main.yml b/aero/roles/sarex_stack/defaults/main.yml
index f94d4b9..aa31285 100644
--- a/aero/roles/sarex_stack/defaults/main.yml
+++ b/aero/roles/sarex_stack/defaults/main.yml
@@ -396,16 +396,25 @@ vault_app_secrets:
   # yc-s3-service-account.json, а не как-нибудь читаемо, и путь обязан
   # совпадать с VAULT_MOUNT_PATH в apps/processing/aero.
   #
-  # Содержимое — тот же JSON, что движок получает в /vault/secrets/processing-s3,
-  # только одной строкой: агент кладёт значение ключа в файл как есть.
+  # СХЕМА ЗДЕСЬ ДРУГАЯ, чем у секрета самого движка, и это главная ловушка.
+  # Движок читает /vault/secrets/processing-s3 с ключами host/bucket/verify, а
+  # задача разбирает свой файл моделью S3AccountModel с ключами
+  #   endpoint / bucket_name / access_key_id / secret_access_key / use_ssl
+  # Совпадают только два имени из пяти. Если положить сюда формат движка,
+  # pydantic НЕ упадёт — access_key_id и secret_access_key подойдут, — а
+  # endpoint и bucket_name молча возьмут значения по умолчанию, и задача
+  # получит 403 Forbidden на HeadObject: креды верные, адрес и бакет чужие.
+  #
+  # endpoint БЕЗ схемы: протокол задаёт use_ssl. У нас MinIO внутри кластера по
+  # http, поэтому use_ssl: false.
   - path: secrets/apps/processing/yc-s3
     data:
       yc-s3-service-account.json: >-
-        {"host": "http://minio.minio.svc.cluster.local:9000",
-        "bucket": "{{ sarex_django_s3_bucket }}",
+        {"endpoint": "minio.minio.svc.cluster.local:9000",
+        "bucket_name": "{{ sarex_django_s3_bucket }}",
         "access_key_id": "{{ sarex_minio_k8s_user }}",
         "secret_access_key": "{{ sarex_secrets.SAREX_MINIO_ROOT_PASSWORD }}",
-        "region": "us-east-1", "verify": false}
+        "use_ssl": false}
   # --- Секреты приложения measurements ---------------------------------------
   # Структура задана vault-шаблоном в apps/measurements/base/backend.yaml: он
   # собирает из этих ключей одну переменную S3_JSON_SETTINGS и читает endpoint