Merge pull request 'chore: align backend engineering workflow (WealthLedger/main#27)' (#76) from chore/27-engineering-workflow into develop

.ai/conventions/engineering.md

@@ -14,7 +14,8 @@ checkout. Внешний API задаётся предоставленным п
 
 Начни с результата и affected areas. До edits проследи flow/invariants, найди
 owner и 1–3 примера. Код показывает механизм; случайный аналог не меняет контракт.
-Работай напрямую; OpenSpec/SDD lifecycle — только по явному запросу.
+Выбери lightweight или SDD по Engineering Workflow из AGENTS; OpenSpec lifecycle
+начинай после явного решения Change Owner.
 Перед Node-командами активируй местную `.nvmrc`: если `nvm` не загружен в
 non-interactive shell, загрузи установленный `$HOME/.nvm/nvm.sh`; затем
 выполни `nvm use --silent` из backend. Если `nvm.sh` недоступен, остановись,
@@ -79,9 +80,13 @@ generated artifacts), сомнении в evidence или явном запро
 
 ## Git и релизы
 
-Работа — в `codex/<task>` от актуального `develop`, затем PR в `develop`.
+Работа — в ветке `<type>/<issue-number>-<slug>` от актуального `develop`,
+затем PR в `develop`; для cross-repo ссылки укажи owner/repo#number.
+Имя ветки и связь PR с реальной Issue проверяются вручную: commitlint
+проверяет синтаксис commit/PR title, но не существование и соответствие Issue.
 Сохраняй чужие изменения; перед commit просмотри staged paths и diff.
-Commits и PR titles — Conventional Commits; допустим `spec:`. Каждый commit
-содержит одну связанную задачу. Root другого checkout не управляет этим repo.
+Commits и PR titles — Conventional Commits с parser-recognized Issue reference; допустим
+`spec:`. Каждый commit содержит одну задачу. Исключения release и правила
+ссылки — в Engineering Workflow из AGENTS. Root другого checkout не управляет этим repo.
 Прямой push в `main`, force-push и перенос опубликованных тегов не входят в
 обычную работу. Перед release/hotfix прочитай местный README, раздел «Релизы».

.gitea/ISSUE_TEMPLATE/bug.md

@@ -0,0 +1,12 @@
+---
+name: Bug Report
+about: Неверное поведение
+---
+## Проблема и шаги воспроизведения
+
+## Факт / ожидание
+
+## Acceptance Criteria
+- [ ]
+
+## Окружение / ссылки (если применимо)

.gitea/ISSUE_TEMPLATE/engineering.md

@@ -0,0 +1,10 @@
+---
+name: Engineering Task
+about: CI, тесты, документация, процесс и прочее
+---
+## Контекст и результат
+
+## Scope / связанные Issues (если есть)
+
+## Acceptance Criteria
+- [ ]

.gitea/ISSUE_TEMPLATE/feature.md

@@ -0,0 +1,12 @@
+---
+name: Feature Request
+about: Новое наблюдаемое поведение
+---
+## Зачем и какой результат
+
+## Ожидаемое поведение
+
+## Acceptance Criteria
+- [ ]
+
+## Зависимости / связанные Issues (если есть)

.gitea/ISSUE_TEMPLATE/refactor.md

@@ -0,0 +1,12 @@
+---
+name: Refactoring / Technical Debt
+about: Улучшение без нового поведения
+---
+## Проблема и результат
+
+## Сохраняемые инварианты / границы
+
+## Acceptance Criteria
+- [ ]
+
+## Зависимости / ссылки (если есть)

.gitea/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,11 @@
+## Summary
+
+## Linked Issue
+Refs
+
+## Changes
+
+## Verification
+- Команда / результат / ограничения:
+
+## Breaking Changes (если есть)

AGENTS.md

@@ -4,6 +4,9 @@
 только его файлы и предоставленные публичные контракты. Перед работой прочитай
 [порядок работы](.ai/conventions/engineering.md#граница-и-порядок-работы), затем
 объединяй triggers задачи и путей; читай активированные темы до решения.
+До edits найди/создай подходящую Gitea Issue, проверь AC и ветку; чтение
+допускается без Issue. Общий маршрут — [Engineering Workflow](https://git.personal.ksv741.ru/WealthLedger/main/src/commit/03b3b59e6ff2ba391f9dfc42a039a96d0d84c1c9/.ai/conventions/engineering-workflow.md)
+(main#28; после merge — актуальная версия `develop`).
 
 | Решение / сигнал | Читать |
 | --- | --- |

README.md

@@ -295,9 +295,11 @@ Durability оставляет временные DB, логи и `result.json`
 ## Релизы
 
 Репозиторий выпускается независимо. `develop` — интеграция, `main` — принятые
-релизы. Работа: `codex/<task>` от актуального `develop`, PR в `develop`.
+релизы. Обычная работа: issue-linked ветка от актуального `develop`, PR в `develop`;
+общие правила — в Engineering Workflow по ссылке из AGENTS.
 Обычные PR допускают squash; release и обратная синхронизация сохраняют историю.
-Commits и PR titles — Conventional Commits, включая `spec:`. Версии вручную не повышай.
+Commits и PR titles — Conventional Commits со ссылкой на Issue (кроме release),
+включая `spec:`. Версии вручную не повышай.
 
 1. Получи `main`, `develop` и теги: `git fetch origin --tags`. Убедись, что
    `develop` содержит последний релиз. Создай `release/<name>` от проверенного

commitlint.config.cjs

@@ -1,4 +1,12 @@
 module.exports = {
   extends: ['@commitlint/config-conventional'],
-  rules: { 'type-enum': [2, 'always', ['feat', 'fix', 'perf', 'docs', 'spec', 'refactor', 'build', 'ci', 'test', 'style', 'chore', 'revert']] },
+  defaultIgnores: false,
+  ignores: [
+    (message) => /^chore\(release\): \d+\.\d+\.\d+$/.test(message.trim()),
+    (message) => /^Merge pull request ['"].+['"] \(#\d+\) from .+ into .+$/.test(message.trim()),
+  ],
+  rules: {
+    'type-enum': [2, 'always', ['feat', 'fix', 'perf', 'docs', 'spec', 'refactor', 'build', 'ci', 'test', 'style', 'chore', 'revert']],
+    'references-empty': [2, 'never'],
+  },
 };