# Сам Решу — ИИ-платформа для бизнеса > ИИ-агент работает с живыми данными из 1С, Битрикс24, amoCRM, Ozon, Wildberries, МойСклад и других систем — считает юнит-экономику, сверяет остатки, разбирает документы, формирует отчёты. Это агент с доступом к источникам и правом действовать. --- Source: https://samreshuuu.ru/home # Сам Решу > AI-агент для российского бизнеса: подключается к 1С, CRM, складу и маркетплейсам, отвечает на вопросы о реальных данных и выполняет рутину. Отличие от ChatGPT + Excel — живой доступ к системам и право на действие, а не работа по выгрузке. ## Факты - Каталог коннекторов по 16 категориям — маркетплейсы (Ozon, Wildberries, Яндекс Маркет), CRM (Битрикс24, amoCRM), банки (Сбербанк, Альфа-Банк, Точка), 1С, МойСклад, Диадок. Машиночитаемый список: https://samreshuuu.ru/connectors.json - MCP-сервер для внешних агентов и IDE (Claude, Cursor, ChatGPT): https://samreshuuu.ru/docs/mcp - Тарифы: бесплатный (чат без счётчика сообщений), Pro 2 000 ₽/мес, Max 10 000 ₽/мес, Team — по числу мест: https://samreshuuu.ru/pricing - Данные хранятся в России (152-ФЗ), не используются для обучения моделей ## Что делает Сам Решу подключается напрямую к рабочим системам компании: 1С, CRM (Битрикс24, amoCRM), складскому учёту (МойСклад), маркетплейсам (Ozon, Wildberries), документообороту (Диадок). Получает запрос в чате на естественном языке, сам выбирает нужные источники, выполняет расчёт, возвращает ответ со ссылками на факты. ## Для кого - Малый и средний бизнес в России: 5–200 сотрудников - Категории: e-commerce, оптовая торговля, услуги, производство - Роли: владелец/CEO, операционный директор, финансовый менеджер, маркетолог ## Сценарии - Свести данные из 1С и CRM, найти разрывы в воронке - Посчитать юнит-экономику товара на Ozon/WB с учётом комиссий и логистики - Проверить остатки на складе против фактических продаж за месяц - Сформировать отчёт по продажам по любому срезу без выгрузок в Excel - Разобрать договор/счёт/акт и извлечь ключевые параметры ## Чем отличается от ChatGPT + Excel ChatGPT работает с тем, что вы скопировали в окно. Сам Решу читает данные из систем в реальном времени, видит обновления, может действовать (создать задачу, выгрузить документ). Это агент, а не консультант. ## Ссылки - Цены: https://samreshuuu.ru/pricing - Интеграции: https://samreshuuu.ru/integrations - Сценарии для продавцов на маркетплейсах: https://samreshuuu.ru/use-cases/sellers --- Source: https://samreshuuu.ru/pricing # Цены > Сам Решу работает по подписке: бесплатный тариф для знакомства, Pro и Max для одного пользователя. Отдельного командного тарифа нет — команда берёт тот же Pro или Max и умножает его на число платных мест. Сообщения в чате не считаются ни на одном тарифе: тариф задаёт запас на неделю и на месяц, а также дневные квоты на запуски задач и картинки. Квота мест хранится в настройках организации. Stripe не используется — оплата российскими способами. ## Как считается лимит У каждого тарифа есть месячный запас и недельный потолок внутри месяца. Чат, автозадачи и генерация расходуют один и тот же запас, поэтому фиксированного числа сообщений нет — сколько вы успеете, зависит от длины переписки, сложности задач и подключённых инструментов. Когда запас израсходован, чат не отключается: агент продолжает отвечать на облегчённой модели, а автозадачи и генерация ждут обновления запаса. Выходов три — дождаться сброса, перейти на тариф выше или, на Pro и Max, сбросить недельный лимит. Запас считается в деньгах по прайс-листу вендоров моделей, а не в служебных единицах: месячный бюджет Pro — $400, Max — $2000, при цене подписки $20 и $100. Тариф даёт в 20 раз больше работы моделей, чем стоит сам, и эту цифру можно проверить по опубликованным ценам самих вендоров. Во сколько запросов превращается бюджет — зависит от модели: на лёгкой он растягивается в десятки раз дальше, чем на самой дорогой, и разбивка по каждой модели есть на странице цен. Отдельно бюджет растягивает кэш: около 75% контекста типичного запроса приходит из кэша, а кэшированный ввод стоит примерно в десять раз дешевле свежего. ## Структура тарифов - **Бесплатный** — 0 ₽: чат с ИИ-агентом, поиск, документы, интеграции, 1 запуск задачи в день (одна задача по расписанию) и 3 картинки в день на базовой модели, без карты и без срока - **Pro** — 2 000 ₽/мес: все интеграции, документы, поиск, 160 запусков задач и 60 картинок в день - **Max** — 10 000 ₽/мес: всё из Pro, 640 запусков задач и 150 картинок в день, до 30 видео в месяц, приоритетная очередь и поддержка - **Команда** — не отдельный тариф, а Pro или Max по числу платных мест, до 150; плюс общий диск, роли и журнал аудита Модели чата по тарифам: Бесплатный работает на Сам Решу 1.1 Лайт, Pro добавляет основную модель Сам Решу 1.1, а самая сильная модель Сам Решу 1.1 Макс есть только на Max. При оплате за год действует скидка. Точные условия — на странице цен. ## Как устроены места Место бывает платным и бесплатным, и тип переключается по каждому участнику. Платное место даёт человеку весь тариф организации; бесплатное оставляет его в той же организации — с общим диском, ролями и базой знаний, — но по лимитам Бесплатного. Счёт считается только по платным местам, поэтому платить нужно лишь за тех, кому объёма Бесплатного не хватает. Места добавляются и снимаются в любой момент: новое место включается сразу и попадает в счёт только за оставшиеся дни периода, а снятое возвращается зачётом на баланс организации и гасит следующий платёж. Общий баланс организации можно включить отдельно — тогда участник, исчерпавший дневной лимит, добирает из него, а не переводит на старший тариф всю команду. ## Сброс недельного лимита Пакеты пополнения баланса больше не продаются. Если на оплаченном Pro или Max упёрся недельный лимит, а в месяце осталось не меньше четверти запаса, неделю можно начать заново разовой оплатой: **790 ₽** на Pro и **3 950 ₽** на Max. Месячный запас при этом не меняется — если в месяце запаса почти не осталось, сброс недели не предлагается, и выход — тариф выше. Оплата — теми же российскими способами, что и подписка; если к моменту подтверждения оплаты неделя уже не упирается в лимит, деньги возвращаются. ## Что входит в любой план - Все интеграции (1С, CRM, маркетплейсы, склад, документооборот) - ИИ-агент с памятью и доступом к данным компании - Документы: разбор, генерация, OCR - Изоляция данных, шифрование, отсутствие обучения на пользовательском контенте ## Как оплачивается Основной способ — российская банковская карта, подписка продлевается автоматически. Для юрлиц доступна оплата по счёту (банковский перевод). Карты иностранных банков не требуются. Подключения Stripe нет. ## Ссылки - Главная: https://samreshuuu.ru - Контакты для корпоративных условий: https://samreshuuu.ru/contacts --- Source: https://samreshuuu.ru/business # Сам Решу для бизнеса > Один ИИ-агент для всей команды. Подключается к 1С, CRM и маркетплейсам, работает с документами и собирает аналитику. Каждому сотруднику — свой агент; руководителю — единый счёт, роли и журнал действий: видно, кто что запускал. ## Что получает команда - **Подключается к вашим системам** — 1С, Битрикс24, amoCRM, Ozon, Wildberries и десятки других сервисов без программиста в штате. Агент работает там, где уже лежат данные. - **Сложные задачи — быстрее** — сверка сотен строк, месячный отчёт, разбор десятков договоров: то, на что уходил рабочий день, агент закрывает за минуты. - **Просто управлять** — единый счёт, гибкое число мест, роли и доступы. Команда подключается за минуты, масштабируется вверх или вниз без хлопот. - **Данные под защитой** — обрабатываются в РФ, не используются для обучения, доступ по ролям. ## Безопасность и комплаенс Серверы в РФ и обработка по 152-ФЗ, шифрование, SSO/SCIM, ролевой доступ и журналы аудита. Для команд с особыми требованиями — On-premise и индивидуальный SLA. Подробности — в разделе о безопасности. ## Ссылки - Главная: https://samreshuuu.ru - Безопасность: https://samreshuuu.ru/trust - Цены: https://samreshuuu.ru/pricing - Интеграции: https://samreshuuu.ru/integrations --- Source: https://samreshuuu.ru/features # Возможности > ИИ для бизнеса, который доводит работу до результата. «Сам Решу» подключается к 1С, CRM и маркетплейсам и закрывает рутину сам: задачи выполняются по расписанию или по событию, документы выходят готовыми файлами, данные остаются в РФ. ## Что умеет - **Задачи и автоматизация** (/features/tasks) — любой сигнал (чат, лид в CRM, расписание, письмо) становится задачей и доходит до конца. Настроили один раз — повторяется каждый день. - **Документы** (/features/documents) — договоры, КП, акты и отчёты: готовые DOCX, XLSX и PDF по шаблонам компании, с реквизитами контрагента, подписью и сдачей в ЭДО. - **Интеграции** (/integrations) — 97+ коннекторов: 1С, Битрикс24, amoCRM, МойСклад, Ozon, Wildberries, Диадок, банки. Подключение за 5 минут, без разработчика. ## С чего начать Регистрация бесплатная, первый результат за 5 минут: /signup. Демо на ваших задачах: /book-demo. --- Source: https://samreshuuu.ru/features/documents # Документы > Сам Решу отдаёт не текст в чате, а готовый DOCX, XLSX или PDF — с реквизитами контрагента, по шаблонам компании, с подписью и сдачей в ЭДО. От входящего файла до подписи — за разговор, а не за вечер. ## Что умеет - **Создание документов:** DOCX, XLSX, PDF, PPTX — с реквизитами контрагента, нумерацией и подписантами - **Анализ документов:** из PDF, скана или аудио звонка агент вытаскивает суммы, сроки и риски - **Шаблоны:** корпоративные образцы и реквизиты берутся из Памяти — не «сочинил с нуля» - **Подпись и отправка:** подписывает через ЭДО, отправляет контрагенту и кладёт результат в Память ## Как это выглядит Запрос в чате: «Сделай договор поставки для ООО „Ромашка" по нашему шаблону». Агент подставляет реквизиты и подписанта из Памяти, сумму и сроки — из сделки в Bitrix24, и возвращает финальный DOCX, готовый к подписанию. ## Память под документы - **Контрагенты:** карточка с реквизитами, история сделок и метки — подставляются везде - **Шаблоны:** образцы договоров, сценарии звонков и готовые артефакты как корпоративная база - **Контекст:** агент помнит, на чём вы остановились — между задачами и сервисами - **Контроль:** вся память открытым списком, любую запись можно поправить или удалить. Хранится в РФ ## Ссылки - Главная: https://samreshuuu.ru - Как ставить задачи: https://samreshuuu.ru/features/tasks - Интеграции: https://samreshuuu.ru/integrations --- Source: https://samreshuuu.ru/features/tasks # Задачи > ИИ-агент для задач: закрывает рабочий день, пока вы заняты другим. Настроили один раз — повторяется каждый день, без вашего участия. Любой сигнал — чат, лид, расписание, письмо — сам становится задачей и доходит до конца. ## Что автоматизирует - Контроль дебиторки в 1С - Сводка по Wildberries и Ozon - Обновление сделок в Битрикс24 - Отчёт из МойСклад в Telegram Запускается по расписанию или по событию — настраивается один раз. ## От сигнала до результата - **Точка входа:** чат, лид в CRM, расписание или письмо — любой сигнал становится задачей - **Выполнение:** задача живёт часами, переживает сбои и продолжает с места остановки - **Доставка:** готовый файл ложится в Память — найдёте по контрагенту, дате или сумме - **Прозрачность:** каждая задача, статус и следующий запуск — на одном экране ## Ссылки - Главная: https://samreshuuu.ru - Работа с документами: https://samreshuuu.ru/features/documents - Интеграции: https://samreshuuu.ru/integrations - Сценарии для продавцов на маркетплейсах: https://samreshuuu.ru/use-cases/sellers --- Source: https://samreshuuu.ru/use-cases # Что бизнес решает с ИИ-агентом > Хаб готовых сценариев: подборки по отделам и конкретные задачи, которые агент выполняет от начала до конца в подключённых системах — маркетплейсы, 1С, банк, CRM, ЭДО. ## Сценарии по отделам - Селлерам на маркетплейсах: https://samreshuuu.ru/use-cases/sellers — юнит-экономика, прибыльность по SKU, возвраты Ozon/WB - Финансам: https://samreshuuu.ru/use-cases/finance — сверки банк/1С, дебиторка, платёжный календарь - Продажам: https://samreshuuu.ru/use-cases/sales — воронка CRM, потери лидов, отчёты по сделкам - Маркетингу: https://samreshuuu.ru/use-cases/marketing — ДРР по кампаниям, контент, отзывы - Аналитике: https://samreshuuu.ru/use-cases/analytics — дашборды, аномалии маржи, динамика месяц к месяцу - Продукту: https://samreshuuu.ru/use-cases/product — обратная связь, приоритизация, метрики - Поддержке: https://samreshuuu.ru/use-cases/support — разбор очереди обращений, автоответы, эскалации ## Задачи-рецепты Более 50 конкретных сценариев с готовым запросом в один клик: P&L по единице товара, разбор падения продаж на WB/Ozon, ответы на отзывы, сверка банка с 1С, просроченная дебиторка, акты сверки через ЭДО, поиск двойных платежей, кассовые разрывы, ежедневный отчёт по деньгам, проверка счетов, недельный дашборд выручки и другие. Каждый рецепт — отдельная страница /use-cases/:slug с описанием шагов агента и запуском. --- Source: https://samreshuuu.ru/integrations # Интеграции ИИ-агента > Подключите сервисы, в которых уже работает бизнес, — агент читает и меняет данные по вашему запросу, без выгрузок в Excel. Каждая интеграция — отдельная страница /integrations/:slug с описанием сценариев агента, частыми вопросами и шагами подключения. Подключение идёт либо по API-ключу, либо входом в аккаунт в один клик (OAuth), либо по коду — способ зависит от сервиса. ## Категории - Маркетплейсы: Ozon, Wildberries, Яндекс Маркет, Avito, Kaspi, Мегамаркет, Uzum — продажи, заказы, остатки, отзывы, реклама. - CRM: Битрикс24, amoCRM, RetailCRM, Мегаплан — сделки, задачи, воронки, контакты. - Банки: Сбербанк, Альфа-Банк, Тинькофф, Точка, Модульбанк — выписки, платежи, сверки. - 1С и ЭДО: 1С:Предприятие, МойСклад — остатки, закупки, взаиморасчёты, продажи. - Аналитика: Яндекс Метрика — трафик, цели, источники, аномалии. - Мессенджеры: Telegram — приём обращений, автоответы, уведомления и рассылки. ## Как подключается 1. В чате упоминается источник («посмотри в Ozon», «возьми из 1С») или подключение делается заранее через раздел настроек 2. Агент инициирует OAuth/токен-флоу, запрашивает у пользователя нужные права 3. Если у пользователя не хватает прав в самой системе (403/scope) — агент возвращает форму запроса доступа администратору, не блокирует чат 4. Данные не хранятся «у нас» сверх необходимого: подтягиваются по запросу ## Безопасность подключений - OAuth-токены шифруются на стороне платформы - Скоупы запрашиваются по принципу минимально необходимых - Подключение можно отозвать в любой момент из настроек ## Полный каталог Машиночитаемый список всех коннекторов (97 сервисов по 16 категориям) опубликован в JSON: https://samreshuuu.ru/connectors.json --- Source: https://samreshuuu.ru/use-cases/sellers # Продавцам на Ozon и Wildberries > Узкая страница для e-commerce: считаем юнит-экономику с учётом всех комиссий и логистики, отслеживаем прибыльность по SKU, разбираем причины возвратов и негативных отзывов. Все данные тянутся напрямую из Seller API маркетплейса. ## Что считает агент - **Юнит-экономика:** себестоимость, комиссия маркетплейса, логистика FBO/FBS, эквайринг, налог — чистая прибыль на единицу - **Прибыльность по SKU:** какие товары приносят деньги, какие убыточны после всех вычетов - **Возвраты и брак:** доля возвратов, причины, влияние на маржу - **Остатки и оборачиваемость:** где затоварка, где грозит out-of-stock - **Конкуренты и цены:** анализ ценового позиционирования (при настроенных источниках) ## Чем отличается от внутренней аналитики кабинета Кабинеты Ozon/WB показывают, что произошло. Сам Решу отвечает на вопрос «почему» и «что делать»: связывает данные, находит закономерности, рекомендует конкретные действия по SKU. ## Сценарии - «Найди 10 товаров с минимальной маржой за квартал и объясни, почему они убыточны» - «Сравни эффективность FBO vs FBS по моим категориям» - «Какие SKU стоит вывести из ассортимента» - «Подготовь отчёт для собственника за месяц одной страницей» ## Ссылки - Главная: https://samreshuuu.ru - Интеграции: https://samreshuuu.ru/integrations - Цены: https://samreshuuu.ru/pricing --- Source: https://samreshuuu.ru/use-cases/finance # Финансы без ручных сверок и дедлайнов > Агент сверяет банковские выписки с проводками в 1С, собирает P&L и отчётность, контролирует дебиторку и разбирает первичные документы. Платежи он не проводит — готовит реестры и сверки на согласование, подпись остаётся за финансистом. ## Что закрывает агент - **Сверки в 1С на автомате:** сопоставляет банковские выписки, счета и проводки, находит расхождения и дубли, отмечает спорное - **P&L и отчётность за минуты:** собирает прибыль и убытки, маржу и динамику из 1С и таблиц — готовый отчёт для руководства - **Дебиторка под контролем:** следит за просрочками, ранжирует должников, шлёт напоминания клиентам и менеджерам по графику - **Первичка и бюджеты:** разбирает входящие документы, проверяет реквизиты и суммы, сверяет факт с бюджетом и подсвечивает отклонения ## Как это работает Агент подключается к 1С по API: читает проводки, выписки, счета и справочники. Доступ выдаётся точечно под нужные участки, действия логируются. Он работает в вашем контуре по выданным правам — данные не уходят на сторону без согласия. ## Сценарии - «Собери P&L за май по подразделениям» - «Сверь выписку Точки с проводками в 1С за июнь» - «Покажи дебиторку с просрочкой больше 10 дней» - «Найди дубли платежей и лишние списания за месяц» - «Сравни факт с бюджетом и подсвети отклонения выше 10%» ## Ссылки - Главная: https://samreshuuu.ru - Интеграции: https://samreshuuu.ru/integrations - Цены: https://samreshuuu.ru/pricing - Аналитика на данных: https://samreshuuu.ru/use-cases/analytics --- Source: https://samreshuuu.ru/use-cases/sales # Продажи, где ни один лид не остывает > Агент подхватывает лиды из CRM, ведёт follow-up, готовит коммерческие предложения и считает прогноз по воронке. Он снимает рутину — письма, КП, отчёты, напоминания — чтобы менеджеры тратили время на разговоры с клиентами и закрытие сделок. ## Что умеет агент - **Лиды не теряются:** разбирает новые заявки из Битрикс24 и amoCRM, квалифицирует, ставит задачи и напоминает о зависших сделках - **Follow-up без напоминаний:** пишет персональные письма после звонков и встреч, ведёт цепочки касаний, фиксирует ответы в карточке - **КП и счёт за минуты:** собирает коммерческое предложение по шаблону компании с актуальными ценами и условиями под клиента - **Прогноз по воронке:** считает взвешенный прогноз по этапам, показывает узкие места, шлёт сводку руководителю отдела ## Как это работает Агент работает с Битрикс24 и amoCRM по API: читает и обновляет карточки, двигает сделки по этапам, ставит задачи, подтягивает историю переписки и звонков. Письма готовит на согласование, а с вашего разрешения отправляет follow-up сам по триггерам. ## Сценарии - «Разбери новые заявки из Битрикс24 и поставь задачи менеджерам» - «Собери КП для клиента по нашему шаблону» - «Покажи сделки, зависшие дольше 7 дней» - «Посчитай взвешенный прогноз по воронке до конца месяца» - «Подготовь сводку по продажам за неделю для РОПа» ## Ссылки - Главная: https://samreshuuu.ru - Интеграции: https://samreshuuu.ru/integrations - Цены: https://samreshuuu.ru/pricing - Поддержка клиентов: https://samreshuuu.ru/use-cases/support --- Source: https://samreshuuu.ru/use-cases/marketing # ИИ-агент, который ведёт ваши кампании сам > Подключите рекламные кабинеты и CRM — агент анализирует каналы, готовит контент и креативы, считает ROMI и присылает отчёт. Один агент закрывает весь цикл: от сбора данных до готового отчёта, чтобы команда занималась стратегией. ## Что закрывает агент - **Сквозная аналитика:** сводит Директ, VK Рекламу, маркетплейсы и CRM в один отчёт с CPL и ROMI по каждому источнику - **Контент и креативы:** посты, рассылки, описания карточек и баннеры в тоне бренда — пачками, под каждый сегмент - **Мониторинг конкурентов:** следит за ценами, акциями и контентом конкурентов на маркетплейсах и в соцсетях, шлёт сводку - **Отчёты для руководителя:** итоги кампаний с выводами и рекомендациями — готовый дашборд или письмо без ручной сборки ## Как это работает Агент подключается по API к Яндекс Директу, VK Рекламе, маркетплейсам (Wildberries, Ozon, Яндекс Маркет), Битрикс24 и amoCRM. По умолчанию готовит черновики на согласование; можно дать право публиковать в нужных каналах. Тон бренда берёт из загруженных гайдлайнов и прошлых постов. ## Сценарии - «Собери отчёт по всем каналам за неделю с ROMI и выводами» - «Покажи, какие кампании в Директе сливают бюджет» - «Сравни наши цены на Wildberries с тремя конкурентами» - «Сделай описания и SEO для десяти карточек товара» - «Предложи 10 идей для контент-плана на месяц» ## Ссылки - Главная: https://samreshuuu.ru - Интеграции: https://samreshuuu.ru/integrations - Цены: https://samreshuuu.ru/pricing - Продавцам на маркетплейсах: https://samreshuuu.ru/use-cases/sellers --- Source: https://samreshuuu.ru/use-cases/analytics # Аналитика, которая отвечает за 5 минут > Агент собирает данные из 1С, CRM и маркетплейсов, отвечает на ad-hoc запросы на естественном языке и строит дашборды и отчёты. SQL и отдельный аналитик в штате не нужны — вопрос формулируется обычными словами. ## Что умеет агент с данными - **Ad-hoc запросы на словах:** спросите данные обычным языком — агент соберёт выгрузку, посчитает и объяснит результат без SQL - **Дашборды и отчёты:** строит сводные дашборды по выручке, воронке и каналам, обновляет по расписанию и шлёт нужным людям - **Данные из всех систем:** сводит 1С, Битрикс24, amoCRM и маркетплейсы в одну картину без ручных выгрузок и склейки таблиц - **Инсайты, а не просто цифры:** находит аномалии и тренды, объясняет причины и предлагает следующий шаг ## Как это работает Агент берёт данные из 1С, Битрикс24, amoCRM, Wildberries, Ozon, Яндекс Маркета, почты и таблиц по API. Он показывает источник каждой цифры, расчёты воспроизводимы — можно раскрыть, как получился результат, и проверить. Дашборды обновляются по заданному расписанию. ## Сценарии - «Сколько продали по WB и Ozon за май и где просели?» - «Построй дашборд выручки по каналам с обновлением по понедельникам» - «Сведи продажи из 1С, CRM и маркетплейсов в одну таблицу» - «Найди аномалии в марже за последние 3 недели» - «Собери воронку из CRM и покажи, на каком этапе теряем сделки» ## Ссылки - Главная: https://samreshuuu.ru - Интеграции: https://samreshuuu.ru/integrations - Цены: https://samreshuuu.ru/pricing - Финансы и отчётность: https://samreshuuu.ru/use-cases/finance --- Source: https://samreshuuu.ru/compare # Сравнения: Сам Решу и другие ИИ > ChatGPT, Claude, Алиса Про и GigaChat отвечают текстом. Сам Решу доводит задачу до результата в ваших сервисах — собирает данные, оформляет документ, обновляет CRM и присылает готовое. Разница не в качестве модели, а в том, где заканчивается работа. Языковая модель заканчивает на ответе: что нужно сделать, в каком порядке, каким инструментом. Агент заканчивает на результате: файл сформирован, заказ обновлён, отчёт отправлен. Ниже — отдельное сравнение по каждому сервису. ## Сравнения по сервисам - [Сам Решу vs ChatGPT](/compare/chatgpt) — ChatGPT доводит вас до ответа. Сам Решу доводит задачу до готового файла. - [Сам Решу vs Claude](/compare/claude) — Claude блестящий ассистент. Сам Решу — агент, который доводит задачу до результата. - [Сам Решу vs Алиса Про](/compare/yandexgpt) — Алиса Про это подписка на помощника. Сам Решу — агент, который доводит дело до конца. - [Сам Решу vs GigaChat](/compare/gigachat) — GigaChat это модель. Сам Решу — агент, который доводит дело до конца. ## Что сравнивается на каждой странице - Автономность: подсказывает шаги или сам находит путь к цели. - Что на выходе: текст в чате или готовый документ и действие в сервисе. - Интеграции: работает ли инструмент внутри 1С, CRM, банков, ЭДО и маркетплейсов — список сервисов опубликован на /integrations. - Работа по расписанию: нужно ли человеку каждый раз начинать диалог. - Где инструмент честно сильнее: под каждую задачу подходит свой класс инструментов, и на страницах сравнения это сказано прямо. --- Source: https://samreshuuu.ru/use-cases/product # Продукт-решения на данных, а не на догадках > Агент собирает обратную связь, ведёт ресёрч, пишет спеки и считает метрики — чтобы команда решала, что строить дальше. Решение остаётся за командой, но на готовых данных. ## Что делает агент - **Обратная связь в одном месте:** собирает отзывы из почты, чатов, маркетплейсов и CRM, группирует по темам, считает частоту - **Ресёрч рынка и конкурентов:** изучает конкурентов, цены и тренды по сотням источников, сводит находки в структурированный отчёт - **Спеки и PRD из идей:** превращает заметки и запросы в черновики спеков, требований и пользовательских историй — готовых к ревью - **Метрики и приоритизация:** подтягивает продуктовые метрики, считает impact/effort, предлагает, что взять в ближайший спринт ## Как это работает Обратную связь агент берёт из почты, мессенджеров, отзывов на Wildberries, Ozon и Яндекс Маркете, тикетов и CRM. При ресёрче параллельно обрабатывает сотни источников, читает первоисточники и сверяет факты со ссылками. Спеки — качественные черновики под ваш формат: проблема, цель, требования, метрики успеха. ## Сценарии - «Разбери отзывы за месяц — что чаще всего просят?» - «Сравни нас с 8 конкурентами по фичам и ценам» - «Сделай черновик PRD на экспорт в Excel по нашим заметкам» - «Посчитай impact/effort для задач из бэклога» - «Найди топ-5 болей пользователей за квартал» ## Ссылки - Главная: https://samreshuuu.ru - Интеграции: https://samreshuuu.ru/integrations - Цены: https://samreshuuu.ru/pricing - Аналитика данных: https://samreshuuu.ru/use-cases/analytics --- Source: https://samreshuuu.ru/use-cases/support # Поддержка, которая не копит очередь и не теряет клиентов > Агент разбирает обращения из чатов и маркетплейсов, готовит ответы по тону бренда и эскалирует спорное — быстро и без выгорания команды. Подключаете каналы за минуты и поручаете агенту очередь, отзывы и базу знаний, а команда занимается сложными случаями. ## Что закрывает агент - **Очередь обращений под контролем:** собирает сообщения из Wazzup, Telegram, Avito и маркетплейсов в одну очередь, группирует по темам и расставляет приоритеты по срочности - **Ответы на отзывы по тону бренда:** готовит ответы на отзывы Ozon и Wildberries, подсвечивает негатив с риском рейтинга и предлагает компенсацию по вашим правилам — на согласование - **Все каналы в одном окне:** видит историю клиента и отвечает в его канале, без переключений между вкладками - **База знаний из частых вопросов:** сводит повторяющиеся вопросы в темы, держит шаблоны и автоответы в актуальном виде ## Каналы Чаты, мессенджеры и маркетплейсы в одной очереди: Wazzup, Telegram, Chat2Desk, Avito, Ozon, Wildberries, Яндекс Маркет, RetailCRM, а также CRM — amoCRM и Битрикс24. ## Сценарии - «Разбери очередь обращений за ночь и подготовь ответы» - «Ответь на новые отзывы на Ozon и WB по тону бренда» - «Подними наверх негатив с риском для рейтинга» - «Предложи компенсацию по претензии в рамках правил» - «Собери частые вопросы за неделю в базу знаний» - «Покажи темы обращений и где растёт нагрузка» ## Ссылки - Главная: https://samreshuuu.ru - Интеграции: https://samreshuuu.ru/integrations - Цены: https://samreshuuu.ru/pricing - Продажи: https://samreshuuu.ru/use-cases/sales --- Source: https://samreshuuu.ru/compare/chatgpt # Сам Решу vs ChatGPT > ChatGPT — универсальный собеседник: отвечает, объясняет, набрасывает черновик. Сам Решу — автономный агент: ставит цель, сам находит путь и доводит задачу до результата прямо в ваших сервисах. Один отвечает текстом — другой доводит задачу до готового файла. ## В чём разница - **Автономность:** ChatGPT подсказывает шаги и ждёт, что вы их выполните; Сам Решу ставит цель и сам находит путь, комбинируя инструменты - **Что на выходе:** ChatGPT говорит, что нужно сделать; Сам Решу делает и отдаёт готовый документ, отчёт или действие в сервисе - **Контекст и данные:** ChatGPT просит объяснять контекст заново; Сам Решу работает в облачном окружении с вашими файлами и данными - **Проверка данных:** ChatGPT отвечает тем, что уже знает; Сам Решу сам исследует и проверяет данные перед действием ## Что Сам Решу делает лучше - **Аналитик, которому можно доверять:** считает в изолированном окружении, запускает скрипты, отдаёт отчёты и графики без галлюцинаций в цифрах - **Документы и отчёты:** Excel, Word, PDF, презентации — собирает готовый файл, а не текст, который ещё надо оформить - **Задачи по расписанию:** настроили один раз — агент сам собирает отчёт каждое утро и присылает в Telegram - **RU-интеграции из коробки:** Битрикс24, 1С, Ozon, Wildberries, МойСклад, Точка — 97 сервисов - **Подтверждение на деньги и необратимое** перед выполнением действия ## Когда что использовать - **Берите ChatGPT**, если нужен быстрый ответ или объяснение, мозговой штурм, разовый черновик без интеграций - **Берите Сам Решу**, если задачу нужно выполнить до готового результата, подключить русские сервисы и автоматизировать рутину по расписанию ## Ссылки - Главная: https://samreshuuu.ru - Интеграции: https://samreshuuu.ru/integrations - Цены: https://samreshuuu.ru/pricing - Сравнение с Claude: https://samreshuuu.ru/compare/claude - Сравнение с Алисой Про: https://samreshuuu.ru/compare/yandexgpt --- Source: https://samreshuuu.ru/compare/claude # Сам Решу vs Claude > Claude силён в письме, анализе и коде — ему почти нет равных, когда нужно подумать над текстом. Сам Решу берёт цель и выполняет её в ваших сервисах: собирает данные, оформляет документ, выполняет действие и присылает результат. Claude напишет и подумает — Сам Решу сделает и положит файл. ## В чём разница - **Что вы получаете:** Claude отвечает, анализирует и пишет; Сам Решу отдаёт готовый файл или действие в сервисе - **Доступ к данным:** Claude работает с тем, что вы вставили в чат; Сам Решу сам подключается к Битрикс24, Ozon, 1С, Точке и берёт данные оттуда - **Повторяемость:** у Claude каждый запуск — новый разговор; Сам Решу работает по расписанию и собирает отчёт каждое утро без вас - **Совет или действие:** Claude даёт совет и черновик; Сам Решу выполняет действие в сервисе и присылает подтверждение ## Что Сам Решу делает лучше - **Анализ ваших данных, а не вставленных:** подключается к выгрузкам и базам, считает в изолированном окружении, строит отчёты по реальным данным - **Готовые файлы в ваших форматах:** Excel, Word, PDF, презентации — собирает документ и кладёт в папку, а не выдаёт разметку для копипаста - **Автономная работа по расписанию:** настроили один раз — агент запускает задачу каждый день и присылает результат в Telegram - **RU-бизнес-интеграции из коробки:** Битрикс24, 1С, Ozon, Wildberries, МойСклад, Точка — 97 сервисов; у Claude из коробки нет ни одного - **Действие с подтверждением** на деньги и необратимое ## Когда что использовать - **Берите Claude**, если нужен лучший напарник по тексту, рассуждению, анализу вставленного документа или коду - **Берите Сам Решу**, если задачу нужно выполнить в ваших бизнес-сервисах до результата и автоматизировать по расписанию — часто их используют вместе ## Ссылки - Главная: https://samreshuuu.ru - Интеграции: https://samreshuuu.ru/integrations - Цены: https://samreshuuu.ru/pricing - Сравнение с ChatGPT: https://samreshuuu.ru/compare/chatgpt - Сравнение с Алисой Про: https://samreshuuu.ru/compare/yandexgpt --- Source: https://samreshuuu.ru/compare/yandexgpt # Сам Решу vs Алиса Про > Алиса Про — платная Алиса на модели YandexGPT: отвечает в Поиске, Браузере и на колонке, а в режиме «Нейроэксперт» разбирает загруженные документы. Сам Решу берёт цель и сам выполняет её в ваших сервисах: собирает данные, оформляет документ, выполняет действие и присылает результат. Спросить можно у обоих — сделать у Сам Решу. ## В чём разница - **Что на выходе:** Алиса Про отвечает на вопрос текстом или голосом; Сам Решу выполняет задачу и отдаёт готовый файл или действие в сервисе - **Интеграции:** Алиса Про работает внутри экосистемы Яндекса — Поиск, Браузер, колонка; Сам Решу подключает 97 сервисов — Битрикс24, Точка, 1С, Ozon, Wildberries — и меняет в них данные - **Повторяемость:** Алиса Про ждёт нового вопроса каждый раз; Сам Решу работает по расписанию и собирает отчёт каждое утро без вас - **Исследование и результат:** Алиса Про отвечает тем, что нашла в Поиске и в загруженных файлах; Сам Решу сам исследует, проверяет данные и доводит до результата по шагам ## Что Сам Решу делает лучше - **Аналитик ваших данных:** считает в изолированном окружении, строит графики и отчёты по вашим выгрузкам, а не пересказывает загруженный файл - **Готовые документы:** Excel, Word, PDF, презентации — отдаёт собранный файл, а не текст для копипаста - **Задачи по расписанию:** отчёт по продажам приходит в Telegram каждое утро сам - **Вся RU-экосистема, не только Яндекс:** Битрикс24, 1С, Ozon, Wildberries, МойСклад, Точка — агент работает там, где ваши данные и деньги - **Действие, а не подсказка:** сам выполняет действие в CRM и присылает подтверждение ## Когда что использовать - **Берите Алису Про**, если нужен помощник на каждый день: быстрый ответ в Поиске, разбор документа, голос в Браузере и на колонке - **Берите Сам Решу**, если задачу нужно выполнить до результата, подключить бизнес-сервисы (не только Яндекс) и автоматизировать рутину по расписанию ## Ссылки - Главная: https://samreshuuu.ru - Интеграции: https://samreshuuu.ru/integrations - Цены: https://samreshuuu.ru/pricing - Сравнение с ChatGPT: https://samreshuuu.ru/compare/chatgpt - Сравнение с Claude: https://samreshuuu.ru/compare/claude --- Source: https://samreshuuu.ru/compare/gigachat # Сам Решу vs GigaChat > GigaChat от Сбера отлично говорит по-русски и живёт внутри экосистемы — приложение, Салют, API. Сам Решу берёт цель и сам выполняет её в ваших сервисах: собирает данные, оформляет документ, выполняет действие и присылает результат. Спросить можно у обоих — сделать у Сам Решу. ## В чём разница - **Что на выходе:** GigaChat отвечает на вопрос текстом или генерирует контент; Сам Решу выполняет задачу и отдаёт готовый файл или действие в сервисе - **Интеграции:** GigaChat работает в основном внутри экосистемы Сбера; Сам Решу подключает 97+ сервисов — Битрикс24, Точка, 1С, Ozon, Wildberries, МойСклад — и меняет в них данные - **Повторяемость:** GigaChat ждёт нового запроса каждый раз; Сам Решу работает по расписанию и собирает отчёт каждое утро без вас - **Исследование и результат:** GigaChat отвечает тем, что знает модель; Сам Решу сам исследует, проверяет данные и доводит до результата по шагам ## Что Сам Решу делает лучше - **Аналитик ваших данных:** считает в изолированном окружении, строит графики и отчёты по вашим выгрузкам, а не пересказывает то, что знает модель - **Готовые документы:** Excel, Word, PDF, презентации — отдаёт собранный файл, а не текст для копипаста - **Задачи по расписанию:** отчёт по продажам приходит в Telegram каждое утро сам - **Вся RU-экосистема, не только Сбер:** Битрикс24, 1С, Ozon, Wildberries, МойСклад, Точка — агент работает там, где ваши данные и деньги - **Действие, а не подсказка:** сам выполняет действие в CRM и присылает подтверждение ## Когда что использовать - **Берите GigaChat**, если нужен быстрый ответ на русском, генерация изображений через Kandinsky, работа в приложении Сбера и Салют - **Берите Сам Решу**, если задачу нужно выполнить до результата, подключить бизнес-сервисы (не только Сбер) и автоматизировать рутину по расписанию ## Ссылки - Главная: https://samreshuuu.ru - Интеграции: https://samreshuuu.ru/integrations - Цены: https://samreshuuu.ru/pricing - Сравнение с ChatGPT: https://samreshuuu.ru/compare/chatgpt - Сравнение с Алисой Про: https://samreshuuu.ru/compare/yandexgpt - Сравнение с Claude: https://samreshuuu.ru/compare/claude --- Source: https://samreshuuu.ru/use-cases/reports # Отчёты, которые собираются сами > Кластер сценариев про регулярную отчётность: дневные и недельные сводки, дашборды по выручке и лидам, сведение продаж из разных систем в одну таблицу. Агент берёт цифры из подключённых систем, считает и присылает готовый отчёт в срок — без ручной выгрузки и склейки. ## Что умеет агент с отчётами - **Регулярные сводки по расписанию:** дневной отчёт по деньгам, недельная сводка по продажам и каналам — приходят сами, в Telegram или на почту - **Дашборды с обновлением:** выручка по каналам, лиды и CPL, ROMI по кампаниям — цифры обновляются к планёрке, а не собираются вручную накануне - **Сведение данных из разных систем:** продажи из 1С, CRM и маркетплейсов складываются в одну таблицу с общими справочниками - **Не только цифры, но и выводы:** сравнение с прошлым периодом, аномалии маржи, объяснение, что именно изменилось ## Как это работает Агент читает данные по API из 1С, Битрикс24, amoCRM, Точки, Ozon, Wildberries, Яндекс Директа и Метрики, Google Таблиц и почты. У каждой цифры видно источник, расчёт раскрывается по шагам и воспроизводится. Расписание задаётся словами — «каждое утро», «по понедельникам», «перед планёркой», — и отчёт уходит нужным людям в нужный канал. ## Сценарии - Получать движение денег в Telegram каждое утро - Дашборд выручки по каналам с обновлением по расписанию - Свести продажи из 1С, CRM и маркетплейсов в одну таблицу - Найти аномалии в марже за последние недели - Сравнить месяц с прошлым по выручке и заказам - Отчёт по всем каналам за неделю с ROMI и выводами - Дашборд по лидам и CPL к планёрке - Собрать сводку по воронке продаж за квартал - Сводка по продажам за неделю для РОПа ## Ссылки - Главная: https://samreshuuu.ru - Интеграции: https://samreshuuu.ru/integrations - Цены: https://samreshuuu.ru/pricing - Все сценарии: https://samreshuuu.ru/use-cases - Аналитика на данных: https://samreshuuu.ru/use-cases/analytics - Финансы и бухгалтерия: https://samreshuuu.ru/use-cases/finance --- Source: https://samreshuuu.ru/use-cases/1c # Работа с 1С и ЭДО без ручного переноса > Кластер сценариев вокруг учётного контура: проводки, счета, акты сверки и отчётность из 1С плюс входящие и исходящие документы в ЭДО. Агент читает данные по API, готовит документы и сверки на согласование — платежи он не проводит и подпись не ставит. ## Что умеет агент в 1С - **Отчётность из проводок:** собирает P&L по подразделениям, маржу и динамику прямо из учётных данных, без выгрузки в Excel - **Сверки с банком:** сопоставляет выписку с проводками, находит расхождения, дубли и незакрытые платежи - **Документы через ЭДО:** формирует акт сверки с контрагентом, отправляет и отслеживает статус подписания - **Проверка первички:** сверяет реквизиты, суммы и НДС во входящем счёте с договором и справочником контрагентов - **Учёт как источник для аналитики:** данные 1С сводятся с CRM и маркетплейсами в одну картину продаж ## Как это работает Агент подключается к 1С:Бухгалтерии, 1С:Управлению торговлей, 1С:ERP и другим конфигурациям по API и к оператору ЭДО (Диадок) — читает проводки, документы, справочники и статусы. Доступ выдаётся точечно под нужные участки, каждое действие логируется. Изменения в учёте и отправка документов идут только после подтверждения — агент готовит, решение остаётся за бухгалтером. ## Сценарии - Собрать P&L по подразделениям с ИИ-агентом - Сверить банковскую выписку с проводками в 1С - Сформировать акт сверки с контрагентом по ЭДО - Проверить реквизиты и сумму входящего счёта - Свести продажи из 1С, CRM и маркетплейсов в одну таблицу ## Ссылки - Главная: https://samreshuuu.ru - Интеграции: https://samreshuuu.ru/integrations - 1С: Бухгалтерия: https://samreshuuu.ru/integrations/onec-accounting - 1С: Документооборот: https://samreshuuu.ru/integrations/onec-document-flow - 1С:Бухгалтерия: https://samreshuuu.ru/integrations/onec-accounting - Контур.Диадок: https://samreshuuu.ru/integrations/diadoc - Цены: https://samreshuuu.ru/pricing - Финансы и бухгалтерия: https://samreshuuu.ru/use-cases/finance - Сверки: https://samreshuuu.ru/use-cases/reconciliation --- Source: https://samreshuuu.ru/use-cases/reconciliation # Сверки, на которые не уходит день > Кластер сценариев про сопоставление данных: выписка против проводок, акт сверки с контрагентом, поиск дублей платежей, проверка входящего счёта. Агент сопоставляет строки, показывает расхождения и объясняет каждое — вручную остаётся только решить, что с ними делать. ## Что умеет агент со сверками - **Банк против 1С:** сопоставляет строки выписки с проводками по сумме, дате и контрагенту, отдельно выносит несопоставленное и спорное - **Акты сверки по ЭДО:** собирает акт с контрагентом, отправляет через оператора и следит за статусом подписания - **Дубли и лишние списания:** находит повторные платежи по одному счёту, оплаты вне договора и подозрительные комиссии - **Проверка первички:** сверяет реквизиты, сумму и НДС во входящем счёте с договором и справочником контрагентов - **Разбор расхождений:** к каждому расхождению прикладывает исходные строки обеих сторон, чтобы результат можно было проверить ## Как это работает Агент читает выписки из банка (Точка), проводки и справочники из 1С и документы у оператора ЭДО (Диадок) по API. Сопоставление воспроизводимо: видно, какая строка выписки к какой проводке привязана и почему остаток не сошёлся. Платежи агент не проводит и документы без подтверждения не подписывает — он готовит сверку, решение остаётся за бухгалтером. ## Сценарии - Сверить банковскую выписку с проводками в 1С - Сформировать акт сверки с контрагентом по ЭДО - Найти дубли платежей и лишние списания - Проверить реквизиты и сумму входящего счёта ## Ссылки - Главная: https://samreshuuu.ru - Интеграции: https://samreshuuu.ru/integrations - 1С: Бухгалтерия: https://samreshuuu.ru/integrations/onec-accounting - Диадок: https://samreshuuu.ru/integrations/diadoc - Контур.Диадок: https://samreshuuu.ru/integrations/diadoc - Цены: https://samreshuuu.ru/pricing - 1С и ЭДО: https://samreshuuu.ru/use-cases/1c - Финансы и бухгалтерия: https://samreshuuu.ru/use-cases/finance - Дебиторка: https://samreshuuu.ru/use-cases/receivables --- Source: https://samreshuuu.ru/use-cases/receivables # Дебиторка, за которой следит агент > Кластер сценариев про деньги, которые должны вам и которые должны вы: просрочка по контрагентам, кассовый разрыв и платёжный календарь, очередь платежей поставщикам, клиенты, переставшие платить. Агент держит картину в актуальном состоянии и напоминает вовремя. ## Что умеет агент с дебиторкой - **Просрочка по контрагентам:** собирает долги из 1С с разбивкой по срокам и ранжирует, с кого начинать - **Платёжный календарь:** сводит поступления и обязательства по датам и подсвечивает недели, где грозит кассовый разрыв - **Очередь платежей поставщикам:** показывает, сколько должны и кому платить первым с учётом сроков и штрафов - **Клиенты, которые перестали платить:** связывает данные CRM и учёта и находит тех, кто не платил дольше заданного срока - **Напоминания без ручной рассылки:** пишет письма клиентам и задачи менеджерам по графику, эскалирует, если оплаты нет ## Как это работает Агент читает по API взаиморасчёты и договоры из 1С, выписку из банка (Точка), сделки и контакты из Битрикс24 и amoCRM, остатки и заказы из МойСклад. Сроки, пороги просрочки и адресаты напоминаний задаются словами. Платежи агент не проводит — он готовит реестр и напоминания, отправка и оплата остаются за человеком. ## Сценарии - Собрать дебиторку с просрочкой по контрагентам - Проконтролировать кассовый разрыв и платёжный календарь - Понять, сколько должны поставщикам и кому платить первым - Найти клиентов, которые не платили больше 30 дней ## Ссылки - Главная: https://samreshuuu.ru - Интеграции: https://samreshuuu.ru/integrations - Цены: https://samreshuuu.ru/pricing - Финансы и бухгалтерия: https://samreshuuu.ru/use-cases/finance - Сверки: https://samreshuuu.ru/use-cases/reconciliation - Отчёты и таблицы: https://samreshuuu.ru/use-cases/reports --- Source: https://samreshuuu.ru/use-cases/proposals # Коммерческое предложение за один запрос > Кластер сценариев вокруг сделки: собрать КП по шаблону из данных CRM, довести его до ответа письмами-напоминаниями и подкрепить сравнением с конкурентами. Агент готовит текст и документ, отправку и цену подтверждает менеджер. ## Что умеет агент с КП - **КП по вашему шаблону:** берёт данные сделки из CRM, подставляет позиции, цены и условия и собирает документ в привычной форме - **Follow-up после отправки:** пишет письма-напоминания под контекст сделки и ведёт их по графику, пока клиент не ответит - **Сравнение с конкурентами:** сводит фичи и цены в таблицу, из которой берутся аргументы для КП и для возражений - **Единый тон и структура:** предложения от разных менеджеров выглядят одинаково, без расхождений в формулировках и условиях ## Как это работает Агент читает сделки, контакты и товарные позиции из Битрикс24 и amoCRM, шаблоны и готовые документы держит в Google Документах и Google Таблицах, письма отправляет через подключённую почту. Цены и условия он берёт из ваших источников, а не придумывает; перед отправкой документ и письмо показываются менеджеру на подтверждение. ## Сценарии - Собрать коммерческое предложение по шаблону - Написать follow-up клиентам после КП - Сравнить продукт с конкурентами по фичам и ценам ## Ссылки - Главная: https://samreshuuu.ru - Интеграции: https://samreshuuu.ru/integrations - Цены: https://samreshuuu.ru/pricing - Отдел продаж: https://samreshuuu.ru/use-cases/sales - Документы: https://samreshuuu.ru/features/documents - Все сценарии: https://samreshuuu.ru/use-cases --- Source: https://samreshuuu.ru/use-cases/documents # Первичка, которую разбирает агент > Кластер сценариев вокруг документов: входящие УПД и акты из ЭДО, проверка счёта перед оплатой, акт сверки с контрагентом, пакет закрывающих за месяц. Агент читает документы, сопоставляет их с данными 1С и показывает, что не сошлось и чего не хватает — подпись и отправка остаются за вами. ## Что умеет агент с документами - **Разбор входящих из ЭДО:** распознаёт реквизиты, номенклатуру и суммы в УПД, актах и счетах-фактурах и сопоставляет каждый документ с договором и заказом - **Проверка счёта перед оплатой:** сверяет реквизиты контрагента, соответствие договору и сумме, ищет дубли и говорит, можно ли отправлять в оплату - **Акты сверки в вашем операторе:** собирает акт по данным 1С и ЭДО — и в Диадоке, и в СБИС, — с расшифровкой расхождений и готовностью к отправке - **Пакет закрывающих за месяц:** сверяет каждую реализацию с актом, УПД и счётом-фактурой и показывает, каких документов не хватает, с черновиками писем контрагентам - **Расхождения с источником:** у каждой цифры видно, откуда она взята — из документа ЭДО или из проводки в 1С ## Как это работает Агент подключается по API к 1С:Бухгалтерии, 1С:Документообороту и операторам ЭДО — Диадоку и СБИС, — читает входящие и исходящие документы, договоры, заказы и проводки. Выгружать документы из 1С вручную не нужно: агент берёт данные прямо из системы, а результат отдаёт таблицей или готовым файлом. Доступ выдаётся точечно, каждое действие логируется. Документы агент готовит, но не подписывает и не отправляет без вашего подтверждения. ## Сценарии - Проверить реквизиты и сумму входящего счёта - Сформировать акт сверки с контрагентом по ЭДО - Сформировать акт сверки в СБИС и сверить с 1С - Разобрать входящие документы ЭДО нейросетью - Собрать пакет закрывающих документов за месяц ## Ссылки - Главная: https://samreshuuu.ru - Интеграции: https://samreshuuu.ru/integrations - Документооборот: https://samreshuuu.ru/integrations/docflow - Контур.Диадок: https://samreshuuu.ru/integrations/diadoc - СБИС: https://samreshuuu.ru/integrations/sbis - 1С:Бухгалтерия: https://samreshuuu.ru/integrations/onec-accounting - 1С:Документооборот: https://samreshuuu.ru/integrations/onec-document-flow - Работа с документами: https://samreshuuu.ru/features/documents - Цены: https://samreshuuu.ru/pricing - 1С и ЭДО: https://samreshuuu.ru/use-cases/1c - Сверки: https://samreshuuu.ru/use-cases/reconciliation - Финансы и бухгалтерия: https://samreshuuu.ru/use-cases/finance --- Source: https://samreshuuu.ru/use-cases/reviews # Работа с отзывами без ручного разбора > Кластер сценариев вокруг отзывов и претензий: ответы на карточках маркетплейсов, мгновенная реакция на негатив, динамика жалоб по неделям и разбор за месяц. Агент читает отзывы, готовит ответы и сводит из них картину проблем — публикацию и компенсацию подтверждает человек. ## Что умеет агент с отзывами - **Ответы в тоне бренда:** разбирает новые отзывы на Ozon и Wildberries и готовит ответ под каждый — с учётом товара, оценки и того, что именно не понравилось - **Реакция на негатив:** отслеживает поступающие отзывы и обращения, распознаёт то, что грозит рейтингу, и сразу поднимает наверх вместе с черновиком ответа - **Динамика, а не разовые случаи:** строит негатив по неделям и по темам — видно, какие проблемы нарастают, а какие уже закрыты - **Выводы за месяц:** сводит отзывы по всем площадкам, группирует запросы и жалобы по темам и показывает, что просят чаще всего - **Претензии и компенсации:** разбирает обращение, сверяется с вашими правилами и предлагает вариант, который снимет конфликт без лишних расходов ## Как это работает Агент читает отзывы и обращения по API из Ozon, Wildberries и подключённой почты, а срочное присылает в Telegram. Ответы пишутся по вашим примерам и правилам тона, компенсации — по вашей матрице, а не по догадке. Каждый вывод раскрывается до конкретных отзывов, на которых он построен. Публикация ответа и решение по компенсации остаются за человеком — агент готовит, вы подтверждаете. ## Сценарии - Ответить на отзывы на Ozon и WB в тоне бренда - Поднимать наверх негатив с риском для рейтинга - Показать динамику негативных отзывов по неделям - Разобрать отзывы за месяц: что чаще всего просят - Предложить компенсацию по претензии в рамках правил ## Ссылки - Главная: https://samreshuuu.ru - Интеграции: https://samreshuuu.ru/integrations - Ozon: https://samreshuuu.ru/integrations/ozon - Wildberries: https://samreshuuu.ru/integrations/wildberries - Маркетплейсы: https://samreshuuu.ru/integrations/marketplaces - Цены: https://samreshuuu.ru/pricing - Для селлеров: https://samreshuuu.ru/use-cases/sellers - Поддержка клиентов: https://samreshuuu.ru/use-cases/support - Продукт и исследования: https://samreshuuu.ru/use-cases/product - Все сценарии: https://samreshuuu.ru/use-cases --- Source: https://samreshuuu.ru/trust # Безопасность и доверие > Безопасно. Прозрачно. Под вашим контролем. Агент спрашивает разрешение, записывает каждый шаг и умеет отменять свои действия. Ваши данные видите только вы. ## Контроль действий Агент ничего не делает втайне. Вы видите каждое действие, одобряете его и можете отменить. - **Согласие на действия** — перед изменением данных или отправкой во внешний сервис агент спросит вас. - **История действий** — видно, что агент сделал, когда и с каким результатом. - **Откат изменений** — любое изменение можно отменить и вернуть, как было. - **Вы задаёте рамки** — вы решаете, что агент делает сам, а что — только с вашего одобрения. ## Защита данных Мы не обучаем модели на ваших данных. Доступ к ним есть только у вас и тех, кому вы его дали. - **Шифрование** — данные зашифрованы при передаче (TLS) и при хранении. - **Только ваша команда** — данные организаций разделены: никто чужой их не увидит. - **Соответствие 152-ФЗ** — данные хранятся на серверах в России и не передаются третьим лицам. - **Резервные копии** — копии создаются автоматически: при сбое данные восстанавливаются. - **Ключи интеграций** — хранятся в зашифрованном виде и отзываются в один клик. ## Соответствие требованиям Платформа соответствует требованиям Федерального закона №152-ФЗ «О персональных данных». Данные обрабатываются и хранятся на территории России. Ключи и токены интеграций хранятся в зашифрованном виде и отзываются в один клик. ## Ссылки - Главная: https://samreshuuu.ru - Интеграции: https://samreshuuu.ru/integrations - Цены: https://samreshuuu.ru/pricing --- Source: https://samreshuuu.ru/docs # samreshuuu API Интегрируйте AI-возможности в ваш продукт: генерация текста, агенты, обработка документов и автоматизация задач. ## Начало работы ### Установите зависимости ```bash # No SDK required — the API is plain HTTP + Server-Sent Events. # Python: pip install requests # Node.js: built-in fetch (Node 18+) ``` ### Настройте переменные окружения ```bash export SAMRESHUUU_API_KEY="sk-org-your_api_key" export SAMRESHUUU_BASE_URL="https://samreshuuu.ru/api/v1" ``` ### Запустите ход `POST /sessions/stream` запускает ход и возвращает `202` с его идентификаторами — он не стримит. Используйте полученные `session_id` и `message_id`, чтобы подписаться на следующем шаге. **Python** ```python import requests, os API_KEY = os.environ["SAMRESHUUU_API_KEY"] BASE = os.environ["SAMRESHUUU_BASE_URL"] headers = {"Authorization": f"Bearer {API_KEY}"} spawn = requests.post( f"{BASE}/sessions/stream", headers=headers, json={"message": "Summarize the key points of this contract"}, ).json() session_id, message_id = spawn["session_id"], spawn["message_id"] ``` **Node.js** ```typescript const API_KEY = process.env.SAMRESHUUU_API_KEY; const BASE = process.env.SAMRESHUUU_BASE_URL; const headers = { Authorization: `Bearer ${API_KEY}` }; const spawn = await fetch(`${BASE}/sessions/stream`, { method: "POST", headers: { ...headers, "Content-Type": "application/json" }, body: JSON.stringify({ message: "Summarize the key points of this contract" }), }).then((r) => r.json()); const { session_id, message_id } = spawn; ``` **cURL** ```bash curl -X POST "$SAMRESHUUU_BASE_URL/sessions/stream" \ -H "Authorization: Bearer $SAMRESHUUU_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "message": "Summarize the key points of this contract" }' # → { "session_id": "ses_abc123", "message_id": "msg_def456", "kind": "new_turn" } ``` ### Читайте поток событий Подпишитесь на устойчивый журнал событий хода через SSE. Каждый фрейм — строка `data:` с JSON-полем `type`. Полная таксономия событий и семантика возобновления — на странице [Стриминг (SSE)](/docs/streaming). **Python** ```python with requests.get( f"{BASE}/sessions/{session_id}/messages/{message_id}/stream", headers=headers, stream=True, ) as resp: for line in resp.iter_lines(): if line: print(line.decode()) ``` **cURL** ```bash curl -N "$SAMRESHUUU_BASE_URL/sessions/$SESSION_ID/messages/$MESSAGE_ID/stream" \ -H "Authorization: Bearer $SAMRESHUUU_API_KEY" ``` ```json data: {"type": "start", "session_id": "ses_abc123"} data: {"type": "delta", "content": "Here are the key points of the contract:\n\n"} data: {"type": "delta", "content": "1. **Term**: 24 months starting March 2026\n"} data: {"type": "complete", "session_id": "ses_abc123", "final_response": "Here are the key points...", "total_input_tokens": 150, "total_output_tokens": 89} ``` ## Доступные модели samreshuuu предоставляет доступ к лучшим моделям для различных задач. Актуальный список — с доступностью и ценами — возвращает эндпоинт `GET /api/v1/models`. | Модель | ID | Примечание | | --- | --- | --- | | DeepSeek V4 Flash | `deepseek` | Модель по умолчанию | | MiniMax M3 | `minimax` | | | NVIDIA Nemotron 3 Super | `nvidia` | | | NVIDIA Nemotron 3 Ultra | `nvidia_ultra` | | | Sber GigaChat 2 | `gigachat` | | | YandexGPT | `yandexgpt` | | [Посмотреть все модели и цены →](/docs/reference) **Полезные ссылки** - [Аутентификация — Bearer-токены и контекст организации](/docs/authentication) - [Агенты — создание агентов, привязка коннекторов, выдача учётных записей](/docs/agents) - [Ошибки и лимиты — формат ошибок, HTTP-коды, retry-логика](/docs/reference) ## FAQ ### Нужен ли SDK для работы с API samreshuuu? Нет. API — это обычный HTTP плюс Server-Sent Events. В Python подойдёт `requests`, в Node.js 18+ — встроенный `fetch`. Если вы предпочитаете OpenAI SDK, доступен OpenAI-совместимый эндпоинт. ### Как запустить ход и прочитать ответ? `POST /api/v1/sessions/stream` запускает ход и возвращает `202` с `session_id` и `message_id` — сам он не стримит. Подпишитесь на `GET /sessions/{session_id}/messages/{message_id}/stream` по SSE, чтобы читать события. ### Какие модели доступны? DeepSeek V4 Flash (модель по умолчанию), MiniMax M3, NVIDIA Nemotron 3 Super и Ultra, Sber GigaChat 2 и YandexGPT. Всегда актуальный список с доступностью и ценами возвращает `GET /api/v1/models`. ### Как устроен base URL? Нативный API — по адресу `https://samreshuuu.ru/api/v1`. OpenAI-совместимый эндпоинт использует `https://samreshuuu.ru/v1`. --- Source: https://samreshuuu.ru/docs/openai-compatible # OpenAI-совместимый API samreshuuu предоставляет drop-in эндпоинт `chat/completions`. Если вы уже используете OpenAI SDK, поменяйте base URL и API-ключ — больше ничего. - **Base URL:** `https://samreshuuu.ru/v1` - **Авторизация:** API-ключ со scope `chat` (см. [Аутентификацию](/docs/authentication)) ## Drop-in пример **Python** ```python from openai import OpenAI client = OpenAI( api_key="sk-org-your_api_key", base_url="https://samreshuuu.ru/v1", ) resp = client.chat.completions.create( model="samreshuuu", messages=[{"role": "user", "content": "Summarize this contract"}], ) print(resp.choices[0].message.content) ``` **Node.js** ```typescript import OpenAI from "openai"; const client = new OpenAI({ apiKey: "sk-org-your_api_key", baseURL: "https://samreshuuu.ru/v1", }); const resp = await client.chat.completions.create({ model: "samreshuuu", messages: [{ role: "user", content: "Summarize this contract" }], }); console.log(resp.choices[0].message.content); ``` **cURL** ```bash curl https://samreshuuu.ru/v1/chat/completions \ -H "Authorization: Bearer sk-org-your_api_key" \ -H "Content-Type: application/json" \ -d '{ "model": "samreshuuu", "messages": [{"role": "user", "content": "Summarize this contract"}] }' ``` **О поле model** Параметр `model` требуется OpenAI SDK, но игнорируется сервером — модель выбирает платформа. Передайте любую строку-заглушку. Параметры сэмплирования, такие как `temperature` и `max_tokens`, принимаются ради совместимости, но не учитываются этим эндпоинтом. ## Поля запроса | Field | Type | Description | | --- | --- | --- | | `messages` (required) | `array` | Сообщения чата. Последнее сообщение пользователя задаёт текущий ход; предыдущие считаются историей. | | `stream` | `boolean` | Если true — стримит фреймы OpenAI chat.completion.chunk. По умолчанию false. | | `session_id` | `string` | Передайте session_id, чтобы продолжить предыдущий разговор. Опустите для нового. | | `max_iterations` | `integer` | Лимит цикла агента, 1–50. По умолчанию 25. | | `stream_options` | `object` | Дополнения стриминга. Установите { "include_tool_progress": true }, чтобы также получать именованные SSE-события tool.progress. По умолчанию выключено. | **Этот ключ действует от имени всего кабинета продавца** API-ключ со scope `chat` управляет тем же агентом, что и рабочее пространство — модель имеет доступ ко всему реестру инструментов, включая коннекторы к кабинету продавца и инструмент `terminal`. Относитесь к ключу как к учётным данным аккаунта: выдавайте отдельный ключ на интеграцию, храните только на сервере и ротируйте при утечке. Режима только-для-чтения у этого эндпоинта нет. ## Стриминг Установите `stream: true`, чтобы получать Server-Sent Events в формате чанков OpenAI, завершаемые финальным фреймом `data: [DONE]`. ```bash data: {"id":"chatcmpl-...","object":"chat.completion.chunk","choices":[{"index":0,"delta":{"content":"Here"},"finish_reason":null}]} data: {"id":"chatcmpl-...","object":"chat.completion.chunk","choices":[{"index":0,"delta":{},"finish_reason":"stop"}]} data: [DONE] ``` ### Прогресс инструментов (opt-in) Передайте `stream_options: { "include_tool_progress": true }` (или заголовок `X-Hermes-Tool-Progress: 1`), чтобы получать именованные SSE-события `tool.progress`, чередующиеся со стандартными чанками. Они живут в отдельном канале событий, поэтому строгие OpenAI-клиенты, читающие только `chat.completion.chunk`, их игнорируют — и никогда не сохраняют в историю. Когда опция выключена, поток байт идентичен обычному ответу OpenAI. ```bash event: tool.progress data: {"type":"tool.started","tool_name":"connector","label":"MoySklad","iteration":1} event: tool.progress data: {"type":"tool.completed","tool_name":"connector","label":"MoySklad","success":true,"duration_ms":842} ``` **Многоходовые диалоги** Передавайте один и тот же `session_id` между запросами, чтобы сохранять контекст. Первый ответ создаёт сессию; используйте её id в следующем вызове. ## FAQ ### Что нужно поменять, чтобы использовать OpenAI SDK с samreshuuu? Только base URL (`https://samreshuuu.ru/v1`) и API-ключ. Существующий код `chat.completions` работает без изменений, а ключу нужен scope `chat`. ### Учитывается ли параметр `model`? Нет. OpenAI SDK требует его, но сервер игнорирует и выбирает модель сам — передайте любую строку-заглушку. Параметры сэмплинга вроде `temperature` и `max_tokens` принимаются для совместимости, но на этом эндпоинте не применяются. ### Как сохранять контекст между запросами? Передавайте один и тот же `session_id` в каждом вызове. Первый ответ создаёт сессию; используйте её id, чтобы продолжить диалог. ### Что может API-ключ со scope `chat`? Он управляет тем же агентом, что и рабочее пространство, с доступом ко всему реестру инструментов, включая коннекторы кабинета продавца и инструмент `terminal`. Режима «только чтение» нет — относитесь к ключу как к учётным данным аккаунта, храните на сервере и меняйте при утечке. --- Source: https://samreshuuu.ru/docs/authentication # Аутентификация Все запросы к API требуют аутентификации через Bearer-токен в заголовке Authorization. ## Bearer-токен Включите ваш API-ключ в заголовок Authorization каждого запроса. ```bash curl https://samreshuuu.ru/api/v1/sessions \ -H "Authorization: Bearer sk-org-your_api_key" ``` ## Примеры на разных языках **Python** ```python import requests API_KEY = "sk-org-your_api_key" BASE_URL = "https://samreshuuu.ru/api/v1" headers = {"Authorization": f"Bearer {API_KEY}"} response = requests.get(f"{BASE_URL}/sessions", headers=headers) ``` **Node.js** ```typescript const API_KEY = "sk-org-your_api_key"; const BASE_URL = "https://samreshuuu.ru/api/v1"; const response = await fetch(`${BASE_URL}/sessions`, { headers: { Authorization: `Bearer ${API_KEY}` }, }); const data = await response.json(); ``` **cURL** ```bash curl https://samreshuuu.ru/api/v1/sessions \ -H "Authorization: Bearer sk-org-your_api_key" ``` ## Контекст организации Если вы являетесь участником нескольких организаций, укажите заголовок X-Org-Id для выбора контекста. ```bash curl https://samreshuuu.ru/api/v1/sessions \ -H "Authorization: Bearer sk-org-your_api_key" \ -H "X-Org-Id: org_abc123" ``` ## Формат токенов API-ключи имеют префикс `sk-org-`. Полный секрет показывается только один раз — при создании, сохраните его надёжно. Эндпоинты списка и отзыва возвращают только префикс ключа, никогда не секрет. ## Scopes Каждый ключ несёт список scope, которые проверяются для каждого эндпоинта. Если у ключа нет нужного scope, запрос завершается ошибкой `403 AUTH_PERMISSION_DENIED`. Ключ со scope `admin` обходит все проверки scope. Новые ключи по умолчанию получают `write:tools`, если scope не указаны явно. | Scope | Доступ | | --- | --- | | `read:tools` | Чтение метаданных инструментов и коннекторов | | `write:tools` | Выполнение инструментов и коннекторов | | `read:data` | Чтение данных вашей организации | | `chat` | Вызов OpenAI-совместимого эндпоинта `/v1/chat/completions` | | `connector:gateway` | Прямой доступ к шлюзу коннекторов | | `admin` | Полный доступ — обходит проверки scope | ## Управление ключами Ключи выпускаются, перечисляются и отзываются в рамках организации. Каждый ключ истекает через `expires_in_days` (по умолчанию 90, диапазон 1–365). ```bash # Создать ключ — полный секрет возвращается один раз curl -X POST https://samreshuuu.ru/api/v1/organizations/$ORG_ID/api-keys \ -H "Authorization: Bearer $ADMIN_TOKEN" \ -H "Content-Type: application/json" \ -d '{"name": "production", "scopes": ["chat", "write:tools"], "expires_in_days": 90}' # Список ключей — только префикс, scopes и last_used_at curl https://samreshuuu.ru/api/v1/organizations/$ORG_ID/api-keys \ -H "Authorization: Bearer $ADMIN_TOKEN" # Отозвать ключ curl -X DELETE https://samreshuuu.ru/api/v1/organizations/$ORG_ID/api-keys/$KEY_ID \ -H "Authorization: Bearer $ADMIN_TOKEN" ``` ## Ошибки аутентификации При неверном или истёкшем токене API вернёт ответ с кодом 401. ```json { "detail": { "code": "AUTH_TOKEN_EXPIRED", "message": "The provided authentication token has expired.", "hint": "Generate a new API token in your dashboard." } } ``` ## FAQ ### Как аутентифицировать запрос? Передайте API-ключ как Bearer-токен в заголовке Authorization: `Authorization: Bearer sk-org-your_api_key`. Он нужен в каждом запросе. ### Я состою в нескольких организациях — как выбрать нужную? Передайте заголовок `X-Org-Id` (например, `X-Org-Id: org_abc123`), чтобы выбрать контекст организации для запроса. ### Что будет, если у ключа нет нужного scope? Запрос завершится ошибкой `403 AUTH_PERMISSION_DENIED`. Каждый эндпоинт проверяет свои scopes; ключ со scope `admin` обходит поэндпоинтные проверки, а новые ключи по умолчанию получают `write:tools`. ### Можно ли получить секрет ключа после его создания? Нет. Полный секрет показывается только один раз, при создании. Эндпоинты списка и отзыва возвращают лишь префикс ключа, но не секрет. Ключи истекают через `expires_in_days` (по умолчанию 90, диапазон 1–365). --- Source: https://samreshuuu.ru/docs/streaming # Стриминг (SSE) Нативный API стримит через Server-Sent Events по **двухшаговому протоколу**: вы запускаете ход, затем подписываетесь на его устойчивый журнал событий. Разделение делает стрим возобновляемым — оборванное соединение переподключается и доигрывает с места обрыва, а один ход можно смотреть из нескольких вкладок. **Нужен drop-in в одну строку?** Если вам нужен только потоковый текст и вы уже используете OpenAI SDK — [OpenAI-совместимый эндпоинт](/docs/openai-compatible) стримит в одном запросе и проще. Эта страница описывает нативный протокол и полный набор его событий. ## Протокол ### Запустите ход `POST /api/v1/sessions/stream` **не** стримит — он возвращает `202 Accepted` с идентификаторами хода, запущенного в фоне. ```bash curl -X POST "https://samreshuuu.ru/api/v1/sessions/stream" \ -H "Authorization: Bearer sk-org-your_api_key" \ -H "Content-Type: application/json" \ -d '{ "message": "Summarize the key points of this contract" }' ``` ```json { "session_id": "ses_abc123", "message_id": "msg_def456", "kind": "new_turn" } ``` ### Подпишитесь на журнал событий `GET /api/v1/sessions/{session_id}/messages/{message_id}/stream` возвращает `text/event-stream` и доигрывает все события этого хода. Каждый фрейм несёт `id:` — сохраняйте последний, чтобы возобновиться. ```bash curl -N "https://samreshuuu.ru/api/v1/sessions/ses_abc123/messages/msg_def456/stream" \ -H "Authorization: Bearer sk-org-your_api_key" ``` ```json id: 1709-0 data: {"type": "start", "session_id": "ses_abc123"} id: 1710-0 data: {"type": "delta", "content": "Here are the key points of the contract:\n\n"} id: 1711-0 data: {"type": "tool_started", "tool_name": "web_search", "label": "Searching the web", "iteration": 1} id: 1715-0 data: {"type": "complete", "session_id": "ses_abc123", "final_response": "Here are the key points...", "total_input_tokens": 150, "total_output_tokens": 89} ``` ## Поля запроса Тело `POST /sessions/stream` принимает: | Field | Type | Description | | --- | --- | --- | | `message` (required) | `string` | Ход пользователя. Обязателен message либо document_ids. | | `session_id` | `string` | Передайте session_id, чтобы продолжить предыдущий разговор. Опустите для нового — ответ вернёт новый id. | | `agent_id` | `string` | Выполнить ход под профилем конкретного агента и выданными ему коннекторами. См. Агенты. | | `document_ids` | `array` | Прикрепить ранее загруженные документы к ходу по id. | ## Типы событий Каждый фрейм — это `data:` и JSON-объект с дискриминатором `type`. Это стабильные публичные типы событий — обрабатывайте нужные и **игнорируйте любой `type`, который не распознали**; набор расширяемый. | Тип | Значение | | --- | --- | | `start` | Ход начался. Несёт `session_id`. | | `delta` | Инкремент текста ассистента — добавляйте `content` для живого рендера. | | `tool_started` | Начался вызов инструмента. Несёт `tool_name`, `label`, `iteration`. | | `tool_completed` | Инструмент завершился. Несёт `success`, `message`, `duration_ms`. | | `artifact_start` | Начал стримиться файл/артефакт. Несёт `artifact_id`, `artifact_type`, `title`; `content_type` и `preview_kind`, когда известны, определяют показ до первого фрагмента содержимого. | | `artifact_delta` | Чанк содержимого артефакта (`content_chunk`, `chunk_index`). | | `artifact_complete` | Артефакт готов. Несёт `version`, `content_type`, опционально `download_url`. | | `artifact_update` | Ранее завершённый артефакт был изменён. | | `complete` | **Терминальный успех.** Несёт `final_response`, счётчики токенов и `artifacts`. | | `error` | **Терминальная ошибка.** Несёт код `error`, `message`, `retryable`, `user_message`. | | `canceled` | Ход остановлен. Несёт `reason` (`user_stop`, `timeout`, …) и `partial_response`, если есть. | | `paused` | Ход приостановлен в ожидании пробуждения (форма, таймер или rate-limit). Стрим закрывается штатно — возобновите позже с теми же id. | | `form_request` | Агенту нужен ввод. Несёт `form_kind` (`clarify` \| `integration` \| `channel_connect` \| `approval`), `form_id` и `payload`. | **Канонический ответ — в событии complete** Рендерьте текст `delta` вживую для UX, но авторитетный ответ — это `complete.final_response`, а не склейка дельт. Агент может переписать ответ по ходу, поэтому дельты — промежуточный нарратив, а `final_response` равен сохранённому сообщению. Также могут появляться транзиентные диагностические события (`thinking`, `heartbeat`, `retry_notification`, `browser_frame`) — они не входят в стабильный контракт, их можно пропускать. ## Возобновление оборванного стрима Эндпоинт подписки идемпотентен и безопасен для нескольких вкладок. Чтобы возобновиться после обрыва, верните id последнего фрейма — заголовком `Last-Event-ID` или query-параметром `?since=` — и сервер доиграет только пропущенное. ```bash curl -N "https://samreshuuu.ru/api/v1/sessions/ses_abc123/messages/msg_def456/stream?since=1711-0" \ -H "Authorization: Bearer sk-org-your_api_key" ``` ## Ответ на form_request Когда приходит `form_request`, ход приостанавливается (можно также увидеть событие `paused`). Отправьте ответ пользователя обычным `POST /sessions/stream` с **тем же `session_id`** — платформа направит его в ожидающую форму, а не начнёт новый ход, и исходный ход возобновится на своём стриме. ## Остановка хода `POST /api/v1/sessions/{session_id}/stop` отменяет активный ход. Идемпотентен и всегда возвращает `204`; стрим затем отдаёт событие `canceled` с `reason: "user_stop"`. ```bash curl -X POST "https://samreshuuu.ru/api/v1/sessions/ses_abc123/stop" \ -H "Authorization: Bearer sk-org-your_api_key" ``` **Полезные ссылки** - [OpenAI-совместимый API — стриминг в одном запросе](/docs/openai-compatible) - [Агенты — выполнить ход под профилем агента](/docs/agents) - [Ошибки и лимиты — коды ошибок и retry-логика](/docs/reference) ## FAQ ### Почему нативный стриминг — это двухшаговый протокол? Сначала вы делаете `POST /sessions/stream`, чтобы запустить ход (возвращаются `202` и идентификаторы), затем подписываетесь на его устойчивый журнал событий по SSE. Разделение делает стрим возобновляемым после обрыва и безопасным для просмотра из нескольких вкладок. ### Как возобновить оборванный стрим? Отправьте обратно id последнего кадра — заголовком `Last-Event-ID` или query-параметром `?since=` — и сервер воспроизведёт только пропущенные события. ### В каком событии находится итоговый ответ? В поле `final_response` события `complete`, а не в конкатенации кадров `delta`. Агент может переписать ответ по ходу, поэтому `delta` — промежуточное повествование, а `final_response` равен сохранённому сообщению. ### Что делать с типами событий, которые я не распознаю? Игнорировать их. Набор типов дополняемый — обрабатывайте нужные и пропускайте остальные, включая временные диагностические вроде `thinking` и `heartbeat`. --- Source: https://samreshuuu.ru/docs/agents # Agents API Настраивайте AI-агентов: системный промпт, набор разрешённых коннекторов и доступ к учётным записям организации. Те же эндпоинты используются разделом «Агенты» в самом приложении. ## Что такое агент Агент — это профиль (имя, описание, системный промпт, аватар) плюс список разрешённых коннекторов и выданных учётных записей. Когда вы стартуете сессию с agent_id, ассистент работает под этим профилем и ограничен только теми коннекторами и учётками, которые вы выдали явно. ## Создать агента POST с профилем агента. Обязательное поле — только name, остальные опциональны. ```bash curl -X POST "$BASE/organizations/$ORG_ID/agents" \ -H "Authorization: Bearer $SAMRESHUUU_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "name": "Marketplace Manager", "description": "Watches WB and Ozon stock, replies to reviews", "system_prompt": "You are a senior marketplace operator. Be concise, cite SKU codes.", "avatar_url": "https://cdn.example.com/avatars/mp.png" }' ``` ```json { "id": "8a4b9c12-...-...", "org_id": "...", "name": "Marketplace Manager", "description": "Watches WB and Ozon stock, replies to reviews", "system_prompt": "You are a senior marketplace operator...", "avatar_url": "https://cdn.example.com/avatars/mp.png", "is_enabled": true, "created_by": "...", "created_at": "2026-04-29T10:00:00Z", "connectors": [], "kind": "custom" } ``` ## Список и получение агента В списке системный агент идёт первым, затем ваши пользовательские агенты (с пагинацией). ```bash curl "$BASE/organizations/$ORG_ID/agents?limit=20&offset=0" \ -H "Authorization: Bearer $SAMRESHUUU_API_KEY" curl "$BASE/organizations/$ORG_ID/agents/$AGENT_ID" \ -H "Authorization: Bearer $SAMRESHUUU_API_KEY" ``` ## Обновить или удалить PATCH принимает частичный профиль. DELETE — мягкое удаление. Системный агент только для чтения и на любые мутации возвращает HTTP 400. ```bash curl -X PATCH "$BASE/organizations/$ORG_ID/agents/$AGENT_ID" \ -H "Authorization: Bearer $SAMRESHUUU_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "description": "WB + Ozon + Yandex Market", "is_enabled": true }' curl -X DELETE "$BASE/organizations/$ORG_ID/agents/$AGENT_ID" \ -H "Authorization: Bearer $SAMRESHUUU_API_KEY" ``` ## Разрешённые коннекторы `PATCH /{agent_id}` полем `connectors` задаёт полный список ключей коннекторов, которые агент может вызывать (wildberries, ozon, telegram, …). Пустой массив очищает список. Коннекторы — это какими инструментами агенту разрешено пользоваться; учётки — под какими аккаунтами. ```bash curl -X PATCH "$BASE/organizations/$ORG_ID/agents/$AGENT_ID" \ -H "Authorization: Bearer $SAMRESHUUU_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "connectors": ["wildberries", "ozon", "telegram"] }' ``` ## Доступные учётные записи Возвращает все учётные записи организации, каждую с флагом granted — есть ли уже у агента доступ к ней. Один список, а не два: «что можно выдать» и «что выдано» — это одни и те же строки под двумя предикатами. ```bash curl "$BASE/organizations/$ORG_ID/agents/$AGENT_ID/credentials" \ -H "Authorization: Bearer $SAMRESHUUU_API_KEY" ``` ```json [ { "credential_id": "c1...", "service_name": "wildberries", "instance_id": "wb_main", "account_label": "WB Seller — main", "last_used_at": "2026-04-28T18:21:00Z", "granted": false, "grant_id": null }, { "credential_id": "c2...", "service_name": "ozon", "instance_id": "ozon_main", "account_label": "Ozon Seller", "last_used_at": null, "granted": true, "grant_id": "g1..." } ] ``` ## Выдать учётную запись Берёте credential_id из `GET /{agent_id}/credentials` и выдаёте его агенту. Опциональные scopes сужают, какие части учётки агент может использовать. Отзыв — `DELETE /grants/{grant_id}`. ```bash curl -X POST "$BASE/organizations/$ORG_ID/agents/$AGENT_ID/grants" \ -H "Authorization: Bearer $SAMRESHUUU_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "credential_id": "c1...", "scopes": { "read": true, "write": false } }' curl -X DELETE "$BASE/organizations/$ORG_ID/agents/$AGENT_ID/grants/$GRANT_ID" \ -H "Authorization: Bearer $SAMRESHUUU_API_KEY" ``` ## Запустить сессию под агентом Передайте `agent_id` в теле `POST /sessions/stream`. Вызов запускает ход и возвращает `202` с его id — читайте ответ через SSE, как описано в разделе [Стриминг (SSE)](/docs/streaming). Ассистент возьмёт системный промпт агента и ограничится его коннекторами и учётками. ```bash curl -X POST "$BASE/sessions/stream" \ -H "Authorization: Bearer $SAMRESHUUU_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "message": "Какие SKU за неделю упали по продажам сильнее всего?", "agent_id": "8a4b9c12-...-..." }' ``` ## Доступные инструменты Полный набор инструментов, которые ассистент может вызывать внутри сессии агента. Набор фиксирован и одинаков для всех агентов — различаются только системный промпт и выданные коннекторы / учётные записи. Имена инструментов — это идентификаторы функций в tool_call. _The full agent tool catalog is rendered on this page._ ## Структура описания инструмента Каждое описание инструмента самодостаточно — отдельного слоя гайдов нет. Модель читает описание дословно, поэтому все они следуют одной пятиблочной структуре: 1. **Назначение** — одно-два предложения: что инструмент делает и что возвращает. 2. **Когда использовать** — конкретные сценарии, где этот инструмент — правильный выбор. 3. **Когда НЕ использовать** — границы применимости с указанием конкретного альтернативного инструмента. 4. **Ключевые ограничения** — предусловия, форматы, лимиты, порядок вызовов и контракт ошибок. 5. **Интерпретация результата** — как читать ответ, когда повторять, когда остановиться. Дескрипторы инструментов лежат в config/prompts/tools.yaml и имеют такую форму: ```bash my_tool: display_name: "Display Name" description: >- One-paragraph purpose of the tool — what it does and what it returns. Когда использовать: concrete scenarios where this tool is the right choice. Когда НЕ использовать: cases where another tool fits better — name the alternative. Key constraints: prerequisites, formats, limits, ordering, error contract. Result interpretation: how to read the response, when to retry, when to stop. category: external # read | write | external | llm | code_execution result_type: contextual # authoritative | contextual | action | metadata | status timeout_ms: 30000 is_idempotent: true is_query_tool: false synthesis: prefix: "[MY_TOOL]" examples: - param: "value" schema_overrides: require_fields: ["param"] strip_null_fields: ["optional_field"] ``` ## FAQ ### Что такое агент? Это профиль (имя, описание, системный промпт, аватар) плюс набор разрешённых коннекторов и выданных учётных данных. Запуск сессии с `agent_id` ограничивает ассистента именно этими коннекторами и учётными данными. ### Чем разрешённые коннекторы отличаются от выданных учётных данных? Коннекторы определяют, какие инструменты агент может использовать; учётные данные решают, под какими аккаунтами он действует. Коннекторы задаются через `PATCH /{agent_id}` полем `connectors`, а учётные данные выдаются из `GET /{agent_id}/credentials`. ### Как запустить чат-сессию под конкретным агентом? Передайте `agent_id` в теле `POST /sessions/stream`. Ход использует системный промпт агента и ограничен его выданными коннекторами и учётными данными; ответ читается по SSE. ### Можно ли изменить или удалить встроенного системного агента? Нет. Системный агент доступен только для чтения и отклоняет изменения с HTTP 400. Ваши собственные агенты поддерживают PATCH (частичное обновление) и DELETE (мягкое удаление). --- Source: https://samreshuuu.ru/docs/code-execution # Выполнение кода и песочница Когда ассистент выполняет shell-команду, ячейку Python или сборку — это происходит внутри управляемой песочницы, а не на хосте, который обслуживает API. Эта страница описывает, **где** идёт выполнение (бэкенды), **насколько оно изолировано** и **какие инструменты** использует агент — с параметрами и форматом ответа. **Бэкенд выбирает платформа** Бэкенд исполнения выбирается платформой при развёртывании, а не в запросе к API. Вы пишете одни и те же вызовы инструментов независимо от бэкенда; уровень изоляции — это операционная гарантия, а не параметр. ## Бэкенды исполнения Активный бэкенд задаётся настройкой `SANDBOX_BACKEND` (список фолбэков через запятую; первый элемент — основной). Все бэкенды предоставляют одинаковый набор инструментов — различаются только изоляция и персистентность. | Бэкенд | Что это | Изоляция | Когда | | --- | --- | --- | --- | | `e2b` | Управляемая облачная песочница (по умолчанию) | Полная VM-изоляция, ФС на сессию | По умолчанию для облачных запусков | | `firecracker` | microVM Firecracker | Аппаратная виртуализация, UFFD-память, пул сети | Максимальная изоляция, быстрый старт | | `local` | Этот хост | Bind-jail воркспейса + git staging jail | Доверенный self-host / разработка | ## Изоляция и контейнмент Контейнерные и microVM-бэкенды работают под профилем контейнмента, а не как голый shell: - **Файловая тюрьма** — доступ к файлам ограничен воркспейсом сессии; выход за пределы корня отклоняется до любого I/O. - **Egress-прокси** — исходящая сеть идёт через контролируемый egress, а не через сырую сеть хоста. - **ФС на сессию** — у каждой сессии свой воркспейс; установленные пакеты и смена `cwd` сохраняются между вызовами в рамках сессии. - **Уровень microVM** — на `firecracker` нагрузка идёт в аппаратно-виртуализированной microVM с собственным ядром, изолированной от хоста и других сессий. **local — это не песочница** `SANDBOX_BACKEND=local` работает на хосте только с bind-jail воркспейса и git staging jail. Используйте для доверенного self-host или разработки — никогда для недоверенного ввода. ## Инструменты ### `sandbox_bash` — shell / Python Разовое выполнение команды в песочнице. Возвращает захваченные потоки и файлы, записанные в воркспейс. | Field | Type | Description | | --- | --- | --- | | `command` (required) | `string` | Shell-команда для выполнения. | | `description` | `string` | Короткая метка того, что делает команда, напр. 'Установка зависимостей'. | | `timeout_seconds` | `int (1–3600)` | Таймаут команды. По умолчанию 60с; повышайте для долгих установок, сборок, экспортов. | | `cwd` | `string` | Рабочая директория (напр. /workspace). По умолчанию: домашняя в песочнице. | Возвращает: | Поле | Значение | | --- | --- | | `stdout` / `stderr` | Захваченные потоки вывода. | | `exit_code` | Код выхода процесса. | | `truncated` | `true`, если вывод обрезан по лимиту размера. | | `files` / `file_count` | Файлы, созданные командой в воркспейсе. | | `local_paths` | Карта файлов воркспейса в извлекаемые пути. | ### `repl_execute` — постоянный Python REPL Jupyter-подобная сессия Python, сохраняющая состояние между вызовами, со встроенными хелперами (`peek`, `grep`, `chunk_indices`, `llm_query`, `FINAL`) для работы с большими данными без перезагрузки на каждом шаге. ### `exec_command` — живая shell-сессия Запускает команду в shell-сессии на привязанной машине (пайпы, не эмулятор терминала). Завершившиеся команды сразу возвращают `stdout` + `exit_code`; долгоживущие процессы (серверы, REPL, watcher'ы) остаются живыми и возвращают `session_id`, в который вы пишете через `write_stdin`. | Field | Type | Description | | --- | --- | --- | | `command` (required) | `string` | Команда для запуска в shell-сессии. | | `grace_seconds` | `float` | Сколько ждать завершения быстрой команды до возврата живого session_id. | Возвращает `session_id`, `pid`, `stdout`, `cursor`, `status`, `exit_code`, `alive` — `cursor` позволяет следующему чтению продолжить ровно с того места, где остановилось прошлое. ### `write_stdin` — управление живой сессией Отправляет символы в stdin ещё работающей сессии `exec_command` и читает свежий вывод. Добавьте `\n`, чтобы отправить строку. | Field | Type | Description | | --- | --- | --- | | `session_id` (required) | `string` | Session id из прошлого exec_command, который ещё жив. | | `input` (required) | `string` | Символы в stdin. Добавьте \n, чтобы отправить строку. | | `since` | `int` | Курсор из прошлого чтения; вернёт только вывод, появившийся после него. | | `wait_seconds` | `float` | Сколько ждать нового вывода до возврата. | ### `edit_file` — точечные правки файлов Search-and-replace правки файлов в песочнице с фолбэком на нечёткое сопоставление, когда целевой текст слегка изменился. ### `bsl_check` — статический анализ 1С (BSL) Запускает `bsl-language-server` по коду 1С. Укажите `.bsl` / `.os` файл или папку выгрузки конфигурации; возвращает диагностику. **Полный список инструментов** Эта страница покрывает инструменты выполнения кода. Полный каталог по всем категориям (поиск, память, коннекторы, медиа, …) — на странице Агенты → Доступные инструменты. --- Source: https://samreshuuu.ru/docs/reference # Ошибки и лимиты Формат ошибок, HTTP-коды, коды ошибок по категориям, заголовки лимитов и retry-логика. ## Ошибки ### Формат ошибки REST-эндпоинты возвращают ошибки в едином формате с полями `code`, `message` и необязательным `hint`, обёрнутыми в объект `detail`. Инструменты MCP используют другой формат — см. ниже. ```json { "detail": { "code": "DOCUMENT_FORMAT_UNSUPPORTED", "message": "The uploaded file format is not supported.", "hint": "Supported formats: PDF, DOCX, XLSX, TXT, CSV, JSON, HTML, MD" } } ``` | Поле | Тип | Описание | | --- | --- | --- | | code | string | Машиночитаемый код ошибки (например, DOCUMENT_FORMAT_UNSUPPORTED) | | message | string | Человекочитаемое описание ошибки | | hint | string? | Необязательная подсказка для исправления ошибки | ### Ошибки инструментов MCP Инструменты, вызываемые через MCP (например, `connector_execute`), не используют HTTP-коды. Они возвращают структурированный конверт с флагом `retryable` вместо `hint`: ```json { "code": "SERVICE_RATE_LIMITED", "message": "Upstream service is rate limiting requests.", "retryable": true } ``` Если `retryable` равно `true`, вызов можно повторить после небольшой задержки; если `false`, повтор с теми же аргументами снова завершится ошибкой. ### HTTP-коды ответов | Код | Описание | | --- | --- | | 200 | Success | | 201 | Created — ресурс успешно создан | | 204 | No Content — успешное удаление | | 400 | Bad Request — неверные параметры или тело запроса | | 401 | Unauthorized — отсутствует или недействителен токен | | 403 | Forbidden — у токена нет нужного scope | | 404 | Not Found — ресурс не существует | | 409 | Conflict — ресурс уже существует (идемпотентность) | | 422 | Unprocessable Entity — ошибка валидации | | 429 | Too Many Requests — превышен лимит запросов | | 500 | Internal Server Error | | 504 | Gateway Timeout — запрос выполнялся слишком долго | ### Коды ошибок по категориям Часто встречающиеся коды ошибок по категориям. Полный актуальный список доступен в [интерактивном API-эксплорере](/docs/api-explorer). | Категория | Коды | | --- | --- | | Authentication | `AUTH_TOKEN_EXPIRED` `AUTH_TOKEN_INVALID` `AUTH_HEADER_MISSING` `AUTH_PERMISSION_DENIED` `AUTH_SCOPE_MISSING` | | Documents | `DOCUMENT_FORMAT_UNSUPPORTED` `DOCUMENT_SIZE_EXCEEDED` `DOCUMENT_PASSWORD_PROTECTED` `DOCUMENT_OCR_FAILED` `DOCUMENT_NOT_FOUND` | | LLM | `LLM_PROVIDER_UNAVAILABLE` `LLM_REQUEST_TIMEOUT` `LLM_PROVIDER_ERROR` `LLM_RATE_LIMITED` | | Tools | `TOOL_VALIDATION_FAILED` `TOOL_NOT_FOUND` `TOOL_TIMEOUT` `TOOL_EXECUTION_FAILED` | | Data | `DATA_NOT_FOUND` `DATA_CONFLICT` `DATA_INVALID_PARAMETER` `DATA_QUOTA_EXCEEDED` | | Service | `SERVICE_UNAVAILABLE` `SERVICE_RATE_LIMITED` `SERVICE_CONNECTION_LOST` `SERVICE_CIRCUIT_OPEN` | ### Пример обработки ошибок Рекомендуемый подход к обработке ошибок API на Python. ```python import requests response = requests.post(url, headers=headers, json=body) if response.status_code >= 400: error = response.json().get("detail", {}) code = error.get("code", "UNKNOWN") message = error.get("message", "An error occurred") hint = error.get("hint") if response.status_code == 429: # Rate limited — retry after delay retry_after = response.headers.get("Retry-After", "60") print(f"Rate limited. Retry after {retry_after}s") elif response.status_code == 401: # Authentication error print(f"Auth error: {message}") else: print(f"Error [{code}]: {message}") if hint: print(f"Hint: {hint}") ``` ## Лимиты запросов ### Заголовки лимитов Каждый ответ API включает заголовки с информацией о текущих лимитах. ```bash HTTP/1.1 200 OK X-RateLimit-Limit: 60 X-RateLimit-Remaining: 58 X-RateLimit-Reset: 1711540800 ``` | Заголовок | Описание | | --- | --- | | X-RateLimit-Limit | Максимальное количество запросов в окне | | X-RateLimit-Remaining | Оставшееся количество запросов | | X-RateLimit-Reset | Unix-время сброса окна лимита | | Retry-After | Секунды до повторной попытки (только при 429) | ### Лимиты по тарифам Лимиты запросов в минуту зависят от вашего тарифного плана и общие для всей организации. | Тариф | Запросы | | --- | --- | | Free | 10 req/min | | Pro | 30 req/min | | Max | 60 req/min | Сейчас применяется только лимит в минуту. ### Ответ при превышении лимита При превышении лимита API возвращает статус 429 с информацией о времени ожидания. ```json { "detail": { "code": "SERVICE_RATE_LIMITED", "message": "Rate limit exceeded. Please retry after the reset time.", "hint": "Check X-RateLimit-Reset header for the reset timestamp." } } ``` ### Повторные попытки Реализуйте экспоненциальную задержку при получении 429-ответов. ```python import time import requests def request_with_retry(url, headers, max_retries=3): for attempt in range(max_retries): response = requests.get(url, headers=headers) if response.status_code == 429: retry_after = int(response.headers.get("Retry-After", "60")) print(f"Rate limited. Retrying in {retry_after}s...") time.sleep(retry_after) continue return response raise Exception("Max retries exceeded") ``` ### Лучшие практики - Кэшируйте ответы, которые не меняются часто (например, список моделей) - Используйте экспоненциальную задержку при повторных попытках - Следите за заголовками X-RateLimit-Remaining для предупреждения о приближении к лимиту - Для пакетных операций используйте batch-эндпоинты вместо множественных одиночных запросов --- Source: https://samreshuuu.ru/docs/api-explorer # Интерактивный API-эксплорер Каждый публичный эндпоинт можно просмотреть и вызвать прямо в браузере. Он генерируется из живой OpenAPI-спеки, поэтому никогда не расходится с реальным API. - **Эксплорер:** [samreshuuu.ru/api/v1/developers/docs](https://samreshuuu.ru/api/v1/developers/docs) - **OpenAPI-спека:** [samreshuuu.ru/api/v1/developers/openapi.json](https://samreshuuu.ru/api/v1/developers/openapi.json) ## Авторизация Каждый запрос несёт API-ключ как bearer-токен: ```bash curl "$BASE/api/v1/sessions" \ -H "Authorization: Bearer $SAMRESHUUU_API_KEY" ``` Отсутствующий или неверный токен возвращает `401`; действительный токен без нужного scope — `403`. Полный контракт статус-кодов и кодов ошибок — в разделе [Ошибки и лимиты](/docs/reference). ## Сгенерировать клиент Спека — это стандартный OpenAPI 3, передайте её любому генератору, чтобы получить типизированный клиент. ```bash npx @openapitools/openapi-generator-cli generate \ -i https://samreshuuu.ru/api/v1/developers/openapi.json \ -g typescript-fetch \ -o ./samreshuuu-client ``` Та же спека работает с любым OpenAPI-совместимым тулчейном — поменяйте цель `-g` на `python`, `go`, `java` и так далее, либо направьте инструменты вроде `openapi-typescript` прямо на URL. **Что входит в публичную поверхность** Эксплорер охватывает `sessions`, `documents`, `knowledge`, `tasks`, `executions`, `agents`, `models` и `chat-completions`. Коннекторы **не** доступны через REST — обращайтесь к ним через агента (через [chat](/docs/openai-compatible)) или инструмент `connector_execute` по [MCP](/docs/mcp). ## Лимиты вкратце API применяет поминутный лимит запросов, общий на организацию: | Field | Type | Description | | --- | --- | --- | | `Free` | `10 зап/мин` | Общий на организацию. | | `Pro` | `30 зап/мин` | Общий на организацию. | | `Max` | `60 зап/мин` | Общий на организацию. | Каждый ответ включает `X-RateLimit-Limit`, `X-RateLimit-Remaining` и `X-RateLimit-Reset`; `429` добавляет `Retry-After`. Полное руководство по повторным попыткам — в разделе [Ошибки и лимиты](/docs/reference). ## FAQ ### Что охватывает интерактивный API-эксплорер? Каждый публичный REST-эндпоинт — `sessions`, `documents`, `knowledge`, `tasks`, `executions`, `agents`, `models` и `chat-completions` — можно просмотреть и вызвать в браузере; он генерируется из живой OpenAPI-спеки, поэтому не расходится с реальным API. Коннекторы не входят в REST-поверхность; к ним обращаются через ассистента или [инструменты коннекторов](/docs/connector-flow). ### Как авторизовать запрос? Передайте API-ключ как bearer-токен в заголовке `Authorization` — `Authorization: Bearer YOUR_API_KEY`. Отсутствующий или неверный токен возвращает `401`; токен без нужного scope — `403`. ### Можно ли сгенерировать типизированный клиент из API? Да. Спека по адресу [`/api/v1/developers/openapi.json`](https://samreshuuu.ru/api/v1/developers/openapi.json) — это стандартный OpenAPI 3, передайте её любому генератору (`openapi-generator`, `openapi-typescript`, …), чтобы получить типизированный клиент на вашем языке. ### Есть ли лимиты на API? Да — поминутный лимит запросов, общий на организацию (Free 10, Pro 30, Max 60 запросов/мин). Ответы несут заголовки `X-RateLimit-*`, а `429` включает `Retry-After`. См. [Ошибки и лимиты](/docs/reference). --- Source: https://samreshuuu.ru/docs/connectors # Коннекторы и сервисы Коннектор — это зарегистрированный внешний сервис, который ассистент может вызвать от вашего имени: маркетплейс, CRM, банк, систему документооборота, мессенджер, аналитическую платформу и так далее. В каталоге **97 коннекторов** в 16 категориях, и каждый вызывается через одни и те же три инструмента: получить каталог, прочитать паспорт сервиса, выполнить вызов. ## Как вызываются коннекторы Коннекторы **не** выставлены как REST-ресурсы — эндпоинта `POST /connectors/{service}/execute` нет. Достучаться до них можно двумя способами: - **Через ассистента** — запустите [чат-сессию](/docs/openai-compatible) (опционально под [агентом](/docs/agents)); модель сама выберет нужный коннектор и вызов. - **Через инструменты коннекторов напрямую** — `list_services`, `describe_service` и `connector_execute`, доступные и как нативные инструменты агента, и через [MCP-сервер](/docs/mcp) (`/mcp`, авторизация по bearer). См. [Вызов коннектора](/docs/connector-flow). REST-эндпоинты под `/api/v1/connectors/*` отвечают только за управление подключением (метаданные экрана подключения, webhook-URL) — но не за исполнение. ## Подключение аккаунта Прежде чем коннектор вернёт реальные данные, организация-владелец подключает к нему аккаунт. Учётные данные шифруются при хранении и подставляются на каждый вызов. Каталог охватывает три схемы авторизации — API-ключи, popup OAuth и device-code — см. [Подключение аккаунтов](/docs/connector-auth). ## Каталог Каждый коннектор ниже адресуется своим `key`. Тот же каталог публикуется в машиночитаемом JSON для индексации и интеграций. **Машиночитаемый каталог** Полный каталог — `key`, `name`, `description`, `category` — отдаётся в JSON по адресу [`/connectors.json`](/connectors.json) и генерируется из бэкенд-манифестов коннекторов. _The full connector catalog (97 services across 16 categories) is published as machine-readable JSON at /connectors.json._ ## Динамические и ограниченные коннекторы Две позиции каталога **динамические** и настраиваются под каждого тенанта, а не поставляются как статические сервисы: `custom_api` (вызов любого REST API, который вы опишете) и `mcp_server` (подключение внешнего MCP-сервера). Их нет в списке выше, потому что у них нет фиксированного набора возможностей. Несколько сервисов **доступны только администраторам** (например `supadata`) — они есть в каталоге, но ограничены на этапе исполнения. Большинство коннекторов отдают насыщенный структурированный паспорт возможностей; два мессенджер-коннектора (`telegram`, `max_messenger`) отдают тонкий паспорт — только summary и transport, без перечня рецептов. ## FAQ ### Сколько коннекторов доступно? В каталоге 97 коннекторов в 16 категориях — маркетплейсы, CRM, банки, ЭДО, мессенджеры, аналитика и другое. Полный список также публикуется в машиночитаемом JSON по адресу [`/connectors.json`](/connectors.json). ### Есть ли REST-эндпоинт для выполнения коннектора? Нет. Коннекторы — не REST-ресурсы, эндпоинта `POST /connectors/{service}/execute` не существует. Обращайтесь к ним через ассистента (чат-сессия, при необходимости под агентом) или через инструменты коннекторов `list_services`, `describe_service` и `connector_execute`, доступные также по [MCP-серверу](/docs/mcp). REST-эндпоинты `/api/v1/connectors/*` отвечают только за управление подключением. ### Как коннектор получает доступ к аккаунту? Сначала владеющая организация подключает для него аккаунт. Каталог охватывает три схемы авторизации — API-ключи, popup-OAuth и device-code. Учётные данные шифруются при хранении и подставляются на каждый вызов. ### Что за коннекторы `custom_api` и `mcp_server`? Две динамические позиции каталога, настраиваемые под каждого тенанта: `custom_api` вызывает любой REST API, который вы опишете, а `mcp_server` подключает внешний MCP-сервер. У них нет фиксированного набора возможностей, поэтому в статическом каталоге их нет. --- Source: https://samreshuuu.ru/docs/connector-flow # Вызов коннектора Любой коннектор — REST или RPC — вызывается через одни и те же три инструмента. Они доступны как нативные инструменты агента и через [MCP-сервер](/docs/mcp). Флоу всегда один: получить каталог, прочитать паспорт сервиса, выполнить вызов. ### list_services — каталог Возвращает каталог коннекторов: канонический `key` и однострочное summary на каждый сервис. Размером с рукопожатие (~2–5 КБ), поэтому любая сессия может начинаться отсюда. При подключённых аккаунтах каждая позиция помечается `connected: true/false`. ### describe_service — паспорт Возвращает структурированный **паспорт** одного сервиса: его модули, типовые рецепты (конкретные примеры `VERB /path` с шаблонами тела), лимиты, подсказки по полям и пагинации, enum'ы, примеры ответов и `version`/`ttl` для клиентского кэширования. Вызовите без `module` для индекса, затем с `module` — для полной спецификации модуля. ```bash describe_service(service="wildberries") describe_service(service="wildberries", module="statistics") ``` ### connector_execute — вызов Единый исполнитель для любого коннектора. Аргументы валидируются по схеме сервиса **до** любого исходящего HTTP-запроса. ```bash connector_execute( service="wildberries", module="statistics", method="GET", path="/api/v1/supplier/orders", query={"dateFrom": "2026-04-15"} ) ``` ## Параметры connector_execute | Field | Type | Description | | --- | --- | --- | | `service` (required) | `string` | Ключ коннектора из list_services (например wildberries). Может нести суффикс аккаунта — см. адресацию нескольких аккаунтов ниже. | | `module` | `string` | Подобласть коннектора (statistics, content, …), как указано в паспорте. | | `method` (required) | `string` | REST: HTTP-глагол (GET/POST/…). RPC: имя RPC-метода. | | `path` | `string` | REST: путь запроса. RPC: оставьте пустым, имя метода передайте в method. | | `body` | `object` | Тело запроса для записывающих вызовов. | | `query` | `object` | Параметры строки запроса. | | `instance_id` | `string` | Нацелиться на конкретный подключённый аккаунт, когда их несколько. | ## REST vs RPC Коннекторы бывают двух форм, и `connector_execute` обрабатывает обе: - **REST** (большинство коннекторов) — передайте `module`, HTTP-`method`, `path` и `body`/`query`. - **RPC** (например `bitrix24`, семейство `onec`) — оставьте `path` пустым, а имя RPC-метода передайте в `method`. Рецепты в паспорте показывают точную форму для каждого коннектора, так что угадывать почти не приходится. ## Адресация нескольких аккаунтов Когда у организации подключено больше одного аккаунта для сервиса (несколько кабинетов Ozon, например), адресуйте конкретный. **Голое имя** сервиса распределяет чтения по всем подключённым аккаунтам; **записи должны указывать один** — через `instance_id` или суффикс к сервису: ```bash connector_execute(service="ozon:Top Zip", method="POST", path="/v1/product/import", body={ ... }) ``` ## Подсказки did-you-mean Вызовы не падают молча при почти-попадании. Рецепты — это примеры, а не белый список, поэтому: - Неизвестный **module** возвращает жёсткую ошибку с подсказками `did_you_mean` и списком `known_modules`. - Неизвестный или несовпавший **path** всё равно выполняется, но добавляет мягкую подсказку `path_did_you_mean` и меню `available_paths` в метаданных ответа. - Неизвестный **аккаунт** возвращает `UNKNOWN_INSTANCE` со списком `candidates` — и то же самое возвращает запись, не назвавшая аккаунт при нескольких подключённых: код и список те же, потому что и выход тот же — взять `instance_id` из `candidates`. ## Ошибки Вызовы коннекторов возвращают стандартный контракт ошибки инструмента — `code`, `message`, `retryable` и опциональный `hint`. Вызовы через MCP не несут HTTP-статуса. См. [таблицу ошибок MCP](/docs/mcp) и [Ошибки и лимиты](/docs/reference). --- Source: https://samreshuuu.ru/docs/connector-auth # Подключение аккаунтов Коннектор возвращает реальные данные только после того, как организация-владелец подключит к нему аккаунт. Каждый коннектор объявляет, как он авторизуется; ассистент подбирает и расшифровывает нужные учётные данные на каждый вызов. ## Схемы авторизации Коннекторы используют одну из трёх схем, объявленную для каждого сервиса: | Field | Type | Description | | --- | --- | --- | | `credentials` | `схема` | API-ключ, токен или basic-авторизация, вставленные на экране подключения. Преобладающая схема в каталоге. | | `popup_oauth` | `схема` | OAuth-авторизация во всплывающем окне — пользователь подтверждает доступ, токен захватывается автоматически. | | `device_code` | `схема` | Device-code: пользователь подтверждает подключение на сайте провайдера по короткому коду (используется рядом сервисов Яндекса). | Транспорт — то, как секрет прикрепляется к каждому запросу — это отдельная ось (bearer-заголовок, basic, query-токен, HMAC конкретного вендора и так далее) и обрабатывается самим коннектором. ## Где подключаются аккаунты Аккаунты подключаются в интерфейсе продукта в настройках организации; OAuth-коннекторы также показывают кнопку подключения прямо в чате через инструмент `request_form`, когда вызову нужен ещё не подключённый аккаунт. Программно метаданные подключения (какие поля нужны коннектору) доступны по `GET /api/v1/connectors/metadata`. ## Хранение учётных данных Подключённые учётные данные **шифруются при хранении** (Fernet) и хранятся для каждого пользователя. Ассистент никогда не отдаёт сырой секрет; в момент исполнения он подбирает и расшифровывает учётные данные для адресуемого аккаунта. **Несколько аккаунтов (кабинеты)** Один сервис может держать несколько подключённых аккаунтов — несколько кабинетов Ozon, два продавца WB. Каждый — это адресуемый instance; нацельтесь на один через `instance_id` или суффикс сервиса (`ozon:Top Zip`). См. [Вызов коннектора](/docs/connector-flow#multi-account-addressing). ## Выдача коннекторов и учётных данных агенту [Агент](/docs/agents) ограничен теми коннекторами и учётными данными, которые вы ему явно выдали. Выдача — это два слоя: какие у него инструменты и какие аккаунты он может использовать: ### Разрешите коннекторы `PUT /agents/{id}/connectors` задаёт, какие ключи коннекторов агент может вызывать (`wildberries`, `ozon`, …). Это решает, *какие инструменты* у него есть. Коннектор, который агенту не разрешён, просто отсутствует в его наборе инструментов. ### Выдайте учётные данные `POST /agents/{id}/grants` выдаёт агенту конкретный подключённый аккаунт с опциональными scope на чтение/запись. Это решает, *какие аккаунты* он может использовать — разрешённый коннектор без выданного аккаунта всё равно не вернёт данные. ### Агент работает в рамках выдач В момент исполнения агент дотягивается только до разрешённых коннекторов и выданных аккаунтов; всё остальное вне области. Отозвать — удалив грант. Полный флоу выдачи — в [Agents API](/docs/agents). ## FAQ ### Какие схемы авторизации используют коннекторы? Одну из трёх, объявленную для каждого сервиса — `credentials` (API-ключ, токен или basic), `popup_oauth` (OAuth во всплывающем окне) и `device_code` (подтверждение на сайте провайдера по короткому коду). Транспорт, прикрепляющий секрет к каждому запросу, — это отдельная ось, которой занимается сам коннектор. ### Как хранятся учётные данные? Подключённые учётные данные **шифруются при хранении** (Fernet) и хранятся для каждого пользователя. Ассистент никогда не отдаёт сырой секрет; в момент исполнения он подбирает и расшифровывает данные для адресуемого аккаунта. ### Может ли один сервис держать несколько аккаунтов? Да. Один сервис может держать несколько подключённых аккаунтов — несколько кабинетов Ozon, два продавца WB. Каждый — это адресуемый instance; нацельтесь на один через `instance_id` или суффикс сервиса, например `ozon:Top Zip`. ### Как агент получает доступ к коннектору и его учётным данным? В два слоя. `PUT /agents/{id}/connectors` задаёт, какие ключи коннекторов агент может вызывать (какие у него инструменты). `POST /agents/{id}/grants` выдаёт конкретный подключённый аккаунт с опциональными scope на чтение/запись (какие аккаунты он может использовать). Агент дотягивается только до того, что вы явно выдали. --- Source: https://samreshuuu.ru/docs/edo # Электронный документооборот Категория `docflow` охватывает электронный документооборот (ЭДО) и смежные системы — отправку и получение документов через стандартный флоу коннектора. ## Коннекторы документооборота Эти коннекторы вызываются через стандартный [флоу коннектора](/docs/connector-flow). В каталоге, среди прочих: - **Диадок** (`diadoc`) и **СБИС** (`sbis`) — операторы ЭДО: отправка и получение документов. - **Контур.Экстерн** (`kontur_extern`) — отчётность и обмен документами. - **1С** (`onec`) — операции с документами в стиле RPC. - **МойСклад** (`moysklad`) — торговые документы и складской учёт. - **Честный ЗНАК** (`chestnyznak`) — коды маркировки и документы. - **HRlink** (`hrlink`) — кадровый электронный документооборот (КЭДО). ## Вызов коннектора документооборота Каждый коннектор ЭДО использует тот же трёхшаговый флоу, что и любой другой, — найти, прочитать паспорт, выполнить: ### Подключите аккаунт Коннектор ЭДО возвращает реальные данные только после того, как организация-владелец подключит к нему аккаунт. Учётные данные шифруются при хранении и подбираются на каждый вызов — см. [Подключение аккаунтов](/docs/connector-auth). ### Прочитайте паспорт Вызовите [`describe_service`](/docs/connector-flow) для коннектора, чтобы увидеть его модули, конкретные рецепты (verb + path или RPC-метод), подсказки по полям и примеры ответов. Не угадывайте форму — её несёт паспорт. ```bash describe_service(service="diadoc") ``` ### Выполните вызов Отправьте или получите документ через [`connector_execute`](/docs/connector-flow). REST-операторы принимают HTTP-метод и путь; семейство 1С — это RPC: оставьте `path` пустым и передайте имя метода в `method`. **Не только ЭДО — ещё маркировка и склад** Категория шире операторов ЭДО: `chestnyznak` — это коды маркировки, `moysklad` — торговые документы и остатки, `hrlink` — кадровый документооборот (КЭДО). Все следуют одному флоу коннектора. ## FAQ ### Какие системы электронного документооборота (ЭДО) поддержаны? Категория `docflow` охватывает **Диадок**, **СБИС** и **Контур.Экстерн** (операторы ЭДО), семейство **1С**, **МойСклад**, **Честный ЗНАК** для маркировки и **HRlink** для кадрового документооборота (КЭДО). Каждый — это коннектор, адресуемый по своему ключу. ### Как вызвать коннектор ЭДО? Через стандартный [флоу коннектора](/docs/connector-flow): `list_services` для каталога, `describe_service` для паспорта (модули, рецепты, подсказки по полям), затем `connector_execute` для отправки или получения документа. Операторы ЭДО вызываются как любой другой коннектор. ### Нужно ли сначала подключить аккаунт? Да. Коннектор ЭДО возвращает реальные данные только после того, как организация-владелец подключит к нему аккаунт. Учётные данные шифруются при хранении и подбираются на каждый вызов — см. [Подключение аккаунтов](/docs/connector-auth). ### Коннекторы 1С — это REST или RPC? 1С (`onec`) работает в стиле **RPC**: в `connector_execute` оставьте `path` пустым и передайте имя RPC-метода в `method`. Точную форму показывают рецепты паспорта. --- Source: https://samreshuuu.ru/docs/connector-webhooks # Вебхуки и события Коннекторы не только вызываются наружу — многие получают **входящие события** (новая сделка в CRM, входящее сообщение, смена статуса заказа). Эти события попадают в локальный журнал и могут запускать автоматические задачи, так что вы реагируете на происходящее во внешнем сервисе, не опрашивая его. ## Как проходит входящее событие ### Регистрация webhook-URL Для коннектора, поддерживающего входящие события, получите его webhook-URL и зарегистрируйте у провайдера (в настройках самого провайдера или в его консоли разработчика). ### Провайдер шлёт POST-событие Когда на стороне провайдера что-то происходит, он шлёт POST-событие на этот URL. Платформа валидирует запрос и записывает его в локальный журнал. ### Отреагировать Пусть сохранённая [задача](/docs/agents) запускается автоматически в момент поступления подходящего события. ## Webhook-URL Коннекторы, поддерживающие входящие события, выставляют webhook-URL на каждый сервис, который вы регистрируете у провайдера. Получите его программно: ```bash curl "$BASE/connectors/$SERVICE/webhook-url" \ -H "Authorization: Bearer $SAMRESHUUU_API_KEY" ``` Дальше провайдер шлёт POST-события на этот URL; платформа валидирует и записывает их. Поддерживает ли конкретный коннектор входящие события, объявлено в его паспорте — прочитайте его через [`describe_service`](/docs/connector-flow), прежде чем настраивать webhook. ## Запуск задач по событиям Сохранённая [задача](/docs/agents) может запускаться автоматически при поступлении подходящего события. Установите `trigger_type: "webhook"` и опишите, на какие события реагировать: | Field | Type | Description | | --- | --- | --- | | `trigger_type` (required) | `string` | Установите webhook для задач, управляемых событиями (альтернатива — schedule для задач по расписанию или manual только для ручного запуска). | | `trigger_config.service` (required) | `string` | Коннектор, чьи события запускают задачу. | | `trigger_config.event_types` | `string[]` | На какие типы событий этого сервиса реагировать (например message.received, deal.created). | | `trigger_config.all_events` | `boolean` | true — реагировать на любое событие сервиса вместо перечисления. Задаётся вместо event_types, не вместе с ним; задача без того и другого не включается. | | `filter_conditions` | `object[]` | Дополнительные условия на полезную нагрузку события перед запуском задачи. | Когда входящее событие совпадает, задача выполняется с этим событием на входе — превращая любой webhook коннектора в автоматизацию. **Webhook или schedule** Триггер `webhook` реагирует на внешнее событие в момент его возникновения; триггер `schedule` запускается по cron-расписанию (минимальный интервал — пять минут). Выбирайте `webhook`, когда работа — это ответ на случившееся, и `schedule`, когда она должна идти по часам. См. Tasks API в [интерактивном эксплорере](/docs/api-explorer). ## FAQ ### Какие коннекторы могут получать входящие webhook-события? Коннекторы, которые заявляют поддержку входящих событий, выставляют webhook-URL на каждый сервис — типичные источники событий message, lead и deal — это мессенджеры и CRM: `telegram`, `amocrm`, `bitrix24` и `wazzup`. Прочитайте паспорт сервиса через [`describe_service`](/docs/connector-flow), чтобы узнать, поддерживает ли он входящие события. ### Как запустить задачу автоматически при поступлении события? Создайте задачу с `trigger_type: "webhook"` и `trigger_config`, указав `service` и `event_types`, на которые реагировать (либо `all_events: true`, чтобы слушать сервис целиком). Добавьте `filter_conditions`, чтобы сузить, какие полезные нагрузки запускают задачу. Когда приходит подходящее событие, задача выполняется с этим событием на входе. --- Source: https://samreshuuu.ru/docs/mcp # MCP сервер Подключите Claude Desktop, Cursor или любой MCP-клиент к каталогу коннекторов samreshuuu и сэндбоксу для исполнения кода. ## Что это Сервер реализует протокол Model Context Protocol (версия 2025-06-18) поверх Streamable HTTP. Точка монтирования — /mcp/, имя сервера — samreshuuu-coworker. Через него тот же набор инструментов, которым пользуется ассистент в чате, доступен внешним клиентам: каталог из 97 интеграций, REPL для Python и доступ к памяти и Диску пользователя. ## Подключение клиента Добавьте блок ниже в claude_desktop_config.json, mcp.json в Cursor или эквивалентный конфиг вашего клиента. URL и готовый JSON также доступны в настройках проекта. ```json { "mcpServers": { "samreshuuu-coworker": { "url": "https://samreshuuu.ru/mcp/", "headers": { "Authorization": "Bearer sk-org-xxxxxxxxxxxx" } } } } ``` [Создать API-ключ в настройках →](/settings/api-keys) ## Аутентификация Каждый запрос требует заголовок Authorization: Bearer sk-org-… Ключ выдаётся в разделе «API-ключи» настроек организации, имеет скоупы (read:tools, write:tools, read:data, admin, chat) и срок действия. Контекст пользователя и организации привязан к ключу — отдельный X-Org-Id передавать не нужно. ## Публичный info-эндпойнт GET /api/v1/mcp/info возвращает URL, имя сервера, версию протокола, список поддерживаемых скоупов и пример конфига. Эндпойнт не требует аутентификации — удобно для генерации сниппетов на стороне клиента. ```json { "url": "https://samreshuuu.ru/mcp/", "server_name": "samreshuuu-coworker", "protocol_version": "2025-06-18", "supported_scopes": ["read:tools", "write:tools", "read:data", "admin", "chat"], "example_config": { "mcpServers": { "samreshuuu-coworker": { "url": "...", "headers": { "Authorization": "Bearer sk-org-" } } } } } ``` ## Доступные инструменты Те же инструменты, что использует чат-ассистент. user_id и org_id выводятся из bearer-ключа, поэтому каждый вызов работает в контексте владельца ключа. | Инструмент | Назначение | | --- | --- | | `list_services` | Каталог коннекторов: имя + однострочное описание для каждого из 97 сервисов. Hand­shake-размер (~2–5 КБ) — с него начинается любая сессия. | | `describe_service` | Полный паспорт одного сервиса: модули, типовые рецепты, лимиты, подсказки по полям и пагинации, а также version/ttl для клиентского кэша. | | `connector_execute` | Единая точка вызова любого коннектора. Для REST-сервисов — module + HTTP-метод + path + body/query; для RPC (bitrix24, onec и т. п.) — оставьте path пустым, передайте RPC-метод в method. | | `repl_execute` | Исполнение Python-кода в песочнице пользователя. Учётные данные подключённых коннекторов автоматически прокидываются в env (WILDBERRIES_API_KEY и т. п.). Запрошенные навыки монтируются в `/mnt/skills//scripts/`. | | `read_memory` | Чтение персонального хранилища памяти пользователя: read одного файла, list по префиксу с пагинацией, read_many для батча до 50 путей. | Типичная последовательность вызовов: ```bash → list_services() → describe_service("wildberries") → connector_execute( service="wildberries", module="statistics", method="GET", path="/api/v1/supplier/orders", query={"dateFrom": "2026-04-15"} ) → repl_execute( code="from wb_analytics import abc_classify; ...", skills=["wb_analytics"] ) ``` ## Skill-ресурсы Каждый включённый навык организации экспонируется как MCP-ресурс по схеме `skill://{skill_id}`. Тело ресурса — system_prompt навыка плюс подсказка о том, как вызывать connector_execute с привязанным сервисом. На первом аутентифицированном запросе сервер однократно регистрирует ресурсы для всех включённых навыков, после чего resources/list их перечисляет. ## Ошибки Ошибки инструментов приходят как стандартный MCP ToolError, тело — JSON с полями code, message, retryable и опциональными hint и details. Базовый набор кодов: ```json { "code": "UNKNOWN_SERVICE", "message": "Connector 'foo' not registered", "retryable": false, "hint": "Known services: wildberries, ozon, telegram, ..." } ``` | Поле | Описание | | --- | --- | | `UNAUTHENTICATED` | Отсутствует или некорректный bearer-ключ. Проверьте префикс sk-org- и срок действия. | | `UNKNOWN_SERVICE` | Указан несуществующий коннектор. В hint возвращается список зарегистрированных сервисов. | | `INVALID_ARG` | Невалидный аргумент: неизвестный module/method, ошибка валидации Pydantic или нарушение контракта инструмента. В details приходят подробности. | | `NOT_FOUND` | Ресурс не найден (например, файл памяти по указанному path). | | `UPSTREAM_ERROR` | Внешний сервис вернул ошибку. Поле retryable показывает, имеет ли смысл повторить запрос. | **Полезные ссылки** - [Настройки → API-ключи и MCP-сервер](/settings/api-keys) - [Аутентификация — Bearer-токены и контекст организации](/docs/authentication) --- Source: https://samreshuuu.ru/help # Как работать с агентом Агент работает как исполнитель, а не как поисковая строка: он берёт данные из ваших подключённых сервисов и файлов, делает работу и отдаёт результат документом — таблицей, отчётом, письмом, сообщением. Эта справка — про то, как ставить ему задачи, чтобы получать нужное с первого раза. ## Первые 10 минут ### Подключите сервис, которым пользуетесь каждый день Раздел **«Интеграции»**: маркетплейс, CRM, почта, банк, телефония, 1С — то, откуда вы обычно выгружаете цифры руками. ### Попросите отчёт, который делаете сами Не «что ты умеешь», а «собери то, что я собираю каждый понедельник». Так вы сразу увидите результат на своих данных. ### Посмотрите, что пришло Агент вернёт не только ответ в чате, но и файл — Excel, Word, презентацию, — который можно сразу отправить дальше. ### Если это нужно регулярно — скажите об этом Одной фразой отчёт превращается в [задачу по расписанию](/help/tasks), которая будет приходить сама. **Про вопрос «что ты умеешь»** Это самый частый первый вопрос и самый бесполезный: в ответ придёт список возможностей, из которого ничего не следует. Одна ваша настоящая задача расскажет о продукте больше, чем любое описание. ## Что стоит знать сразу - **Новая тема — новый чат.** Агент перечитывает всю переписку на каждом шаге, поэтому смешивать в одном чате отчёт по продажам и договор с подрядчиком не стоит. Подробнее — [Чаты и контекст](/help/chats). - **Выгрузку — файлом.** Excel, Word, PDF, фото: файл попадает в рабочую среду, и агент считает по нему все строки. Короткий фрагмент можно вставить текстом. Подробнее — [Файлы и результаты](/help/files). - **Сервис называйте через `@`.** Подключение само по себе не подсказывает, из какого кабинета брать цифры. Подробнее — [Подключённые сервисы](/help/integrations). - **Изменения — небольшими группами.** Правки уходят прямо в ваш сервис, поэтому «все карточки» стоит заменить на условие и предел. Подробнее — [Изменения в сервисах](/help/changes). - **Постоянные правила — в память.** Скажите «запомни: …», и агент будет учитывать это в новых чатах. Подробнее — [Память агента](/help/memory). - **Повторяется — сделайте задачей.** Если вы второй раз копируете один и тот же запрос, его пора поставить на расписание. Подробнее — [Задачи по расписанию](/help/tasks). - **Сайт без интеграции — через браузер на вашем компьютере.** Личный кабинет поставщика, госуслуги, внутренняя админка: агент откроет их у вас на экране. Подробнее — [Браузер на вашем компьютере](/help/local-browser). ## Шпаргалка 1. Новая тема — новый чат. 2. В запросе: что взять, что сделать, в каком виде отдать, за какой период. 3. Выгрузку — файлом, короткий фрагмент — текстом. 4. Сервис — через `@`. 5. Постоянные правила — «запомни: …». 6. Регулярное — «создай задачу: … каждый понедельник в 10:00». 7. Правки — точечные, а не «переделай всё»; изменения в сервисах — сначала списком, потом небольшой группой. 8. Первая задача — своя рабочая, а не «что ты умеешь». Дальше: [как поставить задачу](/help/prompts), чтобы не пришлось её переформулировать. --- Source: https://samreshuuu.ru/help/prompts # Как поставить задачу Рабочая формула: **что взять → что сделать → в каком виде отдать**. Короткий запрос кажется быстрым, но обычно стоит дороже: за ним идёт несколько уточнений. Подробный закрывается за один-два хода. ## До и после | Вместо | Напишите | |---|---| | Проанализируй продажи | Посчитай выручку и маржу по товарам за июнь, сравни с маем и покажи 10 самых просевших позиций. Результат — Excel, одна строка на товар | | Оцени менеджера | Оцени звонки менеджера за прошлую неделю по пяти критериям, каждый по шкале 1–10, с примерами удачных и неудачных звонков. Результат — файл Word | | Сделай презентацию | Сделай 6 слайдов: одна проблема на слайд, фото, причина и что делать дальше. Без статистики и промежуточных файлов | | Посмотри почту | Собери письма за последние 3 дня, на которые никто не ответил, и напиши, кому и что нужно ответить сегодня | ## Что почти всегда стоит добавить - **Период** — «за июнь», «с 1 по 14 число», «за прошлую неделю». - **Разрез** — по товару, по сделке, по сотруднику, по складу. - **Формат результата** — Excel, Word, презентация, короткое сообщение, текст для копирования в мессенджер. - **Чего не надо** — «без промежуточных файлов», «без общих рекомендаций», «только цифры». ## Пример разобранного запроса Здесь названы сервис, период, группа и поля — уточнять нечего, поэтому отчёт приходит сразу. ## Правки: точечно, а не «переделай» Получили черновик — не переписывайте задачу заново. Скажите, что именно поменять: - «Оставь только просроченные поставки». - «Подпись в другом формате — как в прошлом письме». - «Добавь колонку с себестоимостью и пересчитай маржу». Агент помнит, что уже собрал, и переделает только нужное. «Сделай всё заново» — самый долгий путь: он заново поднимает все данные. **Если ответ ушёл совсем не туда** Быстрее начать [новый чат](/help/chats) с уточнённой постановкой, чем спорить в старом: там уже накопился контекст, который тянет агента к прежнему пониманию задачи. ## Тщательность Рядом с полем ввода есть переключатель **«Тщательность»**: - **Обычная** — быстрые ответы, переформатировать текст, написать письмо. - **Средняя** — большинство рабочих задач. - **Высокая** — аналитика, юридические разборы, сложные расчёты. Работает дольше, но копает глубже. Для длинной постановки удобен **голосовой ввод**: наговорить подробности быстрее, чем набрать. --- Source: https://samreshuuu.ru/help/chats # Чаты и контекст Чат — это рабочий стол, а не архив. Всё, что написано в чате, агент перечитывает на каждом шаге: чем длиннее переписка, тем больше внимания уходит на старое и тем выше шанс, что вчерашний отчёт смешается с сегодняшним. ## Одна задача — один чат - Новая тема — кнопка **«Новый чат»** в левой панели. - Признак, что пора: вы пишете «забудь предыдущее», «теперь про другое», «давай сначала». - Отчёт по продажам и договор с подрядчиком — два разных чата, даже если оба нужны сегодня. - Ничего не теряется: все чаты остаются в истории, к любому можно вернуться и продолжить. ## Если переписка всё-таки выросла Агент сожмёт её сам — в ходе работы вы увидите шаг **«Сжимаю контекст»**. Ваши сообщения и сделанные выводы сохранятся, а подробности старых выгрузок — нет. **Признаки перегруженного чата** Ответы стали медленнее, агент путает периоды и файлы, возвращается к задаче, которую вы уже закрыли выше. Начать новый чат и дать в первом сообщении короткую выжимку — быстрее, чем разбирать длинную переписку. ## Предупреждение о цене У некоторых моделей есть **ценовая ступень**: запрос длиннее, чем, например, 272 тысячи токенов, оплачивается вдвое дороже. Дороже становится не один вызов, а каждый следующий до конца хода: агент перечитывает всю переписку на каждом шаге, и весь её объём попадает в счёт снова и снова. Поэтому над полем ввода заранее поднимается полоса **«До автосжатия контекста осталось … %»**. Она появляется, когда до ступени остаётся около десятой части окна, то есть пока ещё есть время свернуть переписку дёшево. Если ступень уже перейдена, полоса скажет прямо: **«Порог автосжатия контекста пройден»**. Что делать: - нажать **«Свернуть контекст»** в той же полосе или отправить команду `/compact` — переписка сожмётся в сводку, как при автоматическом шаге «Сжимаю контекст», и ход продолжится по базовой ставке; - дождаться конца ответа, если агент прямо сейчас работает: во время хода кнопка неактивна, сворачивание доступно после него; - если тема всё равно исчерпана, [начать новый чат](#что-перенести-в-новый-чат) — это самый дешёвый вариант. Ничего не пропадает: ваши сообщения и выводы остаются в сводке, а вся история чата — в записи. ## Что перенести в новый чат Начиная новый чат, дайте агенту минимум, который нужен для задачи: - нужный файл — [приложите заново](/help/files), это надёжнее ссылки на «тот файл выше»; - итог предыдущего разговора одним абзацем, если он важен; - всё, что должно действовать постоянно, — [запишите в память](/help/memory), тогда повторять не придётся вовсе. ## Режим инкогнито **Режим инкогнито** — для разового чувствительного вопроса: чат не сохраняется в историю и ничего не записывается в память. Для повседневной работы он не подходит: агент не сможет опираться на этот разговор дальше. --- Source: https://samreshuuu.ru/help/files # Файлы и результаты ## Как передать данные Нажмите **«Загрузить файл»** или перетащите файл прямо в чат: таблицу, документ, PDF, фотографию, скриншот. Ссылка на облачную таблицу тоже работает, если открыт доступ по ссылке. **Выгрузку — файлом, короткий фрагмент — текстом** Вставленный текст не обрезается: он уходит целиком, длинная вставка сворачивается в чип над полем ввода. Разница в другом — файл попадает в рабочую среду, и агент считает по нему кодом, все строки, хоть сто тысяч. Вставленная таблица остаётся текстом в переписке, а при копировании из Excel теряются листы, формулы и форматы ячеек. Десяток строк, письмо, кусок договора — вставляйте спокойно; выгрузку на тысячи строк — файлом. Если файлов несколько — прикладывайте их вместе и скажите, что с чем сверять: «в первом файле автомобили в статусе, во втором — в работе, найди расхождения». ## Что приходит на выходе Агент отдаёт не только ответ в чате, но и готовый документ: - **таблица** — расчёты, сверки, выгрузки по позициям; - **документ** — отчёт, договор, письмо, инструкция; - **презентация** — когда результат нужно показывать; - **короткое сообщение** — текст, готовый к отправке клиенту или в мессенджер. Формат стоит назвать в запросе — тогда агент сразу соберёт нужное, а не будет переделывать. Об этом подробнее в [«Как поставить задачу»](/help/prompts). ## Правки готового файла Готовый файл можно править словами, не пересобирая задачу: «оставь только просроченные», «добавь колонку с себестоимостью», «убери промежуточные листы». Скачивать, редактировать и загружать обратно не нужно. --- Source: https://samreshuuu.ru/help/integrations # Подключённые сервисы Подключение живёт в разделе **«Интеграции»**: маркетплейсы, CRM, банки, почта, телефония, документооборот, мессенджеры, 1С и другие сервисы. После подключения агент может читать оттуда данные и выполнять действия от вашего имени. ## Называйте сервис через @ Подключённая интеграция не означает, что агент угадает, откуда брать цифры. Напишите **@** и выберите сервис прямо в запросе. Если кабинетов несколько — скажите, какой именно: «по магазину на Ozon, а не на Wildberries», «по юрлицу, которое работает с розницей». ## Что делать, если данных нет **«Не вижу» и «нет доступа» — это про права, а не про внимательность** Если агент отвечает, что доступа нет, значит прав действительно нет. Проверьте: подключение активно в разделе «Интеграции», срок действия не истёк, у выбранного сервиса есть нужная вам область данных. Дальше стоит проверить постановку: назван ли период, названа ли группа или магазин, не спрашиваете ли вы данные, которых в этом сервисе нет (например, себестоимость обычно живёт не в кабинете маркетплейса, а в учётной системе). ## Действия, а не только чтение Из подключённых сервисов агент может не только читать. Он умеет отвечать на отзывы и вопросы, создавать сделки и контакты, отправлять письма и сообщения, менять цены и остатки — если у подключения есть на это права. Изменения уходят прямо в ваш сервис, поэтому границы правки задаются в самом запросе: сколько записей, по какому условию и в каком кабинете. Как это формулировать — в разделе [«Изменения в сервисах»](/help/changes). --- Source: https://samreshuuu.ru/help/changes # Изменения в сервисах Агент не только читает данные из подключённых сервисов, но и меняет их: цены и остатки, карточки товаров, поля сделок и контактов, ответы на отзывы, письма и сообщения. Это самая полезная часть работы — и единственная, где ошибка стоит дороже потраченного времени. Разница с отчётом простая: неудачный отчёт вы просто переделываете, а неудачную правку придётся откатывать в самом сервисе. ## Правило трёх шагов Любое изменение, которое затрагивает больше одной записи, делайте в три хода. 1. **Список без изменений.** «Покажи товары, у которых остаток меньше 5, а цена не менялась с мая. Ничего не меняй.» Вы увидите, что именно попало под условие, до того как что-то произойдёт. 2. **Пилот на 2–3 записях.** «Примени новую цену к первым трём позициям из списка.» Откройте их в кабинете сервиса и убедитесь, что изменилось то и так, как вы ожидали. 3. **Остальное группами.** «Теперь примени к следующим двадцати.» Группами по 10–20 — не потому, что агент не справится с сотней, а потому, что ошибку на двадцати записях вы ещё поправите руками. **«Обнови все карточки» агент понимает буквально** Слова «все», «везде», «по всему каталогу», «всем клиентам» — это точная инструкция, а не оборот речи. Если под условие попало 900 карточек, изменены будут все 900. Вместо «все» называйте фильтр и предел: «только позиции категории «Обувь» с остатком больше 10, не больше 20 позиций за раз». ## Формулировки | Вместо | Напишите | |---|---| | Обнови карточки товаров | Покажи карточки без описания в категории «Обувь» — список, без изменений | | Подними цены на 10% | Подними цену на 10% у трёх позиций из списка выше, потом покажи, что получилось | | Ответь на отзывы | Подготовь ответы на новые отзывы с оценкой ниже 4, покажи текстом — отправлю сам | | Разошли клиентам письмо | Собери список клиентов без оплаты больше 30 дней и черновик письма; отправляй только после моего «ок» | ## Что стоит просить всегда - **Выгрузку до правки** — «сначала выгрузи текущие цены и остатки в Excel». Это ваша точка возврата. - **Отчёт после** — «покажи таблицу: артикул, было, стало». По ней видно и результат, и что вернуть, если что-то пошло не так. - **Точный кабинет** — назовите сервис [через `@`](/help/integrations) и уточните магазин или юрлицо, если их несколько. Правка, ушедшая не в тот кабинет, — самый частый способ испортить чужие данные. ## Действия, которые не отменяются Отправленное письмо, сообщение клиенту, опубликованный ответ на отзыв, проведённый платёж, удалённая запись — всё это назад не возвращается. Для таких задач формулируйте роль агента как подготовку: «собери», «составь черновик», «покажи список» — а отправку оставляйте за собой или разрешайте отдельной фразой в том же чате. **Задачи по расписанию, которые что-то меняют** [Задача](/help/tasks) выполняется без вас, и уточнить у вас на ходу будет некому. Если задача меняет данные, ограничьте её в самой формулировке — сколько записей и при каком условии, — и запустите первый раз руками, чтобы посмотреть на результат до того, как она начнёт ходить по расписанию. ## Если изменилось лишнее Скажите об этом в том же чате: «покажи, что именно ты изменил в последнем шаге» — агент соберёт список записей и прежних значений, пока они есть в контексте разговора. Дальше по этому списку и по выгрузке, сделанной до правки, значения возвращаются обратно — тем же способом, что и любая правка: группами, начиная с нескольких записей. Кнопки «отменить всё» в интерфейсе нет: изменения уходят напрямую в ваш сервис и живут по его правилам. --- Source: https://samreshuuu.ru/help/memory # Память агента Память — это то, что агент помнит о вас и вашем деле **между чатами**. Она живёт в разделе **«Память»**. Сказанное просто в переписке действует до конца этого чата. Сказанное через «запомни» — работает и завтра, и в новом разговоре. ## Как записать Скажите прямо в чате: > Запомни: комиссия площадки — 14% при цене до 100 ₽, 20% до 300 ₽, 42% выше. > Запомни: обменов по гарантии и возврата денег мы не делаем. > Запомни: перед добавлением контакта всегда проверяй дубли и предупреждай, если нашёл. Агент сохранит это отдельной заметкой и будет учитывать дальше. ## Что стоит туда положить - список юрлиц, магазинов, складов и кабинетов; - правила скидок, комиссий и наценки; - как у вас называются отчёты и что в них входит; - тон общения с клиентами и подпись в письмах; - чего делать нельзя. **Признак, что правило пора записать** Вы объясняете одно и то же во второй раз. Если правило пришлось повторить в новом чате — ему место в памяти, а не в переписке. ## Как проверить и поправить Всё сохранённое видно в разделе **«Память»**: там же можно исправить формулировку или удалить заметку. Если агент опирается на устаревшее правило — поправьте запись, а не спорьте в чате. Заметки, к которым долго не обращаются, со временем вычищаются. Важное лучше держать записанным явно, а не рассчитывать на «мы это обсуждали весной». ## Что в память не попадает В **режиме инкогнито** не сохраняется ничего: ни история чата, ни память. Это режим для разового чувствительного вопроса — для накопления рабочих правил он не подходит. --- Source: https://samreshuuu.ru/help/tasks # Задачи по расписанию Если вы второй раз копируете в чат один и тот же запрос — это уже не запрос, а задача. ## Как создать Напишите в чате обычной фразой: Агент уточнит детали, если их не хватает, и поставит задачу на расписание. Дальше она видна в разделе **«Задачи»**: там можно посмотреть историю запусков, поменять время, отредактировать формулировку, приостановить или удалить. ## Задача, ручной запуск или навык | Когда её делать | Чем оформлять | |---|---| | По календарю: каждый понедельник, каждое утро, 1-го числа | Задача по расписанию | | Повторяется, но момент выбираете вы: «когда закрыли месяц», «когда пришла выгрузка» | Задача с ручным запуском: «Запусти отчёт по остаткам» | | Одна и та же методика нужна нескольким задачам и чатам | Навык, а в задаче — строка «работай по навыку „Разбор звонков“» | Самый быстрый путь — не писать инструкцию с нуля, а сделать работу один раз вместе с агентом и сказать: «делай так каждый понедельник в 10:00». Первую задачу сначала запустите руками, посмотрите результат, поправьте формулировку — и только потом отдайте календарю. ## Из чего состоит текст задачи Агент, который выполняет задачу, видит только её текст. Порядок строк рабочий: откуда взять → что сделать → что отдать. 1. **Источник** — сервис и кабинет по имени: «Ozon, кабинет „Основной“», «МойСклад». 2. **Период и разрез** — «за прошедшую неделю», «по товарам», «по складам». Период относительный, а не датами. 3. **Что сделать — шагами и с порогами**: «выдели позиции, просевшие больше чем на 20%», «отметь остатки меньше чем на 14 дней продаж». 4. **Формат результата** — «сообщение до 10 строк», «таблица Excel, одна строка на товар», и чего не надо: «без общих рекомендаций». 5. **Что делать, если пусто или сервис не ответил** — «если изменений нет — не присылай ничего», «если кабинет не ответил — напиши об этом одной строкой и не выдумывай цифры». 6. **Куда прислать** — чат, почта, Telegram, MAX или Пачка. | До | После | |---|---| | Каждый понедельник присылай отчёт по продажам | Каждый понедельник в 10:00 бери Ozon, кабинет „Основной“, за прошедшую неделю: выручку и маржу по товарам, сравнение с предыдущей неделей и топ-10 просевших позиций. Отдай таблицей, одна строка на товар, плюс пять строк выводов. Если кабинет не ответил — напиши об этом и не выдумывай цифры. Присылай в Telegram | ## Пять правил - **Один кабинет — одна задача.** Два кабинета Ozon и один Wildberries — три задачи. У каждой своя история запусков, и упавшая не утаскивает остальные. Кабинет называется в тексте словами. - **Имя задачи — то, чем вы её зовёте вслух.** «Понедельничные продажи», «Просроченные счета». Этим именем вы её и запустите руками. - **Пороги вместо «если что-то не так».** «Меньше 14 дней остатка», «падение больше 20%». Без порога агент присылает всё и возвращает решение вам. - **Сторожу — право молчать.** Задача, которая следит за ценами или остатками, пишет только когда что-то изменилось. Ежедневное «всё в порядке» перестаёт читаться на второй неделе. - **Доступы — до постановки.** Коннектор подключён, права у ключа выданы, кабинет выбран. Задаче без доступа остаётся только вернуть вопрос вам. ## Что чаще всего ставят на расписание - утренняя сводка по деньгам и заявкам; - итоги недели: что сделано, ключевые цифры, план на следующую; - просроченные счета и ожидаемые оплаты; - новые отзывы и изменение рейтинга; - письма и обращения, оставшиеся без ответа; - остатки, поставки и сверка складов; - дайджест новостей отрасли и конкурентов. ## Куда приходит результат Туда, где вам удобно: в чат, на почту или в мессенджер — **Telegram** или **MAX**. Мессенджер должен быть подключён; канал выбирается при создании задачи и меняется потом. **Формулируйте задачу так же, как обычный запрос** Период, разрез и формат нужны задаче даже больше, чем разовому запросу: она будет выполняться без вас, и уточнить на ходу будет некому. «Присылай отчёт по продажам» — слабо; «присылай выручку и маржу по товарам за неделю, файлом, с топ-10 просевших позиций» — то, что нужно. ## Если задача прислала не то Откройте её в разделе «Задачи» и поправьте формулировку — менять постановку можно в любой момент, накопленная история запусков при этом сохраняется. Разовый прогон тоже можно запустить руками, не дожидаясь расписания. Не переписывайте задачу заново — добавьте одну недостающую строку: порог, разрез, формат, запрет выдумывать. Так видно, с какого прогона стало лучше. **Если задача второй месяц требует вашего участия** Чинится не расписание, а одна из строк постановки: не назван кабинет при двух подключениях, не выдан доступ, нет правила на пустоту, нет порога, нет формата. --- Source: https://samreshuuu.ru/help/local-browser # Работа на вашем компьютере Браузер у агента есть всегда. В веб-версии он открывает страницы в облаке — этого хватает, чтобы найти информацию, прочитать сайт или собрать данные с открытых страниц, и приложение для этого не нужно. Приложение добавляет второй браузер — на вашем компьютере. Он открывается прямо у вас на экране, работает с вашего IP и в нём остаётся ваш вход на сайты. Это нужно там, куда облако не попадает: личный кабинет поставщика, госуслуги для бизнеса, внутренняя админка, сайт без API, страница за корпоративной сетью. ## Как запустить ### Скачайте приложение Откройте [samreshuuu.ru/download](/download) и установите версию для своей системы — macOS или Windows. Если при первом запуске система предупреждает, что разработчик не подтверждён, на той же странице есть шаги, как открыть приложение в пару кликов. ### Проверьте, что чат работает на этом компьютере Рядом с полем ввода есть выбор среды: **«В облаке»** или имя вашего компьютера. Выберите компьютер. Если он помечен «Офлайн — сейчас недоступно», значит приложение закрыто — откройте его. ### Скажите, что нужно сделать в браузере Обычной фразой: «открой сайт поставщика и выгрузи остатки», «зайди в кабинет и заполни заявку», «посмотри в браузере на моём компьютере, что с заказом». Отдельной кнопки «включить браузер» нет — агент запускает его сам, когда задача этого требует. ### Разрешите запуск При первом запуске появится окно **«Браузер агента»** — нажмите «Разрешить». Спрашивается один раз на всё приложение. Дальше на экране открывается окно браузера, а в чате появляется живая трансляция **«Локальный браузер · live»** — видно каждый клик, даже если окно свёрнуто. ## Что агент делает в браузере - открывает страницы и переходит по ссылкам; - кликает, заполняет и отправляет формы; - забирает со страниц цифры, таблицы и статусы; - загружает файлы на сайт и скачивает выгрузки; - делает скриншоты того, что видит. Результат приходит как обычно — ответом в чате и файлом, если вы попросили таблицу или отчёт. ## Если нужен вход на сайт Пароли агент не подбирает и не вводит. Как только он попадает на страницу входа, в чате появляется **«Нужен вход»**, а трансляция переключается в режим **«Вы за рулём»**: агент встаёт на паузу, вы входите руками в том же окне. Как только страница входа закрыта, агент продолжает с того места, где остановился. Вход сохраняется в профиле агента — в следующий раз на этот сайт заходить заново не придётся. **Ваш обычный браузер не трогается** Агент работает в отдельном профиле: ваши вкладки, закладки, сессии и сохранённые пароли остаются нетронутыми, и системная связка ключей ему недоступна. Всё, что он делает, видно на экране, и вмешаться можно в любой момент. ## Что важно знать - **Браузер на компьютере — только из приложения.** В веб-версии агент не остаётся без браузера, но открывает страницы в облаке: своего входа на сайты там нет, и часть кабинетов туда не пускает. Если нужен именно ваш компьютер — откройте приложение. - **Только браузеры на Chromium.** Google Chrome, Microsoft Edge, Brave, Vivaldi, Opera, Яндекс Браузер и Chromium. Если установлено несколько, берётся Chrome. Safari и Firefox пока не поддерживаются — поставьте любой из списка. - **Компьютер должен быть включён, приложение — открыто.** Оно живёт в Dock или в трее и продолжает задачи в фоне; можно включить **«Запускать при входе в систему»** в настройках. Если приложение закрыто, чат сам предложит переключиться на облако. - **Задачи по расписанию идут в облаке.** Компьютер может быть выключен в нужный момент, поэтому [регулярные задачи](/help/tasks) на локальный браузер не опираются. - **Маркетплейсы — через интеграции.** Кабинеты Ozon и Wildberries закрыты от автоматизации в браузере, за их данными агент идёт [подключённым сервисом](/help/integrations). - **Закрыли окно браузера — не страшно.** Агент попросит запустить его заново при следующем шаге. Выход из самого приложения закрывает и окно агента. - **Содержимое сайтов агент не слушается.** Текст на странице для него — данные, а не команда: инструкции, встреченные на чужом сайте, он не выполняет и никаких секретов там не вводит. ## Если что-то не сработало - **«Браузер — только в десктоп-приложении»** — агент попытался открыть браузер на компьютере, а вы в этот момент в веб-версии. Откройте установленное приложение и повторите; если задача не требует вашего входа, попросите сделать её в облаке. - **Среда переключилась на облако** — приложение было закрыто или потеряло связь. Откройте его; в чате есть кнопка «Переподключить». - **«Браузер не успел выйти на связь»** — первый запуск бывает долгим. Повторите запрос; если повторяется, проверьте, что приложение обновлено. - **«Браузер по умолчанию нельзя автоматизировать»** — браузером по умолчанию стоит Safari или Firefox. Установите Chrome или другой Chromium-браузер. --- Source: https://samreshuuu.ru/help/trust # Режим доверия Режим доверия задаёт, какие действия агент выполняет сам, а перед какими просит подтверждение. Его можно сменить внизу поля ввода или в настройках. ## Чтение Агент читает и анализирует данные. Перед любой командой или правкой спросит подтверждение. ## Авто Агент сам выполняет локальные команды и правки. Для действий в подключённых сервисах и других рискованных действий всё равно попросит подтверждение. **Важные действия всегда под контролем** Денежные и необратимые действия требуют подтверждения независимо от выбранного режима. ## Если режим выбирает организация В рабочей организации администратор задаёт потолок автономности — самый свободный режим, который разрешён сотрудникам. - Режим строже потолка вы выбираете сами: ограничить агента сильнее можно всегда. - Режим выше потолка недоступен: в списке он подписан **«Задано администратором»** и не выбирается. - Если ваш сохранённый режим оказался выше нового потолка, он понижается до разрешённого, а вы увидите уведомление **«Преобразовано политикой организации»**. Прежний выбор при этом не теряется: когда администратор поднимет потолок, вернётся ваш режим. Отдельно администратор может запретить агенту изменяющие и необратимые действия в конкретных сервисах. Такой запрет сильнее режима доверия: в режиме «Авто» агент всё равно не выполнит запрещённое действие и скажет об этом в чате. --- Source: https://samreshuuu.ru/help/faq # Частые вопросы ## Почему агент не помнит, что я говорил на прошлой неделе? В переписке он помнит только текущий чат. Всё, что должно жить дольше, оформляйте фразой «запомни: …» — это попадёт в раздел [«Память»](/help/memory) и будет доступно в любом новом чате. ## Почему агент не видит данные подключённого сервиса? Проверьте две вещи: подключение активно в разделе «Интеграции» и в самом запросе сервис назван [через `@`](/help/integrations). Если у сервиса несколько кабинетов, групп или юрлиц — укажите, какое нужно. ## Почему ответ получился не таким, как я ждал? Чаще всего в запросе не был назван результат. Добавьте формат и разрез: «Excel, одна строка на товар», «Word с примерами», «короткое сообщение для отправки клиенту». Подробнее — [Как поставить задачу](/help/prompts). ## Почему агент изменил больше записей, чем я имел в виду? «Все», «везде», «по всему каталогу» — для агента это точное условие, а не оборот речи. Такие задачи стоит вести в три шага: список без изменений → правка на двух-трёх записях → остальное группами. Подробнее — [Изменения в сервисах](/help/changes). ## Почему чат стал медленным и путается? Он перегружен. Начните [новый чат](/help/chats) и в первом сообщении дайте короткую выжимку — это быстрее, чем разбирать длинную переписку. ## Нужно ли повторять правила в каждом чате? Нет, если вы записали их в [память](/help/memory). Комиссии, список складов, тон писем, запреты — всё это записывается один раз. ## Куда приходит результат задачи по расписанию? В чат, на почту, в Telegram или MAX — канал выбирается при создании [задачи](/help/tasks) и меняется позже. ## Можно ли работать так, чтобы ничего не сохранялось? Да — **режим инкогнито**: чат не попадает в историю и ничего не записывается в память. ## Что происходит с моими файлами и перепиской? Содержимое документов и сообщений хранится в зашифрованном виде и используется в рамках вашей учётной записи — чтобы агент держал контекст работы. Подробности — в [политике конфиденциальности](/privacy). ## Остались вопросы Спросите прямо в чате — агент отвечает и про свою работу тоже. Если нужен человек, напишите в поддержку: [контакты](/contacts). --- Source: https://samreshuuu.ru/changelog # Что нового в сервисе > Каждое обновление — отдельной записью, в день выхода. Версия рядом с датой — постоянный адрес релиза: на неё можно сослаться, чтобы показать конкретное изменение. ## v1.8.444 — 2026-08-31 ### Экран агента и передача управления **Появилось** · Машина агента · браузер, компьютер У агента свой компьютер — и теперь виден его экран: окно, курсор, полноэкранный режим. Когда сайт просит пароль или код из СМС, нажмите «взять управление», введите сами и верните окно — агент продолжит с того же места. После обрыва связи экран восстанавливается сам. ### Правила автономии — обычными словами **Изменилось** · Доверие и контроль · браузер, iPhone и iPad, Android, компьютер Вместо пяти экранов настроек — одна строка текстом: «счета до 10 000 ₽ отправляй сам, крупнее — покажи мне». Агент сверяет каждое действие с вашими правилами и с тем, о чём вы попросили в этом разговоре, а спрашивает только там, где правило велит спросить. ### Агенты делятся памятью **Изменилось** · Агенты · браузер, iPhone и iPad, Android, компьютер Рассказали ассистенту, что у вас отсрочка платежа 14 дней? Агент, которого вы включите завтра, уже будет это знать. То, что агент узнал сам про свою работу, остаётся его собственной памятью и при расхождении побеждает. ## v1.8.443 — 2026-08-30 ### Вход по корпоративному логину **Появилось** · Для компаний · браузер, компьютер Сотрудники входят тем же логином, что и в другие рабочие системы, — через SSO компании. Есть готовые настройки для Keycloak, Blitz и Яндекс 360: подтверждаете свой домен почты, и дальше все входы видны в журнале. ### Своя модель в своём контуре **Появилось** · Для компаний · браузер, компьютер У компании есть собственная языковая модель — подключите её в настройках организации. Агенты будут обращаться только к ней: переписка, документы и данные не уходят к внешним поставщикам моделей и остаются внутри вашего контура. ### Комнаты: агенты и люди в одном разговоре **Появилось** · Чаты · браузер, iPhone и iPad, Android, компьютер Разговор перестал быть тет-а-тет. Создайте комнату, добавьте несколько агентов — например, одного по 1С и одного по маркетплейсам — и позовите коллег: сотрудники организации читают и пишут наравне с вами, гостя можно пустить по отзываемой ссылке или по домену почты. Внутри — ответы на сообщения, реакции и поиск: найдётся и реплика месячной давности, и файл по куску имени. Служебные записи больше не поднимают комнату в списке и не зажигают счётчик непрочитанного без настоящей новой реплики. ## v1.8.441 — 2026-08-26 ### Обучение показом: пройдите процесс один раз **Появилось** · Агенты · браузер, компьютер Нажмите «научить» и проделайте привычный процесс при агенте — например, как вы собираете еженедельный отчёт по продажам. Агент запишет шаги как рутину и дальше будет выполнять их сам: по расписанию или по событию. ## v1.8.440 — 2026-08-25 ### Одна 1С вместо семи **Изменилось** · Интеграции · браузер, iPhone и iPad, Android, компьютер Бухгалтерия, ERP, Управление торговлей, ЗУП, Документооборот, УНФ и самописные конфигурации подключаются одним коннектором «1С». Уже подключённые кабинеты продолжают работать — прежние имена остались как псевдонимы. ## v1.8.432 — 2026-08-20 ### Приложение для Android в Google Play **Появилось** · Мобильное приложение · браузер, Android Приложение для Android опубликовано и в Google Play — та же сборка, что в RuStore: те же чаты, задачи и подключённые системы, те же push-уведомления; ставьте из того стора, в который телефон уже вошёл. Обе ссылки стоят в настройках, в разделе «Приложения», у каждой — QR-код для чтения с компьютера, и на странице загрузок. Версия для iOS по-прежнему готовится к публикации. [Подробнее](/download) ## v1.8.421 — 2026-08-15 ### Приложение для Android в RuStore **Появилось** · Мобильное приложение · браузер, Android Приложение для Android опубликовано в RuStore: те же чаты, задачи и подключённые системы, что в браузере, плюс push-уведомления — о готовом отчёте, о завершённой длительной операции и о встречном вопросе агента. Ссылка на установку стоит в настройках, в разделе «Приложения», и на странице загрузок. Версия для iOS готовится к публикации. [Подробнее](/download) ## v1.8.406 — 2026-08-09 ### Шкала «быстрее — умнее» в поле ввода **Изменилось** · Модели · браузер, iPhone и iPad, Android, компьютер Выбор модели и глубины рассуждения стал одной шкалой: перетащите ползунок от «быстрее» к «умнее», и подпись под ним скажет, какой тариф и какая глубина получатся. Прежние два списка остались под кнопкой «Дополнительно». Оплата и подключение сервиса теперь открываются поверх текущего экрана — чат и открытая задача остаются на месте. ## v1.8.405 — 2026-08-09 ### Лента изменений **Появилось** · Что нового · браузер Теперь видно, что меняется в сервисе: каждое обновление попадает на страницу «Что нового» в день выхода — с датой, номером релиза и пометкой, где именно изменение заметно: в браузере, на телефоне или на компьютере. --- Source: https://samreshuuu.ru/skills/ceo_review_ru Режим — ответ на вопрос, что сейчас дороже: упущенная возможность или размазанный ресурс. **РАСШИРЕНИЕ** — ищешь версию в 10 раз амбициознее. Уместно, когда спрос подтверждён деньгами, а план описывает малую часть того, за что клиент готов платить; признак — третий клиент подряд спрашивает «а можно ещё вот это?». При нуле платящих не включай: расширение нулевого спроса даёт нулевой спрос. **ВЫБОРОЧНОЕ РАСШИРЕНИЕ** — масштаб держишь, 1–2 области раскачиваешь. Расширяй то, что клиент делает руками и за что платит человеку, а не то, что «хотел бы попробовать». **УДЕРЖАНИЕ ФОКУСА** — границы верные, задача найти дыры. Уместно, когда план в работе, дедлайн ближе месяца. Новых направлений не предлагаешь вообще. **СОКРАЩЕНИЕ** — режешь до минимума, который всё ещё проверяет гипотезу. Уместно, когда горизонт денег короче срока плана, гипотеза не проверена или трудозатраты выросли вдвое с первой оценки. Критерий среза: пункт остаётся, только если без него нельзя узнать, работает ли гипотеза. Сомневаешься — посчитай, сколько недель отделяет план от первого платящего. Больше восьми — СОКРАЩЕНИЕ, что бы ни просил пользователь. ## 2. Шесть форсирующих вопросов ### 2.1 Кто клиент? **Настоящий:** «Ирина, руководитель продаж в оптовой компании по электрике, 12 человек, учёт в 1С:УТ, продажи через Ozon и своих менеджеров; с двумя такими же я говорил». **Правдоподобный:** «селлеры маркетплейсов», «малый бизнес» — категория, а не клиент; она не отвечает на вопрос, кому мы это покажем в четверг. **Стоп:** названо больше двух непохожих сегментов сразу (селлеры + производства + агентства) — клиента не искали, а перечисляли. ### 2.2 Какую проблему решаем? **Настоящий** содержит текущий способ и его цену: «помощник тратит 6 часов в неделю на сведение остатков из 1С и трёх кабинетов; раз в месяц ошибка даёт оверселлинг и штраф площадки». **Правдоподобный:** «нет прозрачности», «неэффективные процессы» — описание чувства. Подставь «…поэтому они платят за ___ / тратят ___ часов»; нечего подставить — проблемы нет. **Стоп:** проблему решают бесплатно и она никого не бесит. Костыль в таблице, который всех устраивает, — выигрывающий конкурент. ### 2.3 Почему сейчас? **Настоящий** называет изменение с датой: площадка сменила правила выгрузки, поменялось требование к отчётности, ушёл западный вендор, технология подешевела в разы. **Правдоподобный:** «рынок растёт», «все переходят на ИИ» — фон, не событие. **Стоп:** единственный ответ — «у нас появилось время». Доступность внутреннего ресурса не создаёт внешнего спроса. ### 2.4 Почему мы? **Настоящий** — преимущество, которое конкурент не купит за квартал: накопленные данные, действующая интеграция, доступ к сегменту, дистрибуция. **Правдоподобный:** «сделаем лучше», «сильная команда». **Стоп:** единственное преимущество — цена ниже. Демпинг воспроизводится за неделю и первым убивает экономику. ### 2.5 Что может пойти не так? Ровно три причины провала, каждая с вероятностью и ранним признаком. «Клиент не будет платить» бесполезно, «на второй встрече просят бесплатный доступ до конца квартала» — признак. **Стоп:** все три риска технические — рыночные не думали вовсе, и план защищает от того, чем команда умеет управлять, а не от того, что убьёт проект. ### 2.6 Как узнаем, что работает? Метрики на 30/60/90 дней, каждая с числом и порогом отказа: «к 60-му дню 5 платящих компаний с чеком ≥ 15 000 ₽/мес; платящих ≤ 2 — сворачиваем». **Правдоподобный:** регистрации, установки, «интерес рынка» — необмениваемая валюта. **Стоп:** ни у одной метрики нет порога отказа. План без порога отказа не проверяет гипотезу, он её обслуживает. ## 3. Оценка рынка снизу вверх ### 3.1 Четыре числа 1. **N — сколько компаний существует.** Реестр МСП ФНС даёт срез по ОКВЭД, региону и категории (микро/малые/средние). Для маркетплейс-ниш — счётчики продавцов площадок и сервисы аналитики (MPStats, Moneyplace); для отраслевых — ассоциации, тендерные площадки, каталоги 1С-франчайзи. 2. **N₁ — сколько подходит по признаку боли.** Резкий срез: не «все селлеры», а «селлеры с ≥ 300 SKU и собственным складом» — единицы процентов. 3. **N₂ — сколько достижимо каналом, который уже есть,** за один квартал. 4. **P — сколько платят сейчас**: подписки, подрядчик, зарплата того, кто делает это руками. Верхняя граница выручки первого года = N₂ × конверсия × средний чек × месяцы. Остальное — фантазия. ### 3.2 Разобранный пример Ниша: сведение остатков и цен между 1С и тремя маркетплейсами. N — сотни тысяч продавцов, но это не рынок. N₁ — со складом, ≥ 300 SKU и учётом в 1С/МойСклад, допустим 8 000. N₂ — канал один, сеть 1С-франчайзи в трёх регионах, охват за квартал 600 компаний. P — платят помощнику (60 000 ₽/мес за часть ставки) либо коробочному сервису. Конверсия охвата в платящих для B2B-инструмента по тёплому партнёрскому каналу реалистично 2–5%. 600 × 3% = 18 клиентов; при чеке 12 000 ₽/мес это 216 000 ₽/мес к концу квартала, ~2,6 млн ₽ в год. Оправдывает ли это план на N человеко-месяцев — весь вопрос. **Правило:** меньше 15–20 платящих в реалистичном сценарии — продукт непроверяем: любой результат объясняется случайностью, а не спросом. ### 3.3 Где эта оценка врёт - **Считают N вместо N₂.** «В России миллионы субъектов МСП» — доедет ноль, если нет канала. - **Конверсию берут из B2C.** 20–30% — про подписку на приложение, не про смену учётного контура. - **Игнорируют, что решение уже куплено.** Если стоит модуль 1С от франчайзи, вы конкурируете не с болью, а с потраченными деньгами и обученным бухгалтером. - **Чек берут по максимальному клиенту.** Бери медиану первых пяти сделок; сделок нет — половину от того, что кажется справедливым. ## 4. Сценарный расчёт экономики решения Одна цифра — мнение, три сценария — решение. План защищается по пессимистичному. ### 4.1 Что считать Чек в месяц без НДС; стоимость привлечения (расходы канала / число сделок плюс вознаграждение партнёра); себестоимость обслуживания в месяц, где расход на модель для ИИ-продукта идёт отдельной строкой — он растёт линейно с использованием и съедает маржу; отток в месяц; срок жизни ≈ 1 / отток. | Показатель | Стоп | Пограничная зона | Здоровая зона | |---|---|---|---| | LTV / CAC | < 1,5 | 1,5–3 | > 3 | | Окупаемость привлечения | > 18 мес | 9–18 мес | < 9 мес | | Валовая маржа | < 50% | 50–70% | > 70% | | Отток в месяц | > 10% | 5–10% | < 5% | Для МСБ окупаемость важнее LTV: у компании с оборотным дефицитом деньги, вернувшиеся через 14 месяцев, — деньги, которых нет. ### 4.2 Три сценария и стоимость бездействия **Пессимистичный:** конверсия вдвое ниже, чек на 30% ниже, отток вдвое выше, привлечение на 50% дороже; вопрос — переживёт ли компания этот вариант. **Базовый:** цифры, которые вы готовы защищать перед дающим деньги. **Оптимистичный** нужен для потолка: если и он не окупает трудозатраты, решение принято. ## 5. Типовые стратегические ошибки **Решение ищет проблему.** План начинается с «мы можем», а не с «клиент не может». Разбор почты для оптовика с 12 письмами в день экономит 20 минут, за которые не платят 20 000 ₽/мес. **Продукт для среднего клиента, которого не существует.** Функции собраны из запросов пяти компаний и ни одной не подходят целиком. **Оценка по одному восторженному собеседнику.** «Отличная идея, берём» — не валюта. Валюта: предоплата, подписанный пилот, доступ к данным, выделенный сотрудник со стороны клиента. **Рост, купленный отрицательной маржой.** Клиенты идут, потому что цена ниже себестоимости обслуживания. Признак: маржу считают «без учёта API» или «без учёта поддержки». **Копирование западного аналога без переноса контекста.** Ломается в трёх местах: учёт (1С как центр правды, а не CRM), оплата (счёт с НДС и закрывающие вместо карты), решение о покупке (собственник, а не отдел). **План без платящего в горизонте.** Три месяца строим платформу, потом продаём; к моменту продажи гипотеза устарела. **Подмена приоритета срочностью.** Первым стоит то, что громче попросили. Проверка каждого пункта: какую из метрик 30/60/90 он двигает и на сколько. Ни одну — вниз списка. ## 6. Сезонность План, свёрстанный по среднему месяцу, ошибается дважды — в деньгах и в сроках. - **Календарь спроса.** У розницы и маркетплейсов пики — ноябрь (распродажи) и декабрь, провалы — январь и первая половина мая. В B2B решения о покупке почти не принимаются с конца декабря до середины января и проседают в июле–августе. У учётных продуктов пики — отчётные периоды. - **Что это меняет.** Запуск в конце декабря или начале мая даёт заниженный результат, который легко принять за отсутствие спроса. Спрашивай, в каком месяце будете мерить и что этот месяц значит для клиента. Сравнивай год к году, а долю выручки закладывай по месяцам, а не 1/12. - **Кассовый разрыв.** У сезонного клиента деньги есть не тогда, когда есть боль. Подписка, попавшая на январь, отваливается не из-за качества — это аргумент за годовой контракт со скидкой, а не за снижение цены. Если в плане нет ни слова о сезоне запуска, это не план, а намерение. ## 7. Зависимость от одного канала или площадки ### 7.1 Индекс концентрации Посчитай долю крупнейшего канала в трафике и выручке и долю крупнейшего клиента. Больше 70% на канале — критическая зависимость, план обязан содержать ответ «что если». Больше 30% выручки на одном клиенте — это не продукт, а подряд; так его и оценивай. ### 7.2 Что меняют площадки 1. Какая часть ценности исчезнет, если завтра закроют или урежут нужный метод API? 2. Останутся ли у вас собственные данные клиента — или всё живёт в чужом кабинете? 3. Есть ли прямой контакт с клиентом (договор, счёт, канал связи) — или клиент принадлежит площадке? 4. Не конкурируете ли вы с сервисом самой площадки? Если она выпустит аналог бесплатно, что противопоставите? ### 7.3 Что даёт устойчивость Собственные накопленные данные, прямой договор с клиентом, интеграция с его учётной системой (1С, МойСклад, Битрикс24) и второй канал продаж хотя бы на 20% объёма. План без единого пункта — временный по построению, и это надо сказать прямо. ## 8. Санкционные и регуляторные риски Этот класс не лечится качеством исполнения: план может быть безупречным и всё равно перестать работать. - **Зависимость от зарубежных сервисов** — оплата, хостинг, платные API, магазины приложений, шлюзы. Что будет с продуктом, если сервис перестанет обслуживать российских клиентов через месяц? Ответ «продукт остановится» — не риск, а условие существования, и ему место на первой странице плана. - **Персональные данные.** Обработка ПДн российских граждан регулируется законодательством о персональных данных: локализация баз, уведомление уполномоченного органа. Номера статей и сроки не выдумывай — помечай обязательной проверкой с юристом. - **Государственные клиенты.** Для них может быть обязателен реестр отечественного ПО: это не бонус, а вход на рынок, то есть срок и деньги. - **Расчёты и документы.** Продукт для юрлиц обязан отдавать счёт, закрывающие документы и корректно работать с НДС. Их отсутствие блокирует оплату по безналу — это не мелочь бухгалтерии, а нет выручки. ## 9. Критерии отказа от проекта Формулируй до старта, с числами: критерий, придуманный после провала, всегда мягче нужного. Отказывайся, если верно хотя бы одно: 1. **Нет платящего в горизонте 90 дней** и нет ни одного подписанного пилота. 2. **Пессимистичный сценарий убыточен**, и компания его не переживёт. 3. **LTV/CAC < 1,5** после трёх честных попыток сменить канал или цену. 4. **N₂ меньше 15–20 компаний** — выборка не различает спрос и случайность. 5. **Ценность держится на одном внешнем правиле** (метод API площадки, курс, зарубежный сервис), плана Б нет. 6. **Клиент не отдаёт данные и не выделяет человека** для пилота — бесплатный интерес есть у всего. 7. **Регуляторный запрет** или стоимость соблюдения выше ожидаемой выручки первого года. 8. **Срок сдвинут трижды** без изменения объёма — оценка сломана, сдвиги продолжатся. Потраченные месяцы не аргумент продолжать: аргумент — только отдача от следующего вложения. ## 10. План Б План Б — не «постараемся лучше», а заранее описанный другой способ получить ту же ценность: 1. **Триггер** — событие или число: «к 60-му дню платящих ≤ 2», «площадка закрыла нужный метод», «привлечение дороже 40 000 ₽ два месяца подряд». 2. **Содержание** — другой сегмент, другой канал, услуга вместо продукта, модуль внутрь чужой платформы, продажа наработок проектом одному клиенту. 3. **Что переиспользуется.** Если ничего, это не план Б, а второй план А ценой в полный цикл заново. Рабочие формы для МСБ: из продукта в услугу (делаем то же руками, пока не подтвердится спрос на автоматизацию); с прямых продаж на партнёрский канал (1С-франчайзи, отраслевые интеграторы, бухгалтерский аутсорсинг); сузить до одной отрасли; встроиться модулем в продукт с готовой дистрибуцией. ## 11. Шаблон стратегического вердикта Пустых полей быть не должно: «не знаю» — валидное значение, пропуск — нет. --- Source: https://samreshuuu.ru/skills/me_mvp_ru ## 1. Три стадии и правила перехода между ними ### Стадия 2 — процесс Записываешь сделанное руками в виде листа: вход, действия по порядку, что считается готовым результатом, что делать в трёх нестандартных случаях. «Волшебный листок бумаги» — документ, по которому работу выполнит человек, не изобретавший её. Стадия пройдена, когда **по твоему листу работу выполнил кто-то другой** и результат не пришлось переделывать. Если пришлось — не готов лист, а не человек плохой. ### Стадия 3 — продукт Автоматизируешь **отдельные шаги** листа — самые частые и меньше требующие суждения. Порядок: приём заявки, выдача результата, в последнюю очередь сама работа. Большинство делает наоборот: пишет «движок», а заявки собирает в личных сообщениях. ### Как понять, на какой стадии человек на самом деле | Платящих клиентов | Записанный процесс | Реальная стадия | Что делать | |---|---|---|---| | 0 | нет | до первой стадии | продавать вручную, ничего не строить | | 0 | есть | процесс без проверки | выбросить лист, найти клиента | | 1–4 | нет | первая | не автоматизировать, набрать 5–10 | | 5–10 | нет | конец первой | сесть и записать лист | | 5–10 | есть | вторая | отдать лист другому человеку | | 10+ | есть, отдан другому | третья | автоматизировать частями | Частая ошибка — человек с нулём клиентов и техзаданием на 40 страниц: он **до** первой стадии, а не в третьей. ## 2. Четыре вопроса, приведённые в рабочий вид **1. Запустится ли это за 16 часов работы?** Две смены по 8 часов, из которых три уйдут на домен и оплату. Ответ «за месяц» — вычёркивай функции, пока не станет 16 часов. Если не остаётся ничего продаваемого, гипотезе нужна другая форма поставки, а не больший срок. **2. Что изменится у клиента в первые 30 минут?** Формулировка с глаголом и числом: «получит остатки по 4 складам за 5 минут вместо часа в 1С». «Повысит эффективность» означает, что польза не найдена. **3. Кто конкретно заплатит и сколько?** Имя, контакт, сумма — не «малый бизнес готов платить». Бесплатная версия проверяет только вежливость знакомых. ## 3. Как выглядит «сделать вручную» для разных типов бизнеса ### Услуга для бизнеса (бухгалтерия, маркетинг, аналитика, консалтинг) Пост в профильном чате → клиент пишет в Telegram → работа в Excel → файл → счёт, никакого сайта. Пример: аналитика для селлеров — берёшь выгрузку из кабинета Ozon, за 40 минут строишь таблицу с оборачиваемостью и упущенными продажами, отдаёшь PDF, берёшь 4 000 ₽. Десять клиентов — 40 000 ₽ и 7 часов; программировать тут нечего. Что видно только руками: у половины выгрузка в другом формате, трое из десяти не понимают слово «оборачиваемость», а настоящий вопрос — «что закупать в следующем месяце». ### Физический товар / производство Ограничение, меняющее схему: **при НПД перепродажа чужих товаров запрещена** — только товар собственного производства (422-ФЗ, статья 4; актуально на 2026-07-28). При закупке и перепродаже нужен ИП; нарушение вскрывается ретроспективно и ведёт к пересчёту налога. ### Обучение, курс, методика Не записывай курс. Проведи его живьём для 5 человек в видеозвонке за деньги, материалы — документ. Получишь вопросы, которых не было в программе, и увидишь, какие два модуля из восьми не нужны. ## 4. Из чего собрать первую версию без разработки Важно не «что умеет», а **что ломается при росте**: первая версия обязана сломаться, вопрос лишь — предсказуемо ли. ### Таблица как продукт Google Sheets или Яндекс Документы — рабочее место оператора, реестр заказов, калькулятор. Ломается на: одновременном редактировании, десятках тысяч строк с формулами, отсутствии истории «кто менял». Порог смены — работают больше 2 человек сразу либо ошибка в ручной строке дважды стоила денег. ### Telegram-бот как основной канал Для российского малого бизнеса это обычно **более быстрый путь, чем сайт**: аудитория уже внутри, авторизация не нужна, платёж проходит в переписке. Годится для заявок, записи, ответов на типовые вопросы, выдачи файлов; собирается на конструкторе. Ломается на: длинных диалогах (человек бросает на четвёртом вопросе — держи 3–4 шага), больших прайсах, поиске по истории, блокировке аккаунта конструктора. Отдельный риск — лимит бесплатного тарифа по числу пользователей или сообщений: узнай его **до** первой рекламы. И бот не хранит единственную копию данных: заявку дублируй в таблицу тем же действием, которым принимаешь. ### Формы Яндекс Формы, Google Формы, форма конструктора. Задача одна — превратить интерес в строку с контактом. Ломается на: отсутствии уведомления (заявка лежит сутки, клиент ушёл), лишних полях, отсутствии галочки о согласии на обработку ПДн. ### Автоматизация связок Albato, ApiX-Drive и подобные; часто проще собрать «форма → таблица → бот». Ломается на: молчаливых отказах (связка встала, никто не заметил три дня), лимитах операций, изменении формата на одном конце. У связки должен быть сигнал живости: раз в сутки в личный чат приходит число обработанных заявок, и ноль — тоже сообщение. ## 5. Приём платежей в России Единственная часть, которую **нельзя делать «пока без»**: продукт, не принимающий деньги, ничего не проверяет. ### Развилка: НПД или ИП **Налог на профессиональный доход (самозанятость).** Регистрация в «Мой налог» за вечер, без отчётности и взносов. Ставка 4% с поступлений от физлиц и 6% от юрлиц, лимит дохода 2 400 000 ₽ за календарный год; режим действует как эксперимент по 422-ФЗ до конца 2028 года (актуально на 2026-07-28). Не подойдёт при: перепродаже чужих товаров, наёмных работниках, подакцизных товарах, работе на прежнего работодателя в течение двух лет после увольнения. Превышение лимита — не штраф, а потеря режима с рубля превышения, поэтому при выручке около 200 000 ₽ в месяц готовь ИП заранее. **ИП.** Нужен при перепродаже, планах на сотрудников, требовании контрагентов заключать полноценный договор или заведомом превышении лимита НПД. С 2026 года порог выручки, до которого УСН освобождает от НДС, — 20 млн ₽ (актуально на 2026-07-28). Правило: **начинай с НПД всегда, когда закон позволяет.** ИП ради ощущения серьёзности — это взносы и бухгалтерия при нуле клиентов. ### Приём денег от физических лиц Самозанятому достаточно: перевод на карту или по номеру телефона → чек в «Мой налог» → ссылка на чек клиенту. Онлайн-касса при НПД не нужна, чек из приложения её заменяет. Для витрины годится платёжная ссылка банка или сервиса, работающего с самозанятыми. ИП без работников применяет онлайн-кассу: отсрочка для продающих услуги и товары собственного производства закончилась 1 июля 2021 года. Для онлайн-продаж это облачная касса — аренда фискального накопителя и ОФД помесячно. Заложи расход до запуска, а не после первой продажи. ### Приём денег от юридических лиц Юрлицу нужен документ, по которому оно проведёт расход. Самозанятый выставляет счёт свободной формы и после оплаты отдаёт чек из «Мой налог», акт — по требованию. У ИП это счёт, договор или оферта и закрывающий документ. Барьер: срок оплаты по безналу у среднего клиента 5–15 рабочих дней, у крупного 30–45. Живущая только на безнале первая версия останется без денег в первый месяц — держи оба канала. ### Эквайринг и СБП `экономия_в_месяц = оборот × (ставка_эквайринга × 1,22 − ставка_СБП)`. При обороте 300 000 ₽, эквайринге 2,2% и СБП 0,5% — около 6 500 ₽ в месяц. **Начинай с СБП**, эквайринг добавляй, когда клиенты начнут спрашивать про карту и рассрочку. ### Оферта 1. Продавец — ФИО или наименование, ИНН, статус (самозанятый / ИП), контакты. Анонимная оферта не работает. 2. Предмет — что продаётся, в каком объёме и срок, что считается исполненным. 3. Цена, порядок оплаты и момент, в который договор считается заключённым. 4. Возврат и отказ. По закону о защите прав потребителей покупатель-физлицо при дистанционной продаже вправе отказаться от товара до передачи и в течение установленного срока после, а от услуги — в любой момент с оплатой фактически понесённых расходов. Оферта это право не отменяет, а описывает процедуру. 5. Ответственность и её пределы, порядок разрешения споров, реквизиты. Не копируй чужую оферту целиком: чужие реквизиты, предмет и сроки в споре читаются как отсутствие договора. ## 6. Персональные данные, если собираешь заявки Рассылка рекламы по собранным контактам требует отдельного согласия именно на рекламу: согласие на обработку данных его не заменяет. ## 7. Чек-лист запуска Порядок важен: каждый пункт открывает следующий. 12–16 часов. Соцсети отсутствуют намеренно: канал без продукта наполняется месяцами и не приносит первой продажи. ## 8. Когда автоматизировать, а когда рано `экономия_часов_в_месяц = частота_в_месяц × минуты_на_раз / 60` `месяцев_окупаемости = стоимость_автоматизации / (экономия_часов × часовая_ставка)` Пример: 60 заявок в месяц по 4 минуты на перенос в таблицу и ответ — 4 часа. При ставке 2 000 ₽/час экономия 8 000 ₽ в месяц; бот за 15 000 ₽ разово плюс 1 000 ₽/мес окупается за 2 месяца — стоит. Тот же шаг при 8 заявках даёт 32 минуты и окупаемость больше двух лет — не стоит. ### Пора автоматизировать, если выполнены три условия 1. Шаг повторялся **не меньше 20 раз** и выполнялся одинаково. 2. Занимает суммарно **больше 4 часов в месяц**. 3. Расчётная окупаемость **меньше 3 месяцев**. Сигнал, перевешивающий расчёт: ошибка на шаге дважды стоила денег или клиента — тогда считается не экономия времени, а цена ошибки. ## 9. Типовые ошибки первой версии и их последствия **Строить полгода без клиента.** К запуску гипотеза не подтверждается, а отказаться уже невозможно — вложено слишком много. Признак: в плане есть слово «этап 2». **Личный кабинет и регистрация до первых десяти клиентов.** 30–40% времени уходит на авторизацию, пароли и роли, не связанные с ценностью. Признак: продуктом нельзя воспользоваться, не заведя аккаунт. **Бесплатный доступ «чтобы собрать отзывы».** Вежливые отзывы и ноль знания о готовности платить; перевод на платное теряет большинство. Признак: 200 пользователей и ноль выручки. **Данные только в одном месте.** Блокировка аккаунта конструктора или удалённая таблица уносят всю базу клиентов. Реестр и контакты дублируй туда, где доступ не зависит от внешнего сервиса. **Слишком широкое обещание.** «Автоматизируем бизнес» нельзя ни выполнить, ни проверить, ни продать. Сузь до «выгружаем остатки из МойСклад в прайс для дилеров раз в сутки». **Отсутствие учёта времени.** Без колонки с минутами автоматизацию выбирают по ощущению усталости и обычно неверно. **Что выдаёшь в итоге:** единственную функцию первой версии одним предложением; набор инструментов, из которых она собирается; налоговый статус и способ приёма денег; список вычеркнутого с причиной; чек-лист на выходные с оценкой в часах; одно число, по которому через месяц будет видно, сработало или нет. --- Source: https://samreshuuu.ru/skills/me_validate_idea_ru # 1. Ворота 0: юридическая допустимость Результат — одна из трёх строк: «можно как есть» / «можно после X» / «нельзя без лицензии Y, срок Z». Третья — вердикт «Разворот». # 2. Ворота 1: гипотеза, которую можно опровергнуть Годная: «Мебельщики с оборотом 50–300 млн ₽ на Ozon и WB теряют 80–150 тыс. ₽/мес на возвратах из-за расхождения габаритов в карточке и упаковке, сверяют вручную в Excel раз в месяц, готовы платить 15 000 ₽/мес за ежедневную сверку, проверяемую долей возвратов "не подошёл размер"». Негодная: «малому бизнесу нужна автоматизация отчётности» — опровергнуть нечем, значит и подтвердить нечем. Требования: из сегмента выгружается список компаний, текущий способ назван инструментом (Excel, 1С, МойСклад, тетрадь, наёмный человек), критерий успеха — метрика, которую заказчик уже считает. Выпиши следом 3–5 предпосылок с ценой ошибки и сроком проверки; первой проверяй ту, где «цена ошибки / стоимость проверки» максимально. Типичный сбой порядка: месяц проверяют «удобен ли интерфейс» (цена ошибки — неделя переделки) и не проверяют «есть ли у роли бюджет» (цена — весь проект). # 3. Ворота 2: проблемные интервью ## 3.1. Где брать респондентов в России | Канал | Как заходить | Отклик | Риск | |-------|--------------|--------|------| | Отраслевые чаты Telegram | неделю отвечай по делу в 5–10 чатах, потом проси разговор в личку | 10–25% | бан за первый же опрос | | Профсообщества, ассоциации, клубы селлеров | через организатора или вопрос на созвоне | 30–50% | 2–4 недели на вход | | Холодный обход офлайн (склад, рынок, ТЦ) | в рабочее время, просишь 10 минут | 20–40% | не держатель бюджета | | Отраслевые выставки | обход стендов, вопрос про процесс стендиста | 50–70% | дорога и календарь | | Обзвон по выгрузке из ЕГРЮЛ | звонок, представление и один вопрос | 3–8% | секретарь | Минимум два канала: «люди из Telegram-чатов» — не отрасль. ## 3.3. Как отличить вежливое согласие от готовности платить | Сигнал | Баллы | |--------|-------| | Отдал предоплату или подписал письмо о намерении с суммой | +8 | | Сейчас платит за решение проблемы (подрядчик, сервис, сотрудник) | +4 | | Показал экраном свой костыль: файл, таблицу, тетрадь | +3 | | Назвал сумму потерь с расчётом либо держателя бюджета и статью расходов | +2 | | Дал интро на коллегу из другой компании | +2 | | Согласился на второй разговор и пришёл | +2 | | Сказал «интересно», «полезно», «обязательно попробуем» | 0 | | Похвалил идею и не назвал ни одного случая | −2 | Пороги по 12 разговорам: медиана **≥ 5** — боль реальна; **2–4** — неудобство, платить будут единицы; **< 2** — проблемы нет. Проблема при этом должна стоить клиенту не меньше ×30 годовой цены продукта: продукт за 5 000 ₽/мес требует боли на 1,8 млн ₽/год, иначе решение откладывают бесконечно — «и так терпимо». # 4. Ворота 3: размер рынка снизу вверх ## 4.2. Формула SOM снизу вверх `доля_с_признаком` берётся из интервью (сколько из 12 подошли под определение). `доля_достижимых` для одиночки без бюджета — 5–15% сегмента за первый год. `конверсия_в_оплату` из холодного контакта в B2B — 1–3%, выше ставишь только по факту своих попыток. Пример: мебельщики, ОКВЭД 31.xx, три региона, микро и малые из реестра МСП — 4 100 компаний. Из 12 интервью 5 продают на маркетплейсах → 1 720. Достижимы через два чата и выставку ≈ 10% → 172 контакта. Конверсия 2% → 3–4 платящих × 15 000 ₽ × 12 = 540–720 тыс. ₽/год, то есть цель «200 тыс. ₽/мес» недостижима: расширяй географию, поднимай цену или меняй сегмент. **Порог ворот:** SOM первого года ≥ ×3 целевого годового дохода. ## 4.3. Вакансии как индикатор боли Нанимают человека под задачу — задача существует, стоит денег и имеет владельца бюджета. # 5. Конкуренты: кто уже берёт деньги Ищи не похожие продукты, а тех, **кому платят за этот результат**: агентства, фрилансеров с бирж, интеграторов 1С, штатных сотрудников, франшизы, Excel-шаблоны, платные Telegram-каналы. Фиксируй цену, модель, клиента из кейсов, что ругают в отзывах и чего продукт не делает. **Отсутствие конкурентов — почти всегда диагноз, а не подарок.** Версии: 1. **Не платят** — проблему терпят или закрывают бесплатно (руками, стажёром, шаблоном из чата). Признак: никто в интервью не назвал статьи расходов на тему. 2. **Пробовали и вышли** — признак: мёртвые сайты, архивные лендинги, закрытые ИП с профильным ОКВЭД. Найди основателя и спроси, почему закрылся: самый дешёвый час валидации. 3. **Регуляторный барьер** — см. ворота 0. 4. **Ты неправильно ищешь** — конкурент называет то же самое другими словами: ищи по формулировкам респондентов. 5. **Ниша реально новая** — остаётся, только когда первые четыре опровергнуты фактами. # 6. Ворота 4: тесты платежом Слабый тест не заменяет сильный, а лишь удешевляет путь к нему. ## 6.1. Ручное оказание услуги Оказывай услугу руками, за деньги, до единой строки кода. Фиксируй: сколько часов ушло и куда, что клиент прислал на входе, что просил переделать. ## 6.2. Предпродажа **Порог ворот:** ≥ 3 предоплат от незнакомых до начала валидации людей, каждая не меньше месячной цены. Предоплата от знакомого считается за 0,3. ## 6.3. Лендинг с оплатой Ставь настоящую кнопку оплаты, а на попытке платежа — честный экран: «запуск такого-то числа: оплатить со скидкой или встать в очередь». Пороги применяй при **≥ 300 целевых визитах**, меньше — не считай вообще: | Метрика | Провал | Серо | Сигнал | |---------|--------|------|--------| | Клик по кнопке оплаты | < 2% | 2–5% | > 5% | | Дошли до формы оплаты | < 1% | 1–3% | > 3% | | Оплатили или оставили контакт с суммой | 0 | 1–2 | ≥ 3 | | Средняя глубина скролла | < 40% | 40–70% | > 70% | Диагностика: низкий скролл и низкий клик — мимо аудитории или проблемы, чинится сегментом; высокий скролл и низкий клик — проблема узнана, предложение не убеждает, чинится текстом; высокий клик и ноль оплат — цена или доверие. # 8. Вердикт **Валидировано** — все условия сразу: медиана ИГП ≥ 5 при ≥ 8 незнакомых респондентах; ≥ 3 предоплаты от незнакомых или ≥ 2 оплаченных ручных исполнения; есть конкурент, берущий деньги за близкий результат; SOM первого года ≥ ×3 целевого дохода; ворота 0 без блокеров. Дальше — `me_mvp_ru`, три ручных прогона уходят туда как спецификация. --- Source: https://samreshuuu.ru/skills/me_marketing_plan_ru ## Предпосылки: можно ли уже масштабировать 1. **Повторяемая продажа.** Не «5 клиентов, все знакомые», а порядка 30–100 платящих, из которых минимум треть пришла не через личные связи основателя. 2. **Известен источник каждого клиента.** Нет ответа на «откуда клиент №17» — сначала учёт, потом масштаб. 3. **Удержание не течёт.** Для подписки — месячный отток по деньгам ниже ~5% и не растёт три месяца подряд; для разовых продаж — доля повторных покупок за полгода стабильна. Лить трафик в дырявое ведро — самый дорогой способ узнать, что продукт не готов. 4. **Есть что сказать.** Сто клиентов = сто узнанных вещей. Если основатель не может надиктовать 15 тем, которые знает лучше клиентов, — это первое задание, а не блокер. ## Воронка: пять шагов, ни один не пропускается Вовлечение → Подписка → Изучение → Рассмотрение → Покупка. У каждого шага свой контент и своя метрика, а типовая ошибка МСБ — продавать на шаге вовлечения: пост, который одновременно объясняет проблему и требует оплатить тариф, не работает нигде. Ориентиры, чтобы замечать аномалию (не обещание клиенту): просмотр → подписка 1–3%; подписчик → переход на сайт 5–15% в месяц; переход → заявка 2–10%; заявка → оплата 15–40% в B2B МСБ. Если заявка в оплату идёт в 2%, дело не в контенте, а в квалификации лида или в цене. ## Карта каналов для России Оценивай канал по четырём осям: кому подходит, сколько часов ест, чем ограничен, когда даёт первые заявки. Не рекомендуй больше двух каналов на старте — один человек не тянет три. ### Telegram: канал Основной контентный канал для B2B и экспертных услуг. Главное ограничение — **нулевой органический охват**: Телеграм не показывает канал тем, кто не подписан, рост идёт только через посевы, репосты, взаимные упоминания и внешние источники, плана «выложу и придут» здесь нет. Метрика — не подписчики, а ERR (охват поста / число подписчиков): здоровый диапазон 20–40%, ниже 15% означает накрученную или выгоревшую базу. ### Telegram: бот Одновременно точка захвата контакта, доставка лид-магнита и мини-CRM; заменяет email там, где аудитория писем не читает. База бота арендованная, как и канал. Обязательно логируй источник входа (deep link с меткой), иначе атрибуция канала невозможна. ### VK B2C, локальные услуги, товарка, регионы за пределами столиц. Даёт органический охват через рекомендации — то, чего Телеграм не даёт вовсе, но аудитория смещена по возрасту и географии, и B2B с чеком выше ~100 тыс. ₽ продаётся плохо. Сильная связка — сообщество плюс рассылка сообщений плюс товары внутри сообщества, чтобы покупка не уводила на сайт. ### Дзен Канал холодного охвата: платформа сама показывает статью незнакомым — редкость, поэтому Дзен стоит пробовать почти всем, чей продукт объясним текстом. Минимум 4 статьи в месяц, иначе алгоритм не начнёт раздавать. Аудитория плохо конвертируется в подписку и хорошо — в переход по ссылке: не строй здесь базу, строй трафик. ### YouTube, Rutube, VK Видео Самый дорогой по времени и самый долгоживущий контент: для одного человека потолок 2–4 выпуска в месяц. YouTube в РФ нестабилен по скорости доступа, но остаётся местом, где ищут обучающее видео; Rutube и VK Видео дают стабильную доставку и меньший поиск — публикуй выпуск во все три с разными UTM-метками. Видео окупается не просмотрами, а тем, что его смотрят целиком перед покупкой: это сильнейший контент шага «Рассмотрение», ставь ссылку прямо в коммерческое предложение. ### Авито Для многих ниш это не доска объявлений, а канал продаж с собственным поиском: ремонт, стройматериалы, оборудование, б/у техника, услуги мастеров, часть B2B-поставок. Конкуренция по цене выражена сильнее, чем где-либо, площадка тянет диалог в свой мессенджер и не отдаёт контакт — но заявки приходят в первые дни, а не месяцы. ### Отраслевые медиа vc.ru, Habr, профильные издания, каталоги и сравнения сервисов. Ценность не в охвате, а в двух вещах: ссылка работает на SEO, присутствие в подборках — на шаге «Рассмотрение». Разовый всплеск, а не поток: 1 материал в 1–2 месяца. ## SEO под Яндекс — отдельная дисциплина Для российского МСБ поиск часто оказывается главным каналом: оттуда приходит человек с деньгами и уже сформированной задачей. И это не «то же самое, что Google, но по-русски». **Поведенческие сигналы весят больше.** Яндекс сильнее опирается на то, что человек сделал после клика: вернулся ли в выдачу, сколько провёл, кликнул ли следующий результат. Вывод: страница, отвечающая на запрос в первом экране, растёт, а страница, где ответ спрятан под тремя абзацами «в современном мире», падает — даже если текст длиннее и «оптимизированнее». Накрутку поведенческих не советуй: за неё прилетает фильтр. **Региональность — самостоятельный рычаг.** Выдача по коммерческим запросам разная в разных городах. Присвоение сайту региона в Вебмастере и заполненная карточка в Яндекс.Бизнесе для локальной ниши дают больше, чем полгода работы над текстами. Для компании одного города это первое действие, а не последнее. **Коммерческие факторы.** Для магазинов и услуг Яндекс оценивает признаки настоящего бизнеса: цены на страницах, ассортимент, телефон и адрес, реквизиты, доставка и оплата, отзывы. Страница услуги без цены проигрывает странице с ценой при прочих равных. Вебмастер даёт индексацию, ошибки, регион и диагностику фильтров, Метрика — поведение и цели: отчёты по источникам вытянет `connector`. Порядок работ: семантика, разделённая на коммерческие запросы («купить», «цена») и информационные («как», «чем отличается»); под коммерческие — посадочные с ценой и формой, под информационные — статьи, ведущие на эти посадочные; техническое (скорость, мобильная версия, дубли, карта сайта); регион, карточка, отзывы. Первые позиции по низкочастотке — 2–4 месяца, по средней — 6–9: если заявки нужны через две недели, SEO не ответ, он идёт параллельно с быстрым каналом. ## Темы: выбор по реальному спросу Тема попадает в план, только если подтверждена минимум двумя источниками. **Wordstat.** Смотри не общую частотность, а уточнённую — в кавычках и с восклицательными знаками перед словами, чтобы отсечь широкие совпадения и словоформы: разрыв между широкой и точной частотностью в 20–50 раз — норма, обещать трафик по широкой нельзя. В «Истории запросов» видно сезонность: сезонную тему публикуют за 1–2 месяца до пика, а не в пик. **Поисковые подсказки и «вместе с этим ищут»** — живые формулировки: подсказка «как выбрать» или «чем отличается» и есть готовый заголовок. **Вопросы своих клиентов** — самый ценный и самый игнорируемый источник. Выгрузи переписки поддержки, письма перед покупкой, возражения из продаж: вопрос, заданный дважды, — тема. Для внутренних данных пригодятся `query_sessions` и `query_tasks`, для внешних CRM — `connector`. ## Три уровня контента **Развлекать** — самый охватный и самый трудный уровень. Для МСБ реалистичная форма не юмор, а истории с конфликтом: клиент, требовавший невозможного; закупка, пошедшая не так; спор с подрядчиком. Развлечение — это напряжение и разрешение, а не мемы. Рабочая пропорция для одного человека: 60 / 30 / 10. Чисто обучающий канал не растёт органически, чисто развлекательный не продаёт. ## Реалистичная частота и атомизация Для основателя, который ещё и ведёт бизнес: один основной канал, 2–3 публикации в неделю; один длинный материал в месяц; рассылка раз в две недели. Всё, что выше, продержится шесть недель и умрёт: планируй то, что выдержит год. Атомизация: один длинный материал = 1 статья в блог + 4–6 постов в канал + 1 видео + 1 письмо. Производится один раз, публикуется восемь — так один человек закрывает два канала. Публикуй по расписанию, а не по настроению: `manage_task` с `trigger_type='schedule'` для регулярной подготовки — чтобы план жил как задачи с датами. ## Email: свой канал и требования закона **Согласие до первого письма.** Рекламная рассылка по сетям электросвязи допускается только с предварительного согласия получателя — требование закона «О рекламе». Согласие выражается активным действием: отдельная непредзаполненная галочка, а не «по факту оформления заказа» и не пункт в пользовательском соглашении; отдельно нужно согласие на обработку персональных данных. Доказывать согласие в споре обязан отправитель, поэтому фиксируй время, IP и текст, а double opt-in — не вежливость, а способ иметь доказательство. **Отписка в каждом письме** — в один-два клика, без авторизации; отзыв согласия обязывает прекратить рассылку немедленно. **Метрики рассылки:** доставляемость (ниже 95% — проблема базы или домена), клики вместо открытий как рабочая метрика, отписки (выше 1% на письмо — контент не совпал с обещанием подписки), жалобы на спам (выше 0.1% — тревога, при устойчивом превышении провайдеры режут доставку). Без отдельного поддомена для рассылок, настроенных SPF, DKIM, DMARC и прогрева домена первые недели письма просто не дойдут. ## Маркировка рекламы и ЕРИР Любое платное размещение, направленное на российскую аудиторию, подлежит учёту. Суть: креатив получает идентификатор **erid** через **ОРД** (оператора рекламных данных), erid показывается в самом объявлении вместе с пометкой «Реклама» и указанием рекламодателя, а сведения о договоре, площадке, креативе и сумме уходят в **ЕРИР** — государственный реестр под Роскомнадзором; отчётность подаётся по итогам периода размещения. Это касается постов в Телеграм-каналах и у блогеров, таргета, размещений в отраслевых медиа — и бартера тоже, оплата не обязана быть денежной. Обычно **не** требует маркировки органичная информация о своих товарах на своём сайте и в своих соцсетях без акцента на конкретное предложение, а также рассылка по своей клиентской базе с ограниченным кругом получателей. Граница между «информацией» и «рекламой» размыта, и антимонопольный орган не признаёт «саморекламу» автоматическим освобождением: чем ближе текст к «купите вот это по такой цене», тем выше риск. ### Запрет площадок и сбор 3% С осени 2025 года запрещено размещать рекламу на площадках, признанных в России нежелательными или экстремистскими, — ответственность несут обе стороны, и разместивший, и заказчик. С 1 апреля 2025 года действует обязательный сбор 3% с доходов от распространения интернет-рекламы; для МСБ-рекламодателя это обычно не прямой платёж, а рост цены размещения, который надо заложить в расчёт канала. ## Когда включать платное продвижение Три условия, все обязательны: органический канал уже даёт заявки и понятно, какой материал их приносит; посчитана максимально допустимая стоимость клиента (без этого числа любая цена клика кажется приемлемой); есть 2–3 месяца бюджета на обучение кампаний — кампания, остановленная через неделю, не даёт данных, а только тратит. Порядок захода: ретаргетинг на тех, кто был на сайте или в базе → поиск по коммерческим запросам, где спрос сформирован → look-alike и холодные охваты. ## Как считать окупаемость канала **Атрибуция при длинном цикле.** В B2B между первым контактом и оплатой проходит 2–6 месяцев, и last-click врёт систематически: он отдаёт всю заслугу брендовому запросу, а контент, из-за которого человек вообще узнал название, выглядит бесполезным. Лечится так: UTM-метки на все внешние ссылки, включая описание видео и шапку канала; промокод или отдельная посадочная под канал там, где меток не хватает; свободное поле «откуда вы о нас узнали» в форме заявки; ассоциированные конверсии в Метрике, а не только последний источник. ## Метрики: тщеславные и рабочие | Тщеславная | Почему обманывает | Чем заменить | |------------|-------------------|--------------| | Подписчики | база выгорает, охват падает | ERR: охват поста / подписчики | | Просмотры | не отличают досмотр от промотки | досмотры и переходы по ссылке | | Размер базы | мёртвые адреса топят доставляемость | активные за 90 дней | | Позиции в поиске | средняя позиция ни о чём | клики и показы из Вебмастера по группам | Правило отбора: метрика рабочая, если по её изменению можно принять решение. «Подписчиков стало на 200 больше» — решения нет. «ERR упал с 32% до 14% за месяц» — решение есть: разобраться, что стало с контентом или откуда пришли эти подписчики. ## Режимы отказа - **Три канала сразу.** Признак: за месяц по каждому вышло меньше половины плана. Оставить один, где уже есть отклик, остальные заморозить открыто, а не тихо. - **Контент есть, заявок нет.** Признак: охваты растут, переходов на сайт меньше 1% от охвата. Причина почти всегда в отсутствии шагов «Подписка» и «Рассмотрение» — публикации не ведут никуда. В каждый третий материал ставить один конкретный следующий шаг. - **Подписчики растут, продажи нет три месяца.** Канал собрал коллег, а не покупателей: сменить темы с «про профессию» на «про проблему клиента». - **Одна площадка кормит всё.** Признак: 80% заявок из одного внешнего источника. Переводить аудиторию в email или бот, которыми владеешь. ## Артефакт: контент-план | Дата | Канал | Уровень | Тема | Источник спроса | Шаг воронки | Следующий шаг для читателя | Атомизация | |------|-------|---------|------|------------------|--------------|-----------------------------|------------| ## Артефакт: расчёт по каналам | Канал | Деньги, ₽ | Часы | Стоимость часов, ₽ | Заявки | Клиенты | CAC, ₽ | LTV, ₽ | LTV/CAC | Окупаемость, мес | Вердикт | |-------|-----------|------|--------------------|--------|---------|--------|--------|---------|-------------------|---------| Вердикт — одно из трёх: масштабировать, держать, закрыть. ## Протокол работы Не обещай охваты и сроки как гарантию, не рекомендуй накрутку поведенческих и покупку баз, не советуй размещения на запрещённых площадках и не называй суммы штрафов и реквизиты НПА по памяти — только после проверки. --- Source: https://samreshuuu.ru/skills/me_minimalist_review_ru ## Когда передавать в профильный навык | Во что упёрлось | Навык | |---|---| | «А нужен ли рынку сам продукт» | `me_validate_idea_ru` | | «Что именно строим первой версией» | `me_mvp_ru` | | «Сколько брать, как поднять цену» | `me_pricing_ru` | | «Где взять первых платящих» | `me_first_customers_ru` | | «Куда тратить на продвижение» | `me_marketing_plan_ru` | | «Хватит ли денег, как расти без внешних вложений» | `me_grow_sustainably_ru` | | «Кого нанимать и по каким правилам работать» | `me_company_values_ru` | | «Кто наши люди и где они собраны» | `me_find_community_ru` | Содержимое соседнего навыка по памяти не пересказывай — загрузи. # 1. Правило остановки: что не надо анализировать До всякой решётки отсеки решения, которые анализа не заслуживают: анализ стоит времени владельца — самого дорогого ресурса в компании из пяти человек. Решение **не требует разбора**, если выполнены все три условия: 1. **Обратимо за 30 дней** — откат не требует ничьего согласия, кроме твоего. 2. **Цена ошибки меньше месячной чистой прибыли** — потеряешь и не заметишь в годовом итоге. 3. **Не создаёт обязательств перед третьими лицами** — нет договора с неустойкой, найма, кредита, публичного обещания клиентам. Пример: протестировать новый канал за 30 000 ₽ при прибыли 400 000 ₽/мес — делай сегодня, не считай. Тот же тест по договору с агентством на 6 месяцев с предоплатой — уже обязательство, гони через решётку. **Обратная граница.** Решение требует полного разбора, если верно хотя бы одно: срок обязательства больше 6 месяцев; сумма больше трёх месячных прибылей; после него нельзя вернуться к прежней схеме без потери клиента, сотрудника или данных. Если владелец третий раз за месяц приносит одно и то же решение — это не решение, а страх. Скажи прямо и переведи разговор на условие, при котором ответ станет очевиден. # 2. Решётка: шесть проверок Каждая проверка даёт число или факт, а не оценку по шкале: «7 из 10» — запрещённый ответ. ## 2.1 Обратимость и цена ошибки Спрашивай не «рискованно ли», а два вопроса: **за сколько дней откатывается** и **сколько стоит откат**. | Тип | Срок отката | Что делать | |---|---|---| | Обратимое | до 30 дней | Не обсуждать, пробовать | | Дорогое, но обратимое | 1–3 месяца | Уменьшить масштаб пробы, поставить дату проверки | | Практически необратимое | больше 3 месяцев или откат стоит >1 месячной прибыли | Полный разбор, письменный вердикт | Признак необратимости, который пропускают: **потеря людей и данных**. Уволенный сотрудник назад не приходит, ушедший от плохого сервиса клиент не возвращается по второму письму, история аналитики после плохой миграции не восстанавливается. Всегда предлагай **дешёвую версию того же решения**: не нанять менеджера, а взять на 3 месяца по ГПХ; не выходить на маркетплейс всем ассортиментом, а вывести 5 SKU; не писать приложение, а сделать страницу с формой. ## 2.2 Влияние на денежный поток, а не на прибыль Пороги по умолчанию (корректируй под отрасль): | Показатель | Норма | Тревога | Стоп | |---|---|---|---| | Запас прочности | ≥ 3 месяца | 1,5–3 месяца | < 1,5 месяца | | Доля одного клиента в выручке | < 20% | 20–35% | > 35% | | Доля одной площадки в выручке | < 40% | 40–70% | > 70% | | Цикл оборота | сокращается | растёт 2 месяца подряд | больше срока кредита | Правило: **при запасе прочности меньше 1,5 месяцев любое решение, удлиняющее цикл оборота, — «не делай», каким бы прибыльным оно ни выглядело.** ## 2.3 Кто именно платит за это временем Деньги в смете есть всегда, времени в смете нет никогда. Найди человека, чьи часы уйдут на решение, и посчитай их. Стоимость часа владельца считай не по окладу, а по альтернативе: сколько выручки приносит час его продаж или производства. В МСБ это обычно самая дорогая ставка в компании. Признаки, что за решение платит временем владелец, а он этого ещё не понял: в плане есть слова «я сам разберусь», «пока поведу лично», «на первое время возьму на себя»; у решения нет второго человека, который может его исполнить; запуск требует освоить новый инструмент до первого результата. Проверка: **если решение съедает больше 20% рабочего времени владельца дольше двух месяцев — это не решение, это новая работа.** Такое либо делегируется, либо не делается. ## 2.4 Альтернатива «не делать вовсе» Формулируй её всегда и вслух, тремя строками: что будет через 3, 6 и 12 месяцев, если не делать ничего. - **Ничего не меняется** → решение необязательно, откладывай на квартал. - **Медленно ухудшается** → есть время на дешёвую пробу, спешить незачем. - **Ломается к конкретной дате** (кончается аренда, поставщик поднимает цену, площадка меняет правила) → у решения появился дедлайн, и он становится главным ограничением. ## 2.5 Что перестанет работать, если решение сработает слишком хорошо Проверка, которую пропускают все: считай сценарий не провала, а **тройного успеха**. | Решение | Что ломается при ×3 | |---|---| | Реклама пошла | Не хватает товара на складе, срок ответа клиенту вырос с часа до суток | | Крупный клиент подписался | Он занимает половину мощности, остальные уходят к конкуренту | | Маркетплейс взлетел | Оборотка вся в товаре на складе площадки, деньги придут через 2–4 недели | | Наняли менеджера, продажи выросли | Производство/логистика не тянет, растёт брак и возвраты | | Запустили подписку | Поддержка становится постоянной работой, которую никто не считал | Формулируй как узкое место: **что первым упрётся в потолок и на каком объёме**. Ответа нет — решение недосчитано, и это причина «упрости», а не «делай». ## 2.6 Признак провала и дата проверки Дата проверки — конкретное число, не «через пару месяцев»: для найма конец испытательного срока, для канала продвижения дата исчерпания тестового бюджета, для маркетплейса конец первого полного сезона. # 3. Разбор типовых решений Готовые выводы по решётке. Не пересказывай их целиком: бери строку, подставляй числа пользователя, выдавай вердикт. ## 3.1 Нанимать ли сотрудника Обратимость низкая: испытательный срок ограничен, увольнение вне его — переговоры и выплаты. Касса: расход сразу, отдача через 2–3 месяца минимум — требуй запас прочности ≥ 3 полных стоимостей сотрудника сверх текущего. Время: ввод в дело съедает часы владельца в первый месяц целиком, заложи их в расчёт. **Правило найма:** нанимай не когда «много работы», а когда одна и та же операция повторяется, описана письменно и её можно передать. Не описана — сначала опиши, наём подождёт. Первый наём снимает с владельца рутину, а не добавляет функцию, которой в компании ещё не было. Дешёвая версия: ГПХ или подряд на 3 месяца, частичная занятость, вынос конкретной операции на аутсорс. ## 3.2 Брать ли кредит Ответ определяется одним вопросом: **кредит под оборот или под дыру**. Под оборот (закупить товар, который продаётся с известной скоростью) — решается арифметикой: маржа на цикле должна превышать стоимость денег за тот же цикл минимум вдвое. Под дыру (закрыть повторяющийся кассовый разрыв) — «не делай»: повторяющийся разрыв значит, что цикл оборота длиннее, чем позволяет модель, а кредит переносит проблему на три месяца и добавляет платёж. Платёж по кредиту не должен превышать 30% средней месячной чистой прибыли за последние 12 месяцев — именно 12, иначе сезонный пик выдаст себя за норму. Залог личным имуществом переводит решение в необратимые по разделу 2.1. ## 3.3 Выходить ли на маркетплейс Касса: деньги приходят выплатами по расписанию площадки, товар лежит на её складе — оборотка заморожена до продажи. Это главный удар по потоку и причина, по которой прибыльный выход убивает компанию. Время: карточки, контент, отзывы, поставки — постоянная функция, не разовый проект. Тройной успех: продажи выросли, весь свободный остаток превратился в товар на чужом складе. ## 3.4 Делать ли своё приложение Почти всегда «не делай» в первой итерации. Приложение добавляет две постоянные статьи, которых нет у сайта: обновления под версии ОС и модерацию в сторах. Для российского бизнеса добавляется доступность самих площадок распространения — проверяй текущее положение дел, оно менялось не раз. Приложение оправдано, когда выполняется хотя бы одно: нужен офлайн-режим, нужны пуши как основной канал удержания, нужен доступ к камере/геолокации в фоне, клиент пользуется сервисом чаще двух раз в неделю. Ничего из этого нет — адаптивный сайт плюс сценарий в мессенджере решают ту же задачу за неделю вместо квартала. ## 3.5 Переходить ли на другую систему учёта Мигрируют не программу, а привычку. Три реальные статьи затрат: перенос данных, простой на время перехода, переобучение людей и подрядчиков — бухгалтер, ведущий вас во «внешней» системе, тоже сторона переезда. Переход оправдан, если текущая система **теряет данные или блокирует конкретную операцию**, которую делают еженедельно. «Неудобно» и «выглядит устаревшей» — не причина. Обратимость низкая в части истории: аналитика «год к году» после плохой миграции недоступна навсегда. Переходить — в **начале отчётного периода**, никогда в сезон и никогда за месяц до отчётности. Проба: перенести один участок (только склад или только продажи), проработать месяц параллельно, потом решать. ## 3.6 Брать ли крупного клиента, который станет половиной выручки Порог концентрации: **свыше 35% выручки в одном клиенте компания перестаёт быть хозяином своих цен**. Он это знает и рано или поздно воспользуется — обычно при продлении договора. Что проверить до подписания: условия оплаты (отсрочка — см. 3.7) и штрафы за срыв срока; эксклюзивность и запрет работать с его конкурентами; требования к документообороту и приёмке, которых нет у остальных клиентов; сколько мощности он займёт и кого придётся подвинуть. Вердикт чаще «делай, но»: подписывай, если условия расторжения симметричны и параллельно записан план набора выручки от других клиентов до возврата доли ниже 35% за 12 месяцев. Без плана — «упрости», возьми меньший объём. ## 3.7 Соглашаться ли на отсрочку платежа При сделке 1 000 000 ₽, отсрочке 60 дней и стоимости денег 25% годовых отсрочка стоит около 41 000 ₽ — 4,1% сделки. При марже 15% это больше четверти прибыли по сделке: либо заложи в цену, либо не давай. Правило: **отсрочка допустима, если её цена заложена в цену сделки, а сумма всех открытых отсрочек не превышает месячную выручку.** Отсрочка вместе с предоплатой поставщику даёт двойной разрыв — считай цикл оборота целиком, а не одну сторону. # 4. Ловушки, специфичные для российского МСБ ## 4.3 Риск блокировки или приостановки операций по счёту Банковский контроль по антиотмывочному законодательству (115-ФЗ) — рабочий риск, а не экзотика: операции могут быть приостановлены на время проверки, и компания в этот момент не платит ни поставщикам, ни зарплату. Что это делает с планами: решение, где деньги идут через новых контрагентов, новые виды операций или заметно больший объём наличных, повышает вероятность вопросов от банка; план без второго расчётного счёта в другом банке — план с одной точкой отказа; запас прочности при таком риске держи деньгами, а не «дебиторкой, которую вот-вот заплатят». ## 4.5 Подписки и лицензии как незаметный постоянный расход Решение тянет за собой хвост ежемесячных платежей за сервисы. Сумму всех порождённых им подписок умножь на 12 и сравни с ожидаемой годовой отдачей: хвост больше 10% отдачи — режь. --- Source: https://samreshuuu.ru/skills/me_find_community_ru ## 2. Что считается сообществом Три признака одновременно: **общая идентичность** (участники называют себя одним словом — «селлеры на WB», «1С-ники», «бухгалтеры на аутсорсе», «фермеры-сыровары», «логисты-международники»), **место, где они говорят друг с другом** (чат, форум, конференция, комитет ассоциации) и **общий контекст проблем** — те же законы, площадки, поставщики, отчёты. Нет места сбора — это не сообщество, а сегмент, и работа с ним стоит денег. «Малый бизнес», «предприниматели», «женщины 25–45» — не сообщества: нет ни общего слова, ни общего чата, ни общей проблемы. Услышав такое, возвращай к вопросу: где эти люди разговаривают между собой прямо сейчас, дай ссылку. ## 3. Инвентаризация: где человек уже свой Четыре вопроса, ответы — ссылками, названиями и именами, а не категориями. Ответы клади в `manage_memory`: к ним придётся возвращаться на каждой итерации. ## 4. Карта: где живут профессиональные сообщества в России ### 4.1 Telegram — главный носитель Различай два объекта. **Канал** — вещание: комментарии дают часть сигнала, но это не разговор участников. **Чат** — разговор: жалобы, цены, названия конкурентов, имена подрядчиков; для выбора ниши он ценнее на порядок. Общий перекос: в чатах перепредставлены новички и микробизнес, платёжеспособность ниже средней. Как искать: поиск по ключевому слову внутри Telegram, каталоги каналов и чатов (TGStat и аналоги — фильтр по категории и порогу подписчиков), плюс приём «через человека»: найти активного практика отрасли и посмотреть, где он пишет. ### 4.2 VK Сильнее Telegram в трёх местах: региональный бизнес вне столиц, товарные ниши, аудитория 35+. Даёт таргетинг по сообществу в VK Рекламе — редкую возможность оценить размер ниши деньгами до появления продукта. Слабее в IT и B2B-услугах. ### 4.3 Профильные форумы Рядом стоят Хабр (разработчики, DevOps, аналитики — жёсткая критика в комментариях), vc.ru (много позы, но комментарии под разбором конкретного кейса читать стоит) и отраслевые медиа, которые дают карту, а не разговор: язык отрасли, календарь событий, список игроков. ### 4.4 Сообщества вокруг площадок и учётных систем Самый плотный слой российского B2B: селлеры Ozon, Wildberries и Яндекс Маркета, пользователи и франчайзи 1С, партнёры Битрикс24, пользователи МойСклад, интеграторы CRM, бухгалтеры на аутсорсе. У них уже есть привычка платить за софт и измеримая боль — комиссии, возвраты, отчёты, интеграции. Риск симметричный: правила площадки меняются без предупреждения, поэтому спрашивай прямо, что человек делает, если площадка закроет API. ### 4.5 Офлайн: выставки Протокол, который окупает билет: один вопрос ко всем («что в этом году больнее всего в <процесс>»), цель — 30 разговоров и 30 контактов, а не буклеты; со стендистами говорить в последние два часа последнего дня, когда они свободны и говорят правду; вечером записывать дословные формулировки в журнал раздела 8. ### 4.6 Бизнес-объединения, ассоциации, кластеры «Опора России» (микро и малый), «Деловая Россия» (средний), РСПП (крупный), торгово-промышленные палаты. Внутри — отраслевые комитеты, где сидят собственники, то есть люди, решающие про расходы. Минус: медленно, много ритуала, всё держится на личных отношениях, до первого полезного контакта 3–6 месяцев. Рядом — центры «Мой бизнес», Корпорация МСП и региональные фонды: не сообщество, но точка сбора микро- и малого бизнеса региона. Отраслевые ассоциации дают списки участников — готовую карту рынка, — статистику и доступ на закрытые мероприятия, но членство платное и рассчитано на компанию, а не на человека без продукта: у РАЭК заявленные взносы — 200 тыс. и 1,5 млн ₽ (по данным сайта ассоциации, актуально на 2026-07-28, перепроверь `web_fetch`). Кластеры, IT-парки, ОЭЗ и вузовские акселераторы ценны не статусом резидента, а плотным скоплением компаний одного профиля с общими проблемами — кадры, логистика, сертификация, экспорт; заходи через мероприятия, а не через заявку на резидентство. Порядок захода: чаты, VK, форумы и сообщества площадок — сразу и бесплатно; выставки — на второй месяц; ТПП и кластеры — месяцы; ассоциации — когда появится выручка. ## 5. Оценка сообщества по проверяемым признакам Не ставь оценки по ощущению: собери по каждому сообществу шесть показателей и сверь с порогами. ### 5.2 Активность Для каналов ориентир — ERR (охват поста к числу подписчиков): ниже ~10% обычно означает накрученную или выгоревшую аудиторию, выше 20% — живую (методология сервисов аналитики Telegram, актуально на 2026-07-28). ### 5.3 Платёжеспособность Прямых данных нет — считай, сколько из пяти косвенных признаков выполняется: 1. В чате обсуждают суммы — цены подрядчиков, зарплаты, бюджеты — порядком от 50 000 ₽. 2. Участники нанимают: регулярные «ищу специалиста», «нужен подрядчик». 3. Есть платные отраслевые конференции с билетом от 15 000 ₽, и они собирают зал. 4. Есть минимум 3 продукта с публичным рублёвым прайсом для этой аудитории. 5. Ниша видна в закупках: поиск по ключевым словам на госзакупках даёт контракты с суммами. 3 из 5 и больше — платёжеспособность подтверждена. 0–1 — это аудитория, а не рынок: годится под контент, не под продукт. ### 5.4 Уже покупаемые решения Отсутствие конкурентов — не удача, а чаще всего доказательство отсутствия бюджета. Ищи, за что в нише уже платят: отраслевой софт, интеграторы, консультанты, курсы, подписки на данные; для ПО — Реестр отечественного ПО Минцифры. 0 платных решений — красный флаг, сначала докажи, что деньги есть. 3–10 решений с живыми прайсами — идеально: рынок доказан, места хватает. Один игрок, покрывающий всё, — заходи только в подсегмент, который ему невыгодно обслуживать. ### 5.5 Доступность входа Меряй в днях от «я новый» до «мне отвечают по имени»: чат — 1–2 недели, форум — 2–4 недели, комитет ТПП — 3–6 месяцев. Если входа нет нигде, а денег на платный вход тоже нет, ниша выбрана неправильно. ### 5.6 Скорость обновления состава Текучесть состава решает, какая монетизация возможна. Высокая (селлеры-новички, начинающие фрилансеры) — постоянный приток покупателей, но короткая жизнь клиента и низкая платёжеспособность: разовый продукт или курс. Низкая (нотариусы, главные инженеры, владельцы производств) — входить сложно и продавать долго, но клиент остаётся на годы и рекомендует: только такая ниша держит подписку. ## 6. Как посчитать размер ниши по открытым данным 1. **Единый реестр субъектов МСП ФНС** (rmsp.nalog.ru, открытые данные на nalog.gov.ru): ИНН, категория (микро/малое/среднее), регион, основной и дополнительные ОКВЭД. Даёт число компаний нужного профиля по стране и региону; выгрузку обрабатывай через `sandbox_bash` и `repl_execute`, а не глазами. 2. **Вордстат Яндекса** — частотность головного запроса по регионам: это спрос, а не количество компаний. 3. **Портал госзакупок** — при наличии бюджетных заказчиков поиск по ключевому слову покажет объём, цены и поставщиков. Основной ОКВЭД часто указан формально, поэтому число по нему — верхняя граница, а не факт: держи три оценки (ОКВЭД, площадка, спрос) и работай с наименьшей. ## 7. Как войти и не быть выгнанным Спамом считается и сообщение без ссылки: переводящее чужой вопрос на себя, «а вот у нас в компании», опрос без обещания вернуть результат, созвон в первом контакте. ## 8. Как измерить повторяемость проблемы Ощущение «на это часто жалуются» не стоит ничего. Заведи журнал (`documents`): дата, сообщество, автор (ник, обезличенно), дословная цитата, проблема в твоей формулировке, чем решает сейчас, названа ли сумма или потерянное время. - < 5 разных людей за 90 дней — частный случай, не проблема ниши. - 5–14 — гипотеза, требует разговоров. - ≥ 15 — повторяемая проблема, с ней можно идти в `me_validate_idea_ru`. Отдельно помечай жалобы, где названы деньги или часы («теряю день на сверку», «плачу 30 тысяч в месяц за это»): проблема с ценой продаётся, проблема без цены — раздражение. ## 9. Широкая ниша или узкая: расчёт вместо спора Клиентов = цель_в_месяц / чек_в_месяц; достижимых людей = клиентов / конверсия_из_контакта_в_оплату. Реалистичная конверсия внутри своего сообщества с живым контактом — 2–5%, в холодной рассылке снаружи — 0,3–1%. | Цель, ₽/мес | Чек 1 000 ₽ | Чек 5 000 ₽ | Чек 20 000 ₽ | Чек 100 000 ₽ | |---|---|---|---|---| | 200 000 | 200 клиентов | 40 | 10 | 2 | | 500 000 | 500 | 100 | 25 | 5 | | 1 000 000 | 1 000 | 200 | 50 | 10 | Пример: цель 250 000 ₽/мес, продукт 3 000 ₽/мес — нужно 84 платящих, при конверсии 2% это 4 200 достижимых людей. Чат на 900 человек столько в первый год не даст: либо поднимай чек до 15 000 ₽ (хватит 17 клиентов и 850 контактов), либо добавляй второе сообщество той же ниши. **Чем уже ниша, тем выше должен быть чек.** Узкая ниша с чеком 500 ₽ арифметически безнадёжна; узкая ниша с чеком 30 000 ₽ и 300 участниками — рабочий бизнес на 5–10 клиентах. Широкая ниша даёт не преимущество, а конкуренцию и дорогой трафик: сужай, пока не сможешь назвать 20 конкретных людей по имени, которым продукт нужен сегодня. Не можешь назвать 20 — ниша ещё не выбрана. ## 10. Регуляторные барьеры: проверить до, а не после Реквизиты и пороги, которых не знаешь точно, проверяй перед тем, как назвать: выдуманная статья хуже её отсутствия. ## 11. Типовые ошибки выбора и чем они заканчиваются | Ошибка | Как выглядит | Чем заканчивается | |---|---|---| | Сообщество выдумано | «Создам комьюнити владельцев кофеен» | Год на сбор аудитории до первого рубля | | Выбор по размеру рынка | «Малый бизнес — миллионы компаний» | Канала до них нет, экономика не сходится | | Пропуск участия | Сразу «что им продать» | Продукт решает придуманную, а не услышанную проблему | | Слишком широко | «Предприниматели» | Не цепляет никого, конверсия ниже 0,3% | | Узко при низком чеке | 200 человек, подписка 500 ₽ | Потолок 100 000 ₽/мес при полной загрузке | | Ниша без конкурентов | «Никто это не делает» | Не делает, потому что за это не платят | | Ниша, которую презираешь | «Скучно, но денежно» | Выгорание на 8–14 месяце | | Регуляторка найдена после запуска | Лицензия, СРО, персданные | Переделка или закрытие | ## 12. Критерии окончательного выбора Проходят только те, у кого выполнены все пять условий — не большинство, все. 1. **Ты внутри:** состоишь сейчас или входишь за 30 дней без денег. 2. **Проблема повторяется:** 15+ разных людей за 90 дней (раздел 8). 3. **Деньги подтверждены:** 3 из 5 признаков платёжеспособности и минимум 3 платных решения. 4. **Арифметика сходится:** достижимых людей хватает под цель (раздел 9). 5. **Ты выдержишь 5 лет:** честный ответ на вопрос 4 из раздела 3. Финалистов не больше трёх, дальше бери один — с максимальным перевесом по пунктам 2 и 3: два сообщества параллельно означают вдвое меньше времени в каждом и ноль репутации в обоих. ## 13. Формат результата Карточка по каждому финалисту плюс таблица сравнения. Таблицу для работы на несколько месяцев отдавай файлом через навык документов или таблиц; короткую таблицу — Markdown. Если выбор понятнее через карту связей или визуальное сравнение, дополнительно используй `render_visual(title=..., html=...)` прямо в разговоре; правила оформления — в описании инструмента, загруженного через `tool_search`. --- Source: https://samreshuuu.ru/skills/office_hours_ru ## 1. Почему по одному вопросу Список вопросов убивает сессию, и механика этого конкретная. Один вопрос за раз даёт три вещи, которых у списка нет: Предел — один вопрос в реплике. Уточняющая переформулировка («когда это было в последний раз?») допустима только как разъяснение того же вопроса. ## 2. Фаза 0. Режим сессии Первая реплика — один вопрос: - **Бизнес-режим** → спрос, клиент, деньги, узкий клин. - **Билдер-режим** → в чём вау, что уже пробовал, что значит «готово». Не смешивай их из вежливости. Билдер-режиму нельзя задавать вопросы про монетизацию — это гасит проект и ничего не выясняет. Бизнес-режиму нельзя разрешать уход в «мне просто интересно» — частая форма побега от вопроса про деньги. Есть третий вариант, самый частый в российском малом бизнесе и никогда не называемый вслух: **внутренний инструмент** («хочу автоматизировать приёмку»). Клиент тут — собственная операционка, спрос проверяется не опросом, а стоимостью нынешнего процесса в часах и рублях. Услышал «это для нас самих» — спрашивай не про рынок, а про человеко-часы в месяц. ## 3. Фаза 1. Диагностика: до факта, а не до мнения Цель фазы — не «понять идею», а достать **проверяемые факты**: имена, даты, суммы, уже произошедшие действия. Мнение о будущем («думаю, будут покупать») данными не является. ### 3.1 Бизнес-режим, порядок вопросов Порядок не случаен. Про клиента спрашиваешь **до** подробного описания решения, иначе клиент подберётся под решение. Про деньги — после статус-кво: цена нынешнего способа задаёт потолок цены нового. ### 3.3 Три вопроса, вскрывающие пустоту Расплывчатый ответ нельзя лечить повтором вопроса — на повтор приходит тот же туман другими словами. Лечится он **сменой типа ответа**: вместо суждения запрашивается факт, который либо есть, либо нет. Правило перехода: **дальше идёшь, только получив имя, дату, число или действие.** Нет факта после двух попыток — это тоже результат: зафиксируй прямым текстом («мы дважды искали конкретного человека и не нашли — это главный риск») и иди дальше, не устраивая допрос. ### 3.4 Как отличить настоящий ответ от правдоподобного Правдоподобный ответ узнаётся по четырём признакам: - **гладкость.** Выходит быстрее настоящего, потому что уже произносился на питчах. Настоящее вспоминание идёт с запинкой и деталью не по делу («это была Марина... нет, в марте, она ещё в отпуск уходила»). - **обобщение вместо случая.** «Селлеры теряют деньги на возвратах» вместо «у Дениса в июне вернулось 340 штук из 1100». - **круглая цифра или её отсутствие.** «Процентов 30» — оценка, а не замер. - **нет имени у источника.** Ответ без единого человека обычно пересказ статьи. Дожимай мягко и конкретно: «покажи, где это видно — выгрузка, переписка, отчёт?» Владелец действующего бизнеса почти всегда достаёт факт из 1С, МойСклада, Битрикс24, кабинета Ozon/WB или банковской выписки — это лучшее доказательство, какое бывает на офис-ауэрсе. ## 4. Типовые уклонения и что за каждым стоит **Говорит о рынке вместо клиента.** «Рынок логистики огромный.» За этим: ни одного разговора с покупателем. Возврат: «Рынок пусть будет любой. Кто конкретно первый — имя, компания, должность?» **Говорит о технологии вместо проблемы.** «Тут будет RAG, векторная база, дообученная модель.» За этим: решение придумано раньше проблемы, человеку просто хочется это построить. Возврат: «Опиши, что происходит у клиента в момент, когда ему это понадобится. Без единого технического слова.» Не описывается — задачи, скорее всего, нет. **Говорит о функциях вместо результата.** «Будет дашборд, уведомления, интеграция с 1С.» За этим: непонимание, что клиент покупает исход, а не экраны. Возврат: «Что у клиента изменится в цифрах через месяц использования?» **Говорит о команде и сроках вместо задачи.** «За два месяца вдвоём поднимем.» За этим: побег из неопределённости в план, потому что план успокаивает. Возврат: «Отложим сроки. Мы всё ещё не назвали, кому это нужно.» ## 5. Фаза 2. Предпосылки и недельные проверки Выдели **3–5 предпосылок**, не любых, а несущих. Признак несущей один: **если она ложна, проект не переделывается, а закрывается.** «Люди предпочтут тёмную тему» — не несущая. «Бухгалтер согласится отдать доступ к 1С» — несущая: без доступа продукта не существует. Для каждой запиши: формулировку в проверяемом виде, уверенность (высокая / средняя / низкая) и **проверку, укладывающуюся в неделю без написания продукта.** Хорошая недельная проверка отвечает трём требованиям: результат наступает за ≤7 дней; итог — число или факт, а не впечатление; провал возможен. Проверка, которая не может провалиться, — не проверка. Каталог проверок, работающих в российском малом и среднем бизнесе: | Предпосылка | Проверка за неделю | Что считается «прошло» | |---|---|---| | «Клиенты платят за это» | Продать вручную трём действующим клиентам до постройки | Хотя бы одна оплата или подписанный счёт | | «Проблема массовая» | Выгрузка из своей же CRM/1С за 12 месяцев | Доля затронутых заказов ≥ порога, названного заранее | | «Процесс дорогой» | Замер: кто, сколько минут, сколько раз в неделю | Часы × ставка дают сумму, которую не стыдно назвать | | «Данные вообще доступны» | Запросить доступ к кабинету/базе у одного клиента | Доступ дали за неделю | | «Люди дойдут до нас» | Объявление в 2–3 отраслевых Telegram-каналах | Заранее названное число откликов | | «Замена ручного труда сработает» | Сделать работу руками для одного клиента за деньги | Клиент принял результат и заплатил повторно | Порог заранее — правило без исключений: до начала проверки человек называет число, при котором признаёт провал. Без него любой исход объявляется успехом. ## 6. Фаза 3. Самый узкий клин Клин — не «MVP поменьше». Это **самая узкая версия, которая всё ещё кому-то целиком закрывает задачу.** Половина задачи, закрытая для всех, не стоит ничего; вся задача, закрытая для одного, стоит денег. Сужать можно по пяти осям, и одной оси обычно мало: 1. **Кто** — не «селлеры», а «селлеры на Ozon в категории БАДов с оборотом 3–15 млн ₽ в месяц». 2. **Что** — один сценарий вместо набора. 3. **Когда** — один момент в месяце (закрытие, приёмка, сверка), а не постоянная работа. 4. **Насколько автоматически** — сначала руками с твоим участием, потом кнопкой. 5. **Где** — один источник данных вместо трёх интеграций. ### Разобранные примеры сужения **Было:** «Платформа аналитики для маркетплейсов.» **Стало:** «Раз в неделю присылаем селлеру на Ozon список SKU, где цена ушла ниже себестоимости с учётом комиссии и логистики, — по выгрузке из его кабинета, файлом, без интеграции.» Ось: что + когда + где. Проверяется на одном клиенте за неделю. **Было:** «ИИ-помощник для бухгалтерии.» **Стало:** «Сверка актов с контрагентами за квартал: берём выгрузку из 1С и присланные акты, отдаём список расхождений с суммами.» Ось: что + когда. Клиент — один главбух в знакомой компании, а не «малый бизнес». **Было:** «CRM для оптовиков цветов.» **Стало:** «Отчёт по списанию: что не продалось за сутки и на какую сумму, по одной точке, из накладных в МойСклад.» Ось: кто + что + где. Проверочный вопрос: «Если построить только это и больше ничего — назовёт ли этот человек цену, за которую возьмёт?» Нет — клин не найден, сужай дальше, а не расширяй. ## 7. Фаза 4. Несколько подходов - **Подход A — самый простой.** Работает на выходных, часть шагов вручную. Обычно: таблица + выгрузка + человек. - **Подход B — амбициознее.** Неделя работы, интеграция, автоматизация одного шага. - **Подход C — другой угол.** Не версия A побольше, а другая гипотеза о том, кто платит и за что: не продукт, а услуга под ключ; не подписка, а процент от найденных денег. Для каждого: что делает, сложность, ключевой риск, почему может сработать и — обязательно — **какую предпосылку из фазы 2 проверяет.** Подход, не проверяющий ни одной, лишний. ## 8. Когда честнее отговорить Отговаривать нужно, когда сходятся несколько признаков сразу — по одному они ничего не значат: - ни одного человека по имени за всю сессию; - нынешний способ бесплатен для клиента и никого не раздражает; - решение придумано раньше проблемы и не отпускается; - нет ни одного способа проверки дешевле трёх месяцев работы; - у собеседника уже есть работающий бизнес, а идея отбирает внимание, ничего не давая взамен; - сумма, которую он собирается потратить, для него значима (спроси, а не считай сам). Как сказать, чтобы услышали: Не отговаривай в билдер-режиме. Там критерий — интерес автора, и деньги ни при чём. ## 9. Фаза 5. Дизайн-документ Собирается в конце, из материала сессии, без новых допущений. Раздел нечем заполнить — пиши «нет данных», а не сочиняй. Документ отдавай через `documents` — как файл, а не простыней в чат: его будут править и показывать другим. ## 10. Фаза 6. Наблюдения о мышлении 2–4 наблюдения, **цитатами, а не характеристиками.** Цитата проверяема и не оспаривается; характеристика — оценка, на неё отвечают защитой, а не размышлением. Одно наблюдение о сильной стороне обязательно: из сессии, состоящей только из дыр, запоминается не разбор, а обида. --- Source: https://samreshuuu.ru/skills/me_first_customers_ru ## 1. С чего начинаешь любой разговор 1. **B2B или B2C**, и если B2B — кто платит: собственник, руководитель отдела, закупщик. Три разных цикла сделки: 2–10 дней / 2–6 недель / 1–4 месяца. 2. **Средний чек.** При 3 000 ₽/мес ручной созвон не окупается, при 60 000 ₽/мес окупается даже поездка в другой город. 3. **Сколько клиентов уже платят деньгами** — не «тестируют», не «обещали». Ноль, 1–5, 6–30, 30+ — четыре разных плана. 4. **Сколько часов в неделю** он реально тратит на продажи. Не знает своего чека — это `me_pricing_ru`. ## 2. Концентрические круги: кому писать и в каком порядке Круги идут по возрастанию цены контакта. Не перескакивай: холодные продажи без отработки на тёплых сжигают базу. ### Круг 3 — незнакомцы 300–1 000 адресных контактов до первых 20 клиентов, нормативы — в разделе 8. ## 3. Где в России физически лежат первые клиенты ### 3.1 Отраслевые Telegram-сообщества (B2B, основной канал) Заменили и LinkedIn, и отраслевые форумы. Ищи по формуле «отрасль + чат/сообщество/клуб»: селлеры маркетплейсов, 1С-франчайзи, бухгалтерские аутсорсеры, логисты, автосервисы, застройщики. ### 3.2 Отраслевые выставки Стенд не нужен — нужен **билет посетителя**: экспоненты стоят и ждут разговора, за два дня реально провести 30–60 бесед с ЛПР. Площадки — Экспоцентр и Крокус Экспо, Экспофорум в Петербурге; календари ведут ТПП РФ и отраслевые ассоциации. Не питчь: задай один вопрос — «как вы это делаете сейчас?» — и договорись о созвоне через неделю (конверсия 20–30%). ### 3.3 Тендерные площадки как источник контактов zakupki.gov.ru и коммерческие ЭТП — **открытая база подтверждённой деньгами потребности**. Ищи закупки по своим ключевым словам за 12 месяцев и выписывай два списка: проигравших участников (потребность осталась, поставщика нет) и заказчиков с регулярными однотипными закупками. Заход — «видел вашу закупку на X, есть решение дешевле, готов показать до следующей». ### 3.4 ЕГРЮЛ, реестр МСП и проверка контрагентов Так список собирается по формальным признакам, а не «по ощущениям». - **Единый реестр субъектов МСП (ФНС)** выгружается целиком: ИНН, наименование, регион, ОКВЭД, категория; на март 2026 в нём более 6,9 млн субъектов. Лучший бесплатный источник сегментации: «микропредприятия, ОКВЭД 47.91, Свердловская область» — список за запрос. - **ЕГРЮЛ/ЕГРИП** — руководитель, дата регистрации, уставный капитал, адрес. - **Контур.Фокус, СПАРК, Rusprofile** добавляют выручку, численность, арбитражи, а в платных тарифах — выгрузку по фильтрам. Сегмент строй по 3–5 признакам: ОКВЭД, регион, категория МСП, год регистрации, выручка. Компании старше десяти лет с выручкой 50–500 млн ₽ — типичный платящий сегмент для ИИ-сотрудника. Данные о юрлице открытые, личный мобильный директора — уже персональные данные (раздел 7). ### 3.5 Прочие живые каналы **2ГИС и Яндекс Карты** — локальный B2B: категория + город даёт список с телефонами, отзывы в карточке — материал для первого сообщения. **B2C:** сообщества ВКонтакте, Авито, чаты районов и ЖК, офлайн-точки, где аудитория уже стоит в очереди; конверсия ниже, но контакт дешевле — считай стоимость одного платящего, а не проценты. ## 4. Квалификация до траты времени Созвон стоит 40–60 минут твоей жизни. Отсеивай до него, четырьмя вопросами в переписке: 1. **Есть ли задача сейчас** — «как вы решаете это сегодня?» «Никак и нас устраивает» = не клиент. 2. **Кто решает** — «кроме вас, кто-то ещё согласует?» В МСБ это почти всегда собственник. 3. **Есть ли деньги** — не спрашивай бюджет, назови вилку: «у нас от N ₽ в месяц, это в вашей зоне?» Половина отвалится здесь. 4. **Есть ли срок** — «к какому моменту это должно работать?» Без срока сделка не закрывается. Красные флаги: просят бесплатный пилот «посмотреть», отказываются назвать свои цифры, общаются через ассистента без доступа к ЛПР, требуют NDA и полное ТЗ до разговора. Норматив — **отсеивать 50–70% лидов до созвона**. ## 5. Шаблоны первого контакта ### 5.2 Почта (B2B, когда мессенджера нет) Тема — про задачу конкретной компании; слова «предложение», «сотрудничество», «скидка» в теме отправляют письмо в игнор. **Строка «откуда взял контакт» обязательна**: она превращает холодное письмо в обоснованное обращение. **Один вопрос вместо призыва к действию** — на вопрос отвечают, на «давайте созвонимся» нет. **«Не буду отвлекать»** даёт лёгкий выход и повышает долю ответов. Норматив: 4–12% ответов, половина из них — «нет». Меньше 2% — проблема в сегменте, меняй список, а не формулировки. ### 5.3 Телефон **«Удобно минуту» с настоящей паузой**: без вопроса о времени человек слушает вполуха, без паузы вопрос риторический. **Повод во втором предложении** — на третьем кладут трубку. **Финальный вопрос о положении дел, а не о встрече** — так разговор продолжается. Звони с 10:30 до 12:00 и с 15:00 до 17:00 по времени клиента, а после в тот же час отправь письмо-резюме: устная договорённость без письменного следа не существует. ## 6. Возражения МСБ и что на них отвечать **«Мы подумаем».** Самый дорогой ответ: выглядит как «почти да». Возвращай в конкретику — «Что должно произойти, чтобы ответ стал “да”?» и «Когда перезвонить?» Без даты следующего шага сделка мертва. **«Мы небольшие, нам рано».** «Сколько часов в неделю уходит на X?» Часто больше, чем у крупных: системы нет. ## 8. Воронка с числами | Этап | Переход | Норматив | Что значит провал | |------|---------|----------|-------------------| | Прошли формальную квалификацию | 1 000 → 400 | 40% | Сегмент выбран наугад | | Ответили хоть что-то | 400 → 40 | 10% | Ниже 4% — плохой сегмент, не текст | | Ответили «расскажите» | 40 → 20 | 50% | Оффер не про их боль | | Созвон состоялся | 20 → 12 | 60% | Нет подтверждения за час до | | Дошли до КП | 12 → 7 | 55–60% | Плохая квалификация | | Оплатили | 7 → 2 | 25–35% | Нет срока, не тот ЛПР | Итого **1 000 контактов → 2 платящих клиента**: 20 холодных клиентов — это 8–10 тыс. контактов и год работы одного человека. Поэтому круги 1 и 2 обязательны, они дают первые 10–20 клиентов в 20 раз дешевле. ### 8.2 Учёт До 30 клиентов хватает одной таблицы: дата контакта, канал, компания, ИНН, ЛПР, этап, дата следующего шага, причина отказа. **Причина отказа обязательна**, без неё воронка бесполезна. Расчёты — `repl_execute`, профиль клиента — `manage_memory`, напоминания — `manage_task`. Битрикс24 и amoCRM (через `connector`) имеют смысл после 30–50 сделок: раньше CRM отнимает больше, чем экономит. ## 9. Что должно быть в коммерческом предложении КП на 1–2 страницы, PDF (собери через `documents`), имя файла «КП_Самрешу_для_Технопарк_2026-07-28.pdf», а не «kp_final_v3.pdf». Не должно быть: истории компании, слов «инновационный» и «под ключ», всех тарифов сразу, скриншотов. ## 10. Договор с первым клиентом - **Оферта на сайте** — рабочий вариант до 50–100 тыс. ₽: оплата счёта = акцепт, подписывать нечего, экономия — недели. Содержит предмет, цену и порядок оплаты, срок и порядок оказания, порядок возврата, ответственность, реквизиты. - **Предоплата 100%** у первых клиентов — не жадность, а фильтр: кто отказывается платить вперёд при чеке 20–30 тыс. ₽, скорее всего не заплатит и потом. Выше 100 тыс. ₽ нормально 50/50 или помесячно. - **Акт** клиенту на ОСН или УСН «доходы минус расходы» нужен для расходов, без него он тянет с оплатой следующего периода. Закрывай период сразу, не в конце квартала. - **Оплата.** Юрлицам — счёт на расчётный счёт; физлицам — эквайринг или платёжная ссылка плюс онлайн-чек (54-ФЗ «О применении контрольно-кассовой техники»). - **Что прописать:** предмет в измеримых единицах, срок, порядок приёмки, последствия просрочки с обеих сторон, порядок расторжения, конфиденциальность. Штрафные санкции в первом договоре с МСБ пугают. ## 12. Порог «100 клиентов» и когда он другой 100 платящих — число, при котором повторяемость перестаёт быть случайностью и включается сарафанное радио. Но порог считается от экономики: `нужное_число_клиентов = целевой_месячный_доход / средний_чек_в_месяц`. Сигнал готовности к масштабу — три факта сразу: клиенты продлевают без напоминаний, приходят входящие по рекомендации, `контактов_на_клиента` перестало падать. --- Source: https://samreshuuu.ru/skills/retro_ru ## 1. Порядок: факты собираются ДО обсуждения **Первое высказанное мнение задаёт рамку всем остальным.** Если встречу открывает фраза «мы просели из-за интеграции с 1С», дальше команда спорит с этой рамкой, а не ищет причины: одни защищают интеграцию, другие ищут ей подтверждения. Сильнее всего это работает, когда первым говорит самый старший в комнате. ## 2. Что собирается машинно ### 2.1 План против факта по срокам Через `query_tasks` подними задачи периода с плановой и фактической датой: Среднее врёт: одна застрявшая задача создаёт ощущение системного провала. **Доля в срок ниже 60%** — планирование сломано. **Выше 95% — тоже сигнал**: оценки с запасом, реальная ёмкость скрыта. ### 2.2 Число возвратов задачи в работу Через `query_tasks` посчитай переходы назад: «в ревью» → «в работе», «готово» → «переоткрыто». Возврат дороже, чем видно в отчёте: разработчик уже выгрузил контекст из головы и загружает заново. **Выше 25%** — критерии готовности не согласованы до начала работы. Задача с 3+ возвратами разбирается отдельно: там расплывчатая постановка или два представления о результате. ### 2.3 Время ожидания ревью Разница между «отправлено» и «начато», а не между отправкой и мержем: ожидание, не проверка. **p50 больше 8 рабочих часов** — задачи ночуют в очереди, разработчик каждый день начинает с чужого контекста. **p90 больше 3 рабочих дней** — узкое горло, обычно один человек, к которому сходятся все проверки; лечится вторым ревьюером на область. ### 2.4 Частота срочных правок Через `sandbox_bash` (`git log`) по клону репозитория: Доля срочных правок и откатов от всех релизов — прямой индикатор качества выхода. **Выше 20%** — приёмка не работает, проверку делают пользователи. Смотри отдельно вечер пятницы: срочные там регулярно — это не про качество, а про календарь релизов. ### 2.5 Файлы, которые правятся чаще всего Файл в топе — либо точка роста продукта, либо место, где архитектура сопротивляется изменениям. Различает вторая выкладка: сколько правок были срочными или откатами. Высокая частота И высокая доля срочных — кандидат номер один в техдолг, доказуемый, а не «Петя считает, что там каша». ### 2.6 Незавершённое из прошлого периода Через `query_tasks` — задачи, открытые больше периода назад и не закрытые, с возрастом в днях. Старше двух спринтов почти всегда мертва: либо не нужна, либо её некому начать. Разговор о ней — «закрываем или назначаем владельца сегодня». ### 2.7 Пакет фактов Одна страница, через `documents`: ## 3. Форматы под ситуацию ### 3.1 Обычный спринт (45–60 минут) Решения прошлого раза (5 мин) → факты без обсуждения (5 мин) → три колонки (20 мин) → причины двух самых дорогих проблем (15 мин) → решения (10 мин). ### 3.2 Провал: сорванный релиз, потерянный клиент, отменённый проект (90 минут) Три колонки здесь не работают: «хорошо» превращается в вымученное «зато мы сплотились». Вместо неё — **хронология**: восстанови события с метками времени через `query_tasks` и `query_sessions` и разбирай не «что плохо», а «в какой момент мы ещё могли свернуть и почему не свернули». Почти всегда находится точка, где сигнал был, но его нечем было услышать: не было отчёта, порога, договорённости, кто эскалирует. Разбор не проводится в день провала: минимум сутки, иначе это выяснение, кто виноват. ### 3.3 Конфликт в команде Ретро — неподходящий инструмент, и это надо сказать вслух: конфликт при всех либо замалчивается, либо превращается в публичную сцену, после которой в команде на месяц пропадает откровенность. Выноси его в разговор один на один или с медиатором, а на ретро оставляй **процессную часть**: «две команды правят один модуль», «непонятно, кто решает по API». Её чинят регламентом, личную — нет. ### 3.4 Разбор инцидента Жёсткое правило: **разбор безвиновный**. Имена в хронологии допустимы («дежурный применил откат в 14:22»), оценки действий — нет. Разделы: хронология по минутам, время обнаружения, реакции и восстановления, влияние в измеримых единицах (сколько заказов не прошло и на какую сумму), что сработало, решения. Если время обнаружения больше времени восстановления — чинить надо мониторинг, а не код. Самый пропускаемый вывод постмортема. ## 4. Безопасность обсуждения как условие правды Ретро производит только ту информацию, которую безопасно произнести. Иначе встреча идёт, отчёт пишется, знания в нём нет. ### 4.2 Что даёт правду Открывай встречу фразой: «Каждый действовал разумно, исходя из того, что знал в тот момент». Это рабочая гипотеза, а не вежливость: странный выбор означает неполную картину, чинить надо доступ к информации. ## 5. Три колонки: как не получить вату **Хорошо.** Не «команда молодец», а действие с последствием: «раннее подключение тестировщика к выгрузке в МойСклад — задача ушла в прод с первого раза». Практику повторяют намеренно, только если понятно, что сработало. **Не так.** Обязательно измеримое последствие: «было сложно» → «интеграция с Битрикс24 заняла 9 дней вместо оценённых 2: документация метода не совпадала с фактическим ответом, и это выяснилось на четвёртый день». Не назвал цену в днях, рублях, возвратах — спроси «во что обошлось»; нет ответа — пункт в наблюдения, а не в проблемы. **Улучшить.** Только зона влияния команды: «клиент меняет требования» — не улучшаемо, «мы начинаем работу до письменной фиксации требований» — улучшаемо. Разделяй явно, иначе колонка заполняется жалобами на внешний мир. ## 6. Причины: «пять почему» и её предел **Известный предел: цепочка линейна, а причин обычно несколько.** Реальный отказ почти всегда совпадение: не сработал автотест И ревьюер торопился И релиз был в пятницу вечером. Цепочка выберет одну ветку — ту, что назвал первый говорящий, — и остальные останутся неисправленными. Лечение: на каждом «почему» спрашивай **«что ещё»**. Получается дерево, а не цепочка. Ветку выбирай по критерию: **какая причина, будучи устранённой, предотвратила бы больше похожих случаев**. ### 6.1 Как не упереться в «человек был невнимателен» Это тупик, а не причина: выглядит ответом, потому что дальше спрашивать неловко. Признак — из вывода следует действие «быть внимательнее». Проход сквозь него — смена вопроса: **не «почему он ошибся», а «почему ошибка доехала до последствий»**. Ошибка человека — данность, она случится снова. Вопрос в том, что должно было её остановить: проверки не было, отключена, её результат не читают или он тонет среди ложных срабатываний. Пример. В прод уехала цена с ошибкой в разряде: 1 990 ₽ вместо 19 900 ₽, за 40 минут 60 заказов, потери около 1 140 000 ₽. - Почему уехало? Менеджер ошибся при ручной правке. *(Тупик — дальше «был невнимателен».)* - Переформулируем: почему доехала до покупателя? Нет проверки на резкое отклонение цены от предыдущей. - Почему нет? Выгрузка идёт из таблицы прямо в маркетплейс, без промежуточного шага — так делали с запуска, когда позиций было 30 и всё просматривалось глазами. - Что ещё сработало? Отклонение было видно в отчёте продаж, но отчёт смотрят раз в сутки утром. Две ветки — два решения: блокировка выгрузки при изменении цены больше чем вдвое и оповещение при всплеске заказов по одному SKU. Ни одно не про внимательность. ### 6.2 Что значит «системная причина» проверяемо Причина системная, если верно всё из трёх: 1. Не содержит имени человека и не изменится от его замены. 2. Из неё следует изменение процесса, инструмента или договорённости — то, что можно записать и проверить. 3. Объясняет **больше одного** случая. Если ровно один — возможно, случайность, и чинить процесс под неё дорого. ## 7. Паттерны: одно и то же в третий раз Веди список проблем прошлых ретро через `manage_memory`, поднимай перед встречей через `read_memory`. **Одна и та же проблема на трёх ретро подряд — это не проблема, это свойство вашей системы.** Обсуждать надо не её, а почему два предыдущих решения не сработали. Ответ один из трёх: решение было не про причину, у него не было владельца, у владельца не было полномочий — последнее самое частое и означает, что команда назначила себе решение, требующее чужого согласия. ## 8. Решения: два-три, не десять ### 8.1 Почему не десять Ёмкость команды — примерно **одно-два изменения процесса за период**: изменение конкурирует за то же время, что и работа. Список из десяти исполняется на 10–20% и обесценивает жанр. **Два выполненных решения лучше десяти записанных.** Отбор: причины сортируй по «сколько случаев предотвращает» / «сколько стоит внедрить», верхние две-три — в работу, остальное — в отложенный список без обязательств. ### 8.2 Формулировка, которая исполняется Четыре обязательных поля; пункт без любого из них в протокол не попадает: | Поле | Требование | Плохо | Хорошо | |------|-----------|-------|--------| | Действие | Глагол совершенного вида, один шаг | «улучшить процесс ревью» | «добавить второго ревьюера на модуль биллинга» | | Владелец | Одно имя, не команда и не роль | «команда», «разработка» | «Игорь К.» | | Срок | Конкретная дата | «в следующем спринте» | «до 8 августа 2026» | | Признак выполнения | Наблюдаемый факт, проверяемый без спора | «станет быстрее» | «p90 ожидания ревью ≤ 1 рабочий день» | **Двое ответственных — это ноль ответственных.** Работу делают двое — один назван владельцем, второй участником. Признак должен различать «сделали» и «сработало»: «написали регламент» — сделали, «возвраты упали ниже 25%» — сработало. Записывай оба, проверяй второе. ### 8.3 Невыполненные решения прошлого раза — главный сигнал Это первый пункт повестки: в конце время кончится и он выпадет — удобно всем присутствующим. По каждому решению — «выполнено / не выполнено», без «частично» и «в процессе»: «в процессе» на решении с истёкшим сроком означает «не выполнено». По каждому невыполненному — один вопрос: **«что помешало»**. Не «почему не сделал» — это вопрос к человеку; «что помешало» — вопрос к системе: не было времени (изменение не заложили в план), не было полномочий (приняли не своё решение), забыли (не завели задачу), передумали (решение было слабым). ## 9. Метрики, которые портят поведение, если сделать их целью Метрика, ставшая целью, перестаёт быть измерением: оптимизируют показатель, а не то, что он отражал. | Метрика | Что произойдёт, если сделать целью | |---------|-----------------------------------| | Число завершённых задач | Задачи дробятся, крупная работа откладывается | | Velocity в очках | Оценки инфлируют: те же задачи стоят дороже, график растёт, выработка нет | | Время закрытия задачи | Задачи закрываются недоделанными и возвращаются позже | Метрики на ретро — **индикаторы для разговора, не цели**: «доля в срок 54% — повод спросить, что с оценками, а не показатель, который надо поднять до 90%». Держи их парами, где рост одной ограничивает вторую: скорость закрытия против доли возвратов, релизы против срочных правок. ## 10. Распределённая команда и часовые пояса Российская команда легко расползается на 10 часов — от Калининграда (UTC+2) до Камчатки (UTC+12): Москва — Новосибирск 4 часа, Москва — Владивосток 7. Асинхронный формат **лучше** в одном: молчаливые пишут больше, чем говорят, и первое мнение не задаёт рамку — все пишут независимо. Хуже в другом: нет диалога, где причина всплывает из спора; компенсируй вторым кругом адресных вопросов. Часть команды в переговорке, часть по одному в звонке — у удалённых нет шансов вставить слово. **Хоть один удалённо — все удалённо, каждый со своего устройства.** ## 11. Шаблон протокола Не стенограмма: страница плюс приложение фактов. Формируй через `documents`, рассылай через `message_compose`. В версии за пределы команды из разделов 3–5 убираются имена: владельцы решений — единственные, которые обязаны там быть. ## 12. Режимы отказа самой ретроспективы | Признак | Что сломалось | Что делать | |---------|---------------|-----------| | Решения не выполняются 3 периода | Решения крупные или не свои | Одно решение на период, размером в рабочий день | | Все проблемы «из-за смежников» | Зона вне влияния | Разделить «не так» на «наше» и «внешнее»; по внешнему решение одно — как узнавать раньше | --- Source: https://samreshuuu.ru/skills/me_grow_sustainably_ru 1. **Остаток денег сегодня** — счета, касса, невыплаченные деньги на площадках. Личные карты основателя — отдельно. 2. **Обязательный месячный отток** — что платится даже при нулевой выручке: аренда, ФОТ со взносами, подписки, долг, налоги, минимальные закупки. 3. **Ожидаемые поступления по датам** — не суммой за месяц, а с датами и от кого. Нет третьего — платёжный календарь не ведётся, начинай с раздела 3. ## 2. Прибыль — мнение, деньги — факт ### 2.1 Прибыльная компания не может заплатить зарплату Поставщик товара на Ozon, июнь: выручка по отгрузке 4 000 000 ₽, себестоимость −2 400 000, комиссия и логистика −800 000, ФОТ с арендой −500 000. **Прибыль +300 000 ₽.** То же в датах: | Дата | Событие | Движение | Остаток | |---|---|---|---| | 01.06 | старт | — | 900 000 | | 25.06 | предоплата поставщику за июльскую партию | −2 400 000 | **−1 500 000** | | 05.07 | зарплата | −500 000 | | | 12.07 | выплата площадки за июнь, нетто | +3 200 000 | | | 28.07 | налоги и взносы | −280 000 | | Компания зарабатывает 300 000 ₽/мес и 25 июня не может заплатить 2 400 000 ₽: разрыв 1 500 000 ₽ — впятеро больше месячной прибыли. ### 2.2 Финансовый цикл: почему рост увеличивает разрыв В примере: DIO 45, DSO 25, DPO 0 → **70 дней**. **Рост выручки на X% требует роста оборотного капитала примерно на X%.** Рост на 50% — ещё 2 800 000 ₽: при прибыли 300 000 ₽/мес копить 9 месяцев, а вырасти хочется за 3. Три рычага дешевле кредита: сократить DIO (меньше SKU и глубина закупки), сократить DSO (авансы), увеличить DPO (отсрочку часто никто не просил). Каждые 10 дней цикла — 800 000 ₽ живых денег. ## 3. Платёжный календарь Горизонт — **13 недель, обновление еженедельно в один и тот же день**: меньше не даёт времени среагировать, больше — фантазия. Колонки: дата, контрагент/статья, сумма, направление, вероятность, остаток после. ### 3.1 Правила заполнения 1. **Входящие — по платёжной дисциплине клиента, а не по дате счёта.** Платит исторически на 9-й день после срока — ставь на 9-й. 2. **Входящие сдвигай на +5 дней от обещанного, исходящие — на самую раннюю дату.** Календарь обязан ошибаться в безопасную сторону. 3. **Вероятность ниже 80% — не платёж, а надежда.** В остаток не включать. 4. **Налоги и взносы — отдельными строками с датами.** Самая частая забытая строка. 5. **Зарплатные даты неподвижны.** Просрочка зарплаты — юридическое событие, дороже пени. ### 3.2 Сигналы - минимум в горизонте ниже нуля → красный: действуй сегодня, а не в дату разрыва; - минимум ниже недельного оттока → жёлтый: никаких новых обязательств; - минимум на одной и той же неделе месяца третий раз подряд → структура цикла: двигай даты закупок и выплат, а не ищи деньги. ### 3.3 Когда разрыв виден — строго сверху вниз **1)** обзвонить дебиторку лично, скидка 3–5% за оплату сегодня дешевле факторинга; **2)** отсрочка у поставщика письменно и заранее — за день до платежа её не дают; **3)** отменить следующую закупку; **4)** срезать постоянные; **5)** заёмные — только если разрыв временный (раздел 11). ## 4. Постоянные и переменные **Переменные** растут с каждой единицей: себестоимость, комиссия площадки, эквайринг (обычно 1,5–3%), логистика, упаковка, сдельный ФОТ. **Постоянные** не зависят от выручки: аренда, оклады со взносами, бухгалтерия и 1С/МойСклад, лицензии, обслуживание долга, оплата основателя. Три ошибки классификации, из-за которых расчёт врёт: зарплата основателя не считается (бизнес дотируется твоим трудом — ставь себе фиксированную сумму, иначе безубыточность не посчитать); ФОТ считается по окладу, а не по полной стоимости работодателя (раздел 6); реклама записана в переменные, хотя переменная она только при управлении по факту продаж. Запас ниже 20%: падение выручки на пятую часть — один ушедший клиент или конец сезона — делает месяц убыточным. В этом состоянии нельзя ни нанимать, ни брать кредит. ## 5. Налоговый режим меняет экономику сильнее цены | Режим | Ставка | Лимит дохода | Кому | |---|---|---|---| | НПД (самозанятость) | 4% с физлиц, 6% с юрлиц и ИП | 2,4 млн ₽/год | одиночка без работников и без перепродажи товара | | ПСН (патент) | фиксированная стоимость патента | 20 млн ₽/год (проверяй лимит на текущий год) | ИП с доходом выше расчётного по патенту | | УСН «Доходы» | 6%, регион может снижать | 490,5 млн ₽/год | услуги, расходы ниже 60% | | УСН «Доходы минус расходы» | 15%, регион может снижать; минимальный налог 1% с доходов | 490,5 млн ₽/год | торговля и производство, расходы выше 60% | ### 5.1 Выбор объекта на УСН — одно неравенство Два уточнения переворачивают вывод: на «Доходах» налог **уменьшается на страховые взносы** (ИП без работников — вплоть до нуля, работодатель — не более чем наполовину; у ИП-одиночки с доходом до ~1 млн ₽ налог часто обнуляется целиком); на «Доходы минус расходы» есть **минимальный налог 1% с доходов** — убыточный год всё равно оплачивается, и расход засчитывается только подтверждённый документами. ### 5.2 Порог НДС — главный разрыв экономики 2026 года Услуги и производство с малой долей покупных материалов — почти всегда 5%. Перепродажа с закупкой у плательщиков НДС выше 77% выручки — 22% с вычетами. Решающий вопрос в B2B: корпоративному клиенту нужен вычет — работа без НДС для него удорожание на 22%. ### 5.3 Режим отказа при переходе порога Превышение фиксируется в месяце, когда произошло; обязанность возникает почти сразу. Признак приближения: накопленный доход с начала года превысил **15 млн ₽** — с этого момента есть месяцы: настроить учёт входящего НДС, добиться документов от поставщиков, пересчитать цены. Держи порог отдельной строкой отчёта и предупреждай **до**. ## 6. Сколько стоит сотрудник | Строка | Сумма | |---|---| | Оклад начислено | 100 000 ₽ | | НДФЛ, удерживается из оклада | −13 000 ₽ | | **Человек получает** | **87 000 ₽** | | Страховые взносы 30%, работодатель платит сверх оклада | +30 000 ₽ | | **Компания платит** | **130 000 ₽** | Взносы (актуально на 2026-07-28): базовый тариф 30% до предельной базы 2 979 000 ₽ за год, сверх — ниже. Пониженный 15% с выплат сверх 1,5 МРОТ с 2026 года — **не у всех МСП, а только у приоритетных ОКВЭД** из перечня Правительства при доле выручки от них ≥ 70%. Не обещай льготу, не проверив ОКВЭД: разница — 15 п.п. от ФОТ. Невидимое в расчётном листке: отпуск 28 дней — около +8% к годовой стоимости; больничные, обучение, простой — 3–7%; рабочее место, техника, лицензии 1С/Битрикс24 — 5 000–15 000 ₽/мес; управление — 4–6 часов в неделю на человека. **Полный множитель 1,45–1,6 к окладу**: сотрудник «за сто тысяч» стоит 145 000–160 000 ₽/мес, около 1,8 млн ₽/год, и он необратим — подписку отключают за минуту, подрядчика по договору, сотрудника нет. ## 7. Подрядчик, самозанятый или штат Штат — когда задача непрерывна и требует накопленного контекста. Подрядчик — когда результат дискретен и измерим: сайт, партия текстов, настройка учёта. Красные признаки переквалификации в трудовые отношения: **Правило:** самозанятый — исполнитель проекта, а не дешёвый сотрудник. Платишь одинаковую сумму 5-го числа за присутствие — это работник. ## 8. Когда нанимать: пять критериев одновременно **«Нанимай, когда больно»** — это факты: отказываешь платящим клиентам, время ответа выросло вдвое, пошли возвраты. Найм под ещё не пришедшую выручку делает прибыльный бизнес убыточным за квартал. ## 9. Резервный фонд **База расчёта — обязательный месячный отток, а не выручка.** | Профиль | Резерв | |---|---| | Услуги и подписки, ровная выручка, много мелких клиентов | 3 месяца оттока | | Проектный B2B, 1–3 клиента дают больше половины выручки | 6 месяцев | | Товарный, маркетплейсы, сезонность | 4–6 месяцев + сезонный запас | ## 10. «По умолчанию жив или мёртв» — это расчёт **Пример.** Остаток 1 800 000 ₽, чистый поток −300 000 ₽/мес, выручка 2 000 000 ₽/мес, валовая маржа 40% (800 000 ₽), рост 8%/мес. Дефицит сокращается: 236 000 → 167 000 → 92 000 → 12 000 → плюс на 5-м месяце, сожжено около 507 000 ₽ из 1 800 000 ₽. **По умолчанию жива, с запасом.** При росте 3%/мес дефицит сокращается на 24 000 ₽/мес, накопленный расход превысит остаток на ~7-м месяце: **по умолчанию мертва**, лечится сокращением постоянных расходов сегодня. Пересчитывай ежемесячно: главная ошибка — считать, что постоянные не растут вместе с выручкой. ## 11. Источники денег: реальная стоимость **Правило, отменяющее половину вопросов:** заёмные деньги лечат разрыв во времени, а не убыточность в юнит-экономике. План не показывает возврата из операционного потока в срок кредита — это отсрочка закрытия с процентами и личным поручительством. Признак структурного убытка: разрыв повторяется третий месяц при стабильной выручке. Заём у близких оплачивается отношениями, венчур — контролем и обязанностью расти кратно; для МСБ это не источники. ## 12. Второй способ умереть: энергия основателя Измеряй наблюдаемым: - рабочая неделя больше 55 часов четвёртую неделю подряд; - полностью нерабочей недели не было 9 месяцев и дольше; - одна и та же задача переносится третий раз без изменения условий — истощение, а не лень; - дважды за месяц не ответил клиенту в срок, назначенный самому себе; - решения принимаются, чтобы закрыть вопрос, а не потому что лучшие; - на «что хорошего будет через три месяца» нет ответа. Три признака и больше — лечи финансовыми средствами: ## 13. Формат ответа по любому решению Расход, найм, кредит, закупка, направление — формат один: 1. **Денежный поток по месяцам на 12 месяцев** — таблицей, деньги, а не прибыль. 2. **Дата и глубина минимального остатка.** 3. **Обратимость**: за сколько дней и денег откатывается — обратимо / дорого / необратимо. 4. **Одно проверяемое утверждение** с числом и датой проверки. 5. **Вердикт**: *делай* / *делай в урезанном виде (что урезать)* / *отложи до условия с числом* / *не делай (что вместо)*. Порог НДС, приближение разрыва, отрицательный запас прочности назови в самом ответе числом и датой проверки; структуру расходов, режим, дни цикла и профиль резерва — через `manage_memory`. --- Source: https://samreshuuu.ru/skills/me_company_values_ru ## 1. Тест инверсии: ценность или лозунг Единственный быстрый фильтр: **заявил бы кто-нибудь в здравом уме обратное?** - «Мы за честность», «мы за качество», «мы за клиента» → обратного не заявит никто. Это не ценности, это гигиена. Вычёркивай. - «Принимаем текучку, если это делает продукт лучше» → обратное («удерживаем людей даже ценой продукта») — реальная позиция многих компаний. Это ценность. - «Ни одного созвона без повестки за сутки» → обратное («созвонимся, разберёмся на месте») — тоже нормальная позиция. Это ценность. Ценность живёт только там, где есть **отвергнутая альтернатива**. Нет альтернативы — это лозунг, он не изменит ни одного решения. Второй фильтр — **цена**: что мы теряем, соблюдая это? Ответ «ничего» означает, что ценности нет. Настоящая в момент применения стоит денег, времени или человека. ## 2. Вопросы, которые дают неочевидный ответ Вопросы 1, 3, 6, 8 дают неочевидный ответ чаще прочих. Если после всех восьми осталась одна гигиена — культура ещё не сформировалась, честнее написать 2 ценности, чем выдумать 5. ## 3. Формулировка: ситуация, поведение, цена Схема одна: Пример: > **Клиент узнаёт о проблеме от нас.** > Обнаружив сбой, испортивший клиенту данные, мы пишем ему сами в тот же день — даже если он не заметил и, возможно, не заметит. Даже когда это стоит расторжения договора. > В работе: письмо уходит до того, как починили; в нём что сломалось, кого затронуло, что делаем; извинение — одна строка, остальное факты. > Антипаттерн: «сначала починим, потом напишем» — так письмо не уходит никогда. Пункт «даже когда стоит Z» обязателен: без него формулировка не проходит тест инверсии. ### 3.1 Сколько ценностей 3–5. Меньше трёх — не покрывает конфликтующие ситуации. Больше пяти никто не помнит, значит ни одна не работает при решении. Проверка: попроси перечислить их по памяти через неделю. ## 4. Чужие наборы как справочник, а не каркас Не переписывай чужие ценности. Смотри на форму — конкретность и наличие цены. **Gumroad** (Сахил Лавингия), 4 пункта: «нас судят по работе» (текучка допустима, если продукт лучше); «ищи суперлинейность»; «каждый — генеральный директор своей функции»; «осмелься быть открытым» (документы публичны, зарплаты раскрыты, совещаний нет). У каждого пункта видна цена: они отказались от менеджмента и совещаний, заплатив скоростью координации. Переносится формат «принимаем издержку X ради Y», а не содержание: открытость зарплат в команде, где двое в штате, а трое самозанятые, даёт не симметрию, а конфликт — сравниваются несопоставимые формы оплаты. ## 5. Где ценности работают Ценность существует ровно в пяти точках. Не задета ни одна — есть только текст на сайте. ### 5.1 Найм **Ответ «у меня такого не было» — валидный сигнал**, а не повод помогать кандидату придумать историю: помог — потерял данные. Культурное несоответствие — законный отказ, но формулируй его через поведение («работает только синхронно, у нас 6 часов разницы»), а не через личность. ### 5.2 Обратная связь Раз в 2 недели, письменно: наблюдение → к какой ценности относится → что сделать иначе. Без привязки к ценности обратная связь читается как вкусовщина и придирка. ### 5.3 Повышение Сформулируй заранее «за что у нас повышают» — 3–4 наблюдаемых признака поведения, не только цифры. Если человек с лучшими цифрами и худшим поведением получает повышение, набор ценностей умирает в этот день. ### 5.4 Увольнение Самая читаемая точка: команда узнаёт настоящие ценности из ответа на вопрос **кого уволили последним и за что**. Сильный по результату остался при нарушении ценности — все поняли, что работает только результат. Поэтому вопрос «за что уволю приносящего деньги» стоит первым. ### 5.5 Разбор инцидента Без поиска виновного: что произошло по минутам → какой был сигнал и кто его видел → почему решение выглядело разумным тогда → что меняем в процессе. Слово «невнимательность» в выводах означает, что разбор не состоялся: она не лечится требованием быть внимательнее. ## 6. Часовые пояса как проектное ограничение В России 11 часовых зон. Калининград — UTC+2 (МСК−1), Камчатка — UTC+12 (МСК+9): между крайними точками **10 часов**. Это не нюанс коммуникации, а ограничение, из которого выводятся правила команды. **Окно пересечения.** При рабочем дне 8 часов и разнице D часов окно совместной работы = `max(0, 8 − D)`. | Пара городов | Разница | Окно | |---|---|---| | Москва — Екатеринбург | 2 ч | 6 ч | | Москва — Новосибирск | 4 ч | 4 ч | | Москва — Владивосток | 7 ч | 1 ч | | Калининград — Владивосток | 8 ч | 0 ч | Пороги: - **≥ 4 часов** — обычная удалёнка, синхронные встречи возможны. - **1–3 часа** — окно дефицитно. Тратить только на то, что нельзя написать: конфликт, увольнение, переговоры, разбор инцидента. Статусы и демо — в записи. - **0 часов** — асинхронность не выбор, а физика. Синхронная встреча означает, что кто-то работает ночью: либо оплачено, либо не назначается. Если общего окна нет, а в культуре записано «отвечаем быстро», правило нарушается гарантированно и учит команду, что правила можно не соблюдать. ### 6.1 Что закрепить письменно про асинхронность - **Норма ответа по каналам**: общий канал — до конца следующего рабочего дня; срочное — 2 часа в рабочее окно; звонок — только инцидент. Норма считается в **рабочих днях получателя**, иначе Камчатка всегда «опаздывает». - **Решение фиксирует письменно тот, кто его принял**, в тот же день. Ненаписанное решение через неделю не существует. - **Встреча без повестки и письменного итога не считается состоявшейся.** - **Право не отвечать вне своих часов** — прямым текстом, за подписью основателя. Иначе не работает: смотрят на его поведение, а не на текст. ### 6.2 Что нельзя переводить в письменный формат Нельзя: увольнение, разбор личного конфликта, первую негативную обратную связь, сообщение о снижении дохода. Причина не в вежливости: в письме не видно реакции, адресат достраивает худшую интерпретацию, а вы узнаёте об этом через две недели или из заявления. Эти четыре — голосом, письменное резюме после. Туда же: зарплаты конкретных людей в общем канале, оценка отсутствующего в переписке третьего лица и любая формулировка, которую вы не готовы увидеть в материалах трудового спора. ## 7. Документы: юридический слой и фактический Юридический слой отвечает на «что можно предъявить в суде», фактический — «как люди себя ведут». Культура умирает, когда слои противоречат: договор говорит «9:00–18:00 в офисе», а команда распределённая и асинхронная. **Трудовой договор** фиксирует функцию, оплату, место работы, режим; ценности в него не пишут. **Локальные нормативные акты** (правила внутреннего распорядка, положение о дистанционной работе, регламент коммуникаций) — слой, куда переезжают правила асинхронной работы; с ЛНА знакомят под подпись. ### 7.1 Три нормы главы 49.1 ТК РФ - **Режим рабочего времени** (ст. 312.4): если он не установлен коллективным договором, ЛНА или трудовым договором, дистанционный работник устанавливает его **сам**. Async — состояние по умолчанию, фиксированные часы надо записать явно. Время взаимодействия с работодателем входит в рабочее. - **Порядок взаимодействия** (ст. 312.3) и **основание увольнения** (ст. 312.8): невыход на связь по рабочим вопросам без уважительной причины **более двух рабочих дней подряд** со дня запроса — основание для расторжения по инициативе работодателя, **кроме случая, когда более длительный срок установлен вашим порядком взаимодействия**. Команда с разницей 7–8 часов и нормой ответа «до конца следующего дня» обязана прописать больший срок, иначе действуют два дня. - **Оборудование** (ст. 312.6): работодатель обеспечивает оборудованием и ПО; при использовании личного — с его согласия — выплачивает компенсацию и возмещает расходы в размере по ЛНА или договору. Молчание читается как «работник платит сам» и первым ломает заявленную заботу. ## 8. Форма оформления меняет культуру Команда из 8 человек обычно собрана из трёх разных форм, и это влияет на культуру сильнее любого документа. | Форма | Что даёт культуре | Чем ломает | |---|---|---| | Штат | Общий календарь, отпуск, обучение, длинный горизонт | Дороже всего; медленное расставание; сильнее регламент | | ГПХ | Быстрый старт под задачу | Нет режима работы и подчинённости — нельзя требовать присутствия «в окне»; человек вне ритуалов команды | | Самозанятый (НПД) | Низкая нагрузка, простые расчёты | Лимит годового дохода; уходит в любой день; **нельзя оформлять по НПД своего бывшего работника, если с увольнения прошло менее двух лет** (ФЗ о налоге на профессиональный доход) | | ИП-подрядчик | Гибко для долгих ролей | Тот же риск переквалификации при постоянном характере работы | ### 8.1 Главный риск Гражданско-правовой договор, фактически регулирующий трудовые отношения, — нарушение по ч. 4 ст. 5.27 КоАП РФ: штраф на юрлицо 50 000–100 000 ₽, на должностное лицо 10 000–20 000 ₽, на ИП 5 000–10 000 ₽ (актуально на 2026-07-28). Отношения могут признать трудовыми с доначислением НДФЛ и взносов. С 1 января 2025 года Роструд ведёт общедоступный реестр работодателей с выявленной нелегальной занятостью. **Признаки, по которым отношения читаются как трудовые** (они же — признаки культуры на неподходящей форме): работает по вашему графику и регламенту, получает фиксированную сумму дважды в месяц независимо от результата, пользуется вашим оборудованием и почтой, вы его единственный заказчик, участвует во всех ритуалах. **Вывод культурный, а не юридический:** хотите, чтобы человек ходил на дейли, соблюдал часы и рос по грейдам, — это штат; другая форма создаёт враньё, которое команда видит. Человек автономен и сдаёт результат — не тащите его в ритуалы штата. ## 9. Расхождения заявленного и реального Диагностируй по последнему кварталу, а не по ощущениям. | Заявлено | Что делают на самом деле | Признак, по которому видно | |---|---|---| | «Право на ошибку» | Об ошибке узнают от клиента | За 3 месяца ноль сообщений об инцидентах от исполнителей | | «Прозрачность» | Решения принимаются в личке основателя | У ключевых решений квартала нет письменного следа в общем канале | | «Асинхронность» | Основатель пишет в 23:00 и ждёт ответа | Медиана ответа команды вечером < 20 минут | | «Люди важнее прибыли» | Токсичный, но результативный не уволен | Все увольнения были по результату, ни одного по поведению | | «Каждый — CEO своей функции» | Любая трата согласуется | Нет ни одного порога самостоятельных решений в рублях | | «Обучение и рост» | Бюджет не потрачен | 0 ₽ по статье за год при заявленных 50 000 ₽ на человека | | «Баланс работы и жизни» | Отпуска переносятся | Средний неотгулянный остаток > 20 дней | Каждая строка правой колонки — **проверяемый детектор**. Собранные вместе, они и есть ежеквартальный аудит культуры: час работы, без опросов. ## 10. Как пересматривать ценности Раз в год плановый просмотр плюс внеплановый по триггеру: численность выросла в 1,5 раза; первое увольнение по поведению; первый нанятый руководитель; переход к распределённой работе; уход живого носителя ценности; столкновение двух ценностей без ясного приоритета. **Процедура:** каждой ценности три вопроса — какое решение за год она изменила; кто её нарушил и что было дальше; какая ситуация показала нехватку формулировки. Не изменившая ни одного решения удаляется, а не смягчается: мёртвая ценность обесценивает живые. Изменение объявляется публично с причиной — тихая правка документа читается как «нам всё равно». ## 11. Шаблон документа о ценностях Отдай готовый файл через `documents`, заполненный материалом пользователя. ## 12. Протокол работы Хочет 5 красивых ценностей за один заход — скажи, что получится плакат, и предложи начать с двух настоящих. --- Source: https://samreshuuu.ru/skills/me_pricing_ru ## Что спросить до первого расчёта Пять вещей; чего пользователь не знает — задай допущением и посчитай базовый и пессимистичный сценарий. 1. **Что продаётся** — товар, услуга с человеко-часами, подписка, разовый цифровой продукт: от этого зависит модель. 2. **Канал** — сайт, маркетплейс, B2B-договор, розница. Съедает 5–40% цены и закладывается до расчёта, а не после. 3. **Система налогообложения** — и платит ли НДС покупатель. 4. **Переменные на единицу** и **постоянные в месяц**: без первого нет маржинальности, без второго — безубыточности. 5. **Цель** — ноль, максимум прибыли или доля рынка: разные цели дают разные цены при одинаковых затратах. ## Наценка и маржа — не одно и то же Половина ошибок начинается здесь: наценка считается от себестоимости, маржинальность — от цены. Товар за 600 ₽ с наценкой 50% стоит 900 ₽, но маржинальность у него 33,3%. Чтобы получить маржу 50%, наценка должна быть 100%, то есть цена 1 200 ₽. | Наценка | 20% | 30% | 50% | 100% | 150% | 300% | |---|---|---|---|---|---|---| | Маржа | 16,7% | 23,1% | 33,3% | 50% | 60% | 75% | ## Модель 1. Затратная (cost-plus) Для производства, работ с материалами, услуг с понятным фондом времени. Формула включает целевую загрузку, иначе простой оплачивается из кармана владельца. **Разбор.** Мастерская мебели: материалы 18 000 ₽, сдельная оплата 7 000 ₽, постоянные 240 000 ₽/мес, план 12 изделий, целевая маржа 25%. Переменные = 25 000 ₽, постоянные на единицу = 20 000 ₽, себестоимость 45 000 ₽, цена = 45 000 / 0,75 = **60 000 ₽**. ## Модель 2. От ценности (value-based) **Разбор.** Сервис выгрузки товаров на маркетплейсы. Сейчас клиент держит контент-менеджера 4 часа в неделю: 17 часов × 700 ₽ = 11 900 ₽/мес. Плюс 2 карточки в месяц уходят с неверной ценой по 4 000 ₽ = 8 000 ₽. Экономическая ценность ≈ 19 900 ₽/мес. При доле 0,2 цена = **3 980 ₽/мес** → 3 990 ₽: клиент видит возврат в 5 раз и не торгуется. При доле 0,5 (9 950 ₽) начинается сравнение с наймом человека, и цикл сделки удлиняется вдвое. **Правило разговора:** до того как назвать цену, заставь клиента вслух назвать стоимость текущего способа. Не может — возвращайся к затратной модели. ## Модель 3. Рыночный коридор **Ловушка:** у конкурента на витрине 2 490 ₽, а внедрение отдельно 30 000 ₽. Сравнивай стоимость владения за 12 месяцев, а не витрины. ## Модель 4. Подписка и тарифная сетка Сначала решай **за что считаем** — метрика биллинга важнее числа. Хорошая растёт вместе с ценностью и не штрафует за использование продукта: активные сотрудники, обработанные заказы, подключённые магазины. Число API-вызовов почти всегда плохо — клиент не оценит его заранее и боится счёта. ### Как проектировать три тарифа Три плана, не пять, с соотношением цен **1 : 3 : 9** (старший может быть «по запросу»). Средний — целевой, в него попадает 55–70% клиентов; младший нужен, чтобы средний выглядел разумно; старший — чтобы у среднего был потолок сверху. **Разбор для сервиса на 3 990 ₽ из модели 2:** 1 490 ₽ (1 магазин, 1 пользователь) / 4 490 ₽ (5 магазинов, 5 пользователей, интеграция с МойСклад) / 12 900 ₽ (без ограничений, выгрузка в 1С, приоритетная поддержка). ## Эффект нулевой цены Переход 0 → 1 ₽ отсекает больше людей, чем последующее 1 000 → 2 000 ₽. Бери деньги сразу: пятьдесят человек, из которых платит один, дают о продукте больше знания, чем пятьсот неплатящих. Если продукт уже раздан, действующим оставь доступ, плату включи для новых. ## Юнит-экономика: пять чисел, без которых цена не проверена ### Пороги, по которым выносится вердикт | Метрика | Здорово | Терпимо | Чинить цену | |---|---|---|---| | LTV / CAC | ≥ 3 | 2–3 | < 2 | | Окупаемость CAC | ≤ 6 мес | 6–12 мес | > 12 мес | | Маржинальность (услуги, ПО) | ≥ 70% | 50–70% | < 50% | | Маржинальность (товар, маркетплейс) | ≥ 25% | 15–25% | < 15% | | Месячный отток (B2B-подписка МСБ) | ≤ 3% | 3–6% | > 6% | **Разбор.** Подписка 3 990 ₽/мес, переменные 800 ₽ → маржинальность 80%. Реклама 120 000 ₽/мес даёт 15 клиентов → CAC = 8 000 ₽. Отток 4%/мес → срок жизни 25 мес. LTV = 3 990 × 0,8 × 25 = **79 800 ₽**, LTV/CAC = 10, окупаемость CAC = 8 000 / 3 192 = **2,5 месяца**, BEP при постоянных 250 000 ₽/мес = **79 клиентов**. Вердикт: цена занижена — при LTV/CAC = 10 бизнес недозарабатывает, а не растёт. **Обратный признак:** LTV/CAC = 1,4 при марже 80% — проблема в цене или оттоке, а не в затратах. Посчитай оба рычага, «+30% к цене» и «−1 п.п. оттока», и покажи, какой сильнее. ### Насколько можно двигать цену При марже 30% скидка 10 п.п. требует роста продаж на 10/(30−10) = **50%**, скидка 20 п.п. — **удвоения**. Повышение цены на 15 п.п. при марже 70% выгодно, пока отток не превысил 15/85 = **17,6%**. Большинство скидочных кампаний в МСБ проваливают именно этот тест. ## Налоги: цена, которую видит клиент, и деньги, которые остаются - Базовая ставка **НДС — 22%** с 1 января 2026 года; льготные 10% и 0% сохранены для своих категорий. - Порог освобождения от НДС на УСН — **20 млн ₽ дохода за предыдущий год** (для 2026 года). Дальнейшая траектория порога источниками описывается по-разному: одни говорят о поэтапном снижении после 2026 года, другие — о сохранении 20 млн ₽. Не называй клиенту цифру на 2027 и далее как решённую: проверяй на момент разговора и планируй сценарно от двух вариантов. - Спецставки НДС на УСН **5% и 7%** сохранены, без вычетов входящего НДС; выбранная ставка применяется минимум 12 кварталов. - НПД: **4% с физлиц, 6% с юрлиц**, лимит **2,4 млн ₽ в год**, режим продлён до 31.12.2028. При ставке 22% НДС «сидит» в цене как P × 22/122 ≈ 18,03% чека: витрина 100 000 ₽ оставляет 81 967 ₽ выручки без НДС. ### Сравнение режимов на одном примере Услуга 100 000 ₽, прямые расходы 30 000 ₽: | Режим | Что видит клиент | Налог | Остаётся | |---|---|---|---| | НПД, клиент-юрлицо | 100 000 ₽ | 6 000 ₽ | 64 000 ₽ | | УСН «доходы» 6%, без НДС | 100 000 ₽ | 6 000 ₽ | 64 000 ₽ | | УСН «доходы−расходы» 15% | 100 000 ₽ | 10 500 ₽ | 59 500 ₽ | | УСН + НДС 5% | 105 000 ₽ | 5 000 + 6 000 ₽ | 64 000 ₽ | | ОСНО, НДС 22% | 122 000 ₽ | 22 000 ₽ НДС + налог на прибыль | зависит от вычетов | **Режим отказа:** ИП на УСН «доходы» подписал годовой договор с фиксированной ценой, перевалил порог и стал плательщиком НДС — оговорки нет, налог вынимается из собственной маржи. **В долгосрочных договорах рекомендуй формулировку «цена без учёта НДС; НДС начисляется сверх по действующей ставке».** ## Цена на полке маркетплейса Здесь чаще всего уходят в минус: цену считают наценкой от себестоимости, а комиссия, логистика и налог берутся с цены продажи. Формула решается относительно цены. `C` — закупка единицы; `L_эфф` — логистика с поправкой на выкуп; `S` — хранение и приёмка; `F` — упаковка, маркировка, брак; `k_ком` — комиссия площадки; `k_экв` — эквайринг; `k_рек` — ДРР; `k_налог` — ставка **к полной цене продажи**; `m_цель` — целевая маржинальность. Все `k` и `m` — доли, не проценты. ### Логистика с поправкой на выкуп Выкуп `v` — 25–40% для одежды и обуви, 80%+ для техники: При прямой логистике 60 ₽, обратной 50 ₽ и выкупе 35%: L_эфф = 171 + 93 = **264 ₽** на проданный товар вместо 60 ₽. Расхождение в 4 раза — типичная причина «продаж много, денег нет». ### Разобранный пример Закупка 700 ₽, комиссия 17%, эквайринг 2%, ДРР 8%, УСН «доходы» 6%, хранение 15 ₽, упаковка и брак 25 ₽, логистика 264 ₽ (как выше), целевая маржа 15%. Знаменатель = 1 − 0,17 − 0,02 − 0,08 − 0,06 − 0,15 = **0,52**. Числитель = 700 + 264 + 15 + 25 = **1 004 ₽**. P = 1 004 / 0,52 = **1 931 ₽**, ставим 1 990 ₽. Проверка обратным ходом: 1 990 − 338 − 40 − 159 − 119 − 1 004 = **330 ₽**, 16,6%. Если рыночная цена в категории 1 490 ₽, при той же себестоимости выходит 1 490 × 0,52 − 1 004 = **−229 ₽ на единицу**. Вывод не «снизим маржу», а «этот товар с этой закупкой в этой категории не продаётся». ### Что учесть дополнительно 1. **Налог берётся с цены до удержания комиссии.** На УСН «доходы» база — сумма, заплаченная покупателем, а не выплата площадки. Ошибка стоит 6% выручки. 2. **Скидочные механики.** Скидка постоянного покупателя на Wildberries снижает витрину, но не приходит напрямую из твоего кармана: юнит-экономику считай от цены продавца. Промо-акции площадки, наоборот, режут выплату. 3. **Комиссии меняются несколько раз в год и зависят от категории, схемы (FBO/FBS/DBS) и объёма — не запоминай их.** Коридор на 2026-07-28: WB примерно 5–23%, Ozon примерно 4–22%, Яндекс Маркет как правило ниже; ставку бери из личного кабинета или тарифной страницы площадки через `web_fetch`. `k_ком` — параметр, не константа. 4. **Отдай пороговую цену**: `P_min = (C + L_эфф + S + F) / (1 − k_ком − k_экв − k_рек − k_налог)` — это число продавец держит в голове во время акций. Детали API площадок бери через `read_skill` (`ozon_guide_ru`, `wildberries_guide_ru`, `yandex_market_guide_ru`), комиссии — из `marketplace_commissions_ru`. ## Психологические границы цены Это способ поставить цену внутрь уже существующей у клиента категории «сколько такое стоит», а не украшение. 1. **Границы категорий в рознице РФ** идут по круглым числам: 500, 1 000, 3 000, 5 000, 10 000, 30 000, 50 000, 100 000 ₽. Цена 10 200 ₽ продаётся хуже 9 900 ₽, а 10 900 ₽ — почти как 12 000 ₽. Расчёт дал 10 200 ₽ — либо 9 990 ₽ и ищи 2% в себестоимости, либо 11 900 ₽ и добавляй видимую ценность. 2. **Окончания на 90/99** работают в масс-маркете, но вредят в B2B и премиуме: 250 000 ₽ читается как обдуманная цена, 249 990 ₽ — как уловка. 3. **Якорь.** Первое названное число задаёт шкалу — показывай старший тариф или стоимость альтернативы до своей цены. 4. **Приманка.** Если 1 490 и 4 490 плохо перетекают, добавь третий план за 12 900 ₽: доля среднего вырастет без изменения его цены. 5. **Скидка меньше 10% не замечается**, больше 30% — ставит под сомнение исходную цену. 6. **Дробление платежа.** «19 900 ₽ в год» и «1 990 ₽ в месяц» воспринимаются как разные продукты: месяц проходит легче, год даёт кэш. ## Повышение цены действующим клиентам Цена, не пересматривавшаяся два года, при накопленной инфляции — это молчаливое снижение. **Когда повышать (хватает одного признака):** закрываешь больше 70% входящих сделок без торга; о цене вообще не спорят; LTV/CAC > 5; себестоимость выросла больше чем на 10% с последнего пересмотра; появилась функция, которую клиенты называют причиной оставаться. ## Режимы отказа: как понять, что цена неправильная | Признак | Диагноз | Что делать | |---|---|---| | Никто не торгуется, конверсия > 70% | Цена ниже рынка | Поднять на 20–30% новым, замерить конверсию | | Торгуются все, сделки идут месяцами | Ценность не объяснена | Пройти модель 2 с клиентом, цену не снижать | | Прибыль есть, денег на счету нет | Покрыты переменные, но не постоянные | Пересчитать BEP и цену при плане × 0,7 | | Продажи растут, прибыль падает | Не заложен канал | Пересчитать по формуле полки, найти убыточные SKU | | Скидки дают всем | Прайс перестал существовать | Скидка только за объём, предоплату или срок | | Клиенты уходят на 2–3 месяце | Дело не в цене, а в онбординге | Цену не трогать, чинить активацию | ## Математика финансовой независимости Цель 250 000 ₽/мес чистыми при марже 80%: цена 990 ₽ — 316 клиентов, 3 990 ₽ — 79, 12 900 ₽ — 25, 49 000 ₽ — 7. Показывай эту лесенку всегда: разница между «найти 79 компаний» и «найти 25» меняет разговор о цене быстрее аргументов. ## Как считать и что отдавать Итоговый ответ содержит: **цену** с психологическим округлением; **формулу с подстановкой**; **юнит-экономику** при этой цене (маржинальность, BEP, окупаемость CAC); **порог убыточности**; **тарифную сетку**, если продукт её допускает; **список допущений**; **условие пересмотра**. Таблицы вариантов выгружай через `documents` в xlsx, структуру цен сохраняй через `manage_memory`, напоминание о пересмотре ставь через `manage_task`. --- Source: https://samreshuuu.ru/skills/legal_translation_ru # Юридический перевод (EN-RU) ## Быстрый справочник Юридический перевод требует не дословной передачи текста, а точной передачи правового смысла. Термин в одной юрисдикции может не иметь прямого эквивалента в другой. Приоритет: **правовой смысл > буквальный перевод**. # БЛОК 1: Принципы перевода ## Иерархия приоритетов 1. **Правовой смысл** — сохранение юридических последствий 2. **Терминологическая точность** — использование устоявшихся эквивалентов 3. **Структурная целостность** — сохранение нумерации, абзацев, ссылок 4. **Стилистическое соответствие** — деловой регистр, без разговорных форм ## Режимы перевода | Режим | Описание | Когда использовать | |-------|----------|-------------------| | **inline** | перевод (оригинал) | Для внутреннего использования, учебных целей | | **target_only** | Только перевод | Для официальных документов, нотариального заверения | | **footnotes** | Сноски с терминами | Для сложных документов с множеством терминов | # БЛОК 2: Глоссарий — Обязательственное право | Русский | English | Контекст / ГК РФ | |---------|---------|------------------| | неустойка | penalty / liquidated damages | ст. 330 ГК РФ | | штраф | fine / penalty | Фиксированная сумма | | пени | late payment interest / penalty interest | За просрочку, % от суммы | | залог | pledge / collateral | ст. 334 ГК РФ | | поручительство | suretyship / guarantee | ст. 361 ГК РФ | | цессия | assignment (of rights) | ст. 382 ГК РФ | | уступка права требования | assignment of receivables | Синоним цессии | | обеспечительный платеж | security deposit | ст. 381.1 ГК РФ | | задаток | earnest money / deposit | ст. 380 ГК РФ | | аванс | advance payment | Без обеспечительной функции | | предоплата | prepayment | Синоним аванса | # БЛОК 3: Глоссарий — Договорное право | Русский | English | Контекст | |---------|---------|----------| | расторжение договора | termination of contract | Полное прекращение | | односторонний отказ | unilateral withdrawal | ст. 450.1 ГК РФ | | существенные условия | essential terms / material terms | Без них договор недействителен | | предмет договора | subject matter of the contract | Обязательное условие | | права и обязанности | rights and obligations | Стандартный раздел | | форс-мажор | force majeure | Обстоятельства непреодолимой силы | | обстоятельства непреодолимой силы | circumstances of insurmountable force | Полный термин | | ответственность сторон | liability of the parties | Раздел об ответственности | | срок действия договора | term of the contract | Период действия | | порядок расчетов | payment procedure | Раздел об оплате | | конфиденциальность | confidentiality | NDA условия | | интеллектуальная собственность | intellectual property | IP права | | гарантийные обязательства | warranty obligations | Гарантии качества | | приемка работ | acceptance of work | Подписание акта | | акт приема-передачи | acceptance certificate | Двусторонний документ | # БЛОК 4: Глоссарий — Процессуальное право | Русский | English | Контекст | |---------|---------|----------| | претензия | claim / complaint | Досудебное урегулирование | | арбитражный суд | arbitration court | Суд для юрлиц в РФ | | третейский суд | arbitral tribunal | Негосударственный арбитраж | | подсудность | jurisdiction | Определение суда | | исковая давность | statute of limitations | Сроки исковой защиты | | солидарная ответственность | joint and several liability | Каждый отвечает за всё | | субсидиарная ответственность | subsidiary liability | Дополнительная ответственность | # БЛОК 5: Глоссарий — Общие термины | Русский | English | Контекст | |---------|---------|----------| | добросовестность | good faith | ст. 10 ГК РФ | | разумность | reasonableness | Оценочная категория | | публичная оферта | public offer | ст. 437 ГК РФ | | акцепт | acceptance (of offer) | Согласие с офертой | | оферта | offer | Предложение заключить договор | | правоспособность | legal capacity | Способность иметь права | | дееспособность | legal competence | Способность осуществлять права | # БЛОК 6: Особенности EN→RU ## Термины без прямых эквивалентов | English | Варианты перевода | Рекомендация | |---------|-------------------|--------------| | consideration | встречное предоставление | Объяснить в скобках: нет в РФ | | estoppel | эстоппель | Транслитерация + пояснение | | tort | деликт | Внедоговорное обязательство | | injunction | судебный запрет | Обеспечительная мера | | specific performance | исполнение в натуре | ст. 308.3 ГК РФ | | breach of contract | нарушение договора | Неисполнение/ненадлежащее | | indemnity | возмещение убытков | Отличать от indemnification | | waiver | отказ от права | Добровольный отказ | | covenant | обязательство / ковенант | В банковских — транслит | | representation | заверение | representations and warranties | | warranty | гарантия | Часть заверений | ## Ложные друзья переводчика | English | НЕ переводить как | Правильный перевод | |---------|-------------------|-------------------| | actual | актуальный | фактический, реальный | | pretend | претендовать | притворяться | | speculation | спекуляция | предположение | | accurate | аккуратный | точный | | original | оригинальный | подлинный, первоначальный | # БЛОК 7: Особенности RU→EN ## Российские реалии | Русский | English | Примечание | |---------|---------|------------| | ООО | LLC (Limited Liability Company) | Указать: under Russian law | | АО | JSC (Joint Stock Company) | Public/Private JSC | | ИП | Sole Proprietor / Individual Entrepreneur | IE для краткости | | ОГРН | Primary State Registration Number | PSRN или оставить OGRN | | ИНН | Taxpayer Identification Number | TIN | | КПП | Tax Registration Reason Code | Оставить KPP | | ЕГРЮЛ | Unified State Register of Legal Entities | USRLE | | нотариус | notary public | Не solicitor | | доверенность | power of attorney | POA | | печать | corporate seal / stamp | В РФ не обязательна с 2015 | ## Названия судов | Русский | English | |---------|---------| | Арбитражный суд | Commercial Court / Arbitrazh Court | | Суд общей юрисдикции | Court of General Jurisdiction | | Верховный Суд РФ | Supreme Court of the Russian Federation | | Конституционный Суд РФ | Constitutional Court of the Russian Federation | # БЛОК 8: Структурные элементы ## Стандартные разделы договора | Русский | English | |---------|---------| | ДОГОВОР № | AGREEMENT No. / CONTRACT No. | | Преамбула | Preamble / Recitals | | 1. Предмет договора | 1. Subject Matter | | 2. Права и обязанности сторон | 2. Rights and Obligations of the Parties | | 3. Порядок расчетов | 3. Payment Terms / Payment Procedure | | 4. Ответственность сторон | 4. Liability of the Parties | | 5. Форс-мажор | 5. Force Majeure | | 6. Разрешение споров | 6. Dispute Resolution | | 7. Срок действия и расторжение | 7. Term and Termination | | 8. Заключительные положения | 8. Miscellaneous / General Provisions | | 9. Реквизиты и подписи сторон | 9. Details and Signatures of the Parties | ## Стандартные формулировки | Русский | English | |---------|---------| | Настоящий Договор вступает в силу с момента подписания | This Agreement shall enter into force upon signing | | Договор составлен в двух экземплярах | The Agreement is executed in two counterparts | | Все изменения и дополнения действительны в письменной форме | All amendments and supplements shall be valid if made in writing | | Стороны пришли к соглашению о нижеследующем | The Parties have agreed as follows | # БЛОК 9: Чек-лист качества ## Перед сдачей перевода - [ ] Все термины из глоссария использованы последовательно - [ ] Нумерация разделов и пунктов сохранена - [ ] Ссылки на статьи законов корректны (ст. → Art. / Section) - [ ] Названия сторон единообразны по всему тексту - [ ] Даты в правильном формате (DD.MM.YYYY → MM/DD/YYYY или словами) - [ ] Суммы с указанием валюты - [ ] Реквизиты сторон переведены корректно - [ ] Нет смешения British/American English - [ ] Проверены ложные друзья переводчика ## Частые ошибки | Ошибка | Исправление | |--------|-------------| | Дословный перевод юридических клише | Использовать устоявшиеся эквиваленты | | Непоследовательность терминологии | Один термин = один перевод по всему тексту | | Потеря структуры | Сохранять нумерацию и форматирование | | Перевод названий без пояснений | LLC under Russian law, не просто LLC | # БЛОК 10: Инструкции для агента ## При переводе EN→RU По умолчанию используй режим **inline**: `перевод (оригинал)` для ключевых терминов. Для официального перевода используй **target_only** — только целевой язык. *Skill-файл составлен на основе практики юридического перевода и сопоставления правовых систем РФ и common law. Февраль 2026.* --- Source: https://samreshuuu.ru/skills/pr_code_review # Эксперт по ревью Pull Request'ов ## Методология ревью ### Фаза 1: Понимание контекста Перед проверкой кода установи контекст: 1. **Заголовок и описание PR** — Какая заявленная цель? 2. **Связанные задачи / тикеты** — Какую проблему решаем? 3. **Размер диффа** — Маленький (<100 строк), Средний (100–500), Большой (500+) 4. **Изменённые файлы** — Какие области кодовой базы затронуты? 5. **Опыт автора** — Первый контрибьютор или основной мейнтейнер? ### Фаза 2: Архитектурный обзор | Проверка | Вопрос | |----------|--------| | Соответствие дизайну | Вписывается ли изменение в текущую архитектуру? | | Скоуп | Сделано больше или меньше, чем требовалось? | | Альтернативы | Есть ли более простой подход для достижения той же цели? | | Обратная совместимость | Ломает ли это обратную совместимость? | | Зависимости | Обоснованы ли и проверены ли новые зависимости? | ### Фаза 3: Проверка на уровне кода Анализируй каждый изменённый файл систематически: #### Корректность - Логические ошибки, ошибки на единицу (off-by-one), обработка null/undefined - Граничные случаи: пустой ввод, пограничные значения, конкурентный доступ - Обработка ошибок: перехватываются ли исключения и обрабатываются ли правильно? - Управление состоянием: гонки данных, устаревшие данные, утечки памяти #### Безопасность (с учётом OWASP) - **Инъекции**: SQL, XSS, command injection, SSRF - **Аутентификация/Авторизация**: повышение привилегий, отсутствие проверок доступа - **Утечка данных**: секреты в коде, логирование персональных данных, избыточные права API - **Валидация входных данных**: недоверенные данные на границах системы - **Криптография**: слабые алгоритмы, захардкоженные ключи, небезопасная генерация случайных чисел #### Производительность - N+1 запросы, отсутствие индексов, ненужные обращения к БД - Неограниченные циклы, экспоненциальные алгоритмы на пользовательском вводе - Память: большие аллокации, незакрытые ресурсы, удерживаемые ссылки - Сеть: многословные API, отсутствие пагинации, нет таймаута/ретрая #### Поддерживаемость - Нейминг: передают ли имена переменных/функций намерение? - Сложность: цикломатическая сложность, глубокая вложенность условий - DRY: скопированная логика, которую стоит вынести - Принцип единственной ответственности: делает ли каждая функция/класс одно дело? - Мёртвый код: недостижимые ветки, неиспользуемые импорты/переменные #### Тестирование - Покрыты ли тестами новые/изменённые пути кода? - Проверяют ли тесты поведение, а не реализацию? - Протестированы ли граничные случаи и пути ошибок? - Детерминированы ли тесты (нет нестабильных утверждений по таймингу/порядку)? - Недостающие категории тестов: юнит, интеграционные, E2E по необходимости ## Уровни серьёзности | Серьёзность | Значение | Требуемое действие | |-------------|----------|-------------------| | CRITICAL | Баг, уязвимость безопасности, риск потери данных | Обязательно исправить до мержа | | HIGH | Значимая проблема, логическая ошибка, деградация производительности | Следует исправить до мержа | | MEDIUM | Code smell, проблема поддерживаемости, отсутствие теста | Обсудить, обычно исправить | | LOW | Стилистическое замечание, минорное улучшение, опциональный рефакторинг | На усмотрение автора | | PRAISE | Хорошо написанный код, изящное решение, удачный паттерн | Позитивная обратная связь | Структурируй ревью следующим образом: ### Резюме ревью PR **PR:** [заголовок] **Вердикт:** APPROVE / REQUEST_CHANGES / COMMENT **Уровень риска:** LOW / MEDIUM / HIGH / CRITICAL **Размер диффа:** Маленький/Средний/Большой (N файлов, +N/-N строк) #### Обзор 1–3 предложения о том, что делает этот PR, и общая оценка. #### Ключевые находки ##### Средние проблемы Тот же формат, что и выше. ##### Мелкие замечания - Файл:Строка — краткое описание - ... ##### Что сделано хорошо - Позитивные наблюдения — всегда включай хотя бы одно #### Чек-лист безопасности - Нет секретов и учётных данных в коде - Валидация входных данных на границах системы - Нет векторов SQL/XSS/command injection - Проверки авторизации на новых эндпоинтах/маршрутах - Чувствительные данные не логируются и не раскрываются #### Оценка тестирования | Аспект | Статус | |--------|--------| | Новый код покрыт | ДА / ЧАСТИЧНО / НЕТ | | Граничные случаи протестированы | ДА / ЧАСТИЧНО / НЕТ | | Пути ошибок протестированы | ДА / ЧАСТИЧНО / НЕТ | | Нет нестабильных паттернов | ДА / ЧАСТИЧНО / НЕТ | #### Рекомендации Приоритезированный список: что исправить до мержа, а что можно отложить. ## Принципы ревью ### НЕ ДЕЛАЙ - Придираться к форматированию, когда настроен линтер/форматтер - Предлагать крупные рефакторинги, не связанные с целью PR - Блокировать из-за стилистических предпочтений — фокус на корректности и ясности - Ревьюить сгенерированные/вендорные файлы (lock-файлы, миграции и т.д.) - Предполагать злой умысел — сначала спрашивай, потом делай выводы - Штамповать — даже маленькие PR заслуживают внимания ## Проверки по языкам ### Python - Аннотации типов на публичных API, корректность async/await - Контекстные менеджеры для ресурсов (файлы, соединения) - Мутабельные аргументы по умолчанию, позднее связывание замыканий ### JavaScript/TypeScript - Строгое сравнение (=== vs ==), правильные null-проверки - useEffect cleanup, массивы зависимостей в React - Типобезопасность: escape-хатчи через any, правильные дженерики ### SQL - Параметризованные запросы (никогда не интерполяция строк) - Отсутствие WHERE в UPDATE/DELETE, использование индексов - Границы транзакций, потенциальные дедлоки ### Go - Обработка ошибок (не игнорировать возвращённые ошибки) - Утечки горутин, управление каналами/контекстом - Правильное использование defer, область действия мьютексов ### Rust - Unwrap/expect в продакшн-коде, правильная пропагация ошибок - Соответствие borrow checker и lifetimes - Обоснование и документирование unsafe-блоков ## Особые сценарии ### Изменения API - Обратная совместимость для потребителей - Стратегия версионирования - Обновлена ли документация - Консистентность формата ответов об ошибках ## Матрица принятия решения по вердикту | Условие | Вердикт | |---------|---------| | Нет проблем или только LOW/PRAISE | APPROVE | | Только MEDIUM, ни одна не блокирующая | APPROVE с комментариями | | Любая HIGH проблема | REQUEST_CHANGES | | Любая CRITICAL проблема | REQUEST_CHANGES | | Нужно больше контекста для ревью | COMMENT (задать вопросы) | --- Source: https://samreshuuu.ru/skills/code_quality_audit_ru # Аудит качества кода ## Философия Ключевой принцип: **улучшение балла должно реально коррелировать с улучшением кода.** Балл, который легко накрутить без реальных улучшений — бесполезен. ## Модель скоринга Итоговый балл = **25% механический** + **75% субъективный** (шкала 0–100). ### Механический пул (25% итогового балла) Пять измерений с весами: | Измерение | Вес | Что проверяем | |-----------|-----|---------------| | **Здоровье файлов** | 2.0 | Размер файлов, количество файлов в директориях, мёртвые файлы, нейминг | | **Качество кода** | 1.0 | Мёртвый код, code smells, неиспользуемые импорты/переменные/функции, сложность | | **Дупликация** | 1.0 | Повторяющиеся блоки, бойлерплейт, скопированная логика | | **Здоровье тестов** | 1.0 | Покрытие, качество тестов, детерминированность, граничные случаи | | **Безопасность** | 1.0 | Инъекции, утечки секретов, небезопасная криптография, SSRF, XSS | Формула для каждого измерения: Вес ошибки зависит от уверенности: HIGH = 1.0, MEDIUM = 0.7, LOW = 0.3. ### Субъективный пул (75% итогового балла) Двенадцать измерений с весами: | Измерение | Вес | Что оцениваем | |-----------|-----|---------------| | **Высокоуровневая элегантность** | 22 | Архитектура системы в целом: разделение ответственности, граф зависимостей, потоки данных. Мог бы новый инженер понять систему за день? | | **Среднеуровневая элегантность** | 22 | Модули и компоненты: связность внутри, слабая связанность между. Есть ли чёткие контракты на границах модулей? | | **Низкоуровневая элегантность** | 12 | Функции и методы: длина, вложенность, цикломатическая сложность. Читается ли код сверху вниз без прыжков? | | **Когерентность контрактов** | 12 | Согласованность интерфейсов, API, типов между модулями. Одинаковые данные представлены одинаково? | | **Типобезопасность** | 12 | Строгость типизации, отсутствие any/unknown escape-хатчей, правильные дженерики и guard-клаузы | | **Когерентность дизайна** | 10 | Единообразие паттернов: если ошибки обрабатываются через Result — везде ли? Если state через хуки — везде ли? | | **Уместность абстракций** | 8 | Нет ли преждевременных абстракций? Нет ли недо-абстракций (3+ копии одной логики)? Каждая абстракция оправдана реальным переиспользованием? | | **Ясность логики** | 6 | Можно ли понять бизнес-логику, не заглядывая в соседние файлы? Guard clauses вместо глубокой вложенности? | | **Структура и навигация** | 5 | Организация файлов/папок: можно ли найти нужный код по названию? Есть ли паттерн в расположении? | | **Консистентность ошибок** | 3 | Единый подход к ошибкам: одинаковые коды, форматы сообщений, стратегии обработки | | **Качество нейминга** | 2 | Имена переменных, функций, типов передают намерение. Нет сокращений без контекста, нет generic имён (data, info, item, handle) | | **AI-сгенерированный долг** | 1 | Признаки генерации без ревью: одинаковые комментарии-заглушки, избыточная обработка невозможных ошибок, over-engineering простых задач | ## Процедура аудита ### Шаг 2: Механический анализ Для каждого из 5 механических измерений выполни проверки: #### Здоровье файлов (вес 2.0) - [ ] Файлы > 300 строк — кандидаты на разбиение - [ ] Директории > 15 файлов — нужны поддиректории - [ ] Мёртвые файлы (не импортируются, не используются) - [ ] Нарушения конвенции нейминга файлов - [ ] Плоские директории без структуры #### Качество кода (вес 1.0) - [ ] Неиспользуемые импорты, переменные, параметры - [ ] Неиспользуемые экспорты / функции / классы - [ ] Пустые блоки catch/except без обработки - [ ] Мёртвые ветки (unreachable code) - [ ] Цикломатическая сложность > 10 - [ ] Глубокая вложенность > 4 уровней - [ ] Debug-логи в продакшн-коде (console.log, print, debugger) - [ ] Закомментированный код #### Дупликация (вес 1.0) - [ ] Дублированные блоки кода (> 6 строк) - [ ] Повторяющийся бойлерплейт между файлами - [ ] Скопированная бизнес-логика вместо переиспользования - [ ] Одинаковые паттерны обработки ошибок, которые можно обобщить #### Здоровье тестов (вес 1.0) - [ ] Непокрытые критические пути (happy path + основные ошибки) - [ ] Тесты, проверяющие реализацию, а не поведение - [ ] Недетерминированные тесты (зависят от времени, порядка, сети) - [ ] Моки, скрывающие реальные проблемы - [ ] Отсутствие тестов на граничные случаи - [ ] Пустые или тривиальные тесты (assert True) #### Безопасность (вес 1.0) - [ ] SQL-инъекции (конкатенация строк вместо параметризации) - [ ] XSS (вставка пользовательских данных без экранирования) - [ ] Секреты в коде (API-ключи, пароли, токены) - [ ] Отсутствие валидации входных данных на границах API - [ ] Небезопасная криптография (MD5, SHA1 для паролей) - [ ] SSRF (запросы по пользовательским URL без проверки) - [ ] Избыточные права доступа / отсутствие проверок авторизации ### Шаг 3: Субъективная оценка Для каждого из 12 субъективных измерений: Шкала субъективной оценки: - **90–100**: Образцовый код, можно показывать как пример - **70–89**: Хорошо, есть куда расти, но основа крепкая - **50–69**: Средне, заметные проблемы, но код рабочий - **30–49**: Ниже среднего, накопленный техдолг мешает развитию - **0–29**: Критично, код хрупкий, каждое изменение рискует что-то сломать ### Шаг 4: Классификация находок Каждой найденной проблеме присвой: **Тир (серьёзность):** | Тир | Название | Вес | Описание | |-----|----------|-----|----------| | T1 | Авто-фикс | 1 | Тривиально исправить: удалить импорт, убрать лог, форматирование | | T2 | Быстрый фикс | 2 | Простое ручное исправление: переименовать, добавить валидацию, исправить тип | | T3 | Требует решения | 3 | Нужна инженерная оценка: разбить файл, выделить модуль, пересмотреть контракт | | T4 | Рефакторинг | 4 | Значительная переработка: изменить архитектуру модуля, пересмотреть flow данных | **Уверенность:** HIGH (1.0) / MEDIUM (0.7) / LOW (0.3) **Измерение:** К какому из 17 измерений относится находка. ### Шаг 5: Антиманипуляционные проверки Перед выдачей финального балла проверь себя: ## Формат отчёта ### Механические измерения Таблица с баллами по каждому из 5 измерений: | Измерение | Балл | Проверок | Проблем | Тяжесть | |-----------|------|----------|---------|---------| | Здоровье файлов | XX/100 | N | N | T1:N T2:N T3:N T4:N | | Качество кода | XX/100 | N | N | ... | | Дупликация | XX/100 | N | N | ... | | Здоровье тестов | XX/100 | N | N | ... | | Безопасность | XX/100 | N | N | ... | ### Субъективные измерения Таблица с баллами по каждому из 12 измерений: | Измерение | Балл | Уверенность | Главная проблема | |-----------|------|-------------|------------------| | Высокоуровневая элегантность | XX | HIGH/MED/LOW | Краткое описание | | Среднеуровневая элегантность | XX | ... | ... | | ... | ... | ... | ... | ### Топ-проблемы (отсортированы по влиянию на балл) Для каждой из 10 самых влиятельных проблем: ### Самые большие тормоза балла Список из 5 измерений, которые больше всего тянут балл вниз, с расчётом: ### Приоритизированный план действий Три горизонта: #### Немедленно (T1–T2, рост балла +N) Пронумерованный список конкретных действий, которые можно выполнить за 1 сессию. #### Ближайший спринт (T2–T3, рост балла +N) Задачи, требующие инженерной оценки, но выполнимые за 1–2 дня. #### Стратегически (T3–T4, рост балла +N) Архитектурные изменения, требующие планирования. ## Адаптация под стек ### Python - Аннотации типов (mypy strict), dataclasses vs pydantic - Async/await корректность, отсутствие блокирующих вызовов в async-контексте - Импорты: абсолютные vs относительные, циклические зависимости ### TypeScript / JavaScript - Строгость tsconfig (strict: true), отсутствие any - React: правильные зависимости хуков, мемоизация, разделение компонентов - Next.js: RSC/client boundary, правильный fetching, нет env-утечек ### Go - Обработка ошибок (не игнорировать), горутин-менеджмент - Интерфейсы: маленькие, в месте использования - Context propagation, graceful shutdown ### Rust - Обработка ошибок: Result вместо panic, thiserror/anyhow - Ownership: минимум clone(), правильные lifetimes - Unsafe: обоснован и задокументирован ### SQL / Миграции - Параметризация, индексы, обратимость миграций - N+1 проблемы, денормализация vs производительность --- Source: https://samreshuuu.ru/skills/qa_report_ru ## Железное правило: ничего не исправлять **Не правишь код, не создаёшь ветки, не открываешь pull request, не меняешь данные, не перезапускаешь сервисы.** Это условие, при котором отчёт имеет силу. Четыре причины, каждая достаточна: ## Что запросить до первого клика | Что | Зачем | Если не дали | |-----|-------|--------------| | URL стенда и его тип (прод / стейдж / демо) | Дефект на стейдже и на проде — разные дефекты | Работай на проде **только на чтение**, зафиксируй ограничение | | Версия: коммит, тег, дата сборки | Без версии отчёт не привязать к сдаче | Зафиксируй дату/время начала, версию отметь как неустановленную | | ТЗ, договор, макеты, спецификация API | Отличает дефект от «мне не нравится» | Спорное — в «Вопросы к договорённостям» | | Учётки всех ролей (гость, клиент, менеджер, админ) | Половина дефектов доступа видна только сравнением ролей | Роли без доступа — в границы применимости | | Тестовые данные и тестовый эквайринг | Оплату нельзя проверять реальными деньгами | «Оплата не проверена» — строка отчёта, а не молчание | | Окно проведения работ | Аудит прода в пиковые часы вредит бизнесу | Согласуй окно письменно | Отдельно спроси: **какое решение принимается по итогам**. «Платить последний транш» и «понять, что чинить первым» — два разных отчёта. ## Три корзины: дефект, вопрос, пожелание Свалить в дефекты всё, что не понравилось, — главная ошибка: подрядчик оспорит половину списка, и с ней потеряет вес настоящая половина. - **Дефект** — нарушение зафиксированной договорённости или объективно неработающая функция. «Кнопка «Оформить заказ» не отправляет форму» — дефект без всякого ТЗ; «поле обязательное, в макете необязательное» — дефект со ссылкой на макет. - **Вопрос к договорённостям** — поведение неочевидное, но нигде не описанное («что при повторной отправке формы»). Отдельный список, часто ценнее списка багов — показывает дыры в ТЗ. - **Пожелание** — «было бы лучше». В приёмочный отчёт не входит, идёт приложением: одно пожелание среди дефектов даёт право сказать «вкусовщина» про весь список. Правило: не можешь показать пальцем на строку ТЗ, макет или объективный отказ (ошибка, пустой экран, потерянные данные) — это не дефект. ## Доказательная база дефекта Дефект доказан, если посторонний по карточке воспроизвёл его с первой попытки. Шесть обязательных элементов: 1. **Окружение**: URL, браузер и версия, ОС, ширина окна в пикселях, роль. 2. **Версия продукта**: коммит или дата сборки; недоступна — дата и время наблюдения с часовым поясом. 3. **Шаги** — от чистого состояния: новое приватное окно, разлогиненный пользователь. Один шаг — одно действие. Введённые данные дословно, с пробелами и кириллицей. 4. **Ожидаемое** — со ссылкой на источник: пункт ТЗ, экран макета, поведение соседнего раздела. 5. **Фактическое** — без интерпретации: «страница осталась пустой, в консоли `TypeError: cannot read property 'id' of undefined`» — факт; «сломался роутинг» — интерпретация, её оспорят. 6. **Воспроизводимость** — `N из M`. Пять попыток — минимум для слова «всегда»; один раз — `1 из 1`, так и пиши. **Правило трёх кадров**: до (исходный экран), во время (момент действия), после (результат). Скриншоты — `browser_interact`, текст ошибки с картинки — `analyze(kind="ocr")`. Для сетевых дефектов — запрос целиком: метод, URL, код ответа, тело, время. Для зависящих от времени — метка времени, чтобы разработчик нашёл строку в своих логах. Стоимость доказательства ограничивай: на «низкий» — не больше 10–15 минут; дольше — либо он серьёзнее, либо не стоит места в отчёте. ## Классификация серьёзности через ущерб Серьёзность — ответ на «что теряет бизнес, если не починить». Четыре оси: деньги, данные, доступность, право и репутация. Уровень — максимум по осям. | Уровень | Деньги | Данные | Доступность | Право и репутация | |---------|--------|--------|-------------|-------------------| | **Критический** | Оплата не проходит или проходит дважды; заказ не доезжает до 1С/МойСклад; неверная сумма списания | Потеря или порча данных клиента; чужие персональные данные видны без авторизации | Сайт или ключевой раздел недоступен; 5xx на основном сценарии | Согласие на обработку персональных данных не собирается; чек не формируется | | **Высокий** | Сценарий проходим только в обход; корзина теряется; промокод считается неверно | Данные сохраняются с искажением (кодировка, дата, дробная часть) | Раздел недоступен в одном из массовых браузеров или на мобильных | Нет политики обработки персональных данных, оферты или реквизитов продавца | | **Средний** | Лишние шаги, потеря части пользователей | Данные корректны, но отображаются неверно | Ответ основной страницы дольше 3 секунд | Ошибки в юридически значимых текстах, битые ссылки на документы | | **Низкий** | Влияния нет | Влияния нет | Влияния нет | Опечатки, съехавшие отступы, неконсистентные шрифты | Проверка на честность: не можешь назвать пострадавшего и его потерю — уровень завышен. И наоборот: «мелкая» опечатка в сумме или реквизитах юрлица не бывает низкой. ### Денежная оценка дефекта Для дефектов, влияющих на выручку, считай потерю прямо в карточке: Данные — из аналитики заказчика (Яндекс.Метрика: доля браузеров и устройств, конверсия, средний чек), не из головы. Пример: 30 000 визитов/мес, конверсия 1,4 %, чек 4 200 ₽; кнопка оформления не работает в Safari на iOS — 18 % визитов по Метрике. Потеря: `30 000 × 0,18 × 0,014 × 4 200 ≈ 317 500 ₽/мес` — такой дефект спорить не будут. Нет данных — пиши «оценка невозможна, требуется доступ к аналитике»: выдуманное число разрушает доверие сильнее его отсутствия. ## Методика: приёмочный балл Одно число 0–100, чтобы сравнивать состояние во времени и между подрядчиками; считается механически. Это не Health Score из `qa_ru`: тот взвешивает техническое здоровье, этот — ущерб заказчика; числа не сравнивай и в одном отчёте не смешивай — называй то, которое считал. **Шаг 1. Оценка категории.** Старт со 100, минус за каждый подтверждённый дефект: критический −40, высокий −20, средний −7, низкий −2. Снизу ноль. Дефекты с воспроизводимостью ниже `2 из 5` в счёт не идут — уходят в «Наблюдения». **Шаг 2. Взвешивание** (веса отражают ущерб, а не объём работы): | Категория | Вес | Что входит | |-----------|-----|------------| | Деньги и заказы | 25 | Корзина, оформление, оплата, выгрузка заказа в 1С / МойСклад / Битрикс24, письма и статусы | | Данные и целостность | 20 | Сохранение, кодировки, даты, суммы, разграничение доступа | | Доступность и стабильность | 15 | Коды ответа, ошибки в консоли, скорость основных страниц | | Основные сценарии | 15 | Регистрация, вход, поиск, карточка товара, личный кабинет | | Формы и обработка ошибок | 10 | Валидация, понятность сообщений, восстановление после ошибки | | Мобильная версия | 7 | Экраны 360–430 px, попадание по элементам, клавиатура | | Обязательный контент | 5 | Политика персональных данных, оферта, реквизиты, контакты | | Доступность интерфейса | 3 | Контраст, клавиатура, альтернативный текст изображений | **Шаг 3. Жёсткие ограничители** (важнее арифметики): критический дефект в деньгах или данных → балл не выше 40 и вердикт не выше «вернуть на доработку»; категория с оценкой 0 → балл не выше 60; проверено меньше 60 % заявленной области → балл не публикуется, вместо него «оценка невозможна, покрытие N %». **Шаг 4. Вердикт:** | Балл | Вердикт | Формулировка для заказчика | |------|---------|----------------------------| | 85–100 | Принять | Работа соответствует договорённостям, замечания несущественны | | 70–84 | Принять с замечаниями | Принимать можно, перечень устранить в согласованный срок | | 50–69 | Вернуть на доработку | Существенные недостатки, приёмка преждевременна | | 0–49 | Не принимать | Продукт не выполняет основную функцию | ## Раздел «Что не проверялось» Обязателен всегда, с **причиной** по каждому пункту: молчание читается как «проверено и в порядке». Стандартная формулировка в конце: «Отчёт отражает состояние продукта на {дата} для версии {версия} в перечисленных условиях. Отсутствие дефекта в отчёте не означает его отсутствия в продукте». Отдельно перечисли проверенное **поверхностно**: «просмотрено визуально, сценарии не проходились» — это не «проверено». ## Карточка дефекта Нумерацию между отчётами не переиспользуй: `ДЕФЕКТ-14` означает одно и то же и через полгода переписки. ## Типовые возражения — снять заранее | Возражение | Чем закрывается прямо в карточке | |------------|----------------------------------| | «У меня работает» | Полное окружение и версия: разница в браузере, ширине окна или роли обычно и есть ответ | | «Так и задумано» | Ссылка на источник ожидаемого; нет источника — карточка заранее в «Вопросах к договорённостям» | | «Вы неправильно тестировали» | Шаги от чистого состояния, дословный ввод, три кадра | | «Это редкий кейс» | Доля затронутых из аналитики и денежная оценка | | «Это ваш интернет» | Код и время ответа сервера из сетевой панели | | «Это сторонний сервис» | Домен и путь запроса; ответственность за интеграцию на исполнителе | | «Это уже починили» | Дата, время и версия наблюдения: отчёт фиксирует состояние на дату | | «Это не входило в объём работ» | Цитата из договора или ТЗ; объём не описан — «Вопрос к договорённостям» | | «Воспроизводится не всегда» | Формат `N из M` заявлен честно, оспорить нечего | До публикации пройдись по таблице: ни одно возражение не должно остаться без ответа в тексте карточки. ## Три формата под трёх читателей ### Для разработчика — реестр Сортировка «серьёзность → категория → номер», карточки целиком, отдельным блоком — сетевые запросы и ошибки консоли, пригодные для копирования. Денежные оценки и вердикт не нужны. ### Для заказчика — повествование Что проверяли, как и что нашли — человеческим языком, разделы «критично», «важно», «мелочи», «вопросы, на которые нужен ваш ответ». Без жаргона: не «5xx на эндпойнте», а «при отправке заявки сервер отвечает ошибкой, заявка не доходит». Отчёты — через `documents`, распределение дефектов — HTML/SVG-визуал через `render_visual(title=..., html=...)` прямо в разговоре (правила — в описании инструмента, загруженного через `tool_search`), вердикт с числом — первой строкой отчёта. ## Чего не делать никогда - Не чинить, не коммитить, не открывать pull request, не менять данные на чужом стенде — даже правку на одну строку. - Не публиковать балл при покрытии ниже 60 %. - Не выдумывать денежные оценки без данных аналитики. - Не квалифицировать дефекты юридически и не ссылаться на номера статей и приказов: неточная ссылка обесценит отчёт целиком. - Не смешивать пожелания с дефектами и не писать «всегда» после одной попытки. - Не оставлять на скриншотах персональные данные клиентов: маскируй телефоны, адреса, почту. - Не молчать о том, что не проверил. --- Source: https://samreshuuu.ru/skills/qa_ru ## С чего начинаешь 1. **Что тестируем** — URL стенда (не прод, если есть выбор), сценарии, что считается «работает». 2. **Под кем** — гость или авторизованный; учётку запроси через `request_form`, а не сообщением в чат. 3. **Что запрещено** — по умолчанию всё, что видит третье лицо: оплата, письмо, SMS, заказ поставщику, остатки в боевом 1С/МойСклад, публикация на Ozon/WB. | Режим | Покрытие | Действий | |-------|----------|--------| | Быстрый | Главная + 5 ключевых страниц, один сквозной сценарий | ~15 | | Полный | Все маршруты, формы, граничные значения, адаптивность | 60–120 | | Регрессия | Область прошлого бага + соседние по данным экраны | 20–40 | | По изменениям | Диф последнего PR → карта затронутых маршрутов | по дифу | Диф бери через `sandbox_bash` (`git diff`) и разворачивай в список URL: изменился компонент формы → все страницы, где он встроен; изменилась миграция → все экраны, читающие таблицу. ## Основной инструмент: `browser_interact` Управление постоянным Chromium: `navigate`, `snapshot`, `act`, `click`, `fill`, `type`, `select`, `check`, `hover`, `scroll`, `press_key`, `upload_file`, `wait`, `screenshot`, `back`. **По `ref`** (по умолчанию): `snapshot` отдаёт дерево доступности с номерами элементов, дальше `click`/`fill` с номером — точно и дёшево. **По `intent`**: `act` с фразой «нажми кнопку Оформить заказ» — когда дерево не даёт однозначного имени. ### Как читать ответ - **`outcome`** — самое ценное поле. Для `click`/`press_key`: `changed — page navigated` / `changed — N DOM mutation(s)` / `no-change` / `unknown`. Для `fill`/`type`/`select` — значение поля после действия с пометкой расхождения: готовый детектор багов масок (ввёл `+7 (999) 123-45-67`, поле вернуло `+7 (999) 123-45-6`). - **`no-change` — не всегда провал:** canvas-, iframe- и Flutter-интерфейсы не мутируют DOM. Прежде чем писать «кнопка не работает» — `screenshot`, `url`, повторный `snapshot`. - **`unknown` — не доказательство:** шаг непройден, пока не подтверждён вторым фактом. - **`element_count: 0`** — почти всегда редирект на пустой экран, незагрузившийся SPA или требование входа. - **`console_errors`** — приходят **только на `navigate`**, не более 20, обрезаны до 300 символов, только `error` плюс необработанные исключения: ошибку после клика этим полем не увидишь. ### Когда не хватает: CDP из `repl_execute` `scrollWidth > clientWidth` при `overflow:hidden` — машинный признак обрезанного текста; горизонтальный скролл на 360px — несжимаемой вёрстки. Обрыв сети и часовой пояс — через `ctx.new_cdp_session(page)`: `Network.emulateNetworkConditions` с `offline: True` и `Emulation.setTimezoneOverride`. На десктоп-поверхности `browser_interact` поднимает локальный браузер и возвращает `connected`/`launched` — дальше доступны `mcp__chrome-devtools__*` (`navigate_page`, `take_snapshot`, `click`, `fill`, `resize_page`, `emulate`, `list_console_messages`), и вьюпорт с консолью берутся оттуда. ## Протокол одного сценария Сценарий — путь к результату, за который платят: «оформил заказ», «выгрузил акт сверки», а не «открыл страницу». ## Классы дефектов, которые ищешь прицельно ### Гонка при двойной отправке Воспроизведение: два `click` по кнопке отправки без ожидания; отдельно — `press_key: Enter` сразу после клика. Признаки: два одинаковых заказа/платежа/письма, два POST с одинаковым телом, счётчик вырос на 2, у кнопки нет состояния «отключена». Цена: двойное списание, две отгрузки. В баге не пиши «заблокировать кнопку»: она спасает только от клиентского дубля, настоящая защита — идемпотентный ключ на стороне API. ### Потеря состояния при возврате Воспроизведение: фильтры → карточка → `back`; три шага мастера → `back` → вперёд; ошибка валидации → `back`. Признаки: фильтры сброшены, пагинация на первой странице, введённое пропало, форма оплаты пустая — но заказ создан. Подкласс: `back` после успешной отправки показывает прежние данные, и повторная отправка создаёт дубль. ### Часовые пояса и даты В России 11 зон, UTC+2 (Калининград) — UTC+12 (Камчатка); сервер почти всегда по Москве, пользователь — нет. Воспроизведение: `Emulation.setTimezoneOverride` на `Asia/Kamchatka` и `Europe/Kaliningrad`, те же сценарии; создай запись в 23:30 по местному и смотри, какой датой она попала в отчёт. Признаки: дата документа сдвинута на сутки; «сегодня» в фильтре не включает только что созданную запись; отчёт «за 1 июля» у клиента из Владивостока содержит часть 30 июня; время в списке и карточке различается на 3 часа — одно место форматирует UTC, другое локальное. Правило: если хранение в UTC, а бизнес-сутки местные, сутки считаются в зоне пользователя; на закрытых сутках это расхождение с 1С, которое заметит бухгалтер. ### Формы при потере сети Воспроизведение: заполнил → offline через CDP → отправил → вернул сеть. Признаки: вечный спиннер без таймаута; «Ошибка» без ответа, сохранились ли данные; после возврата сети форма ушла повторно; сетевая ошибка показана как «Неверный логин или пароль». Разделяй: запрос не ушёл (повтор безопасен) и запрос ушёл без ответа (повтор опасен) — интерфейс, не различающий их, «высокий» на денежном шаге. ### Числа, деньги и файлы из 1С Воспроизведение: `1 234,56`, `1234.56`, `1 234 567,89 ₽` с неразрывными пробелами (U+00A0), минус U+2212 вместо дефиса, отрицательный остаток, три знака после запятой. Признаки: запятая отвергается или молча превращает 1 234,56 в 1; вставка из Excel/1С ломается о неразрывный пробел; построчное округление копеек расходится с итогом. Файлы (`upload_file`): CSV в CP1251, CSV с BOM, .xlsx с объединёнными ячейками в шапке, файл 0 байт. Признак бага: кракозябры, «файл повреждён» без номера строки, импорт половины строк. ### Пустые состояния и базовая безопасность Пустое — в свежем контексте: пустой список, поиск с 0 результатов, отчёт без данных, удалён последний элемент. Признаки: белая область, `undefined`, `NaN`, «0 из 0», вечный спиннер. В поля подставь ``, `">`, `' OR 1=1--`, `{{7*7}}`: признак — значение отрисовалось как разметка или появилось `49`. Отдельно — чужой `id` документа в URL. Найденное здесь всегда «критический»; описывай без подробностей эксплуатации. ## Граничные значения для российских форм - **ОГРН и КПП:** ОГРН — 13 знаков, ОГРНИП — 15; последняя цифра контрольная — последняя цифра остатка от деления числа без неё (13 знаков — на 11, 15 — на 13). КПП — 9 знаков, 5-я и 6-я позиции могут быть **латинскими буквами** у иностранных организаций: форма «только цифры» отсекает часть контрагентов. - **Телефон:** `+79991234567`, `89991234567`, `+7 (999) 123-45-67`, `8-800-555-35-35`, городской с кодом, «доб. 123», международный `+375…`. Отдельно — вставка из буфера в маску и ввод в середину заполненной маски (каретка прыгает в конец). Баг, если 8 и +7 сохранились как разные номера. - **Адрес, индекс, даты:** длинные названия («улица имени 40-летия Победы»), литера дома («д. 5Б» — кириллическая Б и латинская B разные), «корп. 2 стр. 3», квартира «12/1», сёла без улиц. Индекс — 6 цифр строкой: числом теряет ведущий ноль. При подсказках адресов проверь ручной ввод того, чего нет в справочнике. Даты: `01.07.2026` и `2026-07-01` в одном интерфейсе — уже дефект; 29.02 невисокосного года, конец периода раньше начала, ручной ввод с клавиатуры. ## Классификация серьёзности - **Критический** — теряются деньги или данные, обхода нет: двойное списание, доступ к чужим данным, потеря документа, отказ входа. - **Высокий** — ключевой сценарий не проходится, обход неочевиден: отчёт не выгружается, оплата проходит без уведомления. - **Средний** — сценарий проходится с потерей времени или доверия: слетают фильтры, непонятная ошибка, обрезанный реквизит. - **Низкий** — косметика: отступы, опечатка, несогласованный термин. Серьёзность задаёт последствие: опечатка в сумме — критический баг, не низкий. ## Health Score Оценка нужна, чтобы сравнивать прогоны между собой: категории и веса не меняй. | Категория | Вес | Почему столько | |-----------|-----|----------------| | Функциональность | 20% | Единственная, где дефект — потерянные деньги сегодня | | Консоль (JS-ошибки) | 15% | Молчащая ошибка сегодня — сломанный сценарий завтра | | UX | 15% | Потери данных и неясные ошибки — из-за чего пишут в поддержку | | Доступность | 15% | Элемент без имени не виден ни скринридеру, ни автоматизации | | Ссылки | 10% | Считается машинно и полностью — вес умеренный | | Визуал | 10% | Заметно, но обходится пользователем | | Производительность | 10% | Влияет на конверсию, но редко блокирует | | Контент | 5% | Дёшево чинится; ошибки в суммах — в баги, а не сюда | - **Функциональность** = 100 × (пройденные шаги / запланированные); шаг с `unknown` непройден. - **Консоль** = 100 − 15 × (уникальные JS-ошибки, дедуп по первой строке) − 25 × (ошибки на денежном или регистрационном шаге), не ниже 0. - **UX** = 100 − 10 за каждое: действие без отклика дольше секунды, потеря введённого, ошибка без объяснения, что делать. - **Доступность** = 100 × (доля интерактивных элементов с непустым именем в дереве) − 20, если фокус не виден, − 20, если сценарий непроходим с клавиатуры (`press_key: Tab`, `Enter`); элементы вида `button ""` — прямой счётчик. - **Ссылки** = 100 × (доля ответов 2xx); 4xx/5xx — ноль, редирект длиннее двух хопов — половина. - **Визуал** = 100 − 8 за обрезанный элемент, − 15 за нечитаемый или перекрытый текст, − 20 за скролл вбок на 360px. - **Производительность** — по худшей странице маршрута: LCP до 2,5 с → 100, до 4 с → 60, дольше → 20; CLS выше 0,25 → −20 (пороги Core Web Vitals на 2026-07-28). - **Контент** = 100 − 10 за опечатку или расхождение в терминах. **Вердикт не выводится из числа.** Критический баг есть → «Не готов» при любом score; критических нет, но score < 70 или высокие на ключевом сценарии → «Нужна доработка»; иначе → «Готов к релизу». ## Итоговый отчёт «Не проверено» обязателен: без него отчёт читается как «проверено всё», и первый баг из непокрытой области обнулит доверие. Отдавай отчёт через `documents`, регулярный прогон оформи задачей по расписанию через `manage_task`, критические находки называй первыми; правку можно довести до коммита в ветке (PR открывает владелец), но отчёт описывает состояние до неё. ## Правила работы 1. **Экран — не факт.** «Кнопка не нажалась» без `outcome` и второй проверки — гипотеза, а не баг. 2. **Один шаг — один вызов:** склейка делает невоспроизводимым и баг, и отчёт. 3. **Валидный путь сначала:** пока сценарий не пройден целиком, непонятно, что считать нормой. 4. **Пять попыток для плавающего бага**, и число в отчёте. 5. **Не чини по дороге:** правки в середине прогона делают отчёт описанием несуществующей версии. 6. **Не трогай боевые данные:** оплата — в тестовом режиме провайдера, рассылки — на свои адреса, остатки и заказы в 1С/МойСклад/Ozon/WB не меняешь. 7. **Пять доказанных багов лучше двадцати расплывчатых:** закроют те, что удаётся воспроизвести. 8. **Ограничения инструмента — часть отчёта:** не проверил «Отмену» из-за автопринятия диалогов — так и напиши. --- Source: https://samreshuuu.ru/skills/autoplan_ru ## Шаг 0. Профиль ревьюируемого артефакта До первого этапа ответь на четыре вопроса, ответы — в шапку отчёта: 1. **Что ревьюим** — идея на абзац / план фичи / архитектурный документ / диф или PR / работающий интерфейс. 2. **Что меняется наружу** — экраны, тексты, публичные API, ничего. 3. **Какие деньги и данные затрагиваются** — расчёт цены, списания, ПДн, остатки, ничего из этого. 4. **Есть ли снапшот** — редакция плана, на которую сошлются все этапы. Четвёртый пункт не формальность: этапы, посмотревшие разные редакции, дадут вердикты, которые нельзя сложить. Фиксируй текст плана до старта. ## Шаг 0.1. Какие этапы нужны Полный прогон не всегда оправдан. Решай по таблице: **Дизайн-этап** нужен, если план меняет экран внешнего пользователя, текст в интерфейсе, поток оплаты или согласие на обработку ПДн. Диф целиком в `*.py`, `*.sql`, CI и миграциях — пропуск. **Инженерный этап** нужен всегда, когда есть код или схема данных; пропуск — только для идеи без плана реализации. **CEO-этап** «лайт» — три вопроса из шести: кто клиент, какую проблему решаем, как узнаем, что сработало; полный — все шесть плюс выбор режима масштаба. **Пропуск обязан быть записан:** «Дизайн-ревью: пропущено — изменения не выходят за бэкенд». Читатель отличает «проверили» от «не смотрели» только по этой строке. ## Шаг 0.2. Инлайн или делегирование **Инлайн** — сам вызываешь `read_skill` и применяешь: план текстовый, помещается в контекст, в код ходить не надо. **Делегирование** — `run_subagent` с задачей на этап: ревью требует чтения кода, обхода репозитория или данных из внешних систем. Реально существующие параметры: `agent_type` (`explore` | `execute` | `verify`), `tasks` (1–5), `wait`. Никакого `max_iterations` нет — бюджет задан ролью. ### Бюджеты ролей (актуально на 2026-07-28, задаются конфигом платформы) Следствие: этапы запускай как `explore`. Запущенный как `verify` этап не загрузит навык-ревьюер и выдаст импровизацию — тот же пересказ, чужими руками. `verify` годится лишь на сверку чисел в отчёте. ### Стоимость полного прогона против выборочного Три этапа в бюджетах `explore` = до 240 tool calls и 300 тыс. токенов; выборочный прогон по Шагу 0.1 обычно снимает этап целиком — треть. Платформа держит 3 одновременных LLM-вызова: три параллельных этапа по стене идут как один самый долгий. Правило: нужны все три и надо читать код — делегируй одним вызовом с `wait=true`; нужен один — не делегируй вовсе. ## Шаг 0.3. Как не потерять контекст между этапами - Текст плана клади в `context` задачи (лимит 16 000 знаков), `task_instruction` держи коротким (лимит 4000). План длиннее — стадируй артефактом (`save_artifact` в `repl_execute`) и ссылайся на его имя. - Возврат идёт двумя каналами: `summary` инлайн **обрезается на ~1200 знаках** и `full_output_path` с полным выводом. Таблицу из 10 дизайн-измерений в 1200 знаков не уложить — читай `full_output_path` для каждого этапа с вердиктом хуже «Готов», иначе половина проблем исчезнет по дороге. - Подагент делегировать дальше не может (глубина — 1): трёхуровневых схем не проектируй. ### Карточка плана Едет во все этапы дословно, чтобы они не разошлись по редакциям: ## Шаг 0.4. Порядок этапов: параллельно или последовательно По умолчанию этапы независимы и идут **параллельно**: они читают один снапшот и не нуждаются в выводах друг друга. Последовательность обязательна ровно в одном случае — **когда CEO-этап меняет сам предмет ревью**: вердикт «Нужна переработка» или режим «СОКРАЩЕНИЕ», после которого из плана уходит 30% пунктов и больше. Тогда дизайн и инженерка ревьюят урезанный план, иначе половина их замечаний адресована функциональности, которой не будет. Отсюда протокол: CEO первым инлайном (он дешёвый — текст против текста), посмотри вердикт, потом одним вызовом `run_subagent` гони дизайн и инженерку параллельно против выжившей редакции. ## Шаг 0.5. Досрочная остановка Останавливай пайплайн при любом из условий: 1. **CEO не может назвать клиента.** Ответ — категория («малый бизнес»), а не конкретный человек: план перепишут целиком, дизайн-ревью такого плана — выброшенный бюджет. 2. **Нечего ревьюить.** Нет ни списка изменений, ни описания экранов, ни схемы данных — верни список недостающего. 3. **Снапшота нет, план правится по ходу.** Вердикты по движущейся цели нельзя свести. 4. **Первый этап нашёл блокер с приоритетом ≥12** (формула ниже): утечка ПДн, потеря денег, нарушение договора с площадкой. Остальные этапы не изменят «переработать». Остановка ≠ молчание: дай по оставшимся этапам 3–5 строк «на что смотреть, когда план вернётся» по заголовкам измерений навыка, и напиши, что этап не выполнялся. Независимость этапов означает, что дизайнер не смягчает оценку из-за одобрения CEO. Она не значит, что этапы обязаны отработать по плану, который решено переписать. ## Нормализация вердиктов Этапы говорят на трёх языках. Сведи их к шкале 0/1/2: | Этап | 2 (зелёный) | 1 (жёлтый) | 0 (красный) | |------|-------------|------------|-------------| | CEO | Одобрено | Одобрено с замечаниями | Нужна переработка | | Дизайн | средний балл ≥ 8.0 | 6.0–7.9 | < 6.0 | | Инженерка | Готов к реализации | Нужна доработка | Требует переработки | Две поправки, без которых нормализация врёт: - **Проблема с приоритетом «Критический» обнуляет этап** независимо от среднего балла: дизайн со средним 8.4 и одним нечитаемым на мобильном шагом оплаты — это 0, потому что среднее прячет провал в одном измерении за девятью хорошими. - **Этап, неприменимый по Шагу 0.1, в свёртку не входит:** он не 0 и не 2, его нет. ## Свёртка: минимум, а не среднее Ревью — конъюнкция, а не средневзвешенное. Пример: CEO=2, Дизайн=2, Инженерка=0 (нашли передачу токена площадки в query-строке). Среднее даёт 1.33 → «нужна доработка», план едет в спринт с пометкой «почти готово». Минимум даёт 0 → «требует переработки», утечка чинится до релиза. Разница между формулами — разница между инцидентом и его отсутствием. Итог словами: **2 — Готов к реализации**, **1 — Нужна доработка**, **0 — Требует переработки**. ## Приоритет сквозного списка проблем ### Формула Каждой проблеме из любого этапа считай `P = И × Р × Н`: - **И — влияние:** 3 — блокирует использование или теряет деньги/данные; 2 — заметно ухудшает результат; 1 — косметика. - **Р — радиус:** 3 — все пользователи или все данные; 2 — сегмент (площадка, тариф, тип клиента); 1 — единичный сценарий. - **Н — необратимость:** 2 — после релиза чинится миграцией данных, сменой публичного контракта или разговором с клиентом; 1 — правится деплоем. Пороги: **P ≥ 12** — блокер, релиз не выходит; **6–11** — чинить до релиза; **3–5** — следующий спринт; **≤2** — бэклог. **Поправка на согласие.** Проблема, независимо поднятая двумя этапами и более, получает **И + 1** (потолок 3): совпадение перспектив — сигнал сильнее, чем уверенность одной. ### Дедупликация Одна проблема, увиденная с двух сторон, — один пункт: дизайн пишет «нет пустого состояния для списка заказов», инженерка — «не обработан пустой ответ Ozon API при нулевых заказах», это один дефект на двух слоях. В отчёт идёт формулировка этапа с бо́льшим P, в скобках оба источника — `[Диз+Инж]`. Не сливай проблемы, у которых совпадает экран, но различается причина. **Квота.** В отчёт идут топ-5 по P плюс все блокеры; остальное — приложением. Список из тридцати замечаний не читают. ## Конфликты между перспективами Конфликт — не сбой пайплайна, а его продукт. Разреши его по каталогу ниже или оставь открытым, назвав цену вариантов. ### Конфликт A: «расширить» против «слишком большой диф» CEO требует амбиции, инженерка ставит красный флаг на >8 файлов и >2 новых сервиса. **Правило:** амбиция цели и размер первой поставки — разные величины. Расширяй цель, режь релиз. Разбор. План: синхронизация остатков с 1С для Ozon. CEO в режиме РАСШИРЕНИЕ: клиент торгует на трёх площадках, добавить WB и Яндекс Маркет. Инженерка: три клиента API с разной пагинацией и лимитами, 14 файлов, 3 сервиса — красный флаг по обоим порогам. Разрешение: цель — три площадки, релиз 1 — Ozon плюс адаптер, чей интерфейс с первого дня рассчитан на три реализации: 6 файлов, 1 сервис. В отчёт: «цель — 3 площадки (CEO), релиз 1 — 6 файлов (инженерка)». ### Конфликт B: покрытие тестами против срока Разбор. 11 непокрытых веток, закрыть все — 5 дней. По правилу: 3 ветки в расчёте цены со скидкой площадки и 1 в списании остатка закрываем за 1.5 дня, остальные 7 в экспорте XLSX получают `★★` и ждут спринта. Срок соблюдён, риск денег закрыт. ### Конфликт C: дизайн просит оптимистичный UI, инженерка запрещает **Правило:** спрашивай, кто владеет истиной. Оптимистичное обновление разрешено, где операция идемпотентна и обратима локально (пометить прочитанным, добавить тег, сменить сортировку). **Запрещено**, где единственный источник истины — ответ внешней системы: цена на площадке, остаток, статус отгрузки, результат платежа; там вместо оптимизма — явный прогресс и блокировка повторной отправки. Разбор. Дизайн: «после „Обновить цену" карточка сразу показывает новую цену». Инженерка: «площадка применяет цену асинхронно и может отклонить её — пользователь увидит цену, которой нет». Разрешение: новое значение со статусом «отправлено, ожидает подтверждения площадки» и временем последней сверки — мгновенная обратная связь без вранья на экране. ### Конфликт E: молчаливый — этапы не спорят, потому что смотрели разное Самый опасный: выглядит как согласие. Признаки — этапы цитируют формулировки, которых нет в снапшоте; ссылаются на пункты с разной нумерацией; один обсуждает экран, которого другой не видел; оценка объёма у CEO и инженерки различается вдвое. **Правило:** ничего не сводить, зафиксировать снапшот заново, перезапустить разошедшиеся этапы. Отчёт по разным редакциям хуже его отсутствия — он выглядит достоверным. ### Правило по умолчанию, когда готового нет Приоритет у стороны, чья ошибка **необратима**: деньги, ПДн, юридические обязательства и публичные контракты перевешивают удобство, скорость и красоту. Необратимости нет ни у кого — бери вариант, который позволяет узнать ответ дешевле (флаг, канарейка, один сегмент клиентов). ### Неразрешённый конфликт не замалчивается Он идёт в отчёт строкой: суть, позиция каждого этапа, варианты A/B, цена каждого в днях или рублях, кто решает. Вычеркнутый ради красивого отчёта конфликт вернётся на реализации, дороже. ## Шаблон сводного отчёта Проблемы с P 3–11, не попавшие в топ, ставь задачами через `manage_task`: иначе следующее ревью найдёт их заново. ## Российский контекст: где пороги другие - **Маркетплейсы (Ozon, Wildberries, Яндекс Маркет).** План, где цена или остаток уезжает на площадку, получает Н=2 автоматически: неверная цена на карточке — проданный товар по неверной цене, деплоем не чинится. Инженерный этап проверяет пагинацию и поведение при лимитах API площадки, дизайн — что интерфейс показывает время последней успешной синхронизации, а не молча старые данные. - **Учётные системы (1С, МойСклад).** Обмен асинхронный: дизайн, нарисовавший мгновенный результат, конфликтует с реальностью — правило конфликта C. - **Персональные данные.** Новое поле с ПДн или передача их третьей стороне получает И=3 и Н=2 автоматически, а CEO-этап отвечает на «почему сейчас» ещё и в смысле правовых оснований. Номера статей закона не выдумывай — поставь открытый вопрос для юриста. - **Оплата, эквайринг, Битрикс24.** Экран оплаты не бывает «пропустить дизайн-ревью» — всегда полный этап. Двусторонняя синхронизация с CRM — типовой конфликт A: назначь одну систему владельцем каждого поля, это дешевле любой стратегии слияния. ## Режимы отказа самого пайплайна | Симптом | Что на самом деле сломалось | Что делать | |---------|-----------------------------|------------| | У подагента одна проблема, а вердикт «переработка» | `summary` обрезан на ~1200 знаках | читать `full_output_path` | | «Готов» при наличии критической проблемы | свернул средним вместо минимума | пересчитать по min | | В отчёте нет ни одной цифры: файлов, экранов, дней | этапы работали с абстракцией | вернуть на Шаг 0 за объёмом | | Подагент упал с упоминанием бюджета | этап не влез в лимит роли | сузить задачу до одной секции навыка | | Все три этапа выдали «Одобрено» с первого прохода | этапы не искали | ревью без единой проблемы почти всегда поверхностно | --- Source: https://samreshuuu.ru/skills/benchmark_ru # 1. Замер, которому можно верить ## 1.1 Одно измерение — это одна выборка Единичный прогон Lighthouse или `curl -w %{time_total}` — одна реализация случайной величины. Разброс между соседними прогонами на неизменной странице типично 5–15 % по LCP и до 30 % по TBT, поэтому «было 2.9 с, стало 2.6 с» — шум, пока не доказано обратное. Любое число несёт число прогонов, меру разброса и условия; голое число — брак. ## 1.2 Разогрев: что именно греется Первые прогоны медленнее не из-за шума: система в другом режиме. Греются JIT (первая тысяча итераций меряет интерпретатор), пул соединений (первый запрос платит TCP + TLS + аутентификацию Postgres, 5–50 мс), кеш ОС и `shared_buffers` (диск против памяти — порядок величины), кеш браузера и CDN (первый запрос уходит на origin — проверяй HIT/MISS, прежде чем объявлять TTFB). Сколько отбрасывать: страница — 1 прогон; серверный бенчмарк — пока медиана последних 20 наблюдений не перестанет падать; нагрузочный тест — ramp-up 30–60 с. Если интересует **холодный** сценарий (первый визит, рестарт пода), разогрев — враньё: каждый прогон из чистого состояния, и метрика зовётся «холодный LCP». ## 1.3 Сколько прогонов нужно `E` — относительная полуширина 95 % доверительного интервала, `CV = СКО / среднее`. Пример: 10 прогонов дали TTFB 240 мс при СКО 29 мс → CV = 12 %; хочешь различать 5 % → `n = (1.96 × 12 / 5)² ≈ 23`. На 10 прогонах разрешение ±7.4 %, и «ускорили на 5 %» по ним не заявляется. Ориентиры: Lighthouse — 5 прогонов, 9–11 если решение о релизе; микробенчмарк — до стабилизации CV < 5 %; нагрузочный тест — окно ≥ 5 минут. ## 1.4 Шумовой пол: прогон A/A Прежде чем сравнивать «до» и «после», сравни **«до» с «до»**: две независимые серии на неизменённой сборке. Разница их медиан — шумовой пол стенда; порог регрессии ниже него даёт ложные тревоги, которые команда научится игнорировать за две недели. Типично: выделенная машина — 1–3 %, раннер CI — 10–30 %, VPS с соседями — до 50 % на пиках. # 2. Перцентили, а не средние ## 2.1 Почему бизнес интересует хвост 990 запросов по 50 мс и 10 по 5 с дают среднее 99 мс — прилично на вид, но десять человек ждали пять секунд, и это те, у кого больше данных. Сегментируй p95 по размеру аккаунта: доля выручки в хвосте не равна доле запросов в хвосте. ## 2.2 Сколько наблюдений нужно для перцентиля p95 → ≥ 200 наблюдений, p99 → ≥ 1000, p99.9 → ≥ 10 000. При n = 50 «p99» — это максимум, названный красиво. ## 2.3 Перцентили нельзя усреднять Среднее из p95 четырёх подов — не p95 сервиса, среднее p95 по часам — не дневной p95. Складываются только **гистограммы**: `histogram_quantile()` в Prometheus, t-digest, HDR. При этом `histogram_quantile` интерполирует внутри бакета: при границах 0.5 / 1 / 2.5 / 5 с точность оценки p99 равна ширине бакета, то есть ±2.5 с. ## 2.4 Перцентиль запроса ≠ перцентиль экрана Экран, делающий 40 запросов к API, при p99 = 1 % отрисуется медленно с вероятностью `1 − 0.99^40 ≈ 33 %`: «отличный p99» и «треть открытий тормозит» — совместимые утверждения. Формула: `P(медленная сессия) = 1 − (1 − q)^k`. Доводи серверный перцентиль до перцентиля сценария, иначе бэкенд и фронтенд будут спорить, у кого числа правильнее, а правы оба. ## 2.5 Скоординированный пропуск Самая частая причина завышенно-хороших нагрузочных отчётов. Генератор с замкнутым циклом (N потоков, каждый шлёт следующий запрос после ответа) во время затыка просто не отправляет запросы — и не измеряет ожидание, которое испытал бы пользователь, пришедший по расписанию: хвост исчезает тогда, когда он важнее всего. Лечение — генерация с **фиксированной интенсивностью прибытия**: в k6 это `constant-arrival-rate`, а не `constant-vus`; в Яндекс.Танке — генератор с заданным rps. Умеет только потоки — отчёту по p99 верить нельзя. Признак попадания: RPS упёрся в потолок, а p99 не изменился. # 3. Лаборатория против поля **Лаборатория** (Lighthouse, локальный k6, синтетика) воспроизводима и доступна до релиза, но описывает одну придуманную конфигурацию. **Поле** (RUM) описывает происходящее на самом деле, но приходит после релиза и требует объёма. Расходятся закономерно: в лаборатории нет расширений браузера (блокировщики меняют LCP и INP в обе стороны), один профиль CPU против парка, где бюджетный Android медленнее флагмана в 4–6 раз, холодный кеш против тёплого, а INP не измеряется вовсе — Lighthouse даёт TBT как прокси. Правило: **лаборатория ловит регрессии, поле назначает цели.** Порог бюджета берётся из поля (p75 реальных пользователей), проверка на PR — лабораторная, но с порогом по шумовому полу CI. # 4. Core Web Vitals по существу Метрики оцениваются как **p75 полевых данных за скользящее окно 28 дней**, на уровне URL или группы URL, раздельно для мобильных и десктопа: «в среднем проходим» не бывает. Пороги (актуально на 2026-07-28, документация Google по Web Vitals): | Метрика | Хорошо | Требует улучшения | Плохо | |---|---|---|---| | LCP | ≤ 2.5 с | ≤ 4.0 с | > 4.0 с | | INP | ≤ 200 мс | ≤ 500 мс | > 500 мс | | CLS | ≤ 0.1 | ≤ 0.25 | > 0.25 | | TTFB (диагностика) | ≤ 800 мс | ≤ 1.8 с | > 1.8 с | | FCP (диагностика) | ≤ 1.8 с | ≤ 3.0 с | > 3.0 с | TTFB и FCP — не Core Web Vitals: они объясняют LCP, но целью не являются. ## 4.1 LCP раскладывается на четыре части **TTFB** → **задержка до начала загрузки ресурса** (сколько браузер ждал, прежде чем узнал про LCP-элемент: растёт от картинок, вставляемых JS, от `background-image` в CSS, от отсутствия `preload`) → **длительность загрузки** → **задержка отрисовки** (ресурс есть, главный поток занят). Сумма = LCP. Доминирует первая часть — это бэкенд, дальше по `perf_profiling_ru`; вторая — порядок загрузки; четвёртая — JS блокирует отрисовку. Типичные губители на российских проектах: баннер согласия на обработку ПДн поверх контента; шрифты со стороннего CDN; «главное фото товара» из 1С или из выгрузки маркетплейса в исходных 3000 px. ## 4.2 INP заменила FID и меряет другое INP стала Core Web Vital в марте 2024 года, FID выведена из набора в сентябре 2024: FID мерил задержку **до начала** обработки **первого** взаимодействия — его проходили почти все, и о качестве он не говорил ничего. INP берёт примерно худшее взаимодействие за визит и считает время до следующей отрисовки целиком: **input delay** (главный поток занят — гидратация, разбор большого JSON, аналитика), **processing time** (работа обработчиков), **presentation delay** (до кадра). Плохи первая и третья при быстром обработчике — это не «медленный обработчик», а перегруженный главный поток; лабораторный прокси — TBT и число задач длиннее 50 мс. ## 4.3 CLS Сумма худших сессионных окон сдвига (окно ≤ 5 с, разрыв ≤ 1 с), каждое окно = доля сдвинутой площади × доля расстояния; в SPA сумма не сбрасывается при навигации, если не сообщить явно. Портит: изображения и iframe без `width`/`height` или `aspect-ratio`; шрифты со `swap` без метрик подстановки; баннеры (ПДн, промо, «установите приложение») после отрисовки; ленивая подгрузка без зарезервированной высоты. Переход между экранами SPA, готовность таблицы и выгрузку отчёта CWV не измеряют вовсе — им назначай собственные метрики с письменными точками старта и стопа. # 5. Сбор полевых данных Минимальный контур: `web-vitals` в сборке с атрибуцией (возвращает не только значение, но и виновный элемент); отправка через `navigator.sendBeacon` на `visibilitychange` в состояние `hidden` (не на `unload` — на мобильных он часто не срабатывает); хранение сырых событий, а не готовых перцентилей. К каждому событию обязательны: тип устройства, `effectiveType`, регион, шаблон страницы (не URL), новый визит или повторный, версия сборки — без неё ухудшение не связать с релизом. Устойчивый p75 по сегменту требует ≥ 1000 событий: при 300 визитах в день это 3–4 дня, поэтому работай с семидневным скользящим. ## 5.1 Почему CrUX в России показывает не вашу аудиторию CrUX и всё, что на нём построено (полевая часть PageSpeed Insights, отчёт в Search Console), собирает данные **только с Chrome**. В России Яндекс Браузер занимает порядка трети рынка, а на мобильных сопоставим с Chrome или опережает его (Яндекс.Радар, актуально на 2026-07-28). Следствия: CrUX описывает в лучшем случае половину российской аудитории; собственный RUM обязателен, а не желателен; расхождение своего RUM с CrUX на 10–20 % — норма, а не ошибка внедрения. Для аудитории из Яндекса смотри скорость в Яндекс.Метрике и Яндекс.Вебмастере, сравнивая не абсолютные значения между системами, а динамику внутри каждой. # 6. Российская специфика замера **Точка замера важнее инструмента.** Замер из зарубежного дата-центра добавляет к TTFB собственный RTT и меняет вердикт. Мерь с российских площадок (Yandex Cloud, Selectel, VK Cloud, Timeweb) из двух разнесённых точек — Москва и что-то за Уралом; разброс TTFB между ними сразу выдаёт статику, медленную из России. **Одиннадцать часовых поясов растягивают пик.** Суточный профиль — не московский горб, а плато примерно с 06:00 до 20:00 MSK: Дальний Восток работает, когда Москва спит, и профиль по «пиковому часу» занижает длительность. **Ночное окно занято.** Обмен с 1С, выгрузки в МойСклад, синхронизация остатков с Ozon / Wildberries / Яндекс Маркетом идут ночью: замер в 03:00 «когда никого нет» попадает в самый тяжёлый ввод-вывод суток. Сезонный множитель (11.11, «чёрная пятница», декабрь) бери из прошлогодних логов этой компании. **Мобильный сценарий — базовый.** Доля мобильного трафика высокая, 3G за пределами городов ещё встречается; не ослабляй пороги «потому что у нас B2B» — закупщик открывает карточку с телефона. Профиль троттлинга Lighthouse по умолчанию — примерно 150 мс RTT, 1.6 Мбит/с приём, CPU ×4 (в DevTools этот пресет теперь зовётся Slow 4G, раньше Fast 3G). Для региона добавь второй: RTT 250–300 мс, 1 Мбит/с. # 7. Бюджет производительности Бюджет — число, при превышении которого что-то происходит; без последствия это пожелание. ## 7.1 Как назначить **От конкурента**: померь двух-трёх из той же выдачи, возьми лучшее минус 20 % — пользователь сравнивает не с вашим прошлым релизом, а с соседней вкладкой. **От порога**: граница «хорошо» минус запас (цель LCP 2.0 с при пороге 2.5 с) — без запаса вы будете пересекать границу от любого сезонного сдвига. **От текущего состояния**: сегодняшний p75 как потолок — слабейший способ, но применим сразу. ## 7.2 Что бюджетируется | Величина | Где проверяется | Ориентир для старта | |---|---|---| | Начальный JS маршрута, brotli | сборка, в CI | ≤ 200 КБ | | Вес первого экрана / число запросов | синтетика | ≤ 1 МБ / ≤ 50 | | LCP p75, мобильные | RUM | ≤ 2.0 с | | INP p75, мобильные | RUM | ≤ 150 мс | | CLS p75 | RUM | ≤ 0.05 | | p95 ключевых API | серверные метрики | назначается по сценарию | | SQL-запросов на эндпойнт | интеграционный тест | фиксируется числом | Ориентиры стартовые: подмени их числами по 7.1. ## 7.3 Что делать при превышении До 10 % над бюджетом — предупреждение в PR и заведённая задача, слияние разрешено. Свыше 10 % — блокировка до объяснения. Осознанное превышение требует записи: кто разрешил, ради чего, до какой даты. Без даты возврата это не исключение, а тихий пересмотр бюджета. # 8. Замер размера бандла Меряй **передаваемые байты после сжатия**, отдельно brotli и gzip и по маршрутам: общий размер `dist/` бесполезен, первый экран не скачивает всё. Смотреть, помимо суммы: **начальный чанк маршрута** — то, без чего страница не отрисуется, он и есть предмет бюджета; **крупнейшие зависимости в нём** — библиотека дороже 15 % начального веса должна быть разбита, загружена лениво или заменена; **справочники, вкомпилированные в бандл** (регионы, банки, категории маркетплейсов) — сотни килобайт, которым место в сети, а не в JS. Байты — не вся цена. На среднем Android разбор и исполнение обходятся ориентировочно в 1 мс на килобайт несжатого кода: 200 КБ brotli разворачиваются примерно в 700–900 КБ исходника и дают полсекунды-секунду занятого главного потока — это видно в TBT и в input delay. # 9. Замер бэкенда ## 9.2 Как построить реалистичный профиль нагрузки Строй из access-логов за реальное плато: 1. Неделя логов без ботов; берёшь эндпойнты, дающие 95 % запросов (обычно 10–20 маршрутов), и сохраняешь пропорции, а не только суммарный RPS. 2. Отдельно **тяжёлый хвост**: выгрузка отчёта, массовое обновление цен, обмен с 1С — меньше 1 % запросов и половина нагрузки на БД. 3. Перекос в параметрах: равномерный выбор ключей ломает кеш и даёт пессимистичный результат, один и тот же ключ — оптимистичный и бессмысленный. Целевой RPS: `RPS = DAU × сессий_на_пользователя × запросов_на_сессию / длительность_плато_в_секундах`, затем множитель пика из своих логов (максимальная минута к средней; типично 2–4, в распродажу больше). ## 9.3 Почему тест на пустой БД врёт Минимально честный набор: объём таблиц того же порядка, что в проде; сохранённый перекос по ключевым сущностям; `ANALYZE` после наполнения. Лучше всего — обезличенная копия прода, где персональные данные заменены, а не «прикрыты»: ФЗ «О персональных данных» действует и на тестовых стендах. ## 9.4 Инструменты и что снимать Генераторы: k6 (пороги в конфиге, режимы с фиксированной интенсивностью прибытия), Locust, JMeter, Яндекс.Танк (отечественный, генераторы Phantom и Pandora, держит высокие RPS). Режим генерации важнее выбора — см. 2.5. Снимай вместе с латентностью фактический RPS (а не заданный), долю ошибок, насыщение CPU и длину очереди пула. Латентность без доли ошибок бесполезна: система, быстро отвечающая пятисоткой, выглядит быстрой. # 10. Регрессии в CI **Гейтить нужно то, что детерминировано**: время на общем раннере имеет шумовой пол 10–30 %, и порог ниже него превращает проверку в лотерею, которую отключат. Жёстко проверяй: размер чанков после сжатия побайтово; число HTTP-запросов на первый экран; число SQL-запросов на эндпойнт (счётчик в интеграционном тесте — так регрессия вида N+1 ловится до релиза); число прочитанных страниц данных (`BUFFERS`). Зависящие от времени величины — только трендом на выделенной машине, вне гейта PR. Регрессия засчитывается, если разница медиан превышает **максимум из (шумовой пол × 2) и 5 %** и подтверждена односторонним критерием Манна — Уитни, `p < 0.05`. Расчёты — через `repl_execute`, регулярный замер — через `manage_task` с `trigger_type='schedule'`. # 11. Формат отчёта Раздел «ограничения» обязателен: замер всегда чего-то не видит, и если не назовёшь этого сам, это сделает тот, кому результат не понравился. Полевая метрика несёт выборку и сегмент: «LCP p75 = 2.3 с, мобильные, 14 200 событий, 7–13 июля». --- Source: https://samreshuuu.ru/skills/deploy_ru ## 1. Шесть вопросов до нажатия кнопки 1. **Что именно едет?** Тег или диапазон коммитов: `v1.8.377`, `a887c26..982e407`. «Предыдущая версия» не адрес, и откатывать будет нечего. 2. **Меняется ли схема БД?** Если да — схема и код это две отдельные выкатки (раздел 3), самый частый источник невозможного отката. 3. **Новые переменные окружения, секреты, ключи коннекторов?** Проставлены ли в проде *до* кода: приложение, падающее на старте из-за отсутствующего `YOOKASSA_SHOP_ID`, уходит в цикл рестартов и роняет группу под rolling. 4. **Что с текущими соединениями?** Воркер, получивший SIGTERM посреди задачи и не умеющий вернуть её в очередь, теряет работу пользователей молча. 5. **Обратима ли выкатка вообще?** См. 6.4: рассылка, списание, необратимая миграция — план восстановления пишется до, а не после. 6. **Кто на связи ближайшие 2 часа и подходящий ли сейчас час?** Не «команда уведомлена», а человек с правами на откат; про час — раздел 7. Нет ответа на 1, 2 или 5 — выкатка не готова. Это вердикт, а не пожелание. ## 2. Стратегии: выбирай не по риску, а по требованиям к приложению Стратегия — не уровень осторожности, а набор требований. Стратегия, требований которой приложение не выполняет, риск не снижает, а добавляет новый. ### 2.1 Прямая замена Простой равен времени старта и прогрева. Взамен — единственный момент, когда работает ровно одна версия: только здесь можно безопасно катить схему, несовместимую с прошлым кодом. ### 2.2 Rolling update **Требует главного и почти всегда забываемого: версии N и N+1 должны одновременно работать с одной схемой БД и одним форматом сообщений в очередях** — это ограничение важнее самой стратегии. Новая версия читает колонку, которой ещё нет, — половина запросов падает всю раскатку. Новая версия кладёт в очередь новый формат, старый консьюмер его не разбирает — задачи теряются, и потеря не видна в HTTP-метриках. Требует также readiness-пробы, graceful-периода больше самого долгого запроса и согласования `maxSurge` с пулом коннектов: 10 подов × 20 коннектов при `maxSurge: 100%` дают 400 вместо 200 — лимит Postgres упрётся на середине выкатки. ### 2.3 Blue-green Полная вторая среда, переключение одним движением, старая остаётся живой — откат за секунды. Требует двойной ёмкости на время переключения (в российском облаке это прямые деньги — посчитай) и решённого вопроса про БД: общая возвращает вас к требованию 2.2, отдельная означает, что записанное после переключения при откате потеряется без обратной репликации. ### 2.4 Канареечная 1% → 10% → 50% → 100% с паузами 15 мин / 30 мин / 1 час; для релизов, меняющих расчёты, паузы удлиняй — такие ошибки видны не в 5xx, а в жалобах. Требует того, о чём вспоминают последним: **трафика, при котором 1% что-то значит.** При 20 запросах в минуту 1% — это три запроса за 15-минутную ступень, то есть гадание, а не эксперимент; ниже примерно 500 запросов в минуту суммарно начинай с 10%. Требует также липкости сессии (иначе человек увидит два поведения подряд и принесёт баг, который не воспроизводится) и раздельных метрик по версиям: без разделения 1% ошибок утонет в 99% нормы. ### 2.5 Выбор | Ситуация | Стратегия | |---|---| | Текст, конфиг, стили | Прямая или rolling — цена ошибки ниже цены церемонии | | Обычная фича, схема не менялась | Rolling | | Схема поменялась несовместимо | Прямая, в окно простоя: единственный момент, когда версия одна | | Деньги, платежи, начисления | Blue-green: откат должен занимать секунды | | Крупная фича, трафик есть | Канареечная: ошибка достанется 1%, а не всем | | Крупная фича, трафика мало | Rolling + фича-флаг: долю задаёт флаг, а не роутер | ## 3. Схема БД едет отдельно от кода ### 3.1 Почему отдельно Код откатывается за минуту — старый образ никуда не делся. Схема не откатывается полностью никогда: данные, записанные новой версией, уже есть, а `DROP COLUMN` уничтожает их безвозвратно. Пока схема и код едут одной кнопкой, откат кода означает откат схемы, а откат схемы — потерю данных. **Выкатка схемы — отдельное событие раньше кода, и схема обязана быть совместима со старым кодом.** Тогда откатывать нечего, кроме кода. ### 3.2 Экспансия — миграция — сжатие **Экспансия** — добавь новое, не удаляя старого: колонка nullable или с константным дефолтом, таблица, индекс. Старый код работает, потому что про новое не знает. **Миграция** — код пишет в оба места и читает из нового с падением обратно на старое; параллельно идёт backfill истории. **Сжатие** — код перестаёт писать в старое место, и отдельным релизом, **не раньше, чем исчезнет нужда откатываться на версию, читающую старое поле**, старое удаляется. Здесь торопятся и получают невозможный откат. `RENAME COLUMN` мгновенен и выглядит невинно, но несовместим с любой стратегией без простоя: переименование — три релиза. ### 3.3 Что блокирует таблицу в Postgres и как обойти Этот список важнее знания стратегий: блокировка на горячей таблице кладёт сервис целиком, а не частично. | Операция | Что делает | Обход | |---|---|---| | `CREATE INDEX` | Блокирует запись на всё время построения | `CONCURRENTLY`: дольше, вне транзакции, при сбое оставляет невалидный индекс — удалить и повторить | | `ADD COLUMN` с volatile-дефолтом (`now()`, `gen_random_uuid()`) | Переписывает таблицу | Nullable → заполнить пачками → поставить дефолт | | `ADD COLUMN` с константным дефолтом | В современном Postgres быстро, без переписывания | Можно напрямую, сверившись с версией сервера | | `SET NOT NULL` | Полный скан под тяжёлой блокировкой | `CHECK (col IS NOT NULL) NOT VALID` → `VALIDATE CONSTRAINT` → `SET NOT NULL` примет уже проверенный CHECK | | `ADD FOREIGN KEY` | Блокирует обе таблицы на время проверки | `NOT VALID`, затем отдельным шагом `VALIDATE` | | `ALTER COLUMN TYPE` | Переписывает таблицу и индексы | Новая колонка + зеркалирование + переключение; расширение `varchar` вверх — дешёвое исключение | | `DROP COLUMN` | Мгновенно, но данные недоступны | Опасность не в блокировке: старый код с `SELECT *` и колонкой в ORM-модели упадёт после отката | В MySQL логика та же, инструмент другой: `ALGORITHM=INPLACE, LOCK=NONE`, а где он не поддерживается — `gh-ost` или `pt-online-schema-change`. ### 3.4 lock_timeout — главная строчка любой миграции `ALTER TABLE`, ждущий тяжёлой блокировки, встаёт в очередь, и всё, что приходит после, встаёт за ним — включая обычные `SELECT`. Один долгий отчёт плюс ваш `ALTER` — и сервис лежит целиком, хотя таблица «просто добавляла колонку». Не удалось — миграция падает быстро и безвредно, повторяете через минуту. Без `lock_timeout` она не падает, а ждёт, собирая за собой очередь. ### 3.5 Долгий backfill Backfill — не миграция, а фоновая работа: единый `UPDATE` на миллионы строк держит транзакцию часами, раздувает WAL, блокирует автовакуум и при обрыве откатывает всё. Пачками по первичному ключу (5–50 тыс. строк, чтобы пачка укладывалась в секунду-две), с паузой между пачками, с курсором в отдельной таблице для возобновляемости, отдельной задачей — миграция обязана завершаться за секунды. Признаки, что идёт не так: растёт лаг реплики, растут `n_dead_tup`, растёт WAL-каталог; лаг перевалил единицы секунд — увеличивай паузу, а не размер пачки. ### 3.6 Почему откат схемы не симметричен `ADD COLUMN` обратим ценой всего, что в колонку записали; разбиение колонки — только если склейка однозначна; нормализация справочника необратима, если схлопнули дубликаты; смена типа обратима, только если не терялась точность. ## 4. Фича-флаг вместо отката Откат отменяет весь релиз: сломалось одно изменение из десяти — уезжают и девять исправных, а флаг выключает одно. Флаг ещё и отделяет момент выкатки от момента включения: код едет в спокойное окно, фича включается в понедельник утром, когда все на месте. **Фича, видимая пользователю и выключаемая строчкой конфига, едет за флагом** — особенно изменения в расчётах: формула комиссии, алгоритм подбора, логика начисления. Правила: у флага есть владелец и срок жизни, а удаление планируется тем же релизом, что и включение на 100% (флаг старше пары месяцев — мёртвая ветка, которую никто не тестирует); флаг проверяется в одном месте, а не в сорока, иначе выключение оставит систему в состоянии, которого не было ни до, ни после; аварийное выключение отдельно от процентного раскатывания; состояние флагов пишется в запись о выкатке. Флаг не откатывает данные: сотня строк в новом формате останется, и старый код должен уметь их прочитать или хотя бы не падать; писем он не отзывает и бесполезен, если ошибка в общем коде обеих ветвей. ## 5. Наблюдение ### 5.1 Пять сигналов — и почему именно они 1. **Доля ошибок** (5xx, необработанные исключения, отвалы фоновых задач) — «работает ли вообще». 2. **Задержка p95 или p99, не среднее**: среднее не двигается, когда ломается один эндпоинт из двадцати. 3. **Насыщение** (CPU, память, коннекты к БД, глубина очереди) — «доживёт ли до вечера»: растущая память при ровных ошибках убьёт сервис через час, а не сейчас. 4. **Поток запросов** — объясняет остальные три: ошибки упали до нуля не потому, что починилось, а потому что балансировщик перестал слать трафик. 5. **Новые строки в логах**: сообщение, которого не было вчера, появляется раньше, чем деградация станет видна в долях. ### 5.2 Технические метрики против бизнесовых Технические реагируют за секунды и врут в сторону «всё нормально»; бизнесовые — за минуты и часы, но показывают то, что стоит денег. Классика: 5xx на нуле, задержка в норме, CPU ровный, а кнопка оплаты не отрисовалась из-за ошибки в JS, и заказы перестали создаваться. HTTP-метрики этого не увидят никогда, увидит счётчик «заказов в минуту». Поэтому на каждую выкатку заранее назови **один бизнесовый счётчик**, который обязан продолжать расти, и сравнивай его с тем же часом прошлой недели: минус 40% оформлений в 3 часа ночи — норма, в 14:00 вторника — инцидент. ### 5.3 Сколько ждать и что считать шумом Правило для малых чисел: если за окно прошло N запросов и ошибок не было ни одной, это значит лишь, что доля ошибок с высокой вероятностью ниже 3/N. Триста запросов без ошибок дают «меньше 1%» — при базовой норме 0.1% это не подтверждает ничего. Одна ошибка на 30 запросов — 3.3% на дашборде и ноль информации: не откатывайся, но прочитай трейс. Чтобы уверенно поймать рост доли ошибок с 0.1% до 0.5%, нужны тысячи запросов, то есть при 50 запросах в минуту — час, а не пять минут. Горизонты: **0–5 минут** — старт, рестарты, новые сообщения в логах: ловятся отсутствующие переменные окружения, несовместимость схемы, сломанная сборка. **5–30 минут** — доли ошибок и задержка на реальном трафике, очереди, лаг реплики: регрессии производительности. **30 минут – 2 часа** — память, коннекты, кэши: утечки и исчерпание пулов. **Первые сутки** — бизнес-метрики, ночные задания, обращения в поддержку: всё, что не ломается, а тихо считает неправильно. Пока не закрылось второе окно, релиз не «выкачен», а «наблюдается». ### 5.4 Пороги | Сигнал | Норма | Наблюдать | Откат | |---|---|---|---| | Доля 5xx | базовая линия | ×2 и статистически значимо | ×5, либо любые 5xx на платежах и авторизации | | p95 | ±10% | +30% | +100% или упирается в клиентский таймаут | | Рестарты | 0 | 1 разовый | цикл рестартов | | Память | плато | растёт линейно | приближается к лимиту и растёт | | Глубина очереди | разбирается | растёт медленнее, чем разбирается | растёт монотонно 10 минут | | Бизнес-счётчик | ±15% к тому же часу прошлой недели | −25% | −50% | «Любые 5xx на платежах» — не преувеличение: на платёжном пути один процент это не процент, а конкретные люди с деньгами. ### 5.5 Медленное отравление Отдельный класс поломок не виден ни в одном пороге: релиз работает, но пишет неправильные данные — неверный часовой пояс, потерянный знак в расчёте, перепутанные единицы, отвалившийся коннектор, из-за которого выгрузка в 1С молча уходит пустой. Ловится ровно одним способом: посмотреть на несколько свежих записей глазами и сравнить со вчерашними. Три заказа, три платежа, три строки выгрузки — три минуты работы, и ловит то, чего не поймает ни один дашборд. ## 6. Откат ### 6.1 Критерии немедленного отката Сервис не поднимается или циклически рестартует. Любые ошибки на пути авторизации, оплаты, оформления заказа. Доля 5xx выше базовой в пять раз дольше двух минут. Данные пишутся неправильно — это хуже недоступности, потому что недоступность прекращается с откатом, а испорченные данные остаются. И самый игнорируемый критерий: **ты не понимаешь, что происходит.** ### 6.2 Почему отладка в проде дороже отката Перед откатом потрать 60 секунд на улики — снимок логов, значения метрик, пример упавшего запроса: после отката они уйдут из горячего хранилища или перемешаются со старой версией. ### 6.3 Откат по слоям Лестница с разной ценой: иди сверху вниз и остановись на первом шаге, который решает проблему. ### 6.4 Что делает откат невозможным - **Необратимая миграция**: удалённая колонка или таблица, схлопнутые дубликаты, потеря точности при смене типа. - **Отправленные наружу сообщения**: письма, пуши, Telegram, СМС. Ошибка в шаблоне рассылки не откатывается — она компенсируется вторым письмом, и это письмо тоже надо написать. - **Проведённые платежи и фискальные документы**: чек не удаляется, он аннулируется отдельным документом — отдельный процесс со своими сроками. - **Данные, ушедшие во внешние системы**: документы в 1С, отгрузки в МойСклад, изменённые через API цены и остатки на Ozon и Wildberries. Маркетплейс принял ваши цены — откат кода их не вернёт, нужна обратная выгрузка, и её готовят заранее. - **Записи в неизменяемых журналах** и всё, что уже прочитали внешние потребители по вебхукам. Односторонний релиз катится отдельно, маленьким, с флагом или ограничением масштаба — сначала одна организация, потом десять, потом все. Не смешивай его с двадцатью обычными изменениями: лишите отката все двадцать. ### 6.5 Компенсация вместо отката Когда откат невозможен, план восстановления — это компенсация, описанная до выкатки, и она отвечает на три вопроса: как найти пострадавшие записи (конкретный запрос, а не «поищем»), как их исправить и что сказать затронутым людям. Пример: релиз ошибочно начислил бонус существующим аккаунтам вместо новых. Откат кода начисление не отменяет — отменяет компенсирующая проводка: миграция, которая списывает начисленное с ограничением по фактическому остатку и намеренно **не** сбрасывает флаг «награда выдана», иначе следующая выкатка начислит бонус второй раз. ## 7. Окно выкатки и российская сезонность Не катить в пятницу после обеда, в предпраздничный день и в последний час рабочего дня: проблема, всплывшая через шесть часов, обнаружится, когда автора уже нет. Катить в начале дня, лучше вторник или среда. Ночная выкатка оправдана только там, где нужен простой, и её цена — сонный человек и никого рядом. Не катить поверх незакрытого инцидента и не катить два релиза сразу: при поломке вы не будете знать, чей это релиз. Календарь запретов; даты сверяй с календарём года, сроки отчётности — с бухгалтерией клиента (актуально на 2026-07-28). - **Конец месяца и первые дни следующего** — закрытие периода, сверки, акты, зарплата: сбой выгрузки документов в 1С 30-го числа стоит дороже, чем 12-го. - **Налоговые даты.** В режиме единого налогового счёта ключевые числа месяца — 25-е (уведомления и большинство деклараций) и 28-е (уплата); сервисы учётного контура в эти дни не трогают. - **Конец квартала** — март, июнь, сентябрь, декабрь: сверху квартальная отчётность. - **Распродажи маркетплейсов**: 11.11, конец ноября, первая половина декабря, пики перед 23 февраля и 8 марта, школьный август. Неверная цена, уехавшая на Ozon или WB в пик, — убыток за минуты, и откат вашего кода его не вернёт. - **Январские и майские каникулы** — по нагрузке отличное окно, по доступности людей худшее: катите, но с явным дежурством. Понедельник утром — пик у B2B, вечер пятницы — у B2C. Пользователь настаивает на стоп-дне — не спорь, предложи компромисс: только за флагом, выключенным по умолчанию, с включением после окна. ## 8. Артефакты ### 8.1 Запись о выкатке Заводится до выкатки, дополняется по ходу, сохраняется документом (`documents`): понадобится при разборе через месяц. Строка «Отклонения» обязательна и при успехе: выкатка, прошедшая с отклонением, — это будущий инцидент, о котором уже есть информация. ### 8.2 Разбор инцидента без поиска виноватого Пишется по каждому откату и по каждой выкатке, потребовавшей внепланового вмешательства. **Разбирается система, а не человек:** фамилия в роли причины означает, что разбор написан неправильно, потому что «человек ошибся» не порождает исправления. Правильная формулировка — «изменение переменной окружения не проверялось ничем, кроме внимательности». Время до обнаружения и время до восстановления лечатся разным: первое — наблюдением и алертами, второе — отработанным откатом. Команда, считающая только общее время, чинит не то. ## 9. Правила работы Инструменты по шагам: `sandbox_bash` — диапазон коммитов (`git log`), команды выкатки, логи и миграции, `repl_execute` — базовая линия и значимость роста ошибок, `web_fetch` — health-эндпоинт, `browser_interact` — смоук по сценариям (о сломанном фронтенде технические метрики молчат), `documents` — запись и разбор, `manage_task` (`trigger_type='schedule'`, `run_once`) — проверки на +2 и +24 часа, `manage_memory` — базовые линии и постоянные ограничения («по 25-м и 28-м числам выкаток по учётному контуру нет»), `message_compose` — уведомления. Названия метрик и дашбордов клиента не выдумывай: спроси, где они лежат, или работай по логам. --- Source: https://samreshuuu.ru/skills/design_consultation_ru # Дизайн-система: построить с нуля или привести в порядок ## 1. Сначала посчитай, окупается ли **Не нужна вовсе:** меньше 15 новых экранов на полгода и 1–2 фронтендера; один продукт, бренд и тема; фаза поиска модели с выбрасыванием экранов раз в две недели. Замена: 30–50 строк CSS-переменных, три компонента (кнопка, поле, карточка), одностраничный DESIGN.md — 1–2 дня и 80% пользы. «Система не нужна» — правильный ответ, а не отказ от работы. **Обязательна** при любом из: ≥ 3 человек пишут UI; ≥ 30 экранов; два продукта на одном бренде (кабинет, приложение, виджет в Битрикс24); нужна тёмная тема, вторая плотность или white-label; UI отдаётся интеграторам — система работает как контракт. ## 2. Инвентаризация: посчитай реальный разнобой Начинай с измерения — `sandbox_bash` в клоне (`git clone --depth=1`): | Показатель | Здорово | Тревожно | Разнобой | |---|---|---|---| | Уникальных цветов | ≤ 40 | 40–90 | > 90 | | Уникальных px-значений | ≤ 15 | 15–30 | > 30 | | Начертаний шрифта | ≤ 3 | 4 | ≥ 5 | | Радиусов / теней | ≤ 4 | 5–8 | ≥ 9 | | Файлов с inline `style={{}}` | ≤ 5% | 5–15% | > 15% | ## 3. Три уровня токенов Тема — переопределение **ролей**, не значений. `bg-gray-50` в компоненте для тёмной темы расходится на три исхода (фон страницы `gray-950`, карточка `gray-900`, разделитель `gray-800`) — ручной проход по всему коду, ровно то, что система должна была отменить. С ролями тема — один блок: ## 4. Палитра **Тёмная тема — зеркало лестницы:** роль со ступени `N` в тёмной указывает на `1000 − N` того же тона. Поправки: насыщенность акцента (`C`) −10–20%, иначе звенит на тёмном; фон страницы `900`–`950`, но не `#000000` (ореолы на OLED). Тени в тёмной теме почти не работают — иерархию поверхностей передавай светлотой фона и границей. Состав: нейтраль и бренд по 11 ступеней, интенты success/warning/danger/info по 4–5, отдельная палитра графиков (6–8 цветов, различимых при дейтеранопии) — красный в графике значит категорию, а не ошибку. ## 5. Контраст: проверяемое требование Минимумы (WCAG 2.1/2.2 AA; ГОСТ Р 52872-2019 гармонизирован с ними): обычный текст **4.5:1**; крупный (≥ 24 px или ≥ 18.66 px полужирного) **3:1**; границы полей, иконки-действия, индикаторы состояния, фокус-кольцо **3:1** к соседнему фону. Стабильные провалы: `text-muted` на цветной поверхности (серый рассчитан на белый, на `bg-info-subtle` ~3:1); белый текст на кнопке-warning (жёлтый/оранжевый 500 почти никогда не держат 4.5:1); граница поля `gray-200` на белом (~1.5:1 — поля невидимы); состояние, закодированное только цветом (красная рамка без иконки не читается при дальтонизме). Фокус-кольцо — один токен `--color-focus-ring` (3:1 к обеим поверхностям) и `:focus-visible`; снятие `outline` без замены — дефект. ## 6. Типографическая шкала Для интерфейсов отношение **1.2**, реже 1.25; 1.333 и 1.5 — лендинги. 1.333 от 16 px (16 → 21.3 → 28.4 → 37.9) не даёт промежуточных размеров плотного интерфейса — их добирают на глаз, отсюда 40 уникальных размеров из инвентаризации. 1.2 даёт 16 → 19.2 → 23 → 27.6 → 33.2 — 7–8 значений. | Токен | Размер | Line-height | Назначение | |---|---|---|---| | `text-xs` | 12 | 16 | служебные метки, единицы измерения | | `text-sm` | 14 | 20 | подписи полей, плотные таблицы | | `text-base` | 16 | 24 | основной текст, поля ввода | | `text-lg` | 20 | 28 | заголовок карточки, метрика | | `text-xl` | 24 | 32 | заголовок раздела | | `text-2xl` | 30 | 38 | заголовок страницы | **Поля ввода на мобильных — не меньше 16 px**: Safari на iOS зумит страницу при фокусе в меньший кегль. Начертаний ≤ 3 (400/500/700), длина строки 60–75 знаков (`max-width: 65ch`). ## 7. Кириллица **Русский текст на 10–15% длиннее английского**, интерфейсные слова — вдвое (Save → «Сохранить»). Кнопки — от контента с `min-width`; в библиотеке держи пример с самой длинной реальной русской подписью. «Й» и «Ё» несут надстрочные знаки, и `line-height: 1` (`leading-none` для крупных заголовков) их обрезает. Минимум для заголовков — **1.15–1.25**. Безопасный выбор: **Golos Text** (Paratype, SIL OFL, свободен и для коммерции), **PT Sans / PT Mono**, **Inter**, **Manrope**, **Onest**. Фирменные шрифты экосистем и банков лицензированы под владельцев. Числа и текст: - **₽ (U+20BD)** в урезанных сабсетах отсутствует — «тофу» (□). Не вырезай при сабсеттинге; формат — `1 250 ₽` с неразрывным пробелом. - **`font-variant-numeric: tabular-nums`** обязателен для колонок с суммами и процентами — токен системы, а не решение автора таблицы. - **`hyphens: auto` работает только с `lang="ru"`**; для артикулов — `overflow-wrap: anywhere`. - **`uppercase`** на кириллице — только с `letter-spacing: 0.04em`. **«ё»** в подписях пишется, в поиске нормализуется, иначе «Королёв» не найдётся по «Королев». ## 8. Сетка, отступы, правило внутреннего и внешнего База — **4 px** (восьмипиксельная груба: между иконкой и текстом в строке таблицы нужно 4 или 6). Шкала: 0, 2, 4, 8, 12, 16, 20, 24, 32, 40, 48, 64, 80; значений вне шкалы в коде быть не должно. Радиусов четыре (`none`, `sm` 4–6, `md` 8–10, `full`), внешний радиус = внутренний + отступ между ними. Теней ≤ 4, каждая привязана к уровню поверхности. **Расстояние между элементами всегда меньше расстояния вокруг группы** — единственный механизм, по которому глаз понимает принадлежность. Подпись от поля 8 → поле от следующей пары 16 → группа от секции 32; соотношение соседних уровней ≥ **1.5×**. Самый частый дефект: подпись прижата к предыдущему полю сильнее, чем к своему, — форма читается со смещением на строку. Сетка: десктоп 12 колонок, gutter 24, максимум 1200–1440; мобильный 4 колонки, gutter 16. Брейкпоинты 640 / 768 / 1024 / 1280 / 1536, и обязательно **360 px** — большая доля бюджетных Android у российской аудитории; макет с 390 ломается на 360 в длинных русских подписях. ## 9. Состояния компонента: полный набор Интерактивный элемент: `default`, `hover`, `active`, `focus-visible`, `disabled`, `loading`, `selected`, `error`, `read-only`. Контейнер данных: `loading` (скелетон по размеру реального контента), `empty` (как наполнить), `no-results` (кнопка сброса фильтра), `error` (причина + «повторить»), `partial`, `overflow`. Забывают, в порядке частоты: 1. **`focus-visible`** — снесли `outline` ради вида, клавиатурная навигация умерла. 2. **`no-results` отдельно от `empty`** — «У вас пока нет заказов» при активном фильтре читается как потеря данных. 3. **`loading` на кнопке** — без блокировки повторного нажатия форма уходит дважды; в биллинге это двойное списание. 4. **`disabled` без объяснения причины.** 5. **Длинный контент** — обрезка, перенос или сжатие соседей выбраны, а не случились. 6. **Hover на таче** (залипает после тапа — `@media (hover: hover)`) и **`prefers-reduced-motion`**, выключающий анимации целиком. Комбинаций «варианты × размеры × состояния» у кнопки 4×3×10 = 120: их не рисуют, **их генерируют** циклом по спискам, чтобы новый вариант сам появился везде. ## 10. Именование Формат: `<категория>-<роль>-<модификатор>-<состояние>` (`color-border-input-invalid`). Имя описывает **роль**, не вид: `color-text-danger`, не `color-text-red` — при смене красного на терракотовый `red` станет ложью. Не кодируй значение в имени: `space-16` запрещает менять шкалу. Модификаторы интенсивности фиксируй заранее — `subtle` → `default` → `emphasis` → `inverse`; пропсы по ролям (`variant`, `size`, `tone`) — булевы (`isPrimary`, `isDanger`) допускают невозможные сочетания. Имена `primary2`, `blueNew`, `cardV2` значат: нужной роли нет — заведи её, а не наращивай суффикс. ## 11. Документация, которой пользуются Мёртвая документация — картинки компонентов: картинка расходится с кодом в день правки. Живая — генерирует таблицу токенов из файла токенов, показывает компонент живым и матрицей состояний рядом с копируемым кодом, называет случаи **когда компонент НЕ применять** (самая полезная и почти всегда отсутствующая секция) и записывает решения с причинами: не «радиус 8», а «радиус 8, потому что при 12 в плотных таблицах углы съедают строку». Правило, которое нельзя проверить линтером, будет нарушено. Документ живёт рядом с файлом токенов (`edit_file`), не в вики. ## 12. Внедрение без остановки разработки - **Фаза 0 (0.5 дня). Инвентаризация** — раздел 2: таблица разнобоя, базовая метрика. - **Фаза 1 (1–2 дня). Токены поверх существующего** — 15–20 доминирующих значений: визуально ничего не меняется, появляется словарь, ноль конфликтов с чужими ветками. - **Фаза 2 (2–3 дня). Семантический слой и тема** — роли + переопределения тёмной, даже если тема пока не включается. - **Фаза 3 (5–10 дней). Ядро компонентов** по частоте: почти всегда Button → Input → Select → Modal → Table → Toast; первые три покрывают половину вхождений. Частоту даёт `rg -o '<[A-Z][A-Za-z]+' src | sort | uniq -c | sort -rn`. - **Фаза 4 (постоянно). Миграция по правилу касания** — новый код только на системе, старый переписывается, когда его открыли по задаче. - **Фаза 5. Гард в CI** — запрет новых hex вне токенов на изменённых строках: ## 14. Шаблон DESIGN.md Отдавай заполненным: раздел, где нечего написать, — нерешённый вопрос. ## 15. Протокол работы Не предлагай непроверяемого. Вместо «улучшить визуальную иерархию» — какой токен на каком элементе меняется, с какого значения на какое и по какому измеримому признаку станет видно улучшение. --- Source: https://samreshuuu.ru/skills/design_review_ru ## 1. Вход По плану текстом проверяемы полнота состояний, навигация и копирайтинг; по скриншоту добавляются иерархия, плотность и контраст; по живому URL — всё остальное. Половина классов дефектов (фокус, табуляция, долгий ответ, переполнение реальными данными) в макете не существует, поэтому живой экран даёт вдвое больше находок. Интерфейс в проде — проси URL. Не начинай, пока не знаешь: **кто пользователь**, **какую задачу решает на этом экране**, **как часто**. Экран, который бухгалтер открывает раз в квартал, и экран, который менеджер маркетплейса открывает 40 раз в день, оцениваются по-разному: первому нужна подсказка у каждого поля, второму — минимум кликов. Нет данных — спроси через `request_form`. ## 2. Ревью живого интерфейса Схему «было / стало» показывай прямо в разговоре через `render_visual(title=..., html=...)`: пространственное сравнение должно объяснять предложенную перестановку блоков. Правила композиции и взаимодействия — в описании инструмента, загруженного через `tool_search`; уточнения той же схемы передавай с её `artifact_id`. `analyze(kind="describe")` вытащит из скриншота фактические цвета и размеры, `analyze(kind="ocr")` — если прислали фотографию экрана телефона. ## 3. Десять измерений **Ниже 7 — когда найден хотя бы один признак дефекта из списка измерения; 3 и ниже — когда найден блокирующий.** Ни одного — 8; 9–10 только если можешь сказать, чем решение лучше типового. Измерения 4–8 (доступность, адаптивность, пустые состояния, загрузка, ошибки форм) — в разделах 5–9. ### 3.1 Навигация и информационная архитектура **Ниже 7:** главное действие глубже трёх шагов; два раздела с пересекающимся смыслом («Отчёты» и «Аналитика»); отфильтрованный список нельзя переслать ссылкой. **Блокирует:** «назад» выбрасывает из мастера в начало и стирает введённое; после сохранения нет пути к списку. ### 3.2 Визуальная иерархия **Ниже 7:** больше 4 размеров текста на экране; две кнопки-призыва одинаковой яркости рядом; цветом размечено больше трёх смыслов, и цвет перестал что-либо значить; отступы между несвязанными блоками меньше, чем внутри блока. **Блокирует:** деструктивное действие («Удалить», «Отменить заказ») выглядит как основное и стоит рядом с ним. ### 3.3 Единообразие **Ниже 7:** «Товар», «Позиция» и «SKU» про один объект; подтверждение в диалогах то справа, то слева; дата в таблице и карточке в разных форматах. **Блокирует:** одинаково подписанное действие даёт разный результат — «Сохранить» в одной форме публикует, в другой оставляет черновик. ### 3.9 Обратная связь **Ниже 7:** кнопка не меняется после нажатия, и её жмут второй раз (проверь, создаются ли две сущности — это уже баг данных); уведомление об успехе исчезает за 1,5 с; анимация дольше 300 мс на действии, которое повторяют десятки раз за смену. **Блокирует:** необратимое действие без подтверждения и без отмены — удаление карточек товара, рассылка клиентам, смена цен на всём остатке. ### 3.10 Контент и копирайтинг **Ниже 7:** «ОК» и «Готово» там, где непонятно, что произойдёт; подсказка дублирует подпись («Email» — «введите email»); «синхронизация вебхуков» в интерфейсе для бухгалтера; текст обвиняет пользователя. **Блокирует:** надпись на кнопке не соответствует её действию. ## 5. Доступность: пороги ### 5.1 Контраст WCAG 2.2, уровень AA: **4.5:1** — обычный текст; **3:1** — крупный (от 24px обычного или 18.66px полужирного); **3:1** — границы полей, смысловые иконки, индикатор фокуса, элементы графиков. Декор и выключенные контролы порогом не связаны. Типовой провал: серый `#9CA3AF` на белом даёт 2.54:1 — а это подписи полей, плейсхолдеры и вторичный текст, то есть то, что читает пожилой бухгалтер на ноутбуке у окна. Плейсхолдер вместо подписи — двойной дефект: и контраст, и исчезающая при вводе подсказка. Красный текст ошибки на белом обычно проходит, красная рамка поля — часто нет, и единственный признак ошибки для слабовидящего пропадает. ### 5.2 Размер цели Минимум — **24×24 CSS-пикселя** (WCAG 2.2 AA), считается вся кликабельная область, а не иконка. Ориентир там, где работают с телефона: **44×44 pt** (Apple) / **48×48 dp** (Material), между соседними целями от 8px. Крестик 16×16 без padding — самый частый дефект класса; смотри размер, вычисленный браузером, а не картинку. ### 5.3 Клавиатура и фокус 1. Виден ли фокус на каждом шаге? `outline: none` без замены — блокирующий дефект. 2. Совпадает ли порядок фокуса с визуальным? Расходится из-за `order` во flex/grid и положительных `tabindex`: колонки поменялись местами, а фокус идёт по DOM. 3. Ловушка фокуса: в модальном окне нужна, вне его — дефект. 4. Возвращается ли фокус на элемент, открывший окно, после закрытия? Иначе после Esc человек оказывается в начале страницы. Достижим ли крестик с клавиатуры? 5. Есть ли ссылка «к основному содержимому»? Без неё клавиатурный пользователь проходит всё меню на каждой странице. ### 5.4 Что именно ломает скринридер - кнопка без доступного имени (``) читается как «кнопка», назначение неизвестно; - поле без связи с подписью (`