ksv741
e4f10dedef
Specs security / security (pull_request) Successful in 7s
Specs verify / verify (pull_request) Successful in 10s
Conventional commits / commits (pull_request) Successful in 10s
Specs security / security (push) Successful in 7s
Specs verify / verify (push) Successful in 10s
62 lines
5.1 KiB
Markdown
62 lines
5.1 KiB
Markdown
# WealthLedger Specs
|
||
|
||
Этот репозиторий — единственный versioned SDD authority рабочей области. Canonical OpenSpec store `wealth-ledger-specs` расположен в `openspec/` (`specs/openspec` от workspace), новые changes используют project-local schema `wealth-ledger-sdd`.
|
||
|
||
## Начало работы
|
||
|
||
OpenSpec применяется по явному запросу согласно [AGENTS](AGENTS.md). Proposal, Delta Specs, Design и Tasks создаются последовательно по одному после approval Change Owner. Для любой команды, читающей или изменяющей change, явно передавайте `--store wealth-ledger-specs`.
|
||
|
||
Design должен оценить `frontend`, `backend`, `specs`, `docs` в Delivery Map и при обязательном trigger включить Solution Assessment. Docs описывает as-built state и не становится параллельным store требований.
|
||
|
||
## Проверка
|
||
|
||
Для native validation из этого репозитория:
|
||
|
||
```bash
|
||
openspec schema validate wealth-ledger-sdd --verbose
|
||
openspec validate <change> --type change --strict --store wealth-ledger-specs
|
||
openspec validate --specs --strict --store wealth-ledger-specs
|
||
```
|
||
|
||
Structural validation не заменяет semantic verification и independent read-only review перед archive.
|
||
|
||
Node задаётся собственной `.nvmrc`; после `nvm use --silent` выполните `npm ci`.
|
||
`npm run verify` проверяет diff. OpenSpec validation остаётся отдельной проверкой
|
||
при изменениях требований. История релизов — [CHANGELOG](CHANGELOG.md).
|
||
|
||
## Релизы
|
||
|
||
Репозиторий выпускается независимо. `develop` — интеграция, `main` — принятые
|
||
релизы. Работа: `codex/<task>` от актуального `develop`, PR в `develop`.
|
||
Обычные PR допускают squash; release и обратная синхронизация сохраняют историю.
|
||
Commits и PR titles — Conventional Commits, включая `spec:`. Версии вручную не повышай.
|
||
|
||
1. Получи `main`, `develop` и теги: `git fetch origin --tags`. Убедись, что
|
||
`develop` содержит последний релиз. Создай `release/<name>` от проверенного
|
||
`develop`; `nvm use --silent`, `npm ci`. Hotfix начинается от `main` в
|
||
`release/hotfix-<name>` и проходит тот же процесс.
|
||
2. На чистой ветке выполни `npm run release:preview`, просмотри версию/changelog,
|
||
затем `npm run release:prepare`. Команда создаёт `chore(release): X.Y.Z`,
|
||
обновляет manifest/lockfile/CHANGELOG; тег и push не выполняет. Не обходи
|
||
guards ветки, чистого дерева, отсутствующих тегов или уже подготовленной версии.
|
||
3. Проверь diff и штатные gates этого репозитория. Отправь только release-ветку,
|
||
открой PR в `main` с заголовком `chore(release): X.Y.Z`. После зелёных
|
||
`verify`, `security`, `commits` выполни fast-forward-only merge. Если `main`
|
||
изменился, согласуй историю и повтори проверки кандидата.
|
||
4. Получи удалённый `main`, сравни его HEAD с проверенным release SHA и версией
|
||
manifest/lockfile. Создай аннотированный `vX.Y.Z` именно на этом SHA:
|
||
`git tag -a vX.Y.Z <release-sha> -m "Release X.Y.Z"`, затем отправь только
|
||
`git push origin refs/tags/vX.Y.Z`. Не запускай release-it повторно на `main`.
|
||
5. Верни release-коммит через PR `main → develop` без squash/rebase; проверь,
|
||
что `develop` содержит тег. Опубликованные теги не перемещай. При сбое после
|
||
merge создай отсутствующий тег без нового bump; до merge исправь и проверь
|
||
существующий кандидат без повторного повышения версии.
|
||
|
||
`feat:` повышает minor, `fix:`/`perf:` и прочие разрешённые типы — patch;
|
||
`!`/`BREAKING CHANGE:` — major, включая версии до 1.0. `chore(release):`
|
||
исключён из рекомендации и changelog. Конфигурация — `.release-it.json`.
|
||
В Gitea для `main`/`develop` должны быть запрещены прямой/force push и обход
|
||
администратором, обязательны `verify`, `security`, `commits`; теги `v*` защищены.
|
||
Workflow сам не включает эти настройки. Отдельное review approval для одного
|
||
владельца не требуется. Npm publishing, deploy и Gitea Releases не включены.
|