steelmorgan/predefined-elements

Reuse-first для настроек и предопределенных значений

Триггер: задаче нужна настройка, именованное предопределенное значение, порог, флаг, код, ссылка на объект или другой параметр, который должен жить централизованно.

Принцип

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

MUST

| Требование | Описание | |-----------|----------| | Сначала поиск | Перед созданием новой настройки или хардкодом значения найти существующее значение по бизнес-ключу через штатный механизм проекта. Нашел - переиспользовать, не плодить дубль | | Чтение через обертки | Если в проекте есть сервисный модуль, API или БСП-обертка доступа к настройкам, использовать ее, а не прямой запрос к хранилищу | | Запрет хардкода | Не зашивать коды, ссылки, пороги и флаги, которые должны быть управляемыми настройками. Значение должно читаться по осмысленному бизнес-ключу | | Новый ключ только при отсутствии | Создавать новую настройку только после проверки отсутствия существующего ключа и коллизий по назначению | | Ключ в одном месте | Строковый бизнес-ключ объявлять один раз: константа, экспортная функция или единая точка доступа. Не дублировать литерал по коду | | Документировать назначение | Для новой настройки фиксировать назначение, формат значения, владельца логики и допустимое значение по умолчанию в артефактах задачи или проектной документации |

SHOULD

• Если настройка нужна нескольким местам, все они читают ее через один и тот же ключ и один слой доступа.
• Если проект не имеет централизованного хранилища настроек, сначала проверить типовые или библиотечные механизмы, а не создавать локальный справочник/регистр без архитектурного решения.
• Для миграции старого хардкода сначала найти все места использования литерала и определить единый ключ, затем заменить обращения через общий API.

Что НЕ покрывается этим правилом

• Настройки, являющиеся полноценной предметной моделью со сложной идентификацией и жизненным циклом. Для них нужен отдельный дизайн, а не key-value запись.
• Типовые механизмы хранения настроек платформы или библиотек. Их нужно переиспользовать по правилам ssl-patterns, если они подходят задаче.

Связанные правила

• search-before-write - reuse-first для кода и готовых механизмов.
• ssl-patterns - переиспользование типовых и библиотечных механизмов.

depends_on:

• search-before-write
• ssl-patterns