Память о файле

git blame скажет, кто изменил строку. Линтер скажет, что с ней не так сейчас. И только bee может сказать, что произошло в прошлый раз, когда этот файл трогали, и что с этим сделали.

bee remember "граница ** молча терялась, поэтому **/foo.cs совпадал с notfoo.cs" \
  --type error \
  --solution "сохраняй границу: (?:.*/)? а не .*" \
  --prevention "напиши негативный тест — шаблон, который НЕ должен совпадать" \
  --path 'src/Bee/Hooks/*.cs'

С этого момента каждый, кто собирается менять подходящий файл, это видит:

bee lint src/Bee/Hooks/PathGlob.cs

# bee — known about src/Bee/Hooks/PathGlob.cs
# - [error] граница ** молча терялась, поэтому **/foo.cs совпадал с notfoo.cs
#     ↳ fix: сохраняй границу: (?:.*/)? а не .*
#     ↳ avoid: напиши негативный тест — шаблон, который НЕ должен совпадать
#     ↳ matched: src/Bee/Hooks/*.cs

--path повторяем и использует ту же glob-нотацию, что и правила — на самом деле тот же сопоставитель, потому что два авторитета в вопросе «что значит glob» — это на один больше, чем нужно.

Куда это приходит, а куда нет

	привязанная память
bee lint на подходящем файле	✅ приходит
bee lint на любом другом файле	— тишина
хук перед записью	✅ приходит
начало сессии	— не приходит
каждый запрос	— не приходит
bee remember search	✅ по-прежнему находится

Эти два отсутствия и есть суть. Привязанная запись не стоит ничего на ходах, которые не трогают её файл — измерено около 37 токенов для примера выше, и платятся они только когда этот путь назван.

Когда это было написано впервые, это было неправдой

remember context возвращал последние записи без фильтра, поэтому привязанная попадала в каждый блок начала сессии: 3 записи / 94 токена с утечкой, 2 записи / 49 токенов после исключения привязанных. Ровно та цена, ради устранения которой привязка и существует, всё равно платилась. Теперь привязанные записи исключены из сессионного блока по той же причине, что и привязанные правила.

Ошибки первыми

Когда ограничение срабатывает, отпадать должно наименее срочное. Тому, кто собирается менять файл, «в прошлый раз это сломалось» нужнее, чем «вот соглашение», поэтому записи типа error идут первыми. Команда показывает до 5; хук перед записью берёт 3, поскольку едет рядом с правилами в двухсекундном бюджете.

bee lint --memory 0      # пропустить совсем
bee lint --memory 10     # или запросить больше

Знание — это не инструкция

Блок печатается под собственным заголовком, отдельно от правил, и это не косметика.

Правило — инструкция, которой надо следовать. Запись памяти — факт о прошлом. В одном списке модель обходится с ними одинаково — а следовать записи error, которая описывает баг, значит воспроизвести его. Другой заголовок, другой глагол.

Решение и профилактика едут вместе с проблемой, потому что «однажды это сломалось» без «а вот что это починило» — предупреждение, по которому нельзя действовать.

Что стоит привязывать

Привязывайте то, что иначе будет открыто заново:

# ловушка в конкретном файле
bee remember "AppKit не проставляет поля аудита — задай CreatedAt в инициализаторе" \
  --type error --solution "= DateTimeOffset.UtcNow на свойстве" \
  --path '**/Entities/*.cs'

# решение, действующее для каталога
bee remember "этот слой — записывающая сторона CQRS; чтения идут через проекцию" \
  --type decision --reason "у модели чтения другой контракт согласованности" \
  --path 'src/Orders/Commands/**'

Не привязывайте то, что верно везде — это правило или обычная запись. Привязка нужна для того, что важно только здесь.