Проверь, как работает выделенная функция в связке с файлом `run.py`.
🔹 Что нужно проверить: - Все ли аргументы передаются и используются корректно? - Соответствует ли возвращаемое значение ожиданиям в `run.py`? - Логика внутри функции соответствует контексту её вызова?
✍️ Пояснения пиши по-русски, коротко и понятно. Учитывай, что у меня мало опыта в программировании.
💡 Если можно — предложи конкретные строки, которые стоит изменить.
Если функция устроена слишком нестабильно и требует переработки — перепиши её целиком, сохранив логику проекта.

Проверь архитектуру проекта: как файлы связаны между собой и как данные проходят через систему.
🔹 Что нужно проанализировать: - Структура проекта и распределение ответственности по файлам. - Импорты, вызовы функций, передача параметров и область видимости переменных. - Потоки данных между файлами, многопоточность, логика очередей. - Обработка ошибок и консистентность логирования. - Использование config и соблюдение принципов модульности.
🔹 На что обратить внимание: - Есть ли сильная связность (tight coupling) между модулями? - Нарушена ли логика "разделения ответственности" (separation of concerns)? - Есть ли потенциально опасные или неустойчивые архитектурные приёмы?
✍️ Пояснения пиши по-русски, коротко и ясно. Учитывай, что у меня мало опыта с большими проектами.
💡 Если всё сделано правильно — просто подтверди. Если есть проблемы — укажи, где и как улучшить (без переписывания всего кода).

Выполни аудит использования prompt-шаблонов и данных из config.py.
🔹 Шаг 1 — Сравнение ключей в `.format()`: - Пройди по каждому шаблону-промпту в CONFIG. - Определи, какие ключи используются внутри `.format()` во всём проекте. - Сравни с аргументами, которые реально передаются при форматировании.
🔹 Шаг 2 — Выявление несоответствий: - Если в шаблоне не хватает ключей — укажи, какие нужно добавить. - Если есть лишние (неиспользуемые) — укажи, какие можно удалить. - Определи потенциальные ошибки `.format()` при отсутствии ключей.
🔹 Шаг 3 — Проверка функций: - Найди все функции, где используется `.format()` с этими шаблонами. - Убедись, что все нужные переменные передаются в `.format(...)`. - Если каких-то аргументов не хватает — предложи, где и как их добавить. - Проверь сигнатуру функций на соответствие.
🔹 Шаг 4 — Аудит обращения к CONFIG: - Проверь, как во всём проекте используются данные из config.py. - Все ли обращения соответствуют структуре CONFIG["..."]? - Используется ли безопасная логика на случай отсутствия ключей? - Прямое обращение к CONFIG допустимо только в entry point-файлах (например, run.py). - В остальных местах конфиг должен передаваться явно через аргументы.
📝 Ответ оформи структурированно: - Список шаблонов с замечаниями. - Список функций с предложениями по правкам. - Комментарии по использованию CONFIG. - Если возможно — укажи номера строк и конкретные места для исправлений.

Проанализируй выделенный код — в чём причина ошибки?
🔹 Объясни, что именно не работает и почему.
🔹 Если ошибка связана с другим файлом (например, config, imports или внешняя функция) — учти это.
🔹 Укажи, как конкретно можно исправить: предложи точные строки, которые нужно заменить или добавить.
✍️ Пояснения пиши по-русски, понятно и без сложных терминов — у меня мало опыта в программировании.
💡 Если для исправления достаточно поменять 1–2 строки — покажи только их.
Если код полностью сломан и требует полной переработки — перепиши весь файл, соблюдая логику проекта.

Проверь весь проект на корректность реализации логики очередей и потоков.
🔹 Не ограничивайся только `queue_manager.py`. Проанализируй все участки, где используются функции `save_queue`, `load_queue`, и любые связанные с потоками участки.
🔹 Что нужно проверить: - Есть ли защита от одновременного доступа (например, `Lock`)? - Используются ли `try-except` при работе с очередями? Логируются ли ошибки? - Можно ли восстановить очередь после сбоя? (например, при генерации изображений) - Правильно ли расставлены вызовы очередей: после генерации, перед завершением потока и т.п.? - Соблюдаются ли зависимости задач? Исключена ли повторная генерация?
✍️ Комментарии и пояснения пиши по-русски, коротко и понятно. Учитывай, что у меня мало опыта в многопоточности.
💡 Если есть ошибки — укажи конкретные строки. Если всё корректно — объясни, почему реализация надёжна.

