Merge pull request 'fix(alembic): устранить дубликат revision=0051 в test (AURORA-1850)' (#274) from fix/0051-migration-collision into test

api/alembic/versions/0052_upd_form_cells_subtree.py

@@ -1,14 +1,14 @@
 from sql_migration import run_sql_file_migration
 
 
-revision = "0051"
-down_revision = "0050"
+revision = "0052"
+down_revision = "0051"
 branch_labels = None
 depends_on = None
 
 
 def upgrade() -> None:
-    run_sql_file_migration("0051_upd_form_cells_subtree.sql")
+    run_sql_file_migration("0052_upd_form_cells_subtree.sql")
 
 
 def downgrade() -> None:

openspec/changes/aurora-1850-upd-form-cells-subtree/design.md

@@ -287,3 +287,4 @@
 | 2026-10-28 | Исполнитель Task 3 (T3.1): ранг скелета присоединяется внешним `JOIN sk` поверх `UNION` построителя, а не внутри веток; ключ скелета один bigint (узел = `-id`, строка = `lid`) | Вариант с `JOIN sk` в каждой ветке обрушил оценку строк, планировщик выбрал nested loop, GET AHR вырос со 105 до 203 мс; внешний JOIN даёт около 114 мс (+8 %) | Хрупкость плана на других объёмах; ловит замер GET на стенде |
 | 2026-10-28 | Исполнитель Task 4 (T4.4): JOIN `vsp` в скелете сателлитов оставлен, хотя `vsp_id` и `line_id` NOT NULL с FK (доказано по схеме); OTCH9F: перестановка строк с равным `(expense_item_id, month)` по tie-break `id` в снимке GET — 4 строки формы 26 (id 4/1 месяц 1, id 6/2 месяц 2), содержимое строк одинаково | Рулинг R-1; порядок при равных ключах раньше не был определён (D6) | Если фронт опирался на прежний случайный порядок равных ключей, порядок двух пар строк изменится |
 | 2026-10-29 | Контроллер (M-3): тест «0 вложенных `v_form_view`» жёстко требует `rolsuper` (assert вместо skip) | Рулинг R-2 | На не-суперпользовательской роли тест падает; нужен суперпользователь или проверка `has_parameter_privilege` |
+| 2026-11-01 | Слияние в `test`: миграция переименована 0051→0052 (`down_revision` 0050→0051) | Коллизия revision=0050/0051 с независимо одобренными #229 (занял 0050) и #231 (переименован 0050→0051 при слиянии, тот же конфликт) — см. предсказание в proposal.md «Номер может измениться при rebase». Первая попытка исправления (PR #244) потерялась при force-push, из-за чего дубликат revision=0051 на короткое время попал в `test`; это PR отдельно устраняет его | Если номер не синхронизирован с реальным down_revision цепочки — alembic падает на дублирующейся ревизии (upgrade head становится неоднозначным) |