Skip to content

CLAUDE.md

Latest commit

 

History

History
140 lines (92 loc) · 7.63 KB

CLAUDE.md

File metadata and controls

140 lines (92 loc) · 7.63 KB

Документация по проекту лежит в ./docs

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

При добавлении текстов в ответ бота сохраняй их в ./config/locales и используй от туда через I18n.t

Мы не используем переменные окружения напрямую (ENV), доставай значения через ApplicationConfig

Перед тем как отвечать на вопросы касающиеся продукта изучи ./docs/Product

Структура документации

  • ./docs/Product - документация по продукту
    • target-audience.md - целевая аудитория
    • bot-descriptions.md - описания ботов
    • problems.md - проблемы которые решает продукт
    • telegram-descriptions.md - описания для Telegram
    • core-settings.md - основные настройки
    • features.md - функциональность
    • user-flow.md - пользовательский поток
  • ./docs/Architecture - архитектурная документация
    • c4-model.md - C4 модель архитектуры
  • ./docs/gems - документация по используемым gem-ам
    • telegram-bot.md - Telegram bot
    • ruby-llm.md - Ruby LLM
  • ./docs/Other - прочая документация
  • ./docs/Hidden - скрытая документация
  • ./docs/ROADMAP.md - дорожная карта проекта

Модели и новые таблицы создаем через rails g model а не через прямое создание миграций.

При планировании проекта с нуля сначала заводим модели и все необходимые свойства схемы делаем через rails g model

Рельсовые команды запускай через ./bin/rails

В миграциях в базе вместо json всегда используй jsonb

При создании индексов в базе учти что индексы для references колонок уже создаются автоматически.

После выполнения пункта из ROADMAP отмечай его выполненным.

Перед тем как что-то делать или планировать делать с кодом изучай файлы в ./docs/Architecture

При создании тестов изучай ./docs/Testing

Работа со спецификациями

ВАЖНО: Всегда следуй регламенту работы со спецификациями:

  • Регламент работы со спецификациями
  • Статусы: draft → need_plan → approved → implemented
  • Всегда проверяй статус спецификации перед началом работы
  • Обновляй статусы при завершении этапов
  • TDD подход: тесты первыми, затем реализация

Если делаешь обещания - записывай их в .claude/promises.md

/file:.claude-on-rails/context.md /file:.claude/promises.md

  • Когда работаешь с фоновыми задачами учитывай config/queue.yml

Инстуркции для claude

Use context7

Always use context7 when I need code generation, setup or configuration steps, or library/API documentation. This means you should automatically use the Context7 MCP tools to resolve library id and get library docs without me having to explicitly ask.

При создании или рефакторинга текста

Никогда не используй в assert куски текстаз из локали. Используй полный текст через I18n.t с полным ключем. Это правило действует только если в локали не используется интерполяция.

Разработка телеграм бота

При анализе или разработку кода для телеграм бота предварительно изучай ./docs/gems/telegram-bot.md

Отделяй спецификацию от имплементации

  • Создавай новую спецификацию в ./docs/Specs/XXX_{TITLE}_Specification.md
  • Реализовывай в ./docs/Implementation/Spec_XXX_{TITLE}_Implementation.md

Ruby Linting

при генерации кода учитывай настройки из .rubocop.yml

Error catching

Каждый раз когда мы ловим ошибку через rescue мы отправляем уведомление в Bugsnag, по-возмоности указывая контекст который пригодится для расследования в metadata.

Instructions

ВАЖНО: Отмечай пункт плана (имплементации или любого другого) в файле выполненным как только ты его сделал.

Когда создаешь спецификации (спеки) давай им номера в виде: XXX_Название.md

Linting

Когда создаешь ruby-код делай его согласно правилам .rubocop.yml

Test Driven Development

Используй minitest вместо rspec.

При создани плана импленетации, после этапа инициализации начинай с создания тестов. ВАЖНО: любую реализацию в коде начинай с тестов. Tests first! Сначала создаешь тесты, смотриш что они красные, добавляешь код, проверяешь что они зеленые. И только тогда переходишь к следующему этапу. Tests First - каждый этап функциональности начинается с тестов. RED-GREEN-REFACTOR - классический цикл TDD.

  • Спеки лежат в @docs/Specs/

После того как тесты начали работать, сделай rubocop -A для измененных файлов

Git commiting

Перед тем как сделать git add сделай rubocop -A для измененных файлов

План имплементации (он-же план реализации)

План имплементации всегда создается с нумерованными этапами и подпунктами имеющие чекбоксы для загрузки в TODO.

В плане создается МИНИМАЛЬНЫЙ набор тестов.

План имплементации всегда имеет такой-же номер как и спецификаций по которой он создан и имеет ссылку на неё.

После выполнения плана имплементации отмечай выполненные пункты как выполненные.

  • Вместо Fetch используй mcp__tavily__tavily-extract
  • Мы не используем rspec для тестов. Мы используем только minitest
  • При создании тестов предпочитае фикстуры вместо фабрик
  • Планы рефакторинга сохраняются в .protocols/