Update project task cards to version 1.1

project-tasks/README.md

@@ -81,6 +81,12 @@
 
 ## Как читать проектное задание
 
-Поле «Кратко о статье» объясняет решаемую авторами проблему, основную идею работы и связь с конкретным проектом; поле «Почему результат актуален» описывает современное состояние и сохраняющееся значение результата. «Артефакты и данные» фиксируют доступные исходные материалы, но не определяют способ реализации. Раздел «Обязательный результат» задаёт минимальный содержательный объём и допустимый технический путь, а «Содержательные направления» помогают команде распределить работу без назначения готовых персональных ролей. «Возможное продолжение» не входит в обязательную часть и высокой оценки не гарантирует.
+Поле «Кратко о статье» объясняет проблему, идею работы и связь с проектом; поле «Почему результат актуален» — сохраняющееся значение результата. «Артефакты и данные» фиксируют источники и ревизии, а «Что уже предоставляет артефакт» перечисляет готовые компоненты и разрешённые способы их использования. «Обязательное приращение команды» показывает, какие компоненты, эксперименты и проверки нужно подготовить самостоятельно. Сборка, запуск и повторение готового сценария сами по себе технический результат не закрывают; содержательная адаптация засчитывается по результату, прямо указанному в карточке.
+
+Как готовый артефакт сочетается с самостоятельной работой команды, показано в [примере проекта Remix](../project.md#что-предстоит-делать-если-код-уже-опубликован).
+
+Раздел «Обязательный результат» полностью задаёт достаточный объём проекта, включая сокращённый ресурсный путь. «Содержательные направления» помогают распределить работу в тройке. «Возможное продолжение» остаётся необязательным и высокой оценки не гарантирует. Достаточность проверяется по кратчайшему допустимому пути выполнения задания; общих квот на строки кода, эксперименты или часы нет.
+
+7 сентября 2026 года карточки обновлены до версии 1.1 по содержимому закреплённых ревизий; в десяти карточках с существенным покрытием готовыми сценариями приведены ссылки на просмотренные исходники и история уточнений. Это статическая проверка кода, scripts, examples, benchmarks и notebooks. Сборка и запуск внешних артефактов в неё не входили; работоспособность конкретного окружения проверяется на первой контрольной точке.
 
 Общие [итоговые материалы](../project.md#итоговые-материалы-и-защита) и [шкала `ТР`, `Э` и `ВО`](../grading.md#материалы-проекта) действуют для всех заданий. Оценивается новое приращение относительно опубликованных кода, данных и результатов.

project-tasks/p01-remix.md

@@ -1,6 +1,6 @@
 # P01. Remix: спецификации разной гранулярности для проверки распределённых систем
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,21 +9,29 @@
 - **Кратко о статье:** Авторы проверяют 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).
+- **Что уже предоставляет артефакт:** Готовы ZooKeeper, смешанная спецификация `generator/MSPEC_2.tla`, генерация и преобразование трасс, их проигрывание и отчёт `matchReport`. Скрипты и демонстрационные трассы разрешено использовать как основу; они не заменяют новый сценарий и независимую проверку команды. Проверенные исходные материалы: [демонстрационные трассы](https://github.com/Lingzhi-Ouyang/Remix/tree/81869f1accc1/traces/demo), [конфигурация TLC](https://github.com/Lingzhi-Ouyang/Remix/blob/81869f1accc1/generator/Zab-simulate.ini).
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** смешанная гранулярность спецификации уменьшает стоимость model checking относительно полностью детальной модели и обнаруживает расхождения, которые теряются в полностью грубой модели.
-- **Технический результат:** Собрать воспроизводимый конвейер для трёх вариантов спецификации: генерация трасс в TLC, преобразование в формат проигрывателя, запуск на малой конфигурации ZooKeeper и автоматический отчёт о совпадениях и расхождениях. Все варианты должны использовать общие сценарии и одинаковые ограничения поиска.
+- **Технический результат:** Подготовить грубую, детальную и смешанную спецификации и общий воспроизводимый конвейер: генерация трасс в TLC, преобразование в формат проигрывателя, запуск на малой конфигурации ZooKeeper и автоматический отчёт о совпадениях и расхождениях. Готовый конвейер можно повторно использовать; все варианты должны включать новый сценарий и одинаковые ограничения поиска.
-- **Эксперимент:** воспроизвести генерацию и проигрывание трасс для ZooKeeper, затем сравнить грубую, детальную и смешанную спецификации по числу состояний, времени проверки и найденным расхождениям на 2–3 сценариях.
+- **Обязательное приращение команды:** Добавить сценарий ZooKeeper, отсутствующий в демонстрационных трассах закреплённой версии, и включить его в сравнение гранулярностей. Для хотя бы одного совпадения или расхождения самостоятельно сопоставить события модели с журналами и состоянием реализации; итогового `matchReport` без этого разбора недостаточно.
+- **Эксперимент:** Сравнить три гранулярности по числу состояний, времени проверки и расхождениям на 2–3 сценариях, включая отсутствующий в демонстрации. Хотя бы одно совпадение или расхождение независимо подтвердить по событиям и состоянию ZooKeeper, объяснив их соответствие модели; обнаружение неизвестной ошибки не требуется.
 - **Границы выводов:** сравнение относится к выбранным сценариям ZooKeeper и ограничениям поиска TLC; оно не доказывает полноту спецификаций и не оценивает все возможные ошибки реализации.
-- **Ресурсный профиль:** локально, Linux, CPU, 8–16 ГБ памяти. Если полная генерация пространства состояний слишком долгая, использовать демонстрационные трассы и уменьшенную конфигурацию ZooKeeper, сохранив сравнение трёх вариантов спецификации и проверку соответствия.
+- **Ресурсный профиль:** Локально, Linux, CPU, 8–16 ГБ памяти. При дорогой генерации уменьшить число событий и конфигурацию ZooKeeper, сохранив три гранулярности, новый сценарий и независимую проверку соответствия. Демонстрационные трассы подходят для проверки конвейера.
 
 ## Содержательные направления
 
-- спецификации и конфигурации TLC.
+- спецификации трёх гранулярностей и конфигурации TLC.
-- воспроизведение трасс и инструментирование ZooKeeper.
+- новый сценарий и воспроизведение трасс ZooKeeper.
-- сравнение гранулярностей, контролируемые расхождения и анализ результатов.
+- независимая проверка соответствия и сравнительный анализ.
 
 ## Возможное продолжение
 
 Детализировать один дополнительный модуль или изменение ZooKeeper, внести контролируемое расхождение между моделью и кодом либо исследовать границу, после которой дополнительная детализация перестаёт окупаться.
+
+## История уточнений
+
+| Дата | Версия | Основание | Изменение обязательного результата |
+|---|---|---|---|
+| 07.09.2026 | 1.1 | Статический просмотр закреплённого артефакта: готовые сценарии частично покрывают задание. | Добавлены новый сценарий и независимая проверка соответствия реализации; сокращённый путь сохраняет их. |

project-tasks/p02-dupchecker.md

@@ -1,6 +1,6 @@
 # P02. DUPChecker: статическая проверка совместимости форматов при обновлении
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,11 +9,13 @@
 - **Кратко о статье:** Авторы исследуют 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).
+- **Что уже предоставляет артефакт:** Готовы анализаторы совместимости protobuf и enum, примеры и скрипты воспроизведения опубликованных экспериментов. DUPChecker разрешено запускать как основной анализатор, используя примеры для проверки окружения.
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** статическая проверка изменений схем находит потенциальные межверсионные несовместимости, которые обычная проверка каждой версии по отдельности не обнаруживает.
 - **Технический результат:** Подготовить воспроизводимый анализатор зафиксированных пар выпусков для 2–3 открытых систем, реализовать простой синтаксический diff как baseline и собрать размеченный набор предупреждений с подтверждениями из истории изменений и тестов. Один сценарий должен запускать оба анализатора на одинаковых входах и формировать сопоставимый отчёт.
+- **Обязательное приращение команды:** Подготовить предусмотренные заданием пары выпусков 2–3 систем, собственный синтаксический diff, разметку предупреждений по истории изменений и тестам и единый сравнительный запуск. Оцениваются обоснованная разметка, сравнение и анализ ошибок обоих вариантов; воспроизведение авторской таблицы служит исходной проверкой.
 - **Эксперимент:** выбрать 2–3 открытые системы, проверить несколько последовательных выпусков, вручную классифицировать предупреждения по истории изменений и тестам и сравнить DUPChecker с простым синтаксическим diff по точности и времени.
 - **Границы выводов:** оценки точности и времени относятся к выбранным системам, выпускам и размеченным предупреждениям; они не характеризуют все виды межверсионной несовместимости и другие форматы схем.
 - **Ресурсный профиль:** локально, CPU, 4–8 ГБ памяти. Если крупный репозиторий неудобно анализировать целиком, использовать зафиксированные пары выпусков и отдельно подготовленный набор совместимых и несовместимых изменений схем.

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

@@ -1,6 +1,6 @@
 # P03-A. Acto: поиск состояний
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,21 +9,29 @@
 - **Кратко о статье:** Операторы 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).
+- **Что уже предоставляет артефакт:** Acto уже генерирует переходы, проверяет достижение состояния, разворачивает операторы и воспроизводит известные ошибки; есть конфигурации и средства сбора статистики. Эти компоненты разрешено использовать, а готовую демонстрационную ошибку — только для проверки стенда. Проверенные исходные материалы: [генераторы](https://github.com/xlab-uiuc/acto/blob/a0d0fb7bb840/docs/test_generator.md), [сбор статистики](https://github.com/xlab-uiuc/acto/blob/a0d0fb7bb840/scripts/collect_statistics.py).
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** генерация последовательностей переходов и сквозная проверка состояния позволяют находить ошибки согласования, которые пропускают отдельные тесты обработчиков и случайная генерация операций.
-- **Технический результат:** Развернуть небольшой оператор и управляемую систему в Kind, подключить генератор переходов Acto и воспроизводимый случайный baseline. Добавить сбор покрытия переходов и автоматическую проверку достижения желаемого состояния.
+- **Технический результат:** Развернуть небольшой оператор и управляемую систему в Kind, подготовить новую конфигурацию и подключить генератор переходов Acto. Самостоятельно реализовать воспроизводимый случайный baseline и расчёт покрытия общей модели переходов, связав их с автоматической проверкой достижения желаемого состояния.
-- **Эксперимент:** На одном операторе выполнить не менее трёх серий систематической и случайной генерации с одинаковым бюджетом. Сравнить покрытие переходов, число уникальных расхождений и время до первого сбоя; для найденного сбоя подтвердить воспроизводимость отдельным тестом.
+- **Обязательное приращение команды:** Подготовить новую конфигурацию выбранного оператора с содержательно отличающимися начальными условиями или сочетанием операций, самостоятельно реализовать случайный baseline и расчёт покрытия общей модели переходов. Провести сравнение на этой конфигурации; изменение имени, seed или числа повторов готовой демонстрации не заменяет её.
+- **Эксперимент:** На новой конфигурации одного оператора выполнить не менее трёх серий систематической и случайной генерации с одинаковым бюджетом. Собственным расчётом сравнить покрытие переходов, число уникальных расхождений и время до первого сбоя; найденный сбой подтвердить отдельным тестом. При отсутствии сбоев зафиксировать исчерпание бюджета без обнаружения; готовая демонстрационная ошибка проверяет только стенд.
 - **Границы выводов:** результат показывает покрытие и обнаружение сбоев для выбранного оператора, модели переходов и бюджета генерации; он не доказывает полноту поиска или корректность оператора во всех конфигурациях.
-- **Ресурсный профиль:** расширенно локально, Linux, Docker, Kind, CPU, желательно 16 ГБ памяти. Если выбранный оператор слишком тяжёл, использовать демонстрационную конфигурацию Cassandra либо собственный минимальный оператор с намеренно внесёнными ошибками согласования.
+- **Ресурсный профиль:** Расширенно локально, Linux, Docker, Kind, CPU, желательно 16 ГБ памяти. Если выбранный оператор слишком тяжёл, использовать малую конфигурацию Cassandra с новым сочетанием операций либо собственный минимальный оператор с намеренно внесёнными ошибками согласования. Собственные случайный baseline и расчёт покрытия обязательны в обоих случаях.
 
 ## Содержательные направления
 
-- оператор и локальный стенд.
+- новая конфигурация оператора и локальный стенд.
-- генератор переходов и стратегии обхода.
+- самостоятельный случайный baseline и сопоставление стратегий.
-- проверки состояния, уменьшение сбоев и сравнительный анализ.
+- собственный расчёт покрытия, проверка состояния и анализ сбоев.
 
 ## Возможное продолжение
 
 Перенести Acto на новый оператор, добавить новый тип перехода или вид проверки, исследовать раннюю остановку либо автоматическое уменьшение ошибочной последовательности.
+
+## История уточнений
+
+| Дата | Версия | Основание | Изменение обязательного результата |
+|---|---|---|---|
+| 07.09.2026 | 1.1 | Статический просмотр закреплённого артефакта: готовые сценарии частично покрывают задание. | Закреплены новая конфигурация, собственные случайный baseline и расчёт покрытия; демонстрационная ошибка служит проверке стенда. |

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

@@ -1,6 +1,6 @@
 # P03-B. Acto: проверки и уменьшение
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,11 +9,13 @@
 - **Кратко о статье:** Операторы 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).
+- **Что уже предоставляет артефакт:** Acto предоставляет генерацию и проигрывание последовательностей, встроенные проверки, конфигурации операторов и примеры ошибок. Их можно использовать как стенд и исходные тестовые последовательности.
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** Сквозная проверка состояния и автоматическое уменьшение последовательности превращают сбой оператора в воспроизводимый диагноз; качество результата зависит от полноты наблюдаемого состояния и правил эквивалентности сценариев.
 - **Технический результат:** Развернуть небольшой оператор и управляемую систему в Kind. Реализовать две независимые проверки — достижения желаемого состояния и предметного инварианта — и средство уменьшения ошибочной последовательности с сохранением сбоя.
+- **Обязательное приращение команды:** Реализовать предусмотренные заданием две проверки и средство структурного уменьшения с сохранением сбоя, собрать набор из не менее пяти ошибок и сравнить его с исходными последовательностями и удалением суффикса. Собственные проверки и алгоритм уменьшения оцениваются отдельно от встроенных возможностей Acto.
 - **Эксперимент:** На наборе не менее чем из пяти известных или намеренно внесённых ошибок сравнить исходные последовательности без уменьшения как baseline, удаление суффикса и структурное уменьшение. Измерить долю воспроизведённых сбоев, длину результата, число перезапусков, время и ложные срабатывания проверок.
 - **Границы выводов:** качество проверок и уменьшения оценивается на выбранных известных или намеренно внесённых ошибках; результат не определяет точность на неизвестных естественных сбоях и других операторах.
 - **Ресурсный профиль:** расширенно локально, Linux, Docker, Kind, CPU, желательно 16 ГБ памяти. Если выбранный оператор слишком тяжёл, использовать демонстрационную конфигурацию Cassandra либо собственный минимальный оператор с намеренно внесёнными ошибками согласования.

