Отчёт
и критерии

§1Что сохранять по ходу работы

Часть подтверждений позже не воспроизвести, поэтому их сохраняют по ходу работы, а не перед сдачей.

§2Как снимать доказательства

Команду приводят рядом с выводом: без неё неизвестно, что именно выполнялось.

$ curl -i -X POST http://127.0.0.1:8000/api/v1/bookings \
    -H 'Authorization: Bearer demo-token' \
    -H 'Content-Type: application/json' \
    -d '{"room": "312", "date": "2026-10-01", "slot": 3}'

HTTP/1.1 201 Created
location: /api/v1/bookings/6dfeb4e3-497b-4d62-8270-40dace132b9f
etag: "72d232d249fabd6e"
x-request-id: 9073c15c-ea8a-409d-b492-5315e909a71b
content-type: application/json

{ "id": "6dfeb4e3-…", "room": "312", "status": "requested", … }

Четыре части — команда, код ответа, заголовки и тело — описывают выполненный запрос полностью.

§3Структура отчёта

Объём отчёта сам по себе не оценивается. Раздел 2 занимает страницу-полторы, раздел 3 — больше всего места, раздел 4 — несколько абзацев. Пересказывать содержание справочника в отчёте не нужно: проверяющий его читал.

§4Раздел «Контракт»

Удобнее всего свести операции в таблицу: она короче текста и показывает контракт целиком.

| Метод и адрес                     | Успех          | Ошибки                    | Заголовки       |
|-----------------------------------|----------------|---------------------------|-----------------|
| GET /api/v1/bookings              | 200            | 422                       | X-Request-Id    |
| POST /api/v1/bookings             | 201 + Location | 401, 403, 422             | ETag            |
| GET /api/v1/bookings/{id}         | 200            | 404                       | ETag            |
| PATCH /api/v1/bookings/{id}       | 200            | 401, 403, 404, 412, 422   | If-Match → ETag |
| DELETE /api/v1/bookings/{id}      | 204            | 401, 403, 404             | —               |

Рядом — три-четыре предложения о схемах: сколько их, чем модель запроса отличается от модели ответа, какие ограничения заданы. И одно предложение про версию: где она указана и по какому правилу меняется.

§5Раздел «Доказательства»

Раздел строят не списком снимков, а по утверждениям: сначала формулировка того, что подтверждается, затем подтверждение.

Шести утверждений с подтверждениями достаточно; остальные приводят по желанию.

§6Раздел «Решения и отступления»

Здесь отвечают на вопросы из главы 7.4 — те, где своды расходятся и выбор за вами.

Решение: мажорная версия в пути /api/v1.
Варианты: путь, заголовок, параметр запроса, media type.
Почему: версия видна в журналах и ссылках; клиентов мало и они обновляются быстро.
Чем платим: несовместимое изменение одной операции требует выпуска /api/v2 целиком.
Источник: Microsoft Graph, ADR 0001 в репозитории.

Отступления от правил справочника тоже записываются в этот раздел. Отступление с названной причиной ошибкой не считается. «Не поддерживаю Idempotency-Key, потому что создание брони и так проверяется по паре аудитория + пара, и повтор не создаст дубль» — это обоснованное решение, а не пропуск требования.

§7Критерии приёмки