3.0 KiB
Specs
Репозиторий содержит существующие behavioral specifications и SDD history.
Для обычной разработки не создавай и не обновляй planning artifacts ради
процесса. До edits найди/создай подходящую Gitea Issue, проверь AC и ветку;
чтение допускается без Issue. Выбор lightweight/SDD — по
Engineering Workflow
(main#28; после merge — актуальная версия develop);
OpenSpec lifecycle начинается только после явного решения Change Owner.
Если нужна существующая behavioral spec, выбери точный target через AI_INDEX. Specs не являются вторым editable HTTP OpenAPI: HTTP-провайдер публикует контракт, а потребитель получает отдельный artifact и локально проверяет generated types. Specs фиксируют behavioral requirements; другие checkout не нужны для чтения и native validation этого store.
Архивы и чужие active changes сохраняй. Для правки индекса проверь targets,
anchors и git diff --check; application gates принадлежат affected repos.
Если явно запрошена работа через OpenSpec, следуй
локальным инструкциям OpenSpec
и используй store wealth-ledger-specs. Перед Node-командами активируй
местную .nvmrc: если nvm не загружен в non-interactive shell, загрузи
установленный $HOME/.nvm/nvm.sh, затем выполни nvm use --silent из specs.
Если nvm.sh недоступен, остановись; не используй системный Node.
Ветки и релизы
Работа — в issue-linked ветке от develop, затем PR в develop; в main напрямую
не пушить. PR сливается squash или rebase-merge; merge-коммит не используется.
main обновляется только fast-forward из develop, поэтому origin/main
всегда предок origin/develop:
git merge-base --is-ancestor origin/main origin/develop. Срочный fix —
обычная ветка fix/* от develop; пути hotfix от main нет.
Релиз — по README.
Commits и заголовки PR — Conventional Commits со ссылкой на Issue (кроме release);
для спецификаций допустим spec:.
Перед подготовкой релиза прочитай местный README; версии вручную не повышать.