ТЗ ступени 4 «Перепиши нарезку стенда»: расчет сессии внутри конвейера #236
Assignees
ddmitry (Dmitry Dementiev)
Clear assignees
ddmitry (Dmitry Dementiev)
No Assignees
ddmitry
ddmitry
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: ddmitry/clickstream-data-platform#236
Reference in new issue
Block a user
Part of #206
Цель
Написать ТЗ ступени 4 «Перепиши нарезку стенда» по принятой программе учебных лаб. Урок: изменить расчетную сущность внутри готового конвейера и проверить ее внешним эталоном.
Результат —
docs/labs/4-1-session-pipeline.mdи ссылка в строке ступени 4 вdocs/labs/README.md; диапазон будущих ТЗ становится 5–7.Содержание и границы
sql/dds/session_scope.sql,session_rebuild.sql,session_replace.sql. В этой задаче создается ТЗ, сами SQL сохраняются.dq_check, поштучное сопоставление сVisitIDиз ступени 3 и проверка размещения по шардам черезhostName(). Счетная сверка не подтверждает атрибуты строки и правильность шарда; это объясняется в ТЗ.codex-subagent-playbook: роли Sol/Terra и независимый обзор вместо прежнего обязательного распределения Claude/Fable/Opus.Сначала прочитать
docs/specs/2026-09-01-labs-program.md, ступень 4 и общее правило вычитания.docs/research/2026-08-31-labs-inventory.md, раздел про вычитание DDS-сессии.docs/labs/3-1-sessions-by-hand.mdиdocs/labs/2-1-superset-chart.md.docs/architecture/dds/session.md,docs/architecture/etl.md,docs/architecture/storage.md.sql/dds/session_*.sql,dags/dds_transform.py,sql/dq/sessions_vs_reference.sql.Проверка и приемка
make lintв корне и проверены ссылки; проведено независимое ревью и вычитание лишнего.Результат
Подготовлен PR «ТЗ ступени 4 „Перепиши нарезку стенда“», коммит
49a1565. ТЗ —docs/labs/4-1-session-pipeline.md, индекс лаб ведет на него. Задача остается открытой до слияния PR.Учащийся переписывает три SQL-файла, понимая их договор с дагом. Адресное удаление партиции заставляет конвейер выполнить новый SQL. Проверки сравнивают сохраненный срез, число сессий с
VisitID, границы отдельной сессии и размещение строк по шардам. Повтор без пропущенных дней проверяет штатный пропуск сборки. Если мир ушел вперед, конвейер собирает также последующие прожитые дни.Проверено:
make lint, ссылки,git diff --check. На живом стенде подanalystзапрос сhostName()увидел оба шарда и ноль ошибочно размещенных строк. SQL, даги, DDL, службы и данные не менялись; само упражнение с удалением партиции на общем стенде не выполнялось.Для закрепленной версии ClickHouse
26.3.17.56синтаксис адресногоDROP PARTITION ... ON CLUSTERи замены партиции проверен через Context7 по официальной документации. Выбрано удаление только партиции сессий: исходные события сохраняются, а существующий расчет объема находит пропущенный день.Прогон codex-subagent-playbook
Запрошенные роли: Sol с high — исследование, текст и исправления в одном контексте; свежая Astra с high — независимое ревью и затем узкая перепроверка. Координатор сверил карту и комментарии, создал постановку, проверил ключевые факты и принял результат. Claude не участвовал.
Две находки ревью подтверждены: три типа событий вместо четырех и отсутствие гарантии ровно одной замены партиции. Обе исправлены без дополнительных этапов упражнения. Проход на вычитание сохранил договор SQL, выполнимый запуск и способы самопроверки. Применены
writing-for-agents,ai-text-lintи литературная вычитка; Голос: чисто.Полезным оказалось переиспользование автора для исследования и исправлений, а ревью выявило реальную связь с предыдущей лабой. Лишний расход координатора — первоначальная загрузка больших документов и повторное чтение части материалов. Точных счетчиков токенов по ролям нет; основной расход времени агентов пришелся на техническую сверку и вычитку. Сам скилл не менялся: обсуждение улучшений оставлено на после прогона по просьбе владельца.
Следующее направление карты — ТЗ ступени 5 «Сначала сторож, потом ломай: заказы». Новый тикет сейчас не создается.
Подробности прогона codex-subagent-playbook
Запись для последующего анализа скилла. Это описание одного прогона, а не сравнение моделей в одинаковых условиях. Скилл по итогам не менялся.
Задача и исходные условия
По карте «Реализация учебной программы: документация стенда и ТЗ лаб» требовалось выбрать следующий шаг и выполнить его. После чтения актуальной карты, ее комментария и постановок с резолюциями двух последних задач выбран следующий пункт принятой программы — ТЗ «Перепиши нарезку стенда». Открытых детей карты и PR не было, локальный main совпадал с origin/main. Создана и назначена задача этого прогона, подготовлена отдельная ветка.
Объем результата: новый документ и две правки индекса. SQL, даги, DDL и живые данные в задаче не менялись. Упражнение описывает удаление одной партиции сессий с последующим восстановлением; на общем стенде этот опыт не выполнялся. Проверки исполнения опирались на чтение кода, прав доступа и документации. Запрос размещения строк проверялся живым SELECT.
Кто что делал
session_contract: при запуске запрошеныgpt-5.6-sol,high,fork_turns=none. Сначала исследовал договор SQL и выполнимый путь упражнения. Затем в том же контексте написал ТЗ и поправил индекс. После ревью получил продолжение с полным отчетом и внес исправления. После отзыва Fable ему снова передан разбор замечаний. Других исполнителей он не запускал.lab_review: запрошеныgpt-6-astra,high,fork_turns=none. Получил постановку, точные файлы и базовую версию, самостоятельно читал код. После исправлений продолжил тот же контекст для узкой перепроверки.Это настройки вызовов, не независимое подтверждение фактически обслужившей модели. Встроенные вызовы дали двух агентов; Luna и Claude координатором не запускались. Поэтому формулировка внешнего отзыва «Астра на Астру» неточна: автором был Sol, ревьюером — Astra. При этом обе запрошенные модели одного семейства; свежий контекст не означает различие семейств.
Как передавался материал
Первый агент получил самодостаточное поручение без истории разговора. По мере уточнения координатор передавал короткие дополнения сообщениями. Для технического исследования, отчета реализации, ревью, триажа и перепроверки использовались отдельные файлы в
/tmp. Полные находки передавались исполнителю путем к файлу, без восстановления доказательств из пересказа координатора.Ревьюер не получил историю автора или его отчет. До чтения текста ему предлагалось представить минимально достаточную форму задания. Фокус объединял соответствие программе, техническую выполнимость, читаемость и вычитание лишнего. Координатор сообщил результат своей проверки шардирования; ревьюер повторил SELECT самостоятельно. Это был свежий обзор, но не эксперимент с полностью скрытыми подсказками координатора.
Владельцем двух файлов при написании и исправлениях был один исполнитель. Во время исходного ревью черновик не менялся. Замеченную координатором оговорку отложили до завершения обзора, чтобы ревьюер проверял устойчивую версию.
Первый обзор и приемка
Astra вернула два дефекта:
Обе находки исполнитель подтвердил и исправил за один проход. Перепроверка закрыла обе как соразмерные. Дополнительно «координаты загрузки» заменены на «служебные колонки загрузки». Увеличения области задачи, новых проверок и остановки за разрешением не потребовалось.
Автор применил writing-for-agents, затем ai-text-lint и литературную вычитку. Он вынес плотные объяснения из ячеек таблицы в абзацы. Это облегчило чтение таблицы, но оставило часть повторов между ней и прозой. Заявленный проход на вычитание не привел к достаточному сокращению итогового документа. Координатор и первый ревью приняли результат; последующий отзыв показал пределы этой приемки.
Выполнены make lint, проверки ссылок и git diff --check. Координатор отдельно повторил make lint. Проверка размещения с hostName() дала ноль ошибок на обоих шардах, в том числе под analyst. Синтаксис операций с партициями уточнен через Context7. Эти проверки не доказывают, что учащийся без затруднений пройдет весь текст.
Что добавил отзыв Fable
Владелец передал внешний отзыв уже после публикации PR. Сам запуск Fable и его затраты координатор не наблюдал. В отзыве семь замечаний, три отмечены как желательные до слияния:
Подробные исходы этого разбора будут записаны следующим комментарием после исправления и проверки. Отзыв выявил пропуски, которые не сняли ни самопроверка, ни свежий обзор, ни приемка координатора. Это наблюдение. Объяснение через общую слепоту семейства остается гипотезой: здесь не сравнивались одинаковые задания и бюджеты, а внешний ревьюер видел уже исправленную версию. При этом первоначальное ревью тоже обнаружило ошибку на стыке со ступенью 3 — неверное число замен; говорить, что эта связь совсем не проверялась, было бы неточно.
Расход контекста и времени
Точных счетчиков токенов по агентам, стоимости и времени рассуждения в доступных отчетах нет. Владелец во время работы заметил, что израсходовано почти полокна координатора. Это наблюдение интерфейса со стороны владельца, не измерение всех агентов.
Основные лишние затраты координатора видны по действиям: большие документы и навыки загружались целиком, отдельные выдачи обрезались, часть материала читалась повторно. Даже после делегирования технический отчет был прочитан целиком. Были частые короткие ожидания и проверки наличия файлов, которые почти не добавляли сведений. Загрузка полного отчета не всегда требовалась для решения конкретного вопроса.
Затраты исполнителя: чтение технического договора, написание текста, несколько вычиток и правки после ревью. Затраты ревьюера: независимая сверка источников, подробный отчет, затем узкая перепроверка. По наблюдаемому ходу ожидание этих этапов занимало заметную часть времени, но точных длительностей здесь нет. Часть проверок повторялась между ролями: корневой lint и живой SELECT. Независимость давала основание для проверки, но в следующем прогоне стоит оценить, где достаточно готового журнала.
Отдельные накладные расходы среды: sandbox блокировал DNS/Git, первый SELECT был запущен без контейнерного пароля; повтор с существующими учетными данными прошел. Это не дефекты продукта. Секреты в отчеты не выводились.
Вопросы для последующего разбора скилла
Переиспользование исполнителя для исследования, написания и исправлений оказалось полезным. Свежий обзор дал проверяемые находки, файловая передача упростила триаж. Слабее сработали защита контекста координатора и проверка качества прозы. Решение об изменениях скилла оставлено владельцу после разбора этого случая.
Дополнение: выбор Claude и разгрузка координатора
Владелец спросил, почему в первом прогоне не было ревью Claude. Причина решения координатора: эксперимент с новым playbook был истолкован как повод попробовать исполнение силами Codex; для небольшого ТЗ выбран один свежий обзор Astra с объединенным фокусом. В playbook такой состав допустим, но пользователь Claude не исключал.
Оценка после отзыва: координатор недооценил известную проблему читательской прозы. Размер изменения небольшой, но текст составляет весь результат задачи. Взгляд другого семейства на читаемость и связь между заданиями стоило рассмотреть отдельно. Возможность Claude уже есть в скилле; этот случай сначала стоит разбирать как выбор координатора, а не как отсутствие еще одного обязательного пункта.
По предложению владельца добавлен свежий обзор исправленного текста через Claude CLI. Запрошены Sonnet, high, permission-mode auto. Его фокус — читаемость, преемственность со ступенью 3 и уместность объема. Предыдущие отчеты ему не переданы. Первичный запуск отклонила автоматическая проверка разрешений, ошибочно считая репозиторий приватным. После проверки Gitea API (private:false) тот же запуск с уточненным объемом и запретом чтения секретов разрешен; сессия 137cd100-77c9-4a23-b663-fa69adc52a13. Итог этого обзора будет записан отдельно.
Еще одна гипотеза владельца для следующего прогона: простую механику с репозиторием и тикетами передать Luna или Terra. Возможная граница поручения — чтение задач и комментариев, сверка Git, подготовка и выполнение согласованных операций публикации. Координатор получает короткую сводку состояния, расхождения и пути к доказательствам; сохраняет решения о границах и приемке. Начать можно с Luna, прибегая к Terra при более сложном разборе. Пока это предложение для проверки, не изменение скилла и не установленное правило.
Разрешение владельца на канал ревью Claude
Владелец явно разрешил передачу материалов и предложил добавлять в поручения:
Это действующее разрешение для дальнейших вызовов данного канала. Формулировку следует учитывать при последующем разборе playbook, чтобы техническая проверка разрешений видела уже данное согласие. Сам скилл в этом прогоне не изменен. Разрешение касается материалов ревью; секреты и посторонние файлы в поручение не входят.
Уточнение владельца: модель для ревью Claude
Для ревью явно выбирать Opus. Sonnet владелец оставляет простым подзадачам.
Координатор первоначально запросил Sonnet/high, не уточнив распределение этих ролей по предпочтению владельца. Журнал подтвердил claude-sonnet-5. После уточнения владельца сессия 137cd100-77c9-4a23-b663-fa69adc52a13 остановлена без принятого отчета; ее работа не засчитывается как завершенное ревью.
Запущена новая независимая сессия Opus/high, короткий идентификатор f80776be, с тем же предметом обзора и отдельным отчетом. Предыдущие выводы ей не переданы. Повторное чтение материалов и время остановленного запуска — дополнительные затраты из-за выбора координатора. Предпочтение владельца и явное разрешение канала Claude нужно учитывать при дальнейшем разборе playbook.
Частота наблюдения за ревьюером
Уточнение владельца: проверять ревьюера не чаще одного раза в пять минут — он может долго работать над обзором.
В этом прогоне координатор опрашивал состояние и наличие отчета примерно раз в минуту, а ранее делал короткие ожидания еще чаще. Эти действия почти не добавляли информации и создавали шум. Для дальнейшего разбора playbook стоит сохранить интервал владельца; уведомления о завершении или прямой запрос статуса остаются отдельными поводами обратиться к результату.
Эксперимент с Luna для Git
По прямому предложению владельца подключен субагент
git_delivery: запрошеныgpt-5.6-luna,medium, свежий контекст. Поручение ограничено Git: проверить ветку и изменения, подготовить сообщение коммита, после отдельного сигнала приемки выполнить commit/push и подтвердить опубликованную версию. Содержание документа остается у Sol, решение о приемке — у координатора.Подготовительный этап завершен. При чтении сообщения коммита координатор попросил заменить слово baseline русской формулировкой. Стадирование и публикация ждут приемки текста после ревью Opus.
Следующая гипотеза владельца: повысить reasoning Luna до high — это может улучшить следование инструкциям при небольшой стоимости. Это предложение для проверки, не измеренный эффект. Текущую сессию решено закончить на medium, чтобы сохранить известные условия прогона; менять настройку и заново передавать контекст посреди механического поручения не стали. Итог выполнения Git будет записан после публикации.
Итог исправлений и завершение эксперимента
PR «ТЗ ступени 4 „Перепиши нарезку стенда“» обновлен коммитом
05f4e775e2ab013bd9e6ac43f3963c5cd67b1eb3. Координатор отдельно подтвердил SHA через Gitea API, состав коммита и чистое дерево. PR открыт, слияние доступно; задача закроется при слиянии.Разбор Fable
Все семь пунктов рассмотрены. Смысловые исправления: требования ступени 3 отделены от новых требований конвейера; сохраненный срез сравнивает идентификаторы, границы, длительность и счетчики. Страницы и UTM сверяются отдельно по событиям, поскольку стендовый argMin/argMax не задает выбор при равных метках времени.
Убраны олицетворения, объяснен выбор последнего дня, команда удаления упрощена до ALTER в DBeaver под etl. Формула session_id названа рядом с доводом повторяемости. Попытка убрать повторы в договоре оказалась частично неудачной: из таблицы исчезли нужные имена объектов. Они возвращены после замечания Opus. Это пример того, почему вычитание нужно проверять по удобству работы с документом, а не только по числу удаленных слов.
Что добавил Opus
Первичный свежий обзор Opus дал девять находок. После одного прохода исправлений тот же ревьюер сделал узкую перепроверку: APPROVED, все девять закрыты. Восемь приняты целиком, одна частично; отклонение лишнего введения признано обоснованным.
distributed_foreground_insert = 1и причина — доставить строки на шарды до замены партиции.Дополнительный проход действительно оказался полезен: он выявил отсутствующее условие выполнения вставки, уточнил договор scope и снял несколько трудностей чтения. Это не доказательство превосходства модели во всех задачах: предметом было уже исправленное ТЗ и специально заданный фокус. Первоначальное утверждение координатора о семи находках было ошибкой чтения лишь части длинного отчета; исполнитель получил полный файл и разобрал все девять. Для компактной передачи результата нужен полный индекс идентификаторов вместе с вердиктом, а не обрезанный фрагмент отчета.
SQL, даги, данные и службы не менялись. После правок Markdown проверены ссылки и git diff --check. Повторный полный make lint не запускался: код после его зеленого прогона не менялся, а эта цель Markdown не проверяет. Написание и финальная вычитка использовали writing-for-agents, ai-text-lint и литературный русский язык.
Что получилось с Luna
Luna/medium получила отдельное поручение на Git, без истории реализации. Ей были нужны ветка, опубликованный исходный коммит, ожидаемый состав изменений, формат коммита и граница «публиковать после приемки». После перепроверки ей переданы хеш принятого файла и сигнал на публикацию.
Она подготовила коммит, дождалась разрешенного этапа, обновила подготовку после правок автора, сверила хеш файла, зафиксировала только ТЗ, выполнила push и проверила удаленный SHA через ls-remote. Посторонних изменений не внесла. Одно уточнение координатора касалось слова baseline в сообщении коммита. Ограничение песочницы на
.git/index.lockснято разрешенным повышением доступа.Координатор прочитал сообщение коммита и короткий отчет, затем независимо сверил SHA PR и состав коммита. Команды стадирования и отправки за агентом не повторялись. Для такого узкого поручения передача механики сработала. Точных счетчиков Codex/Luna в доступных данных нет; дешевизна этого запуска численно не доказана. Предложение владельца попробовать Luna/high сохранено для следующего прогона.
Измерения Claude, с границами применимости
Журнал подтвердил
claude-sonnet-5в остановленном запуске иclaude-opus-5в законченном обзоре. В обоих запрошен high; при возобновлении Opus CLI подтвердил наследование сохраненных модели, effort и permission-mode. Результат Sonnet не использовался. Opus продолжен той же сессией, без нового общего обзора.Ниже суммы полей usage из локальных JSONL: записи сгруппированы по message.id, для каждого идентификатора взята последняя запись. Это счетчики журнала, не счет за API и не общий расход задачи.
Последние две строки перекрываются, складывать их нельзя. Чтение кэша суммируется по обращениям и включает повторно переданный контекст: это не размер одного окна и не объем уникально прочитанных файлов. Расход незавершенной генерации Sonnet мог не попасть в журнал. Метрики не покрывают координатора, Sol, Astra, Luna или внешний запуск Fable; сравнивать стоимость этих ролей по таблице нельзя.
Что оставить для обсуждения скилла
Полезное: один автор с переиспользованным контекстом, свежий обзор с конкретным фокусом, полный отчет исполнителю напрямую, узкая перепроверка, отдельный владелец Git. Неудачное: перегрузка контекста координатора большими выдачами, слишком частые опросы, первоначальный выбор Sonnet для ревью и недостаточная первая приемка прозы.
Уточнения владельца записаны выше отдельными комментариями: разрешенный канал Claude; Opus для ревью; наблюдение за ревьюером не чаще раза в пять минут; механика Git и тикетов у Luna/Terra; гипотеза Luna/high. Сам playbook и память агента в ходе задачи не изменялись. Следующий шаг — разобрать эти факты и выбрать соразмерные изменения скилла, а не автоматически превращать каждое наблюдение в новое правило.
После слияния Git-уборку выполнила та же Luna/medium: проверила вхождение опубликованного коммита в origin/main и отсутствие лишних коммитов, обновила main до
d7e8a6f, удалила только ветку задачи. Повторно объяснять устройство проекта не потребовалось: достаточно было короткого поручения с хешем и границами удаления. Координатор подтвердил чистое дерево и расхождение main с origin/main 0/0, обновил карту; .env сохранен, все 12 служб healthy.Владелец предложил Luna/high и для уборки. На момент уточнения работа уже шла в существующей сессии medium; ее завершили без нового запуска. Для следующего поручения Luna выбрана high. Это предпочтение владельца, а не результат сравнения двух настроек.