project-tasks/p04-legolas.md

@@ -1,6 +1,6 @@
 # P04. Legolas: поиск ошибок частичных отказов по состояниям системы
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,21 +9,29 @@
 - **Кратко о статье:** Ошибки частичных отказов часто проявляются только при редком сочетании внутреннего состояния системы, места сбоя и момента инъекции. Legolas статически анализирует код, выводит абстрактные состояния и использует их для выбора более содержательных точек отказа. Авторы применили систему к шести распределённым системам и нашли 20 новых ошибок. Проект сравнивает управляемую состояниями и случайную инъекцию при одинаковом бюджете запусков.
 - **Почему результат актуален:** репозиторий поддерживает локальную сборку Maven на обычном Linux-стенде; задача управляемой инъекции отказов сохраняется при переходе к новым версиям систем, поскольку проект сравнивает стратегии исследования состояний независимо от фиксированного набора найденных ошибок.
 - **Артефакты и данные:** [OrderLab/Legolas](https://github.com/OrderLab/Legolas) под Apache-2.0, со статическим анализатором, инструментированием Java-кода, оркестратором экспериментов и примерами для ZooKeeper. Зафиксированные ревизии: `OrderLab/Legolas@84278d313f98` (Apache-2.0).
+- **Что уже предоставляет артефакт:** Готовы инструментирование, драйверы ZooKeeper, оркестратор и отчёты, а также случайная `RandomPolicy` и стратегии по состояниям. Их разрешено использовать как основу сравнения; повторная реализация готовых стратегий не обязательна. Проверенные исходные материалы: [готовые эксперименты](https://github.com/OrderLab/Legolas/blob/84278d313f98/scripts/experiment/README.md), [RandomPolicy](https://github.com/OrderLab/Legolas/blob/84278d313f98/injector/src/main/java/edu/umich/order/legolas/injector/policy/RandomPolicy.java).
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** выбор точек отказа по выведенным состояниям быстрее и стабильнее обнаруживает ошибки частичных отказов, чем случайная инъекция при том же бюджете запусков.
-- **Технический результат:** Развернуть малую конфигурацию ZooKeeper, инструментировать её средствами Legolas и реализовать два режима инъекции — случайный и управляемый состояниями. Общий исполнитель должен фиксировать состояние, место инъекции и исход запуска, определять сбой по явному критерию и объединять повторения одного дефекта.
+- **Технический результат:** Развернуть малую конфигурацию ZooKeeper, инструментировать её средствами Legolas и подключить случайную и управляемую состояниями стратегии инъекции. Дополнить готовые scripts новой нагрузкой или классом инъекции и собственным предметным критерием сбоя, например проверкой сохранности подтверждённых записей после восстановления. Общий исполнитель должен фиксировать состояние, место инъекции и исход запуска и объединять повторения одного дефекта.
-- **Эксперимент:** на малой конфигурации ZooKeeper воспроизвести один опубликованный сценарий, затем сравнить случайную и управляемую состояниями инъекцию по времени до первого сбоя, числу уникальных сбоев и доле полезных запусков.
+- **Обязательное приращение команды:** Добавить отсутствующую в готовых сценариях нагрузку ZooKeeper или новый класс инъекции и самостоятельно реализовать предметный критерий сбоя по операциям и результатам. Сравнить обе стратегии на добавленном сценарии при одинаковом бюджете и проверить срабатывания критерия независимо от авторского reporter.
+- **Эксперимент:** Воспроизвести опубликованный сценарий для проверки стенда, затем сравнить обе стратегии на добавленном сценарии при одинаковом бюджете по времени до первого сбоя, числу уникальных сбоев и доле полезных запусков. Проверить критерий на корректном и заведомо нарушенном поведении; отсутствие найденных дефектов допустимо при обоснованной проверке и анализе.
 - **Границы выводов:** преимущество стратегии инъекции проверяется на малой конфигурации ZooKeeper и выбранном наборе классов и исключений; оно не означает полного покрытия дефектов или той же эффективности на производственном кластере.
-- **Ресурсный профиль:** расширенно локально, Linux, Java, Maven, CPU, желательно 16 ГБ памяти. Если полный анализ выбранной системы слишком тяжёл, использовать ZooKeeper и ограниченный набор классов и исключений, сохранив сравнение стратегий.
+- **Ресурсный профиль:** Расширенно локально, Linux, Java, Maven, CPU, желательно 16 ГБ памяти. Если полный анализ слишком тяжёл, ограничить набор классов и исключений ZooKeeper, сохранив новый сценарий, собственный критерий и сравнение стратегий.
 
 ## Содержательные направления
 
-- сборка и инструментирование системы.
+- инструментирование системы и новая нагрузка или класс инъекции.
-- оркестрация отказов и критерии сбоев.
+- оркестрация отказов и независимый предметный критерий сбоя.
-- стратегии выбора состояний, статистика и перенос на новый сценарий.
+- сопоставление стратегий выбора состояний и статистический анализ.
 
 ## Возможное продолжение
 
 Перенести сокращённый конвейер на другую Java-систему, улучшить группировку состояний или предложить стратегию выбора точек, учитывающую историю предыдущих запусков.
+
+## История уточнений
+
+| Дата | Версия | Основание | Изменение обязательного результата |
+|---|---|---|---|
+| 07.09.2026 | 1.1 | Статический просмотр закреплённого артефакта: готовые сценарии частично покрывают задание. | Закреплены новая нагрузка или класс инъекции и независимый предметный критерий; готовые стратегии разрешено использовать. |

project-tasks/p05-sieve.md

@@ -1,6 +1,6 @@
 # P05. SIEVE: простая политика вытеснения веб-кэша
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,11 +9,13 @@
 - **Кратко о статье:** Политика вытеснения веб-кэша должна одновременно давать хорошую долю попаданий и допускать дешёвую конкурентную реализацию. SIEVE использует однобитную отметку востребованности и последовательный указатель вытеснения, поэтому попадания не требуют перестройки общей структуры. Авторы показывают, что простая политика конкурентоспособна с более сложными алгоритмами. Проект проверяет этот результат на нескольких трассах и размерах кэша.
 - **Почему результат актуален:** авторы предлагают очень простую политику вытеснения SIEVE и показывают на веб-трассах, что она часто сочетает высокую скорость с хорошей долей попаданий.
 - **Артефакты и данные:** [cacheMon/NSDI24-SIEVE](https://github.com/cacheMon/NSDI24-SIEVE) с симулятором, прототипами и открытыми трассами. Зафиксированные ревизии: `cacheMon/NSDI24-SIEVE@0861f8261c37` (Apache-2.0).
+- **Что уже предоставляет артефакт:** Артефакт содержит симулятор libCacheSim, реализации политик, прототипы и ссылки на трассы. Их роль — данные и эталон для сопоставления; центральные реализации SIEVE, LRU и третьей политики команда пишет независимо.
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** очень простая политика SIEVE может одновременно давать высокую пропускную способность и меньшую долю промахов, чем существенно более сложные политики, но результат зависит от следа и размера кэша.
 - **Технический результат:** Независимо реализовать SIEVE, LRU и ещё одну сильную политику в общем симуляторе кэша. Симулятор должен читать одинаковый формат трасс, проверять инварианты ёмкости и учёта запросов и формировать сопоставимую статистику попаданий, вытеснений и служебных операций.
+- **Обязательное приращение команды:** Создать уже предусмотренный общий симулятор с тремя собственными политиками, проверкой инвариантов и сопоставимым учётом служебных операций. Подготовить сравнение на нескольких трассах и анализ зависимости от размера кэша; готовые графики служат ориентиром при разборе результатов.
 - **Эксперимент:** на нескольких открытых трассах сравнить SIEVE, LRU и ещё одну сильную политику по доле промахов и служебным операциям, воспроизвести часть результатов статьи и проверить чувствительность к размеру кэша.
 - **Границы выводов:** сравнение характеризует долю попаданий и алгоритмические накладные расходы на выбранных трассах и размерах кэша; без работающего сервера оно не подтверждает производственную пропускную способность и цену синхронизации.
 - **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти; можно использовать подвыборки трасс с проверкой устойчивости выводов.

project-tasks/p06-superbench.md

@@ -1,6 +1,6 @@
 # P06. SuperBench: упреждающая проверка вычислительной инфраструктуры
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,11 +9,13 @@
 - **Кратко о статье:** В крупных кластерах для задач ИИ отдельные компоненты могут деградировать, не вызывая явного отказа, но заметно замедляя распределённые задания. SuperBench объединяет направленные микротесты и проверки на разных этапах жизненного цикла инфраструктуры, чтобы заранее находить такие узлы и локализовать причину. В проекте строится доступный CPU-аналог этого подхода и сравниваются стратегии выбора проверок.
 - **Почему результат актуален:** SuperBench запускает короткие целевые тесты оборудования и коммуникаций до выдачи ресурсов ИИ-задачам, чтобы заранее исключать деградировавшие узлы из кластера.
 - **Артефакты и данные:** [microsoft/superbenchmark](https://github.com/microsoft/superbenchmark) с CPU- и GPU-тестами, профилями и документацией. Зафиксированные ревизии: `microsoft/superbenchmark@2e2c52b80f4e` (MIT).
+- **Что уже предоставляет артефакт:** SuperBench предоставляет тесты, конфигурации, сбор результатов и документацию для проверки инфраструктуры. CPU-тесты и средства их запуска можно использовать в собственном стенде.
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** набор направленных микротестов и обоснованный выбор их поднабора выявляют заданные виды скрытой деградации с меньшей стоимостью, чем неизбирательный запуск всех проверок.
 - **Технический результат:** Собрать CPU-набор проверок вычислений, памяти, диска и сети с управляемыми режимами деградации, единым сбором результатов и простым алгоритмом выбора поднабора тестов. Стенд должен автоматически подтверждать, что нормальный и деградированный режимы действительно различаются по заданным признакам.
+- **Обязательное приращение команды:** Создать управляемые режимы деградации вычислений, памяти, диска и сети, предусмотренную автоматическую проверку их проявления и простой алгоритм выбора поднабора тестов. Сопоставить диагностическую полезность тестов и результат отбора на собственных повторяемых сериях.
 - **Эксперимент:** на CPU построить несколько воспроизводимых режимов деградации, сравнить отдельные тесты и проверить простой алгоритм выбора поднабора проверок; при временном доступе к одной GPU можно добавить отдельную необязательную серию.
 - **Границы выводов:** стенд проверяет различимость заданных CPU-, memory-, disk- и network-деградаций и качество отбора тестов; он не подтверждает диагностику GPU-сбоев или предсказание отказов крупного производственного кластера.
 - **Ресурсный профиль:** локально, CPU, сеть, диск и 8–16 ГБ памяти; GPU не требуется. Обязательная часть проверяет сам механизм отбора и не переносит выводы на крупный AI-кластер.

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

@@ -1,6 +1,6 @@
 # P07-A. DeathStarBench: хвостовая задержка
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,11 +9,13 @@
 - **Кратко о статье:** DeathStarBench — открытый набор сквозных приложений, представляющих типичные графы облачных и edge-микросервисов. Авторы показывают, что зависимости между сервисами, программный стек и совместное использование ресурсов создают узкие места, которые не видны в изолированном микротесте. В этом проекте исследуется распространение задержки по графу и поведение её хвостовых квантилей.
 - **Почему результат актуален:** набор нагрузок продолжает использоваться как открытый стенд для исследований микросервисов. Конкретные зависимости отдельных приложений могут устаревать, поэтому перед проектом фиксируется собираемая версия. Выводы ограничиваются исследуемым графом сервисов и не распространяются на весь современный облачный стек.
 - **Артефакты и данные:** [delimitrou/DeathStarBench](https://github.com/delimitrou/DeathStarBench) под Apache-2.0, с несколькими приложениями, контейнерами и генераторами нагрузки. Зафиксированные ревизии: `delimitrou/DeathStarBench@6ecb09706140` (Apache-2.0).
+- **Что уже предоставляет артефакт:** DeathStarBench предоставляет приложения, контейнерные конфигурации, генераторы нагрузки и средства наблюдения. Их разрешено использовать как объект эксперимента и основу измерительного стенда.
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** при приближении графа микросервисов к насыщению хвостовая задержка растёт заметнее средней, а трассировка критического пути позволяет локализовать сервис, причинно влияющий на этот рост.
 - **Технический результат:** Развернуть сокращённый сквозной граф Hotel Reservation или Social Network, добавить генератор нагрузки, трассировку запросов и сбор метрик по каждому сервису.
+- **Обязательное приращение команды:** Организовать описанные серии ступенчатой нагрузки со сквозной трассировкой и метриками сервисов, локализовать узкое место и подтвердить его влияние контролируемым изменением ресурса. Оценивается собственная причинная проверка на сопоставимых сериях.
 - **Эксперимент:** Провести ступенчатую нагрузку от ненасыщенного режима до перегрузки не менее чем в трёх сериях. Сопоставить медиану, p95/p99, очереди и загрузку ресурсов; локализовать хотя бы одно узкое место и подтвердить причинность контролируемым изменением его ресурса.
 - **Границы выводов:** причинный анализ относится к выбранному сокращённому графу сервисов, нагрузке и локальным ограничениям ресурсов; он не воспроизводит хвостовые задержки полной производственной конфигурации DeathStarBench.
 - **Ресурсный профиль:** расширенно локально, Docker, CPU, желательно 16–32 ГБ памяти. Запасной вариант — оставить один опубликованный сервис и уменьшить число реплик, сохранив сквозной граф вызовов.

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

@@ -1,6 +1,6 @@
 # P07-B. DeathStarBench: размещение и интерференция
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,11 +9,13 @@
 - **Кратко о статье:** DeathStarBench — открытый набор сквозных приложений, представляющих типичные графы облачных и edge-микросервисов. Поведение приложения зависит от отдельных сервисов, их взаимодействия с аппаратными ресурсами и программным стеком. В этом проекте исследуется, как размещение сервисов и фоновая конкуренция меняют сквозную хвостовую задержку.
 - **Почему результат актуален:** набор нагрузок продолжает использоваться как открытый стенд для исследований микросервисов. Конкретные зависимости отдельных приложений могут устаревать, поэтому перед проектом фиксируется собираемая версия. Выводы ограничиваются исследуемым графом сервисов и не распространяются на весь современный облачный стек.
 - **Артефакты и данные:** [delimitrou/DeathStarBench](https://github.com/delimitrou/DeathStarBench) под Apache-2.0, с несколькими приложениями, контейнерами и генераторами нагрузки. Зафиксированная основная ревизия: `delimitrou/DeathStarBench@6ecb09706140` (Apache-2.0).
+- **Что уже предоставляет артефакт:** Готовы приложения, контейнеры, нагрузки и средства наблюдения DeathStarBench. Их разрешено использовать как основу стенда; готовые конфигурации размещения служат исходными вариантами.
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** Совместное размещение и фоновая конкуренция меняют хвостовую задержку сквозного запроса в зависимости от структуры графа; равномерное распределение CPU не всегда даёт лучший результат.
 - **Технический результат:** Развернуть один сокращённый сквозной граф DeathStarBench, добавить управляемое размещение контейнеров, фоновую CPU- и memory-нагрузку и трассировку критического пути.
+- **Обязательное приращение команды:** Реализовать предусмотренное управляемое размещение, CPU- и memory-интерференцию и сравнение изолированного, случайного и учитывающего граф размещения. Собрать трассы критического пути и объяснить измеренные изменения при двух уровнях нагрузки и двух видах интерференции.
 - **Эксперимент:** Сравнить изолированное и случайное размещение как baselines с размещением, учитывающим граф, при двух уровнях нагрузки и двух видах интерференции. Выполнить не менее трёх серий; измерить throughput, p50/p95/p99, длины очередей, загрузку ресурсов и вклад сервисов в критический путь.
 - **Границы выводов:** эффект размещения и интерференции проверяется на одном сокращённом графе и доступных локальных узлах; результат не оценивает качество полноценного кластерного планировщика и переносимость политики на производственную топологию.
 - **Ресурсный профиль:** расширенно локально, Docker, CPU, желательно 16–32 ГБ памяти. Запасной вариант — оставить один опубликованный сервис и уменьшить число реплик, сохранив сквозной граф вызовов.

project-tasks/p08-pgval.md

@@ -1,6 +1,6 @@
 # P08. PGVal: сквозная проверка гарантий потоковой обработки
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,21 +9,29 @@
 - **Кратко о статье:** Заявленная системой гарантия обработки потока ещё не доказывает, что входные события дали правильный сквозной результат при сбое. 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).
+- **Что уже предоставляет артефакт:** PGVal содержит топологии, источник, расчёт ожидаемого результата, инфраструктуру и режимы процессных и сетевых отказов, включая потери, дублирование и переупорядочивание. Инфраструктуру и исполнитель отказов можно использовать; готовый benchmark служит исходным сравнением. Проверенные исходные материалы: [сценарий benchmark](https://github.com/jawadtahir/DSPF-BM/blob/d74c9b80a3a1/experiment.yaml), [сетевые отказы](https://github.com/jawadtahir/DSPF-BM/blob/d74c9b80a3a1/operations-playground/faults.sh).
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** заявленной гарантии обработки недостаточно для правильного сквозного результата: надёжность существенно меняется с топологией, разбиением данных, параллелизмом и типом отказа.
-- **Технический результат:** Развернуть локальные Kafka и одну потоковую систему, реализовать воспроизводимый источник, оконную топологию, независимый расчёт ожидаемого результата и управляемую инъекцию отказов. Один сценарий должен запускать нагрузку, вводить выбранный отказ, собирать выход и автоматически сравнивать его с эталоном.
+- **Технический результат:** Развернуть локальные Kafka и одну потоковую систему. Самостоятельно реализовать новую оконную топологию и независимый расчёт ожидаемого результата; инфраструктуру PGVal и воспроизводимый источник можно адаптировать. Добавить управляемый отказ, связанный с этапом обработки новой топологии, например недоступность приёмника между закрытием окна и подтверждением записи результата. Общий запуск должен вводить отказ, собирать выход и автоматически сравнивать его с эталоном.
-- **Эксперимент:** на подготовленном стенде сравнить обычный режим, перезапуск процесса и сетевую задержку по доле правильных результатов, надёжной пропускной способности, задержке и времени восстановления.
+- **Обязательное приращение команды:** Самостоятельно реализовать новую оконную топологию и независимый эталон, а также добавить отсутствующий в готовых сценариях отказ, привязанный к этапу обработки этой топологии. Показать отличия от закреплённых топологий и scripts и сопоставить режимы на одинаковых входных событиях.
+- **Эксперимент:** На одинаковых входных событиях сравнить обычный режим, перезапуск процесса, сетевую задержку и добавленный сценарий по доле правильных результатов, надёжной пропускной способности, задержке и времени восстановления. В отчёте указать, чем новая топология и момент или условие отказа отличаются от готового benchmark; смены значения задержки или процента потерь недостаточно.
 - **Границы выводов:** сквозная гарантия проверяется для одной потоковой системы, выбранной топологии и заданных отказов; выводы не распространяются на все операторы, конфигурации и крупные кластеры поддерживаемых систем.
-- **Ресурсный профиль:** расширенно локально, Docker, CPU, желательно 16 ГБ памяти. Если полный PGVal требует слишком много процессов, сохранить Kafka, одну систему, эталонную проверку результата и два вида отказов на одном компьютере.
+- **Ресурсный профиль:** Расширенно локально, Docker, CPU, желательно 16 ГБ памяти. Если полный PGVal требует слишком много процессов, оставить Kafka и одну систему на одном компьютере и уменьшить нагрузку, сохранив новую топологию, независимый эталон и перечисленные режимы.
 
 ## Содержательные направления
 
-- нагрузка и эталонная проверка результата.
+- новая оконная топология и воспроизводимая нагрузка.
-- потоковая топология и инъекция отказов.
+- независимый эталон результата и метрики корректности.
-- метрики корректности, повторные запуски и исследование новой конфигурации.
+- новый сценарий отказа, повторные запуски и анализ восстановления.
 
 ## Возможное продолжение
 
 Добавить соединение двух потоков, другой приёмник, поздние события, изменение числа разделов либо вторую систему и проверить переносимость выводов статьи.
+
+## История уточнений
+
+| Дата | Версия | Основание | Изменение обязательного результата |
+|---|---|---|---|
+| 07.09.2026 | 1.1 | Статический просмотр закреплённого артефакта: готовые сценарии частично покрывают задание. | Закреплены новая оконная топология, независимый эталон и отказ, связанный с этапом её обработки. |

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

@@ -1,6 +1,6 @@
 # P09-A. FoundationDB: транзакции и отказы
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,11 +9,13 @@
 - **Кратко о статье:** FoundationDB строит распределённую базу вокруг небольшого строго упорядоченного транзакционного ядра, отделяя обработку транзакций, журналирование и хранение данных. Более сложные модели данных реализуются слоями поверх упорядоченного key-value-интерфейса, а архитектура рассчитана на заменяемость внутренних ролей и восстановление после отказов. В этом проекте проверяются транзакционная семантика и поведение сокращённой конфигурации при сбоях.
 - **Почему результат актуален:** статья описывает архитектуру FoundationDB: небольшое транзакционное ядро, разделение ролей хранения и обработки и детерминированную имитацию отказов для проверки системы.
 - **Артефакты и данные:** [apple/foundationdb](https://github.com/apple/foundationdb), открытая система с локальным многопроцессным режимом и детерминированными simulation tests. Зафиксированные ревизии: `apple/foundationdb@ddec61a629a9` (Apache-2.0).
+- **Что уже предоставляет артефакт:** FoundationDB предоставляет транзакционный движок, клиентские API, локальный кластер, тесты и нагрузки. Систему можно использовать как внешнюю зависимость и объект измерения.
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** FoundationDB сохраняет сериализуемость и подтверждённые записи при конфликтующих транзакциях и отказе процесса, хотя рост конфликтности увеличивает число повторов и хвостовую задержку.
 - **Технический результат:** Развернуть малый многопроцессный кластер FoundationDB и реализовать повторяемую нагрузку с конфликтующими транзакциями, журналом исходов и проверкой сериализуемости.
+- **Обязательное приращение команды:** Реализовать предусмотренные нагрузку с управляемой конфликтностью, журнал исходов и проверку сериализуемости; организовать отказ процесса и проверку сохранности подтверждённых записей. Получить собственные сопоставимые серии при трёх уровнях конфликтности.
 - **Эксперимент:** Сравнить не менее трёх уровней конфликтности в штатном режиме и при одном управляемом отказе процесса. Измерить долю конфликтов и повторов, пропускную способность, p95/p99 и время восстановления; отдельно проверить отсутствие потерянных подтверждённых записей.
 - **Границы выводов:** проверяются сериализуемость, конфликты и восстановление для выбранной нагрузки и одного отказа в малом кластере; эксперимент не подтверждает производительность и отказоустойчивость FoundationDB в производственном масштабе.
 - **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти. Сборка всей системы может быть долгой; запасной вариант — использовать готовый выпуск для реального эксперимента и исходный код только для simulation tests.

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

@@ -1,6 +1,6 @@
 # P09-B. FoundationDB: детерминированная имитация
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,11 +9,13 @@
 - **Кратко о статье:** FoundationDB сочетает рабочую распределённую базу с детерминированной имитацией, в которой тот же код выполняется под управляемым временем, сетью и инъекцией отказов. Фиксация начального зерна позволяет точно повторять редкие последовательности событий и отлаживать нарушения инвариантов. В этом проекте воспроизводится принцип детерминированного планирования и сравнивается повторяемость диагностики с обычным многопроцессным запуском.
 - **Почему результат актуален:** статья описывает архитектуру FoundationDB: небольшое транзакционное ядро, разделение ролей хранения и обработки и детерминированную имитацию отказов для проверки системы.
 - **Артефакты и данные:** [apple/foundationdb](https://github.com/apple/foundationdb), открытая система с локальным многопроцессным режимом и детерминированными simulation tests. Зафиксированная основная ревизия: `apple/foundationdb@ddec61a629a9` (Apache-2.0).
+- **Что уже предоставляет артефакт:** FoundationDB уже содержит детерминированный simulation-режим, нагрузки, инъекцию отказов и воспроизведение по seed. Эти механизмы разрешено использовать как стенд.
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** Детерминированная имитация позволяет систематически проверять последовательности отказов и точно воспроизводить редкие нарушения, которые трудно диагностировать в обычном многопроцессном запуске.
 - **Технический результат:** Собрать или использовать зафиксированный simulation-режим FoundationDB, подготовить малую нагрузку, один проверяемый инвариант и сценарии отказов, управляемые seed. Добавить автоматическое повторное проигрывание найденной трассы.
+- **Обязательное приращение команды:** Подготовить предусмотренные нагрузку, инвариант и проверяемое нарушение, организовать сопоставление реальной инъекции с simulation-режимом и автоматически проверять точность повторного проигрывания. Сравнение проводится при двух видах отказа и нескольких seed; один готовый simulation test его не заменяет.
 - **Эксперимент:** Сравнить обычный локальный fault-injection и детерминированную имитацию по числу исследованных сценариев, времени до обнаружения, доле точных повторов и размеру диагностической трассы. Обязательны несколько seed, два вида отказа и намеренно внесённое либо уже известное нарушение.
 - **Границы выводов:** сравнение характеризует воспроизводимость и исследованное пространство для выбранной нагрузки, инварианта и видов отказа; оно не доказывает корректность FoundationDB и не оценивает частоту таких сбоев в эксплуатации.
 - **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти. Сборка всей системы может быть долгой; запасной вариант — использовать готовый выпуск для реального эксперимента и исходный код только для simulation tests.

project-tasks/p10-detock.md

@@ -1,6 +1,6 @@
 # P10. Detock: транзакции между регионами без глобального упорядочивания
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,11 +9,13 @@
 - **Кратко о статье:** Межрегиональные транзакции затрагивают несколько первичных регионов и при высокой конфликтности приводят либо к частым откатам, либо к распределённым взаимоблокировкам. Detock предлагает протоколы управления конкурентностью и детерминированного разрешения взаимоблокировок, сохраняя строгую сериализуемость без глобального упорядочивания всех операций. Проект проверяет этот механизм на сокращённой реализации или дискретно-событийной модели.
 - **Почему результат актуален:** код собирается на обычном Linux-стеке и допускает локальный функциональный запуск; вопрос о цене межрегиональной координации и конфликтов остаётся центральным для геораспределённых транзакционных систем.
 - **Артефакты и данные:** [umd-dslam/Detock](https://github.com/umd-dslam/Detock) под MIT, с C++-реализацией, однопроцессной конфигурацией, многорегиональным стендом и отдельными данными экспериментов. Зафиксированные ревизии: `umd-dslam/Detock@9f75dbdf93b6` (MIT).
+- **Что уже предоставляет артефакт:** Готовы реализация Detock, генерация транзакций и экспериментальные конфигурации. Их можно адаптировать для локального пути либо использовать как эталон при создании модели.
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** графовое управление зависимостями и детерминированное разрешение взаимоблокировок сохраняют строгую сериализуемость и уменьшают потери при высокой конфликтности по сравнению с глобальным упорядочиванием или откатами по тайм-ауту.
 - **Технический результат:** Запустить сокращённую конфигурацию Detock в нескольких локальных процессах либо независимо реализовать его дискретно-событийную модель. Добавить реализации глобального порядка и простой стратегии отката, общий генератор транзакций и автоматическую проверку допустимости и сериализуемости по журналу.
+- **Обязательное приращение команды:** Создать предусмотренный общий стенд Detock, глобального порядка и простой стратегии отката, дополнив его сопоставимыми входами и собственной проверкой допустимости и сериализуемости по журналу. При модельном пути команда реализует сохраняемые механизмы и проверяет модель; при работе с кодом отвечает за локальную адаптацию и сравнение.
 - **Эксперимент:** при выбранном техническом пути сравнить Detock с глобальным порядком и простой стратегией отката, варьируя конфликтность и межрегиональную задержку и контролируя сериализуемость всех результатов.
 - **Границы выводов:** сериализуемость и относительная эффективность проверяются для выбранной модели транзакций, конфликтности и межрегиональной задержки; локальный стенд или модель не подтверждают производительность Detock в реальной глобальной сети.
 - **Ресурсный профиль:** расширенно локально или имитация, Linux, C++, CPU, желательно 16 ГБ памяти. Исходная оценка использует несколько физических узлов; обязательный результат допускает несколько локальных процессов или независимую модель с проверкой сериализуемости по журналу.

project-tasks/p11-clay-codes.md

@@ -1,6 +1,6 @@
 # P11. Clay Codes: восстановление данных с меньшим сетевым обменом
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,14 +9,16 @@
 - **Кратко о статье:** Обычные 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).
+- **Что уже предоставляет артефакт:** Библиотека содержит кодирование и восстановление, тесты побайтовой корректности, CPU-benchmarks и расчёт объёма восстановления. Кодеки разрешено использовать; готовые примеры и формулы служат эталоном для нового стенда. Проверенные исходные материалы: [CPU-benchmark](https://github.com/spool-labs/clay/blob/aa6a1f986866/benches/clay_bench.rs), [восстановление](https://github.com/spool-labs/clay/blob/aa6a1f986866/src/repair.rs).
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** Clay уменьшает объём чтения и сетевой передачи при восстановлении, но выигрывает по полному времени только в режимах, где экономия ввода-вывода превышает дополнительные вычисления и накладные расходы разбиения.
-- **Технический результат:** Создать CPU-стенд, который кодирует одни и те же данные кодами Clay и Рида — Соломона, удаляет один фрагмент и восстанавливает его. Стенд должен автоматически проверять побайтовое равенство результата и учитывать объём чтения и передачи, процессорное и полное время.
+- **Технический результат:** Создать CPU-стенд, который кодирует одинаковые данные кодами Clay и Рида — Соломона, удаляет один фрагмент и восстанавливает его с побайтовой проверкой. Добавить модель чтения и передачи от нескольких помощников с управляемой пропускной способностью и параллелизмом. Учитывать байты по событиям чтения и передачи, сверять их с формулами кода и отдельно измерять CPU-время и оценивать полное время с учётом модели.
-- **Эксперимент:** на одной CPU-машине сравнить Clay и Reed–Solomon при разных параметрах кода, размерах блоков и числе помощников; проверить восстановление одного узла и измерить прочитанные и переданные байты, процессорное и полное время.
+- **Обязательное приращение команды:** Добавить собственную модель чтения и передачи от нескольких помощников с управляемой пропускной способностью и числом параллельных передач. Считать прочитанные и переданные байты по событиям модели и независимо сверять с теоретическими формулами для параметров кода; исследовать, как ограничения меняют выигрыш по времени.
+- **Эксперимент:** Сравнить Clay и Reed–Solomon при разных параметрах кода, размерах блоков и допустимом числе помощников. Для восстановления одного узла варьировать ограничения чтения, сети и параллелизма, проверять учёт байтов по теории и объяснить, в каких режимах экономия передачи даёт выигрыш по полному времени.
 - **Границы выводов:** стенд проверяет корректность восстановления и объём чтения и передачи для выбранных параметров кода; модель сети на одной машине не воспроизводит полное время ремонта в распределённом хранилище с реальными дисками и сетью.
-- **Ресурсный профиль:** локально, Rust, CPU, 8–16 ГБ памяти. Сеть моделируется ограничением пропускной способности или задержкой; при проблемах с библиотекой обязательная часть использует независимый малый кодировщик и аналитически проверяемый объём восстановления.
+- **Ресурсный профиль:** Локально, Rust, CPU, 8–16 ГБ памяти. Чтение и сеть моделируются на одной машине; при проблемах с библиотекой использовать независимый малый кодировщик, сохранив нескольких помощников, ограничения пропускной способности и параллелизма, побайтовую проверку и независимый учёт объёма восстановления.
 
 ## Содержательные направления
 
@@ -26,4 +28,10 @@
 
 ## Возможное продолжение
 
-Найти границу выигрыша при ограничении сети, исследовать неоднородных помощников, несколько отказов, выбор размера фрагмента либо адаптивный выбор кода по наблюдаемой цене CPU и сети.
+Исследовать неоднородных помощников, несколько отказов либо адаптивный выбор кода по наблюдаемой цене CPU и сети.
+
+## История уточнений
+
+| Дата | Версия | Основание | Изменение обязательного результата |
+|---|---|---|---|
+| 07.09.2026 | 1.1 | Статический просмотр закреплённого артефакта: готовые сценарии частично покрывают задание. | Добавлены модель нескольких помощников с ограничениями чтения, сети и параллелизма и независимая сверка байтов с теорией. |

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

@@ -1,6 +1,6 @@
 # P12-A. ClickHouse: отсечение данных
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,11 +9,13 @@
 - **Кратко о статье:** Статья описывает архитектуру 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 — данные, SQL-запросы, конфигурации и скрипты измерений. Их можно использовать как основу стенда и фиксированной нагрузки.
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** порядок данных и пропуск ненужных гранул дают измеримый выигрыш для аналитических запросов, когда фильтр согласован с физической организацией таблицы.
 - **Технический результат:** Развернуть ClickHouse и подготовить уменьшенный ClickBench с двумя физическими вариантами одной таблицы, различающимися ключом сортировки и размером гранул.
+- **Обязательное приращение команды:** Подготовить уже предусмотренные два физических варианта одной таблицы, выполнить одинаковые запросы с прогревом и повторами и самостоятельно объяснить различия через `EXPLAIN` и системные таблицы. Собрать прочитанные строки и байты, CPU и память вместе со временем выполнения.
 - **Эксперимент:** Для не менее чем пяти запросов сравнить варианты хранения по прочитанным строкам и байтам, времени, CPU и памяти. Выполнить прогрев и не менее трёх измеряемых повторов; объяснить результат через `EXPLAIN` и системные таблицы.
 - **Границы выводов:** эффект отсечения данных оценивается для выбранных ключей сортировки, размеров гранул и запросов уменьшенного ClickBench; он не характеризует все оптимизации ClickHouse и производительность распределённого кластера.
 - **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти, готовый бинарный выпуск или контейнер. Полный ClickBench не требуется: объём данных и набор запросов сокращаются с проверкой того, что выбранные режимы остаются различимы.

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

@@ -1,6 +1,6 @@
 # P12-B. ClickHouse: векторизованный конвейер
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,11 +9,13 @@
 - **Кратко о статье:** Статья описывает архитектуру 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 дают данные, запросы, исполняемый движок и измерительные примеры. Они используются как источник входов и эталон результата и трендов.
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** Блочная обработка столбцов уменьшает накладные расходы на строку, но выигрыш зависит от селективности, сложности выражения и размера блока.
 - **Технический результат:** Реализовать эквивалентные row-at-a-time и блочный конвейеры scan–filter–project–aggregate над одним столбцовым набором данных. Проверять результаты обоих вариантов по эталонному запросу ClickHouse.
+- **Обязательное приращение команды:** Самостоятельно реализовать предусмотренные построчный и блочный конвейеры scan–filter–project–aggregate. Создать общий запуск, проверку эквивалентности и измерения при изменении размера блока, селективности и стоимости выражения; ClickHouse остаётся внешним эталоном.
 - **Эксперимент:** Варьировать размер блока, селективность и вычислительную стоимость выражения. Сравнить построчный baseline и блочный конвейер по времени, throughput, CPU, аллокациям и памяти после прогрева минимум в трёх сериях; отдельно сопоставить тренд с профилем эквивалентного запроса ClickHouse.
 - **Границы выводов:** сравнение относится к самостоятельно реализованному конвейеру и выбранному профилю ClickHouse; оно не измеряет вклад векторизации внутри полного движка и не подтверждает производительность распределённых запросов.
 - **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти, готовый бинарный выпуск или контейнер. Полный ClickBench не требуется: объём данных и набор запросов сокращаются с проверкой того, что выбранные режимы остаются различимы.

project-tasks/p13-noria.md

@@ -1,6 +1,6 @@
 # P13. Noria: частично материализованный потоковый граф для веб-приложений
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,11 +9,13 @@
 - **Кратко о статье:** Веб-приложениям нужны быстрые чтения производных представлений, но полная материализация всех результатов требует много памяти и усложняет обновления. 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 предоставляет потоковый движок, частичную материализацию, интерфейсы и нагрузку `vote`. Их можно адаптировать для собственного сравнения либо использовать как эталон малого прототипа.
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** частичная материализация позволяет сохранить быстрые чтения и инкрементальные обновления, расходуя меньше памяти, чем полная материализация результатов всех запросов.
 - **Технический результат:** Подготовить в Noria или собственном малом потоковом прототипе общий граф операторов с тремя режимами: без материализации, с полной и с частичной материализацией. Реализовать одинаковый генератор обновлений и чтений, автоматическую проверку эквивалентности результатов и учёт занятого и восстановленного состояния.
+- **Обязательное приращение команды:** Подготовить описанный общий граф с тремя режимами материализации, одинаковыми обновлениями и чтениями и собственной проверкой эквивалентности. Обеспечить сопоставимый учёт памяти и восстановления состояния и объяснить наблюдаемый компромисс.
 - **Эксперимент:** на локальном стенде или в собственном малом dataflow-прототипе сравнить отсутствие материализации, полную и частичную материализацию для read-heavy нагрузки; измерять задержку чтений и записей, память и стоимость восстановления вытесненного состояния.
 - **Границы выводов:** компромисс памяти и задержки проверяется на выбранном графе операторов и read-heavy-нагрузке; собственный прототип не подтверждает производительность полной реализации Noria и других классов запросов.
 - **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти. Исследовательский код использует старое Rust-окружение; если его сборка блокирует проект, команда независимо реализует ограниченный граф операторов и проверяет тот же механизм на синтетической и веб-нагрузке.

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

@@ -1,6 +1,6 @@
 # P14-A. Flink: режимы контрольных точек
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,11 +9,13 @@
 - **Кратко о статье:** 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).
+- **Что уже предоставляет артефакт:** Flink уже реализует stateful-обработку, выровненные и невыровненные checkpoint, метрики и восстановление. Движок и локальное развёртывание разрешено использовать как основу.
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** асинхронные контрольные точки обеспечивают exactly-once-восстановление состояния с измеримым компромиссом между накладными расходами, задержкой обработки и временем восстановления после отказа.
 - **Технический результат:** Построить stateful-конвейер Flink с повторяемым источником, уникальными идентификаторами событий, файловым приёмником и автоматической проверкой эквивалентности результатов. Автоматизировать противодавление и отказ TaskManager.
+- **Обязательное приращение команды:** Создать предусмотренный конвейер с повторяемыми событиями и файловым приёмником, автоматизировать противодавление и отказ TaskManager и самостоятельно проверять выходные идентификаторы и агрегаты. Провести сопоставимые серии двух режимов checkpoint.
 - **Эксперимент:** Сравнить выровненные и невыровненные контрольные точки при двух уровнях противодавления и одном отказе. Измерить throughput, p95/p99, длительность и размер checkpoint, время восстановления, пропуски, дубликаты и ошибки агрегатов; выполнить не менее трёх серий.
 - **Границы выводов:** накладные расходы и exactly-once-восстановление проверяются для одного локального конвейера, двух режимов противодавления и отказа TaskManager; результат не охватывает внешние источники и приёмники или крупный кластер.
 - **Ресурсный профиль:** одна машина, CPU, 4–8 ГБ памяти и локальная файловая система; Docker и облако необязательны. При нехватке памяти уменьшаются параллелизм и состояние, но сохраняются отдельные процессы, контрольные точки, отказ и автоматическая проверка корректности.

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

@@ -1,6 +1,6 @@
 # P14-B. Flink: rescaling и восстановление
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,11 +9,13 @@
 - **Кратко о статье:** 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).
+- **Что уже предоставляет артефакт:** Flink предоставляет сохранение состояния, restart, rescaling и средства наблюдения. Их разрешено использовать для выполнения и восстановления конвейера.
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** Контрольная точка или savepoint позволяет корректно перераспределить состояние при изменении параллелизма, однако время восстановления и пауза обработки зависят от размера и распределения состояния.
 - **Технический результат:** Построить key-partitioned stateful-конвейер Flink с повторяемым источником, автоматической проверкой эквивалентности результатов и автоматизированным сохранением состояния. Реализовать остановку и восстановление с прежним и изменённым параллелизмом.
+- **Обязательное приращение команды:** Создать описанный key-partitioned-конвейер, повторяемый источник и независимую проверку результатов; автоматизировать сохранение и восстановление с прежним и изменённым параллелизмом. Сравнить предусмотренные три размера состояния и разобрать паузу и корректность восстановления.
 - **Эксперимент:** Для не менее чем трёх размеров состояния сравнить обычный restart без изменения параллелизма как baseline и восстановление с rescaling. Измерить паузу, полное время восстановления, размер сохранения, throughput после запуска, пропуски, дубликаты и ошибки агрегатов; выполнить по три серии.
 - **Границы выводов:** корректность и пауза восстановления измеряются для выбранного stateful-конвейера, размеров состояния и параллелизма на одной машине; результат не характеризует эластичность производственного кластера и удалённого хранилища.
 - **Ресурсный профиль:** одна машина, CPU, 4–8 ГБ памяти и локальная файловая система; Docker и облако необязательны. При нехватке памяти уменьшаются параллелизм и состояние, но сохраняются отдельные процессы, контрольные точки, отказ и автоматическая проверка корректности.

project-tasks/p15-autothrottle.md

@@ -1,6 +1,6 @@
 # P15. Autothrottle: двухуровневое управление ресурсами микросервисов
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,11 +9,13 @@
 - **Кратко о статье:** В графе микросервисов трудно связать сквозной 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; архивирован).
+- **Что уже предоставляет артефакт:** Autothrottle содержит контроллеры, три приложения, трассы и автоматизированную оценку. Разрешено использовать код и нагрузки как основу уменьшенного стенда; опубликованные серии служат исходными материалами.
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** разделение управления на сквозной и локальный уровни позволяет экономить CPU при соблюдении SLO устойчивее, чем фиксированные лимиты и один общий либо только локальные контроллеры.
 - **Технический результат:** Развернуть сокращённый граф из 3–5 сервисов или вариант DeathStarBench, реализовать локальные контроллеры CPU и упрощённый верхний контроллер сквозной цели. Добавить фиксированные лимиты и одноуровневую политику как baselines, общий генератор нагрузки и автоматическую проверку соблюдения SLO.
+- **Обязательное приращение команды:** Реализовать и откалибровать предусмотренное локальное управление CPU и упрощённый верхний контроллер для 3–5 сервисов, подготовить фиксированный и одноуровневый baselines. Собственная работа включает перенос контроля на малый стенд, проверку SLO и сравнение при ступенчатой и переменной нагрузке.
 - **Эксперимент:** на подготовленном графе сравнить двухуровневое управление с фиксированными лимитами и одноуровневой политикой при ступенчатой и переменной нагрузке по соблюдению SLO, потреблению CPU и устойчивости управления.
 - **Границы выводов:** соблюдение SLO и экономия CPU проверяются для сокращённого графа, выбранных нагрузок и упрощённых контроллеров; эксперимент не подтверждает устойчивость исходной политики на крупном производственном кластере.
 - **Ресурсный профиль:** расширенно локально, Linux, Docker или Kubernetes, CPU, желательно 16–32 ГБ памяти. Если DeathStarBench не помещается, использовать собственную цепочку сервисов с реальной очередью и управляемым потреблением CPU; имитация допустима только для дополнительного масштабирования.

project-tasks/p16-oakestra.md

@@ -1,6 +1,6 @@
 # P16. Oakestra: иерархическая оркестрация edge-кластера
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,11 +9,13 @@
 - **Кратко о статье:** Edge-инфраструктура состоит из географически распределённых и неоднородных узлов, поэтому единый центральный оркестратор плохо масштабируется и не всегда видит локальные условия. Oakestra организует управление иерархически: верхний уровень координирует систему, а локальные уровни принимают решения в своих кластерах. В проекте иерархическая политика размещения сравнивается с централизованной на изменяющихся ресурсах и отказах.
 - **Почему результат актуален:** проект продолжает развиваться после публикации и остаётся специализированной открытой платформой для edge orchestration. Проверяемый механизм охватывает распределённое размещение и управление при слабых узлах и нестабильных связях и выходит за пределы конкретного edge-приложения.
 - **Артефакты и данные:** [oakestra/oakestra](https://github.com/oakestra/oakestra) под Apache-2.0, с оркестраторами, worker-компонентами, сетевым слоем и документацией локального развёртывания. Зафиксированные ревизии: `oakestra/oakestra@2d74107a14d8` (Apache-2.0).
+- **Что уже предоставляет артефакт:** Oakestra предоставляет корневой и кластерный оркестраторы, worker-компоненты, сеть и локальное развёртывание. Их можно использовать как реализацию иерархического варианта.
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** делегирование решений по иерархии уменьшает нагрузку на центральный уровень и позволяет учитывать локальные ресурсы, сохраняя приемлемое время размещения сервисов.
 - **Технический результат:** Развернуть корневой оркестратор, один кластерный оркестратор и 2–4 рабочих процесса или контейнера. Реализовать централизованный baseline, общий генератор запросов на размещение и автоматическую проверку ограничений CPU и памяти и фактического назначения сервисов.
+- **Обязательное приращение команды:** Создать предусмотренные централизованный baseline, генератор запросов на размещение и независимую проверку ограничений и фактических назначений. Организовать одинаковые входы и измерения для сравнения двух вариантов на малом стенде.
 - **Эксперимент:** на подготовленном стенде сравнить централизованную и иерархическую политику на серии размещений при ограничениях CPU и памяти, измеряя время решения, успешность размещения, служебный трафик и потребление ресурсов control plane.
 - **Границы выводов:** сравнение проверяет механизм размещения при одном корневом и одном кластерном оркестраторе и 2–4 рабочих узлах; оно не оценивает масштабирование многоуровневой edge-топологии и нестабильность реальной сети.
 - **Ресурсный профиль:** расширенно локально, Linux, Docker, CPU, желательно 16 ГБ памяти. При проблемах со сборкой полного сетевого слоя сохранить реальные компоненты планирования и заменить worker-узлы контролируемыми локальными агентами.

project-tasks/p17-skypilot.md

@@ -1,6 +1,6 @@
 # P17. SkyPilot: планирование заданий между облаками
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,11 +9,13 @@
 - **Кратко о статье:** Облачное задание можно разместить у разных провайдеров, в разных регионах и на разных типах машин, которые различаются ценой и доступностью. SkyPilot выступает межоблачным брокером: подбирает выполнимый план, автоматизирует запуск и при необходимости меняет размещение. В проекте исследуется именно выбор плана по сохранённому каталогу ресурсов без расходов на реальные облачные машины.
 - **Почему результат актуален:** система активно развивается и используется как самостоятельный слой управления облачными заданиями. Статья сохраняет ценность как ясная постановка распределённого выбора ресурсов при различиях цен, квот и доступности, хотя конкретные провайдеры и их тарифы требуют свежего снимка перед экспериментом.
 - **Артефакты и данные:** [skypilot-org/skypilot](https://github.com/skypilot-org/skypilot) под Apache-2.0, с активно развиваемым планировщиком, каталогами ресурсов и поддержкой нескольких облаков и локальных кластеров. Зафиксированные ревизии: `skypilot-org/skypilot@fff7b16adc0c` (Apache-2.0).
+- **Что уже предоставляет артефакт:** SkyPilot предоставляет планировщик, каталоги ресурсов и описания заданий. Планировочные компоненты разрешено использовать без запуска платных ресурсов.
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** совместный выбор облака, региона и ресурсов позволяет чаще находить выполнимое и дешёвое размещение, чем фиксированный провайдер или жадный выбор самого дешёвого типа машины.
 - **Технический результат:** Подготовить автономный планировочный стенд с зафиксированным открытым или синтетическим каталогом ресурсов и набором CPU-заданий. Добавить две простые политики размещения, единый формат планов и проверку ограничений по сроку, региону и ёмкости без запуска платных облачных ресурсов.
+- **Обязательное приращение команды:** Подготовить предусмотренный автономный стенд с фиксированным каталогом, двумя простыми политиками и собственной проверкой планов. Получить сопоставимое сравнение стоимости и допустимости при ограничениях по сроку, региону и ёмкости и дефиците ресурсов.
 - **Эксперимент:** на зафиксированном каталоге сравнить SkyPilot с двумя простыми политиками для CPU-заданий с ограничениями по сроку, региону и ёмкости, измеряя стоимость плана, долю размещённых заданий и устойчивость решения к дефициту ресурсов.
 - **Границы выводов:** качество планов оценивается на зафиксированном каталоге и заданных ограничениях; эксперимент не подтверждает текущие цены и доступность реальных облаков или время исполнения размещённых заданий.
 - **Ресурсный профиль:** локально, CPU, 4–8 ГБ памяти; облачная учётная запись и реальные расходы не требуются. Если интерфейс текущей версии изменится, команда независимо реализует оптимизатор по модели статьи и проверяет его на сохранённом каталоге.

project-tasks/p18-faasm.md

@@ -1,6 +1,6 @@
 # P18. Faasm: WebAssembly-изоляция для stateful serverless
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,11 +9,13 @@
 - **Кратко о статье:** Обычная 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).
+- **Что уже предоставляет артефакт:** Faasm предоставляет runtime, распределённое состояние, локальное развёртывание, примеры функций и тесты. Систему можно использовать как внешнюю среду исполнения.
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** совместное размещение WebAssembly-функций с разделяемой памятью уменьшает стоимость запуска, копирования данных и потребление памяти относительно изолированных процессов или контейнеров с сериализацией состояния.
 - **Технический результат:** В локальном Faasm-кластере реализовать две CPU-функции, которые обмениваются массивом или состоянием через разделяемую память. Подготовить функционально эквивалентный baseline с сериализацией через файл, сокет или Redis, единый запуск и автоматическую проверку равенства результатов.
+- **Обязательное приращение команды:** Создать предусмотренные две CPU-функции с обменом состоянием, эквивалентный baseline с сериализацией и общий проверяющий запуск. Самостоятельно организовать измерения холодного и тёплого режима, копирования и памяти при нескольких уровнях параллелизма.
 - **Эксперимент:** на подготовленных функциях сравнить разделяемую память Faasm с передачей сериализованных данных через файл, сокет или Redis. Измерять холодный и тёплый запуск, задержку, объём копирования, RSS и пропускную способность при нескольких уровнях параллелизма.
 - **Границы выводов:** стоимость обмена состоянием проверяется для двух CPU-функций и выбранного baseline в локальном окружении; результат не оценивает межузловую сеть, многоарендную изоляцию и масштабирование облачного кластера.
 - **Ресурсный профиль:** локально, Linux или Docker, CPU, желательно 16 ГБ памяти. Если распределённый режим нестабилен, обязательная часть сохраняет реальные Faaslets и разделяемую память на одном узле, а межузловой обмен исследуется в отдельной модели с калибровкой по локальным измерениям.

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

@@ -1,6 +1,6 @@
 # P19. Serverless Cold Starts: проверка обобщений на производственных трассах
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,21 +9,29 @@
 - **Кратко о статье:** Авторы анализируют месячную производственную трассу 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).
+- **Что уже предоставляет артефакт:** Опубликованы трассы, агрегаты, схемы и `src/demo_cold_start.ipynb` с загрузкой, CDF по регионам, временными рядами и группировкой функций. Код загрузки можно повторно использовать; готовые графики и группировки служат исходной точкой. Проверенные исходные материалы: [демонстрационный notebook](https://github.com/sir-lab/data-release/blob/84a9d7727aef/src/demo_cold_start.ipynb), [схема данных](https://github.com/sir-lab/data-release/blob/84a9d7727aef/README_data_release_2025.md).
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** частота cold start и связанные с ней наблюдаемые характеристики заметно различаются между регионами, функциями и периодами; популярные упрощённые модели не описывают весь производственный набор.
-- **Технический результат:** Создать воспроизводимый конвейер загрузки, проверки, нормализации и выборки открытых трасс холодных запусков. Конвейер должен фиксировать происхождение данных, одинаково строить группы по периоду, региону и популярности и автоматически воспроизводить выбранные таблицы и графики.
+- **Технический результат:** Создать воспроизводимый конвейер загрузки, проверки, нормализации и выборки трасс холодных запусков с фиксацией происхождения данных. Дополнить воспроизведение графиков собственным расчётом устойчивости по периодам, регионам и популярности, альтернативной нормализацией и анализом влияния агрегации или исключения части данных.
-- **Эксперимент:** на доступной части трасс воспроизвести 2–3 основных наблюдения статьи и проверить, сохраняются ли они на разных периодах, регионах и группах популярности.
+- **Обязательное приращение команды:** Создать собственный конвейер проверки устойчивости 2–3 наблюдений по периодам, регионам и популярности с альтернативной нормализацией. Для одного наблюдения сопоставить веса по событиям и равные веса функций на общем наборе, затем оценить влияние укрупнения временной агрегации или контролируемого исключения части данных.
+- **Эксперимент:** Воспроизвести 2–3 наблюдения статьи и проверить устойчивость по периодам, регионам и популярности на доступных данных. Для одного наблюдения сравнить веса по событиям с равными весами функций на общем наборе, затем укрупнить временную агрегацию либо контролируемо исключить часть данных и оценить изменение вывода. Искусственное исключение данных характеризует чувствительность и не оценивает реальную долю пропусков.
 - **Границы выводов:** наблюдения относятся к доступным периодам, регионам и выбранной части опубликованных трасс; статистические связи не устанавливают причины cold start и не описывают текущее состояние всех облачных платформ.
-- **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти; использовать агрегированные файлы или стратифицированную выборку, если полный объём не помещается. Выводы ограничивать выбранной частью данных.
+- **Ресурсный профиль:** Локально, CPU, 8–16 ГБ памяти; использовать агрегаты или стратифицированную выборку, если полный объём не помещается. Выбрать наблюдения, для которых опубликованы необходимые числители, знаменатели и разрезы; данные отдельных запросов не предполагаются доступными за все периоды. Сокращённый путь сохраняет сравнение нормализаций и анализ чувствительности.
 
 ## Содержательные направления
 
-- подготовка и аудит данных.
+- подготовка, аудит данных и альтернативная нормализация.
-- воспроизведение статистик.
+- воспроизведение наблюдений и устойчивость по разрезам.
-- модель или политика и проверка переноса.
+- влияние агрегации или пропусков на выводы.
 
 ## Возможное продолжение
 
-Построить и честно оценить простую модель риска cold start, проверить устойчивость агрегирования либо смоделировать одну политику keep-alive.
+Построить и честно оценить простую модель риска cold start либо смоделировать одну политику keep-alive.
+
+## История уточнений
+
+| Дата | Версия | Основание | Изменение обязательного результата |
+|---|---|---|---|
+| 07.09.2026 | 1.1 | Статический просмотр закреплённого артефакта: готовые сценарии частично покрывают задание. | Добавлены альтернативная нормализация и проверка влияния агрегации или исключения данных на устойчивость наблюдений. |

project-tasks/p20-cloudcast.md

@@ -1,6 +1,6 @@
 # P20. Cloudcast: стоимость и скорость многоадресной передачи между облаками
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,11 +9,13 @@
 - **Кратко о статье:** Репликация большого набора данных сразу в несколько облачных регионов ограничена пропускной способностью и платой за исходящий трафик. Cloudcast строит оверлейное дерево с промежуточными узлами, учитывая цены и измеренную скорость каналов при заданном сроке передачи. В проекте оптимизатор сравнивается с прямой репликацией и простыми деревьями на воспроизводимой модели сети.
 - **Почему результат актуален:** Cloudcast строит прикладное дерево многоадресной передачи между облачными регионами, совместно учитывая пропускную способность, цены трафика и ограничения виртуальных машин.
 - **Артефакты и данные:** статья сообщает, что Cloudcast опубликован как часть открытого проекта [Skyplane](https://github.com/skyplane-project/skyplane) с подключаемыми алгоритмами планирования; в зафиксированной ревизии доступны планировщик и решатели. Центральный оптимизатор также можно воспроизвести независимо по псевдокоду и модели стоимости. Зафиксированная ревизия: `skyplane-project/skyplane@4602d9cec208` (Apache-2.0).
+- **Что уже предоставляет артефакт:** Skyplane предоставляет компоненты планирования и решатели; статья описывает модель стоимости и оптимизацию Cloudcast. Их разрешено использовать как основу оптимизатора или эталон независимой реализации.
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** промежуточные узлы и разбиение данных позволяют уменьшить стоимость исходящего трафика при заданном сроке передачи по сравнению с прямой репликацией.
 - **Технический результат:** Реализовать модель малой межрегиональной топологии и три построителя плана передачи: оптимизатор Cloudcast, прямую звезду и минимальное остовное дерево. Стенд должен проверять связность дерева, ограничения пропускной способности, стоимость и выполнение заданного срока на общих матрицах входных данных.
+- **Обязательное приращение команды:** Создать предусмотренную модель общей топологии, варианты прямой звезды и минимального остовного дерева, единый расчёт стоимости и времени и независимую проверку допустимости. Сравнить планы на одинаковых матрицах и объяснить различия и ограничения.
 - **Эксперимент:** на опубликованных либо синтетических матрицах стоимости и пропускной способности сравнить Cloudcast с прямой звездой и минимальным остовным деревом по стоимости, сроку передачи и допустимости плана.
 - **Границы выводов:** модель проверяет стоимость и выполнимость планов на выбранных матрицах цен и пропускной способности; она не учитывает всю изменчивость реальных межоблачных каналов, тарифов и времени запуска узлов.
 - **Ресурсный профиль:** имитация, CPU, 4–8 ГБ памяти; платные межоблачные передачи не нужны. Допустимы небольшие локальные измерения между контейнерами для проверки модели исполнения.

project-tasks/p21-dbsp-feldera.md

@@ -1,6 +1,6 @@
 # P21. DBSP/Feldera: инкрементальное выполнение запросов
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,21 +9,29 @@
 - **Кратко о статье:** Повторное выполнение полного запроса после каждого изменения данных тратит работу на уже известный результат. DBSP задаёт алгебраическую модель потоковых вычислений и преобразует пакетную программу в инкрементальную, которая обновляет представление по дельте входа и состояния. В проекте такой план сравнивается с полным пересчётом при разных размерах обновлений.
 - **Почему результат актуален:** DBSP перестал быть только теоретическим прототипом и развивается внутри Feldera. Механизм автоматической инкрементализации актуален для совмещения потоковой обработки, materialized views и аналитики над меняющимися данными.
 - **Артефакты и данные:** идеи статьи реализованы в активно развиваемой системе [Feldera](https://github.com/feldera/feldera), объединяющей SQL-компилятор и потоковую среду выполнения. Зафиксированная ревизия: `feldera/feldera@ab74092c6a0c` (MIT для открытой редакции; лицензии сторонних компонентов и данных проверяются отдельно).
+- **Что уже предоставляет артефакт:** Feldera предоставляет SQL-компилятор, инкрементальный движок, примеры и benchmarks, включая соединения и агрегации. Его разрешено использовать как сравниваемую систему и эталон; готовый движок не заменяет малую реализацию команды. Проверенные исходные материалы: [проверка join и aggregate](https://github.com/feldera/feldera/blob/ab74092c6a0c/python/tests/workloads/test_aggregate_join.py), [benchmarks](https://github.com/feldera/feldera/blob/ab74092c6a0c/benchmark/README.md).
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** инкрементальная программа выполняет работу, зависящую преимущественно от размера изменения и затронутого состояния, и поэтому выигрывает у полного пересчёта при достаточно малых обновлениях.
-- **Технический результат:** Реализовать в Feldera или собственном малом инкрементальном движке зафиксированные запросы с фильтрацией, агрегацией и соединением. Добавить пакетный пересчёт как baseline, общий генератор обновлений и автоматическую проверку эквивалентности результатов после каждой серии.
+- **Технический результат:** Независимо реализовать малый инкрементальный движок для зафиксированных запросов с фильтрацией, агрегацией и соединением; хотя бы один запрос должен сочетать соединение и агрегацию. Добавить Feldera и полный пакетный пересчёт как сравниваемые варианты, общий генератор обновлений и автоматическую проверку эквивалентности после каждой серии.
-- **Эксперимент:** на сериях обновлений сравнить инкрементальное выполнение с полным пересчётом для запросов с фильтрацией, агрегацией и соединением, измеряя время, память и порог, после которого преимущество исчезает.
+- **Обязательное приращение команды:** Независимо реализовать инкрементальное обслуживание хотя бы одного запроса, сочетающего соединение и агрегацию. Сопоставить его с Feldera и полным пакетным пересчётом на одинаковых обновлениях, проверяя эквивалентность после каждой серии.
+- **Эксперимент:** Сравнить собственное инкрементальное выполнение, Feldera и полный пересчёт на одинаковых запросах и сериях обновлений. Измерить время и память, проверить эквивалентность и определить режимы, в которых преимущество инкрементального подхода исчезает.
 - **Границы выводов:** преимущество инкрементального выполнения проверяется для выбранных операторов, запросов и серий обновлений; результат не характеризует полный SQL и распределённую производительность Feldera на производственных данных.
-- **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти. Если полный стек Feldera слишком тяжёл, обязательная часть использует самостоятельно реализованный набор операторов и проверяет эквивалентность результата пакетному вычислению.
+- **Ресурсный профиль:** Локально, CPU, 8–16 ГБ памяти. При высокой стоимости стека Feldera уменьшить данные и запросы для контрольного сравнения трёх вариантов; основные серии собственного движка и полного пересчёта можно провести отдельно на большем объёме. Независимая реализация запроса с соединением и агрегацией сохраняется.
 
 ## Содержательные направления
 
-- запросы, данные и пакетный пересчёт.
+- запросы, общий генератор и пакетный пересчёт.
-- инкрементальный конвейер и проверка корректности.
+- собственный инкрементальный движок и проверка корректности.
-- профилирование состояния, границы применимости и новый режим.
+- сравнение с Feldera, профилирование и границы применимости.
 
 ## Возможное продолжение
 
 Исследовать перекос ключей, размер пакета обновлений, поздние исправления, стоимость хранения состояния либо запрос, для которого автоматическая инкрементализация даёт неожиданно слабый результат.
+
+## История уточнений
+
+| Дата | Версия | Основание | Изменение обязательного результата |
+|---|---|---|---|
+| 07.09.2026 | 1.1 | Статический просмотр закреплённого артефакта: готовые сценарии частично покрывают задание. | Собственный инкрементальный запрос с соединением и агрегацией обязателен; Feldera и полный пересчёт служат сравнению. |

project-tasks/p22-dctcp.md

@@ -1,6 +1,6 @@
 # P22. DCTCP: управление перегрузкой в сети дата-центра через ECN
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -8,22 +8,30 @@
 - **Основная статья:** 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 конкурирующих потоков, несколько узких мест и собирает пропускную способность, справедливость и длину очередей. Для независимой реализации фиксируются версии всех зависимостей и использованных наборов данных.
+- **Артефакты и данные:** [пример DCTCP в ns-3.45](https://github.com/nsnam/ns-3-dev-git/blob/4059af204636298c061df368e241941fa3ff97bf/examples/tcp/dctcp-example.cc) под GPL-2.0 моделирует ECN-коммутаторы, 40 конкурирующих потоков, несколько узких мест и собирает пропускную способность, справедливость и длину очередей. Зафиксированная ревизия: `nsnam/ns-3-dev-git@4059af204636298c061df368e241941fa3ff97bf` (ns-3.45, GPL-2.0). Для дополнительных зависимостей и данных также фиксируются версии.
+- **Что уже предоставляет артефакт:** В закреплённом примере ns-3 уже есть ECN-очереди, выбор TCP, топология, долгоживущие потоки, throughput, fairness и длина очередей. Пример и реализации TCP можно использовать как основу; собственная работа охватывает конечные потоки, анализ чувствительности и проверку механизма. Проверенные исходные материалы: [пример ns-3.45](https://github.com/nsnam/ns-3-dev-git/blob/4059af204636298c061df368e241941fa3ff97bf/examples/tcp/dctcp-example.cc).
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** пропорциональная реакция на ECN позволяет DCTCP поддерживать меньшие очереди и хвостовые задержки, чем обычный TCP, сохраняя высокую загрузку канала при смешанных потоках.
-- **Технический результат:** Подготовить параметризованный сценарий ns-3 с ECN-коммутатором, DCTCP и TCP Cubic или NewReno, генераторами incast и смешанных потоков. Стенд должен проверять доставку заданного объёма данных и собирать время завершения потоков, длину очереди, загрузку канала и справедливость.
+- **Технический результат:** Подготовить параметризованный сценарий ns-3 с ECN-коммутатором, DCTCP и TCP Cubic или NewReno, собственными генераторами incast и смешанных конечных потоков. Проверять доставку заданного объёма, собирать время завершения, загрузку и справедливость, а также синхронизированные трассы отметок ECN, окна TCP и длины очереди для независимой проверки механизма.
-- **Эксперимент:** воспроизвести пример ns-3 и сравнить DCTCP с TCP Cubic или NewReno при incast и смеси коротких и длинных потоков по времени завершения, p95/p99, длине очереди, загрузке и справедливости.
+- **Обязательное приращение команды:** Создать генераторы incast и смешанных конечных потоков, измерение времени завершения и проверку доставки. Провести анализ чувствительности к порогу ECN и интенсивности incast; независимо сопоставить отметки ECN, изменение окна TCP и динамику очереди на общем времени по собранным трассам.
+- **Эксперимент:** Воспроизвести пример ns-3 для проверки стенда, затем сравнить DCTCP с TCP Cubic или NewReno при incast и смеси коротких и длинных потоков по времени завершения, p95/p99, длине очереди, загрузке и справедливости. Обязательно варьировать порог ECN и интенсивность incast; по трассам независимо проверить связь отметок, реакции окна и изменения очереди и разобрать отклонения.
 - **Границы выводов:** эксперимент проверяет поведение модели DCTCP в ns-3 для заданной топологии и потоков; он не воспроизводит особенности конкретных сетевых карт, коммутаторов и трафика крупного дата-центра.
-- **Ресурсный профиль:** локальная имитация, CPU, 4–8 ГБ памяти. Если полная топология даёт слишком длинные серии, уменьшить число потоков и длительность, сохранив ECN, два режима нагрузки, несколько повторов и проверку загрузки канала.
+- **Ресурсный профиль:** Локальная имитация, CPU, 4–8 ГБ памяти. При длинных сериях уменьшить число потоков и длительность, сохранив два режима нагрузки, несколько повторов, изменение порога ECN и интенсивности incast и проверку механизма по трассам.
 
 ## Содержательные направления
 
-- топология и проверка модели.
+- топология и независимая проверка механизма ECN по трассам.
-- генераторы нагрузок и базовые варианты TCP.
+- генераторы конечных потоков и базовые варианты TCP.
-- метрики, статистический анализ и новые режимы.
+- метрики и чувствительность к порогу ECN и интенсивности incast.
 
 ## Возможное продолжение
 
-Исследовать чувствительность к порогу ECN, размеру буфера, числу отправителей, неоднородным RTT или сосуществованию DCTCP и обычного TCP.
+Исследовать чувствительность к размеру буфера, неоднородным RTT или сосуществованию DCTCP и обычного TCP.
+
+## История уточнений
+
+| Дата | Версия | Основание | Изменение обязательного результата |
+|---|---|---|---|
+| 07.09.2026 | 1.1 | Статический просмотр закреплённого артефакта: готовые сценарии частично покрывают задание. | Закреплена ns-3.45; добавлены чувствительность к порогу ECN и интенсивности incast и независимая проверка механизма. |

project-tasks/p23-pagedattention.md

@@ -1,6 +1,6 @@
 # P23. PagedAttention: управление памятью KV-кэша
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,11 +9,13 @@
 - **Кратко о статье:** При обслуживании 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).
+- **Что уже предоставляет артефакт:** vLLM предоставляет реализацию PagedAttention и обработку запросов; код и опубликованные измерения служат эталоном механизма. В обязательном CPU-пути команда создаёт собственные аллокаторы и обработчик.
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** блочное размещение KV-кэша уменьшает фрагментацию и позволяет обслуживать больший динамический пакет запросов, чем непрерывное резервирование памяти.
 - **Технический результат:** Реализовать минимальный исполняемый обработчик авторегрессионных запросов на CPU с взаимозаменяемыми непрерывным и страничным аллокаторами KV-кэша. Добавить планирование динамического пакета, проверку инвариантов размещения и учёт реально выделенной памяти и отказов.
+- **Обязательное приращение команды:** Реализовать предусмотренные непрерывный и страничный аллокаторы над реально выделенными массивами, динамический пакет и проверку инвариантов. Подготовить собственный поток запросов и сопоставимые измерения памяти, фрагментации, отказов и задержки.
 - **Эксперимент:** на подготовленном обработчике и реально выделяемых массивах сравнить непрерывный и страничный аллокаторы по занятой памяти, внутренней фрагментации, отказам размещения, размеру динамического пакета и задержке.
 - **Границы выводов:** стенд проверяет управление памятью и планирование динамического пакета на CPU; он не оценивает GPU-ядро PagedAttention, качество модели и сквозную производительность полноценного LLM-сервера.
 - **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти; вместо большой модели допустим детерминированный генератор токенов, но обязательный результат включает работающий аллокатор и обработчик запросов. Имитация используется только для расширения масштаба; небольшая GPU-проверка необязательна.

project-tasks/p24-llumnix.md

@@ -1,6 +1,6 @@
 # P24. Llumnix: динамическое перепланирование LLM-запросов
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,11 +9,13 @@
 - **Кратко о статье:** При одноразовом назначении 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).
+- **Что уже предоставляет артефакт:** Llumnix содержит перепланирование, миграцию, benchmark-сценарии и режим симуляции на профилях. Эти материалы разрешено использовать как источник профилей и эталон поведения собственной CPU-модели.
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** перенос активного запроса вместе с KV-состоянием позволяет выравнивать загрузку, устранять фрагментацию и поддерживать приоритеты лучше одноразового назначения.
 - **Технический результат:** Построить дискретно-событийный симулятор нескольких экземпляров с профилями запросов, очередями, стоимостью миграции и тремя политиками: статическое назначение, least-loaded и перепланирование Llumnix. Добавить проверки сохранения запросов и согласованности учёта времени и очередей.
+- **Обязательное приращение команды:** Построить предусмотренную собственную дискретно-событийную модель очередей и миграции с тремя политиками, проверкой сохранения запросов и учёта времени. Сопоставить политики при неоднородных длинах и интенсивности; готовый режим симуляции служит проверке модели.
 - **Эксперимент:** в симуляторе сравнить статическое назначение, least-loaded и перепланирование Llumnix при неоднородных длинах и интенсивности запросов по времени ожидания, нарушению SLO, использованию памяти и числу миграций.
 - **Границы выводов:** выводы относятся к очередям, профилям и стоимости миграции, заданным в симуляторе; без GPU-стенда они не подтверждают фактическую цену переноса KV-кэша и соблюдение SLO в реальном LLM-сервисе.
 - **Ресурсный профиль:** имитация, CPU и 4–8 ГБ памяти; полное авторское воспроизведение требует 16 GPU, поэтому обязательная часть проверяет алгоритмический механизм и калибрует стоимость по опубликованным данным.

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

@@ -1,6 +1,6 @@
 # P25-A. Ray: динамические графы задач
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,11 +9,13 @@
 - **Кратко о статье:** Приложения машинного обучения сочетают динамические графы коротких задач с долгоживущим изменяемым состоянием, которое неудобно выражать в традиционных пакетных системах. Ray объединяет удалённые функции и акторы в одном распределённом движке с масштабируемым планированием и восстановлением. В этом проекте исследуются накладные расходы и масштабирование динамических графов задач.
 - **Почему результат актуален:** Ray объединяет задачи и акторы в одном распределённом runtime, рассчитанном на динамические графы вычислений, возникающие в обучении с подкреплением и других ИИ-приложениях.
 - **Артефакты и данные:** [ray-project/ray](https://github.com/ray-project/ray), открытая система с локальным кластерным режимом и актуальной документацией. Зафиксированные ревизии: `ray-project/ray@2ff4d94078ee` (Apache-2.0).
+- **Что уже предоставляет артефакт:** Ray предоставляет исполнение задач, планировщик, object store, локальный кластер и примеры. Их можно использовать как измеряемую среду исполнения.
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** единый динамический движок задач и акторов способен поддерживать высокую частоту коротких задач и сложные зависимые вычисления без специализированного планировщика для каждого приложения.
 - **Технический результат:** Подготовить локальный кластер Ray, генератор динамических DAG из коротких CPU-задач и сопоставимый baseline на процессном пуле. Добавить трассировку постановки, ожидания и исполнения задач.
+- **Обязательное приращение команды:** Создать предусмотренный генератор динамических DAG, сопоставимый процессный baseline, общий эталон результатов и трассировку ожидания и исполнения. Провести серии по гранулярности, ширине и глубине графа и объяснить накладные расходы.
 - **Эксперимент:** Варьировать гранулярность, ширину и глубину графа; сравнить Ray и baseline по времени выполнения, накладным расходам планирования, загрузке CPU и масштабированию. Для каждого режима выполнить не менее трёх серий и проверить равенство результатов.
 - **Границы выводов:** накладные расходы планирования измеряются для коротких CPU-задач и выбранных DAG на одном компьютере; результат не характеризует многоузловое масштабирование, неоднородные ресурсы и восстановление Ray после отказов.
 - **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти; масштаб статьи не воспроизводится, проверяется механизм на одном компьютере с несколькими процессами.

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

@@ -1,6 +1,6 @@
 # P25-B. Ray: акторы и восстановление
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,11 +9,13 @@
 - **Кратко о статье:** Приложения машинного обучения сочетают динамические графы задач с долгоживущим изменяемым состоянием. Ray предоставляет для них общую модель удалённых функций и акторов, дополняя её распределённым планированием, объектным хранилищем и механизмами восстановления. В этом проекте исследуется граница между состоянием актора, повторным выполнением задач и внешним сохранением данных при сбоях.
 - **Почему результат актуален:** Ray объединяет задачи и акторы в одном распределённом runtime, рассчитанном на динамические графы вычислений, возникающие в обучении с подкреплением и других ИИ-приложениях.
 - **Артефакты и данные:** [ray-project/ray](https://github.com/ray-project/ray), открытая система с локальным кластерным режимом и актуальной документацией. Зафиксированная основная ревизия: `ray-project/ray@2ff4d94078ee` (Apache-2.0).
+- **Что уже предоставляет артефакт:** Ray предоставляет акторы, выполнение задач и механизмы перезапуска. Их разрешено использовать как runtime для собственного приложения; политику сохранения прикладного состояния задаёт команда.
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** Модель акторов упрощает долгоживущее изменяемое состояние, но гарантии восстановления и цена повторного выполнения зависят от границы между состоянием актора, задачами и внешним хранилищем.
 - **Технический результат:** Реализовать локальное приложение из нескольких stateful-акторов и клиентов с журналом операций, контрольными суммами и управляемыми падениями. Добавить как минимум две стратегии восстановления состояния.
+- **Обязательное приращение команды:** Создать предусмотренное приложение с журналом и контрольными суммами, две стратегии восстановления и процессный baseline. Организовать управляемые отказы worker и актора, независимую проверку конечного состояния и учёт потерянных, повторных операций и повторной работы.
 - **Эксперимент:** Сравнить restart без внешнего состояния, checkpoint/replay и простой процессный baseline при отказе worker и актора. Измерить время восстановления, потерянные или повторные операции, p95/p99, объём повторной работы и правильность конечного состояния минимум в трёх сериях.
 - **Границы выводов:** гарантии и цена восстановления проверяются для выбранного приложения акторов, стратегий хранения и локальных отказов; результат не устанавливает общую семантику долговечности Ray и поведение крупного кластера.
 - **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти; масштаб статьи не воспроизводится, проверяется механизм на одном компьютере с несколькими процессами.

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

@@ -1,6 +1,6 @@
 # P26-A. Parrot: планирование графа
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,11 +9,13 @@
 - **Кратко о статье:** LLM-приложение часто состоит из зависимых вызовов модели, но обычный сервис видит их как отдельные непрозрачные запросы и не может учитывать общий критический путь. Parrot вводит семантические переменные, раскрывающие зависимости и повторно используемый контекст, и планирует весь граф приложения. В этом проекте графовое планирование сравнивается с последовательной и простой очередной обработкой.
 - **Почему результат актуален:** Parrot добавляет в интерфейс LLM-сервиса семантические переменные, которые раскрывают зависимости между вызовами и структуру промптов для совместной оптимизации всего приложения.
 - **Артефакты и данные:** [microsoft/ParrotServe](https://github.com/microsoft/ParrotServe) под MIT, с клиентской частью, примерами составных приложений, планировщиком и тестами. Зафиксированные ревизии: `microsoft/ParrotServe@2e1825ee2bc3` (MIT).
+- **Что уже предоставляет артефакт:** ParrotServe содержит семантические переменные, исполнитель, планировщик, примеры составных приложений и тесты. Эти материалы служат образцом интерфейсов и эталоном зависимостей для собственного CPU-сервиса.
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** знание графа вызовов и общих префиксов позволяет сервису распараллеливать независимые запросы, переиспользовать состояние и оптимизировать время выполнения приложения лучше, чем при обработке непрозрачных запросов по отдельности.
 - **Технический результат:** Реализовать исполняемый сервис составного приложения с семантическими переменными, реальной очередью и двумя DAG, содержащими последовательные и независимые вызовы. Исполнитель должен поддерживать последовательную и графовую политики.
+- **Обязательное приращение команды:** Реализовать предусмотренный сервис с реальной очередью и двумя DAG, политики последовательного, пакетного и графового выполнения и проверки зависимостей. Собрать собственные сквозные измерения по времени приложения, ожиданию и загрузке.
 - **Эксперимент:** Сравнить последовательное выполнение, обычную пакетную обработку и планирование по критическому пути при нескольких уровнях параллелизма. Измерить полное время приложения, p95, загрузку исполнителей и ожидание узлов; проверить корректность зависимостей и выполнить не менее трёх серий.
 - **Границы выводов:** эффект планирования графа проверяется для двух составных DAG и локального исполнителя с измеряемой стоимостью вызовов; он не характеризует качество LLM, GPU-планирование и производственную нагрузку Parrot.
 - **Ресурсный профиль:** локально, CPU, до 16 ГБ памяти; вызов LLM можно заменить малой локальной моделью или детерминированной функцией с измеряемым временем, но сам исполнитель и планировщик должны работать на реальных запросах. Симулятор допустим только для масштабных серий.

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

@@ -1,6 +1,6 @@
 # P26-B. Parrot: префиксы и локальность
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,11 +9,13 @@
 - **Кратко о статье:** В LLM-приложениях разные вызовы часто используют общие части промптов, однако обычный сервис не знает ни об этой связи, ни о зависимостях между запросами. Parrot представляет значения семантическими переменными и использует открывшийся граф для переиспользования контекста и совместного планирования. В этом проекте исследуется компромисс между локальностью общих префиксов и балансировкой очередей.
 - **Почему результат актуален:** Parrot добавляет в интерфейс LLM-сервиса семантические переменные, которые раскрывают зависимости между вызовами и структуру промптов для совместной оптимизации всего приложения.
 - **Артефакты и данные:** [microsoft/ParrotServe](https://github.com/microsoft/ParrotServe) под MIT, с клиентской частью, примерами составных приложений, планировщиком и тестами. Зафиксированная основная ревизия: `microsoft/ParrotServe@2e1825ee2bc3` (MIT).
+- **Что уже предоставляет артефакт:** ParrotServe предоставляет семантические переменные, планирование и примеры приложений. Код и описание используются как эталон взаимодействия запросов и общего префикса.
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** Знание общих частей промптов позволяет уменьшать повторные вычисления, но политика локальности может конфликтовать с балансировкой очередей и критическим путём приложения.
 - **Технический результат:** Реализовать исполнитель составных запросов с явными семантическими переменными, блочным кэшем префиксов и двумя политиками маршрутизации: least-loaded и prefix-aware. Допустима малая локальная модель или детерминированная функция с измеряемой стоимостью.
+- **Обязательное приращение команды:** Реализовать предусмотренные CPU-исполнитель, блочный кэш и маршрутизацию least-loaded и prefix-aware. Подготовить собственную параметризованную нагрузку, проверку изоляции результатов и измерения попаданий, повторной работы и времени приложения.
 - **Эксперимент:** Варьировать долю общих префиксов, размер кэша, интенсивность и перекос запросов. Сравнить least-loaded baseline и prefix-aware-политику по hit rate, объёму повторной работы, полному времени приложения, p95 и загрузке исполнителей минимум в трёх сериях; проверить правильность изоляции результатов разных запросов.
 - **Границы выводов:** компромисс локальности и балансировки проверяется для выбранной модели стоимости, кэша и распределения префиксов; результат не подтверждает совместимость реального KV-кэша модели и производительность GPU-сервера.
 - **Ресурсный профиль:** локально, CPU, до 16 ГБ памяти; вызов LLM можно заменить малой локальной моделью или детерминированной функцией с измеряемым временем, но сам исполнитель и планировщик должны работать на реальных запросах. Симулятор допустим только для масштабных серий.

project-tasks/p27-dede.md

@@ -1,6 +1,6 @@
 # P27. DeDe: декомпозиция задач распределения ресурсов
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,11 +9,13 @@
 - **Кратко о статье:** Крупные задачи распределения ресурсов в облаке перерастают возможности универсальных решателей, а специализированные алгоритмы обычно привязаны к одной системе. DeDe использует общую разделимость многих постановок: разъединяет ограничения ресурсов и запросов и решает чередующиеся подзадачи независимо и параллельно. В проекте этот подход сравнивается с монолитным решением по времени, допустимости и качеству распределения.
 - **Почему результат актуален:** опубликованный пакет предоставляет высокоуровневый интерфейс, тесты и три разные прикладные задачи. Статья свежая, поэтому статус влияния предварительный, но общий механизм не привязан к закрытому кластеру или специальному оборудованию и уже допускает независимую проверку на CPU.
 - **Артефакты и данные:** [illinois-nsai/dede](https://github.com/illinois-nsai/dede) под MIT, доступен как Python-пакет и содержит примеры для кластерного планирования, балансировки нагрузки и управления трафиком. Для обязательного сравнения достаточно свободного решателя CVXPY; Gurobi не требуется. Зафиксированные ревизии: `illinois-nsai/dede@11c97f786a1e` (MIT).
+- **Что уже предоставляет артефакт:** DeDe предоставляет библиотеку декомпозиции и готовые примеры оптимизационных задач. Их можно использовать как основу модели; свободный решатель CVXPY остаётся допустимым baseline.
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** разделение связанных ограничений на подзадачи для ресурсов и запросов ускоряет решение крупных задач распределения, сохраняя допустимость и качество результата относительно монолитного решателя.
 - **Технический результат:** Формализовать одну задачу кластерного размещения или балансировки нагрузки и реализовать её в DeDe и как монолитную модель CVXPY. Подготовить общий генератор входов, проверку допустимости решения и единый расчёт целевой функции и невязок.
+- **Обязательное приращение команды:** Формализовать предусмотренную задачу и подготовить её сопоставимые DeDe- и монолитную модели, общий генератор и независимую проверку допустимости и цели. Самостоятельно исследовать время, невязки и масштабирование; готовое toy-сравнение без этих результатов недостаточно.
 - **Эксперимент:** для выбранной задачи на открытых или синтетических данных сравнить DeDe и монолитное решение CVXPY по времени, целевой функции, невязкам и масштабированию по числу ресурсов и запросов.
 - **Границы выводов:** сравнение относится к одной формализации задачи, выбранным входам и размерам, доступным точному решателю; оно не устанавливает преимущество DeDe для других задач распределения и производственных масштабов.
 - **Ресурсный профиль:** локально, CPU, Python, 8–16 ГБ памяти. Если высокоуровневый интерфейс нестабилен на большой задаче, использовать опубликованные низкоуровневые примеры и уменьшить размер, сохранив сравнение с точным решением на тех же входах.

project-tasks/p28-distserve.md

@@ -1,6 +1,6 @@
 # P28. DistServe: раздельное выполнение prefill и decode
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,21 +9,29 @@
 - **Кратко о статье:** Обработка 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).
+- **Что уже предоставляет артефакт:** Готовый `simdistserve` содержит очереди, workers, профили, генерацию запросов, варианты DistServe и vLLM, goodput и сценарии оценки. Он используется только как эталон и источник профилей; центральную событийную модель команда пишет независимо. Проверенные исходные материалы: [simdistserve](https://github.com/LLMServe/DistServe/blob/82831f1604cc/simdistserve/README.md), [модель worker](https://github.com/LLMServe/DistServe/blob/82831f1604cc/simdistserve/base/worker.py).
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** разделение prefill и decode увеличивает goodput при одновременных ограничениях на TTFT и TPOT, если выигрыш от независимого масштабирования превышает стоимость передачи KV-кэша.
-- **Технический результат:** Реализовать CPU-симулятор фаз prefill и decode с очередями, профилями выполнения и моделью сети. Добавить совместное и раздельное размещение, общий генератор запросов и проверки сохранения запросов, пропускной способности и разложения задержки по фазам.
+- **Технический результат:** Независимо реализовать уменьшенный CPU-симулятор фаз prefill и decode с очередями, профилями и моделью сети. Добавить совместное и раздельное размещение, общий генератор запросов, журнал событий и проверки сохранения запросов, пропускной способности и разложения задержки. Разрешены библиотеки событийной симуляции; готовые модель очередей, workers и планировщик simdistserve используются только как эталон.
-- **Эксперимент:** на профилях или синтетической модели сравнить совместное и раздельное размещение для нескольких распределений длин входа и выхода, явно варьируя пропускную способность сети и проверяя обе задержки и goodput.
+- **Обязательное приращение команды:** Создать независимый уменьшенный CPU-симулятор фаз и сети с совместным и раздельным размещением, журналом событий и проверками сохранения запросов и времени. На контрольных сценариях сопоставить его с авторским симулятором при согласованных профилях и допущениях и разобрать расхождения.
+- **Эксперимент:** Сначала сопоставить собственный и авторский симуляторы на контрольных сценариях при одинаковых профилях и согласованных допущениях, объяснив расхождения. Затем сравнить совместное и раздельное размещение для нескольких распределений длин входа и выхода, варьируя пропускную способность сети и проверяя TTFT, TPOT и goodput.
 - **Границы выводов:** выигрыш раздельного выполнения определяется профилями и сетевой моделью симулятора; без GPU-стенда он не подтверждает фактические TTFT, TPOT, goodput и цену передачи KV-кэша в DistServe.
-- **Ресурсный профиль:** локально, CPU и 8–16 ГБ памяти для имитации; полная система требует как минимум два GPU и остаётся необязательной. Калибровку можно провести по опубликованным профилям и небольшому локальному измерению.
+- **Ресурсный профиль:** Локально, CPU, 8–16 ГБ памяти для собственного и авторского симуляторов; полная система с как минимум двумя GPU остаётся необязательной. Использовать опубликованные профили; для контрольного сравнения согласовать учитываемые задержки и ограничения, а дополнительные сетевые режимы исследовать отдельно в собственной модели.
 
 ## Содержательные направления
 
-- модель фаз и профили.
+- независимая модель фаз и проверка по авторскому симулятору.
-- политики размещения и маршрутизации.
+- политики размещения, маршрутизации и корректность событий.
 - SLO, сетевые ограничения и анализ чувствительности.
 
 ## Возможное продолжение
 
 Динамически переключать совместный и раздельный режим, учитывать неоднородные ускорители, искать неблагоприятные режимы либо предложить новую политику выбора числа экземпляров каждой фазы.
+
+## История уточнений
+
+| Дата | Версия | Основание | Изменение обязательного результата |
+|---|---|---|---|
+| 07.09.2026 | 1.1 | Статический просмотр закреплённого артефакта: готовые сценарии частично покрывают задание. | Закреплены независимый CPU-симулятор и контрольное сопоставление; simdistserve служит эталоном и источником профилей. |

project-tasks/p29-mooncake.md

@@ -1,6 +1,6 @@
 # P29. Mooncake: глобальный многоуровневый KV-кэш
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,11 +9,13 @@
 - **Кратко о статье:** Для длинных диалогов и повторяющихся префиксов повторный 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).
+- **Что уже предоставляет артефакт:** Mooncake предоставляет передачу данных, кэш и открытые трассы запросов с хешами блоков. Трассы используются как вход, а готовые компоненты — как источник устройства и эталон для локального стенда.
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** глобальное хранение KV-блоков может выгодно заменить повторный prefill для длинных общих префиксов, но результат определяется пропускной способностью хранилища, конкуренцией за сеть и политикой допуска в кэш.
 - **Технический результат:** Построить из нескольких процессов общий блочный кэш поверх RAM и локального SSD с сетевым чтением, вытеснением и предварительной загрузкой. Добавить локальный LRU и модель повторного вычисления, проигрыватель открытых трасс и проверку целостности возвращаемых блоков.
+- **Обязательное приращение команды:** Построить предусмотренный многопроцессный блочный кэш RAM/SSD с сетевым чтением, вытеснением и предзагрузкой; добавить локальный LRU, модель повторного вычисления и проверку целостности. Собственная работа включает проигрывание одинаковых трасс и сопоставимые измерения кэша.
 - **Эксперимент:** на подготовленном блочном кэше и открытых трассах сравнить глобальную политику с локальным LRU и повторным вычислением по доле попаданий, переданным байтам, задержке и goodput.
 - **Границы выводов:** стенд проверяет политики блочного кэша на RAM, SSD и локальной сети при заданной стоимости повторного вычисления; он не воспроизводит RDMA, GPU-prefill и конкуренцию производственного кластера Mooncake.
 - **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти, несколько процессов; RDMA и GPU не требуются. Стоимость prefill задаётся реальной малой функцией или калиброванной задержкой, а при тяжёлой трассе используется воспроизводимая подвыборка.

project-tasks/p30-pollux.md

@@ -1,6 +1,6 @@
 # P30. Pollux: совместная адаптация обучения и кластерного планировщика
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,11 +9,13 @@
 - **Кратко о статье:** Скорость обучения зависит от числа выделенных ускорителей и размера пакета. Размер пакета меняет системную производительность и статистическую эффективность оптимизации. 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).
+- **Что уже предоставляет артефакт:** Закреплённая версия AdaptDL предоставляет планировщик заданий и библиотеку адаптивного обучения. Код и опубликованные профили можно использовать как основу упрощённого Pollux и для сопоставления; обязательный исполнитель малых CPU-задач создаёт команда.
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** совместный учёт системной скорости и статистической эффективности обучения позволяет перераспределять ресурсы с меньшим средним временем завершения, сохраняя справедливость между задачами.
 - **Технический результат:** Создать исполнитель нескольких малых CPU-задач обучения как реальных процессов и три планировщика: фиксированный, простой динамический и упрощённый Pollux с изменением параллелизма и размера пакета. Добавить единый журнал событий, проверку завершения задач и расчёт goodput, JCT и справедливости.
+- **Обязательное приращение команды:** Создать предусмотренный исполнитель реальных малых CPU-задач, фиксированный и простой динамический baselines и упрощённый Pollux. Самостоятельно связать изменение параллелизма и пакета с журналом, проверкой завершения и измерением goodput, JCT и справедливости; одних готовых имитационных серий недостаточно.
 - **Эксперимент:** на нескольких наборах одновременно выполняющихся задач сравнить фиксированное распределение, простую динамическую политику и упрощённый Pollux, измеряя goodput, JCT и справедливость.
 - **Границы выводов:** сравнение относится к малым CPU-задачам, упрощённой модели goodput и выбранным политикам; оно не подтверждает статистическую эффективность и время завершения много-GPU-обучения в производственном кластере.
 - **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти; достаточно малых моделей и наборов данных, поэтому несколько реальных задач входят в обязательную часть. Синтетические профили используются для калибровки и расширения масштаба; при несовместимости артефакта планировщик реализуется независимо.

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

@@ -1,6 +1,6 @@
 # P31-A. GC3: корректность расписаний
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,11 +9,13 @@
 - **Кратко о статье:** Быстрые коллективные операции для 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).
+- **Что уже предоставляет артефакт:** MSCCL-tools предоставляет DSL, компилятор, алгоритмы коллективных операций, примеры и встроенные проверки. Их разрешено использовать для записи и компиляции расписаний и как источник положительных примеров.
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** явное описание алгоритма на уровне блоков вместе с компиляторными преобразованиями позволяет безопасно получать специализированные конвейерные коллективы без ручного написания низкоуровневого GPU-кода.
 - **Технический результат:** Выразить ring AllReduce и один AllToAll в MSCCLang, построить независимый эталон семантики блоков и автоматическую проверку полученного расписания.
+- **Обязательное приращение команды:** Создать предусмотренный независимый эталон семантики блоков и проверку расписаний ring AllReduce и AllToAll. Проверить потери, дублирование, чтение до записи и взаимоблокировку на положительных и не менее трёх испорченных расписаниях; встроенная проверка DSL не заменяет эталон команды.
 - **Эксперимент:** Для нескольких размеров топологии проверить отсутствие потерь, дублирования, чтения до записи и взаимоблокировки, затем сопоставить IR и имитационную стоимость с эталонным расписанием. Обязательны положительные тесты и не менее трёх намеренно испорченных расписаний.
 - **Границы выводов:** проверка относится к семантике блоков, выбранным коллективам и сгенерированному IR; без исполнения на GPU она не подтверждает производительность расписаний и корректность низкоуровневого runtime.
 - **Ресурсный профиль:** локально, CPU и 4–8 ГБ памяти для компиляции и имитации; исполнение через MSCCL на нескольких GPU необязательно и не входит в минимальный результат.

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

@@ -1,6 +1,6 @@
 # P31-B. GC3: оптимизация под топологию
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,11 +9,13 @@
 - **Кратко о статье:** Быстрые коллективные операции для 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).
+- **Что уже предоставляет артефакт:** MSCCL-tools предоставляет DSL, компилятор и исходные расписания. Их можно использовать как формат и baselines для собственной CPU-модели.
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** Специализированное расписание, учитывающее топологию и параллельные каналы, может сократить критический путь коллектива без изменения его семантики.
 - **Технический результат:** Построить CPU-симулятор топологии и расписаний MSCCLang, реализовать хотя бы одно преобразование порядка, разбиения или назначения каналов. Корректность каждого результата проверяется независимой моделью движения блоков.
+- **Обязательное приращение команды:** Построить предусмотренный симулятор топологии и расписаний, реализовать преобразование и независимую проверку движения блоков. Сравнить исходное и преобразованное расписания на двух топологиях и нескольких размерах сообщения, включая чувствительность к параметрам.
 - **Эксперимент:** Сравнить исходный ring либо AllToAll и оптимизированное расписание на двух топологиях и нескольких размерах сообщения. Измерить критический путь, переданные байты, загрузку узких каналов и число шагов; проверить корректность и устойчивость к изменению параметров.
 - **Границы выводов:** выигрыш оценивается по модели критического пути на двух заданных топологиях; он не учитывает все эффекты реальной сети, GPU-ядер и конкуренции каналов при исполнении коллектива.
 - **Ресурсный профиль:** локально, CPU и 4–8 ГБ памяти для компиляции и имитации; исполнение через MSCCL на нескольких GPU необязательно и не входит в минимальный результат.

project-tasks/p32-alea-bft.md

@@ -1,6 +1,6 @@
 # P32. Alea-BFT: асинхронная репликация с византийскими отказами
 
-- **Версия и дата проверки:** 1.0, 05.09.2026.
+- **Версия и дата проверки:** 1.1, 07.09.2026.
 - **Статус:** готово к назначению.
 
 ## Статья и исходные материалы
@@ -9,20 +9,22 @@
 - **Кратко о статье:** Классические 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 по официальной странице проекта; файл лицензии в репозитории отсутствует).
+- **Что уже предоставляет артефакт:** Готовы протоколы, клиенты, benchmark service, конфигурации отказов и метрик; `bench` задаёт сетевую задержку. Прототип запускается как внешняя зависимость с учётом ограничения лицензии ниже; готовые benchmark-серии служат исходным сравнением. Проверенные исходные материалы: [bench](https://github.com/diogoantunes25/AleaBFT/blob/543786ef199a/bench), [серии экспериментов](https://github.com/diogoantunes25/AleaBFT/blob/543786ef199a/experiments.py).
 
 ## Обязательный результат
 
 - **Проверяемый вопрос или утверждение:** двухступенчатый конвейер сохраняет прогресс при непредсказуемых задержках и отказах без настройки таймаутов и даёт меньшую задержку, чем сравниваемые асинхронные протоколы в части режимов.
-- **Технический результат:** Развернуть 4–7 локальных процессов Alea-BFT и хотя бы одного опубликованного baseline, подготовить общий клиент и управляемую инъекцию задержек, потерь и crash-отказов. Стенд должен автоматически проверять единый порядок доставки, отсутствие потерь подтверждённых запросов и прогресс допустимого числа реплик.
+- **Технический результат:** Развернуть 4–7 локальных процессов Alea-BFT и хотя бы одного опубликованного baseline. Создать внешний генератор нагрузки и управляемых отказов и независимую проверку по журналам доставки: единый порядок, сохранность подтверждённых запросов и прогресс корректных реплик. Дополнить готовый benchmark сценарием потерь или переупорядочивания сообщений; генератор и проверяющий модуль пишутся независимо от прототипа.
-- **Эксперимент:** на подготовленном стенде сравнить Alea-BFT хотя бы с одним опубликованным baseline при контролируемых задержках, потерях и crash-отказах по порядку доставки, прогрессу, задержке и пропускной способности.
+- **Обязательное приращение команды:** Создать внешний генератор нагрузки и управляемых отказов и независимый проверяющий модуль по журналам доставки. Добавить сценарий потерь или переупорядочивания, отсутствующий в готовых режимах benchmark, с проверкой порядка, сохранности подтверждённых запросов и возобновления прогресса после снятия сетевого нарушения.
+- **Эксперимент:** Сравнить Alea-BFT с baseline при контролируемых задержках, потерях и crash-отказах по порядку доставки, прогрессу, задержке и пропускной способности. Добавленный сценарий потерь или переупорядочивания должен выходить за готовые режимы benchmark. Проверить порядок при нарушении сети и возобновление прогресса после его снятия и восстановления доставки; число crash-отказов ограничить допущениями каждого протокола.
 - **Границы выводов:** безопасность и прогресс проверяются для 4–7 локальных процессов, выбранного baseline и управляемых задержек, потерь и crash-отказов; эксперимент не подтверждает устойчивость ко всем византийским стратегиям и производительность геораспределённого развёртывания.
-- **Ресурсный профиль:** расширенно локально, Linux или Docker, CPU, желательно 16 ГБ памяти. Если полный benchmark service нестабилен, оставить реальные локальные реплики Alea-BFT и один простой baseline, а сетевые режимы задавать через управляемый прокси или `tc netem`.
+- **Ресурсный профиль:** Расширенно локально, Linux или Docker, CPU, желательно 16 ГБ памяти. Если полный benchmark service нестабилен, оставить реальные локальные реплики Alea-BFT и один опубликованный baseline. Собственные внешний генератор и проверяющий модуль сохраняются; новые сетевые режимы можно задавать через управляемый прокси или tc netem.
 
 ## Содержательные направления
 
-- сборка реплик и автоматическая проверка согласованности порядка.
+- локальные реплики и независимая проверка порядка и прогресса.
-- базовый протокол и инъекция отказов.
+- сравниваемый протокол, внешний генератор и сетевые отказы.
-- нагрузка, статистический анализ и новый режим.
+- нагрузочные серии, метрики и статистический анализ.
 
 ## Возможное продолжение
 
@@ -31,3 +33,9 @@
 ## Известное ограничение
 
 На зафиксированной ревизии нет файла лицензии, хотя официальная страница проекта указывает MIT. До появления однозначного файла лицензии исходный код прототипа не копируется в репозиторий команды. Его можно запускать как внешнюю зависимость; изменения реализуются независимо либо после разрешения правообладателя.
+
+## История уточнений
+
+| Дата | Версия | Основание | Изменение обязательного результата |
+|---|---|---|---|
+| 07.09.2026 | 1.1 | Статический просмотр закреплённого артефакта: готовые сценарии частично покрывают задание. | Закреплены внешние генератор и проверка порядка и прогресса и новый сетевой сценарий. |

project.md

@@ -54,9 +54,9 @@
 
 ## Что требуется от проекта
 
-Обязательный объём задаёт назначенное проектное задание. Существовавшие до начала курса код, данные и результаты считаются исходной точкой; оценивается новая работа команды.
+Обязательный объём задаёт назначенное проектное задание. Поле «Что уже предоставляет артефакт» описывает готовые код, данные и сценарии и разрешённое повторное использование. Поле «Обязательное приращение команды» указывает собственные компоненты, эксперименты и проверки. Оно входит в обычную программу проекта; раздел «Возможное продолжение» остаётся необязательным.
 
-Простого запуска готового кода недостаточно. Нужны:
+Сборка, запуск и повторение готового сценария сами по себе не закрывают технический результат. Адаптация засчитывается, когда получен её содержательный результат, прямо указанный в задании. Трудности сборки и несовместимость зависимостей сами по себе не образуют исследовательского результата; диагностика блокировки рассматривается по правилам контрольных точек. От проекта требуются:
 
 - проверяемый технический результат;
 - корректный эксперимент с сопоставимыми вариантами, метриками и повторами;
@@ -81,6 +81,21 @@
 
 Самостоятельная реализация должна явно отделять сохранённые свойства метода от упрощений и иметь автоматическую проверку корректности. Для симулятора нужно описать допущения, проверить его на аналитических примерах, опубликованных данных или доступной реализации и ограничить выводы областью применимости модели. При любом пути сохраняются заданные проверяемый вопрос, baseline, основные показатели и требования к анализу.
 
+## Что предстоит делать, если код уже опубликован?
+
+Рассмотрим [проект P01 Remix по статье EuroSys 2025](project-tasks/p01-remix.md). Авторы предоставляют смешанную спецификацию, демонстрационные трассы и инструменты генерации новых трасс и их проигрывания на ZooKeeper. Команда использует эту базу, чтобы исследовать, как степень детализации модели влияет на стоимость проверки и обнаружение расхождений между моделью и реализацией.
+
+Работа в этом проекте проходит четыре этапа:
+
+1. **Воспроизвести исходный сценарий.** Запустить готовые демонстрационные трассы, сопоставить результат с ожидаемым в авторской инструкции, затем проверить генерацию и проигрывание трасс из модели.
+2. **Разобраться в проверке.** Установить, какие события и ограничения задаёт модель, что означает совпадение при проигрывании и какие свойства остаются вне проверки.
+3. **Подготовить собственное сравнение.** Использовать доступные спецификации как основу грубого, детального и смешанного вариантов с сопоставимыми сценариями и ограничениями поиска. Добавить содержательно новый сценарий ZooKeeper; генерация очередной случайной трассы готовой модели этот шаг не заменяет.
+4. **Провести эксперимент.** Сравнить число состояний, время проверки и расхождения на нескольких сценариях. Хотя бы один результат независимо разобрать по журналам и состоянию ZooKeeper, объяснив соответствие событий модели и реализации.
+
+Подготовка и сравнение грубой, детальной и смешанной спецификаций входят в обязательную работу команды. Полное повторение экспериментов статьи и обнаружение неизвестной ошибки не требуются. Пример иллюстрирует технический путь Remix; в других заданиях роль авторского артефакта определяется их карточками.
+
+Работа развивается через несколько итераций: реализация сценария, проверка его корректности, первые измерения, разбор результатов и уточнение эксперимента. Обратная связь на контрольных точках помогает определить, что нужно доработать. Готовый артефакт помогает пройти этот путь и даёт основу для проверки собственных решений.
+
 ## Ресурсы, данные и лицензии
 
 Каждое выданное задание имеет содержательный обязательный путь на CPU, обычном личном компьютере или бесплатно доступной инфраструктуре. Личные расходы не требуются. По согласованию команда с подтверждённым доступом к GPU может включить GPU-реализацию и эксперименты в обязательный план. Доступ должен сохраняться до окончания проверки, а преподавателю должна быть обеспечена возможность выборочно повторить запуски на сопоставимом ресурсе. Оценка зависит от полученного результата; сам доступ к оборудованию преимуществ не даёт. При утрате доступа команда возвращается к исходному CPU-пути. По согласованию могут быть выделены ресурсы Яндекс Облака, но их наличие, объём и срок не гарантируются.