first commit

2026-05-04 09:49:45 +03:00
commit 8dda4328a7
273 changed files with 52880 additions and 0 deletions
--- a/SmartRep/0_prompts/prompt_SOTA_таблица.md
+++ b/SmartRep/0_prompts/prompt_SOTA_таблица.md
@@ -0,0 +1,67 @@
+# Промпт: SOTA-таблица по поддиректории
+
+Используется, когда в директории прочитано 5+ статей и нужно построить сравнительную таблицу методов.
+
+---
+
+## Промпт
+
+Ты анализируешь поддиректорию литобзора SmartRep. Я дам тебе N заметок по статьям (каждая в формате `prompt_анализ_статьи.md`). Построй сводную таблицу SOTA и gap-анализ.
+
+**Вход:** набор статей по теме `<подставить: pose_estimation | aqa | ssl_motion | few_shot | edge | physics | ...>`.
+
+**Выход:** Markdown-документ со следующей структурой:
+
+```markdown
+# SOTA по теме: <название>
+
+## Сводная таблица методов
+
+| Метод | Год | Венью | Tier | Backbone | Датасет | Метрика | Результат | GFLOPs/params | Код |
+|---|---|---|---|---|---|---|---|---|---|
+| ... | ... | ... | ... | ... | ... | ... | ... | ... | ... |
+
+(Сортировка: по году DESC, потом по результату на общем бенчмарке)
+
+## Таксономия подходов
+
+- **Группа 1: <название>**
+  - <метод 1> — ключевая идея
+  - <метод 2> — ключевая идея
+- **Группа 2: ...**
+
+## Текущий SOTA
+- На датасете <X>: <метод Y>, метрика <Z>
+- На edge-устройстве: <метод>, latency <X> мс на <hardware>
+
+## Общие ограничения подходов
+- <пункт 1 — что никто не решает>
+- <пункт 2>
+- <пункт 3>
+
+## Открытые вопросы (gap-candidates)
+Здесь важно выделить конкретные дыры, которые могут стать новизной SmartRep:
+1. <gap 1 — формулировка в виде «никто не сделал X при условиях Y»>
+2. <gap 2>
+3. <...>
+
+## Рекомендуемые бейзлайны для SmartRep
+Методы, с которыми обязательно сравниваться в статьях SmartRep:
+- <метод 1> — почему именно он
+- <метод 2>
+- <метод 3>
+
+## Ссылки на статьи в vault
+- [[2023_zhu_motionbert]]
+- [[2022_tong_videomae]]
+- ...
+```
+
+---
+
+## Инструкции
+1. В таблице оставляй только те статьи, для которых есть численный результат на общем бенчмарке. Остальные упомяни в таксономии.
+2. `tier` для конференций: A*/A/B по CORE ranking (CVPR/ICCV/ECCV/NeurIPS/ICML = A*).
+3. Если у статьи нет GFLOPs/params — пиши «н/д», не выдумывай.
+4. В `Открытые вопросы` минимум 3 формулировки, каждая ≤2 строк, с условиями применимости.
+5. В `Рекомендуемые бейзлайны` — максимум 5 методов, по одному из каждой ветки таксономии.
--- a/SmartRep/0_prompts/prompt_datasets.md
+++ b/SmartRep/0_prompts/prompt_datasets.md
@@ -0,0 +1,545 @@
+
+````markdown
+Ты — научный рецензент с экспертизой в области computer vision, human pose estimation, 
+action quality assessment (AQA) и создания benchmark-датасетов. Проведи глубокий 
+структурированный анализ приложенной статьи о датасете для проекта SmartRep — системы 
+анализа техники силовых упражнений из видео на edge-устройствах.
+
+## Контекст моего исследования (для оценки релевантности)
+
+Я разрабатываю SmartRep — систему автоматической оценки техники силовых упражнений 
+(жим лёжа, приседания, становая тяга, подтягивания, тяга в наклоне и т.д.) из 
+монокулярного видео с возможностью развёртывания на мобильных и edge-устройствах. 
+Цель: предоставлять пользователю feedback о конкретных ошибках техники в реальном 
+времени.
+
+### Научные направления (кандидатные проблемы)
+- 🅰 Fine-grained error detection: классификация конкретных ошибок техники 
+  (рука уходит внутрь, спина округляется, колени заваливаются) — не просто 
+  «правильно/неправильно», а локализация и типизация ошибки.
+- 🅱 Biomechanics-aware pose estimation: учёт физических ограничений суставов, 
+  межзвеньевых связей, нагрузок при анализе техники. Стандартные модели 
+  (HRNet, ViTPose) обучены на распределениях типа COCO и плохо переносятся 
+  на «скрюченные» позы в жиме и приседе.
+- 🅲 Few-shot / SSL adaptation: адаптация под специфичного пользователя 
+  (антропометрия, индивидуальный стиль движения) с минимальной разметкой.
+
+### Критерии оценки датасета для SmartRep
+1. **Содержание**: силовые упражнения (free weights, resistance training) — 
+   критично. Йога, танцы, гимнастика — менее релевантно. Bodyweight training 
+   (приседания без штанги) — промежуточно.
+2. **Ground truth**: MoCap / multi-view / IMU — предпочтительно. Ручная разметка 
+   одним аннотатором — слабая позиция.
+3. **Ракурсы**: фронт + бок + 3/4 одновременно — идеально. Один ракурс — ограничение.
+4. **Антропометрическое разнообразие**: разные роста, вес, пол, раса, уровень 
+   подготовки. Часто датасеты смещены к молодым атлетичным мужчинам — это bias.
+5. **Разметка ошибок техники**: наличие экспертной (тренерской) разметки 
+   конкретных ошибок — редкая и самая ценная характеристика.
+6. **Разрешение и FPS**: ≥720p, ≥30 FPS — стандарт для анализа движения. 
+   Низкие разрешения допустимы, если это edge-benchmark.
+7. **Лицензия**: CC-BY / CC-BY-NC / research-only / требует MoU — влияет на 
+   практическую применимость.
+8. **Доступность**: открытая ссылка vs. запрос авторам vs. только по договору.
+
+### Ключевые референсные датасеты (для сравнения)
+- Fit3D — fitness + MoCap, но ограниченный набор упражнений
+- FLAG3D — language-annotated fitness, 60 activities
+- Fitness-AQA — quality assessment для фитнеса
+- Human3.6M / 3DPW / AMASS — общий pose, не fitness
+- NTU RGB+D / FineGym — action recognition, не техника
+- MTL-AQA / AQA-7 / FineDiving — AQA, но спорт, не силовые
+
+---
+
+## Структура анализа
+
+### 1. МЕТАДАННЫЕ ДАТАСЕТА
+
+- Полное название датасета и акроним
+- Название сопровождающей статьи (dataset paper)
+- Авторы (все) и аффилиации
+- Год релиза, venue публикации, tier (Q1/Q2/A*/A/workshop/preprint)
+- DOI / arXiv ID
+- Количество цитирований (если известно)
+- Версии датасета (если обновлялся) и статус поддержки (активно развивается / 
+  заморожен / deprecated)
+
+---
+
+### 2. ПОЗИЦИОНИРОВАНИЕ ДАТАСЕТА
+
+В 3–5 предложениях:
+- Какую задачу / пробел в литературе призван закрыть датасет?
+- Какие датасеты он замещает или дополняет?
+- В чём принципиальная новизна по сравнению с предшествующими? (размер, 
+  модальности, разметка, домен)
+- Какую гипотезу о «правильном» датасете защищают авторы?
+
+---
+
+### 3. ТЕХНИЧЕСКИЕ ХАРАКТЕРИСТИКИ
+
+#### 3.1. Общая статистика
+
+| Параметр | Значение |
+|----------|----------|
+| Общее число субъектов | |
+| Распределение по полу | |
+| Распределение по возрасту | |
+| Антропометрия (рост/вес/BMI) | |
+| Уровень подготовки (novice/intermediate/expert) | |
+| Число классов упражнений / действий | |
+| Общее число видео / клипов | |
+| Общее число кадров | |
+| Общая длительность записи | |
+| Средняя длина клипа | |
+| Train / val / test split | |
+
+#### 3.2. Модальности данных
+
+Для каждой модальности укажи наличие, разрешение, частоту, формат:
+
+| Модальность | Наличие | Разрешение / частота | Формат | Количество |
+|-------------|---------|----------------------|--------|------------|
+| RGB video | | | | |
+| Depth (Kinect / другая) | | | | |
+| IR | | | | |
+| 2D pose / keypoints | | | | |
+| 3D pose (MoCap) | | | | |
+| SMPL / SMPL-X параметры | | | | |
+| IMU данные | | | | |
+| EMG / physiological | | | | |
+| Текстовые описания / labels | | | | |
+| Аудио | | | | |
+
+#### 3.3. Съёмочная установка
+
+- Сколько камер? Их расположение относительно субъекта (фронт, бок, top-down, 
+  произвольные)?
+- Синхронизированы ли камеры? Как (hardware sync, software, timestamp)?
+- Калибровка: intrinsic + extrinsic? Включены ли параметры в датасет?
+- Фон: controlled (green screen, лаборатория) / semi-controlled / in-the-wild?
+- Освещение: постоянное / переменное?
+- MoCap-система: какая (Vicon, OptiTrack, Xsens, IMU-only)? Сколько маркеров? 
+  Какова заявленная точность?
+
+#### 3.4. Визуальные материалы из статьи
+
+**КРИТИЧЕСКИ ВАЖНО:** Используй рисунки из статьи как основу для описания 
+устройства датасета.
+
+**Если рисунки ЕСТЬ:**
+Для каждого ключевого рисунка:
+- Номер и название
+- Что изображено (съёмочная установка, примеры кадров, распределения, статистика)
+- Какую характеристику датасета иллюстрирует
+- Качество визуализации
+  
+Особенно обрати внимание на рисунки:
+- Диаграмма сбора (capture setup) — расположение камер, MoCap
+- Примеры кадров по классам действий
+- Распределения (pose space coverage, длины клипов, демография)
+- Примеры аннотаций (skeleton overlay, segmentation masks, quality scores)
+
+**Если рисунков нет или они слабы:**
+- Отметь как серьёзный недостаток
+- Составь mermaid-диаграмму или ASCII-схему capture setup на основе текста
+- Предложи, какие визуализации следовало бы добавить
+
+---
+
+### 4. МЕТОДОЛОГИЯ СБОРА ДАННЫХ
+
+Это ключевой раздел для датасет-пейпера — оцени строгость методологии.
+
+#### 4.1. Рекрутинг субъектов
+- Как рекрутировали? (студенты университета / профессиональные атлеты / 
+  crowdsourcing / тренировочные залы)
+- Были ли критерии отбора / исключения?
+- Компенсация участникам?
+- Процедура информированного согласия (IRB / ethics board approval)?
+- Возможное смещение (selection bias) — какое и насколько критично?
+
+#### 4.2. Протокол записи
+- Инструктаж субъектов: свободное исполнение / фиксированные инструкции / 
+  следование экспертной демонстрации?
+- Сколько повторений на упражнение?
+- Контроль нагрузки (для силовых): была ли штанга / вес? Какой?
+- Рандомизация порядка упражнений?
+- Варьирование условий (ракурс, скорость, стиль)?
+
+#### 4.3. Качественный контроль
+- Отбраковывались ли записи с артефактами?
+- Процедура верификации MoCap (ручная коррекция, auto-cleaning)?
+- Процент забракованных / исправленных данных (если указан)?
+
+---
+
+### 5. ПРОТОКОЛ АННОТАЦИИ
+
+#### 5.1. Типы меток
+Перечисли все уровни разметки:
+- Категориальные: класс упражнения / действия
+- Временные: фазовая сегментация (эксцентрика/концентрика/пауза), 
+  подсчёт повторений, начало/конец
+- Пространственные: bounding boxes, сегментационные маски
+- Pose: 2D/3D keypoints
+- Quality / AQA: численные оценки, ранжирование, ошибки техники
+- Текстовые: описания на естественном языке, теги ошибок
+
+#### 5.2. Процедура разметки
+- Автоматическая (MoCap) / ручная / гибридная?
+- Кто аннотаторы? Их квалификация (обычные работники / студенты / сертифицированные 
+  тренеры / физиотерапевты)?
+- Сколько аннотаторов на образец? Межаннотаторское согласие 
+  (Cohen's κ, IoU, MPJPE)?
+- Инструкции аннотаторам — опубликованы ли? Насколько детальны?
+- Инструменты разметки (CVAT, VGG, проприетарные)?
+- Процедура разрешения конфликтов (majority vote / expert arbitration)?
+- Время на разметку одного образца (если указано)?
+
+#### 5.3. Валидация разметки
+- Golden set / test probe?
+- Перекрёстная проверка экспертом?
+- Статистика ошибок разметки (если проводился аудит)?
+
+---
+
+### 6. ДОСТУПНОСТЬ И ЛИЦЕНЗИРОВАНИЕ
+
+| Параметр | Значение |
+|----------|----------|
+| Лицензия (CC-BY / CC-BY-NC / custom / research-only) | |
+| Коммерческое использование разрешено? | |
+| Необходимость подписания MoU / data use agreement | |
+| Способ получения (прямая ссылка / регистрация / запрос авторам) | |
+| Размер загрузки (GB/TB) | |
+| Хостинг (институциональный сервер / Zenodo / HuggingFace / GitHub) | |
+| Задокументирован ли процесс загрузки? | |
+| Есть ли API или dataloader на PyTorch / TF? | |
+| Актуальность ссылок (проверь, если возможно) | |
+
+[МОЙ КОММЕНТАРИЙ] Оцени практическую применимость: сколько времени реально 
+потратить на получение и запуск датасета?
+
+---
+
+### 7. ДЕМОГРАФИЧЕСКИЕ И МЕТОДОЛОГИЧЕСКИЕ ПЕРЕКОСЫ (BIASES)
+
+#### 7.1. Демографические перекосы
+- Gender imbalance
+- Ethnic / geographic homogeneity
+- Возрастной диапазон
+- Антропометрический охват (BMI spread)
+- Физическая подготовленность (bias к фитнес-энтузиастам / профи)
+
+#### 7.2. Съёмочные перекосы
+- Pose coverage: покрывает ли датасет распределение целевых поз? 
+  Какие позы недопредставлены?
+- Viewpoint coverage: какие ракурсы доминируют?
+- Environmental: только лаборатория / только залы / смесь?
+- Temporal: запись в один день / несколько сессий (fatigue effects)?
+
+#### 7.3. Аннотационные перекосы
+- Class imbalance: распределение меток
+- Temporal imbalance: длина клипов по классам
+- Quality label distribution: есть ли перекос к «хорошим» / «плохим» 
+  исполнениям?
+
+[МОЙ КОММЕНТАРИЙ] Какие перекосы критичны для SmartRep (особенно 
+антропометрическое и viewpoint покрытие)?
+
+---
+
+### 8. ИСПОЛЬЗОВАНИЕ В НАУЧНОМ СООБЩЕСТВЕ
+
+#### 8.1. Модели, обученные на датасете
+- Перечисли известные SOTA-модели и их результаты
+- Существует ли официальный leaderboard? Где?
+- Воспроизведи таблицу сравнения методов в формате:
+
+| Метод | Год | Архитектура | Метрика_1 | Метрика_2 | Примечание |
+|-------|-----|-------------|-----------|-----------|------------|
+| | | | | | |
+
+#### 8.2. Метрики оценки
+- Стандартные метрики, принятые в сообществе для этого датасета
+- Адекватны ли они заявленной задаче?
+- Какие метрики отсутствуют, но следовало бы использовать? 
+  (например, per-class accuracy для оценки bias)
+
+#### 8.3. Типичные ошибки SOTA на этом датасете
+- На каких подклассах / условиях методы проваливаются?
+- Есть ли известные «hard cases» / challenge subsets?
+- Опубликованы ли failure mode analyses?
+
+---
+
+### 9. СРАВНЕНИЕ С АЛЬТЕРНАТИВНЫМИ ДАТАСЕТАМИ
+
+Построй сравнительную таблицу с 3–5 ближайшими датасетами:
+
+| Параметр | Анализируемый | Fit3D | FLAG3D | Human3.6M | <другой> |
+|----------|---------------|-------|--------|-----------|----------|
+| Fitness-specific | | ✓/✗ | | | |
+| Число субъектов | | 29 | | | |
+| Число упражнений | | 47 | | | |
+| MoCap GT | | ✓ | | | |
+| Multi-view | | ✓ | | | |
+| Технические ошибки размечены | | ✗ | | | |
+| Лицензия | | research-only | | | |
+
+---
+
+### 10. РЕЛЕВАНТНОСТЬ ДЛЯ SMARTREP
+
+Оцени по шкале 1–5 каждый аспект:
+
+| Аспект | Оценка (1–5) | Комментарий |
+|--------|:------------:|-------------|
+| Силовые упражнения представлены | | Какие именно? |
+| Multi-view покрытие | | Фронт+бок+3/4? |
+| Антропометрическое разнообразие | | BMI spread, диверсификация |
+| Экспертная разметка ошибок техники | | Ключевая редкая характеристика |
+| MoCap / IMU ground truth | | Для валидации pose моделей |
+| Достаточное разрешение (≥720p) | | |
+| Достаточная частота (≥30 FPS) | | |
+| Доступность / лицензия | | Реально ли получить? |
+| Совместимость с edge-pipeline | | Размер, формат, dataloaders |
+
+**Для какого из направлений 🅰/🅱/🅲 датасет наиболее ценен?**
+
+**Роль датасета в пайплайне SmartRep:**
+- Для предобучения? (веса на схожем домене)
+- Для fine-tuning? (адаптация к фитнесу)
+- Для evaluation? (бенчмарк для сравнения)
+- Для baseline training? (обучение референсных моделей)
+- Для pseudo-labeling? (источник pose GT для нашего сырого видео)
+
+**Конкретные риски при использовании:**
+- Domain gap с целевым применением
+- Юридические / этические ограничения
+- Технические (несовместимые форматы, отсутствие dataloader-ов)
+
+---
+
+### 11. ПОТЕНЦИАЛ ДЛЯ DATA AUGMENTATION / SYNTHESIS  [НОВОЕ]
+
+Этот раздел оценивает, насколько датасет можно **расширить** синтетическими 
+данными, а не только использовать «как есть». Для небольших датасетов с богатой 
+модальной структурой (MoCap, multi-view) это часто превращает маргинально 
+полезный ресурс в ключевой.
+
+#### 11.1. Параметрические модели тела
+- Присутствуют ли SMPL / SMPL-X / SMPL-H параметры (β shape, θ pose)?
+- Если да — какая версия, gendered/neutral, насколько точно фитированы?
+- Возможно ли ре-рендеринг через SMPL renderer + произвольный текстуринг 
+  (одежда, освещение) для domain randomization?
+- Есть ли meshes / vertices в готовом виде?
+
+#### 11.2. MoCap как источник ре-таргетинга
+- Формат MoCap: BVH / C3D / custom? Совместимость с AMASS-форматом?
+- Можно ли ре-таргетить MoCap на альтернативные скелеты (например, на 
+  антропометрически разнообразные модели) для расширения субъектного 
+  разнообразия?
+- Пригоден ли датасет для drive-ania синтетических аватаров в игровых движках 
+  (Unity / Unreal / Blender) с целью генерации синтетического видео в 
+  контролируемых условиях (освещение, фон, экипировка)?
+
+#### 11.3. Multi-view novel view synthesis
+- Сколько камер и насколько плотное покрытие углов?
+- Есть ли калибровка, достаточная для NeRF / Gaussian Splatting на уровне 
+  субъекта?
+- Реалистично ли синтезировать промежуточные ракурсы для покрытия углов, 
+  отсутствующих в реальной съёмке?
+
+#### 11.4. Композитные аугментации
+- Есть ли segmentation masks / alpha mattes для background replacement?
+- Green screen записи → свободная замена фона (спортзал vs. лаборатория)?
+- Depth / normals → relighting?
+- Домен-рандомизация: какие аспекты варьируемы (одежда, экипировка, фон, 
+  освещение)?
+
+#### 11.5. Pseudo-labeling для внешних данных
+- Можно ли натренировать на датасете 2D/3D pose-модель, которая далее будет 
+  производить pseudo-labels для сырого in-the-wild видео (например, 
+  YouTube-фитнес-видео)?
+- Достаточно ли MoCap GT, чтобы доверять такой модели как «экспертному 
+  разметчику» для последующего самообучения SSL?
+- Есть ли уже готовые pretrained веса на этом датасете для такой задачи?
+
+#### 11.6. Композиция с другими датасетами
+- Совместим ли датасет с AMASS (можно ли добавить в общий pool MoCap)?
+- Совместимы ли форматы аннотаций с Fit3D / FLAG3D для multi-dataset training?
+- Есть ли уже опубликованные работы, которые объединяют этот датасет с 
+  другими?
+
+#### 11.7. Риски и ограничения синтеза
+
+[МОЙ КОММЕНТАРИЙ] Оцени:
+- Domain gap real→synthetic: насколько синтетический рендер будет отличаться 
+  от реального видео с фактурой одежды, тенью, motion blur?
+- Риск «утечки» MoCap-смещений: если оригинальный датасет смещён к молодым 
+  атлетам, синтетические аугментации унаследуют эти смещения (ре-таргетинг 
+  на «других» аватаров не добавляет реального движенческого разнообразия).
+- Потеря информации об экипировке: штанга, гантели, пояса критичны для 
+  SmartRep, а в SMPL-синтезе они отсутствуют.
+
+**Итоговая оценка синтетического потенциала:** ВЫСОКИЙ / СРЕДНИЙ / НИЗКИЙ / 
+ОТСУТСТВУЕТ + 1–2 предложения обоснования.
+
+---
+
+### 12. GAP-АНАЛИЗ ДЛЯ НАШЕГО ДАТАСЕТА  [ИЗМЕНЕНО: бывшая секция 11]
+
+Самая важная часть. Сформулируй максимально конкретно:
+
+**Что этот датасет НЕ покрывает и что могло бы стать вкладом нашего датасета?**
+
+Оси для анализа gap:
+1. **Упражнения**: какие силовые упражнения отсутствуют? (жим, присед, 
+   становая, подтягивания, тяга в наклоне, армейский жим, разведения)
+2. **Ошибки техники**: размечены ли конкретные типы ошибок? Если нет — 
+   это наш вклад.
+3. **Антропометрия**: есть ли представленность тех типажей, с которыми 
+   модель будет работать (не только молодые спортсмены)?
+4. **Условия съёмки**: реальные залы vs. лаборатория?
+5. **Экипировка**: штанги, гантели, тренажёры присутствуют?
+6. **Разметка от тренеров-экспертов**: есть ли она, и насколько 
+   квалифицированы эксперты?
+7. **Пост-аугментационный gap**: если учесть потенциал синтеза из секции 11, 
+   какие пробелы всё равно остаются неустранимыми? (например, синтез не 
+   способен закрыть отсутствие экспертной разметки ошибок техники)
+
+[МОЙ КОММЕНТАРИЙ] Сформулируй в стиле: «… при этом не рассматривается X, 
+что открывает нишу для SmartRep-dataset: Y».
+
+---
+
+### 13. КРИТИЧЕСКАЯ ОЦЕНКА (DATASET PAPER PEER-REVIEW)  [ИЗМЕНЕНО: бывшая секция 12]
+
+#### 13.1. Transparency score  [НОВОЕ]
+
+Оцени полноту документирования датасета по 10 осям. Каждая ось: 
+0 (отсутствует) / 1 (частично) / 2 (полно и верифицируемо).
+
+Критерии опираются на фреймворк **Datasheets for Datasets** (Gebru et al., 
+CACM 2021), расширенный спецификой pose/AQA-датасетов.
+
+| # | Ось транспарентности | Оценка (0/1/2) | Обоснование |
+|---|----------------------|:--------------:|-------------|
+| 1 | Collection protocol disclosed (рекрутинг, инструктаж, порядок записи) | | |
+| 2 | Capture setup specifications (камеры, MoCap, синхронизация, точность) | | |
+| 3 | Intrinsic/extrinsic калибровка камер опубликована | | |
+| 4 | Demographics breakdown (пол/возраст/BMI/этнос) | | |
+| 5 | Annotation instructions опубликованы и детализированы | | |
+| 6 | Inter-annotator agreement отчитан (κ, IoU, MPJPE и т.п.) | | |
+| 7 | Rejection / cleaning статистика указана (% отбракованных, причины) | | |
+| 8 | IRB / ethics approval явно упомянут | | |
+| 9 | Datasheet for Datasets (Gebru et al. 2021) или эквивалент приложен | | |
+| 10 | Known limitations / failure modes честно изложены авторами | | |
+
+**Итоговый Transparency Score:** Σ / 20
+
+**Интерпретация:**
+- 17–20: fully transparent (publication-grade documentation, можно 
+  воспроизвести и критически оценить)
+- 12–16: adequately documented (большинство критических вопросов отвечены, 
+  есть несколько пробелов)
+- 7–11: partially documented (существенные пробелы, use with caveats — 
+  при публикации результатов нужна осторожность и прямая переписка с 
+  авторами)
+- 0–6: opaque (датасет фактически «чёрный ящик», результаты на нём с трудом 
+  интерпретируемы, научная ценность под вопросом)
+
+[МОЙ КОММЕНТАРИЙ] Отдельно отметь, какие именно оси провалены и как это 
+влияет на применимость к SmartRep. Например, отсутствие опубликованной 
+калибровки камер блокирует multi-view экспериментирование; отсутствие 
+inter-annotator agreement по ошибкам техники делает экспертную разметку 
+непригодной для обучения error-detection моделей.
+
+#### 13.2. Peer-review оценка по критериям
+
+| Критерий | Оценка (1–10) | Комментарий |
+|----------|:-------------:|-------------|
+| Новизна / уникальность | | |
+| Размер и покрытие | | |
+| Качество разметки | | |
+| Методологическая строгость сбора | | |
+| Документация (согласовать с Transparency Score из 13.1) | | |
+| Воспроизводимость (могу ли я использовать?) | | |
+| Этическая строгость (IRB, consent, privacy) | | |
+| Отсутствие перекосов | | |
+| Полезность для сообщества (adoption) | | |
+| Синтетическая расширяемость (согласовать с секцией 11) | | |
+
+**Общая рекомендация:** Adopt / Adopt with caveats / Reference only / Skip
+
+---
+
+### 14. EXECUTIVE SUMMARY  [ИЗМЕНЕНО: бывшая секция 13, расширена до 10 пунктов]
+
+В конце — краткое резюме из 10 пунктов:
+1. Датасет в одном предложении (что, для чего, уникальность)
+2. Самая сильная сторона (что делает его незаменимым)
+3. Самая слабая сторона (что дисквалифицирует или требует осторожности)
+4. Transparency Score (из 13.1) и его значение для практики
+5. Синтетический потенциал (из секции 11) — можно ли «дофармить» датасет 
+   аугментациями
+6. Роль в пайплайне SmartRep (pretrain / finetune / eval / baseline / 
+   pseudo-label / synthesis-source / не использовать)
+7. Главный gap, который оставляет для нашего датасета (конкретная ниша)
+8. Лицензионный статус в одной фразе (реально ли использовать?)
+9. Приоритет для SmartRep: ВЫСОКИЙ / СРЕДНИЙ / НИЗКИЙ / ОТКАЗ
+10. Связанные датасеты, которые стоит изучить следом (2–3 штуки)
+
+---
+
+## Формат вывода
+
+- Используй заголовки, таблицы, сравнительные матрицы
+- Если информация отсутствует в статье — явно пиши «НЕ УКАЗАНО В СТАТЬЕ»
+- Не додумывай характеристики — если чего-то нет, так и отмечай
+- Разделяй факты из статьи и свои оценки: маркируй субъективное как 
+  [МОЙ КОММЕНТАРИЙ]
+- При описании рисунков — сначала факт (что изображено), потом интерпретация
+- Финальную YAML-frontmatter карточку (для Obsidian vault) добавь 
+  в начале ответа в следующем формате:
+
+---
+
+```yaml
+---
+dataset_name: "<название>"
+dataset_acronym: "<акроним>"
+paper_title: "<название статьи>"
+paper_title_ru: "<перевод>"
+authors: [<фамилии>]
+year: <YYYY>
+venue: "<venue>"
+venue_tier: "<Q1/A*/workshop/preprint>"
+doi: "<DOI / arXiv id>"
+domain: [fitness_specific | pose_3d | motion_generic | aqa_benchmarks | 
+         action_recognition]
+subjects_count: <N>
+exercises_count: <N>
+modalities: [rgb, mocap, imu, depth, text, smpl, ...]
+multi_view: <true/false>
+expert_error_annotation: <true/false>
+license: "<CC-BY / research-only / custom>"
+availability: "<open / request / mou>"
+url: "<ссылка>"
+relevance_to_smartrep: <1-5>
+direction: "<A|B|C|ABC|—>"
+role_in_pipeline: [pretrain | finetune | eval | baseline | pseudo_label | 
+                   synthesis_source | skip]
+transparency_score: "<N>/20"          # НОВОЕ: итог из секции 13.1
+synthesis_potential: [smpl_rerender, mocap_retarget_amass, nerf_novel_view, 
+                      background_swap, pseudo_labeling_source, none]  # НОВОЕ
+tags: [fitness, strength_training, pose_estimation, aqa, mocap, multi_view, 
+       expert_annotation, error_detection, commercial_friendly, edge]
+priority: "<HIGH | MEDIUM | LOW | REJECT>"
+---
+```
+````
+
--- a/SmartRep/0_prompts/prompt_gap_analysis.md
+++ b/SmartRep/0_prompts/prompt_gap_analysis.md
@@ -0,0 +1,85 @@
+# Промпт: кросс-директорный gap-анализ
+
+Используется для финального синтеза, когда по каждой директории уже есть SOTA-таблица. Цель — найти пересечение gap'ов и сформулировать итоговую научную проблему SmartRep.
+
+---
+
+## Промпт
+
+Ты — ведущий CV-исследователь. Тебе дан литобзор проекта SmartRep в виде 10 SOTA-таблиц (по одной на директорию). Проведи кросс-анализ и выдай:
+
+1. **Матрицу пересечений gap'ов** — какие открытые вопросы повторяются в разных директориях (они самые важные).
+2. **Рекомендацию по выбору научной проблемы** из 🅰/🅱/🅲 (или их комбинации) на основе:
+   - плотности публикаций за 2023–2026 (чем насыщеннее — тем выше риск «нас опередят»),
+   - наличия публичных датасетов и кода для бейзлайнов,
+   - междисциплинарности (для РНФ важна),
+   - соответствия профилю команды (CV + edge inference, без строгой биомех. экспертизы).
+3. **Конкретную формулировку научной проблемы** SmartRep в виде 1 параграфа с численными критериями успеха.
+4. **Научную гипотезу проекта** — одно предложение в формате «если X, то Y при условиях Z».
+5. **Список обязательных сравнений** — минимум 5 методов SOTA, с которыми мы ОБЯЗАНЫ сравниться в публикациях.
+6. **Оценку реализуемости** — чего не хватает команде (данных / железа / экспертизы / партнёров) для каждого из 🅰/🅱/🅲.
+
+---
+
+## Формат ответа
+
+```markdown
+## 1. Матрица пересечений gap'ов
+
+| gap / директория | 2_pose | 3_motion | 4_ssl | 5_few_shot | 6_edge | 7_physics | 8_aqa | 9_valid | 10_related |
+|---|---|---|---|---|---|---|---|---|---|
+| edge latency <30ms | ✓ | ✓ | ✓ | ✗ | ✓ | ✗ | ✓ | ✗ | ✓ |
+| few-shot без разметки | ✗ | ✗ | ✓ | ✓ | ✗ | ✗ | ✓ | ✗ | ✗ |
+| ... | ... | ... | ... | ... | ... | ... | ... | ... | ... |
+
+**Топ-3 самых «продуктивных» gap'а** (повторяются в ≥4 директориях):
+1. <формулировка>
+2. <формулировка>
+3. <формулировка>
+
+## 2. Рекомендация направления
+
+🅰 / 🅱 / 🅲 / комбинация: **<выбор>**
+
+Обоснование:
+- <пункт 1>
+- <пункт 2>
+- <...>
+
+## 3. Формулировка научной проблемы
+<1 параграф, 5-8 предложений, с численными критериями>
+
+## 4. Научная гипотеза
+<1 предложение>
+
+## 5. Обязательные бейзлайны
+1. <метод 1> — почему
+2. <метод 2>
+3. <метод 3>
+4. <метод 4>
+5. <метод 5>
+
+## 6. Реализуемость по направлениям
+
+### 🅰 SSL AQA on edge
+- ✅ Есть: <ресурсы>
+- ❌ Не хватает: <что именно>
+- Риск: <формулировка>
+
+### 🅱 Few-shot adaptation
+... аналогично
+
+### 🅲 Physics-informed pose
+... аналогично
+
+## Итог
+<1 параграф: что делаем, с кем, в какие сроки>
+```
+
+---
+
+## Инструкции
+1. Не оценивай то, чего нет в литобзоре — пиши «недостаточно данных».
+2. Если у какой-то директории ещё не построен SOTA-отчёт, укажи это в начале и пометь соответствующие клетки матрицы как «?».
+3. Финальная рекомендация (п. 2) должна быть однозначной — НЕ «оба варианта хорошие».
+4. Численные критерии в п. 3 — обязательно (проценты, миллисекунды, градусы). Без чисел экспертиза РНФ не пропустит.
--- a/SmartRep/0_prompts/prompt_motion_temporal.md
+++ b/SmartRep/0_prompts/prompt_motion_temporal.md
@@ -0,0 +1,79 @@
+
+
+#prompts #claude #smartrep #motion_temporal #single_paper
+
+ПРОМПТ: Анализ статьи по временным моделям над позами (Motion Temporal)
+
+Ты — старший научный рецензент с экспертизой в области распознавания действий (action recognition), анализа человеческих движений (human motion understanding) и оптимизации нейросетей для edge-устройств. Подготовь реферативную карточку предоставленной статьи для литобзора проекта SmartRep (анализ техники силовых упражнений, подсчет повторений и сегментация фаз на edge-устройствах из видео).
+
+Особое внимание удели тому, как модель работает с временным контекстом (skeleton GCN, video transformers, temporal CNN), её вычислительной сложности и способности выделять фазы движения/считать повторения.
+
+Выдай результат строго в следующем формате (Markdown, frontmatter YAML в начале):
+
+---
+title: "<оригинальный заголовок>"
+title_ru: "<перевод на русский>"
+authors: [<фамилии через запятую>]
+year: <YYYY>
+venue: "<журнал/конференция>"
+venue_tier: "<Q1/Q2/Q3/Q4/A*/A/B/workshop/preprint>"
+doi: "<DOI или arXiv id>"
+tags: [skeleton_gcn, video_transformer, temporal_cnn, rep_counting, phase_segmentation, motion_representation, edge, distillation, aqa, biomech]
+relevance_to_smartrep: <1-5>   # 5 = прямо про подсчет/технику упражнений на edge, 1 = тангенциально (напр., чистая генерация танцев)
+params: "<кол-во параметров, если указано (напр., 100M)>"
+flops: "<вычислительная сложность, если указана (напр., 50 GFLOPs)>"
+---
+
+# <title_ru>
+
+## TL;DR (≤3 предложения)
+<О чём статья, какой механизм моделирования времени предложен, какой ключевой результат получен на бенчмарках.>
+
+## Проблема
+<Какую научную проблему решают авторы (например, захват долгосрочных зависимостей, робастность к окклюзиям, нерегулярность периодов при подсчете повторов).>
+
+## Гипотеза / вклад
+- <основной вклад 1>
+- <основной вклад 2>
+- <...>
+
+## Метод (Temporal Modeling)
+<Краткое описание архитектуры. Обязательно ответь на вопросы: 
+1. Как кодируется пространственная информация (spatial)?
+2. Как моделируется время (temporal: GCN, Attention, 1D/3D Conv, SSM)?
+3. Как объединяются признаки? (если применимо)>
+
+## Вычислительная сложность и Edge-потенциал
+<Анализ "тяжести" модели. Пригодна ли она для запуска на edge-устройствах? Используются ли методы сжатия, дистилляции (например, distillation of video transformers to light models) или оптимизации инференса?>
+
+## Датасеты и метрики
+| Датасет | Домен (Спорт/Общее) | Метрика (Top-1, MAE/OBO и др.) | Результат модели |
+|---|---|---|---|
+| ... | ... | ... | ... |
+
+## Сравнение с SOTA
+<Кого превосходят (напр., ST-GCN, RepNet, VideoMAE), на сколько, за счет чего.>
+
+## Ограничения / слабости
+<Что авторы сами признают + что видно при чтении (например, требует 64 кадра на вход, не работает в реальном времени, не проверялось на реальных фитнес-данных).>
+
+## Релевантность SmartRep
+<Как это использовать в нашем проекте? (Например: можно взять их модуль подсчета повторений, адаптировать их GCN для нашего графа позы, использовать их лосс для фазовой сегментации).>
+
+## Gap для нас
+<Что эта статья НЕ решает — наша потенциальная ниша. Ищи следующие триггеры:
+- Модель слишком тяжелая (отсутствует дистилляция в edge-модель).
+- Модель только считает повторения (RepNet-like), но не отличает "верное" выполнение от "неверного" в контексте техники.
+- Игнорируется сегментация специфичных силовых фаз (эксцентрика, концентрика, изометрия/пауза), исследуются только общие действия.>
+
+## Ссылки на связанные статьи в литобзоре
+<Если перекликается с SOTA моделями (ST-GCN, PoseConv3D, RepNet, VideoMAE) — [[wikilink]] на них.>
+
+## Код / данные
+- Repo: <ссылка или «нет»>
+- Pretrained: <ссылка или «нет»>
+- Отношение к нашим данным: <требует ли 3D-позы или работает с 2D, берет ли на вход RGB или heatmaps?>
+
+## Цитата (BibTeX)
+```bibtex
+@...{...}
--- a/SmartRep/0_prompts/prompt_pose_estimation.md
+++ b/SmartRep/0_prompts/prompt_pose_estimation.md
@@ -0,0 +1,363 @@
+
+
+
+# ПРОМПТ: Глубокий анализ статьи по Pose Estimation для проекта SmartRep
+
+````markdown
+Ты — старший научный рецензент с экспертизой в области human pose estimation, edge AI и спортивной биомеханики. Готовишь реферативную карточку статьи для литобзора проекта **SmartRep** (анализ техники силовых упражнений из монокулярного видео на edge-устройствах). Проведи глубокий структурированный анализ предоставленной статьи и выдай результат в формате, описанном ниже.
+
+## Контекст проекта SmartRep (для оценки релевантности)
+
+### Задача
+Автоматический анализ техники выполнения силовых упражнений (приседания, становая тяга, жим, тяга и т.п.) из видео, снятого на смартфон, с обратной связью пользователю в реальном времени.
+
+### Целевой пайплайн
+**Pose Estimation → Joint Angle Computation → Movement Phase Segmentation → Technique Assessment → Feedback Generation**
+
+### Жёсткие технические ограничения
+| Параметр | Значение |
+|----------|----------|
+| Платформа | Snapdragon 8 Gen 2 / Apple A16+ (CPU, без обязательного NPU) |
+| Latency | <10 мс на кадр для pose-блока |
+| FPS | ≥30 fps end-to-end |
+| Разрешение входа | 256–384 px (короткая сторона) |
+| Точность углов суставов | MAE ≤5° vs MoCap на фитнес-движениях |
+| Устойчивость к ракурсу | ±45° от фронтального |
+| Память модели | <30 MB |
+| Энергопотребление | важно (видео-сценарий тренировки 30+ мин) |
+
+### Архитектурные предпочтения
+- **2D pose** как основной канал, **3D lifting** как опциональный модуль для углов в сагиттальной/фронтальной плоскостях
+- Top-down пайплайн допустим (один человек в кадре — обычный сценарий тренировки)
+- Heatmap-based и regression-based — оба варианта рассматриваются
+- Temporal smoothing желателен (видео, не отдельные кадры)
+- SMPL-based подходы рассматриваются, но их вычислительная стоимость — обычно блокер
+
+### Критические свойства для фитнеса (отсутствуют в обычных бенчмарках)
+- **Устойчивость к самоокклюзиям**: руки перед корпусом (жим, тяга), ноги в приседе
+- **Нестандартные позы**: горизонтальное положение тела (планка, румынская тяга в нижней точке), инвертированные позы (мост)
+- **Высокая угловая точность** в нижних/верхних конечностях (≠ среднего PCK)
+- **Близкий ракурс**: значительная часть тела может быть обрезана (truncation)
+- **Снаряды в кадре**: гриф штанги, гантели, тренажёры — могут вводить в заблуждение модели, обученные на COCO
+- **Повторяющаяся циклическая активность** — потенциал для temporal priors
+
+### Ключевые датасеты, которые нас интересуют
+- **Fit3D** — фитнес-движения с MoCap (47 упражнений, 3D ground truth)
+- **MM-Fit** — мультимодальный фитнес-датасет
+- **Squat dataset, BarBend** — узкоспециализированные
+- **Human3.6M, MPI-INF-3DHP** — общие 3D бенчмарки
+- **COCO, MPII, CrowdPose** — общие 2D бенчмарки
+- **AIST++** — танцы (близкая к фитнесу динамика)
+
+### Базовые/конкурирующие модели
+- **Edge / mobile**: BlazePose, MoveNet (Lightning/Thunder), MovePose, RTMPose-Lite, Lite-HRNet, EfficientPose
+- **Heavy 2D**: HRNet, ViTPose, TokenPose, RTMPose
+- **3D monocular**: VideoPose3D, MeTRAbs, MotionBERT, PoseFormerV2, MotionAGFormer
+- **SMPL**: VIBE, PARE, CLIFF, SMPLer-X
+
+### Кандидатные направления новизны (🅰/🅱/🅲)
+- **🅰** — fitness-specific fine-tuning + edge-оптимизация (адаптация SOTA под фитнес при сохранении латентности)
+- **🅱** — temporal-aware pose estimation для циклических движений (использование periodicity priors)
+- **🅲** — биомеханически-информированная регуляризация (constraints на углы суставов из биомеханики)
+
+### Известные пробелы в литературе (gap analysis)
+- Edge-модели жертвуют accuracy ради speed; **нет** моделей, одновременно удовлетворяющих <10 мс на Snapdragon 8 Gen 2 CPU **И** MAE ≤5° по углам vs MoCap на фитнес-движениях
+- Fitness-специфичная адаптация pose estimators почти не исследована
+- Большинство работ валидируется на Human3.6M; **почти никто не использует Fit3D**
+- Окклюзия снарядами и self-occlusion в нестандартных позах — слабо изучены
+- Угловая точность редко используется как первичная метрика (доминируют MPJPE, PCK)
+
+---
+
+## Структура анализа
+
+Проведи анализ по разделам ниже. Результат выдай в виде Markdown-документа с YAML frontmatter в начале (формат финальной карточки описан в самом конце).
+
+### 1. МЕТАДАННЫЕ
+- Полное название (оригинал + перевод)
+- Все авторы и аффилиации
+- Год, venue, рейтинг venue (Q1/Q2/A*/A/B/workshop/preprint)
+- DOI / arXiv ID, ссылка на код
+- Цитирований (если известно)
+
+---
+
+### 2. КЛЮЧЕВАЯ ИДЕЯ (Core Contribution)
+В 3–5 предложениях:
+- Какую проблему решает статья?
+- Что предлагается? (метод/архитектура/датасет)
+- Принципиальная новизна vs предшественников?
+- Главная гипотеза?
+
+---
+
+### 3. АРХИТЕКТУРА И МЕТОД
+
+#### 3.1. Тип подхода
+Классифицируй по таксономии pose estimation:
+- **Размерность**: 2D / 3D / SMPL / 6DoF body
+- **Стратегия**: Top-down / Bottom-up / Single-stage / Two-stage lifting
+- **Регрессия**: Heatmap-based / Direct regression / Hybrid / Token-based
+- **Темпоральность**: Per-frame / Sliding window / Recurrent / Transformer-based temporal
+- **Backbone**: CNN (MobileNet, ResNet, HRNet) / ViT / Hybrid / SSM
+
+#### 3.2. Описание архитектуры
+- Общий pipeline и data flow (вход → backbone → head → выход)
+- Ключевые модули и их функции
+- Размерности тензоров на каждом этапе (если указано)
+- Размер модели, число параметров, FLOPs
+
+#### 3.3. Визуальные материалы из статьи
+
+**КРИТИЧЕСКИ ВАЖНО:** Используй рисунки и таблицы из статьи как основу для описания.
+
+**Если рисунки ЕСТЬ:**
+- Для каждого ключевого Figure: номер, название, что изображено, какую часть метода иллюстрирует, что можно понять из него (визуальные подсказки, отсутствующие в тексте)
+- Список всех рисунков/таблиц с краткой аннотацией
+
+**Если рисунков НЕТ или они неинформативны:**
+- Отметь как недостаток
+- Сгенерируй текстовую/ASCII/mermaid-диаграмму архитектуры на основе текста
+
+#### 3.4. Математическая формализация
+- Ключевые формулы (loss functions, heatmap formulation, decoding strategy, temporal aggregation)
+- В LaTeX-нотации
+- Комментарий по каждой формуле
+
+#### 3.5. Ключевые технические решения
+- Нестандартные приёмы (tricks)
+- Inference optimizations (quantization, pruning, distillation, NAS)
+- Augmentation strategies (особенно если фитнес-релевантны)
+
+---
+
+### 4. ЭКСПЕРИМЕНТАЛЬНАЯ ЧАСТЬ
+
+#### 4.1. Датасеты
+| Датасет | Размер (train/val/test) | Тип (2D/3D/SMPL) | Разрешение | Домен (general/sport/fitness) | Public? |
+|---|---|---|---|---|---|
+
+#### 4.2. Метрики
+Какие метрики используются? Отметь:
+- **Координатные**: PCK@0.05/0.2, MPJPE, PA-MPJPE, AUC, OKS-mAP, NME
+- **Угловые**: MAE по joint angles, RMSE — **критично для нашей задачи!**
+- **Темпоральные**: MPJVE (velocity error), MPJAE (acceleration error)
+- **Деплоймент**: FLOPs, params, latency (на каком hw?), FPS, energy, memory footprint
+- **Робастность**: occlusion accuracy, cross-dataset generalization
+
+**Критически:** есть ли валидация на фитнес/спортивных датасетах? Используются ли угловые метрики?
+
+#### 4.3. Сравнительная таблица результатов
+Воспроизведи основную таблицу:
+
+| Метод | Backbone | Params | FLOPs | Latency (hw) | PCK / MPJPE | ... |
+|-------|----------|--------|-------|--------------|-------------|-----|
+
+- Жирным — лучший результат
+- Отметь: маргинальное / умеренное / существенное улучшение
+- Укажи нечестные сравнения (разный input size, дополнительные данные, другая инициализация)
+
+#### 4.4. Ablation Study
+- Какие компоненты аблированы?
+- Что критично, что даёт минимальный вклад?
+- Воспроизведи таблицу
+
+---
+
+### 5. RESULTS & DISCUSSION
+
+#### 5.1. Основные выводы
+- Подтверждается ли гипотеза?
+- Контринтуитивные результаты?
+
+#### 5.2. Качественный анализ
+- Визуализации предсказаний
+- Failure cases — особенно при окклюзии, нестандартных позах
+- Анализ ошибок
+
+#### 5.3. Edge-готовность (специально для SmartRep)
+| Параметр | Значение в статье | Соответствие SmartRep (<10 мс, <30 МБ, ≥30 fps) |
+|---|---|---|
+| Hardware (test platform) | | |
+| Latency per frame | | |
+| FPS | | |
+| Model size | | |
+| FLOPs | | |
+| Quantization support | | |
+| Mobile/embedded benchmarks | | |
+
+---
+
+### 6. ПРЕИМУЩЕСТВА ПОДХОДА
+- Архитектурные
+- В обучении
+- Практические (простота, переносимость, устойчивость)
+- По метрикам
+
+---
+
+### 7. НЕДОСТАТКИ И ОГРАНИЧЕНИЯ
+- Архитектурные / методологические
+- Экспериментальные пробелы
+- Что авторы не обсудили
+- Проблемы при переносе в фитнес-домен
+
+---
+
+### 8. РЕЛЕВАНТНОСТЬ ДЛЯ SMARTREP
+
+Оцени по шкале 1–5 каждый аспект:
+
+| Аспект | Оценка (1–5) | Комментарий |
+|--------|:---:|---|
+| Edge-готовность (соответствие <10 мс, <30 МБ) | | |
+| Точность по угловым метрикам | | |
+| Устойчивость к самоокклюзии (руки/ноги перед корпусом) | | |
+| Работа с нестандартными позами (горизонтальные, инвертированные) | | |
+| Темпоральная стабильность (jitter в видео) | | |
+| Применимость к циклическим движениям | | |
+| Валидация на фитнес/спортивных датасетах | | |
+| Робастность к truncation (обрезке кадра) | | |
+| Возможность fine-tuning под наш домен | | |
+| Доступность кода и весов | | |
+
+**Конкретные элементы для заимствования:**
+- Что именно можно перенести в SmartRep?
+- Какие модификации потребуются?
+- Риски при адаптации?
+- Противоречит ли что-то нашим архитектурным решениям?
+
+**Привязка к направлению (🅰/🅱/🅲):** какое из наших кандидатных направлений новизны эта статья поддерживает или, наоборот, закрывает?
+
+---
+
+### 9. СВЯЗЬ С ДРУГИМИ РАБОТАМИ
+- Какие работы продолжает/расширяет?
+- Связь с ключевыми моделями: BlazePose, MoveNet, RTMPose, ViTPose, HRNet, MotionBERT, VideoPose3D, MeTRAbs
+- Связь с фитнес-специфичными работами (если таковые есть в нашем литобзоре)
+
+---
+
+### 10. КРИТИЧЕСКАЯ ОЦЕНКА (Peer-Review)
+
+| Критерий | 1–10 | Комментарий |
+|---|:---:|---|
+| Новизна | | |
+| Техническая глубина | | |
+| Экспериментальная строгость | | |
+| Ясность изложения | | |
+| Воспроизводимость | | |
+| Значимость для community | | |
+| Релевантность edge-deployment | | |
+
+**Общая оценка:** Accept / Weak Accept / Borderline / Weak Reject / Reject
+
+---
+
+### 11. КЛЮЧЕВЫЕ ВЫВОДЫ
+1. Главный вклад статьи (1 предложение)
+2. Самое сильное техническое решение
+3. Главный недостаток
+4. Самый полезный элемент для SmartRep (с привязкой к компоненту: backbone / head / loss / decoder / temporal module / training trick)
+5. Что изучить дополнительно после этой статьи
+6. Приоритет для нашего исследования: ВЫСОКИЙ / СРЕДНИЙ / НИЗКИЙ
+7. Связанные статьи, которые стоит прочитать следом
+
+---
+
+## ИТОГОВАЯ КАРТОЧКА (выдать в самом конце)
+
+После развёрнутого анализа сформируй сжатую карточку для литобзора:
+
+```markdown
+---
+title: "<оригинальный заголовок>"
+title_ru: "<перевод на русский>"
+authors: [<фамилии через запятую>]
+year: <YYYY>
+venue: "<журнал/конференция>"
+venue_tier: "<Q1/Q2/Q3/Q4/A*/A/B/workshop/preprint>"
+doi: "<DOI или arXiv id>"
+tags: [pose_estimation, edge, aqa, ssl, few_shot, physics, biomech, occlusion, validation, commercial]
+pose_dim: "<2d|3d|smpl|hybrid>"
+strategy: "<top_down|bottom_up|single_stage|lifting>"
+backbone: "<тип бэкбона>"
+params_M: <число параметров в миллионах>
+flops_G: <FLOPs в гигафлопсах>
+latency_ms: <latency в мс, если указано>
+hw_tested: "<на чём тестировали>"
+relevance_to_smartrep: <1-5>
+direction: "<A|B|C|ABC|—>"
+priority: "<HIGH|MEDIUM|LOW>"
+---
+
+# <title_ru>
+
+## TL;DR (≤3 предложения)
+<...>
+
+## Проблема
+<...>
+
+## Гипотеза / вклад
+- <...>
+
+## Метод
+<краткий пересказ, не копировать>
+
+## Датасеты
+| Датасет | Размер | Метрика | Результат |
+|---|---|---|---|
+
+## Сравнение с SOTA
+<...>
+
+## Edge-метрики
+| Параметр | Значение | hw |
+|---|---|---|
+| Latency | | |
+| FPS | | |
+| Params | | |
+| FLOPs | | |
+
+## Ограничения / слабости
+<...>
+
+## Релевантность SmartRep
+<что заимствовать, с чем сравниваться>
+
+## Gap для нас
+<что эта статья НЕ решает — формулировка «… при этом не рассматривается X»>
+
+## Ссылки на связанные статьи
+<wikilinks на заметки в vault>
+
+## Код / данные
+- Repo: <ссылка или «нет»>
+- Pretrained: <ссылка или «нет»>
+- Датасет: <ссылка или «нет»>
+
+## BibTeX
+```bibtex
+@...{...}
+```
+```
+
+---
+
+## Правила вывода
+1. **Не выдумывай.** Если информации нет в статье — пиши «НЕ УКАЗАНО В СТАТЬЕ».
+2. Чётко разделяй факты из статьи и свои оценки. Свои комментарии маркируй как **[МОЙ КОММЕНТАРИЙ]**.
+3. При описании рисунков: сначала факт (что изображено), потом интерпретация.
+4. В `tags` используй **только** перечисленные значения: `pose_estimation, edge, aqa, ssl, few_shot, physics, biomech, occlusion, validation, commercial`.
+5. `relevance_to_smartrep`: ставь честно. **5** = прямо fitness/exercise pose estimation на edge. **4** = edge pose estimation general. **3** = pose estimation вообще. **2** = смежные задачи (action recognition, AQA). **1** = только косвенно (3D-реконструкция, generative).
+6. **`Gap для нас` — самое важное поле.** Конкретное «что НЕ сделали» в формулировке «… при этом не рассматривается X» или «… не валидируется на Y» или «… не достигает <условие>».
+7. Если статья — обзор: отметь в TL;DR, пропусти разделы 3.4 и 4.3, добавь раздел «Таксономия подходов».
+8. Если статья — датасет: акцент на статистику данных, разнообразие, лицензию, baseline-результаты.
+9. Формулы — в LaTeX (`$...$` для inline, `$$...$$` для display).
+10. Все таблицы — в Markdown.
+````
+
+---
+
+**Использование:** прикрепи PDF статьи или вставь её текст вместе с этим промптом. Ответ Claude будет содержать развёрнутый анализ по 11 секциям + сжатую карточку для вставки в Obsidian-vault.
--- a/SmartRep/0_prompts/prompt_анализ_статьи.md
+++ b/SmartRep/0_prompts/prompt_анализ_статьи.md
@@ -0,0 +1,79 @@
+# Промпт: анализ одной статьи
+
+Вставить PDF или текст статьи + этот промпт.
+
+---
+
+## Промпт
+
+Ты — научный рецензент, готовящий реферативную карточку статьи для литобзора проекта SmartRep (анализ техники силовых упражнений из видео на edge-устройствах). Проанализируй приложенную статью и выдай результат в следующем формате (Markdown, frontmatter YAML в начале):
+
+```markdown
+---
+title: "<оригинальный заголовок>"
+title_ru: "<перевод на русский>"
+authors: [<фамилии через запятую>]
+year: <YYYY>
+venue: "<журнал/конференция>"
+venue_tier: "<Q1/Q2/Q3/Q4/A*/A/B/workshop/preprint>"
+doi: "<DOI или arXiv id>"
+tags: [pose_estimation, edge, aqa, ssl, few_shot, physics, biomech, occlusion, validation, commercial]
+relevance_to_smartrep: <1-5>   # 5 = прямо про нашу задачу, 1 = тангенциально
+direction: "<A|B|C|ABC|—>"     # связь с кандидатной проблемой 🅰/🅱/🅲
+---
+
+# <title_ru>
+
+## TL;DR (≤3 предложения)
+<О чём статья, что нового, какой результат>
+
+## Проблема
+<Какую научную проблему решают авторы>
+
+## Гипотеза / вклад
+- <основной вклад 1>
+- <основной вклад 2>
+- <...>
+
+## Метод
+<Краткое описание архитектуры/алгоритма, ключевые формулы, если есть. Не копировать — пересказать>
+
+## Датасеты
+| Датасет | Размер | Метрика | Результат |
+|---|---|---|---|
+| ... | ... | ... | ... |
+
+## Сравнение с SOTA
+<Что превосходят, на сколько, в каких условиях>
+
+## Ограничения / слабости
+<Что авторы сами признают + что видно при чтении>
+
+## Релевантность SmartRep
+<Как это использовать в нашем проекте, что заимствовать, с чем сравниваться>
+
+## Gap для нас
+<Что эта статья НЕ решает — потенциальная ниша для нашей новизны>
+
+## Ссылки на связанные статьи в литобзоре
+<Если перекликается с уже прочитанными — [[wikilink]] на заметки в vault>
+
+## Код / данные
+- Repo: <ссылка или «нет»>
+- Датасет: <ссылка или «нет»>
+- Pretrained: <ссылка или «нет»>
+
+## Цитата (BibTeX)
+```bibtex
+@...{...}
+```
+```
+
+---
+
+## Инструкции
+1. Не выдумывай ничего, чего нет в статье. Если неясно — пиши «не указано».
+2. В `tags` используй только перечисленные значения.
+3. `relevance_to_smartrep` ставь честно: 5 — прямо fitness/exercise assessment; 3 — общая pose estimation; 1 — tangentially related (например, чистая 3D-реконструкция).
+4. `Gap для нас` — самое важное поле. Здесь должно быть конкретное «что НЕ сделали» с формулировкой «… при этом не рассматривается X».
+5. Если статья — обзор, отметь это в TL;DR и пропусти поля «Метод» и «Сравнение с SOTA», вместо них добавь «Таксономия подходов».
--- a/SmartRep/0_prompts/ПРОМПТ
+++ b/SmartRep/0_prompts/ПРОМПТ
@@ -0,0 +1,81 @@
+
+
+ПРОМПТ ДЛЯ АНАЛИЗА СТАТЬИ (SSL MOTION & AQA)
+
+Ты — старший научный рецензент с экспертизой в SSL (Self-Supervised Learning) для видео и анализа движений человека. Твоя задача — подготовить глубокий технический разбор статьи для проекта **SmartRep** (система оценки качества упражнений на edge-устройствах).
+
+### 1. МЕТАДАННЫЕ (YAML)
+
+YAML
+
+```
+title: "<оригинальный заголовок>"
+title_ru: "<перевод на русский>"
+authors: [<фамилии>]
+year: <YYYY>
+venue: "<conference/journal>"
+venue_tier: "<A*/A/B/Q1/Q2>"
+doi: "<link>"
+tags: [pose_estimation, edge, aqa, ssl, few_shot, occlusion, one_class_anomaly, masked_modeling, contrastive, periodicity]
+relevance_to_smartrep: <1-5> # 5 = fitness AQA, 1 = general video SSL
+direction: "🅰" # Self-supervised motion / One-class AQA
+```
+
+### 2. CORE CONTRIBUTION (TL;DR)
+
+- Опиши суть метода в 3 предложениях. Какую проблему SSL (Masked Modeling, Contrastive, Periodicity или Anomaly Detection) решает статья?
+    
+
+### 3. АРХИТЕКТУРА И МЕТОД
+
+- **Механизм обучения:** Подробно опиши SSL-задачу (предикция маскированных патчей, контрастивное выравнивание, цикл-консистентность и т.д.).
+    
+- **Backbone:** Какая архитектура используется? (ViT, CNN, Mamba/SSM). Укажи, если есть специфические блоки для обработки временной размерности.
+    
+- **Математика:** Выпиши ключевые Loss-функции в LaTeX: $L_{total} = \dots$. Прокомментируй физический или геометрический смысл слагаемых.
+    
+- **Диаграмма:** Сгенерируй Mermaid-схему потока данных (Inputs -> Encoder -> SSL-Head -> Loss).
+    
+
+### 4. ЭКСПЕРИМЕНТЫ (AQA & Motion)
+
+- **Datasets:** (Kinetics-400, NTU RGB+D, Fitness-AQA, или специфические спортивные датасеты).
+    
+- **Результаты:** Воспроизведи таблицу сравнения с SOTA.
+    
+- **Метрики:** Используются ли стандартные метрики качества (Recall, Acc) или специфические для движений (Spearman's rank correlation, AUROC для аномалий)?
+    
+
+### 5. EDGE FEASIBILITY (Критично для SmartRep)
+
+- **Вычислительная сложность:** Число параметров (M), GFLOPs, Latency (если указано железо).
+    
+- **Квантизация/Дистилляция:** Обсуждают ли авторы перенос на мобильные устройства или сжатие модели?
+    
+
+### 6. РЕЛЕВАНТНОСТЬ ДЛЯ SMARTREP (Анализ по пунктам)
+
+Оцени применимость следующих идей статьи к нашему проекту:
+
+- **One-class AQA:** Можно ли использовать этот SSL-метод для оценки "правильности" движения без разметки ошибок (только на эталонах)?
+    
+- **LUPI-потенциал:** Можно ли адаптировать этот метод под схему Teacher (богатое видео) -> Student (скелет или компактное видео)?
+    
+- **Periodicity-awareness:** Поможет ли метод в подсчете повторов и анализе их ритма?
+    
+
+### 7. GAP ДЛЯ НАС (Ниша для новизны)
+
+- Чего статья **НЕ** делает? (Например: "метод точен, но не работает в реальном времени", "не учитывает окклюзии суставов", "требует слишком длинных последовательностей для SSL-прогрева"). Сформулируй 1-2 конкретных "гэпа", которые мы можем закрыть в SmartRep.
+    
+
+### 8. ВЫВОД ДЛЯ ЛИТОБЗОРА
+
+- Рекомендуемый приоритет: (ВЫСОКИЙ / СРЕДНИЙ / НИЗКИЙ).
+    
+- Связанные статьи для прочтения (из списка: VideoMAE, TCLR, RepNet, PatchCore).
+    
+
+---
+
+**Инструкция для ИИ:** Не придумывай данные. Если параметров модели или кода нет — пиши «НЕ УКАЗАНО». Разделяй факты из статьи и свои комментарии [КОММЕНТАРИЙ РЕЦЕНЗЕНТА].
--- a/SmartRep/0_prompts/Промпт
+++ b/SmartRep/0_prompts/Промпт
@@ -0,0 +1,297 @@
+Прежде чем писать — фиксирую структурные решения для рерайта:
+
+1. **Архитектура двух версий.** Полностью раздельные промпты (без шаринга), потому что копировать целиком быстрее, чем собирать по фрагментам. Дублирование разделов 1, 2, 3, 5, 7, 8 контролируемое.
+2. **Обязательное поле `paper_type`.** Это explicit routing key в YAML — позволяет на уровне vault'а фильтровать карточки и не путать. Допустимые значения: `aqa_method`, `ssl_backbone`, `pose_method`, `biomech_model`, `hybrid`. Если `hybrid` — берём то из двух шаблонов, что ближе по доминанте, и помечаем secondary axes в комментарии.
+3. **`direction` — required без default.** Убираю предзаполнение 🅰. AI обязан явно обосновать выбор направления в первом абзаце TL;DR.
+4. **Расширение тег-словаря.** Добавляю: `cross_view`, `instance_discrimination`, `skeleton_only`, `video_modality`, `multi_modal`, `knowledge_distillation`, `transformer`, `gcn`, `mamba`, `regression_head`, `anomaly_score`, `cycle_consistency`. Остальные оставляю.
+5. **Edge feasibility — качественный fallback.** Если все 5 численных пунктов «НЕ УКАЗАНО» — обязательная качественная оценка по шкале `lightweight / medium / heavy / unknown` с короткой мотивацией (по backbone'у и числу веток).
+6. **Раздел 4 — основное расхождение.** В AQA-варианте AQA-метрики обязательны; в SSL-варианте явно разрешено «AQA-метрик нет — это нормально, фиксируем».
+7. **Раздел 6 — второе расхождение.** AQA-вариант оценивает прямой transfer; SSL-вариант оценивает место в pretraining-pipeline и chaining с downstream-головой.
+
+---
+
+# 📑 Обновлённый тег-словарь (фиксированный, расширенный)
+
+```
+# Парадигма
+ssl, supervised, semi_supervised, few_shot, zero_shot, masked_modeling, 
+contrastive, instance_discrimination, cross_view, knowledge_distillation, 
+cycle_consistency, anomaly_score
+
+# Задача
+pose_estimation, action_recognition, aqa, one_class_anomaly, 
+fine_grained_classification, rep_counting, periodicity, regression_head
+
+# Модальность входа
+skeleton_only, video_modality, multi_modal, imu, depth
+
+# Архитектура
+gcn, transformer, mamba, cnn, lstm
+
+# Условия
+edge, occlusion, in_the_wild
+```
+
+---
+
+# 📝 ВАРИАНТ A — Промпт для AQA / Anomaly / Error-detection статей
+
+````
+ПРОМПТ ДЛЯ АНАЛИЗА AQA-СТАТЬИ (paper_type: aqa_method)
+
+Ты — старший научный рецензент с экспертизой в Action Quality Assessment, 
+fine-grained error detection и anomaly detection для движений человека. 
+Твоя задача — подготовить разбор статьи для проекта SmartRep (оценка техники 
+силовых упражнений на edge-устройствах).
+
+ВАЖНО: если в процессе анализа окажется, что статья НЕ про AQA / anomaly / 
+fine-grained errors (а, например, про общий SSL pretraining или pose estimation) — 
+ОСТАНОВИСЬ и сообщи: «Эта статья не AQA-типа, рекомендую SSL-backbone-промпт». 
+Не натягивай AQA-нарратив на не-AQA содержание.
+
+### 1. МЕТАДАННЫЕ (YAML)
+
+```yaml
+title: "<оригинальный заголовок>"
+title_ru: "<перевод>"
+short_name: "<canonical акроним если есть>"
+authors: [<фамилии>]
+year: <YYYY>
+venue: "<conference/journal>"
+venue_tier: "<A*/A/B/Q1/Q2>"
+doi: "<link>"
+code: "<github если есть>"
+paper_type: "aqa_method"   # обязательно
+tags: [<из фиксированного словаря, минимум 3>]
+relevance_to_smartrep: <1-5>
+direction: "<🅰 / 🅱 / 🅲>"   # обязательно, без default. Обоснуй в TL;DR.
+status: "reviewed"
+````
+
+### 2. CORE CONTRIBUTION (TL;DR)
+
+3 предложения. **Первое** — какую AQA-задачу решает: scoring (regression), ranking, fine-grained error classification, anomaly detection (one-class), multi-error localization. **Второе** — основной механизм. **Третье** — обоснование выбора `direction` (🅰 / 🅱 / 🅲).
+
+### 3. АРХИТЕКТУРА И МЕТОД
+
+- **Постановка задачи:** regression / ranking / classification / anomaly
+    - per-rep / per-set / per-frame granularity.
+- **Backbone** + временная агрегация (сколько кадров, какой stride).
+- **Голова оценки** (regression head, prototype-based, distance to mean, reconstruction error и т.д.).
+- **Loss-функции в LaTeX** ($\mathcal{L} = \dots$) с физическим/геометрическим смыслом.
+- **Обработка эталона:** есть ли явный «правильный» template? Как агрегируется по нескольким эталонам?
+- **Mermaid-диаграмма:** Inputs → Encoder → AQA-Head → Score/Anomaly.
+
+### 4. AQA-ЭКСПЕРИМЕНТЫ (КРИТИЧНО)
+
+- **Datasets:** AQA-7, MTL-AQA, FineDiving, Fitness-AQA, EC3D, FLEX, JIGSAWS, собственные — указать конкретно. Чем размечен: continuous score / named errors / pairwise ranks?
+- **AQA-метрики:**
+    - Для scoring/regression: Spearman's ρ, Kendall's τ, MSE, R²
+    - Для error classification: Accuracy, F1, mAP, per-error precision/recall
+    - Для anomaly: AUROC, AUPRC, EER
+    - **Если используется только Top-1 accuracy** — это сигнал, что задача подменяется обычной классификацией; явно отметь.
+- **Inter-annotator agreement:** Cohen's κ / Krippendorff α — если есть.
+- **SOTA-таблица:** воспроизведи ключевую таблицу сравнения.
+- **Per-error breakdown:** есть ли разложение по типам ошибок? Какие ошибки метод ловит хорошо, какие плохо?
+- **Granularity:** оценка целиком за подход, за повтор, за фрейм, с временной локализацией?
+
+### 5. EDGE FEASIBILITY (для SmartRep)
+
+|Параметр|Значение|
+|---|---|
+|Параметры (M)|<число / НЕ УКАЗАНО>|
+|GFLOPs|<число / НЕ УКАЗАНО>|
+|Latency + железо|<число + device / НЕ УКАЗАНО>|
+|Квантизация / дистилляция|<обсуждается? как?>|
+|Edge / mobile deployment|<да/нет/не обсуждается>|
+
+**Качественный fallback (если ≥4 НЕ УКАЗАНО):** оцени backbone как `lightweight / medium / heavy / unknown` с мотивацией в одну строку (тип архитектуры, число веток, требуемый временной контекст).
+
+### 6. РЕЛЕВАНТНОСТЬ ДЛЯ SMARTREP (AQA-применимость)
+
+- **Прямой transfer на штангу:** какой domain gap (тип упражнений в датасете ↔ силовые)? Что сломается?
+- **Соответствие нашей таксономии ошибок:** есть ли в статье именованные ошибки, которые ложатся на наши (butt-wink, hitch, valgus knee, uneven bar path и т.д.)?
+- **Per-rep vs per-set:** наша задача — feedback по каждому повтору; поддерживает ли метод per-rep granularity или только summary?
+- **One-class совместимость:** если у статьи multi-class supervised — можно ли выкрутить в one-class (только эталоны)? Что для этого нужно изменить?
+- **LUPI-потенциал:** Teacher (богатые данные при сборе: видео + IMU + барбелл-трекер) → Student (только скелет на инференсе) — поддерживает ли фреймворк такую асимметрию?
+- **Periodicity / rep counting:** учитывает ли метод цикличность повторов?
+
+### 7. GAP ДЛЯ НАС (НИША НОВИЗНЫ — самое важное поле)
+
+Сформулируй 2–4 конкретных гэпа в формате:
+
+- **Гэп N:** [что не делает статья] → [как это становится новизной SmartRep].
+
+Пример формы: «Метод даёт скаляр-оценку всего подхода, но не локализует ошибку по времени → SmartRep делает per-rep + per-frame оценку с визуальной подсветкой проблемного интервала».
+
+### 8. ВЫВОД ДЛЯ ЛИТОБЗОРА
+
+- Приоритет: **ВЫСОКИЙ / СРЕДНИЙ / НИЗКИЙ** + одна строка обоснования.
+- Место в SmartRep-pipeline: какому направлению (🅰/🅱/🅲) и какому этапу (pretraining / fine-tuning / inference head / baseline для сравнения).
+- 3–5 связанных статей для следующего разбора (с краткой ремаркой почему).
+
+---
+
+ИНСТРУКЦИИ AI:
+
+- Не выдумывай данные. «НЕ УКАЗАНО» — допустимый ответ.
+- Разделяй факты и [КОММЕНТАРИЙ РЕЦЕНЗЕНТА].
+- Все формулы — LaTeX в `$...$` или `$$...$$`.
+- Перед финальным артефактом — короткий блок структурных решений (какие нестандартные выборы пришлось сделать).
+- После артефакта — мета-комментарий: что в шаблоне сработало, что трещит на этой конкретной статье.
+
+```
+
+---
+
+# 📝 ВАРИАНТ B — Промпт для SSL backbone / pose / representation learning статей
+
+```
+
+ПРОМПТ ДЛЯ АНАЛИЗА SSL-BACKBONE СТАТЬИ (paper_type: ssl_backbone)
+
+Ты — старший научный рецензент с экспертизой в SSL для видео и скелетов, representation learning, masked modeling, contrastive learning. Твоя задача — подготовить разбор статьи для проекта SmartRep как кандидата на этап pretraining скелетного/видео-энкодера.
+
+ВАЖНО: если статья ЯВНО про AQA / fine-grained errors / anomaly detection с готовой задачей — ОСТАНОВИСЬ и сообщи: «Эта статья AQA-типа, рекомендую AQA-промпт». Не пытайся натянуть SSL-нарратив на supervised AQA.
+
+ВАЖНО-2: AQA-метрики (Spearman, AUROC, error breakdown) в SSL-статьях обычно ОТСУТСТВУЮТ. Это нормально и не повод для упрёка статье. Фиксируй факт «AQA-evaluation не проводится» в разделе 4 и переноси обсуждение применимости к AQA в раздел 6.
+
+### 1. МЕТАДАННЫЕ (YAML)
+
+```yaml
+title: "<оригинальный заголовок>"
+title_ru: "<перевод>"
+short_name: "<canonical акроним>"
+authors: [<фамилии>]
+year: <YYYY>
+venue: "<conference/journal>"
+venue_tier: "<A*/A/B/Q1/Q2>"
+doi: "<link>"
+code: "<github>"
+paper_type: "ssl_backbone"   # обязательно
+tags: [<из фикс. словаря, минимум 3 — обязательно укажи парадигму, модальность и архитектуру>]
+relevance_to_smartrep: <1-5>
+direction: "<🅰 / 🅱 / 🅲>"   # обязательно. Большинство SSL-статей — 🅲. Если иначе, обоснуй.
+status: "reviewed"
+```
+
+### 2. CORE CONTRIBUTION (TL;DR)
+
+3 предложения. **Первое** — какую SSL-задачу решает (masked recon, contrastive, predictive coding, cycle consistency, distillation). **Второе** — основной механизм + что нового относительно прямых предшественников. **Третье** — обоснование `direction` (почему именно 🅰/🅱/🅲 в нашем проекте).
+
+### 3. АРХИТЕКТУРА И МЕТОД
+
+- **SSL-задача:** что именно предсказывается / выравнивается / маскируется. Какова конструкция позитивов и негативов (если contrastive).
+- **Backbone:** ViT / ST-GCN / Mamba / CNN + специфические блоки для временной размерности.
+- **Аугментации:** перечисли все. Особо отметь те, что ломают: периодичность (rep counting), геометрию суставов (наша задача), биомеханику (направление 🅱).
+- **Loss-функции в LaTeX** с комментарием о геометрическом/информационном смысле.
+- **Двухстадийность / warm-up / curriculum** — есть ли? Какое условие переключения?
+- **Гиперпараметры обучения:** оптимизатор, batch, memory bank size, эпохи, K в top-K (если применимо).
+- **Mermaid-диаграмма:** Raw input → View generation → Encoders → Projector → SSL-Loss.
+
+### 4. SSL-ЭКСПЕРИМЕНТЫ
+
+- **Pretraining datasets:** NTU-60/120, Kinetics-400/700, ImageNet, собственные. Какова шкала?
+- **Downstream protocols:**
+    - Linear evaluation (frozen encoder + FC)
+    - Finetune (encoder + head обучаются end-to-end)
+    - KNN evaluation
+    - Few-label / semi-supervised (1% / 10% label fraction)
+    - Transfer на out-of-distribution датасет
+- **Метрики downstream:** Top-1 / Top-5 accuracy, NMI / ARI для кластеризации, mAP для retrieval. **AQA-метрики обычно отсутствуют — это ожидаемо, отметь явно одной строкой.**
+- **SOTA-таблица:** воспроизведи основную, не все.
+- **Качественные результаты:** t-SNE / attention maps / cluster purity — если есть, прокомментируй что они показывают про геометрию пространства.
+- **Ablation:** какие компоненты критичны, какие косметические.
+
+### 5. EDGE FEASIBILITY (для SmartRep)
+
+|Параметр|Значение|
+|---|---|
+|Параметры энкодера на инференсе (M)|<число / НЕ УКАЗАНО>|
+|GFLOPs|<число / НЕ УКАЗАНО>|
+|Latency + железо|<число + device / НЕ УКАЗАНО>|
+|Квантизация / дистилляция|<обсуждается?>|
+|Edge / mobile deployment|<да/нет/не обсуждается>|
+|Memory bank / момент-копии на инференсе|<используются? обычно нет>|
+
+**Качественный fallback (если ≥4 НЕ УКАЗАНО):** оценка backbone'а `lightweight / medium / heavy / unknown` + мотивация (тип, ширина, число параллельных веток). Особо отметь, что из SSL-инфраструктуры (memory bank, EMA-encoder, projector head) **не нужно** на инференсе.
+
+### 6. РЕЛЕВАНТНОСТЬ ДЛЯ SMARTREP (как pretraining-кандидат)
+
+- **Backbone reusability:** напрямую совместим со скелетным input'ом SmartRep (33-точечный COCO/MoveNet)? Какие переходы нужны (NTU-25 ↔ COCO-33, joint mapping)?
+- **Pretraining recipe transferability:** warm-up, аугментации, размер batch, memory bank — что переносится на наш малый датасет, что нет?
+- **Domain gap к силовому тренингу:** датасеты статьи (бытовые действия / спорт / игры) ↔ штанговые упражнения. Насколько большой gap, что его смягчает (motion-stream? bone-stream?).
+- **Совместимость с downstream AQA-головами:** можно ли поверх этого энкодера навесить one-class anomaly head (PatchCore, KNN-distance, reconstruction error)? Не коллапсирует ли SSL-objective при подаче только эталонных подходов?
+- **LUPI-совместимость:** поддерживает ли фреймворк асимметричные потоки (Teacher с богатыми данными / Student с бедными), или все «views» — это симметричные преобразования одного входа?
+- **Periodicity-совместимость:** ломают ли аугментации цикличность (например, random crop с reflection padding ломает; phase-aware resampling сохраняет)?
+- **Чувствительность к мелким геометрическим отклонениям:** по построению objective статьи — он склеивает или различает сэмплы внутри одного класса? (Для нас критична внутриклассовая дискриминация: правильный присед vs присед с butt-wink.)
+
+### 7. GAP ДЛЯ НАС (НИША НОВИЗНЫ — самое важное поле)
+
+2–4 конкретных гэпа в формате:
+
+- **Гэп N:** [что не делает статья как pretraining-метод] → [конкретная модификация / расширение, которое мы можем заявить как вклад SmartRep].
+
+Типичные формы для SSL-статей:
+
+- objective не чувствителен к ошибкам техники → ввести error-aware SSL signal
+- нет edge-бенчмарков → воспроизвести + INT8-квантизация
+- views симметричны → ввести настоящий LUPI с привилегированным учителем
+- аугментации ломают периодичность → phase-aware augmentations
+
+### 8. ВЫВОД ДЛЯ ЛИТОБЗОРА
+
+- Приоритет: **ВЫСОКИЙ / СРЕДНИЙ / НИЗКИЙ** + одна строка обоснования.
+- Место в SmartRep-pipeline: какой этап (pre-pretraining / pretraining / finetune-инициализация / baseline-сравнение).
+- Прямой вклад в направления (🅰 / 🅱 / 🅲) — обычно для SSL-backbone ненулевой вклад только в 🅲, нулевой в 🅰 и 🅱. Если иначе — обоснуй.
+- 3–5 связанных статей для следующего разбора с краткой ремаркой почему.
+
+---
+
+ИНСТРУКЦИИ AI:
+
+- Не выдумывай данные. «НЕ УКАЗАНО» — допустимый и частый ответ для edge-метрик в SSL-статьях.
+- Не натягивай AQA-нарратив. Если AQA-evaluation нет — фиксируй и идём дальше.
+- Разделяй факты и [КОММЕНТАРИЙ РЕЦЕНЗЕНТА].
+- Формулы — LaTeX.
+- Перед финальным артефактом — короткий блок структурных решений.
+- После артефакта — мета-комментарий о работе шаблона на этой статье.
+
+```
+
+---
+
+## 🧭 Селектор: какой промпт когда применять
+
+| Признаки в abstract / methods | Шаблон |
+|---|---|
+| Spearman / Kendall / AUROC / per-error F1 / regression head на оценку | **A (AQA)** |
+| Named error taxonomy (named technique mistakes) | **A (AQA)** |
+| Reconstruction error / distance-to-prototype как anomaly score | **A (AQA)** |
+| Pretext task (masked recon / contrastive / cycle / pred coding) + linear/finetune evaluation на классификации | **B (SSL backbone)** |
+| Linear eval / KNN на NTU/Kinetics/ImageNet, Top-1 как главная метрика | **B (SSL backbone)** |
+| Гибрид: SSL-pretraining + AQA-fine-tuning в одной статье | По доминанте экспериментов; в разделе 1 пометить `paper_type: hybrid`, в TL;DR — какая часть для нас важнее |
+| Pose estimation (MPJPE / PA-MPJPE на H36M/3DPW) | Ни тот, ни другой — нужен **третий** шаблон (`pose_method`) |
+
+---
+
+## Мета-комментарий и предупреждения по применению
+
+**Что закрыто в этой версии:**
+- `direction` без default → AI обязан обосновать выбор и не сваливаться в дефолт.
+- Раздел 4 разделён → AQA-метрики не провоцируются на не-AQA статьях.
+- Раздел 6 разделён → разные подвопросы для прямого AQA-transfer и для chaining-роли pretraining'а.
+- Edge fallback → качественная шкала избавляет от полупустого раздела.
+- Тег-словарь расширен под subtypes contrastive learning.
+- Routing явный: `paper_type` в YAML + safety-check «остановись и переключись на другой шаблон».
+
+**Что пока НЕ закрыто и стоит запланировать:**
+- Третий шаблон **`pose_method`** (для AIFit, SMPLify-style, биомех. fitting) — у тебя AIFit уже разобран, но без отдельного промпта. Имеет смысл выделить, потому что у pose-papers свои оси оценки (MPJPE/PA-MPJPE, joint angle error, stability under occlusion, biomechanical priors).
+- Четвёртый — **`dataset`** — у тебя уже есть рабочий 14-секционный шаблон, не трогаем.
+- Совместимость нескольких карточек по одной статье. Например, AIFit — это и pose_method, и слабо AQA. Имеет смысл разрешить **two cards per paper** с явной перекрёстной ссылкой во frontmatter (`primary_card`, `secondary_card`).
+- Поле `external_eval_done` — флаг «мы воспроизвели цифры / пробовали backbone у себя / только прочитали». Это для следующего этапа когда начнётся реальный pretraining.
+
+**Подводный камень в Obsidian:** `paper_type` в frontmatter — это новое поле, и существующие 4 карточки (Fit3D, FLAG3D, Fitness-AQA, H36M) его не имеют. Их стоит мигрировать одним проходом — у датасетных карточек проставить `paper_type: dataset`. Иначе Dataview-запросы по `paper_type` будут давать пустоту на старых карточках.
+
+Если согласен с разбиением — могу сейчас же написать **третий промпт `pose_method`** для AIFit-style статей. Или сначала прогоним новый SSL-промпт на FLEX (он у тебя в highest priority) и посмотрим, не выскочат ли ещё дыры в шаблоне.
+```
--- a/SmartRep/0_prompts/Промпт
+++ b/SmartRep/0_prompts/Промпт
@@ -0,0 +1,154 @@
+## ВАРИАНТ B — Промпт для SSL backbone / pose / representation learning статей
+
+````
+ПРОМПТ ДЛЯ АНАЛИЗА SSL-BACKBONE СТАТЬИ (paper_type: ssl_backbone)
+
+Ты — старший научный рецензент с экспертизой в SSL для видео и скелетов, 
+representation learning, masked modeling, contrastive learning. Твоя задача 
+— подготовить разбор статьи для проекта SmartRep как кандидата на этап 
+pretraining скелетного/видео-энкодера.
+
+ВАЖНО: если статья ЯВНО про AQA / fine-grained errors / anomaly detection 
+с готовой задачей — ОСТАНОВИСЬ и сообщи: «Эта статья AQA-типа, рекомендую 
+AQA-промпт». Не пытайся натянуть SSL-нарратив на supervised AQA.
+
+ВАЖНО-2: AQA-метрики (Spearman, AUROC, error breakdown) в SSL-статьях 
+обычно ОТСУТСТВУЮТ. Это нормально и не повод для упрёка статье. Фиксируй 
+факт «AQA-evaluation не проводится» в разделе 4 и переноси обсуждение 
+применимости к AQA в раздел 6.
+
+### 1. МЕТАДАННЫЕ (YAML)
+
+```yaml
+title: "<оригинальный заголовок>"
+title_ru: "<перевод>"
+short_name: "<canonical акроним>"
+authors: [<фамилии>]
+year: <YYYY>
+venue: "<conference/journal>"
+venue_tier: "<A*/A/B/Q1/Q2>"
+doi: "<link>"
+code: "<github>"
+paper_type: "ssl_backbone"   # обязательно
+tags: [<из фикс. словаря, минимум 3 — обязательно укажи парадигму, модальность и архитектуру>]
+relevance_to_smartrep: <1-5>
+direction: "<🅰 / 🅱 / 🅲>"   # обязательно. Большинство SSL-статей — 🅲. Если иначе, обоснуй.
+status: "reviewed"
+```
+
+### 2. CORE CONTRIBUTION (TL;DR)
+
+3 предложения. **Первое** — какую SSL-задачу решает (masked recon, 
+contrastive, predictive coding, cycle consistency, distillation). 
+**Второе** — основной механизм + что нового относительно прямых 
+предшественников. **Третье** — обоснование `direction` 
+(почему именно 🅰/🅱/🅲 в нашем проекте).
+
+### 3. АРХИТЕКТУРА И МЕТОД
+
+- **SSL-задача:** что именно предсказывается / выравнивается / маскируется. 
+  Какова конструкция позитивов и негативов (если contrastive).
+- **Backbone:** ViT / ST-GCN / Mamba / CNN + специфические блоки для 
+  временной размерности.
+- **Аугментации:** перечисли все. Особо отметь те, что ломают: 
+  периодичность (rep counting), геометрию суставов (наша задача), 
+  биомеханику (направление 🅱).
+- **Loss-функции в LaTeX** с комментарием о геометрическом/информационном смысле.
+- **Двухстадийность / warm-up / curriculum** — есть ли? Какое условие 
+  переключения?
+- **Гиперпараметры обучения:** оптимизатор, batch, memory bank size, эпохи, 
+  K в top-K (если применимо).
+- **Mermaid-диаграмма:** Raw input → View generation → Encoders → 
+  Projector → SSL-Loss.
+
+### 4. SSL-ЭКСПЕРИМЕНТЫ
+
+- **Pretraining datasets:** NTU-60/120, Kinetics-400/700, ImageNet, 
+  собственные. Какова шкала?
+- **Downstream protocols:**
+  - Linear evaluation (frozen encoder + FC)
+  - Finetune (encoder + head обучаются end-to-end)
+  - KNN evaluation
+  - Few-label / semi-supervised (1% / 10% label fraction)
+  - Transfer на out-of-distribution датасет
+- **Метрики downstream:** Top-1 / Top-5 accuracy, NMI / ARI для кластеризации, 
+  mAP для retrieval. **AQA-метрики обычно отсутствуют — это ожидаемо, 
+  отметь явно одной строкой.**
+- **SOTA-таблица:** воспроизведи основную, не все.
+- **Качественные результаты:** t-SNE / attention maps / cluster purity — 
+  если есть, прокомментируй что они показывают про геометрию пространства.
+- **Ablation:** какие компоненты критичны, какие косметические.
+
+### 5. EDGE FEASIBILITY (для SmartRep)
+
+| Параметр | Значение |
+|---|---|
+| Параметры энкодера на инференсе (M) | <число / НЕ УКАЗАНО> |
+| GFLOPs | <число / НЕ УКАЗАНО> |
+| Latency + железо | <число + device / НЕ УКАЗАНО> |
+| Квантизация / дистилляция | <обсуждается?> |
+| Edge / mobile deployment | <да/нет/не обсуждается> |
+| Memory bank / момент-копии на инференсе | <используются? обычно нет> |
+
+**Качественный fallback (если ≥4 НЕ УКАЗАНО):** оценка backbone'а 
+`lightweight / medium / heavy / unknown` + мотивация (тип, ширина, 
+число параллельных веток). Особо отметь, что из SSL-инфраструктуры 
+(memory bank, EMA-encoder, projector head) **не нужно** на инференсе.
+
+### 6. РЕЛЕВАНТНОСТЬ ДЛЯ SMARTREP (как pretraining-кандидат)
+
+- **Backbone reusability:** напрямую совместим со скелетным input'ом 
+  SmartRep (33-точечный COCO/MoveNet)? Какие переходы нужны 
+  (NTU-25 ↔ COCO-33, joint mapping)?
+- **Pretraining recipe transferability:** warm-up, аугментации, размер 
+  batch, memory bank — что переносится на наш малый датасет, что нет?
+- **Domain gap к силовому тренингу:** датасеты статьи (бытовые действия 
+  / спорт / игры) ↔ штанговые упражнения. Насколько большой gap, что 
+  его смягчает (motion-stream? bone-stream?).
+- **Совместимость с downstream AQA-головами:** можно ли поверх этого 
+  энкодера навесить one-class anomaly head (PatchCore, KNN-distance, 
+  reconstruction error)? Не коллапсирует ли SSL-objective при подаче 
+  только эталонных подходов?
+- **LUPI-совместимость:** поддерживает ли фреймворк асимметричные 
+  потоки (Teacher с богатыми данными / Student с бедными), или все 
+  «views» — это симметричные преобразования одного входа?
+- **Periodicity-совместимость:** ломают ли аугментации цикличность 
+  (например, random crop с reflection padding ломает; phase-aware 
+  resampling сохраняет)?
+- **Чувствительность к мелким геометрическим отклонениям:** 
+  по построению objective статьи — он склеивает или различает 
+  сэмплы внутри одного класса? (Для нас критична внутриклассовая 
+  дискриминация: правильный присед vs присед с butt-wink.)
+
+### 7. GAP ДЛЯ НАС (НИША НОВИЗНЫ — самое важное поле)
+
+2–4 конкретных гэпа в формате:
+- **Гэп N:** [что не делает статья как pretraining-метод] → [конкретная 
+  модификация / расширение, которое мы можем заявить как вклад SmartRep].
+
+Типичные формы для SSL-статей:
+- objective не чувствителен к ошибкам техники → ввести error-aware SSL signal
+- нет edge-бенчмарков → воспроизвести + INT8-квантизация
+- views симметричны → ввести настоящий LUPI с привилегированным учителем
+- аугментации ломают периодичность → phase-aware augmentations
+
+### 8. ВЫВОД ДЛЯ ЛИТОБЗОРА
+
+- Приоритет: **ВЫСОКИЙ / СРЕДНИЙ / НИЗКИЙ** + одна строка обоснования.
+- Место в SmartRep-pipeline: какой этап (pre-pretraining / pretraining / 
+  finetune-инициализация / baseline-сравнение).
+- Прямой вклад в направления (🅰 / 🅱 / 🅲) — обычно для SSL-backbone 
+  ненулевой вклад только в 🅲, нулевой в 🅰 и 🅱. Если иначе — обоснуй.
+- 3–5 связанных статей для следующего разбора с краткой ремаркой почему.
+
+---
+
+ИНСТРУКЦИИ AI:
+- Не выдумывай данные. «НЕ УКАЗАНО» — допустимый и частый ответ для 
+  edge-метрик в SSL-статьях.
+- Не натягивай AQA-нарратив. Если AQA-evaluation нет — фиксируй и идём дальше.
+- Разделяй факты и [КОММЕНТАРИЙ РЕЦЕНЗЕНТА].
+- Формулы — LaTeX.
+- Перед финальным артефактом — короткий блок структурных решений.
+- После артефакта — мета-комментарий о работе шаблона на этой статье.
+````
--- a/SmartRep/0_prompts/Промпт
+++ b/SmartRep/0_prompts/Промпт
@@ -0,0 +1,266 @@
+Структурные решения для `pose_method`-промпта (что отличает от A и B):
+
+1. **Direction по умолчанию НЕ нулевой.** Pose papers почти всегда 🅱 (биомех-aware pose), но иногда чисто backbone-роль для 🅲. По умолчанию — 🅱, явное обоснование требуется только если иначе.
+2. **Ключевое различие в разделе 4.** Pose papers оцениваются метриками положений и углов (MPJPE / PA-MPJPE / PVE / joint angle error), а не классификации. Дополнительная ось — **физическая правдоподобность** (jitter, foot sliding, penetration), которую AQA/SSL-шаблоны не покрывают.
+3. **Body model — обязательное поле.** SMPL / SMPL-X / SMPL+H / GHUM / STAR / mesh-free / только joints. От этого зависит, получим ли мы углы в суставах (нужны для 🅱) или только координаты.
+4. **Камера и калибровка — обязательное поле.** Многие SOTA-pose требуют known intrinsics или weak perspective с предположениями, которые не выполняются в зале с телефоном.
+5. **Athletic / extreme pose evaluation — отдельная подсекция.** Большинство pose-методов оценены на H36M (everyday actions); их деградация на глубоких приседах / арках жима — главный риск для нас. Если этой проверки нет, фиксируем явно.
+6. **Stability across reps — отдельный пункт.** Jitter в pose может быть ошибочно интерпретирован downstream-головой как изменение техники между повторами. Это уникальная для periodic-задач проблема, в общих pose-papers её обычно не меряют.
+7. **Раздел 6 — pose-specific релевантность.** Не «применим ли AQA-метод» и не «годится ли как pretraining», а «можно ли вообще получить из этого pose-выхода стабильные joint angles на штанговом видео с окклюзиями».
+
+---
+
+# 📑 Дополнения к тег-словарю для pose-papers
+
+```
+# Выход
+joint_regression, smpl_fitting, smplx_fitting, ghum_fitting, mesh_recovery, 
+ik_solver, dense_pose, 2d_pose, 3d_pose
+
+# Камера и сцена
+single_view, multi_view, monocular, multi_camera, known_intrinsics, in_the_wild
+
+# Приоры
+physics_aware, biomech_aware, kinematic_prior, temporal_prior, contact_aware
+
+# Обучение pose
+synthetic_pretraining, weak_supervision, pseudo_labels
+```
+
+---
+
+# 📝 ВАРИАНТ C — Промпт для pose estimation / mesh recovery / biomech-aware статей
+
+````
+ПРОМПТ ДЛЯ АНАЛИЗА POSE-СТАТЬИ (paper_type: pose_method)
+
+Ты — старший научный рецензент с экспертизой в 2D/3D human pose estimation, 
+parametric body models (SMPL/SMPL-X/GHUM), inverse kinematics и 
+biomechanics-aware pose. Твоя задача — подготовить разбор статьи для 
+проекта SmartRep как кандидата на pose-стадию pipeline'а перед AQA/error-головой.
+
+ВАЖНО-1: если статья ЯВНО про AQA / fine-grained errors / scoring движений 
+— ОСТАНОВИСЬ и сообщи: «AQA-типа, рекомендую AQA-промпт». Pose-выход в AQA-статьях 
+обычно вспомогательный.
+
+ВАЖНО-2: если статья про чистый SSL pretraining без явного pose-output 
+(joint coords / SMPL params / mesh) — ОСТАНОВИСЬ и переключись на 
+SSL-backbone промпт.
+
+ВАЖНО-3: для нашей задачи критичны три риска, которые нужно явно 
+проверить в каждой pose-статье: 
+  (a) деградация на атлетических / экстремальных позах, 
+  (b) поведение при окклюзии (штанга закрывает кисти/плечи), 
+  (c) jitter между фреймами в периодических движениях. 
+Если статья не отвечает на какой-то из трёх — фиксируй как «НЕ ОЦЕНИВАЕТСЯ» 
+и переноси в Gap.
+
+### 1. МЕТАДАННЫЕ (YAML)
+
+```yaml
+title: "<оригинальный заголовок>"
+title_ru: "<перевод>"
+short_name: "<canonical акроним>"
+authors: [<фамилии>]
+year: <YYYY>
+venue: "<conference/journal>"
+venue_tier: "<A*/A/B/Q1/Q2>"
+doi: "<link>"
+code: "<github>"
+paper_type: "pose_method"   # обязательно
+tags: [<из фикс. словаря, минимум 4 — обязательны: тип выхода, body model, камера, парадигма обучения>]
+relevance_to_smartrep: <1-5>
+direction: "<🅰 / 🅱 / 🅲>"   # default 🅱 для pose. Если иначе — обоснуй в TL;DR.
+status: "reviewed"
+```
+
+### 2. CORE CONTRIBUTION (TL;DR)
+
+3 предложения. **Первое** — какую pose-задачу решает: 2D keypoints / 3D joints 
+(absolute / root-relative) / SMPL parameters / full mesh; single-view 
+или multi-view; в реальном времени или offline. **Второе** — основной механизм 
+(regression / optimization-based fitting / IK / hybrid). **Третье** — обоснование 
+`direction` (🅱 если pose-метод, 🅲 если синтетический pretraining backbone, 🅰 если 
+включает явный biomech error head).
+
+### 3. АРХИТЕКТУРА И МЕТОД
+
+- **Выход модели:** {2D-keypoints / 3D-joints / SMPL θ,β / SMPL-X / mesh vertices 
+  / dense correspondences}. **Обязательно укажи, есть ли joint angles на выходе** 
+  (или их нужно вычислять самостоятельно).
+- **Body model:** SMPL / SMPL-X / SMPL+H / GHUM / STAR / skeleton-only / none. 
+  Версия (neutral / gendered), число вершин, число суставов.
+- **Pipeline:**
+  - Backbone (ResNet / HRNet / ViT / Mamba / GCN);
+  - Голова (regression / heatmap / parametric / IK / optimization);
+  - Если optimization-based — solver (LBFGS / Adam) и сколько итераций.
+- **Камера:**
+  - Модель: weak perspective / full perspective / orthographic;
+  - Требуются ли known intrinsics (focal length, principal point)?
+  - Калибровка: автоматическая / нужна заранее / отсутствует.
+- **Кинематические и физические приоры:**
+  - Joint limits (анатомические границы углов)?
+  - Bone length constraints?
+  - Temporal smoothness?
+  - Contact / penetration / foot sliding?
+  - Physics simulation в loop?
+- **Loss-функции в LaTeX** ($\mathcal{L} = \dots$) с разбором по слагаемым: 
+  3D joint loss, 2D reprojection, SMPL params, regularization, biomech priors.
+- **Mermaid-диаграмма:** Image / Video → Backbone → {Heatmaps / Features} → 
+  {Regression / IK / Optimization} → {Joints / SMPL / Mesh}.
+
+### 4. POSE-ЭКСПЕРИМЕНТЫ
+
+- **Training datasets:** H36M, MPI-INF-3DHP, 3DPW, AMASS, AGORA, BEDLAM, 
+  COCO, MPII, собственные. Полностью / частично / только pretraining?
+- **Evaluation datasets:** H36M, 3DPW, EMDB, AGORA-test, ASPset (athletic), 
+  SportsPose, fitness-specific. **Особо отметь, есть ли out-of-distribution 
+  атлетический бенчмарк.**
+- **Pose metrics (обязательно):**
+  - MPJPE (mean per joint position error, mm)
+  - PA-MPJPE (Procrustes-aligned, mm) — снимает absolute scale/rotation
+  - PVE / MPVPE (per-vertex error, для mesh-методов)
+  - PCK @ threshold (Percentage of Correct Keypoints)
+  - Joint angle error (degrees, per-joint) — **редкая, но критичная для нас метрика**
+- **Stability / temporal metrics (если есть):**
+  - Jitter / acceleration error
+  - Foot sliding (mm)
+  - Smoothness (e.g., MPJPE first-derivative)
+- **Robustness тесты (если есть):**
+  - Окклюзия: synthetic mask-out, real occlusion datasets (3DOH, OCHuman);
+  - Cropping / truncation;
+  - Adversarial / compression artifacts.
+- **Athletic / extreme pose evaluation:** делается ли отдельная оценка на 
+  глубоких приседах, мостах, инверсиях, олимпийских позициях? Если нет — 
+  это серьёзный риск, явно фиксируй.
+- **SOTA-таблица:** воспроизведи ключевую.
+- **Ablation:** какие компоненты критичны, какие — косметические.
+
+### 5. EDGE FEASIBILITY (для SmartRep)
+
+| Параметр | Значение |
+|---|---|
+| Параметры (M) | <число / НЕ УКАЗАНО> |
+| GFLOPs / image | <число / НЕ УКАЗАНО> |
+| Latency + железо | <число + device / НЕ УКАЗАНО> |
+| FPS на видео | <число / НЕ УКАЗАНО> |
+| Optimization-loop на инференсе | <да/нет, сколько итераций> |
+| Известные intrinsics / калибровка нужна на инференсе | <да/нет> |
+| Квантизация / дистилляция | <обсуждается?> |
+| Mobile / edge deployment | <да/нет/не обсуждается> |
+
+**Качественный fallback (если ≥4 НЕ УКАЗАНО):** оценка `lightweight / medium / 
+heavy / unknown` + мотивация. Особо отметь два killer-фактора для edge: 
+(i) optimization-loop на инференсе (даже 5–10 итераций LBFGS убивают real-time), 
+(ii) требование известных intrinsics (в зале с произвольным телефоном — 
+несбыточная роскошь).
+
+### 6. РЕЛЕВАНТНОСТЬ ДЛЯ SMARTREP (pose-pipeline применимость)
+
+- **Атлетический domain transfer:** обучен ли метод на чём-то кроме H36M-style 
+  бытовых движений? Если нет — насколько сильно деградирует на глубоких 
+  приседах, плотном бенче, тяге с округлой спиной (можно судить по 
+  атлетическим бенчмаркам или их отсутствию).
+- **Barbell-occlusion устойчивость:** при наличии гриф закрывает кисти, 
+  предплечья, иногда плечи и подбородок. Метод оценен на real occlusion? 
+  Какова деградация MPJPE при mask-out 30–50% видимости?
+- **Углы vs координаты:** даёт ли метод joint angles на выходе напрямую 
+  (через SMPL θ или явный IK), или только координаты, из которых углы 
+  считаются постфактум (с накоплением ошибки)? Для направления 🅱 первое 
+  принципиально важно.
+- **Body-shape нормализация:** даёт ли β-параметры SMPL (или эквивалент)? 
+  Без них одинаковый угол в колене на разных телах = разная биомеханика.
+- **Камерные требования:**
+  - Монокуляр side-view (наш случай) поддерживается?
+  - Нужна ли калибровка intrinsics?
+  - Нужен ли ground-plane?
+- **Темпоральная стабильность:** есть ли явный smoothing / temporal prior? 
+  Какой jitter на статичной части движения (нижняя точка приседа)?
+- **Совместимость с downstream AQA-головой (направление 🅰):** pose-выход 
+  стабилен и плотен по фреймам? Дискретизация по времени совпадает с 
+  частотой нашего видео (≥30 FPS)?
+- **Real-time бюджет:** успевает ли в наш taraget (~30 FPS на mobile)?
+
+### 7. GAP ДЛЯ НАС (НИША НОВИЗНЫ — самое важное поле)
+
+2–4 конкретных гэпа в формате:
+- **Гэп N:** [что не делает или плохо делает статья] → [как это становится 
+  новизной SmartRep].
+
+Типичные формы для pose-papers:
+- Не оценен на атлетических позах → ввести silver-standard атлетический 
+  бенчмарк + бенч-дека-присед domain adaptation.
+- Не оценена устойчивость к barbell-occlusion → ввести синтетический 
+  barbell-mask augmentation + бенч.
+- Optimization-loop на инференсе делает edge невозможным → дистилляция 
+  в feedforward student.
+- Joint angles только постфактум → явная angle-regression head поверх 
+  pose-backbone.
+- Нет temporal prior → cycle-aware smoothing для периодических движений.
+
+### 8. ВЫВОД ДЛЯ ЛИТОБЗОРА
+
+- Приоритет: **ВЫСОКИЙ / СРЕДНИЙ / НИЗКИЙ** + одна строка обоснования.
+- Место в SmartRep-pipeline: какой компонент (pose backbone / SMPL-fitting 
+  step / biomech feature extractor / baseline для сравнения).
+- Прямой вклад в направления: обычно 🅱 ненулевой, 🅰 косвенный (pose 
+  как вход), 🅲 нулевой. Если иначе — обоснуй.
+- 3–5 связанных статей для следующего разбора с краткой ремаркой почему.
+
+---
+
+ИНСТРУКЦИИ AI:
+- Не выдумывай данные. «НЕ УКАЗАНО» / «НЕ ОЦЕНИВАЕТСЯ» — допустимые ответы.
+- Особо аккуратно с интерпретацией МPJPE: это среднее по 14–17 суставам, 
+  а ошибки на extremities (запястья, лодыжки) часто в 2–3× выше; если 
+  per-joint breakdown есть — обязательно его процитируй.
+- Если в статье есть только PA-MPJPE без MPJPE — это сигнал, что absolute 
+  pose плохой; явно отметь.
+- Разделяй факты и [КОММЕНТАРИЙ РЕЦЕНЗЕНТА].
+- Формулы — LaTeX.
+- Перед финальным артефактом — короткий блок структурных решений.
+- После артефакта — мета-комментарий о работе шаблона.
+````
+
+---
+
+## 🧭 Обновлённый селектор (с учётом всех трёх шаблонов)
+
+|Признаки в abstract / methods|Шаблон|
+|---|---|
+|Spearman / Kendall / AUROC / per-error F1 / regression head на оценку движения|**A (AQA)**|
+|Named error taxonomy (butt-wink, hitch, valgus и т.п.)|**A (AQA)**|
+|Reconstruction error / distance-to-prototype как anomaly score|**A (AQA)**|
+|MPJPE / PA-MPJPE / PVE / SMPL-fitting / IK / mesh recovery|**C (pose)**|
+|Joint angles / biomech priors / kinematic constraints как первичный выход|**C (pose)**|
+|Pretext task (masked / contrastive / cycle / pred coding) + linear/finetune eval на классификации|**B (SSL backbone)**|
+|Linear eval / KNN на NTU/Kinetics/ImageNet с Top-1 как главной метрикой|**B (SSL backbone)**|
+|Гибрид: pose + AQA в одной статье (как AIFit)|**C primary**, A secondary; в frontmatter `paper_type: hybrid`, два direction-тега|
+|Гибрид: SSL pretraining + downstream pose|**B primary**, C secondary|
+|Dataset paper (sampling protocol / annotation methodology — главное)|существующий 14-секционный dataset-шаблон|
+
+---
+
+## Мета-комментарий
+
+**Что специфично для C по сравнению с A и B:**
+
+- Три «hard checkpoints» (атлетические позы, окклюзия, jitter) вынесены в верхнюю часть промпта, чтобы AI явно их искал, а не упускал в потоке стандартных pose-метрик.
+- Раздел 5 расширен двумя edge-killer полями (optimization loop, intrinsics requirement) — без них pose-метод можно ошибочно классифицировать как edge-friendly по числу параметров.
+- Раздел 6 разворачивает «применимость» через монокуляр-side-view-фильтр SmartRep, а не через generic pose-quality.
+
+**Что закрыто полным трио A/B/C:**
+
+- Spearman/AUROC больше не появляются автоматически в SSL- и pose-карточках (где их нет).
+- MPJPE/PA-MPJPE больше не появляются в AQA- и SSL-карточках.
+- `direction` без default во всех трёх (B и C переопределяют через «обычно X, но обоснуй»).
+- Edge fallback унифицирован.
+
+**Что ещё в очереди (не сейчас, но имеет смысл записать):**
+
+- Возможный **четвёртый** шаблон `synthesis_method` (для NeRF / 3DGS / SMPL-rendering / data augmentation статей) — тебе он может понадобиться при разборе FLEX и пайплайнов синтеза тренировочных данных. Решать стоит после FLEX-карточки, чтобы понять, лезет ли FLEX в существующие или нужен отдельный.
+- Миграция старых карточек: добавить `paper_type` в frontmatter Fit3D / FLAG3D / Fitness-AQA / H36M / AIFit. Это пять минут ручной работы или один прогон через скрипт.
+
+---
+
+Прагматичный следующий шаг: **прогнать новый pose_method-промпт на AIFit**. У тебя уже есть AIFit-карточка по старому общему шаблону — это даст прямую A/B-проверку, что именно прибавляет специализированный pose-промпт. Если ОК — запускаем?
--- a/SmartRep/0_prompts/Промпт
+++ b/SmartRep/0_prompts/Промпт
@@ -0,0 +1,338 @@
+
+
+Структурные решения для `synthesis_method`-промпта (что отличает от A/B/C):
+
+1. **Принципиально другой угол оценки.** A/B/C оценивают модель, которая что-то предсказывает. Здесь модель **создаёт данные**, и оцениваем мы пригодность синтеза для downstream-обучения, а не визуальное качество как самоцель. Sim2real gap — главная ось.
+    
+2. **Три подкласса под одной шапкой — нужен явный sub-type.** NeRF/3DGS (novel view synthesis из реальных видео), SMPL-rendering (физико-параметрический рендер из mocap), GAN/диффузия (генерация с нуля или conditional) — у них разные параметры качества, разные риски, разные edge-кейсы. Ввожу `synthesis_subtype` в YAML.
+    
+3. **«Edge feasibility» переосмысливается.** Synthesis в SmartRep — **offline data generation**, не runtime. Поэтому раздел 5 — это не latency на mobile, а **production cost**: GPU-часы на сцену, требования к captureу (число камер, синхронизация, маркеры), масштабируемость. Inference latency может быть вообще нерелевантен.
+    
+4. **«Fidelity vs Utility» — ключевое разделение.** Visual fidelity (PSNR / SSIM / LPIPS / FID) ≠ downstream utility (улучшает ли downstream MPJPE / accuracy при добавлении синтетики в обучение). Многие работы хвалят fidelity, но не проверяют utility — это главный gap-генератор.
+    
+5. **Контролируемость генерации — обязательное поле.** Можем ли мы синтезировать **именно ту ошибку техники**, которой нам не хватает в реальных данных (e.g., butt-wink с заданной амплитудой)? Без controllability синтез — просто шумная аугментация.
+    
+6. **Лицензионные / этические риски.** Synthetic faces, synthetic identities, deepfake-adjacent методы — отдельная категория рисков, которой нет в A/B/C. Особенно если пайплайн синтезирует лица атлетов.
+    
+7. **Sim2real bridge — отдельный раздел.** Domain randomization, domain adaptation, mixed pretraining recipes (synthetic→real fine-tuning) — есть ли у статьи что-то про это, или она оставляет sim2real upstream-задачей.
+    
+
+---
+
+# 📑 Дополнения к тег-словарю для synthesis-papers
+
+```
+# Подтип синтеза
+nerf, gaussian_splatting, smpl_rendering, mocap_replay, 
+diffusion, gan, neural_rendering, physics_simulation, motion_retargeting
+
+# Контролируемость
+controllable_pose, controllable_appearance, controllable_camera, 
+controllable_lighting, controllable_clothing, uncontrolled
+
+# Sim2real
+domain_randomization, domain_adaptation, mixed_training, no_sim2real
+
+# Капчер-требования
+multi_view_capture, single_view_capture, mocap_required, marker_based, 
+markerless_capture, in_the_wild_capture, studio_capture
+
+# Применение
+data_augmentation, novel_view_synthesis, avatar_creation, mesh_recovery_aux
+```
+
+---
+
+# 📝 ВАРИАНТ D — Промпт для synthesis / data generation статей
+
+````
+ПРОМПТ ДЛЯ АНАЛИЗА SYNTHESIS-СТАТЬИ (paper_type: synthesis_method)
+
+Ты — старший научный рецензент с экспертизой в neural rendering 
+(NeRF, 3D Gaussian Splatting), parametric body rendering (SMPL-X / GHUM), 
+diffusion-based generation, motion retargeting и synthetic data pipelines 
+для обучения CV-моделей. Твоя задача — подготовить разбор статьи для 
+проекта SmartRep как кандидата на источник синтетических данных для 
+обогащения тренировочной выборки (особенно — для редких ошибок техники, 
+которых в реальных датасетах мало).
+
+ВАЖНО-1: если статья — это AQA / pose method / SSL backbone и synthesis 
+там вспомогательный модуль, ОСТАНОВИСЬ и переключись на соответствующий 
+шаблон (A / C / B). Этот шаблон — для статей, где **синтез данных — 
+главный вклад**.
+
+ВАЖНО-2: для нашей задачи критичны четыре оси, которые нужно явно 
+проверить:
+  (a) Sim2real gap — переносится ли модель, обученная на синтетике, 
+      на реальное видео из зала;
+  (b) Controllability — можем ли мы задать конкретную ошибку техники 
+      (butt-wink с амплитудой X°, valgus knee на повторе N);
+  (c) Production cost — сколько стоит сгенерировать N часов видео 
+      (GPU-часы, требования к источникам);
+  (d) Лицензионные / этические риски — особенно для синтеза лиц / 
+      идентичностей.
+Если статья молчит по какой-то оси — фиксируй как «НЕ ОЦЕНИВАЕТСЯ» 
+и переноси в Gap.
+
+ВАЖНО-3: Visual fidelity (PSNR / SSIM / LPIPS / FID) ≠ downstream utility 
+(улучшение downstream MPJPE / accuracy при добавлении синтетики в обучение). 
+Это РАЗНЫЕ оси оценки. Если статья хвалит только fidelity без utility-теста 
+на downstream-задаче — явно отметь это как красный флаг.
+
+### 1. МЕТАДАННЫЕ (YAML)
+
+```yaml
+title: "<оригинальный заголовок>"
+title_ru: "<перевод>"
+short_name: "<canonical акроним>"
+authors: [<фамилии>]
+year: <YYYY>
+venue: "<conference/journal>"
+venue_tier: "<A*/A/B/Q1/Q2/SIGGRAPH>"
+doi: "<link>"
+code: "<github>"
+project_page: "<если есть отдельная>"
+paper_type: "synthesis_method"   # обязательно
+synthesis_subtype: "<nerf | gaussian_splatting | smpl_rendering | diffusion | gan | physics_sim | motion_retargeting | hybrid>"   # обязательно
+tags: [<из фикс. словаря, минимум 4 — обязательны: подтип, контролируемость, capture-требования, sim2real подход>]
+relevance_to_smartrep: <1-5>
+direction: "<🅰 / 🅱 / 🅲>"   # synthesis обычно служит 🅲 (data adaptation), 
+                              # реже 🅰 (controllable error generation), редко 🅱.
+                              # Обязательно обоснуй в TL;DR.
+status: "reviewed"
+```
+
+### 2. CORE CONTRIBUTION (TL;DR)
+
+3 предложения. **Первое** — что именно синтезирует метод 
+(novel views реального человека / параметрические аватары / полное видео 
+с нуля / motion-only / appearance-only) и из каких входов. 
+**Второе** — основной механизм + что нового относительно прямых предшественников. 
+**Третье** — обоснование `direction` и принципиальная роль для SmartRep 
+(generator of training data / generator of test cases / avatar creation / 
+ничто из этого).
+
+### 3. АРХИТЕКТУРА И МЕТОД
+
+- **Подтип синтеза:** NeRF / 3DGS / SMPL-rendering / diffusion / GAN / 
+  physics simulation / motion retargeting / гибрид.
+- **Входы метода:**
+  - Source: multi-view видео / single-view / mocap (.bvh / SMPL params) / 
+    text prompt / reference image / scan / none;
+  - Capture требования: число камер, синхронизация, маркеры, контролируемое 
+    освещение, green screen, studio vs in-the-wild;
+  - Pose source: GT mocap / pseudo-labels от pose estimator / sampled 
+    из латентного пространства.
+- **Выходы метода:**
+  - Modality: RGB видео / RGB+depth / RGB+normals / mesh + texture / 
+    SMPL params + render / pose-only sequence;
+  - Resolution + FPS;
+  - Длительность сэмпла (несколько кадров / несколько секунд / 
+    произвольная длина).
+- **Pipeline:**
+  - Backbone (CNN / NeRF MLP / Gaussian primitives / U-Net diffusion / GAN);
+  - Body / scene representation (volumetric / point cloud / mesh / hybrid);
+  - Renderer (volume / rasterization / differentiable);
+  - Optimization (per-scene / amortized / hybrid).
+- **Контролируемость:**
+  - Pose: можно ли задать произвольную позу / последовательность? Источник 
+    (SMPL params / skeleton / latent code)?
+  - Appearance: одежда, телосложение, кожа — управляемы или фиксированы?
+  - Camera: viewpoint, FOV, intrinsics — можно ли варьировать?
+  - Lighting: фиксированное / управляемое / relit;
+  - Background: studio fixed / interchangeable / generated.
+- **Loss-функции в LaTeX** ($\mathcal{L} = \dots$) с разбором по слагаемым: 
+  reconstruction (RGB / mask / depth), perceptual (LPIPS), regularization 
+  (smoothness / sparsity / SDS-loss для diffusion), pose / shape priors.
+- **Mermaid-диаграмма:** Inputs (source data) → Representation (3D model) 
+  → Renderer → Output (video / images) → (опционально) Downstream training.
+
+### 4. SYNTHESIS-ЭКСПЕРИМЕНТЫ
+
+#### 4.1 Visual fidelity метрики (что обычно есть)
+
+- **Image-level:** PSNR ↑, SSIM ↑, LPIPS ↓, FID ↓, KID ↓;
+- **Video-level:** FVD ↓, temporal LPIPS;
+- **Geometry (если применимо):** Chamfer distance, IoU, normal consistency;
+- **User study:** preference rate, realism rating (если есть).
+
+#### 4.2 Downstream utility метрики (что обычно НЕТ — но критично нам)
+
+Делает ли статья хотя бы один из тестов:
+- Pretraining на synthetic → finetune на real → улучшение downstream метрики 
+  (MPJPE / accuracy) vs only-real baseline?
+- Mixed training (real + synthetic) → улучшение vs only-real?
+- Synthetic-only training → real test → насколько деградирует?
+- **Если ни один из этих тестов не проводится — это главный red flag**. 
+  Visual fidelity без utility-теста означает, что синтетика может быть 
+  красивой, но бесполезной для обучения. Явно отметь.
+
+#### 4.3 Sim2real анализ
+
+- Domain gap между synthetic и real — оценен ли количественно?
+- Domain randomization применяется (lighting / background / camera jitter / 
+  texture variation)?
+- Domain adaptation (после-генерации post-processing, adversarial alignment)?
+- Mixed training recipe (соотношение real:synth, curriculum)?
+- Failure modes на real data — обсуждаются?
+
+#### 4.4 Controllability эксперименты
+
+- Pose disentanglement: меняется ли только поза при фиксированной 
+  appearance? Измерено количественно (например, FID при свапе)?
+- Appearance transfer: один человек в позах другого — работает?
+- Out-of-distribution позы: синтез работает на позах, далёких от 
+  training distribution? **Это критично для нас** — атлетические 
+  позы редко в training.
+
+#### 4.5 SOTA-таблица + ablation
+
+Воспроизведи ключевую сравнительную таблицу. Особо отметь, на каком датасете 
+сравнение (in-distribution vs OOD).
+
+### 5. PRODUCTION FEASIBILITY (для SmartRep — ОТЛИЧАЕТСЯ от edge!)
+
+Synthesis в SmartRep — **offline data generation**, не runtime. Поэтому 
+оцениваем production cost, а не mobile latency.
+
+| Параметр | Значение |
+|---|---|
+| GPU-часы на одну сцену / аватара (training) | <число / НЕ УКАЗАНО> |
+| GPU-часы на N секунд видео (inference) | <число / НЕ УКАЗАНО> |
+| Тип GPU в экспериментах | <модель / НЕ УКАЗАНО> |
+| Render FPS | <число / НЕ УКАЗАНО> |
+| Capture cost (камеры / mocap / studio) | <описание / не нужен> |
+| Per-scene optimization (NeRF/3DGS) или amortized | <да / нет> |
+| Масштабируемость (можно ли сгенерировать 100+ часов) | <качественная оценка> |
+| Лицензия выходных данных | <permissive / restricted / unclear> |
+
+**Качественный fallback:** оценка стоимости как `cheap / moderate / expensive / 
+prohibitive` для нашего use case (нам нужны десятки-сотни часов синтетики 
+с управляемыми ошибками техники).
+
+### 6. РЕЛЕВАНТНОСТЬ ДЛЯ SMARTREP (synthesis-применимость)
+
+- **Нужный нам тип синтеза:** делает ли метод то, что нам реально нужно — 
+  синтез человека в **полный рост в side-view** при выполнении упражнений 
+  с предметом (штанга / турник)? Поддерживает ли human-object interaction?
+- **Контролируемость ошибок техники:** можем ли мы программно задать 
+  «сделай присед с butt-wink амплитудой 15° на повторе 3 из 5»? Если pose 
+  controllable через SMPL θ — да. Если только текст/латент — скорее нет.
+- **Body / shape diversity:** можем ли варьировать телосложение (β-параметры)? 
+  Это критично для генерализации модели на разные тела пользователей.
+- **Equipment & occlusion:** есть ли поддержка штанги / гантелей как 
+  отдельного объекта в сцене (для реалистичной окклюзии)? Если только 
+  голый человек — utility для нас сильно ограничен.
+- **Side-view bias:** обычные NeRF/3DGS работают на 360°-захвате; для нас 
+  достаточно качественного side-view, но качество должно держаться при 
+  смене угла камеры (зеркала в зале, разные смартфоны).
+- **Sim2real bridge:** что нужно сделать после генерации, чтобы синтетика 
+  работала с реальной gym-камерой (compression, JPEG-noise, motion blur)?
+- **Source data requirements vs наши возможности:**
+  - Нужен ли multi-view capture (у нас его нет)?
+  - Нужен ли mocap / IMU (у нас есть для отдельных сессий)?
+  - Можно ли использовать только monocular видео тренировки?
+- **Лицензионные / этические риски:**
+  - Синтез реальных лиц атлетов — рискованно, потенциально deepfake-adjacent;
+  - Синтетические идентичности (без лиц / blurred faces / generic avatars) 
+    — безопасно;
+  - Если статья синтезирует faces — отметь и предложи модификацию.
+
+### 7. GAP ДЛЯ НАС (НИША НОВИЗНЫ — самое важное поле)
+
+2–4 конкретных гэпа в формате:
+- **Гэп N:** [что не делает или плохо делает статья] → [как это становится 
+  новизной SmartRep].
+
+Типичные формы для synthesis-papers:
+- Только visual fidelity, без downstream utility теста → провести utility 
+  benchmark для AQA-задачи (pretrain on synthetic squats → eval on real Fitness-AQA).
+- Нет equipment/occlusion поддержки → расширить SMPL-X-рендер композицией 
+  с штангой (rigid object + shadow + contact).
+- Контролируемость только по joint positions, не по error type → ввести 
+  taxonomy-aware controller, который мапит named errors (butt-wink, valgus) 
+  на параметрические возмущения SMPL θ.
+- Нет sim2real evaluation на gym-camera artifacts → benchmark с smartphone 
+  compression / lighting variation как post-processing pipeline.
+- Per-scene optimization дорого → дистилляция в amortized feedforward avatar.
+
+### 8. ВЫВОД ДЛЯ ЛИТОБЗОРА
+
+- Приоритет: **ВЫСОКИЙ / СРЕДНИЙ / НИЗКИЙ** + одна строка обоснования.
+- Место в SmartRep-pipeline: какой компонент 
+  (data augmentation для редких ошибок / controllable error injection / 
+  avatar для тестового бенчмарка / baseline для сравнения / неприменимо).
+- Прямой вклад в направления:
+  - 🅲 (адаптация / few-shot): обычно ненулевой, если есть utility test;
+  - 🅰 (error detection): ненулевой только если есть controllable error generation;
+  - 🅱 (biomech pose): обычно нулевой, кроме случаев physics-simulated synthesis 
+    с biomech-aware приорами.
+- 3–5 связанных статей для следующего разбора с краткой ремаркой почему.
+
+---
+
+ИНСТРУКЦИИ AI:
+- Не выдумывай данные. «НЕ УКАЗАНО» / «НЕ ОЦЕНИВАЕТСЯ» — допустимые ответы.
+- Visual fidelity и downstream utility — РАЗНЫЕ вещи, не смешивай.
+- Если статья хвалит PSNR / FID, но не проверяет utility на downstream — 
+  явно фиксируй это как red flag в разделе 4.2 и в Gap.
+- Если synthesis_subtype гибридный — укажи доминанту и второстепенный 
+  компонент, не пиши просто "hybrid".
+- Лицензионные и этические аспекты для face/identity synthesis — 
+  обязательны, не пропускай.
+- Разделяй факты и [КОММЕНТАРИЙ РЕЦЕНЗЕНТА].
+- Формулы — LaTeX.
+- Перед финальным артефактом — короткий блок структурных решений.
+- После артефакта — мета-комментарий о работе шаблона.
+````
+
+---
+
+## 🧭 Финальный селектор (4 шаблона + dataset)
+
+|Признаки в abstract / methods|Шаблон|
+|---|---|
+|Spearman / Kendall / AUROC / per-error F1 / regression на оценку движения|**A (AQA)**|
+|Named error taxonomy + classification/scoring по ошибкам|**A (AQA)**|
+|Reconstruction error / distance-to-prototype как anomaly score|**A (AQA)**|
+|MPJPE / PA-MPJPE / PVE / SMPL fitting / IK / mesh recovery — главный выход|**C (pose)**|
+|Joint angles / biomech priors как первичный выход|**C (pose)**|
+|Pretext task + linear/finetune eval на классификации|**B (SSL backbone)**|
+|Linear / KNN на NTU/Kinetics/ImageNet с Top-1 как главной метрикой|**B (SSL backbone)**|
+|**Главный вклад — генерация данных** (NeRF / 3DGS / SMPL-render / diffusion / GAN / motion retargeting)|**D (synthesis)**|
+|Novel view synthesis от реальных видео людей|**D (synthesis)**|
+|Avatar creation / controllable rendering / data augmentation pipeline|**D (synthesis)**|
+|Гибрид: AQA + pose в одной (как AIFit)|**C primary**, A secondary|
+|Гибрид: SSL pretraining + pose downstream|**B primary**, C secondary|
+|Гибрид: synthesis + downstream evaluation встроенный|**D primary**, B/C secondary|
+|Dataset paper (sampling protocol / annotation methodology — главное)|**dataset (14-секц.)**|
+
+---
+
+## Мета-комментарий
+
+**Что специфично для D по сравнению с A/B/C:**
+
+- Раздел 4 разделён на **fidelity** и **utility** с явным red-flag механизмом — это уникально, в pose/AQA/SSL папках такой развилки нет.
+- Раздел 5 переименован из «edge feasibility» в **«production feasibility»** и измеряет совсем другие вещи (GPU-часы, capture cost, лицензии вывода) — потому что synthesis у нас offline.
+- Controllability — отдельная подсекция (4.4) и отдельный блок в 6 — потому что это килл-фактор для нашего use case (синтез ради синтеза нам не нужен).
+- Лицензионно-этический блок — единственный из четырёх шаблонов, где он обязателен (риск face/identity synthesis).
+
+**Что закрыто полным квартетом A/B/C/D:**
+
+- Каждый шаблон явно отгораживается от трёх остальных в верхней части ("ВАЖНО-1: если статья X-типа — переключись").
+- `direction` без default везде, с правилом по-умолчанию для подсказки и обязательным обоснованием в TL;DR.
+- Edge / production feasibility унифицирован по структуре, но разный по содержанию.
+- Тег-словарь покрывает все четыре парадигмы без дублей.
+- Все четыре шаблона требуют структурный preamble + meta-commentary.
+
+**Очередь следующих улучшений (после применения на реальных статьях):**
+
+- Возможный **пятый** шаблон `evaluation_protocol` — для статей про метрики и бенчмарки сами по себе (Datasheets for Datasets, AQA evaluation protocols, fairness audits). Сейчас явной нужды нет, но если попадётся — будем знать.
+- Миграция старых карточек: добавить `paper_type` в frontmatter Fit3D / FLAG3D / Fitness-AQA / H36M / AIFit (последняя — `pose_method` или `hybrid: pose_method + aqa_method`).
+- Cross-reference между гибридными карточками: `primary_card`, `secondary_card` — как договаривались. Реализуется в Obsidian как обычные wikilinks `[[...]]` в frontmatter.
+- Dataview-запросы для vault: после миграции можно будет легко фильтровать `paper_type: synthesis_method AND relevance_to_smartrep >= 4` или строить таблицы покрытия по направлениям.
+
+---
+
+Прагматичный следующий шаг: у тебя FLEX (arXiv 2506.03198) был flagged как highest priority и identified как closest competitor. Вероятно, FLEX — это **D (synthesis) или гибрид D + dataset**, если он собирает синтетический fitness-датасет. Прогоняем D-промпт на FLEX и смотрим, как он себя ведёт на реальной статье из нашей ниши?
--- a/SmartRep/0_prompts/Промпт
+++ b/SmartRep/0_prompts/Промпт
@@ -0,0 +1,243 @@
+
+
+---
+
+# 📝 ВАРИАНТ E — Промпт для task-utility статей (rep counting, localization, tracking, phase classification)
+
+````
+ПРОМПТ ДЛЯ АНАЛИЗА TASK-UTILITY СТАТЬИ (paper_type: task_utility)
+
+Ты — старший научный рецензент с экспертизой в supervised методах узких 
+задач для видео и движений: подсчёт повторов, временная локализация действий, 
+классификация фаз, трекинг объектов, gait analysis. Твоя задача — подготовить 
+разбор статьи для проекта SmartRep как кандидата на конкретный компонент 
+pipeline, а не как методологическую основу.
+
+ВАЖНО-1: если статья учит representation (без явной готовой задачи на выходе) 
+через pretext task / contrastive / masked modeling — ОСТАНОВИСЬ и переключись 
+на B (SSL backbone).
+
+ВАЖНО-2: если статья оценивает качество движения (regression score / 
+named errors / anomaly per rep) — ОСТАНОВИСЬ и переключись на A (AQA).
+
+ВАЖНО-3: если статья восстанавливает позу или mesh (MPJPE / SMPL fitting) — 
+ОСТАНОВИСЬ и переключись на C (pose).
+
+ВАЖНО-4: если статья генерирует данные (NeRF / 3DGS / SMPL-rendering / 
+diffusion) — ОСТАНОВИСЬ и переключись на D (synthesis).
+
+Этот шаблон — для статей, где (i) задача известна и точно определена 
+выходным контрактом (per-frame label / count / bounding box / boundary), 
+(ii) обучение supervised, (iii) ценность для нас — компонент в pipeline, 
+а не методология. Типичные представители: RepNet, TransRAC, BMN, 
+ActionFormer, ByteTrack, TCC.
+
+ВАЖНО-5: для нашей задачи у task-utility статей чаще всего критичен 
+edge feasibility как DEAL-BREAKER. Multi-speed inference, optimization-loop 
+во время inference, sliding window на длинных видео, quadratic attention — 
+все это потенциальные kill-факторы. Если такой kill-фактор есть, фиксируй его 
+явно в разделе 5 как "edge_killer: <тип>".
+
+### 1. МЕТАДАННЫЕ (YAML)
+
+```yaml
+title: "<оригинальный заголовок>"
+title_ru: "<перевод>"
+short_name: "<canonical акроним>"
+authors: [<фамилии>]
+year: <YYYY>
+venue: "<conference/journal>"
+venue_tier: "<A*/A/B/Q1/Q2>"
+doi: "<link>"
+arxiv: "<link>"
+code: "<github>"
+paper_type: "task_utility"   # обязательно
+task_subtype: "<rep_counting | action_localization | phase_classification | object_tracking | shot_boundary | gait_analysis | other>"   # обязательно
+direct_ancestor: "<short_name предшественника или null>"   # обязательно для incremental статей
+tags: [<из фикс. словаря, минимум 4 — task_subtype, output type, ключевые edge-decision-points, modality>]
+relevance_to_smartrep: <1-5>
+direction: "<🅰 / 🅱 / 🅲 + опц. (preprocessing/utility)>"   # обязательно. Task-utility часто = preprocessing для 🅰. Обоснуй явно.
+pipeline_role: "<deployment_candidate | distillation_teacher | dataset_construction_tool | preprocessing_step | reference_baseline | not_applicable>"   # обязательно, можно несколько через запятую
+status: "reviewed"
+```
+
+### 2. CORE CONTRIBUTION (TL;DR) + DELTA OVER ANCESTOR
+
+3 предложения. **Первое** — какую узкую задачу решает (rep counting / 
+temporal localization / phase classification / tracking) и формальный 
+output-контракт (per-frame density / boundaries / labels / boxes). 
+**Второе** — основной механизм + что нового относительно direct_ancestor 
+(если есть). **Третье** — обоснование `direction` и `pipeline_role` 
+для SmartRep.
+
+Если есть direct_ancestor — отдельный микро-блок «Delta over <ancestor>»: 
+2-3 пункта что *именно* добавлено / изменено / убрано. Это ключевое для 
+incremental task_utility статей: вся ценность часто сосредоточена в delta.
+
+### 3. ВЫХОДНОЙ КОНТРАКТ И АРХИТЕКТУРА
+
+**Output spec (формально, обязательно):**
+- Input shape: <e.g., N frames × H × W × 3>
+- Output shape: <e.g., per-frame N × density value, или N × 2 (period, periodicity)>
+- Output units / range: <density 0..1, period in frames, count integer, bbox xyxy, ...>
+- Aggregation: как из per-frame output получается финальный ответ 
+  (sum, integration, NMS, max, ...).
+
+**Backbone:** что используется как feature extractor. Если backbone 
+heavy (ResNet-50, ViT-B+, Video Swin) — особо отметь.
+
+**Task-specific блоки:** density map regressor / boundary classifier / 
+TSM bottleneck / cross-attention head / sliding-window aggregator. 
+Перечисли с краткими размерностями.
+
+**Аугментации:** как для обучения, так и для inference (если применимо). 
+Особо отметь те, что моделируют наш реальный сценарий (camera motion, 
+lighting variation, occlusion) или ломают его (artificial structure 
+not present in real videos).
+
+**Loss-функции в LaTeX** ($\mathcal{L} = \dots$) с разбором по слагаемым. 
+Для task_utility статей loss обычно простой (CE / MSE / focal); ключевое 
+— какой именно target и как он генерируется.
+
+**Inference protocol:** что происходит на test-time, помимо forward pass. 
+Multi-speed evaluation? Multi-scale aggregation? Iterative refinement? 
+Sliding window? Caching? Это места возможных edge-killers.
+
+**Mermaid-диаграмма:** Input → Backbone → Task head → Output → Aggregation.
+
+### 4. ЭКСПЕРИМЕНТЫ
+
+- **Training datasets:** что использовалось для обучения. Если synthetic — 
+  как генерируется (link на D-шаблон если нужен полный разбор generation 
+  pipeline отдельно).
+- **Evaluation datasets:** in-domain + out-of-domain. Особо отметь, есть 
+  ли fitness/sport-specific eval.
+- **Task-specific метрики (обязательно по типу задачи):**
+  - Rep counting: MAE, OBO, RMSE
+  - Localization: mAP@IoU, recall@K
+  - Phase classification: per-frame accuracy, F1
+  - Tracking: MOTA, IDF1, HOTA
+  - Period estimation: F1, precision, recall, AUC
+  - Если используются нестандартные метрики — обоснуй.
+- **SOTA-таблица:** воспроизведи ключевую сравнительную таблицу.
+- **Cross-dataset transfer:** работает ли метод без fine-tuning на 
+  unseen датасете? Это сильный сигнал генерализации.
+- **Failure modes:** какие сценарии явно ломают метод? Многие task_utility 
+  статьи честно перечисляют (double-counting, action interruption, 
+  long videos, multi-instance). Зафиксируй.
+- **Ablation:** какие компоненты критичны, какие косметические.
+
+### 5. EDGE FEASIBILITY (DEAL-BREAKERS, не fallback)
+
+Сначала отдельный блок **edge_killers** — категориальные kill-факторы 
+для нашего edge-таргета. Если хотя бы один присутствует, метод НЕ 
+deployment-кандидат; пересматриваем pipeline_role на teacher / 
+preprocessing / dataset_construction.
+
+| Edge-killer | Присутствует? | Деталь |
+|---|---|---|
+| Multi-speed inference (×N стоимость) | да/нет | <количество прогонов> |
+| Optimization loop на инференсе | да/нет | <число итераций> |
+| Sliding window over long video | да/нет | <window size, stride> |
+| Quadratic attention (NxN over длинных N) | да/нет | <max N, что лимитирует> |
+| Multi-scale processing (×K backbone passes) | да/нет | <K> |
+| Heavy backbone (>10M params) | да/нет | <модель + размер> |
+| Multi-stream fusion на инференсе | да/нет | <streams> |
+| Iterative refinement | да/нет | <число итераций> |
+| Required intrinsics / calibration | да/нет | <какая> |
+
+Затем стандартная таблица:
+
+| Параметр | Значение |
+|---|---|
+| Параметры (M) | <число / НЕ УКАЗАНО + оценка по компонентам> |
+| GFLOPs | <число / НЕ УКАЗАНО> |
+| Latency + железо | <число + device / НЕ УКАЗАНО> |
+| Inference cost multiplier | <1× / 2× / 4× / больше> |
+| Real-time на mobile? | <да/нет/не тестировано/невозможно (объясни)> |
+| Квантизация / дистилляция | <обсуждается?> |
+
+**Качественный вердикт:** `lightweight / medium / heavy / prohibitive` 
+для нашего mobile-таргета (Jetson Orin Nano / iPhone Neural Engine, 
+~30 FPS). С обоснованием в одну строку.
+
+### 6. РОЛЬ В SMARTREP-PIPELINE (центральный раздел)
+
+Это главный раздел этого шаблона. Прямо отвечает на вопрос 
+«куда мы это ставим, и ставим ли вообще».
+
+Для каждой возможной роли — оцени с обоснованием:
+
+- **deployment_candidate:** работает ли метод как есть на нашем 
+  edge-таргете в нашем sub-domain (5 силовых упражнений, side-view 
+  monocular, gym camera, real-time/near-real-time)? Если да — какие 
+  inference-tweaks нужны.
+- **distillation_teacher:** годится ли как teacher для дистилляции 
+  в более лёгкого student'а (e.g., heavy ResNet-50 → light MobileNet 
+  / ST-GCN)? Какой output-target подходит для distillation 
+  (logits / soft labels / intermediate features)?
+- **dataset_construction_tool:** можно ли offline прогнать через метод 
+  наш собранный корпус, чтобы получить silver-standard метки 
+  (per-rep boundaries, period lengths, phase labels)? Какие риски 
+  (false positives, double counting, разметочные артефакты)?
+- **preprocessing_step:** служит ли как обязательный пред-шаг для 
+  downstream-головы (наш AQA-head требует rep boundaries — этот метод 
+  их даёт)? Архитектурно какова связка: что в, что из.
+- **reference_baseline:** годится ли для валидации, что наш собственный 
+  метод не хуже SOTA на стандартных бенчмарках (для аргументации в 
+  публикации SmartRep)?
+
+Указывай несколько ролей одновременно, если применимо. Например, 
+«distillation_teacher + reference_baseline» — типичная комбинация для 
+heavy SOTA метода.
+
+### 7. GAP ДЛЯ НАС (НИША НОВИЗНЫ)
+
+2-4 конкретных гэпа в формате:
+- **Гэп N:** [что не делает метод как task-solver / что плохо в его 
+  edge-профиле / что недоступно в его выходном контракте] → 
+  [конкретная модификация / расширение / замена для SmartRep].
+
+Типичные формы для task_utility-papers:
+- RGB-only, нет skeleton-варианта → переписать на skeleton input для edge
+- Multi-speed inference невозможен real-time → заменить на adaptive period range за один проход
+- Class-agnostic overengineering → exercise-specific lightweight specialization
+- Output даёт boundaries без quality score → расширить с per-rep AQA head
+- Не оценен на gym camera artifacts → бенч с реальными артефактами
+- Heavy backbone убивает edge → distill в lightweight student
+
+### 8. ВЫВОД ДЛЯ ЛИТОБЗОРА
+
+- Приоритет: **ВЫСОКИЙ / СРЕДНИЙ / НИЗКИЙ** + одна строка обоснования.
+- Pipeline role (повторение из YAML, но с нюансами): 
+  основная роль + вторичная + что для этого нужно сделать практически.
+- Прямой вклад в направления:
+  - 🅰: обычно как preprocessing/utility, не сам error detection
+  - 🅱: обычно нулевой
+  - 🅲: обычно нулевой (метод supervised, не SSL adaptation)
+  - Если иначе — обоснуй.
+- 3-5 связанных статей для следующего разбора: direct_ancestor 
+  (если ещё не разобран), direct_descendant (если есть), 
+  методологические альтернативы, complementary компоненты для нашего pipeline.
+
+---
+
+ИНСТРУКЦИИ AI:
+- Не выдумывай данные. «НЕ УКАЗАНО» — допустимый ответ.
+- Если ты заметил, что edge-killer присутствует — фиксируй явно и 
+  пересматривай pipeline_role. Не пиши «medium feasibility» если 
+  multi-speed ×4 inference категориально несовместим с real-time mobile.
+- Output-контракт — формально. Не «модель выдаёт повторы», а «модель 
+  выдаёт per-frame density vector D ∈ R^N со значениями [0, 1], 
+  count = sum(D)».
+- Direct_ancestor и delta_over_ancestor — обязательны для incremental 
+  статей. Это сильно ускоряет понимание цепочки.
+- Раздел «Роль в SmartRep-pipeline» — центральный. Не стесняйся писать 
+  его длиннее раздела «архитектура».
+- Разделяй факты и [КОММЕНТАРИЙ РЕЦЕНЗЕНТА].
+- Формулы — LaTeX.
+- Перед финальным артефактом — короткий блок структурных решений.
+- После артефакта — мета-комментарий о работе шаблона на этой статье.
+````
+
+---