Проверь файл @config.py и оцени корректность всех лимитов по токенам.
🔹 **Промпты и лимиты:** - Соответствуют ли лимиты токенов количеству слов и предложений, указанных в промптах? - Есть ли конфликт: например, лимит малый, а в промпте требуется длинный вывод?
🔹 **Учёт модели:** - Учитывай модель и режим из config["server"]: GPT или Nous. - Если используется Nous — применяй коэффициенты из настроек (они масштабируют лимит относительно GPT).
🔹 **Рекомендации:** - Если лимит слишком мал — предложи увеличить, чтобы избежать усечения вывода. - Если лимит чрезмерен — предложи уменьшить, чтобы не тратить токены впустую. - Укажи конкретные строки или блоки, где лимит стоит откорректировать.
✍️ Пиши всё по-русски, коротко и понятно. Если всё корректно — просто подтверди.

Проверь весь проект как единую систему. Проанализируй архитектуру, конфигурацию, функции и логику.
🔹 **1. Архитектура:** - Структура файлов и модулей — корректна ли? - Взаимосвязи между функциями и файлами. - Порядок и структура импортов. - Использование переменных, аргументов и config. - Следование принципам модульности и повторного использования.
🔹 **2. Логика и аргументы:** - Если функция использует параметры из config.py — должен быть аргумент `config`. - Если используется StatsManager — должен быть аргумент `stats`, в нужной позиции. - Все параметры из config должны использоваться через `config`, а не через глобальный CONFIG. - Совпадают ли сигнатуры и вызовы функций? (особенно в `run.py`) - Есть ли логические ошибки или конфликты между файлами?
🔹 **3. Ограничения токенов и модели:** - Проверь `config.py` — лимиты токенов соответствуют шаблонам? - Везде ли применяется функция `text_token_limit_models`, где есть лимиты? - Какая LLM используется — GPT, Nous и т.п.? - Отметь места с явно завышенными или заниженными лимитами.
🔹 **4. Логгирование:** - Нет ли дублирующих логов одних и тех же этапов? - Логи только на ключевых этапах — без лишнего `log_info`. - Все сообщения на русском, кратко и по делу.
🔹 **5. Очереди:** - Проверка функций `save_queue`, `load_queue`: есть ли `try-except`, `Lock`, логгирование ошибок? - Можно ли восстановить выполнение после сбоя?
📝 Комментарии и объяснения пиши по-русски, коротко и ясно. Укажи конкретные строки или блоки, где есть проблемы. Если всё хорошо — напиши просто: всё окей.

Проверь код Python на ошибки отступов, пробелов и синтаксиса:
🔹 Не меняй логику, имена переменных или структуру.
🔹 Если ошибки есть — верни полностью исправленный код.
🔹 Если ошибок нет — просто напиши: всё корректно.
✏️ Комментарии пиши по-русски, коротко и понятно. Учитывай, что у меня мало опыта в программировании.
💡 Если можно — покажи конкретный пример, какую строку и как лучше переписать. Но не переписывай весь файл, если это не критично.
Если исправить можно только переписав весь блок — сделай это.

Проанализируй все Python-файлы проекта и выполни аудит логгирования (`log_info`, `log_error`, `log_error`).
🔹 **Цель:** убедиться, что логирование полезное, краткое и не дублируется.
🔹 **Аргументы:**  - Проверь использоваться ли исключительно именованные аргументы для всего проекта. Только в местах, где это крайне необходимо - можно использовать позиционные.
🔹 **Дублирование:**  - Не должно быть одинаковых сообщений в нескольких файлах. - Пример: если "Создано 7 заголовков" уже есть в `text_block.py`, не дублируй это в `text_run.py`, если нет веской причины.
🔹 **Ключевые точки:**  - Убедись, что логируются основные этапы: запуск, успешное завершение, ошибка. - Выдели бессмысленные или пустые `log_`, которые ничего не добавляют.
🔹 **Стиль:**  - Все сообщения должны быть на русском языке. - Пиши кратко, без повторений и воды. - Логируй только действительно важные события.
🔹 **Комментарии и рекомендации:** - Комментарии пиши по-русски, чётко и кратко. - Код переписывай только если это явно необходимо.
🔹 **Формат ответа:** - Если всё хорошо — напиши коротко: всё окей. - Если есть замечания — перечисли конкретные места: где что и как нужно заменить подробно в стиле 'гараж'.

