# Как ведётся работа над порталом

Проект ведёт один разработчик. Требования приходят из Teams-чата и устно, поэтому вся
история — что просили, что решили, что выехало — хранится здесь и в Gitea, а не в памяти.

## Где что лежит

| Что | Где | Отвечает на вопрос |
| --- | --- | --- |
| Задачи | Gitea Issues `ct-forms-portal` | Что надо сделать, кто и когда попросил |
| Решения | `docs/adr/` | Почему сделано именно так, какие были варианты |
| Изменения | `CHANGELOG.md` | Что и в какой версии выехало на прод |
| Код | коммиты с `(#номер)` | Каким кодом закрыта задача |

## Путь запроса

1. **Пришло сообщение** (чат, устно) — каждый пункт становится issue. В issue — цитата или
   скрин как есть, дата, кто попросил.
2. **Разбор.** Метка по типу: `bug`, `ux`, `feature`, `perf`, `справочники`,
   `вопрос-бизнесу`, `смена-модели`.
   - Если пункт меняет устройство данных (`смена-модели`) — сначала ADR, потом код.
   - Если нужен ответ бизнеса (`вопрос-бизнесу`) — вопрос в чат, issue ждёт ответа.
3. **Работа.** Ветка `fix/<номер>-кратко` или `feat/<номер>-кратко`. Баг — сначала падающий
   Jest-тест, потом фикс. Коммиты — `тип: описание (#номер)`.
4. **Деплой.** Запись в `CHANGELOG.md`, тег версии `vX.Y.Z` (= версия в
   `config/package-solution.json`), issue закрывается, в чат — короткий список изменений.

## Вопрос, который задаём каждому новому пункту

> Это меняет то, как устроены данные, или только как они показываются?

Только показ или поведение — делаем. Меняет данные — сначала проходим весь путь:
где создаётся, кто видит, что уходит в отчёт, INCORE и согласование. Потом ADR.