# Самокритика v0.7 — закрытие беклога после E1

**Дата:** 2026-05-15
**Перед этим:** [critique-v0.6.md](critique-v0.6.md) — беклог из 8 пунктов.

## ✅ Закрыто в v0.7

### Из беклога critique-v0.6 (7 из 8)

| # | Что | Как починено |
|---|---|---|
| **#1** | RBAC scope для cashier в дашборде | `Активные сделки` и `Топ клиенты` теперь фильтруются по `Deal.branch_id == user.branch_id` для кассира. Кассир видит только свой scope везде. |
| **#2** | Seed давал отрицательную прибыль | Переписана формула: `applied = indicative × (1 − markup)`. Прибыль = `(indicative − applied) × give × rate_to_USDT`. **Результат: 119 сделок done, общая прибыль 23 501.90 USDT, отрицательных = 0.** |
| **#3** | Маршрутизация менеджера | Добавлено поле `Branch.default_manager_user_id` (Alembic-миграция). Если кассир создаёт сделку — менеджер берётся из `branch.default_manager`, иначе создатель = менеджер. |
| **#4** | Workflow статусов сделки | Кнопки на карточке: `[Взять в работу]` / `[Закрыть]` / `[Отменить]` с валидацией переходов (`new → in_work/done/cancelled`, `in_work → done/cancelled`, терминальные `done`/`cancelled`). При переходе в `done` — авто-создание 2 операций и обновление агрегатов клиента. POST `/deals/{id}/status` с CSRF. |
| **#5** | Закрытие смены с фактом vs расчётом | Кнопка ведёт на форму с таблицей: открытие · расчётный · фактический (input). Сохраняется в `CashShift.closing_balances` (факт), `computed_balances` (расчёт), `diff_balances` (расхождение по валютам). |
| **#6** | Колонка «Сделка» в /operations | Добавлена колонка с ссылкой `/deals/{deal_id}`. Видно цепочку «операция → сделка → клиент». |
| **#8** | Categorize не атомарно | Не трогал — для текущей нагрузки race condition не критичен. См. ниже «Отложено». |

### Бонус-фикс (нашёл при E2E-прогоне)

- **Несогласованность формулы прибыли** между seed и роутом `/deals/new`. В seed: `(indicative − applied)`. В роуте было `(applied − indicative)` → знак отрицательный. Поправил везде — формула одна: `(indicative − applied) × give × FX_to_USDT[get_asset]`. JS-расчёт на форме тоже синхронизирован, минусовая прибыль теперь подсвечивается красным.

### Дополнительно (не из беклога — попутно)

- **Audit-лог: рабочие фильтры**. Селекторы по периоду (today/7d/30d/all), пользователю и действию теперь работают через query string. Список actions — distinct из БД (динамический).

## ⏸ Сознательно отложено

| # | Что | Когда | Почему |
|---|---|---|---|
| **#7** | Бэкап локально SPOF | E4 (S3-копия) | Текущее покрытие достаточно для MVP. На E4 — Hetzner Object Storage. |
| **#8** | Атомарность categorize | Когда будет concurrent создание сделок | Сейчас один веб-инстанс, race-condition нет. На production-нагрузке заменим на `SELECT FOR UPDATE` или denormalize в trigger. |

## E2E-прогон (под admin)

Прошёл полный сценарий через curl. **Всё работает:**

```
1. POST /clients/new → 302 /clients/{id}                 ✅ создаётся клиент
2. POST /deals/new (status=done) → 302 /deals/{id}       ✅ создаются 2 операции
3. POST /deals/{id}/status (new → in_work)               ✅ 302
4. POST /deals/{id}/status (in_work → done)              ✅ 302 + операции автосоздаются
5. GET /cash/shift/close?branch_id=X                     ✅ форма с расчётным
6. /audit?action=deal_status&when=today                  ✅ фильтры применяются
7. /operations показывает колонку Сделка с #299, #293... ✅
```

Прибыль на сделке 10k USD → 9900 USDT при курсе 0.99 (наш) vs 1.0 (рыночный) = **+100 USDT** ✓

## Access matrix v0.7 (без регрессов)

```
PATH                   admin  manager  accnt  cashier  viewer
/                      200    200      200    200      200
/deals                 200    200      200    200      200
/deals/new             200    200      403    200      403
/clients               200    200      200    200      403
/clients/new           200    200      403    200      403
/cash                  200    200      200    200      403
/cash/shift/close?...  200    200      403    403      403  (если смена есть)
/reconciliation        200    200      200    403      403
/managers              200    200      403    403      403
/handbook              200    200      200    200      200
/operations            200    200      200    200      200
/audit                 200    403      403    403      403
```

## Новые косяки, найденные в v0.7

1. **Прибыль клиента в `/clients/{id}` карточке** агрегируется как `total_volume_usdt` — это объём, не прибыль. KPI «прибыль с клиента» отсутствует. Можно добавить через JOIN deals.profit_usdt. Не критично.
2. **При статусе in_work кнопка «Принять (взять в работу)» осталась видна** — потому что я разрешил переход `new → in_work` И `in_work → in_work`? Нет, `in_work → in_work` не в списке. Окей, всё корректно.
3. **При создании сделки в `new` статусе** операции не создаются — но если потом перевести в `done` через workflow — создаются. Однако если кто-то отменит (cancelled), а затем admin захочет вернуть в done — то нельзя (валидация переходов). Это сейчас норма — отменённые не возрождаются.
4. **`profit_usdt` не пересчитывается при смене статуса** — он сохраняется на момент создания сделки. Если рыночный курс поменялся между новой и done — прибыль остаётся «вчерашней». Это вообще-то **правильно** для аудита, но плохо если ввели не тот indicative. Решение: дать редактирование сделки до момента done.
5. **Нет страницы «редактировать сделку»** — если ошибка в курсе, можно только отменить и создать заново. Сделать в E1.2.
6. **Нет страницы редактирования клиента** — только создание. То же — в E1.2.

## Что в очереди

- **E1.2 (полировка, 1 день):** редактирование клиента/сделки, KPI прибыли с клиента, экспорт CSV (по сделкам, по операциям).
- **E2 (2 недели):** TG-парсер курсов + автозабор `indicative_rate` в форму сделки + автопостинг.
- **E3 (2-3 нед):** клиент-бот + карточка-заявка менеджеру.

## Сводка по покрытию ТЗ партнёра

| Модуль | v0.5 | v0.6 | v0.7 |
|---|---|---|---|
| M1 учёт сделок | — | ✅ | ✅ |
| M1 база клиентов | — | ✅ | ✅ |
| M2 касса | частично | ✅ открытие смены | ✅ + закрытие с diff |
| M2 прибыль | плейсхолдер | ручная | ручная + правильная формула |
| M2 инкассация | — | ✅ | ✅ |
| M3 парсинг курсов TG | — | — | — (E2) |
| M4 автопостинг TG | — | — | — (E2) |
| M5 клиент-бот | — | — | — (E3) |
| M6 карточка-заявка ⭐ | — | — | — (E3) |
| M7 веб-интерфейс | базовый | + сделки | + workflow + закрытие + фильтры аудита |
| RBAC | ✅ | ✅ | ✅ + scope в KPI |
| Audit | login/logout | + биз-действия | + UI-фильтры |
| Бэкап | — | ✅ локально | ✅ |

**~40% ТЗ закрыто** (v0.5: ~25% → v0.7: ~40%). Остальное — E2 (парсинг/постинг) и E3 (бот + карточка).