То, что вы описываете - уже рабочая система. По сути те же принципы: контекст персистентный, структурированный и рядом с чатом. Разница только в масштабе.
Для одного проекта ваш подход вполне достаточен. Пара мыслей, что можно добавить без усложнения:
Фиксировать отвергнутые решения - буквально пара строк в контексте: "рассматривали X, не подошло потому что Y". Это те же ADR, но в минимальной форме. Экономит повторные обсуждения.
Хранить доки в репозитории (хоть в docs/), а не отдельно — тогда git сохраняет историю, и ничего не потеряется.
Workbench из статьи - это то, во что такой подход естественно вырастает, когда проектов становится несколько и контекст перестаёт помещаться в три документа. Но начинать с трёх документов - абсолютно правильно.
Правильное решение описанной проблемы лежит в смещении фокуса с "передать в контексте как можно больше в меньшем объеме" к "организовать и структурировать связанную документацию". У себя решил дополнительным кросс-проектным репозиторием с документацией, правилами, планами. Подключается к кодовому репо через cursor workspace файл. В ходе реализации ии модель видит и код, и связанные структурированные артефакты разработки, читает только нужные и не переполняет окно контекста лишней информацией, не изучает каждый раз кодовую базу детально, а находит большинство ответов в документации.
Когда секреты не влезают в protected variables, на помощь приходит gitlab secure store для файлов - запись через токен со специальными правами, чтение через токен деплоя.
Решал аналогичную проблему на порядок проще, используя примерно следующий промт: "Изучи раздел/класс Abc этой кодовой базы, его связанные дочерние и родительские модули, сервисы бекенда, связанную документацию, тесты. Затем тщательно обдумай и составь детальный план по добавлению функциональности..." Далее смотрим и корректируем представленный план и отправляем на пошаговое выполнение. Все в cursor'е. Лучше всего работает на последнем клоде, его контекстное окно в 1М токенов хорошо держит направление работы где-то до заполнения в 40-60%, потом качество и глубина проработки падают, стоит начинать новую сессию. До клода последнего тоже нравился gemini-2.5-pro, но ему задачу надо описывать было более детально и точно, иначе его "вело не в ту степь"
То, что вы описываете - уже рабочая система. По сути те же принципы: контекст персистентный, структурированный и рядом с чатом. Разница только в масштабе.
Для одного проекта ваш подход вполне достаточен. Пара мыслей, что можно добавить без усложнения:
Фиксировать отвергнутые решения - буквально пара строк в контексте: "рассматривали X, не подошло потому что Y". Это те же ADR, но в минимальной форме. Экономит повторные обсуждения.
Хранить доки в репозитории (хоть в
docs/), а не отдельно — тогда git сохраняет историю, и ничего не потеряется.Workbench из статьи - это то, во что такой подход естественно вырастает, когда проектов становится несколько и контекст перестаёт помещаться в три документа. Но начинать с трёх документов - абсолютно правильно.
Спасибо! ADR - штука, которая кажется избыточной пока не попробуешь, а потом не понимаешь как без них жил.
Если начнёте внедрять - необязательно документировать всё с нуля. Ретроспективные ADR по 3-5 ключевым развилкам проекта уже дают заметный эффект.
Правильное решение описанной проблемы лежит в смещении фокуса с "передать в контексте как можно больше в меньшем объеме" к "организовать и структурировать связанную документацию". У себя решил дополнительным кросс-проектным репозиторием с документацией, правилами, планами. Подключается к кодовому репо через cursor workspace файл. В ходе реализации ии модель видит и код, и связанные структурированные артефакты разработки, читает только нужные и не переполняет окно контекста лишней информацией, не изучает каждый раз кодовую базу детально, а находит большинство ответов в документации.
Когда секреты не влезают в protected variables, на помощь приходит gitlab secure store для файлов - запись через токен со специальными правами, чтение через токен деплоя.
Решал аналогичную проблему на порядок проще, используя примерно следующий промт: "Изучи раздел/класс Abc этой кодовой базы, его связанные дочерние и родительские модули, сервисы бекенда, связанную документацию, тесты. Затем тщательно обдумай и составь детальный план по добавлению функциональности..." Далее смотрим и корректируем представленный план и отправляем на пошаговое выполнение. Все в cursor'е. Лучше всего работает на последнем клоде, его контекстное окно в 1М токенов хорошо держит направление работы где-то до заполнения в 40-60%, потом качество и глубина проработки падают, стоит начинать новую сессию. До клода последнего тоже нравился gemini-2.5-pro, но ему задачу надо описывать было более детально и точно, иначе его "вело не в ту степь"