Comments 8
Выбор грепа вместо вектора на таких объемах спорным не выглядит, а вот ручное правило «одно понятие, один файл» — самое хрупкое место конструкции: оно держится на дисциплине и в команде из пяти человек размывается первым. Тут просится проверка в CI: у каждого файла в memory/ есть строка в индексе, каждая строка индекса ведет на существующий файл, дублей заголовков нет — дешевле, чем ловить расхождения глазами на ревью. Такой линтер у вас уже есть, или согласованность индекса и файлов пока целиком на аккуратности автора?
Спасибо, предложение по делу! Линтера пока нет - согласованность целиком
на аккуратности автора, и вы указали ровно на ту цену подхода, которую
озвучена в статье. Первые два инварианта (у каждого файла
есть строка в индексе, каждая строка ведет на существующий файл) - прямо
напрашиваются в pre-commit. А вот семантические дубли - когда два файла
на одно понятие названы по-разному - линтер не поймает, это остается на ревью.
Индекс намеренно не уникальный ключ: на стыке общего и частного модель
открывает оба файла, так что структурный линтер отсечет идентичный дубль,
но близкие по смыслу заголовки развести не сможет.
Уже и комментарии с помощью AI пишут) Как будто нельзя понять, что писал коммент именно AI. Можно)
Пишу как умею — привычка к длинным предложениям после технической документации не лечится) Но вопрос был мой, и линтера в проекте от этого, к сожалению, не прибавилось.
Не забыл, просто руки дошли не сразу. Линтер уже написан и гоняется на нашей
стороне - по памяти нескольких агентов, сейчас допиливаю края, потом выложу.
Первый прогон дал неожиданное: битую ссылку агент обходит сам - лезет
смотреть папку и находит файл рядом. А вот файл, у которого строки в индексе
нет вообще, искать ему неоткуда. Так что самый скучный инвариант из трех
оказался единственным по-настоящему рабочим.
Выложил: https://github.com/mngerasimenko/keepware-llm-lab - проверка в scripts, рядом промпт, чтобы агент подключил ее себе сам.
Инвариантов вышло шесть: ваши два плюс имя в шапке против имени файла, имя не по правилу слага и битые связи. Первый прогон по собственной памяти дал 107 нарушений одного корня - имена файлов писали через подчеркивание, а поле name и ссылки через дефис, и месяцами этого никто не видел, потому что сверять было нечем. Семантические дубли он по-прежнему не ловит, тут ничего не изменилось.
Раз код хорошо ищется регулярками почему не использовать сразу нужные инструменты.
https://github.com/Graphify-Labs/graphify
https://github.com/ast-grep/ast-grep
JetBrains MCP https://medium.com/@giuseppetrisciuoglio/jetbrains-mcp-pi-coding-agent-e99db8e9684b
И тому подобное.
Спасибо за ссылки. По коду согласен, на большой базе структурный поиск
по AST и индекс IDE находят точнее обычного грепа, и это естественное
продолжение того же подхода. Про инструменты этого класса писали и под
прошлой статьей. У себя я их не использовал. А поиск по коду у меня делают
агенты, обычным грепом по содержимому и по именам файлов, и на моих
объемах этого хватает.
Граница тут проходит не по инструменту, а по материалу. Статья про память
агента, а память - это проза: решения, правила, договоренности. Дерева из
нее не построишь, у прозы нет синтаксиса, поэтому инструменты по коду
закрывают код и не закрывают этот слой.
У Claude Code уже есть такая память. Тогда зачем я держу свою?