Разбор созвона

Созвон становится тремя вещами, и больше ничем:

1. Заметка созвона calls/<ГГГГ-ММ-ДД>.md в работе, о которой говорили.
2. Правки существующих утверждений списком замен «было → стало», если по утверждению приняли решение или появился новый довод. Новых утверждений созвон не заводит.
3. Задачи на доске этой работы в GitLab: новые — с исполнителем и критерием «сделано»; то, что уже на доске, — правкой существующей задачи.

Заметка и правки едут одним предложением (merge request) в работу. Расшифровка в GitLab не идёт: она остаётся на машине ведущего, и в заметке на неё не ссылайся. Сливает человек, и слияние и есть запись. Пустой созвон («поболтали», «проверка звука») не даёт ничего в работу, и это честный исход, а не провал.

Скилл работает в двух режимах с одним контрактом:

• приложение — Brain Call запускает тебя без человека (DeepSeek или Claude, по выбору в меню) в рабочей копии ветки созвона и отдаёт пакет созвона. Ты пишешь файлы и JSON итога. Git, ворота, push и задачи делает код по твоему JSON. Вопросов человеку не задаёшь.
• вручную — человек в Claude Code даёт расшифровку или пересказ. Ты делаешь то же самое, затем сам выполняешь шаги кода из раздела «Вручную: что делает код» и показываешь итог.

Прежде всего

• Свод правил записи в базу: ~/.claude/skills/lab-knowledge/references/canon.md. В режиме приложения его копии рядом может не быть; тогда держись правил ниже — они выписаны из свода.
• Образец заметки: references/gold-standard-note.md. Заметка тоньше образца не закончена.
• Контракт итога и разделы страниц: references/analysis-contract.md.

Шаги

1. Прочитать пакет и работу

