fix(progress): перенести профильную миграцию на V13 после аттестаций

docs/07-groups-courses.md

@@ -95,9 +95,11 @@
 ### progress
 Данные привязаны к `lab_id` и студенту (сдачи, оценки, комментарии, защиты, назначения вариантов,
 публикации). Схема **в основном не меняется**: доступ регулируется по цепочке
-`lab → course → (преподаватель | группа)`. Для профиля студента курса добавляется
-`grade_comments.author_account_id` (nullable) и индекс `(student_id, lab_id)`;
-остальное — рантайм-проверки.
+`lab → course → (преподаватель | группа)`. Для профиля студента курса добавляются
+`grade_comments.author_account_id` (nullable) и `lab_grades.updated_by_account_id`
+(nullable); существующий индекс `(student_id, lab_id)` (`grade_comments_grade_idx`)
+переиспользуется, дополнительно добавляется индекс `lab_grades(lab_id)`.
+Остальное — рантайм-проверки.
 
 ---
 
@@ -270,7 +272,7 @@ CREATE UNIQUE INDEX chapters_slug_course_uidx ON chapters (course_id, slug) WHER
 Признак видимости актив наследует от статьи→раздела→главы (course/audience). Требуется проверка доступа в
 маршруте выдачи активов (см. §6). Отдельных колонок достаточно опционально; минимум — корректная авторизация.
 
-**V10 — курс C: завершение привязки лаб (post-bootstrap шаг)**
+**Post-bootstrap шаг academic (условный «V10», не файл `db/migration` и вне обычной цепочки Flyway) — курс C: завершение привязки лаб**
 ```sql
 -- Выполняется после bootstrap-сервиса, когда все лабы получили course_id.
 -- Это отдельный шаг/миграция: обычный Flyway-старт применяет миграции раньше
@@ -281,12 +283,14 @@ ALTER TABLE labs ALTER COLUMN course_id SET NOT NULL;
 ### progress
 Схема **в основном не меняется**. Проверки доступа — рантайм (по `lab_id → course`).
 
-**V10 — профиль студента курса: автор комментария**
+**V13 — профиль студента курса: автор комментария**
 ```sql
-ALTER TABLE grade_comments ADD COLUMN author_account_id uuid;
-ALTER TABLE lab_grades ADD COLUMN updated_by_account_id uuid;
-CREATE INDEX lab_grades_lab_idx ON lab_grades (lab_id);
+ALTER TABLE grade_comments ADD COLUMN IF NOT EXISTS author_account_id uuid;
+ALTER TABLE lab_grades ADD COLUMN IF NOT EXISTS updated_by_account_id uuid;
+CREATE INDEX IF NOT EXISTS lab_grades_lab_idx ON lab_grades (lab_id);
 ```
+V13 идемпотентна: если старая feature-миграция V10 уже применялась в dev-БД,
+достаточно убрать её запись из истории Flyway (см. план реализации).
 Индекс `grade_comments (student_id, lab_id)` уже существует (`grade_comments_grade_idx`).
 Старые комментарии остаются без автора и отображаются как «автор не указан».
 

docs/08-groups-courses-plan.md

@@ -200,14 +200,38 @@
 
 ## 4. Ориентировочные миграции
 
-Номера уточняются при реализации, чтобы не конфликтовать с текущими максимумами
-(identity V3, academic V5, progress V9).
+Номера уточняются при реализации, чтобы не конфликтовать с максимумами master
+**до этой ветки** (identity V3, academic V5, progress V12); максимумы этой ветки
+больше.
 
 | Сервис | Миграции | Содержание |
 |---|---|---|
 | identity | V4–V9 | роли, поля групп, статусы студентов, `membership_history`, `promotion_runs/items`, `accounts.status` |
 | academic | V6–V9 + post-bootstrap V10 | курсы, преподаватели, группы курса, `labs.course_id` (nullable), материалы курса/аудитории, частичные индексы, активы; `SET NOT NULL` — отдельный шаг после bootstrap |
-| progress | V10 (+ V11 при необходимости аудита) | `grade_comments.author_account_id`, `lab_grades.updated_by_account_id`, индекс `lab_grades(lab_id)`; аудит скачиваний — этап 6 |
+| progress | V13 (+ V14 при необходимости аудита) | `grade_comments.author_account_id`, `lab_grades.updated_by_account_id`, индекс `lab_grades(lab_id)`; аудит скачиваний — этап 6 |
+
+### Переход со старой feature-миграции V10 на V13
+
+Старая `progress V10__profile_authors.sql` — временная feature-миграция, её нет
+в master.
+
+- **Production / master:** есть только V11 и V12, записи V10 нет — V13 применяется
+  обычным порядком, ничего делать не нужно.
+- **Dev/feature-БД, где `V10__profile_authors.sql` уже применена и имеет
+  `success=true`:** удалить только эту запись истории, ничего не удаляя из схемы;
+  V13 идемпотентна и сама создаст недостающие колонки и индекс. Используйте
+  `flyway repair` или точечно:
+  `DELETE FROM progress.flyway_schema_history WHERE version = '10' AND script = 'V10__profile_authors.sql' AND success;`.
+- **Staging-БД**, которые ненадолго запускали master-коммит `bfdae41` (out-of-order
+  + V10), тоже содержат запись V10 — для них действует тот же порядок.
+- **Если V10 осталась с `success=false`:** сначала убедитесь, что её частичные
+  изменения откатились на уровне объектов, затем `flyway repair` или удаление
+  неуспешной строки; V13 досоздаст недостающее.
+- Перед очисткой и деплоем проверьте состояние через
+  `deploy/preflight/progress-v10-v13.sql`.
+- Переход **forward-only**: после V13 откат на сборку без V13 не пройдёт валидацию
+  Flyway. Не оставляйте `out-of-order` включённым.
+- **Нельзя** переставлять V11/V12.
 
 ---
 

docs/10-stage0-report.md

@@ -13,10 +13,12 @@
     история членства, статусы аккаунтов;
   - academic `V6–V9`: курсы, преподаватели, группы курса, `labs.course_id`,
     материалы курса/аудитории, индексы активов;
-  - progress `V10`: автор комментария и последнего изменения оценки.
+  - progress `V13`: автор комментария и последнего изменения оценки.
 - Preflight-скрипты:
   - `deploy/preflight/groups-courses.sql` — до миграций;
-  - `deploy/preflight/groups-courses-post.sql` — после миграций/bootstrap.
+  - `deploy/preflight/groups-courses-post.sql` — после миграций/bootstrap;
+  - `deploy/preflight/progress-v10-v13.sql` — переход старой feature-миграции
+    progress V10 на V13.
 - UI: статус защиты в ведомости различает «готова» и «кончилось время».
 - Резервное копирование:
   - `deploy/backup.sh` — БД + решения + материалы, checksums, retention,