Помнишь из урока 6.2 два «всего» на соседних страницах, 83 и 80? Эта практика собирает всё, что ты прошёл в П5, и заканчивается проверкой, которую не заменит ни один тест: число на экране равно числу из базы.
Чему научишься в этом уроке:
• выбирать метрики для своего заказчика и записывать их определения;
• сверять число на дашборде с запросом к базе, который выполняешь сам;
• сдавать дашборд с выводами модели без персональных данных и с журналом расхода.
Что продолжаем
Не начинай с нуля. Продолжай кабинет, который ты собирал в миссиях уроков 6.3 и 6.4: там уже есть страница «Дашборд», демо-данные и «Выводы недели», а в уроке 6.4 дашборд выложен на сервер. Если у тебя есть свой заказчик со своим кабинетом из практики 5.7, сделай дашборд для него. Нет заказчика, тогда доделай «Кодиум», это тоже засчитывается. Здесь задача закрыть пункты чек-листа, которые ещё не закрыты, и собрать сдачу.
Шаг 1. Метрики с определениями
Выбери 5–7 метрик, не больше. У каждой запиши определение в одну строку: что считаем, за какой период, что исключаем. Определение похоже на рецепт: два повара по одному рецепту получают одно блюдо, а «добавь соли по вкусу» даёт два разных. Пример для «Кодиума»:
- Заявок за неделю: заявки, созданные с понедельника по воскресенье по московскому времени; тестовые и демо не считаем.
- Конверсия: «записан» делить на все заявки той же недели; если заявок в срезе 10 и меньше, показываем количество, а не процент.
- Время до первого контакта: от создания заявки до первой записи журнала «новая → в работе»; показываем медиану и долю «быстрее 1 часа»; заявки без движения показываем отдельной строкой «ещё не взяты».
Определения положи в файл в проекте и попроси агента сверить, что все страницы кабинета считают по ним. Если старая страница считает иначе, её нужно привести к тому же определению или подписать, что она показывает другое.
Шаг 2. Сверка трёх чисел запросом
Это главный шаг практики. Тесты проверяют, что код считает то, что написано в коде. А написано может быть не то, что нужно: фильтр отсёк демо-заявки, неделя посчитана по UTC, тестовая заявка попала во «всего». Ловится это только так: выбрать число на экране и получить его же запросом к базе, своими руками.
Попроси агента написать SQL-запросы для трёх чисел с дашборда, например: заявок за последнюю неделю, сколько из них записано, сколько пришло из бота. Запросы он пишет, а выполняешь ты сам на сервере, базой только для чтения. Сначала посмотри, какие таблицы есть:
ssh root@<адрес сервера>
sqlite3 -readonly /opt/crm-kodium/crm.db ".tables"
sqlite3 -readonly /opt/crm-kodium/crm.db ".schema <таблица заявок>"Потом выполни запросы агента той же командой: sqlite3 -readonly /opt/crm-kodium/crm.db "<запрос>". Флаг -readonly значит, что запрос ничего в базе не изменит (справка по sqlite3). Если у тебя другая папка проекта, подставь свою. Число из запроса должно совпасть с числом на экране. Не совпало? Не правь запрос, пока не совпадёт, а выясни, кто из двоих прав: часто ошибается как раз дашборд.
Сломай и почини: отправь одну тестовую заявку с источником test (команду curl попроси написать агента, как в миссии 6.3; ключ приёма подставь сам). Если по твоим определениям тестовые не считаются, «всего» на дашборде и на старой странице «Аналитика» должно остаться одинаковым. Разошлось, значит у страниц разные определения, и это нужно исправить до сдачи. Тестовую заявку потом удали под владельцем кнопкой «Удалить» в кабинете.
Шаг 3. Выводы без ПД и журнал
Нажми «Обновить выводы» и проверь всё, что разбирали в уроке 6.4: в сводке для модели только числа, без имён, телефонов, комментариев и логинов, срезы меньше 5 ушли в «прочее», тест «нет ПД в промпте» зелёный. В журнале должны быть видны модель, которая ответила, и расход: токены промпта, ответа и сколько из кэша. Для ориентира: в прогоне один вызов дал 1 118 + 559 токенов на gemini-3.6-flash и стоил около 0,0003 $. Расход самого агента за паттерн посмотри в кабинете CloseRouter: в прогоне на П5 ушло около часа работы агента.
Шаг 4. Проверка сервера
Перед сдачей пройди короткий список из П4 и П5. Страница «Дашборд» открывается под владельцем, под менеджером даёт отказ 403 (проверь, набрав адрес руками). Файлы Chart.js и htmx лежат в static и подключаются оттуда, а не с внешнего сайта. На сервере есть таблица insights. Файл .env на месте: cut -d= -f1 /opt/crm-kodium/.env покажет имена переменных без значений. Служба поднялась после перезапуска.
Если не получилось
- Число из запроса не совпадает с дашбордом → сравни фильтры: демо-пометка is_demo, тестовые заявки, период, неделя по МСК или по UTC. Попроси агента показать, каким запросом считает dashboard.py, и сравни со своим.
- sqlite3 не найден на сервере → попроси агента установить пакет sqlite3 на сервере и показать версию.
- Под менеджером дашборд открывается → права проверяются не в обработчике страницы; дай агенту адрес и попроси тест на 403.
- Выводы пустые или «показатели равны 0» → сводка не видит данных; смотри «Если не получилось» в уроке 6.4.
- Демо-данные смешались с настоящими заявками заказчика → удали демо командой clear-demo (она удаляет только заявки с пометкой is_demo), перед этим резервная копия.
Контрольный вопрос. Дашборд показывает 80 заявок, а твой запрос к базе показывает 83. Тесты зелёные. Что делаешь?
Подсказка: Вспомни историю двух страниц из начала урока: тестовая заявка и разный период.
На курсе задания проверяются автоматически. Решить первое задание бесплатно → · Подобрать курс
Контрольный вопрос. Зачем при сверке запускать sqlite3 с флагом -readonly?
Подсказка: Сверка это чтение или правка?
На курсе задания проверяются автоматически. Решить первое задание бесплатно → · Подобрать курс
Задание. МИССИЯ «Дашборд, которому верит владелец». Продолжай кабинет из миссий 6.3–6.4 (свой заказчик или «Кодиум»). 1. Файл с определениями 5–7 метрик: что считаем, период, что исключаем. 2. Сверка: три числа с дашборда и три SQL-запроса, которые ты сам выполнил на сервере через sqlite3 -readonly. Числа совпадают; если сначала не совпали, то что было причиной и что исправлено. 3. Сломай и почини: тестовая заявка не меняет «всего» на разных страницах (или ты привёл страницы к одному определению). 4. Выводы недели: сводка, ушедшая модели, без ПД; тест «нет ПД в промпте» зелёный; разбор полосы «Не подтверждены». 5. Журнал: модель, токены промпта и ответа, токены из кэша; расход агента за паттерн из кабинета CloseRouter. 6. Проверка сервера: менеджер получает 403 на дашборде, библиотеки из static, cut -d= -f1 .env, служба запущена. 7. Три блока «видим → значит → делаем → проверим» для владельца. Принято, если: приложены снимок дашборда под владельцем, файл определений, три пары «число на экране — запрос и его результат», снимок блока «Выводы недели» и сводка без ПД, вывод pytest -q с полным итогом, строка журнала с моделью и usage, снимок 403 под менеджером, вывод cut -d= -f1 .env и три блока для владельца. Паролей, ключей и настоящих телефонов на снимках нет.
Подсказка: Начни со сверки чисел: если она не сходится, остальные пункты всё равно придётся переделывать.
✅ Готово, если: программа запускается без ошибок и выводит то, что просят в задании.
На курсе задания проверяются автоматически. Решить первое задание бесплатно → · Подобрать курс
Что дальше
Паттерн «Дашборд» закрыт: ты умеешь считать метрики кодом, получать выводы моделью без ПД и проверять, что число на экране правдиво. Следующий паттерн, тоже по желанию, про собственный продукт: чем проект для одного заказчика отличается от продукта для многих.
Итог:
• у каждой метрики одно определение на весь кабинет, тестовые и демо-заявки исключены;
• число на экране сверено с запросом к базе, который ты выполнил сам;
• выводы модели построены на сводке без ПД, расход и модель видны в журнале.
