.forgejo/workflows/ci.yml

@@ -15,22 +15,23 @@ name: CI
 # FUTURE: добавить `postgis/postgis:16-3.4` service + гонять mv_layout — см.
 # .github/workflows/ci.yml как образец service-блока.
 on:
-  # ТОЛЬКО pull_request — НЕТ push-триггера на feature-ветки (CI-шторм #1709).
-  # WHY: раньше был и push: [feat/**,fix/**,...]. Каждый коммит в ветку с открытым
-  # PR триггерил ДВА прогона на ОДИН SHA: push-событие (github.ref=refs/heads/<branch>)
-  # и pull_request-событие (github.ref=refs/pull/<N>/merge). Разный github.ref →
-  # разные concurrency-группы (см. ниже) → прогоны НЕ отменяют друг друга → 2× job
-  # при и так дефицитных раннерах. В bot-пайплайне каждый коммит идёт через PR, так
-  # что pull_request гейтит его полностью; push-прогон был чистым дублем.
-  # Trade-off: push в feature-ветку БЕЗ открытого PR не получит CI до открытия PR
-  # (бот открывает PR сразу после первого push) — приемлемо.
   pull_request:
     branches: [main]
+  push:
+    branches:
+      # Mirror the bot-PR / feature-branch flow в .claude/rules/git-pr.md:
+      # PR получает gate, прямые пуши в feature-ветки — тоже.
+      - "feat/**"
+      - "fix/**"
+      - "refactor/**"
+      - "chore/**"
+      - "docs/**"
+      - "perf/**"
+      - "test/**"
+      - "ci/**"
+      - "hotfix/**"
 
 concurrency:
-  # Теперь, когда остался только pull_request, github.ref стабилен на весь PR
-  # (refs/pull/<N>/merge) → новый push в ветку PR отменяет предыдущий незавершённый
-  # прогон ЭТОГО PR (cancel-in-progress) вместо накопления параллельных.
   group: ci-${{ github.workflow }}-${{ github.ref }}
   cancel-in-progress: true