Проанализируй весь проект и создай технический словарь. Оформи результат в виде чистого и структурированного Markdown-документа.
🔹 **Для каждого файла проекта (Python):** - Кратко опиши его назначение. - Перечисли все функции, переменные и классы. - Для каждой функции: поясни её логику, входные параметры, возвращаемые значения и вызовы других функций. - Отметь, какие внешние функции используются в этом файле.
🔹 **Для словаря CONFIG:** - Извлеки все ключи и поясни их назначение. - Распредели ключи по категориям:
  1. Системные настройки
  2. Шаблоны промптов
  3. Ограничения по токенам
  4. Карты логики и классификации
  5. Настройки моделей и движков (например, LoRA, режимы серверов)
  6. Рекомендации по безопасному расширению CONFIG

🔹 **Дополнительно — рекомендации по наименованиям:** - Проверь единообразие имён в проекте: ключи словарей, флаги, функции, переменные и промпты. - Укажи неудачные или неоднозначные названия. - Построй таблицу с предложениями:
  - Текущее имя
  - Предлагаемое имя
  - Где используется (пример: `config["gpt_translate_v2"] → config["translate.engine"]`)

⚠️ Все рекомендации должны быть безопасны для замены через "Find and Replace" в VS Code.
📝 Пиши по-русски. Используй чёткое оформление в Markdown: заголовки, списки, секции и примеры кода, где нужно.

Проверь все импорты в текущем файле и выполни следующие действия:
🔹 1. Приведи импорты к стандартному порядку:   built-in → external → internal.
🔹 2. Удали неиспользуемые импорты.   Сохрани только те, которые реально используются в коде.
🔹 3. Если каких-то импортов не хватает: - Для built-in и external — добавь их сам в верхнюю часть модуля. - Для internal — укажи, каких не хватает и в каких функциях, чтобы я добавил их вручную.
🔹 4. Ответ предоставь в двух частях: - 📦 Первая часть — обновлённый блок импортов верхнего модуля. - 🧩 Вторая часть — замечания по внутренним (локальным) импортам: где чего не хватает и почему.
✍️ Объяснения пиши кратко, в формате комментариев.

Выполни две проверки по теме ограничения токенов и настройки LLM:
🔹 **Этап 1 — Ограничение токенов**: - Найди все места в проекте, где ограничиваются токены. - Убедись, что в каждом:
  1. Используется функция `text_token_limit_models`.
  2. Применяется ключ из словаря `CONFIG["Ограничение по токенам"]`. Если ключа нет — зафиксируй его в отчёте.
  3. Отдельно укажи все места, где используется `max_tokens_default`.

🔹 **Этап 2 — Использование словаря из CONFIG**: - Проверь раздел `CONFIG["Ограничение по токенам"]`. - Определи, все ли ключи реально используются в проекте. Неиспользуемые — включи в отчёт.
🔹 **Дополнительно — Проверка text_llm_auto**: - Найди все вызовы текстовых LLM. - Убедись, что везде используется функция `text_llm_auto`. Если где-то вызывается напрямую — добавь в список.
📝 Ответ напиши структурированно. Укажи **все** участки проекта, где есть нарушения или отклонения, не ограничиваясь примерами.

Прочитай документацию и кратко опиши цель проекта, ключевые команды запуска, тестирования и сборки. Используй это как базовый контекст для всех следующих запросов.

Проверь, как работает выделенный код в связке с файлом.
🔹 Что нужно проверить: - Все ли аргументы передаются и используются корректно? - Соответствует ли возвращаемые значения ожиданиям? - Логика внутри функции(или функций) соответствует контексту ее(или их) вызова?
✍️ Пояснения пиши по-русски, коротко и понятно. Учитывай, что у меня мало опыта в программировании.
💡 Если нужно править — предложи конкретные строки, которые стоит изменить.
Если функция устроена слишком нестабильно и требует переработки — перепиши её акуратно целиком, сохранив логику и тонкие детали архитектуры.