first commit

project-tasks/README.md

@@ -0,0 +1,86 @@
+# Банк проектных заданий
+
+Банк содержит 40 готовых проектных заданий по 32 основным статьям; отложенных вариантов сейчас нет. По одному заданию подготовлено для каждой статьи; для восьми широких работ выделены по две независимые постановки. Варианты A и B различаются центральным вопросом, техническим результатом и обязательным экспериментом. Изменение только нагрузки, параметра или типа отказа оставлено как возможное продолжение одного задания.
+
+Одно проектное задание назначается одной команде. Если по одной статье назначены две команды, они работают независимо: используют разные репозитории и не передают друг другу код, экспериментальные данные или результаты до завершения оценивания. Общими остаются только опубликованные статья и исходный артефакт.
+
+Во всех заданиях исходный обязательный путь рассчитан на CPU и бесплатную инфраструктуру. Команда с подтверждённым доступом к GPU может по согласованию включить GPU-реализацию и эксперименты в обязательный план по [общим правилам проекта](../project.md#ресурсы-данные-и-лицензии). Ссылки, закреплённые ревизии и лицензии документально проверены 5 сентября 2026 года; известных блокеров для назначения нет. Технические предпосылки команда проверяет по [правилам первой контрольной точки](../project-checkpoints/01-project-plan.md).
+
+Наличие опубликованного артефакта в задании не означает, что команда обязательно строит проект на его коде. В зависимости от проверяемого вопроса допустимым путём может быть работа с авторским артефактом, самостоятельная реализация центрального механизма, собственный симулятор или их сочетание. Конкретные варианты задаются формулировкой технического результата либо отдельным полем «Допустимый технический путь». Если разрешено несколько путей, они равноправны и оцениваются по полученному результату, корректности эксперимента и обоснованности выводов.
+
+Общий порядок выбора, контрольные точки и требования к результатам описаны в [правилах проекта](../project.md), а место `ТР`, `Э` и `ВО` в итоговой оценке — в [правилах оценивания](../grading.md).
+
+## Тематические группы
+
+- [Проверка корректности и надёжности](#проверка-корректности-и-надёжности) — спецификации, тестирование, поиск ошибок и проверка поведения при отказах.
+- [Хранилища, базы данных и потоковая обработка](#хранилища-базы-данных-и-потоковая-обработка) — транзакции, кэширование, хранение и обработка данных.
+- [Облачные, edge- и serverless-системы](#облачные-edge--и-serverless-системы) — микросервисы, оркестрация, размещение и бессерверные вычисления.
+- [Сети и распределённые протоколы](#сети-и-распределённые-протоколы) — передача данных, управление перегрузкой и отказоустойчивое согласование.
+- [Распределённое выполнение и управление ресурсами](#распределённое-выполнение-и-управление-ресурсами) — графы задач, планирование, восстановление и коллективные операции.
+- [Инфраструктура инференса LLM](#инфраструктура-инференса-llm) — память, планирование и раздельное выполнение запросов к большим языковым моделям.
+
+Группировка помогает ориентироваться в банке и не влияет на требования или оценивание. Некоторые задания относятся сразу к нескольким областям; в перечне они помещены в основную группу по центральному вопросу проекта.
+
+## Проверка корректности и надёжности
+
+- [P01. Remix: спецификации разной гранулярности для проверки распределённых систем](p01-remix.md)
+- [P02. DUPChecker: статическая проверка совместимости форматов при обновлении](p02-dupchecker.md)
+- [P03-A. Acto: поиск состояний](p03-a-acto-state-search.md)
+- [P03-B. Acto: проверки и уменьшение](p03-b-acto-oracles-and-shrinking.md)
+- [P04. Legolas: поиск ошибок частичных отказов по состояниям системы](p04-legolas.md)
+- [P06. SuperBench: упреждающая проверка вычислительной инфраструктуры](p06-superbench.md)
+- [P08. PGVal: сквозная проверка гарантий потоковой обработки](p08-pgval.md)
+- [P09-B. FoundationDB: детерминированная имитация](p09-b-foundationdb-simulation.md)
+
+## Хранилища, базы данных и потоковая обработка
+
+- [P05. SIEVE: простая политика вытеснения веб-кэша](p05-sieve.md)
+- [P09-A. FoundationDB: транзакции и отказы](p09-a-foundationdb-transactions.md)
+- [P10. Detock: транзакции между регионами без глобального упорядочивания](p10-detock.md)
+- [P11. Clay Codes: восстановление данных с меньшим сетевым обменом](p11-clay-codes.md)
+- [P12-A. ClickHouse: отсечение данных](p12-a-clickhouse-data-skipping.md)
+- [P12-B. ClickHouse: векторизованный конвейер](p12-b-clickhouse-vectorized-pipeline.md)
+- [P13. Noria: частично материализованный потоковый граф для веб-приложений](p13-noria.md)
+- [P14-A. Flink: режимы контрольных точек](p14-a-flink-checkpoints.md)
+- [P14-B. Flink: rescaling и восстановление](p14-b-flink-rescaling-recovery.md)
+- [P21. DBSP/Feldera: инкрементальное выполнение запросов](p21-dbsp-feldera.md)
+
+## Облачные, edge- и serverless-системы
+
+- [P07-A. DeathStarBench: хвостовая задержка](p07-a-deathstarbench-tail-latency.md)
+- [P07-B. DeathStarBench: размещение и интерференция](p07-b-deathstarbench-placement.md)
+- [P15. Autothrottle: двухуровневое управление ресурсами микросервисов](p15-autothrottle.md)
+- [P16. Oakestra: иерархическая оркестрация edge-кластера](p16-oakestra.md)
+- [P17. SkyPilot: планирование заданий между облаками](p17-skypilot.md)
+- [P18. Faasm: WebAssembly-изоляция для stateful serverless](p18-faasm.md)
+- [P19. Serverless Cold Starts: проверка обобщений на производственных трассах](p19-serverless-cold-starts.md)
+
+## Сети и распределённые протоколы
+
+- [P20. Cloudcast: стоимость и скорость многоадресной передачи между облаками](p20-cloudcast.md)
+- [P22. DCTCP: управление перегрузкой в сети дата-центра через ECN](p22-dctcp.md)
+- [P32. Alea-BFT: асинхронная репликация с византийскими отказами](p32-alea-bft.md)
+
+## Распределённое выполнение и управление ресурсами
+
+- [P25-A. Ray: динамические графы задач](p25-a-ray-task-graphs.md)
+- [P25-B. Ray: акторы и восстановление](p25-b-ray-actors-recovery.md)
+- [P27. DeDe: декомпозиция задач распределения ресурсов](p27-dede.md)
+- [P30. Pollux: совместная адаптация обучения и кластерного планировщика](p30-pollux.md)
+- [P31-A. GC3: корректность расписаний](p31-a-gc3-correctness.md)
+- [P31-B. GC3: оптимизация под топологию](p31-b-gc3-topology-optimization.md)
+
+## Инфраструктура инференса LLM
+
+- [P23. PagedAttention: управление памятью KV-кэша](p23-pagedattention.md)
+- [P24. Llumnix: динамическое перепланирование LLM-запросов](p24-llumnix.md)
+- [P26-A. Parrot: планирование графа](p26-a-parrot-graph-scheduling.md)
+- [P26-B. Parrot: префиксы и локальность](p26-b-parrot-prefix-locality.md)
+- [P28. DistServe: раздельное выполнение prefill и decode](p28-distserve.md)
+- [P29. Mooncake: глобальный многоуровневый KV-кэш](p29-mooncake.md)
+
+## Как читать проектное задание
+
+Поле «Кратко о статье» объясняет решаемую авторами проблему, основную идею работы и связь с конкретным проектом; поле «Почему результат актуален» описывает современное состояние и сохраняющееся значение результата. «Артефакты и данные» фиксируют доступные исходные материалы, но не определяют способ реализации. Раздел «Обязательный результат» задаёт минимальный содержательный объём и допустимый технический путь, а «Содержательные направления» помогают команде распределить работу без назначения готовых персональных ролей. «Возможное продолжение» не входит в обязательную часть и высокой оценки не гарантирует.
+
+Общие [итоговые материалы](../project.md#итоговые-материалы-и-защита) и [шкала `ТР`, `Э` и `ВО`](../grading.md#материалы-проекта) действуют для всех заданий. Оценивается новое приращение относительно опубликованных кода, данных и результатов.

project-tasks/p01-remix.md

@@ -0,0 +1,29 @@
+# P01. Remix: спецификации разной гранулярности для проверки распределённых систем
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Lingzhi Ouyang и соавт. — [Multi-Grained Specifications for Distributed System Model Checking and Verification](https://tianyin.github.io/pub/mspec.pdf). EuroSys 2025, DOI `10.1145/3689031.3696069`.
+- **Кратко о статье:** Авторы проверяют ZooKeeper с помощью TLA+ и рассматривают конфликт между точностью модели и размером пространства состояний. Remix позволяет сочетать детальные спецификации целевых модулей с более грубыми спецификациями остальной системы и проверять соответствие модели коду. Подход помог обнаружить шесть серьёзных ошибок. В проекте сравниваются разные гранулярности спецификаций на сокращённых сценариях ZooKeeper.
+- **Почему результат актуален:** работа 2025 года проверяет развивающуюся производственную систему; исправления шести найденных ошибок были приняты в ZooKeeper. Локальный демонстрационный путь использует Java 11, Python 3 и Maven и не требует кластера или специализированного оборудования.
+- **Артефакты и данные:** [Lingzhi-Ouyang/Remix](https://github.com/Lingzhi-Ouyang/Remix) под Apache-2.0, с ZooKeeper 3.9.1, TLC, генерацией модельных трасс, проверкой соответствия и детерминированным воспроизведением; комитет EuroSys присвоил артефакту знаки Available и Functional. Зафиксированные ревизии: `Lingzhi-Ouyang/Remix@81869f1accc1` (Apache-2.0).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** смешанная гранулярность спецификации уменьшает стоимость model checking относительно полностью детальной модели и обнаруживает расхождения, которые теряются в полностью грубой модели.
+- **Технический результат:** Собрать воспроизводимый конвейер для трёх вариантов спецификации: генерация трасс в TLC, преобразование в формат проигрывателя, запуск на малой конфигурации ZooKeeper и автоматический отчёт о совпадениях и расхождениях. Все варианты должны использовать общие сценарии и одинаковые ограничения поиска.
+- **Эксперимент:** воспроизвести генерацию и проигрывание трасс для ZooKeeper, затем сравнить грубую, детальную и смешанную спецификации по числу состояний, времени проверки и найденным расхождениям на 2–3 сценариях.
+- **Границы выводов:** сравнение относится к выбранным сценариям ZooKeeper и ограничениям поиска TLC; оно не доказывает полноту спецификаций и не оценивает все возможные ошибки реализации.
+- **Ресурсный профиль:** локально, Linux, CPU, 8–16 ГБ памяти. Если полная генерация пространства состояний слишком долгая, использовать демонстрационные трассы и уменьшенную конфигурацию ZooKeeper, сохранив сравнение трёх вариантов спецификации и проверку соответствия.
+
+## Содержательные направления
+
+- спецификации и конфигурации TLC.
+- воспроизведение трасс и инструментирование ZooKeeper.
+- сравнение гранулярностей, контролируемые расхождения и анализ результатов.
+
+## Возможное продолжение
+
+Детализировать один дополнительный модуль или изменение ZooKeeper, внести контролируемое расхождение между моделью и кодом либо исследовать границу, после которой дополнительная детализация перестаёт окупаться.

project-tasks/p02-dupchecker.md

@@ -0,0 +1,29 @@
+# P02. DUPChecker: статическая проверка совместимости форматов при обновлении
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Yongle Zhang и соавт. — [Understanding and Detecting Software Upgrade Failures in Distributed Systems](https://yonglezh-purdue.github.io/files/sosp21-upgrade.pdf). SOSP 2021.
+- **Кратко о статье:** Авторы исследуют 123 сбоя при обновлении восьми распределённых систем и показывают, что многие из них возникают только при взаимодействии разных версий через хранилище или сетевые сообщения. На основе исследования созданы средство тестирования обновлений DUPTester и статические проверки форматов DUPChecker. В проекте воспроизводится именно проверка межверсионной совместимости форматов на небольших примерах.
+- **Почему результат актуален:** инструмент — снимок состояния на момент публикации, но проверяемые правила межверсионной совместимости сохраняют значение для современных систем. Полный авторский эксперимент рассчитан на 4 ГБ памяти и примерно час работы, а отдельная пара версий проверяется быстрее.
+- **Артефакты и данные:** [jwjwyoung/DUPChecker](https://github.com/jwjwyoung/DUPChecker) под MIT, с Python 3-инструментами, примерами для HBase и сценариями воспроизведения опубликованной таблицы; артефакт получил знаки Available, Functional и Results Reproduced на SOSP 2021. Зафиксированные ревизии: `jwjwyoung/DUPChecker@01ba1d490465` (MIT).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** статическая проверка изменений схем находит потенциальные межверсионные несовместимости, которые обычная проверка каждой версии по отдельности не обнаруживает.
+- **Технический результат:** Подготовить воспроизводимый анализатор зафиксированных пар выпусков для 2–3 открытых систем, реализовать простой синтаксический diff как baseline и собрать размеченный набор предупреждений с подтверждениями из истории изменений и тестов. Один сценарий должен запускать оба анализатора на одинаковых входах и формировать сопоставимый отчёт.
+- **Эксперимент:** выбрать 2–3 открытые системы, проверить несколько последовательных выпусков, вручную классифицировать предупреждения по истории изменений и тестам и сравнить DUPChecker с простым синтаксическим diff по точности и времени.
+- **Границы выводов:** оценки точности и времени относятся к выбранным системам, выпускам и размеченным предупреждениям; они не характеризуют все виды межверсионной несовместимости и другие форматы схем.
+- **Ресурсный профиль:** локально, CPU, 4–8 ГБ памяти. Если крупный репозиторий неудобно анализировать целиком, использовать зафиксированные пары выпусков и отдельно подготовленный набор совместимых и несовместимых изменений схем.
+
+## Содержательные направления
+
+- подбор выпусков и эталонная разметка.
+- запуск и расширение анализатора.
+- базовые методы, метрики, проверка предупреждений и анализ ошибок.
+
+## Возможное продолжение
+
+Уточнить одно правило для снижения ложных срабатываний, добавить поддержку ещё одного изменения схемы или сопоставить статические предупреждения с реальными тестами совместного чтения старой и новой версией.

project-tasks/p03-a-acto-state-search.md

@@ -0,0 +1,29 @@
+# P03-A. Acto: поиск состояний
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Jiawei Tyler Gu и соавт. — [Acto: Automatic End-to-End Testing for Operation Correctness of Cloud System Management](https://research.ibm.com/publications/acto-automatic-end-to-end-testing-for-operation-correctness-of-cloud-system-management). SOSP 2023.
+- **Кратко о статье:** Операторы Kubernetes должны многократно приводить управляемую систему к объявленному состоянию, поэтому отдельные тесты обработчиков не покрывают поведение длинных последовательностей операций. Acto представляет операции как переходы состояния, систематически строит их последовательности и проверяет фактическое состояние системы на соответствие требуемому. В проекте основной акцент сделан на стратегии поиска состояний и её преимуществе перед случайной генерацией.
+- **Почему результат актуален:** Acto продолжает развиваться и применён уже к одиннадцати операторам; [работа NSDI 2026 о надёжности операторов](https://www.usenix.org/conference/nsdi26/presentation/gu) подтверждает, что ошибки во взаимодействии оператора с управляемой системой остаются существенным классом отказов.
+- **Артефакты и данные:** [xlab-uiuc/acto](https://github.com/xlab-uiuc/acto) под Apache-2.0, с локальными режимами Kind, Minikube и K3d, воспроизводимыми ошибками и конфигурациями реальных операторов. При [проверке артефакта](https://sysartifacts.github.io/sosp2023/summaries/acto) подтверждены его доступность, работоспособность и воспроизведение результатов. Зафиксированные ревизии: `xlab-uiuc/acto@a0d0fb7bb840` (Apache-2.0).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** генерация последовательностей переходов и сквозная проверка состояния позволяют находить ошибки согласования, которые пропускают отдельные тесты обработчиков и случайная генерация операций.
+- **Технический результат:** Развернуть небольшой оператор и управляемую систему в Kind, подключить генератор переходов Acto и воспроизводимый случайный baseline. Добавить сбор покрытия переходов и автоматическую проверку достижения желаемого состояния.
+- **Эксперимент:** На одном операторе выполнить не менее трёх серий систематической и случайной генерации с одинаковым бюджетом. Сравнить покрытие переходов, число уникальных расхождений и время до первого сбоя; для найденного сбоя подтвердить воспроизводимость отдельным тестом.
+- **Границы выводов:** результат показывает покрытие и обнаружение сбоев для выбранного оператора, модели переходов и бюджета генерации; он не доказывает полноту поиска или корректность оператора во всех конфигурациях.
+- **Ресурсный профиль:** расширенно локально, Linux, Docker, Kind, CPU, желательно 16 ГБ памяти. Если выбранный оператор слишком тяжёл, использовать демонстрационную конфигурацию Cassandra либо собственный минимальный оператор с намеренно внесёнными ошибками согласования.
+
+## Содержательные направления
+
+- оператор и локальный стенд.
+- генератор переходов и стратегии обхода.
+- проверки состояния, уменьшение сбоев и сравнительный анализ.
+
+## Возможное продолжение
+
+Перенести Acto на новый оператор, добавить новый тип перехода или вид проверки, исследовать раннюю остановку либо автоматическое уменьшение ошибочной последовательности.

project-tasks/p03-b-acto-oracles-and-shrinking.md

@@ -0,0 +1,29 @@
+# P03-B. Acto: проверки и уменьшение
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Jiawei Tyler Gu и соавт. — [Acto: Automatic End-to-End Testing for Operation Correctness of Cloud System Management](https://research.ibm.com/publications/acto-automatic-end-to-end-testing-for-operation-correctness-of-cloud-system-management). SOSP 2023.
+- **Кратко о статье:** Операторы Kubernetes должны многократно приводить управляемую систему к объявленному состоянию, поэтому отдельные тесты обработчиков не покрывают поведение длинных последовательностей операций. Acto представляет операции как переходы состояния и автоматически проверяет, достигла ли система требуемого состояния. В проекте основной акцент сделан на качестве сквозных проверок состояния и уменьшении найденной последовательности до воспроизводимого объяснения сбоя.
+- **Почему результат актуален:** Acto продолжает развиваться и применён уже к одиннадцати операторам; [работа NSDI 2026 о надёжности операторов](https://www.usenix.org/conference/nsdi26/presentation/gu) подтверждает, что ошибки во взаимодействии оператора с управляемой системой остаются существенным классом отказов.
+- **Артефакты и данные:** [xlab-uiuc/acto](https://github.com/xlab-uiuc/acto) под Apache-2.0, с локальными режимами Kind, Minikube и K3d, воспроизводимыми ошибками и конфигурациями реальных операторов. При [проверке артефакта](https://sysartifacts.github.io/sosp2023/summaries/acto) подтверждены его доступность, работоспособность и воспроизведение результатов. Зафиксированная основная ревизия: `xlab-uiuc/acto@a0d0fb7bb840` (Apache-2.0).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** Сквозная проверка состояния и автоматическое уменьшение последовательности превращают сбой оператора в воспроизводимый диагноз; качество результата зависит от полноты наблюдаемого состояния и правил эквивалентности сценариев.
+- **Технический результат:** Развернуть небольшой оператор и управляемую систему в Kind. Реализовать две независимые проверки — достижения желаемого состояния и предметного инварианта — и средство уменьшения ошибочной последовательности с сохранением сбоя.
+- **Эксперимент:** На наборе не менее чем из пяти известных или намеренно внесённых ошибок сравнить исходные последовательности без уменьшения как baseline, удаление суффикса и структурное уменьшение. Измерить долю воспроизведённых сбоев, длину результата, число перезапусков, время и ложные срабатывания проверок.
+- **Границы выводов:** качество проверок и уменьшения оценивается на выбранных известных или намеренно внесённых ошибках; результат не определяет точность на неизвестных естественных сбоях и других операторах.
+- **Ресурсный профиль:** расширенно локально, Linux, Docker, Kind, CPU, желательно 16 ГБ памяти. Если выбранный оператор слишком тяжёл, использовать демонстрационную конфигурацию Cassandra либо собственный минимальный оператор с намеренно внесёнными ошибками согласования.
+
+## Содержательные направления
+
+- локальный оператор и набор ошибок.
+- проверки состояния и эталонная разметка.
+- алгоритмы уменьшения, повторные запуски и анализ ошибок.
+
+## Возможное продолжение
+
+Добавить причинно-зависимое уменьшение, новый вид проверки, восстановление после промежуточного сброса состояния или перенос на второй оператор.

project-tasks/p04-legolas.md

@@ -0,0 +1,29 @@
+# P04. Legolas: поиск ошибок частичных отказов по состояниям системы
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Haoze Wu и соавт. — [Efficient Exposure of Partial Failure Bugs in Distributed Systems with Inferred Abstract States](https://www.usenix.org/conference/nsdi24/presentation/wu-haoze). NSDI 2024.
+- **Кратко о статье:** Ошибки частичных отказов часто проявляются только при редком сочетании внутреннего состояния системы, места сбоя и момента инъекции. Legolas статически анализирует код, выводит абстрактные состояния и использует их для выбора более содержательных точек отказа. Авторы применили систему к шести распределённым системам и нашли 20 новых ошибок. Проект сравнивает управляемую состояниями и случайную инъекцию при одинаковом бюджете запусков.
+- **Почему результат актуален:** репозиторий поддерживает локальную сборку Maven на обычном Linux-стенде; задача управляемой инъекции отказов сохраняется при переходе к новым версиям систем, поскольку проект сравнивает стратегии исследования состояний независимо от фиксированного набора найденных ошибок.
+- **Артефакты и данные:** [OrderLab/Legolas](https://github.com/OrderLab/Legolas) под Apache-2.0, со статическим анализатором, инструментированием Java-кода, оркестратором экспериментов и примерами для ZooKeeper. Зафиксированные ревизии: `OrderLab/Legolas@84278d313f98` (Apache-2.0).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** выбор точек отказа по выведенным состояниям быстрее и стабильнее обнаруживает ошибки частичных отказов, чем случайная инъекция при том же бюджете запусков.
+- **Технический результат:** Развернуть малую конфигурацию ZooKeeper, инструментировать её средствами Legolas и реализовать два режима инъекции — случайный и управляемый состояниями. Общий исполнитель должен фиксировать состояние, место инъекции и исход запуска, определять сбой по явному критерию и объединять повторения одного дефекта.
+- **Эксперимент:** на малой конфигурации ZooKeeper воспроизвести один опубликованный сценарий, затем сравнить случайную и управляемую состояниями инъекцию по времени до первого сбоя, числу уникальных сбоев и доле полезных запусков.
+- **Границы выводов:** преимущество стратегии инъекции проверяется на малой конфигурации ZooKeeper и выбранном наборе классов и исключений; оно не означает полного покрытия дефектов или той же эффективности на производственном кластере.
+- **Ресурсный профиль:** расширенно локально, Linux, Java, Maven, CPU, желательно 16 ГБ памяти. Если полный анализ выбранной системы слишком тяжёл, использовать ZooKeeper и ограниченный набор классов и исключений, сохранив сравнение стратегий.
+
+## Содержательные направления
+
+- сборка и инструментирование системы.
+- оркестрация отказов и критерии сбоев.
+- стратегии выбора состояний, статистика и перенос на новый сценарий.
+
+## Возможное продолжение
+
+Перенести сокращённый конвейер на другую Java-систему, улучшить группировку состояний или предложить стратегию выбора точек, учитывающую историю предыдущих запусков.

project-tasks/p05-sieve.md

@@ -0,0 +1,29 @@
+# P05. SIEVE: простая политика вытеснения веб-кэша
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Yazhuo Zhang и соавт. — [SIEVE is Simpler than LRU: an Efficient Turn-Key Eviction Algorithm for Web Caches](https://www.usenix.org/system/files/nsdi24-zhang-yazhuo.pdf). NSDI 2024.
+- **Кратко о статье:** Политика вытеснения веб-кэша должна одновременно давать хорошую долю попаданий и допускать дешёвую конкурентную реализацию. SIEVE использует однобитную отметку востребованности и последовательный указатель вытеснения, поэтому попадания не требуют перестройки общей структуры. Авторы показывают, что простая политика конкурентоспособна с более сложными алгоритмами. Проект проверяет этот результат на нескольких трассах и размерах кэша.
+- **Почему результат актуален:** авторы предлагают очень простую политику вытеснения SIEVE и показывают на веб-трассах, что она часто сочетает высокую скорость с хорошей долей попаданий.
+- **Артефакты и данные:** [cacheMon/NSDI24-SIEVE](https://github.com/cacheMon/NSDI24-SIEVE) с симулятором, прототипами и открытыми трассами. Зафиксированные ревизии: `cacheMon/NSDI24-SIEVE@0861f8261c37` (Apache-2.0).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** очень простая политика SIEVE может одновременно давать высокую пропускную способность и меньшую долю промахов, чем существенно более сложные политики, но результат зависит от следа и размера кэша.
+- **Технический результат:** Независимо реализовать SIEVE, LRU и ещё одну сильную политику в общем симуляторе кэша. Симулятор должен читать одинаковый формат трасс, проверять инварианты ёмкости и учёта запросов и формировать сопоставимую статистику попаданий, вытеснений и служебных операций.
+- **Эксперимент:** на нескольких открытых трассах сравнить SIEVE, LRU и ещё одну сильную политику по доле промахов и служебным операциям, воспроизвести часть результатов статьи и проверить чувствительность к размеру кэша.
+- **Границы выводов:** сравнение характеризует долю попаданий и алгоритмические накладные расходы на выбранных трассах и размерах кэша; без работающего сервера оно не подтверждает производственную пропускную способность и цену синхронизации.
+- **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти; можно использовать подвыборки трасс с проверкой устойчивости выводов.
+
+## Содержательные направления
+
+- реализации политик.
+- подготовка трасс и стенда.
+- анализ режимов, визуализация и дополнительные гипотезы.
+
+## Возможное продолжение
+
+Искать классы нагрузок, на которых SIEVE проигрывает, исследовать влияние размера объектов или предложить небольшую модификацию без заметного усложнения.

project-tasks/p06-superbench.md

@@ -0,0 +1,29 @@
+# P06. SuperBench: упреждающая проверка вычислительной инфраструктуры
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Yifan Xiong и соавт. — [SuperBench: Improving Cloud AI Infrastructure Reliability with Proactive Validation](https://www.usenix.org/system/files/atc24-xiong.pdf). USENIX ATC 2024, Best Paper.
+- **Кратко о статье:** В крупных кластерах для задач ИИ отдельные компоненты могут деградировать, не вызывая явного отказа, но заметно замедляя распределённые задания. SuperBench объединяет направленные микротесты и проверки на разных этапах жизненного цикла инфраструктуры, чтобы заранее находить такие узлы и локализовать причину. В проекте строится доступный CPU-аналог этого подхода и сравниваются стратегии выбора проверок.
+- **Почему результат актуален:** SuperBench запускает короткие целевые тесты оборудования и коммуникаций до выдачи ресурсов ИИ-задачам, чтобы заранее исключать деградировавшие узлы из кластера.
+- **Артефакты и данные:** [microsoft/superbenchmark](https://github.com/microsoft/superbenchmark) с CPU- и GPU-тестами, профилями и документацией. Зафиксированные ревизии: `microsoft/superbenchmark@2e2c52b80f4e` (MIT).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** набор направленных микротестов и обоснованный выбор их поднабора выявляют заданные виды скрытой деградации с меньшей стоимостью, чем неизбирательный запуск всех проверок.
+- **Технический результат:** Собрать CPU-набор проверок вычислений, памяти, диска и сети с управляемыми режимами деградации, единым сбором результатов и простым алгоритмом выбора поднабора тестов. Стенд должен автоматически подтверждать, что нормальный и деградированный режимы действительно различаются по заданным признакам.
+- **Эксперимент:** на CPU построить несколько воспроизводимых режимов деградации, сравнить отдельные тесты и проверить простой алгоритм выбора поднабора проверок; при временном доступе к одной GPU можно добавить отдельную необязательную серию.
+- **Границы выводов:** стенд проверяет различимость заданных CPU-, memory-, disk- и network-деградаций и качество отбора тестов; он не подтверждает диагностику GPU-сбоев или предсказание отказов крупного производственного кластера.
+- **Ресурсный профиль:** локально, CPU, сеть, диск и 8–16 ГБ памяти; GPU не требуется. Обязательная часть проверяет сам механизм отбора и не переносит выводы на крупный AI-кластер.
+
+## Содержательные направления
+
+- сценарии деградации.
+- интеграция тестов и сбор метрик.
+- алгоритм выбора и оценка качества обнаружения.
+
+## Возможное продолжение
+
+Учитывать стоимость ложных тревог и пропусков, добавить дрейф производительности или сравнить статический и адаптивный графики проверок.

project-tasks/p07-a-deathstarbench-tail-latency.md

@@ -0,0 +1,29 @@
+# P07-A. DeathStarBench: хвостовая задержка
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Yu Gan и соавт. — [An Open-Source Benchmark Suite for Microservices and Their Hardware-Software Implications for Cloud & Edge Systems](https://ygan397.github.io/publication/2019.asplos.deathstarbench/2019.asplos.deathstarbench.pdf). ASPLOS 2019.
+- **Кратко о статье:** DeathStarBench — открытый набор сквозных приложений, представляющих типичные графы облачных и edge-микросервисов. Авторы показывают, что зависимости между сервисами, программный стек и совместное использование ресурсов создают узкие места, которые не видны в изолированном микротесте. В этом проекте исследуется распространение задержки по графу и поведение её хвостовых квантилей.
+- **Почему результат актуален:** набор нагрузок продолжает использоваться как открытый стенд для исследований микросервисов. Конкретные зависимости отдельных приложений могут устаревать, поэтому перед проектом фиксируется собираемая версия. Выводы ограничиваются исследуемым графом сервисов и не распространяются на весь современный облачный стек.
+- **Артефакты и данные:** [delimitrou/DeathStarBench](https://github.com/delimitrou/DeathStarBench) под Apache-2.0, с несколькими приложениями, контейнерами и генераторами нагрузки. Зафиксированные ревизии: `delimitrou/DeathStarBench@6ecb09706140` (Apache-2.0).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** при приближении графа микросервисов к насыщению хвостовая задержка растёт заметнее средней, а трассировка критического пути позволяет локализовать сервис, причинно влияющий на этот рост.
+- **Технический результат:** Развернуть сокращённый сквозной граф Hotel Reservation или Social Network, добавить генератор нагрузки, трассировку запросов и сбор метрик по каждому сервису.
+- **Эксперимент:** Провести ступенчатую нагрузку от ненасыщенного режима до перегрузки не менее чем в трёх сериях. Сопоставить медиану, p95/p99, очереди и загрузку ресурсов; локализовать хотя бы одно узкое место и подтвердить причинность контролируемым изменением его ресурса.
+- **Границы выводов:** причинный анализ относится к выбранному сокращённому графу сервисов, нагрузке и локальным ограничениям ресурсов; он не воспроизводит хвостовые задержки полной производственной конфигурации DeathStarBench.
+- **Ресурсный профиль:** расширенно локально, Docker, CPU, желательно 16–32 ГБ памяти. Запасной вариант — оставить один опубликованный сервис и уменьшить число реплик, сохранив сквозной граф вызовов.
+
+## Содержательные направления
+
+- развёртывание и наблюдаемость.
+- генератор нагрузки и контролируемые воздействия.
+- анализ хвостов, причин и альтернативных конфигураций.
+
+## Возможное продолжение
+
+Сравнить две схемы размещения, ограничение одного ресурса, кэширование либо политику перегрузки и проверить перенос вывода между двумя графами вызовов.

project-tasks/p07-b-deathstarbench-placement.md

@@ -0,0 +1,29 @@
+# P07-B. DeathStarBench: размещение и интерференция
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Yu Gan и соавт. — [An Open-Source Benchmark Suite for Microservices and Their Hardware-Software Implications for Cloud & Edge Systems](https://ygan397.github.io/publication/2019.asplos.deathstarbench/2019.asplos.deathstarbench.pdf). ASPLOS 2019.
+- **Кратко о статье:** DeathStarBench — открытый набор сквозных приложений, представляющих типичные графы облачных и edge-микросервисов. Поведение приложения зависит от отдельных сервисов, их взаимодействия с аппаратными ресурсами и программным стеком. В этом проекте исследуется, как размещение сервисов и фоновая конкуренция меняют сквозную хвостовую задержку.
+- **Почему результат актуален:** набор нагрузок продолжает использоваться как открытый стенд для исследований микросервисов. Конкретные зависимости отдельных приложений могут устаревать, поэтому перед проектом фиксируется собираемая версия. Выводы ограничиваются исследуемым графом сервисов и не распространяются на весь современный облачный стек.
+- **Артефакты и данные:** [delimitrou/DeathStarBench](https://github.com/delimitrou/DeathStarBench) под Apache-2.0, с несколькими приложениями, контейнерами и генераторами нагрузки. Зафиксированная основная ревизия: `delimitrou/DeathStarBench@6ecb09706140` (Apache-2.0).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** Совместное размещение и фоновая конкуренция меняют хвостовую задержку сквозного запроса в зависимости от структуры графа; равномерное распределение CPU не всегда даёт лучший результат.
+- **Технический результат:** Развернуть один сокращённый сквозной граф DeathStarBench, добавить управляемое размещение контейнеров, фоновую CPU- и memory-нагрузку и трассировку критического пути.
+- **Эксперимент:** Сравнить изолированное и случайное размещение как baselines с размещением, учитывающим граф, при двух уровнях нагрузки и двух видах интерференции. Выполнить не менее трёх серий; измерить throughput, p50/p95/p99, длины очередей, загрузку ресурсов и вклад сервисов в критический путь.
+- **Границы выводов:** эффект размещения и интерференции проверяется на одном сокращённом графе и доступных локальных узлах; результат не оценивает качество полноценного кластерного планировщика и переносимость политики на производственную топологию.
+- **Ресурсный профиль:** расширенно локально, Docker, CPU, желательно 16–32 ГБ памяти. Запасной вариант — оставить один опубликованный сервис и уменьшить число реплик, сохранив сквозной граф вызовов.
+
+## Содержательные направления
+
+- развёртывание и управление размещением.
+- генератор нагрузки, интерференция и наблюдаемость.
+- политика размещения, повторные серии и причинный анализ.
+
+## Возможное продолжение
+
+Добавить сетевую интерференцию, динамическое перемещение одного сервиса, ограничение мощности либо проверить перенос политики на второй граф вызовов.

project-tasks/p08-pgval.md

@@ -0,0 +1,29 @@
+# P08. PGVal: сквозная проверка гарантий потоковой обработки
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Jawad Tahir и соавт. — [How Reliable Are Streams? End-to-End Processing-Guarantee Validation and Performance Benchmarking of Stream Processing Systems](https://www.vldb.org/pvldb/vol18/p585-tahir.pdf). PVLDB 2024.
+- **Кратко о статье:** Заявленная системой гарантия обработки потока ещё не доказывает, что входные события дали правильный сквозной результат при сбое. PGVal сопоставляет выход с независимо рассчитанным ожидаемым результатом, вводит процессные и сетевые отказы и измеряет надёжность, надёжную пропускную способность и стоимость отказа. Авторы показывают зависимость результата от топологии, разбиения и параллелизма. Проект воспроизводит такую проверку для одной потоковой системы.
+- **Почему результат актуален:** Flink и Kafka Streams активно развиваются, а сквозная гарантия по-прежнему зависит от источника, приёмника, топологии и конфигурации. Модульный расчёт ожидаемого результата и модель отказов позволяют проверять современные версии систем и новые операторы вместо буквального повторения снимка 2024 года.
+- **Артефакты и данные:** [jawadtahir/DSPF-BM](https://github.com/jawadtahir/DSPF-BM) под Apache-2.0, с Docker-развёртыванием Kafka Streams, Apache Storm и Apache Flink, генератором данных, модулем независимого расчёта ожидаемого результата и инъекцией отказов. Зафиксированные ревизии: `jawadtahir/DSPF-BM@d74c9b80a3a1` (Apache-2.0).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** заявленной гарантии обработки недостаточно для правильного сквозного результата: надёжность существенно меняется с топологией, разбиением данных, параллелизмом и типом отказа.
+- **Технический результат:** Развернуть локальные Kafka и одну потоковую систему, реализовать воспроизводимый источник, оконную топологию, независимый расчёт ожидаемого результата и управляемую инъекцию отказов. Один сценарий должен запускать нагрузку, вводить выбранный отказ, собирать выход и автоматически сравнивать его с эталоном.
+- **Эксперимент:** на подготовленном стенде сравнить обычный режим, перезапуск процесса и сетевую задержку по доле правильных результатов, надёжной пропускной способности, задержке и времени восстановления.
+- **Границы выводов:** сквозная гарантия проверяется для одной потоковой системы, выбранной топологии и заданных отказов; выводы не распространяются на все операторы, конфигурации и крупные кластеры поддерживаемых систем.
+- **Ресурсный профиль:** расширенно локально, Docker, CPU, желательно 16 ГБ памяти. Если полный PGVal требует слишком много процессов, сохранить Kafka, одну систему, эталонную проверку результата и два вида отказов на одном компьютере.
+
+## Содержательные направления
+
+- нагрузка и эталонная проверка результата.
+- потоковая топология и инъекция отказов.
+- метрики корректности, повторные запуски и исследование новой конфигурации.
+
+## Возможное продолжение
+
+Добавить соединение двух потоков, другой приёмник, поздние события, изменение числа разделов либо вторую систему и проверить переносимость выводов статьи.

project-tasks/p09-a-foundationdb-transactions.md

@@ -0,0 +1,29 @@
+# P09-A. FoundationDB: транзакции и отказы
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** FoundationDB Team — [FoundationDB: A Distributed Unbundled Transactional Key Value Store](https://www.foundationdb.org/files/fdb-paper.pdf). SIGMOD 2021.
+- **Кратко о статье:** FoundationDB строит распределённую базу вокруг небольшого строго упорядоченного транзакционного ядра, отделяя обработку транзакций, журналирование и хранение данных. Более сложные модели данных реализуются слоями поверх упорядоченного key-value-интерфейса, а архитектура рассчитана на заменяемость внутренних ролей и восстановление после отказов. В этом проекте проверяются транзакционная семантика и поведение сокращённой конфигурации при сбоях.
+- **Почему результат актуален:** статья описывает архитектуру FoundationDB: небольшое транзакционное ядро, разделение ролей хранения и обработки и детерминированную имитацию отказов для проверки системы.
+- **Артефакты и данные:** [apple/foundationdb](https://github.com/apple/foundationdb), открытая система с локальным многопроцессным режимом и детерминированными simulation tests. Зафиксированные ревизии: `apple/foundationdb@ddec61a629a9` (Apache-2.0).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** FoundationDB сохраняет сериализуемость и подтверждённые записи при конфликтующих транзакциях и отказе процесса, хотя рост конфликтности увеличивает число повторов и хвостовую задержку.
+- **Технический результат:** Развернуть малый многопроцессный кластер FoundationDB и реализовать повторяемую нагрузку с конфликтующими транзакциями, журналом исходов и проверкой сериализуемости.
+- **Эксперимент:** Сравнить не менее трёх уровней конфликтности в штатном режиме и при одном управляемом отказе процесса. Измерить долю конфликтов и повторов, пропускную способность, p95/p99 и время восстановления; отдельно проверить отсутствие потерянных подтверждённых записей.
+- **Границы выводов:** проверяются сериализуемость, конфликты и восстановление для выбранной нагрузки и одного отказа в малом кластере; эксперимент не подтверждает производительность и отказоустойчивость FoundationDB в производственном масштабе.
+- **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти. Сборка всей системы может быть долгой; запасной вариант — использовать готовый выпуск для реального эксперимента и исходный код только для simulation tests.
+
+## Содержательные направления
+
+- транзакционная нагрузка.
+- отказы и имитация.
+- слой или исследование параметров и анализ семантики.
+
+## Возможное продолжение
+
+Реализовать небольшой слой поверх упорядоченного KV-интерфейса либо систематически исследовать влияние размера транзакции, конфликтности или размещения ролей.

project-tasks/p09-b-foundationdb-simulation.md

@@ -0,0 +1,29 @@
+# P09-B. FoundationDB: детерминированная имитация
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** FoundationDB Team — [FoundationDB: A Distributed Unbundled Transactional Key Value Store](https://www.foundationdb.org/files/fdb-paper.pdf). SIGMOD 2021.
+- **Кратко о статье:** FoundationDB сочетает рабочую распределённую базу с детерминированной имитацией, в которой тот же код выполняется под управляемым временем, сетью и инъекцией отказов. Фиксация начального зерна позволяет точно повторять редкие последовательности событий и отлаживать нарушения инвариантов. В этом проекте воспроизводится принцип детерминированного планирования и сравнивается повторяемость диагностики с обычным многопроцессным запуском.
+- **Почему результат актуален:** статья описывает архитектуру FoundationDB: небольшое транзакционное ядро, разделение ролей хранения и обработки и детерминированную имитацию отказов для проверки системы.
+- **Артефакты и данные:** [apple/foundationdb](https://github.com/apple/foundationdb), открытая система с локальным многопроцессным режимом и детерминированными simulation tests. Зафиксированная основная ревизия: `apple/foundationdb@ddec61a629a9` (Apache-2.0).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** Детерминированная имитация позволяет систематически проверять последовательности отказов и точно воспроизводить редкие нарушения, которые трудно диагностировать в обычном многопроцессном запуске.
+- **Технический результат:** Собрать или использовать зафиксированный simulation-режим FoundationDB, подготовить малую нагрузку, один проверяемый инвариант и сценарии отказов, управляемые seed. Добавить автоматическое повторное проигрывание найденной трассы.
+- **Эксперимент:** Сравнить обычный локальный fault-injection и детерминированную имитацию по числу исследованных сценариев, времени до обнаружения, доле точных повторов и размеру диагностической трассы. Обязательны несколько seed, два вида отказа и намеренно внесённое либо уже известное нарушение.
+- **Границы выводов:** сравнение характеризует воспроизводимость и исследованное пространство для выбранной нагрузки, инварианта и видов отказа; оно не доказывает корректность FoundationDB и не оценивает частоту таких сбоев в эксплуатации.
+- **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти. Сборка всей системы может быть долгой; запасной вариант — использовать готовый выпуск для реального эксперимента и исходный код только для simulation tests.
+
+## Содержательные направления
+
+- имитационный стенд и нагрузка.
+- инварианты, отказы и воспроизведение.
+- базовые варианты, покрытие, уменьшение трасс и анализ.
+
+## Возможное продолжение
+
+Уменьшать трассу, добавить новый инвариант или отказ, направлять выбор seed по покрытию либо сопоставить simulation trace с реальным локальным кластером.

project-tasks/p10-detock.md

@@ -0,0 +1,29 @@
+# P10. Detock: транзакции между регионами без глобального упорядочивания
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Cuong D. T. Nguyen, Johann K. Miller и Daniel J. Abadi — [Detock: High Performance Multi-region Transactions at Scale](https://drum.lib.umd.edu/items/8c710897-0b8c-4693-9041-e75209e792d7). SIGMOD 2023.
+- **Кратко о статье:** Межрегиональные транзакции затрагивают несколько первичных регионов и при высокой конфликтности приводят либо к частым откатам, либо к распределённым взаимоблокировкам. Detock предлагает протоколы управления конкурентностью и детерминированного разрешения взаимоблокировок, сохраняя строгую сериализуемость без глобального упорядочивания всех операций. Проект проверяет этот механизм на сокращённой реализации или дискретно-событийной модели.
+- **Почему результат актуален:** код собирается на обычном Linux-стеке и допускает локальный функциональный запуск; вопрос о цене межрегиональной координации и конфликтов остаётся центральным для геораспределённых транзакционных систем.
+- **Артефакты и данные:** [umd-dslam/Detock](https://github.com/umd-dslam/Detock) под MIT, с C++-реализацией, однопроцессной конфигурацией, многорегиональным стендом и отдельными данными экспериментов. Зафиксированные ревизии: `umd-dslam/Detock@9f75dbdf93b6` (MIT).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** графовое управление зависимостями и детерминированное разрешение взаимоблокировок сохраняют строгую сериализуемость и уменьшают потери при высокой конфликтности по сравнению с глобальным упорядочиванием или откатами по тайм-ауту.
+- **Технический результат:** Запустить сокращённую конфигурацию Detock в нескольких локальных процессах либо независимо реализовать его дискретно-событийную модель. Добавить реализации глобального порядка и простой стратегии отката, общий генератор транзакций и автоматическую проверку допустимости и сериализуемости по журналу.
+- **Эксперимент:** при выбранном техническом пути сравнить Detock с глобальным порядком и простой стратегией отката, варьируя конфликтность и межрегиональную задержку и контролируя сериализуемость всех результатов.
+- **Границы выводов:** сериализуемость и относительная эффективность проверяются для выбранной модели транзакций, конфликтности и межрегиональной задержки; локальный стенд или модель не подтверждают производительность Detock в реальной глобальной сети.
+- **Ресурсный профиль:** расширенно локально или имитация, Linux, C++, CPU, желательно 16 ГБ памяти. Исходная оценка использует несколько физических узлов; обязательный результат допускает несколько локальных процессов или независимую модель с проверкой сериализуемости по журналу.
+
+## Содержательные направления
+
+- сборка и модель транзакций.
+- алгоритмы зависимостей, взаимоблокировок и проверка сериализуемости.
+- нагрузки, сетевая модель и статистический анализ.
+
+## Возможное продолжение
+
+Исследовать перекос ключей, долю межрегиональных транзакций, хвостовую задержку, миграцию данных либо гибридную стратегию для разных уровней конфликтности.

project-tasks/p11-clay-codes.md

@@ -0,0 +1,29 @@
+# P11. Clay Codes: восстановление данных с меньшим сетевым обменом
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Myna Vajha и соавт. — [Clay Codes: Moulding MDS Codes to Yield an MSR Code](https://www.usenix.org/conference/fast18/presentation/vajha). FAST 2018.
+- **Кратко о статье:** Обычные MDS-коды экономно хранят данные, но восстановление потерянного узла может потребовать чтения и передачи большого объёма фрагментов. Clay Codes строят minimum-storage regenerating code, который сохраняет MDS-свойство и сокращает объём данных, загружаемых от вспомогательных узлов. В проекте Clay сравнивается с Reed–Solomon по трафику, вычислениям и полному времени восстановления.
+- **Почему результат актуален:** [Ceph планирует прекратить поддержку плагина CLAY](https://ceph.io/en/news/blog/2025/ending-support-for-ec-plugins/) в будущем выпуске V, но открытая переносимая реализация позволяет прямо проверить механизм. [Современные работы о векторных кодах](https://www.usenix.org/conference/osdi26/presentation/cai) по-прежнему исследуют тот же обмен между сетевым трафиком, вычислениями и дробностью данных.
+- **Артефакты и данные:** независимая библиотека [spool-labs/clay](https://github.com/spool-labs/clay) под Apache-2.0 реализует Clay Codes и коды Рида — Соломона на Rust, содержит тесты и измерения производительности на CPU. Зафиксированные ревизии: `spool-labs/clay@aa6a1f986866` (Apache-2.0).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** Clay уменьшает объём чтения и сетевой передачи при восстановлении, но выигрывает по полному времени только в режимах, где экономия ввода-вывода превышает дополнительные вычисления и накладные расходы разбиения.
+- **Технический результат:** Создать CPU-стенд, который кодирует одни и те же данные кодами Clay и Рида — Соломона, удаляет один фрагмент и восстанавливает его. Стенд должен автоматически проверять побайтовое равенство результата и учитывать объём чтения и передачи, процессорное и полное время.
+- **Эксперимент:** на одной CPU-машине сравнить Clay и Reed–Solomon при разных параметрах кода, размерах блоков и числе помощников; проверить восстановление одного узла и измерить прочитанные и переданные байты, процессорное и полное время.
+- **Границы выводов:** стенд проверяет корректность восстановления и объём чтения и передачи для выбранных параметров кода; модель сети на одной машине не воспроизводит полное время ремонта в распределённом хранилище с реальными дисками и сетью.
+- **Ресурсный профиль:** локально, Rust, CPU, 8–16 ГБ памяти. Сеть моделируется ограничением пропускной способности или задержкой; при проблемах с библиотекой обязательная часть использует независимый малый кодировщик и аналитически проверяемый объём восстановления.
+
+## Содержательные направления
+
+- корректность кодирования и восстановления.
+- стенд и базовые реализации.
+- модель сети, измерения и поиск границы выигрыша.
+
+## Возможное продолжение
+
+Найти границу выигрыша при ограничении сети, исследовать неоднородных помощников, несколько отказов, выбор размера фрагмента либо адаптивный выбор кода по наблюдаемой цене CPU и сети.

project-tasks/p12-a-clickhouse-data-skipping.md

@@ -0,0 +1,29 @@
+# P12-A. ClickHouse: отсечение данных
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Robert Schulze и соавт. — [ClickHouse — Lightning Fast Analytics for Everyone](https://www.vldb.org/pvldb/vol17/p3731-schulze.pdf). VLDB 2024.
+- **Кратко о статье:** Статья описывает архитектуру ClickHouse — столбцовой аналитической СУБД, рассчитанной на быстрое выполнение запросов над большими объёмами данных. Производительность обеспечивают совместно порядок хранения, разреженный первичный индекс, пропуск ненужных гранул, сжатие и векторизованное выполнение. В этом проекте изолируется вклад порядка данных и отсечения гранул при разной селективности запросов.
+- **Почему результат актуален:** статья описывает устройство открытой аналитической СУБД ClickHouse: столбцовое хранение, фоновые слияния частей, векторизованный конвейер исполнения запросов и отсечение ненужных данных.
+- **Артефакты и данные:** [ClickHouse/ClickHouse](https://github.com/ClickHouse/ClickHouse) под Apache-2.0 и [ClickHouse/ClickBench](https://github.com/ClickHouse/ClickBench) с воспроизводимой аналитической нагрузкой и конфигурациями разных СУБД. Зафиксированные ревизии: `ClickHouse/ClickHouse@2da63c1b42ca` (Apache-2.0); `ClickHouse/ClickBench@fa52f8524ad9` (CC BY-NC-SA 4.0; лицензии отдельных входных наборов проверяются отдельно).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** порядок данных и пропуск ненужных гранул дают измеримый выигрыш для аналитических запросов, когда фильтр согласован с физической организацией таблицы.
+- **Технический результат:** Развернуть ClickHouse и подготовить уменьшенный ClickBench с двумя физическими вариантами одной таблицы, различающимися ключом сортировки и размером гранул.
+- **Эксперимент:** Для не менее чем пяти запросов сравнить варианты хранения по прочитанным строкам и байтам, времени, CPU и памяти. Выполнить прогрев и не менее трёх измеряемых повторов; объяснить результат через `EXPLAIN` и системные таблицы.
+- **Границы выводов:** эффект отсечения данных оценивается для выбранных ключей сортировки, размеров гранул и запросов уменьшенного ClickBench; он не характеризует все оптимизации ClickHouse и производительность распределённого кластера.
+- **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти, готовый бинарный выпуск или контейнер. Полный ClickBench не требуется: объём данных и набор запросов сокращаются с проверкой того, что выбранные режимы остаются различимы.
+
+## Содержательные направления
+
+- данные, схема и варианты хранения.
+- планы и измерения исполнения.
+- распределённый режим или дополнительная оптимизация и анализ результатов.
+
+## Возможное продолжение
+
+Добавить реплицированный двухузловой стенд, сравнить локальный и распределённый запрос, исследовать компрессию, проекции, пропускную способность загрузки либо сопоставимый столбцовый baseline.

project-tasks/p12-b-clickhouse-vectorized-pipeline.md

@@ -0,0 +1,29 @@
+# P12-B. ClickHouse: векторизованный конвейер
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Robert Schulze и соавт. — [ClickHouse — Lightning Fast Analytics for Everyone](https://www.vldb.org/pvldb/vol17/p3731-schulze.pdf). VLDB 2024.
+- **Кратко о статье:** Статья описывает архитектуру ClickHouse — столбцовой аналитической СУБД, которая обрабатывает данные блоками и строит параллельный конвейер операторов. Блочная обработка уменьшает накладные расходы на отдельную строку и лучше использует процессор, память и сжатое представление столбцов. В этом проекте исследуется вклад блочной векторизации и выбор размера блока.
+- **Почему результат актуален:** статья описывает устройство открытой аналитической СУБД ClickHouse: столбцовое хранение, фоновые слияния частей, векторизованный конвейер исполнения запросов и отсечение ненужных данных.
+- **Артефакты и данные:** [ClickHouse/ClickHouse](https://github.com/ClickHouse/ClickHouse) под Apache-2.0 и [ClickHouse/ClickBench](https://github.com/ClickHouse/ClickBench) с воспроизводимой аналитической нагрузкой и конфигурациями разных СУБД. Зафиксированные ревизии: `ClickHouse/ClickHouse@2da63c1b42ca` (Apache-2.0); `ClickHouse/ClickBench@fa52f8524ad9` (CC BY-NC-SA 4.0; лицензии отдельных входных наборов проверяются отдельно).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** Блочная обработка столбцов уменьшает накладные расходы на строку, но выигрыш зависит от селективности, сложности выражения и размера блока.
+- **Технический результат:** Реализовать эквивалентные row-at-a-time и блочный конвейеры scan–filter–project–aggregate над одним столбцовым набором данных. Проверять результаты обоих вариантов по эталонному запросу ClickHouse.
+- **Эксперимент:** Варьировать размер блока, селективность и вычислительную стоимость выражения. Сравнить построчный baseline и блочный конвейер по времени, throughput, CPU, аллокациям и памяти после прогрева минимум в трёх сериях; отдельно сопоставить тренд с профилем эквивалентного запроса ClickHouse.
+- **Границы выводов:** сравнение относится к самостоятельно реализованному конвейеру и выбранному профилю ClickHouse; оно не измеряет вклад векторизации внутри полного движка и не подтверждает производительность распределённых запросов.
+- **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти, готовый бинарный выпуск или контейнер. Полный ClickBench не требуется: объём данных и набор запросов сокращаются с проверкой того, что выбранные режимы остаются различимы.
+
+## Содержательные направления
+
+- эталон и генератор данных.
+- два исполнительных конвейера и проверка эквивалентности.
+- профилирование, серии параметров и анализ границы выигрыша.
+
+## Возможное продолжение
+
+Добавить сжатие, строковые операции, многопоточность, векторизацию SIMD или исследовать режим, где большой блок ухудшает локальность и задержку.

project-tasks/p13-noria.md

@@ -0,0 +1,29 @@
+# P13. Noria: частично материализованный потоковый граф для веб-приложений
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Jon Gjengset и соавт. — [Noria: Dynamic, Partially-Stateful Data-Flow for High-Performance Web Applications](https://www.usenix.org/conference/osdi18/presentation/gjengset). OSDI 2018.
+- **Кратко о статье:** Веб-приложениям нужны быстрые чтения производных представлений, но полная материализация всех результатов требует много памяти и усложняет обновления. Noria превращает запросы в потоковый граф, поддерживает результаты инкрементально и хранит состояние только там, где оно нужно текущим чтениям. В проекте сравниваются полная, частичная и отсутствующая материализация на изменяющейся нагрузке.
+- **Почему результат актуален:** исходный Noria больше не развивается, однако его практическим преемником стал [ReadySet](https://github.com/readysettech/readyset), продолжающий идею инкрементально поддерживаемого кэша SQL-запросов. У ReadySet действует Business Source License 1.1 с переходом указанной версии в открытую лицензию через четыре года; условия нужно проверить перед заимствованием кода.
+- **Артефакты и данные:** [mit-pdos/noria](https://github.com/mit-pdos/noria) под MIT/Apache-2.0, с сервером, встраиваемым примером, MySQL-интерфейсом и нагрузкой `vote` из статьи. Зафиксированные ревизии: `mit-pdos/noria@465184ee4b57` (MIT/Apache-2.0).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** частичная материализация позволяет сохранить быстрые чтения и инкрементальные обновления, расходуя меньше памяти, чем полная материализация результатов всех запросов.
+- **Технический результат:** Подготовить в Noria или собственном малом потоковом прототипе общий граф операторов с тремя режимами: без материализации, с полной и с частичной материализацией. Реализовать одинаковый генератор обновлений и чтений, автоматическую проверку эквивалентности результатов и учёт занятого и восстановленного состояния.
+- **Эксперимент:** на локальном стенде или в собственном малом dataflow-прототипе сравнить отсутствие материализации, полную и частичную материализацию для read-heavy нагрузки; измерять задержку чтений и записей, память и стоимость восстановления вытесненного состояния.
+- **Границы выводов:** компромисс памяти и задержки проверяется на выбранном графе операторов и read-heavy-нагрузке; собственный прототип не подтверждает производительность полной реализации Noria и других классов запросов.
+- **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти. Исследовательский код использует старое Rust-окружение; если его сборка блокирует проект, команда независимо реализует ограниченный граф операторов и проверяет тот же механизм на синтетической и веб-нагрузке.
+
+## Содержательные направления
+
+- генератор нагрузки и базовые варианты.
+- граф операторов и материализация.
+- политика памяти, инструментирование и динамические сценарии.
+
+## Возможное продолжение
+
+Динамически добавить запрос, изменить долю популярных ключей, распределить граф между процессами либо предложить другую политику вытеснения и восстановления состояния.

project-tasks/p14-a-flink-checkpoints.md

@@ -0,0 +1,29 @@
+# P14-A. Flink: режимы контрольных точек
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Paris Carbone и соавт. — [Apache Flink: Stream and Batch Processing in a Single Engine](https://asterios.katsifodimos.com/assets/publications/flink-deb.pdf). IEEE Data Engineering Bulletin 2015, 11 страниц.
+- **Кратко о статье:** Apache Flink объединяет потоковую и пакетную обработку в общем распределённом движке с состоянием операторов. Для согласованного восстановления система строит распределённые снимки состояния, не останавливая весь поток обработки. В этом проекте сравниваются режимы контрольных точек по накладным расходам, задержке и времени exactly-once-восстановления.
+- **Почему результат актуален:** исходная статья описывает раннюю архитектуру, но система стала устойчивой отраслевой платформой и продолжает активно развиваться; [Flink 2.3.0](https://flink.apache.org/2026/06/25/apache-flink-2.3.0-release-announcement/) выпущен в июне 2026 года. Проект использует современную фиксированную версию и проверяет сохраняющийся механизм распределённых контрольных точек.
+- **Артефакты и данные:** [apache/flink](https://github.com/apache/flink) под Apache-2.0; доступны актуальная стабильная ветвь, отдельная LTS-ветвь и [официальный локальный режим](https://nightlies.apache.org/flink/flink-docs-stable/docs/getting-started/local_installation/) без обязательного облака. Зафиксированные ревизии: `apache/flink@81389aca7136` (Apache-2.0).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** асинхронные контрольные точки обеспечивают exactly-once-восстановление состояния с измеримым компромиссом между накладными расходами, задержкой обработки и временем восстановления после отказа.
+- **Технический результат:** Построить stateful-конвейер Flink с повторяемым источником, уникальными идентификаторами событий, файловым приёмником и автоматической проверкой эквивалентности результатов. Автоматизировать противодавление и отказ TaskManager.
+- **Эксперимент:** Сравнить выровненные и невыровненные контрольные точки при двух уровнях противодавления и одном отказе. Измерить throughput, p95/p99, длительность и размер checkpoint, время восстановления, пропуски, дубликаты и ошибки агрегатов; выполнить не менее трёх серий.
+- **Границы выводов:** накладные расходы и exactly-once-восстановление проверяются для одного локального конвейера, двух режимов противодавления и отказа TaskManager; результат не охватывает внешние источники и приёмники или крупный кластер.
+- **Ресурсный профиль:** одна машина, CPU, 4–8 ГБ памяти и локальная файловая система; Docker и облако необязательны. При нехватке памяти уменьшаются параллелизм и состояние, но сохраняются отдельные процессы, контрольные точки, отказ и автоматическая проверка корректности.
+
+## Содержательные направления
+
+- нагрузка и эталон корректности.
+- отказоустойчивость, контрольные точки и инструментирование.
+- экспериментальные серии, статистический анализ и собственное расширение.
+
+## Возможное продолжение
+
+Варьировать размер состояния и период контрольных точек, исследовать savepoint и rescaling, сравнить хранилища состояния либо предложить политику переключения режима при противодавлении.

project-tasks/p14-b-flink-rescaling-recovery.md

@@ -0,0 +1,29 @@
+# P14-B. Flink: rescaling и восстановление
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Paris Carbone и соавт. — [Apache Flink: Stream and Batch Processing in a Single Engine](https://asterios.katsifodimos.com/assets/publications/flink-deb.pdf). IEEE Data Engineering Bulletin 2015, 11 страниц.
+- **Кратко о статье:** Apache Flink объединяет потоковую и пакетную обработку в общем распределённом движке с состоянием операторов. Согласованные контрольные точки и savepoint позволяют восстанавливать вычисление и переносить состояние при изменении параллелизма. В этом проекте исследуется корректность перераспределения состояния и зависимость паузы восстановления от его размера и структуры.
+- **Почему результат актуален:** исходная статья описывает раннюю архитектуру, но система стала устойчивой отраслевой платформой и продолжает активно развиваться; [Flink 2.3.0](https://flink.apache.org/2026/06/25/apache-flink-2.3.0-release-announcement/) выпущен в июне 2026 года. Проект использует современную фиксированную версию и проверяет сохраняющийся механизм распределённых контрольных точек.
+- **Артефакты и данные:** [apache/flink](https://github.com/apache/flink) под Apache-2.0; доступны актуальная стабильная ветвь, отдельная LTS-ветвь и [официальный локальный режим](https://nightlies.apache.org/flink/flink-docs-stable/docs/getting-started/local_installation/) без обязательного облака. Зафиксированная основная ревизия: `apache/flink@81389aca7136` (Apache-2.0).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** Контрольная точка или savepoint позволяет корректно перераспределить состояние при изменении параллелизма, однако время восстановления и пауза обработки зависят от размера и распределения состояния.
+- **Технический результат:** Построить key-partitioned stateful-конвейер Flink с повторяемым источником, автоматической проверкой эквивалентности результатов и автоматизированным сохранением состояния. Реализовать остановку и восстановление с прежним и изменённым параллелизмом.
+- **Эксперимент:** Для не менее чем трёх размеров состояния сравнить обычный restart без изменения параллелизма как baseline и восстановление с rescaling. Измерить паузу, полное время восстановления, размер сохранения, throughput после запуска, пропуски, дубликаты и ошибки агрегатов; выполнить по три серии.
+- **Границы выводов:** корректность и пауза восстановления измеряются для выбранного stateful-конвейера, размеров состояния и параллелизма на одной машине; результат не характеризует эластичность производственного кластера и удалённого хранилища.
+- **Ресурсный профиль:** одна машина, CPU, 4–8 ГБ памяти и локальная файловая система; Docker и облако необязательны. При нехватке памяти уменьшаются параллелизм и состояние, но сохраняются отдельные процессы, контрольные точки, отказ и автоматическая проверка корректности.
+
+## Содержательные направления
+
+- нагрузка, состояние и эталон корректности.
+- автоматизация savepoint/restart/rescaling.
+- измерения восстановления, повторные серии и новый режим.
+
+## Возможное продолжение
+
+Исследовать перекос ключей, incremental checkpoints, разные state backend, автоматический выбор параллелизма или последовательность нескольких rescaling.

project-tasks/p15-autothrottle.md

@@ -0,0 +1,29 @@
+# P15. Autothrottle: двухуровневое управление ресурсами микросервисов
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Zibo Wang и соавт. — [Autothrottle: A Practical Bi-Level Approach to Resource Management for SLO-Targeted Microservices](https://www.usenix.org/conference/nsdi24/presentation/wang-zibo). NSDI 2024, Outstanding Paper.
+- **Кратко о статье:** В графе микросервисов трудно связать сквозной SLO по задержке с CPU, выделенным каждому отдельному сервису. Autothrottle разделяет управление на верхний контроллер, задающий сервисам целевые коэффициенты throttling, и локальные контроллеры, подбирающие CPU для выполнения этих целей. В проекте двухуровневый подход сравнивается с фиксированными лимитами и одноуровневым управлением на сокращённом графе.
+- **Почему результат актуален:** двухуровневый контроллер используется как baseline и расширяется в [Galileo](https://www.usenix.org/conference/nsdi26/presentation/saxena), опубликованной на NSDI 2026. Центральный вопрос о связи сквозного SLO с локальным распределением CPU сохраняется независимо от конкретной версии Kubernetes и обученной модели статьи.
+- **Артефакты и данные:** [microsoft/autothrottle](https://github.com/microsoft/autothrottle) под MIT, с тремя приложениями, производственными трассами и автоматизированной оценкой. Полное воспроизведение рассчитано на пять крупных машин, поэтому проект использует уменьшенный стенд и собственную калибровку. Зафиксированные ревизии: `microsoft/autothrottle@d237d7f3d765` (MIT; архивирован).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** разделение управления на сквозной и локальный уровни позволяет экономить CPU при соблюдении SLO устойчивее, чем фиксированные лимиты и один общий либо только локальные контроллеры.
+- **Технический результат:** Развернуть сокращённый граф из 3–5 сервисов или вариант DeathStarBench, реализовать локальные контроллеры CPU и упрощённый верхний контроллер сквозной цели. Добавить фиксированные лимиты и одноуровневую политику как baselines, общий генератор нагрузки и автоматическую проверку соблюдения SLO.
+- **Эксперимент:** на подготовленном графе сравнить двухуровневое управление с фиксированными лимитами и одноуровневой политикой при ступенчатой и переменной нагрузке по соблюдению SLO, потреблению CPU и устойчивости управления.
+- **Границы выводов:** соблюдение SLO и экономия CPU проверяются для сокращённого графа, выбранных нагрузок и упрощённых контроллеров; эксперимент не подтверждает устойчивость исходной политики на крупном производственном кластере.
+- **Ресурсный профиль:** расширенно локально, Linux, Docker или Kubernetes, CPU, желательно 16–32 ГБ памяти. Если DeathStarBench не помещается, использовать собственную цепочку сервисов с реальной очередью и управляемым потреблением CPU; имитация допустима только для дополнительного масштабирования.
+
+## Содержательные направления
+
+- стенд, нагрузка и измерение SLO.
+- локальные и верхний контроллеры.
+- базовые политики, устойчивость, повторные запуски и новая политика.
+
+## Возможное продолжение
+
+Исследовать задержку обратной связи, ошибку модели, изменение графа вызовов, интерференцию фоновой нагрузки либо правило, ограничивающее колебания контроллера.

project-tasks/p16-oakestra.md

@@ -0,0 +1,29 @@
+# P16. Oakestra: иерархическая оркестрация edge-кластера
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Giovanni Bartolomeo и соавт. — [Oakestra: A Lightweight Hierarchical Orchestration Framework for Edge Computing](https://www.usenix.org/system/files/atc23-bartolomeo.pdf). USENIX ATC 2023.
+- **Кратко о статье:** Edge-инфраструктура состоит из географически распределённых и неоднородных узлов, поэтому единый центральный оркестратор плохо масштабируется и не всегда видит локальные условия. Oakestra организует управление иерархически: верхний уровень координирует систему, а локальные уровни принимают решения в своих кластерах. В проекте иерархическая политика размещения сравнивается с централизованной на изменяющихся ресурсах и отказах.
+- **Почему результат актуален:** проект продолжает развиваться после публикации и остаётся специализированной открытой платформой для edge orchestration. Проверяемый механизм охватывает распределённое размещение и управление при слабых узлах и нестабильных связях и выходит за пределы конкретного edge-приложения.
+- **Артефакты и данные:** [oakestra/oakestra](https://github.com/oakestra/oakestra) под Apache-2.0, с оркестраторами, worker-компонентами, сетевым слоем и документацией локального развёртывания. Зафиксированные ревизии: `oakestra/oakestra@2d74107a14d8` (Apache-2.0).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** делегирование решений по иерархии уменьшает нагрузку на центральный уровень и позволяет учитывать локальные ресурсы, сохраняя приемлемое время размещения сервисов.
+- **Технический результат:** Развернуть корневой оркестратор, один кластерный оркестратор и 2–4 рабочих процесса или контейнера. Реализовать централизованный baseline, общий генератор запросов на размещение и автоматическую проверку ограничений CPU и памяти и фактического назначения сервисов.
+- **Эксперимент:** на подготовленном стенде сравнить централизованную и иерархическую политику на серии размещений при ограничениях CPU и памяти, измеряя время решения, успешность размещения, служебный трафик и потребление ресурсов control plane.
+- **Границы выводов:** сравнение проверяет механизм размещения при одном корневом и одном кластерном оркестраторе и 2–4 рабочих узлах; оно не оценивает масштабирование многоуровневой edge-топологии и нестабильность реальной сети.
+- **Ресурсный профиль:** расширенно локально, Linux, Docker, CPU, желательно 16 ГБ памяти. При проблемах со сборкой полного сетевого слоя сохранить реальные компоненты планирования и заменить worker-узлы контролируемыми локальными агентами.
+
+## Содержательные направления
+
+- стенд и наблюдаемость управляющего уровня.
+- политики размещения и инъекция ограничений.
+- метрики масштабирования, отказов и новая политика.
+
+## Возможное продолжение
+
+Добавить задержку или разрыв связи между уровнями, неоднородность узлов, предпочтение локальности либо собственную политику повторного размещения после отказа.

project-tasks/p17-skypilot.md

@@ -0,0 +1,29 @@
+# P17. SkyPilot: планирование заданий между облаками
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Zongheng Yang и соавт. — [SkyPilot: An Intercloud Broker for Sky Computing](https://www.usenix.org/system/files/nsdi23-yang-zongheng.pdf). NSDI 2023.
+- **Кратко о статье:** Облачное задание можно разместить у разных провайдеров, в разных регионах и на разных типах машин, которые различаются ценой и доступностью. SkyPilot выступает межоблачным брокером: подбирает выполнимый план, автоматизирует запуск и при необходимости меняет размещение. В проекте исследуется именно выбор плана по сохранённому каталогу ресурсов без расходов на реальные облачные машины.
+- **Почему результат актуален:** система активно развивается и используется как самостоятельный слой управления облачными заданиями. Статья сохраняет ценность как ясная постановка распределённого выбора ресурсов при различиях цен, квот и доступности, хотя конкретные провайдеры и их тарифы требуют свежего снимка перед экспериментом.
+- **Артефакты и данные:** [skypilot-org/skypilot](https://github.com/skypilot-org/skypilot) под Apache-2.0, с активно развиваемым планировщиком, каталогами ресурсов и поддержкой нескольких облаков и локальных кластеров. Зафиксированные ревизии: `skypilot-org/skypilot@fff7b16adc0c` (Apache-2.0).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** совместный выбор облака, региона и ресурсов позволяет чаще находить выполнимое и дешёвое размещение, чем фиксированный провайдер или жадный выбор самого дешёвого типа машины.
+- **Технический результат:** Подготовить автономный планировочный стенд с зафиксированным открытым или синтетическим каталогом ресурсов и набором CPU-заданий. Добавить две простые политики размещения, единый формат планов и проверку ограничений по сроку, региону и ёмкости без запуска платных облачных ресурсов.
+- **Эксперимент:** на зафиксированном каталоге сравнить SkyPilot с двумя простыми политиками для CPU-заданий с ограничениями по сроку, региону и ёмкости, измеряя стоимость плана, долю размещённых заданий и устойчивость решения к дефициту ресурсов.
+- **Границы выводов:** качество планов оценивается на зафиксированном каталоге и заданных ограничениях; эксперимент не подтверждает текущие цены и доступность реальных облаков или время исполнения размещённых заданий.
+- **Ресурсный профиль:** локально, CPU, 4–8 ГБ памяти; облачная учётная запись и реальные расходы не требуются. Если интерфейс текущей версии изменится, команда независимо реализует оптимизатор по модели статьи и проверяет его на сохранённом каталоге.
+
+## Содержательные направления
+
+- модель заданий и каталог.
+- политики выбора и исполнитель.
+- сценарии неопределённости, проверка стоимости и собственное расширение.
+
+## Возможное продолжение
+
+Добавить устаревшие сведения о цене и ёмкости, пакет заданий с общей квотой, прерываемые экземпляры, стоимость переноса данных либо онлайн-перепланирование после отказа.

project-tasks/p18-faasm.md

@@ -0,0 +1,29 @@
+# P18. Faasm: WebAssembly-изоляция для stateful serverless
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Simon Shillaker и Peter Pietzuch — [Faasm: Lightweight Isolation for Efficient Stateful Serverless Computing](https://www.usenix.org/conference/atc20/presentation/shillaker). USENIX ATC 2020.
+- **Кратко о статье:** Обычная serverless-платформа изолирует функции процессами или контейнерами, из-за чего запуск и обмен состоянием между функциями становятся дорогими. Faasm использует лёгкую WebAssembly-изоляцию, совместное размещение функций и средства общего состояния, уменьшая копирование и сериализацию данных. В проекте этот компромисс воспроизводится на CPU и сравнивается с процессной изоляцией.
+- **Почему результат актуален:** система продолжает развиваться, а линия работы получила продолжение в [GRANNY](https://www.usenix.org/conference/nsdi25/presentation/segarra) с поддержкой OpenMP, MPI и динамического управления ресурсами. Исходный механизм программной изоляции и совместного состояния остаётся доступен в текущем runtime.
+- **Артефакты и данные:** [faasm/faasm](https://github.com/faasm/faasm) под Apache-2.0, с локальным кластером через Docker Compose, C++-функциями, тестами и поддержкой распределённого состояния. Зафиксированные ревизии: `faasm/faasm@3127fe5aee8e` (Apache-2.0).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** совместное размещение WebAssembly-функций с разделяемой памятью уменьшает стоимость запуска, копирования данных и потребление памяти относительно изолированных процессов или контейнеров с сериализацией состояния.
+- **Технический результат:** В локальном Faasm-кластере реализовать две CPU-функции, которые обмениваются массивом или состоянием через разделяемую память. Подготовить функционально эквивалентный baseline с сериализацией через файл, сокет или Redis, единый запуск и автоматическую проверку равенства результатов.
+- **Эксперимент:** на подготовленных функциях сравнить разделяемую память Faasm с передачей сериализованных данных через файл, сокет или Redis. Измерять холодный и тёплый запуск, задержку, объём копирования, RSS и пропускную способность при нескольких уровнях параллелизма.
+- **Границы выводов:** стоимость обмена состоянием проверяется для двух CPU-функций и выбранного baseline в локальном окружении; результат не оценивает межузловую сеть, многоарендную изоляцию и масштабирование облачного кластера.
+- **Ресурсный профиль:** локально, Linux или Docker, CPU, желательно 16 ГБ памяти. Если распределённый режим нестабилен, обязательная часть сохраняет реальные Faaslets и разделяемую память на одном узле, а межузловой обмен исследуется в отдельной модели с калибровкой по локальным измерениям.
+
+## Содержательные направления
+
+- функции и базовый вариант с сериализацией.
+- развёртывание Faasm и инструментирование.
+- серии нагрузок, анализ памяти и собственный режим.
+
+## Возможное продолжение
+
+Исследовать размер разделяемого состояния, снимки и восстановление, конкуренцию функций, размещение между workers либо границу, после которой удалённый обмен устраняет выигрыш от совместной памяти.

project-tasks/p19-serverless-cold-starts.md

@@ -0,0 +1,29 @@
+# P19. Serverless Cold Starts: проверка обобщений на производственных трассах
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Artjom Joosen и соавт. — [Serverless Cold Starts and Where to Find Them](https://arxiv.org/pdf/2410.06145). EuroSys 2025.
+- **Кратко о статье:** Авторы анализируют месячную производственную трассу Huawei, содержащую 85 миллиардов запросов и 11,9 миллиона холодных запусков в пяти дата-центрах. Исследование разделяет задержку на выделение pod, доставку кода и зависимостей и планирование и показывает, что причины заметно различаются между регионами и типами функций. Проект повторяет часть анализа на открытых трассах и проверяет переносимость обобщений.
+- **Почему результат актуален:** авторы анализируют крупные производственные трассы и проверяют, какие свойства функций действительно объясняют холодные старты и насколько выводы переносятся между нагрузками.
+- **Артефакты и данные:** [sir-lab/data-release](https://github.com/sir-lab/data-release) с обезличенными и агрегированными трассами Huawei Cloud под CC BY 4.0 и примерами анализа. Зафиксированные ревизии: `sir-lab/data-release@84a9d7727aef` (CC BY 4.0).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** частота cold start и связанные с ней наблюдаемые характеристики заметно различаются между регионами, функциями и периодами; популярные упрощённые модели не описывают весь производственный набор.
+- **Технический результат:** Создать воспроизводимый конвейер загрузки, проверки, нормализации и выборки открытых трасс холодных запусков. Конвейер должен фиксировать происхождение данных, одинаково строить группы по периоду, региону и популярности и автоматически воспроизводить выбранные таблицы и графики.
+- **Эксперимент:** на доступной части трасс воспроизвести 2–3 основных наблюдения статьи и проверить, сохраняются ли они на разных периодах, регионах и группах популярности.
+- **Границы выводов:** наблюдения относятся к доступным периодам, регионам и выбранной части опубликованных трасс; статистические связи не устанавливают причины cold start и не описывают текущее состояние всех облачных платформ.
+- **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти; использовать агрегированные файлы или стратифицированную выборку, если полный объём не помещается. Выводы ограничивать выбранной частью данных.
+
+## Содержательные направления
+
+- подготовка и аудит данных.
+- воспроизведение статистик.
+- модель или политика и проверка переноса.
+
+## Возможное продолжение
+
+Построить и честно оценить простую модель риска cold start, проверить устойчивость агрегирования либо смоделировать одну политику keep-alive.

project-tasks/p20-cloudcast.md

@@ -0,0 +1,29 @@
+# P20. Cloudcast: стоимость и скорость многоадресной передачи между облаками
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Sarah Wooders и соавт. — [Cloudcast: High-Throughput, Cost-Aware Overlay Multicast in the Cloud](https://www.usenix.org/system/files/nsdi24-wooders.pdf). NSDI 2024.
+- **Кратко о статье:** Репликация большого набора данных сразу в несколько облачных регионов ограничена пропускной способностью и платой за исходящий трафик. Cloudcast строит оверлейное дерево с промежуточными узлами, учитывая цены и измеренную скорость каналов при заданном сроке передачи. В проекте оптимизатор сравнивается с прямой репликацией и простыми деревьями на воспроизводимой модели сети.
+- **Почему результат актуален:** Cloudcast строит прикладное дерево многоадресной передачи между облачными регионами, совместно учитывая пропускную способность, цены трафика и ограничения виртуальных машин.
+- **Артефакты и данные:** статья сообщает, что Cloudcast опубликован как часть открытого проекта [Skyplane](https://github.com/skyplane-project/skyplane) с подключаемыми алгоритмами планирования; в зафиксированной ревизии доступны планировщик и решатели. Центральный оптимизатор также можно воспроизвести независимо по псевдокоду и модели стоимости. Зафиксированная ревизия: `skyplane-project/skyplane@4602d9cec208` (Apache-2.0).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** промежуточные узлы и разбиение данных позволяют уменьшить стоимость исходящего трафика при заданном сроке передачи по сравнению с прямой репликацией.
+- **Технический результат:** Реализовать модель малой межрегиональной топологии и три построителя плана передачи: оптимизатор Cloudcast, прямую звезду и минимальное остовное дерево. Стенд должен проверять связность дерева, ограничения пропускной способности, стоимость и выполнение заданного срока на общих матрицах входных данных.
+- **Эксперимент:** на опубликованных либо синтетических матрицах стоимости и пропускной способности сравнить Cloudcast с прямой звездой и минимальным остовным деревом по стоимости, сроку передачи и допустимости плана.
+- **Границы выводов:** модель проверяет стоимость и выполнимость планов на выбранных матрицах цен и пропускной способности; она не учитывает всю изменчивость реальных межоблачных каналов, тарифов и времени запуска узлов.
+- **Ресурсный профиль:** имитация, CPU, 4–8 ГБ памяти; платные межоблачные передачи не нужны. Допустимы небольшие локальные измерения между контейнерами для проверки модели исполнения.
+
+## Содержательные направления
+
+- оптимизатор.
+- исполнитель или симулятор передачи.
+- базовые планы, сценарии неопределённости и анализ компромиссов.
+
+## Возможное продолжение
+
+Добавить неопределённость пропускной способности, изменение цен, отказ промежуточного узла или онлайн-перестройку дерева.

project-tasks/p21-dbsp-feldera.md

@@ -0,0 +1,29 @@
+# P21. DBSP/Feldera: инкрементальное выполнение запросов
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Mihai Budiu и соавт. — [DBSP: Automatic Incremental View Maintenance for Rich Query Languages](https://www.vldb.org/pvldb/vol16/p1601-budiu.pdf). PVLDB 2023.
+- **Кратко о статье:** Повторное выполнение полного запроса после каждого изменения данных тратит работу на уже известный результат. DBSP задаёт алгебраическую модель потоковых вычислений и преобразует пакетную программу в инкрементальную, которая обновляет представление по дельте входа и состояния. В проекте такой план сравнивается с полным пересчётом при разных размерах обновлений.
+- **Почему результат актуален:** DBSP перестал быть только теоретическим прототипом и развивается внутри Feldera. Механизм автоматической инкрементализации актуален для совмещения потоковой обработки, materialized views и аналитики над меняющимися данными.
+- **Артефакты и данные:** идеи статьи реализованы в активно развиваемой системе [Feldera](https://github.com/feldera/feldera), объединяющей SQL-компилятор и потоковую среду выполнения. Зафиксированная ревизия: `feldera/feldera@ab74092c6a0c` (MIT для открытой редакции; лицензии сторонних компонентов и данных проверяются отдельно).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** инкрементальная программа выполняет работу, зависящую преимущественно от размера изменения и затронутого состояния, и поэтому выигрывает у полного пересчёта при достаточно малых обновлениях.
+- **Технический результат:** Реализовать в Feldera или собственном малом инкрементальном движке зафиксированные запросы с фильтрацией, агрегацией и соединением. Добавить пакетный пересчёт как baseline, общий генератор обновлений и автоматическую проверку эквивалентности результатов после каждой серии.
+- **Эксперимент:** на сериях обновлений сравнить инкрементальное выполнение с полным пересчётом для запросов с фильтрацией, агрегацией и соединением, измеряя время, память и порог, после которого преимущество исчезает.
+- **Границы выводов:** преимущество инкрементального выполнения проверяется для выбранных операторов, запросов и серий обновлений; результат не характеризует полный SQL и распределённую производительность Feldera на производственных данных.
+- **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти. Если полный стек Feldera слишком тяжёл, обязательная часть использует самостоятельно реализованный набор операторов и проверяет эквивалентность результата пакетному вычислению.
+
+## Содержательные направления
+
+- запросы, данные и пакетный пересчёт.
+- инкрементальный конвейер и проверка корректности.
+- профилирование состояния, границы применимости и новый режим.
+
+## Возможное продолжение
+
+Исследовать перекос ключей, размер пакета обновлений, поздние исправления, стоимость хранения состояния либо запрос, для которого автоматическая инкрементализация даёт неожиданно слабый результат.

project-tasks/p22-dctcp.md

@@ -0,0 +1,29 @@
+# P22. DCTCP: управление перегрузкой в сети дата-центра через ECN
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Mohammad Alizadeh и соавт. — [Data Center TCP (DCTCP)](https://people.csail.mit.edu/alizadeh/papers/dctcp-sigcomm10.pdf). SIGCOMM 2010, Test of Time Award 2021.
+- **Кратко о статье:** В сети дата-центра обычный TCP реагирует на перегрузку только после потерь или грубых сигналов, поэтому короткие очереди трудно сочетать с высокой загрузкой канала. DCTCP использует ECN и оценивает долю помеченных пакетов, пропорционально изменяя окно передачи. В проекте этот механизм сравнивается с обычным TCP при смешении коротких и длинных потоков.
+- **Почему результат актуален:** работа получила Test of Time Award за долговременное влияние на сети дата-центров; алгоритм также описан в [RFC 8257](https://datatracker.ietf.org/doc/html/rfc8257). Поддерживаемая модель ns-3 снимает зависимость от старого исследовательского артефакта и специализированного оборудования.
+- **Артефакты и данные:** актуальный [пример DCTCP в ns-3](https://www.nsnam.org/doxygen/d4/dc2/dctcp-example_8cc_source.html) под GPL-2.0 моделирует ECN-коммутаторы, 40 конкурирующих потоков, несколько узких мест и собирает пропускную способность, справедливость и длину очередей. Для независимой реализации фиксируются версии всех зависимостей и использованных наборов данных.
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** пропорциональная реакция на ECN позволяет DCTCP поддерживать меньшие очереди и хвостовые задержки, чем обычный TCP, сохраняя высокую загрузку канала при смешанных потоках.
+- **Технический результат:** Подготовить параметризованный сценарий ns-3 с ECN-коммутатором, DCTCP и TCP Cubic или NewReno, генераторами incast и смешанных потоков. Стенд должен проверять доставку заданного объёма данных и собирать время завершения потоков, длину очереди, загрузку канала и справедливость.
+- **Эксперимент:** воспроизвести пример ns-3 и сравнить DCTCP с TCP Cubic или NewReno при incast и смеси коротких и длинных потоков по времени завершения, p95/p99, длине очереди, загрузке и справедливости.
+- **Границы выводов:** эксперимент проверяет поведение модели DCTCP в ns-3 для заданной топологии и потоков; он не воспроизводит особенности конкретных сетевых карт, коммутаторов и трафика крупного дата-центра.
+- **Ресурсный профиль:** локальная имитация, CPU, 4–8 ГБ памяти. Если полная топология даёт слишком длинные серии, уменьшить число потоков и длительность, сохранив ECN, два режима нагрузки, несколько повторов и проверку загрузки канала.
+
+## Содержательные направления
+
+- топология и проверка модели.
+- генераторы нагрузок и базовые варианты TCP.
+- метрики, статистический анализ и новые режимы.
+
+## Возможное продолжение
+
+Исследовать чувствительность к порогу ECN, размеру буфера, числу отправителей, неоднородным RTT или сосуществованию DCTCP и обычного TCP.

project-tasks/p23-pagedattention.md

@@ -0,0 +1,29 @@
+# P23. PagedAttention: управление памятью KV-кэша
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Woosuk Kwon и соавт. — [Efficient Memory Management for Large Language Model Serving with PagedAttention](https://arxiv.org/pdf/2309.06180). SOSP 2023.
+- **Кратко о статье:** При обслуживании LLM память под KV-кэш обычно резервируется непрерывными областями, что приводит к фрагментации и избыточному резервированию. PagedAttention делит кэш на блоки и размещает их по принципу виртуальной памяти, выделяя место по мере необходимости и допуская безопасное совместное использование. В проекте механизм изолируется от GPU-вычислений и сравнивается с непрерывным размещением на CPU-стенде.
+- **Почему результат актуален:** PagedAttention разбивает KV-кэш на страницы и устраняет необходимость непрерывного резервирования памяти, позволяя обслуживать больше параллельных LLM-запросов.
+- **Артефакты и данные:** [vllm-project/vllm](https://github.com/vllm-project/vllm), активно развиваемая открытая система с реализацией PagedAttention. Зафиксированные ревизии: `vllm-project/vllm@3e9d364ff727` (Apache-2.0).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** блочное размещение KV-кэша уменьшает фрагментацию и позволяет обслуживать больший динамический пакет запросов, чем непрерывное резервирование памяти.
+- **Технический результат:** Реализовать минимальный исполняемый обработчик авторегрессионных запросов на CPU с взаимозаменяемыми непрерывным и страничным аллокаторами KV-кэша. Добавить планирование динамического пакета, проверку инвариантов размещения и учёт реально выделенной памяти и отказов.
+- **Эксперимент:** на подготовленном обработчике и реально выделяемых массивах сравнить непрерывный и страничный аллокаторы по занятой памяти, внутренней фрагментации, отказам размещения, размеру динамического пакета и задержке.
+- **Границы выводов:** стенд проверяет управление памятью и планирование динамического пакета на CPU; он не оценивает GPU-ядро PagedAttention, качество модели и сквозную производительность полноценного LLM-сервера.
+- **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти; вместо большой модели допустим детерминированный генератор токенов, но обязательный результат включает работающий аллокатор и обработчик запросов. Имитация используется только для расширения масштаба; небольшая GPU-проверка необязательна.
+
+## Содержательные направления
+
+- модель запросов и аллокаторы.
+- планировщик и метрики.
+- анализ чувствительности и дополнительный механизм.
+
+## Возможное продолжение
+
+Выбрать размер блока, добавить prefix sharing, swap или предсказание длины и проверить компромисс памяти, метаданных и задержки.

project-tasks/p24-llumnix.md

@@ -0,0 +1,29 @@
+# P24. Llumnix: динамическое перепланирование LLM-запросов
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Biao Sun и соавт. — [Llumnix: Dynamic Scheduling for Large Language Model Serving](https://www.usenix.org/system/files/osdi24-sun-biao.pdf). OSDI 2024.
+- **Кратко о статье:** При одноразовом назначении LLM-запросов экземплярам со временем возникают дисбаланс очередей и фрагментация KV-кэша, а приоритетные запросы могут ждать за длинными. Llumnix переносит выполняющийся запрос вместе с его KV-состоянием и использует миграцию для балансировки, дефрагментации и соблюдения приоритетов. В проекте проверяется, когда выигрыш от перепланирования превышает стоимость переноса.
+- **Почему результат актуален:** Llumnix переносит активные LLM-запросы и их KV-состояние между экземплярами, чтобы динамически исправлять дисбаланс нагрузки и фрагментацию памяти.
+- **Артефакты и данные:** [llumnix-project/llumnix-ray](https://github.com/llumnix-project/llumnix-ray); исследовательская ветка содержит сценарии основных экспериментов. Зафиксированная ревизия: `llumnix-project/llumnix-ray@3fb6c0376b3b` (Apache-2.0).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** перенос активного запроса вместе с KV-состоянием позволяет выравнивать загрузку, устранять фрагментацию и поддерживать приоритеты лучше одноразового назначения.
+- **Технический результат:** Построить дискретно-событийный симулятор нескольких экземпляров с профилями запросов, очередями, стоимостью миграции и тремя политиками: статическое назначение, least-loaded и перепланирование Llumnix. Добавить проверки сохранения запросов и согласованности учёта времени и очередей.
+- **Эксперимент:** в симуляторе сравнить статическое назначение, least-loaded и перепланирование Llumnix при неоднородных длинах и интенсивности запросов по времени ожидания, нарушению SLO, использованию памяти и числу миграций.
+- **Границы выводов:** выводы относятся к очередям, профилям и стоимости миграции, заданным в симуляторе; без GPU-стенда они не подтверждают фактическую цену переноса KV-кэша и соблюдение SLO в реальном LLM-сервисе.
+- **Ресурсный профиль:** имитация, CPU и 4–8 ГБ памяти; полное авторское воспроизведение требует 16 GPU, поэтому обязательная часть проверяет алгоритмический механизм и калибрует стоимость по опубликованным данным.
+
+## Содержательные направления
+
+- симулятор исполнения.
+- политики и миграция.
+- нагрузка, SLO-метрики и анализ устойчивости.
+
+## Возможное продолжение
+
+Учесть стоимость миграции, ошибку прогноза длины, разные SLO или автоподбор порога переноса.

project-tasks/p25-a-ray-task-graphs.md

@@ -0,0 +1,29 @@
+# P25-A. Ray: динамические графы задач
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Philipp Moritz и соавт. — [Ray: A Distributed Framework for Emerging AI Applications](https://www.usenix.org/conference/osdi18/presentation/moritz). OSDI 2018.
+- **Кратко о статье:** Приложения машинного обучения сочетают динамические графы коротких задач с долгоживущим изменяемым состоянием, которое неудобно выражать в традиционных пакетных системах. Ray объединяет удалённые функции и акторы в одном распределённом движке с масштабируемым планированием и восстановлением. В этом проекте исследуются накладные расходы и масштабирование динамических графов задач.
+- **Почему результат актуален:** Ray объединяет задачи и акторы в одном распределённом runtime, рассчитанном на динамические графы вычислений, возникающие в обучении с подкреплением и других ИИ-приложениях.
+- **Артефакты и данные:** [ray-project/ray](https://github.com/ray-project/ray), открытая система с локальным кластерным режимом и актуальной документацией. Зафиксированные ревизии: `ray-project/ray@2ff4d94078ee` (Apache-2.0).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** единый динамический движок задач и акторов способен поддерживать высокую частоту коротких задач и сложные зависимые вычисления без специализированного планировщика для каждого приложения.
+- **Технический результат:** Подготовить локальный кластер Ray, генератор динамических DAG из коротких CPU-задач и сопоставимый baseline на процессном пуле. Добавить трассировку постановки, ожидания и исполнения задач.
+- **Эксперимент:** Варьировать гранулярность, ширину и глубину графа; сравнить Ray и baseline по времени выполнения, накладным расходам планирования, загрузке CPU и масштабированию. Для каждого режима выполнить не менее трёх серий и проверить равенство результатов.
+- **Границы выводов:** накладные расходы планирования измеряются для коротких CPU-задач и выбранных DAG на одном компьютере; результат не характеризует многоузловое масштабирование, неоднородные ресурсы и восстановление Ray после отказов.
+- **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти; масштаб статьи не воспроизводится, проверяется механизм на одном компьютере с несколькими процессами.
+
+## Содержательные направления
+
+- нагрузки и базовый вариант.
+- инструментирование планировщика и отказы.
+- новая политика и анализ масштабирования.
+
+## Возможное продолжение
+
+Реализовать собственную политику размещения, backpressure, locality-aware вариант либо сравнить Ray с простым процессным baseline на том же workload.

project-tasks/p25-b-ray-actors-recovery.md

@@ -0,0 +1,29 @@
+# P25-B. Ray: акторы и восстановление
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Philipp Moritz и соавт. — [Ray: A Distributed Framework for Emerging AI Applications](https://www.usenix.org/conference/osdi18/presentation/moritz). OSDI 2018.
+- **Кратко о статье:** Приложения машинного обучения сочетают динамические графы задач с долгоживущим изменяемым состоянием. Ray предоставляет для них общую модель удалённых функций и акторов, дополняя её распределённым планированием, объектным хранилищем и механизмами восстановления. В этом проекте исследуется граница между состоянием актора, повторным выполнением задач и внешним сохранением данных при сбоях.
+- **Почему результат актуален:** Ray объединяет задачи и акторы в одном распределённом runtime, рассчитанном на динамические графы вычислений, возникающие в обучении с подкреплением и других ИИ-приложениях.
+- **Артефакты и данные:** [ray-project/ray](https://github.com/ray-project/ray), открытая система с локальным кластерным режимом и актуальной документацией. Зафиксированная основная ревизия: `ray-project/ray@2ff4d94078ee` (Apache-2.0).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** Модель акторов упрощает долгоживущее изменяемое состояние, но гарантии восстановления и цена повторного выполнения зависят от границы между состоянием актора, задачами и внешним хранилищем.
+- **Технический результат:** Реализовать локальное приложение из нескольких stateful-акторов и клиентов с журналом операций, контрольными суммами и управляемыми падениями. Добавить как минимум две стратегии восстановления состояния.
+- **Эксперимент:** Сравнить restart без внешнего состояния, checkpoint/replay и простой процессный baseline при отказе worker и актора. Измерить время восстановления, потерянные или повторные операции, p95/p99, объём повторной работы и правильность конечного состояния минимум в трёх сериях.
+- **Границы выводов:** гарантии и цена восстановления проверяются для выбранного приложения акторов, стратегий хранения и локальных отказов; результат не устанавливает общую семантику долговечности Ray и поведение крупного кластера.
+- **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти; масштаб статьи не воспроизводится, проверяется механизм на одном компьютере с несколькими процессами.
+
+## Содержательные направления
+
+- модель состояния и эталон корректности.
+- приложение акторов, отказы и восстановление.
+- базовый вариант, нагрузка, повторные серии и анализ гарантий.
+
+## Возможное продолжение
+
+Добавить placement groups, репликацию состояния, backpressure, цепочку акторов или отказ во время checkpoint.

project-tasks/p26-a-parrot-graph-scheduling.md

@@ -0,0 +1,29 @@
+# P26-A. Parrot: планирование графа
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Chaofan Lin и соавт. — [Parrot: Efficient Serving of LLM-based Applications with Semantic Variable](https://www.usenix.org/conference/osdi24/presentation/lin-chaofan). OSDI 2024.
+- **Кратко о статье:** LLM-приложение часто состоит из зависимых вызовов модели, но обычный сервис видит их как отдельные непрозрачные запросы и не может учитывать общий критический путь. Parrot вводит семантические переменные, раскрывающие зависимости и повторно используемый контекст, и планирует весь граф приложения. В этом проекте графовое планирование сравнивается с последовательной и простой очередной обработкой.
+- **Почему результат актуален:** Parrot добавляет в интерфейс LLM-сервиса семантические переменные, которые раскрывают зависимости между вызовами и структуру промптов для совместной оптимизации всего приложения.
+- **Артефакты и данные:** [microsoft/ParrotServe](https://github.com/microsoft/ParrotServe) под MIT, с клиентской частью, примерами составных приложений, планировщиком и тестами. Зафиксированные ревизии: `microsoft/ParrotServe@2e1825ee2bc3` (MIT).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** знание графа вызовов и общих префиксов позволяет сервису распараллеливать независимые запросы, переиспользовать состояние и оптимизировать время выполнения приложения лучше, чем при обработке непрозрачных запросов по отдельности.
+- **Технический результат:** Реализовать исполняемый сервис составного приложения с семантическими переменными, реальной очередью и двумя DAG, содержащими последовательные и независимые вызовы. Исполнитель должен поддерживать последовательную и графовую политики.
+- **Эксперимент:** Сравнить последовательное выполнение, обычную пакетную обработку и планирование по критическому пути при нескольких уровнях параллелизма. Измерить полное время приложения, p95, загрузку исполнителей и ожидание узлов; проверить корректность зависимостей и выполнить не менее трёх серий.
+- **Границы выводов:** эффект планирования графа проверяется для двух составных DAG и локального исполнителя с измеряемой стоимостью вызовов; он не характеризует качество LLM, GPU-планирование и производственную нагрузку Parrot.
+- **Ресурсный профиль:** локально, CPU, до 16 ГБ памяти; вызов LLM можно заменить малой локальной моделью или детерминированной функцией с измеряемым временем, но сам исполнитель и планировщик должны работать на реальных запросах. Симулятор допустим только для масштабных серий.
+
+## Содержательные направления
+
+- графы приложений и нагрузки.
+- реализации политик и инструментирование.
+- метрики, граничные случаи и новое правило планирования.
+
+## Возможное продолжение
+
+Исследовать неполные или ошибочные аннотации, динамически раскрываемые зависимости, изоляцию между пользователями либо компромисс между локальностью префикса и критическим путём.

project-tasks/p26-b-parrot-prefix-locality.md

@@ -0,0 +1,29 @@
+# P26-B. Parrot: префиксы и локальность
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Chaofan Lin и соавт. — [Parrot: Efficient Serving of LLM-based Applications with Semantic Variable](https://www.usenix.org/conference/osdi24/presentation/lin-chaofan). OSDI 2024.
+- **Кратко о статье:** В LLM-приложениях разные вызовы часто используют общие части промптов, однако обычный сервис не знает ни об этой связи, ни о зависимостях между запросами. Parrot представляет значения семантическими переменными и использует открывшийся граф для переиспользования контекста и совместного планирования. В этом проекте исследуется компромисс между локальностью общих префиксов и балансировкой очередей.
+- **Почему результат актуален:** Parrot добавляет в интерфейс LLM-сервиса семантические переменные, которые раскрывают зависимости между вызовами и структуру промптов для совместной оптимизации всего приложения.
+- **Артефакты и данные:** [microsoft/ParrotServe](https://github.com/microsoft/ParrotServe) под MIT, с клиентской частью, примерами составных приложений, планировщиком и тестами. Зафиксированная основная ревизия: `microsoft/ParrotServe@2e1825ee2bc3` (MIT).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** Знание общих частей промптов позволяет уменьшать повторные вычисления, но политика локальности может конфликтовать с балансировкой очередей и критическим путём приложения.
+- **Технический результат:** Реализовать исполнитель составных запросов с явными семантическими переменными, блочным кэшем префиксов и двумя политиками маршрутизации: least-loaded и prefix-aware. Допустима малая локальная модель или детерминированная функция с измеряемой стоимостью.
+- **Эксперимент:** Варьировать долю общих префиксов, размер кэша, интенсивность и перекос запросов. Сравнить least-loaded baseline и prefix-aware-политику по hit rate, объёму повторной работы, полному времени приложения, p95 и загрузке исполнителей минимум в трёх сериях; проверить правильность изоляции результатов разных запросов.
+- **Границы выводов:** компромисс локальности и балансировки проверяется для выбранной модели стоимости, кэша и распределения префиксов; результат не подтверждает совместимость реального KV-кэша модели и производительность GPU-сервера.
+- **Ресурсный профиль:** локально, CPU, до 16 ГБ памяти; вызов LLM можно заменить малой локальной моделью или детерминированной функцией с измеряемым временем, но сам исполнитель и планировщик должны работать на реальных запросах. Симулятор допустим только для масштабных серий.
+
+## Содержательные направления
+
+- нагрузки и графы с общими префиксами.
+- кэш и маршрутизация.
+- метрики, проверка изоляции, граничные режимы и новая политика.
+
+## Возможное продолжение
+
+Добавить многоарендность, ошибочные аннотации, стоимость переноса состояния, совместную политику критического пути и локальности или предсказание повторного использования.

project-tasks/p27-dede.md

@@ -0,0 +1,29 @@
+# P27. DeDe: декомпозиция задач распределения ресурсов
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Zhiying Xu и соавт. — [Decouple and Decompose: Scaling Resource Allocation with DeDe](https://www.usenix.org/conference/osdi25/presentation/xu). OSDI 2025.
+- **Кратко о статье:** Крупные задачи распределения ресурсов в облаке перерастают возможности универсальных решателей, а специализированные алгоритмы обычно привязаны к одной системе. DeDe использует общую разделимость многих постановок: разъединяет ограничения ресурсов и запросов и решает чередующиеся подзадачи независимо и параллельно. В проекте этот подход сравнивается с монолитным решением по времени, допустимости и качеству распределения.
+- **Почему результат актуален:** опубликованный пакет предоставляет высокоуровневый интерфейс, тесты и три разные прикладные задачи. Статья свежая, поэтому статус влияния предварительный, но общий механизм не привязан к закрытому кластеру или специальному оборудованию и уже допускает независимую проверку на CPU.
+- **Артефакты и данные:** [illinois-nsai/dede](https://github.com/illinois-nsai/dede) под MIT, доступен как Python-пакет и содержит примеры для кластерного планирования, балансировки нагрузки и управления трафиком. Для обязательного сравнения достаточно свободного решателя CVXPY; Gurobi не требуется. Зафиксированные ревизии: `illinois-nsai/dede@11c97f786a1e` (MIT).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** разделение связанных ограничений на подзадачи для ресурсов и запросов ускоряет решение крупных задач распределения, сохраняя допустимость и качество результата относительно монолитного решателя.
+- **Технический результат:** Формализовать одну задачу кластерного размещения или балансировки нагрузки и реализовать её в DeDe и как монолитную модель CVXPY. Подготовить общий генератор входов, проверку допустимости решения и единый расчёт целевой функции и невязок.
+- **Эксперимент:** для выбранной задачи на открытых или синтетических данных сравнить DeDe и монолитное решение CVXPY по времени, целевой функции, невязкам и масштабированию по числу ресурсов и запросов.
+- **Границы выводов:** сравнение относится к одной формализации задачи, выбранным входам и размерам, доступным точному решателю; оно не устанавливает преимущество DeDe для других задач распределения и производственных масштабов.
+- **Ресурсный профиль:** локально, CPU, Python, 8–16 ГБ памяти. Если высокоуровневый интерфейс нестабилен на большой задаче, использовать опубликованные низкоуровневые примеры и уменьшить размер, сохранив сравнение с точным решением на тех же входах.
+
+## Содержательные направления
+
+- постановка и генератор задач.
+- реализации DeDe и монолитного варианта.
+- проверка допустимости, масштабирование и исследование нового ограничения.
+
+## Возможное продолжение
+
+Добавить неоднородные ресурсы, онлайн-прибытие запросов, ограничение миграций, новый критерий справедливости либо собственное правило адаптации параметра декомпозиции.

project-tasks/p28-distserve.md

@@ -0,0 +1,29 @@
+# P28. DistServe: раздельное выполнение prefill и decode
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Yinmin Zhong и соавт. — [DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving](https://www.usenix.org/conference/osdi24/presentation/zhong-yinmin). OSDI 2024.
+- **Кратко о статье:** Обработка LLM-запроса состоит из вычислительно насыщенного prefill и последовательного decode с другим профилем нагрузки, поэтому совместное выполнение мешает независимо масштабировать стадии. DistServe размещает их на разных наборах устройств и передаёт между ними KV-кэш, оптимизируя полезную пропускную способность при ограничениях на TTFT и TPOT. Проект воспроизводит этот компромисс на CPU-модели.
+- **Почему результат актуален:** исходная реализация остаётся исследовательским артефактом, однако раздельные prefill и decode вошли в современные системы инференса, включая экспериментальный режим [vLLM](https://docs.vllm.ai/en/v0.14.0/features/disagg_prefill/). Поэтому проект проверяет уже применяемое архитектурное решение и его границу выгодности.
+- **Артефакты и данные:** [LLMServe/DistServe](https://github.com/LLMServe/DistServe) под Apache-2.0; включает код системы, профилировщик, сценарии оценки и `simdistserve`. Зафиксированные ревизии: `LLMServe/DistServe@82831f1604cc` (Apache-2.0).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** разделение prefill и decode увеличивает goodput при одновременных ограничениях на TTFT и TPOT, если выигрыш от независимого масштабирования превышает стоимость передачи KV-кэша.
+- **Технический результат:** Реализовать CPU-симулятор фаз prefill и decode с очередями, профилями выполнения и моделью сети. Добавить совместное и раздельное размещение, общий генератор запросов и проверки сохранения запросов, пропускной способности и разложения задержки по фазам.
+- **Эксперимент:** на профилях или синтетической модели сравнить совместное и раздельное размещение для нескольких распределений длин входа и выхода, явно варьируя пропускную способность сети и проверяя обе задержки и goodput.
+- **Границы выводов:** выигрыш раздельного выполнения определяется профилями и сетевой моделью симулятора; без GPU-стенда он не подтверждает фактические TTFT, TPOT, goodput и цену передачи KV-кэша в DistServe.
+- **Ресурсный профиль:** локально, CPU и 8–16 ГБ памяти для имитации; полная система требует как минимум два GPU и остаётся необязательной. Калибровку можно провести по опубликованным профилям и небольшому локальному измерению.
+
+## Содержательные направления
+
+- модель фаз и профили.
+- политики размещения и маршрутизации.
+- SLO, сетевые ограничения и анализ чувствительности.
+
+## Возможное продолжение
+
+Динамически переключать совместный и раздельный режим, учитывать неоднородные ускорители, искать неблагоприятные режимы либо предложить новую политику выбора числа экземпляров каждой фазы.

project-tasks/p29-mooncake.md

@@ -0,0 +1,29 @@
+# P29. Mooncake: глобальный многоуровневый KV-кэш
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Ruoyu Qin и соавт. — [Mooncake: Trading More Storage for Less Computation — A KVCache-centric Architecture for Serving LLM Chatbot](https://www.usenix.org/conference/fast25/presentation/qin). FAST 2025, Best Paper.
+- **Кратко о статье:** Для длинных диалогов и повторяющихся префиксов повторный prefill расходует дорогие вычисления, хотя готовый KV-кэш можно сохранить и передать. Mooncake отделяет стадии prefill и decode и строит глобальный многоуровневый KV-кэш на памяти и накопителях вычислительных узлов. В проекте сравниваются повторное вычисление, локальный кэш и общее блочное хранилище при разных сетевых ограничениях.
+- **Почему результат актуален:** Mooncake разделяет prefill и decode и превращает память GPU, DRAM и SSD кластера в общий KV-кэш, управляемый с учётом повторного использования и требований к задержке.
+- **Артефакты и данные:** [kvcache-ai/Mooncake](https://github.com/kvcache-ai/Mooncake) под Apache-2.0 с движком передачи и [FAST’25-трассами](https://github.com/kvcache-ai/Mooncake/tree/main/FAST25-release), включая отдельную агентную нагрузку. Зафиксированные ревизии: `kvcache-ai/Mooncake@408b831bfeff` (Apache-2.0).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** глобальное хранение KV-блоков может выгодно заменить повторный prefill для длинных общих префиксов, но результат определяется пропускной способностью хранилища, конкуренцией за сеть и политикой допуска в кэш.
+- **Технический результат:** Построить из нескольких процессов общий блочный кэш поверх RAM и локального SSD с сетевым чтением, вытеснением и предварительной загрузкой. Добавить локальный LRU и модель повторного вычисления, проигрыватель открытых трасс и проверку целостности возвращаемых блоков.
+- **Эксперимент:** на подготовленном блочном кэше и открытых трассах сравнить глобальную политику с локальным LRU и повторным вычислением по доле попаданий, переданным байтам, задержке и goodput.
+- **Границы выводов:** стенд проверяет политики блочного кэша на RAM, SSD и локальной сети при заданной стоимости повторного вычисления; он не воспроизводит RDMA, GPU-prefill и конкуренцию производственного кластера Mooncake.
+- **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти, несколько процессов; RDMA и GPU не требуются. Стоимость prefill задаётся реальной малой функцией или калиброванной задержкой, а при тяжёлой трассе используется воспроизводимая подвыборка.
+
+## Содержательные направления
+
+- разбор трасс и модель стоимости.
+- реализации кэшей и маршрутизации.
+- SLO, сетевые эксперименты и новая политика.
+
+## Возможное продолжение
+
+Добавить объединение одновременных загрузок, ограничение полосы, несколько арендаторов, ошибку предсказания повторного использования либо совместное решение о маршрутизации и вытеснении.

project-tasks/p30-pollux.md

@@ -0,0 +1,29 @@
+# P30. Pollux: совместная адаптация обучения и кластерного планировщика
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Aurick Qiao и соавт. — [Pollux: Co-adaptive Cluster Scheduling for Goodput-Optimized Deep Learning](https://www.usenix.org/conference/osdi21/presentation/qiao). OSDI 2021, Best Paper.
+- **Кратко о статье:** Скорость обучения зависит от числа выделенных ускорителей и размера пакета. Размер пакета меняет системную производительность и статистическую эффективность оптимизации. Pollux объединяет эти факторы в метрике goodput и совместно адаптирует конфигурацию задания и распределение ресурсов кластера. В проекте такая политика сравнивается с планированием только по throughput на симуляции CPU.
+- **Почему результат актуален:** ветка AdaptDL в основном сохранилась как снимок статьи, но совместная оптимизация размещения и goodput получила прямое развитие в [Sia](https://shouxulin.github.io/pubs/sia.pdf), учитывающей неоднородные кластеры. Базовый проект использует Pollux как понятный исходный механизм и сравнивает его с современным продолжением постановки.
+- **Артефакты и данные:** ветка [petuum/adaptdl для OSDI 2021](https://github.com/petuum/adaptdl/tree/osdi21-artifact) под Apache-2.0 содержит реализацию и дискретный симулятор кластера. Зафиксированные ревизии: `petuum/adaptdl@542e123e50e9` (Apache-2.0).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** совместный учёт системной скорости и статистической эффективности обучения позволяет перераспределять ресурсы с меньшим средним временем завершения, сохраняя справедливость между задачами.
+- **Технический результат:** Создать исполнитель нескольких малых CPU-задач обучения как реальных процессов и три планировщика: фиксированный, простой динамический и упрощённый Pollux с изменением параллелизма и размера пакета. Добавить единый журнал событий, проверку завершения задач и расчёт goodput, JCT и справедливости.
+- **Эксперимент:** на нескольких наборах одновременно выполняющихся задач сравнить фиксированное распределение, простую динамическую политику и упрощённый Pollux, измеряя goodput, JCT и справедливость.
+- **Границы выводов:** сравнение относится к малым CPU-задачам, упрощённой модели goodput и выбранным политикам; оно не подтверждает статистическую эффективность и время завершения много-GPU-обучения в производственном кластере.
+- **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти; достаточно малых моделей и наборов данных, поэтому несколько реальных задач входят в обязательную часть. Синтетические профили используются для калибровки и расширения масштаба; при несовместимости артефакта планировщик реализуется независимо.
+
+## Содержательные направления
+
+- профили и модель прогресса.
+- планировщики и симулятор.
+- справедливость, чувствительность и новая целевая функция.
+
+## Возможное продолжение
+
+Добавить неоднородные ускорители, ошибку профиля, стоимость перераспределения, приоритеты либо новую цель, объединяющую JCT и справедливость.

project-tasks/p31-a-gc3-correctness.md

@@ -0,0 +1,29 @@
+# P31-A. GC3: корректность расписаний
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Meghan Cowan и соавт. — [GC3: An Optimizing Compiler for GPU Collective Communication](https://arxiv.org/pdf/2201.11840). ASPLOS 2023.
+- **Кратко о статье:** Быстрые коллективные операции для GPU-кластеров обычно реализуются вручную под конкретную топологию, что усложняет проверку и перенос оптимизаций. GC3 задаёт коллектив как структурированную программу пересылок и компилирует её в специализированное выполнение, применяя преобразования и конвейеризацию. В этом проекте строится CPU-модель для проверки корректности расписаний и сохранения семантики после преобразований.
+- **Почему результат актуален:** исходный набор MSCCL tools обновляется редко, но линия программируемых коллективов продолжается в активно развиваемом [MSCCL++](https://github.com/microsoft/mscclpp) под MIT. Проект сосредоточен на переносимом языке расписаний, проверке корректности и компиляции; устаревшая версия runtime не входит в его основной предмет.
+- **Артефакты и данные:** [microsoft/msccl-tools](https://github.com/microsoft/msccl-tools) под MIT, с Python DSL MSCCLang, компилятором, примерами и тестами. Зафиксированные ревизии: `microsoft/msccl-tools@030a750fc56e` (MIT).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** явное описание алгоритма на уровне блоков вместе с компиляторными преобразованиями позволяет безопасно получать специализированные конвейерные коллективы без ручного написания низкоуровневого GPU-кода.
+- **Технический результат:** Выразить ring AllReduce и один AllToAll в MSCCLang, построить независимый эталон семантики блоков и автоматическую проверку полученного расписания.
+- **Эксперимент:** Для нескольких размеров топологии проверить отсутствие потерь, дублирования, чтения до записи и взаимоблокировки, затем сопоставить IR и имитационную стоимость с эталонным расписанием. Обязательны положительные тесты и не менее трёх намеренно испорченных расписаний.
+- **Границы выводов:** проверка относится к семантике блоков, выбранным коллективам и сгенерированному IR; без исполнения на GPU она не подтверждает производительность расписаний и корректность низкоуровневого runtime.
+- **Ресурсный профиль:** локально, CPU и 4–8 ГБ памяти для компиляции и имитации; исполнение через MSCCL на нескольких GPU необязательно и не входит в минимальный результат.
+
+## Содержательные направления
+
+- DSL-программы и эталоны.
+- анализ и модификация компилятора.
+- проверка расписаний, модель стоимости и эксперименты.
+
+## Возможное продолжение
+
+Реализовать проверку корректности, новую оптимизацию порядка или слияния передач, поддержку новой топологии либо автоматический выбор числа каналов.

project-tasks/p31-b-gc3-topology-optimization.md

@@ -0,0 +1,29 @@
+# P31-B. GC3: оптимизация под топологию
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Meghan Cowan и соавт. — [GC3: An Optimizing Compiler for GPU Collective Communication](https://arxiv.org/pdf/2201.11840). ASPLOS 2023.
+- **Кратко о статье:** Быстрые коллективные операции для GPU-кластеров обычно реализуются вручную под конкретную топологию и доступные параллельные каналы. GC3 отделяет описание алгоритма обмена от низкоуровневого выполнения и компилирует специализированные расписания с конвейеризацией. В этом проекте исследуется, как учёт топологии сокращает критический путь коллектива без изменения результата.
+- **Почему результат актуален:** исходный набор MSCCL tools обновляется редко, но линия программируемых коллективов продолжается в активно развиваемом [MSCCL++](https://github.com/microsoft/mscclpp) под MIT. Проект сосредоточен на переносимом языке расписаний, проверке корректности и компиляции; устаревшая версия runtime не входит в его основной предмет.
+- **Артефакты и данные:** [microsoft/msccl-tools](https://github.com/microsoft/msccl-tools) под MIT, с Python DSL MSCCLang, компилятором, примерами и тестами. Зафиксированная основная ревизия: `microsoft/msccl-tools@030a750fc56e` (MIT).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** Специализированное расписание, учитывающее топологию и параллельные каналы, может сократить критический путь коллектива без изменения его семантики.
+- **Технический результат:** Построить CPU-симулятор топологии и расписаний MSCCLang, реализовать хотя бы одно преобразование порядка, разбиения или назначения каналов. Корректность каждого результата проверяется независимой моделью движения блоков.
+- **Эксперимент:** Сравнить исходный ring либо AllToAll и оптимизированное расписание на двух топологиях и нескольких размерах сообщения. Измерить критический путь, переданные байты, загрузку узких каналов и число шагов; проверить корректность и устойчивость к изменению параметров.
+- **Границы выводов:** выигрыш оценивается по модели критического пути на двух заданных топологиях; он не учитывает все эффекты реальной сети, GPU-ядер и конкуренции каналов при исполнении коллектива.
+- **Ресурсный профиль:** локально, CPU и 4–8 ГБ памяти для компиляции и имитации; исполнение через MSCCL на нескольких GPU необязательно и не входит в минимальный результат.
+
+## Содержательные направления
+
+- модель топологии и исходное расписание.
+- компиляторное преобразование и генерация расписаний.
+- проверка корректности, модель стоимости и экспериментальные серии.
+
+## Возможное продолжение
+
+Добавить иерархическую топологию, автоматический поиск числа каналов, отказ одного канала, слияние передач или сравнение с ещё одним опубликованным коллективом.

project-tasks/p32-alea-bft.md

@@ -0,0 +1,33 @@
+# P32. Alea-BFT: асинхронная репликация с византийскими отказами
+
+- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Статус:** готово к назначению.
+
+## Статья и исходные материалы
+
+- **Основная статья:** Diogo S. Antunes и соавт. — [Alea-BFT: Practical Asynchronous Byzantine Fault Tolerance](https://www.usenix.org/conference/nsdi24/presentation/antunes). NSDI 2024.
+- **Кратко о статье:** Классические BFT-протоколы обычно полагаются на частичную синхронность, лидера и тайм-ауты, которые плохо работают при непредсказуемых задержках. Alea-BFT использует рандомизированную асинхронную модель и простой двухступенчатый конвейер: рассылку от назначенной реплики и последующее бинарное согласование. В проекте протокол сравнивается с опубликованным baseline на локальных процессах при задержках, потерях и crash-отказах.
+- **Почему результат актуален:** прототип — снимок состояния на момент публикации, но асинхронная BFT-репликация остаётся самостоятельной базовой темой распределённых систем; две интеграции в системы распределённых валидаторов дают более сильный сигнал практической применимости, чем один экспериментальный стенд.
+- **Артефакты и данные:** [diogoantunes25/AleaBFT](https://github.com/diogoantunes25/AleaBFT) — Java-прототип с Alea-BFT, HoneyBadger и Dumbo, режимами штатной работы, crash- и Byzantine-отказов и возможностью запускать несколько реплик на одной машине. [Официальная страница проекта](https://alea-bft.org/) указывает для прототипа лицензию MIT и приводит две интеграции протокола. Зафиксированная ревизия: `diogoantunes25/AleaBFT@543786ef199a` (MIT по официальной странице проекта; файл лицензии в репозитории отсутствует).
+
+## Обязательный результат
+
+- **Проверяемый вопрос или утверждение:** двухступенчатый конвейер сохраняет прогресс при непредсказуемых задержках и отказах без настройки таймаутов и даёт меньшую задержку, чем сравниваемые асинхронные протоколы в части режимов.
+- **Технический результат:** Развернуть 4–7 локальных процессов Alea-BFT и хотя бы одного опубликованного baseline, подготовить общий клиент и управляемую инъекцию задержек, потерь и crash-отказов. Стенд должен автоматически проверять единый порядок доставки, отсутствие потерь подтверждённых запросов и прогресс допустимого числа реплик.
+- **Эксперимент:** на подготовленном стенде сравнить Alea-BFT хотя бы с одним опубликованным baseline при контролируемых задержках, потерях и crash-отказах по порядку доставки, прогрессу, задержке и пропускной способности.
+- **Границы выводов:** безопасность и прогресс проверяются для 4–7 локальных процессов, выбранного baseline и управляемых задержек, потерь и crash-отказов; эксперимент не подтверждает устойчивость ко всем византийским стратегиям и производительность геораспределённого развёртывания.
+- **Ресурсный профиль:** расширенно локально, Linux или Docker, CPU, желательно 16 ГБ памяти. Если полный benchmark service нестабилен, оставить реальные локальные реплики Alea-BFT и один простой baseline, а сетевые режимы задавать через управляемый прокси или `tc netem`.
+
+## Содержательные направления
+
+- сборка реплик и автоматическая проверка согласованности порядка.
+- базовый протокол и инъекция отказов.
+- нагрузка, статистический анализ и новый режим.
+
+## Возможное продолжение
+
+Исследовать неравномерные задержки, медленного или византийского лидера, размер пакета, восстановление пропущенных запросов либо границу, при которой синхронный baseline становится выгоднее.
+
+## Известное ограничение
+
+На зафиксированной ревизии нет файла лицензии, хотя официальная страница проекта указывает MIT. До появления однозначного файла лицензии исходный код прототипа не копируется в репозиторий команды. Его можно запускать как внешнюю зависимость; изменения реализуются независимо либо после разрешения правообладателя.