Как оформить баг-репорт

Как открыть форму бага

В проблемной Теме отправьте /diag.

Limerence попросит описать проблему одним сообщением.

Также появится кнопка «📎 Приложить снимок Темы» и «❌ Отмена».

В самом приглашении Limerence показывает шаблон описания — четыре строки, которые копируются одним касанием и заполняются поверх.

Как правильно описать баг

Хорошее описание должно ответить примерно на четыре вопроса:

• Что я сделал?
• Что произошло?
• Что должно было произойти?
• Можно ли повторить проблему?

Не нужно писать техническое расследование самостоятельно.

Вам не требуется угадывать:

«Наверное, у вас MongoDB не синхронизировала индекс после race condition».

Это работа диагностики. Нам важнее получить точные наблюдения.

Хороший пример

В Теме «Адриан» нажала «Ещё вариант» на последнем ответе. Появился второй вариант, выбрала его и продолжила игру. Через два сообщения сделала /undo 1. После отката снова показывается первый вариант ответа, хотя выбран был второй. Повторила два раза — происходит одинаково. Ожидала, что после Undo останется выбранный вариант.

Здесь есть:

• конкретная Тема;
• конкретное действие;
• результат;
• ожидаемый результат;
• информация о повторяемости.

Это великолепный баг-репорт.

Плохой пример

Не работает.

Из него можно уверенно установить только один факт: что-то где-то кому-то не понравилось.

Ещё один плохой пример

Память опять говно.

Эмоционально понятно. Диагностически — практически бесполезно.

Гораздо лучше:

В сообщении №... персонаж узнал, что Марк погиб. Через несколько ходов я исправила это через OOC → «Поправить историю»: Марк жив. Limerence подтвердил исправление. Через три ответа модель снова получила старый факт о его смерти. Повторилось дважды.

Теперь уже есть проблема, которую можно искать.

Не бойтесь писать простым языком

Не нужно знать термины Limerence.

Можно написать:

Я включила вот эту кнопку, а после перезапуска она снова выключена.

или:

Бот ответил так, будто не видел картинку.

или:

Я удалила три последних хода, а персонаж всё равно продолжает говорить о событии из них.

Этого достаточно, если описание конкретное.

Укажите последовательность действий

Для сложного бага особенно полезно написать шаги.

Например:

1. Импортировала Character Card.
2. Активировала её в уже начатой Теме.
3. Отправила сообщение.
4. Нажала «Ещё вариант».
5. После этого перестала работать кнопка сохранения варианта.

Если проблему можно воспроизвести по этим шагам, исправлять её становится намного проще.

Напишите, происходит ли это всегда

Очень полезные формулировки:

Происходит каждый раз. Было один раз. Повторилось 3 раза из 5. Началось сегодня, раньше работало. Происходит только с этой моделью. В другой Теме всё нормально. После выключения пресета проблема исчезает.

Иногда одна такая строка сокращает расследование сильнее, чем пять скриншотов.

Если проблема появилась после изменения настройки — скажите об этом

Например:

До включения Regex всё работало. Началось после смены Claude на Gemini. После импорта этого пресета ответы стали пустыми. В новой Теме проблема отсутствует. Если выключить Character Card, ошибка исчезает.

Такие сравнения особенно полезны.

Максимальная длина описания

Описание бага — до 2000 символов.

Этого более чем достаточно для нормального отчёта.

Если вы написали дипломную работу на 14 страниц, скорее всего, проблему можно описать короче.

Фото и файлы

К описанию можно приложить до 5 фотографий или файлов.

Можно отправить их вместе с описанием, в том числе альбомом.

Вложения особенно полезны, если проблема касается:

• интерфейса;
• Кабинета;
• Telegram-кнопок;
• странного форматирования;
• сообщения об ошибке;
• импорта файла.

К вложению всё равно нужен текст

Не отправляйте один голый скриншот с надеждой «ну там же видно».

Форма бага требует текстовое описание. Хотя бы:

После нажатия «Сохранить» появляется эта ошибка. Повторяется каждый раз.

Скриншот показывает симптом. Описание объясняет контекст.

Не присылайте API-ключ

Никогда не вставляйте в баг-репорт:

• полный API-ключ;
• пароль;
• данные банковской карты;
• recovery-коды;
• другие секреты.

Для технической диагностики Limerence сам видит, есть ли у аккаунта настроенный провайдер.

Значение вашего API-ключа в автоматический диагностический снимок не включается.

Что Limerence прикладывает автоматически

При создании /diag Limerence сохраняет технический снимок состояния на момент обращения.

В него могут входить, например:

• версия Limerence;
• проблемная Тема;
• выбранная модель;
• используемый провайдер;
• наличие настроенных ключей — без самих значений;
• последние зарегистрированные API-ошибки;
• техническое состояние памяти;
• некоторые параметры, нужные для диагностики.

Это позволяет не заставлять пользователя вручную отвечать на вопросы «какая модель?», «какой провайдер?», «а ключ точно добавлен?», «а что было в ошибке API?».

Часть этой информации уже прикрепляется автоматически.

Текст вашей истории по умолчанию не прикладывается

Обычный технический снимок /diag не содержит расшифрованный текст вашей RP-истории.

То есть вызов /diag сам по себе не означает, что администратору сервиса отправили весь ваш роман на 600 тысяч слов.

Нет.

Если для расследования нужен непосредственный контекст диалога, для этого существует отдельное действие.

«📎 Приложить снимок Темы»

Эта кнопка нужна для ошибок, которые невозможно понять без самой сцены.

Например:

• модель проигнорировала конкретный факт;
• память вернула удалённое событие;
• Rewrite оставил кусок старой ветки;
• персонаж внезапно знает то, чего знать не должен;
• система перепутала последовательность событий;
• ошибка появляется только после определённого фрагмента разговора.

Тогда нажмите «📎 Приложить снимок Темы» до отправки описания.

Это означает, что вы разрешаете использовать содержимое этой истории при расследовании конкретного бага.

Что именно попадёт в снимок:

• вся история сообщений этой Темы;
• вся её память — факты, синопсис, состояние сцены;
• пользовательский промпт и Заметка автора;
• лор Темы;
• Regex-скрипты;
• игровые настройки: модель, температура, контекст, пресет, персона, карточка.

Чего в снимке нет: ваших API-ключей. Провайдеры при создании снимка вообще не читаются — видно только то, что ключ настроен.

Снимок относится к одной Теме — той, из которой вызван /diag. Другие ваши истории в него не входят.

Когда историю прикладывать НЕ нужно

Не надо прикладывать RP-контекст к проблеме:

кнопка оплаты не открывается; Кабинет показывает белый экран; API возвращает ошибку авторизации; кнопка /cards ничего не делает.

Здесь текст сцены обычно ничего полезного не даст.

Чем меньше лишних данных — тем лучше.

Когда историю почти обязательно стоит приложить

Например:

• Проблема памяти — Limerence вспомнил событие, которое было удалено.
• Проблема Rewrite / Undo — история откатилась неправильно.
• Проблема контекста — модель явно не получила несколько предыдущих сообщений.
• Проблема персонажа — конкретный факт из карточки или памяти применяется неправильно именно в этой сцене.

В таких случаях без контекста можно увидеть техническое состояние системы, но не сам момент, где поведение стало неправильным.