Пакет созвона (packet.md) называет: дату, работу и её путь, кто был на созвоне и их логины GitLab, людей работы, утверждения работы с состоянием, открытые задачи доски, прошлые созвоны и путь к расшифровке. Рядом лежит board.md — доска целиком: каждая открытая задача с описанием, исполнителем, сроком, ярлыками и последними комментариями, и задачи, закрытые за месяц. Прочитай по порядку: расшифровку целиком, board.md, страницы утверждений, о которых шла речь, и один-два последних calls/*.md — чтобы знать, что уже решали и что уже стоит.

Реплика подписана именем, только если имя установлено (дорожка владельца, плитка созвона, каталог голосов, представление вслух). «Участник 2» — неизвестный голос: не угадывай, чей он. И не вычисляй его исключением («кроме Армана был только Кирилл — значит, это Кирилл»): разметка дробит одного человека на несколько меток, и безымянный голос часто принадлежит уже названному. 21-10-2026 так задача Армана ушла Кириллу, который весь созвон молчал. Чей голос, видно только по смыслу: кто продолжает свою мысль, к кому потом обращаются, кто говорит о своей работе.

Кому поручили, решаешь ты по смыслу разговора, а не по правилу. Смотри, к кому обращались («ты сделай», «Влад, запусти»), кто взялся («я посмотрю»), о чьей части работы речь, кто ведёт похожую задачу на доске и что этот человек делал на прошлых созвонах. На созвоне вдвоём «ты» ведущего — это собеседник. Владелец микрофона ведёт работу: его «давай запустим» обычно поручение собеседнику, а не себе, если он не сказал «я сам». Имя в чужой реплике («резы Влада») поручения не делает. Если по смыслу так и не ясно, кому, — это not_tasks с причиной, а не догадка. Кода, который перепроверяет исполнителя по словам, нет: отвечаешь ты.

Короткие имена людей работы («Влад», «Женя») пакет сопоставляет с логинами. У исполнителя нет учётки в GitLab — задача всё равно ставится, с его именем в поле person.

Сторона партнёра — не команда. Если работа идёт по договору (в шапке README «программа Huawei»), безымянные голоса «Участник N» на созвоне с заказчиком — его люди, а не люди работы. То, что делает их сторона, ставится задачей с person: "Ребята из Huawei" (по имени партнёра), а не на логин человека из команды, даже если имя совпало: 30-10-2026 владелец сказал «Женя» человеку Huawei, и три задачи Huawei ушли Евгению Степанову из команды. Владелец: «это не какой-то конкретный человек, он как бы условно не в команде, но задачки вот им». Говорящего, названного в расшифровке человеком команды, сверяй по смыслу: если он говорит за заказчика («у нас просто у самих нет информации, как стейджи закрываются»), это сторона партнёра.

2. Решить, есть ли что записывать

Признак: через месяц кто-то будет это искать и расстроится, не найдя. Решение и почему так; договорённость, кто что делает; новый довод за или против утверждения; тупик, который стоил времени. Не повод: пересказ того, что и так в репозитории; планы без хозяина; болтовня.

Нечего записывать — итог с "empty": true и причиной одной строкой, никаких файлов.

3. Заметка созвона

Файл, который назвал пакет (calls/<дата>.md). Разделы — как в образце: контекст и цель, что обсудили по темам, решения, кто что делает (таблица), открытые вопросы, исправления и неопределённость. Источник — таймкод мм:сс, а не номер сегмента. Числа с созвона пишутся как названные на созвоне («назвали около 3.27»), а не как измерения. Никаких путей на машине, ключей и личного. Ссылки на утверждения — относительные: [H-ZOP-005](../claims/H-ZOP-005/README.md).

4. Правки утверждений — списком замен, не правкой файла

Страницы утверждений ты не правишь. Правка — элемент claim_edits в итоге: {"code", "section", "old", "new", "why", "source"}. old — кусок страницы дословно, ровно как он стоит (копируй, не пересказывай), new — чем его заменить. Добавить абзац или пункт — это тоже замена: old — строка, после которой он встаёт (например заголовок следующего раздела), new — новый текст и та же строка. Код вставит замену, только если old найден на странице дословно и один раз; иначе правка отклоняется и называется в предложении.

Сначала сверь «Чем проверяли» и «Результаты проверки гипотезы» с тем, что показали. Если на созвоне показали выкладку, замер или прогон, а страница говорит «ничем не проверяли», «вывод не начат», — это первая и главная правка: страница должна перестать врать. Напиши, что именно показано, кем, где лежит (TeX в ветке, PDF, лог на сервере) и что на страницу оно ещё не перенесено, если так. 21-10-2026 все три модели это пропустили, и на H-MMU-001 осталось «вывод не начат», хотя Фёдор показал выкладку.

Хорошая правка короткая и меняет смысл: одно-два предложения, факт, а не ход разговора. Правок мало: обычно ноль или одна, больше двух на созвон — почти всегда лишнее. На страницу утверждения идёт только решение или новый довод с основанием (замер, показанный на созвоне). Сомнение «может быть, X искажает сравнение» и «не окажется ли, что…» — не правка утверждения, а открытый вопрос в заметке созвона или задача, если его решили проверить.

• плохо: «На второй встрече ведущий сообщил, что Гуров, вероятно, больше не будет делать работу, а ему на смену найден новый участник…» — кадровое, место ему в заметке;
• плохо: «Моментум отнесён к тому же виду вопросов, что и правило обновления…» на 900 знаков;
• хорошо: в «Открытые вопросы» — «- Помогает ли заморозка маленьких тензоров при оптимизации только больших? Критерия опровержения пока нет (созвон 17-09).»

Правок может не быть совсем: созвон о задачах и людях утверждений не меняет. Только о чём говорили по существу. Разделы страницы фиксированы, и дописывать в конец нельзя:

Гипотеза · Почему мы так думаем · Теория · Условия проверки · Чем опровергается · Чем проверяли · Результаты проверки гипотезы · Вывод · Что решили · Открытые вопросы · Чего не хватает

• Решение с созвона — абзац в «Что решили» (раздел заводится на своём месте, если его нет), со ссылкой на заметку созвона.
• Новый довод — абзац в «Почему мы так думаем» или «Открытые вопросы».
• Ни одной цифры с созвона на странице утверждения. Ворота check_numbers ищут каждое число страницы в прогонах этого утверждения и краснеют на любом другом. Число остаётся в заметке созвона, на странице — словами («на созвоне назвали выигрыш на одной затравке, логов нет»).
• status не меняется от разговора: состояние двигает только серия прогонов по критерию.
• Математика только в $…$, не юникодом (≈, ≤, R² краснеют).

Новых утверждений с созвона не бывает. Гипотеза, прозвучавшая на созвоне, — открытый вопрос в заметке, а если её решили проверять — задача. Утверждение заводит человек. Владелец 21-10-2026: «каждый созвон будет создавать миллиард гипотез, и это нахуй будет не нужно». Код откатит любую новую папку в claims/.

5. Задачи

Задача = исполнитель + что сделать + по чему видно, что сделано. Исполнитель — логин из пакета (assignee), а если учётки в GitLab у него нет — имя полем person: задача всё равно ставится. Владелец 23-10-2026: все четыре поручения Марселя выпали из разбора с причиной no_owner, потому что учётки у него не было, и осталась пара задач самому владельцу. Срок — только если назвали (относительный «к пятнице» переведи в дату от даты созвона). Утверждение — код, если задача на него влияет. Критерий «сделано» выводи из сути поручения, а не жди, что его произнесут дословно. Пиши его в будущем времени, как то, что появится: «прогон будет записан», «на странице появится вывод», «презентацию покажут на созвоне». Настоящее время («в ветке лежит вывод») ведущий читает как факт: 21-10-2026 он решил, что вывод уже есть. Не осторожничай с поручениями. Владелец 22-10-2026 про разборы, где из получасового созвона вышла одна правка задачи: агент «слишком осторожен … надо лучше сильно делать». Каждая строка «кто что берёт» из сводки по умолчанию становится задачей или правкой открытой задачи — с логином или с person. Критерий «сделано» выведи сам, если его не назвали.

Организационные поручения одного человека — одной задачей. Доступы, VPN, учётки, инструкции — это одна задача «инфраструктура для …», а не три. Мелочь, которую владелец делает за минуту («попросить Claude расписать»), — не задача. Владелец 23-10-2026 про три задачи себе: «какие-то хуёвые … можно не писать, или написать одну задачу про инфраструктуру, не надо их так распылять».

• «Надо понять, почему X» и есть тот, кто делал эти прогоны, — задача ему: «на странице или в заметке появится объяснение X, с прогоном, который его проверяет»;
• работу ждут от человека работы, которого на созвоне нет («жду от Саши обученные LoRA», «он обещал сделать быстро, но молчит»), — задача ему (логин или person), а не тому, кто ждёт. Запасной план («если Саша не возьмётся, обучу сам на сервере») пишется в what его задачи, а не отдельной задачей с «если» в заголовке; «тегнуть его, спросить» — минутное дело ведущего, не задача. Владелец 05-11-2026 про lora-style, где Алексею поставили «Обучить LoRA, если Саша не берётся»: «такие надо дать Саше, чтобы он это сделал, почему он Саше-то не даётся»;
• уже запущенный долгий прогон («пересчитываю на 8B, потом на 32B») — задача: его итог должен лечь в работу;
• поручение по другой работе из «Соседних работ участников» — задача на её доску с "work": "<слаг>", а не not_tasks;
• ведущий предложил конкретную проверку («самое тупое — сделать SVD на каждом шаге и посмотреть, падает ли оптимальный ранг с точностью»), и её подхватили — задача тому, кто подхватил или кто делает эту часть работы, даже если слова «сделай» не прозвучало. «Интересное направление, подумать» без проверки — не задача; названная проверка — задача. Владелец 28-10-2026 про SVD-эксперимент, записанный «размышлением без результата»: «пропустили одну большую задачу про СВД»;
• обсуждали, куда двигаться дальше, перебрали кандидатов и не выбрали — задача тому, кто эту работу делает: «Выбрать следующий метод: <кандидаты>», готово, когда на созвоне покажут выбор с первым сравнением. «Идеи отложены, хозяина нет» — не причина, если идеи предлагал и обсуждал человек из команды работы. Владелец 26-10-2026 про поиск метода поверх Muon в huawei-optimizers, отброшенный как «идеи без хозяина»: «а почему не стало? надо сделать».

Работа задачи — по статье или методу, о котором речь, а не по тому, какая работа выбрана для созвона. Сверь названия из разговора с описаниями соседних работ в пакете; в расшифровке они звучат по-русски и искажены («Риманион» — Riemannion, «лора тсд» — LoRA-TSD). 22-10-2026 ребаттл LoRA-TSD ушёл в huawei-optimizers, хотя описание lora-muon было в пакете.

Поручения сводки пронумерованы [К1], [К2]… По каждому верни решение в commitments. Отказ (not_task) — только с одной из причин: no_owner (кто делает, не видно вовсе; названный человек без учётки — не no_owner, а person), personal (скинуть ссылку, написать в личку), on_board (уже стоит на доске и менять нечего), done (сделано на созвоне). Код проверяет: пропущенное поручение или другую причину вернёт тебе в ту же сессию. Работа по статье, которой нет ни в основной, ни в соседних работах, — задача в основную работу с пометкой в what, к какой статье она.

В not_tasks — только то, где исполнителя по смыслу не видно вовсе, личная мелочь без результата для работы («скинуть ссылку», «написать в личку») и то, что уже стоит на доске. Пропущенное поручение дороже лишней задачи: лишнюю владелец уберёт одним «Изменить».

Перед тем как предложить задачу, сверь её с board.md. Доска после созвона должна стать понятнее, а не длиннее. Владелец 21-10-2026 про пять движений по доске за один созвон: «нахуя нам две новые и три правки … можно сделать так, что мы закроем её как закрытую и откроем». Поэтому для каждой открытой задачи, о которой говорили, выбери одно из трёх:

• закрыть (task_updates с "close": true) — работу по ней показали, исполнитель рассказал, что основная работа сделана, или на вопрос ответили. Устного отчёта хватает: доска следит за работой, доказательства живут в утверждениях, а критерий «прогоны записаны рекордером» в старой задаче не держит её открытой — запись прогона станет пунктом следующей задачи. Владелец 30-10-2026: «Дима много всего выполнил, и у него задач только как будто бы добавилось … нужно, чтобы эти задачи переходили в готовое». comment — одна строка, что сделано и где лежит: «черновик анализа показан, TeX и PDF в ветке claim/H-MMU-005». Сменилось направление — старую задачу закрыть с причиной, новую открыть;
• дописать (task_updates без close) — только если работа идёт и поменялось важное: исполнитель, срок, само поручение. Пересказ того, что обсудили, — не повод. Поручение то же, а сформулировано на доске неверно или устарело (не тот метод, не та точность, другой исполнитель) — перепиши саму задачу: title и description целиком в task_updates. Это не новая задача и не закрытие. Владелец 28-10-2026: #12 «Ньютон-Шульц в LORO» закрыли и завели ту же работу Кирилла заново как «LoRA с мюоноподобным шагом», а новая задача Армана про интервал ретракции K повторила #8 «потюнить K» — «как будто две задачи продублировали»;
• не трогать — о ней упомянули, но ничего не изменилось.

comment пишется простыми словами: его читает ведущий, который не держит выкладку в голове. Формула без слов — плохо. assignee — кому по смыслу созвона теперь эта работа: ничью задачу, которую отдали человеку, назначь на него. Срок — только если назвали. Закрытая задача заново не ставится.

Пройди по каждой открытой задаче участников созвона. Пакет перечисляет их в разделе «Задачи участников созвона»; по каждой верни в board_review: {"iid": 25, "decision": "close" | "rewrite" | "update" | "keep", "why": "…, 14:32"}. close, rewrite и update должны стоять и в task_updates. Код проверяет, что решение есть по каждой, и недостающее вернёт тебе в ту же сессию. keep — только если о задаче не говорили или по ней ничего не изменилось.

Ярлыки задачи — kind, списком, обычно один, иногда два: теория (вывод, доказательство, модель на бумаге), код (реализация, скрипт, обвязка), прогон (запуск, замер), текст (страница утверждения, статья, презентация), организация, обязательство. «Построить модель памяти и найти оптимальные параметры» — ["теория", "код"], «реализовать и проверить схему» — ["код"]. Владелец 21-10-2026 про ярлык «текст» на задаче-модели: «и теория, и код одновременно, два тега должно быть».

Прежде чем оставить задачу открытой или завести новую, проверь, не сделано ли это уже: в paper/, на страницах утверждений, в неслитых ветках, в том, что показали на созвоне. Сделанное закрывается, а не висит. Владелец 21-10-2026 про «реализовать и проверить обе схемы»: «посмотреть, нет ли этого уже, потому что это точно было и в статье, и Федя мне показывал».

Новая задача — один проверяемый результат, а не тема. Заголовок называет то, что появится: «Таблица: Assumption 4 при tau > 1», «Vector transport в эксперименте с ретракцией», а не «Дожать эксперименты для ответов рецензентам». Если в теме несколько независимых результатов (четыре эксперимента для разных вопросов рецензентов), это несколько задач, у каждой свой критерий «сделано». what — две-три строки: зачем (кто просит, на какой вопрос отвечает) и из чего исходить; не список подзадач. Владелец 26-10-2026 про задачу «Дожать эксперименты…» с четырьмя пунктами внутри: «какие то общие задачи, непонятно нафига они такие нужны, надо больше конкретики». Правило ниже про одно движение относится к старым задачам доски, а не к тому, сколько новых завести.

Одна тема — одно движение по старым задачам доски. Сначала разбей созвон на темы работы (анализ сходимости, реализация схем, рукопись…), потом на каждую тему — ровно одно из:

• работа по теме продолжается в новом направлении → закрыть старую задачу (что сделано) и открыть новые по результатам следующего шага. Не комментарий в старую сверх закрытия;
• работа по теме сделана или вопрос закрыт → закрыть. «Сделана» — это основная работа показана, а не «доделано до последней строки»: недоделанное уходит пунктом в новую задачу той же темы, а не держит старую открытой. Вопрос владельцу, на который он ответил хотя бы в главном, закрывается с ответом; неотвеченная часть — строка в открытых вопросах заметки. Задача «реализовать и прогнать», по которой показали прогоны, закрывается, даже если прогоны записаны руками: запись рекордером — пункт следующей задачи;
• поменялся только исполнитель или срок → дописать;
• то же поручение, другие слова (уточнили метод, точность, протокол) → дописать с новыми title и description. «Направление сменилось» — это другой результат, а не другая формулировка того же.

Перед каждой новой задачей найди на доске задачу того же человека про тот же прогон или метод. Нашлась — это task_updates к ней, а не новая задача.

Комментарий в старую задачу, который пересказывает то, из чего сделана новая, — дубль. Перенос выкладки, оформление, «показать на созвоне» — части результата той же задачи, а не отдельные задачи. Владелец 21-10-2026 про две новые задачи и три правки по одному созвону: «это дублирование какой-то информации и ебаный мусор». Там должна была быть одна новая задача и три закрытия: правки пересказывали то, что уже было в новой.

5а. Созвон по нескольким работам

Если пакет называет «Другие работы этого созвона», владелец отметил созвон и по ним. Основная заметка — про основную работу; по каждой другой, о которой говорили, верни в side_notes короткую заметку только про её часть разговора. Задачи по ней — в tasks с work. Владелец 26-10-2026: «это в обе надо положить», «у задачи надо писать в таком случае, в какой проект она идёт».

6. Итог

JSON по контракту из references/analysis-contract.md в файл, который назвал пакет. Поле title — первая строка предложения: «Созвон <ДД-ММ-ГГГГ>: <о чём, 3–7 слов>». Поле summary — тело предложения: что изменилось и зачем, чем проверено, что осталось открытым.

Не мусорить — правила, по которым ты сам себя останавливаешь

После тебя итог читает судья — тот же DeepSeek без инструментов, с расшифровкой. Каждый абзац и пункт заметки, каждую замену, задачу и правку задачи он оставляет или выкидывает, и выкинутое не попадает ни в предложение, ни на доску. Выкидывает: пересказ хода разговора («обсудили», «ведущий спросил»), воду, кадровое на странице гипотезы, то, чего нет в расшифровке, повтор, правку без смены смысла, задачу «подумать / посмотреть / разобраться», задачу, которая уже на доске. Пиши так, чтобы ему нечего было выкидывать.

• Записи без утверждения не бывает. Новых папок и разделов не заводить.
• Выдуманных чисел нет ни одного. Число из разговора — не прогон.
• У задачи есть исполнитель с учёткой и критерий «сделано», иначе это открытый вопрос.
• Один объект пишется один раз: то, что уже на доске, — task_updates, повтор решения — не повтор.
• Пишешь только заметку созвона. Страницы утверждений — только через claim_edits. Всё остальное код откатит и назовёт вслух.
• Git не трогаешь: ни commit, ни push, ни смену ветки.

Вручную: что делает код

В интерактивной сессии после шагов 1–6 сделай сам то, что в приложении делает Brain Call:

1. Работа — клон ~/brainlab/<направление>/<тема>/<работа>. Не переключай его ветку: собери ветку в отдельной копии git -C <клон> worktree add -b call/<дата> <tmp> origin/main после git fetch.
2. Вставь замены claim_edits в страницы утверждений сам — только дословно найденное old, без шапки и без чисел с созвона. Расшифровку в работу не клади. Проверь ворота по содержимому коммита (git archive HEAD), как в ~/brainlab/handbook/tools/proposal-gates.md, и считай только новые замечания против main.
3. git commit -F - с title и summary, затем git push origin HEAD:refs/heads/call/<дата>: клон сам откроет предложение на ведущего работы.
4. Задачи — API GitLab (~/.config/brainlab/git-url, ключ git-token): POST projects/<id>/issues с исполнителем, ярлыком вида (прогон, текст, выкладка, организация, обязательство) и телом по шаблону задачи, где первая строка **Утверждение:** H-…; правка задачи — POST …/issues/<iid>/notes, новый исполнитель или срок — PUT …/issues/<iid>.
5. Покажи человеку ссылку на предложение и список задач: заведённые, дописанные, отклонённые.