# ТЗ-Compliance Report — 2026-05-31 (v0.5.0)

Независимая проверка соответствия кода Техническому Заданию (`docs/ТЗ.md`).
Аутентификация "по-настоящему" (OIDC) и сценарий "несколько компаний на пользователя" — ИСКЛЮЧЕНЫ из проверки (уточняется).

---

## ИТОГ: 45/45 тестов пройдено ✅

Все функциональные требования ТЗ **реализованы**. Расхождения — только в объёме/глубине реализации.

---

## Детальный разбор по пунктам ТЗ

### 1. Назначение и цели — ✅

| Требование | Статус | Где |
|---|---|---|
| Web-интерфейс для управления списком | ✅ | `views/index.ejs`, `ui/routes/entries.js` |
| Единая точка для инженеров | ✅ | `/admin`, `/audit` |
| Машиночитаемая выдача агрегированного списка | ✅ | `/exp` (временный), `/export` |

### 2. Объем работ — ✅

| Требование | Статус | Где |
|---|---|---|
| Web-страница | ✅ | SSR через EJS |
| Авторизация OIDC | ⏸️ | mock (DEV_MODE=true), OIDC-код написан но не подключён |
| Валидация клиент + сервер | ⚠️ | Сервер: ✅ полная. Клиент: только HTML5 `pattern` |
| Внешний endpoint txt | ✅ | `/exp` (без авторизации) |
| Хранение + аудит | ✅ | PostgreSQL 3 таблицы |
| Административное управление лимитами | ✅ | `/admin`, `PATCH /api/v1/companies/:id/limit` |

### 3. Роли и права — ✅

| Требование | Статус |
|---|---|
| Client: видит только свои записи | ✅ |
| Client: CRUD своих записей в пределах лимита | ✅ |
| Admin (WZ01112): видит все компании | ✅ |
| Admin: CRUD всех записей | ✅ |
| Admin: изменение лимитов | ✅ |
| Несколько компаний на пользователя | ⏸️ (не реализовано — ждём devops) |

### 4.1. Просмотр списка — ✅

| Требование | Статус | Примечание |
|---|---|---|
| Таблица записей активной компании | ✅ | |
| Admin — записи всех компаний с фильтром | ✅ | `?company=<id>` |
| Колонки: значение, комментарий, автор, дата создания, дата изменения | ✅ | |
| Soft-deleted скрыты по умолчанию | ✅ | |
| Фильтр soft-deleted для admin | ❌ | `listEntries(includeDeleted)` есть, но API не принимает параметр |
| «использовано X из N» | ✅ | `used` / `limit` в ответе API |

### 4.2. Создание записи — ✅

| Требование | Статус |
|---|---|
| Поля: значение, комментарий (до 255) | ✅ |
| Валидация на клиенте и сервере | ✅ (см. примечание по клиентской) |
| Проверка лимита, пересечений, дубликатов, запрещённых диапазонов | ✅ |
| Аудит при создании | ✅ |

### 4.3. Редактирование — ✅

| Требование | Статус |
|---|---|
| Редактирование значения и комментария | ✅ |
| Повторная полная проверка при изменении значения | ✅ |
| Аудит с прежним и новым значением | ✅ |

### 4.4. Soft delete — ✅

| Требование | Статус |
|---|---|
| Логическое удаление (deleted_at, deleted_by) | ✅ |
| Освобождение места в лимите | ✅ |
| Исключение из выдачи | ✅ |
| Аудит | ✅ |

### 4.5. Лимиты — ✅

| Требование | Статус |
|---|---|
| Глобальный лимит по умолчанию: 15 | ✅ |
| Настройка через конфигурацию (env) | ✅ `DEFAULT_LIMIT` |
| Per-company лимит (выше и ниже глобального) | ✅ `custom_limit` |
| Блокировка с понятным сообщением | ✅ 409 с «Лимит исчерпан» |
| Снижение лимита не удаляет существующие записи | ✅ |

### 4.6. Журнал аудита — ✅

| Требование | Статус |
|---|---|
| Все изменяющие операции фиксируются | ✅ CREATE, UPDATE, DELETE |
| Поля: кто, когда, компания, действие, прежнее/новое состояние | ✅ |
| Доступен только администратору | ✅ 403 для user |

### 4.7. Внешняя выдача — ⚠️

| Требование | Статус |
|---|---|
| Суммаризация CIDR по всем компаниям | ✅ `aggregateCIDRs()` |
| HTTP GET endpoint, txt | ⚠️ `/exp` (временный), `/export` требует авторизации |
| Без авторизации (сетевое ограничение) | ⚠️ `/exp` — да, `/export` — нет |

### 5. Валидация — ✅

| Требование | Статус |
|---|---|
| /22–/32 маски | ✅ |
| Только IPv4 | ✅ |
| Нормализация host bits + уведомление | ✅ `wasNormalized` передаётся в UI |
| Запрет 14 диапазонов (Приложение А) | ✅ все 14 |
| Отсутствие дубликатов в компании | ✅ |
| Отсутствие пересечений в компании | ✅ |
| Комментарий ≤ 255 | ✅ |
| Клиентская валидация | ⚠️ только HTML5 `pattern` — нет JS-проверки диапазонов |

---

## НЕРЕАЛИЗОВАННЫЕ / НЕПОЛНЫЕ пункты

| # | Пункт ТЗ | Описание расхождения | Приоритет |
|---|---|---|---|
| 1 | 4.1 | Фильтр soft-deleted записей для admin: `listEntries(includeDeleted=true)` есть, но API-роут `GET /api/v1/entries` не принимает `?includeDeleted=true` | P2 |
| 2 | 4.7 | `/export` требует авторизацию (Bearer). По ТЗ — без авторизации (сетевое ограничение). Обход: `/exp` | P1 — требуется решение |
| 3 | 5 | Клиентская валидация — только HTML5 `pattern`, нет JS-проверки масок /22–/32 и запрещённых диапазонов на стороне браузера | P3 |
| 4 | 3.1 | Несколько компаний на пользователя — не реализовано (ждём уточнения от devops) | P1 |
| 5 | 2 | OIDC-авторизация — код написан (`src/auth.js` OIDC-ветка, `src/routes/auth.js` с `/callback`), но не подключён в `server.js` | P0 для прода |

---

## РЕКОМЕНДАЦИИ

1. **Перед продом:** подключить OIDC-роутер, убрать DEV_MODE
2. **Экспорт:** решить — делать `/export` публичным или оставить `/exp` как временное решение
3. **Soft-delete фильтр:** добавить `?includeDeleted=true` в API и UI для admin
4. **Клиентская валидация:** добавить JS-проверку масок и запрещённых диапазонов