0 Fork 0

Files

T

ddadminandClaude Fable 5 6f18e9989c docs(generator): заморожена спека этапа 2, решения — в ADR 0015-0017

- Зачем:
  - спека разрослась до 1058 строк, а журнал решений в разделе 9 читался
    только целиком; агентам и людям нужен дешевый адресный заход к
    основаниям решений генератора.
- Что:
  - заведены ADR 0015 (пояс счетчика), 0016 (паспорт куки) и 0017 (номер
    заказа); четыре адресные ссылки на «раздел 9» перешиты на них.
  - раздел 9 пересобран в 11 тематических подразделов с датами и тикетами
    у каждого решения и закрыт пометкой о заморозке; устаревшие
    промежуточные замеры свернуты до указателей на актуальные.
  - строка статуса в шапке отмечает закрытие спеки как документа этапа 2.
- Проверка:
  - wc -l docs/specs/2026-08-01-generator.md (951, было 1058);
    rg -n 'раздел[а-яё]* 9|разделы 8 и 9' docs -g '*.md' — 18 попаданий,
    все классифицированы; разделы 1-8 нетронуты (сверка хешем).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

2026-08-28 08:16:11 -04:00

2.1 KiB

Raw Blame History

ADR 0017. Номер заказа объединяет две проекции покупки

Дата: 28 августа 2026 года. Статус: принято. Реализация — тикет #40.

Решение

Номер заказа включает день по модельному времени и порядковый номер покупки в этот день, например 20260603-0042. Событийная сторона пишет его в purchaseID, бэкенд — в order_id; обе стороны берут один номер из плана покупки.

Все покупки, попавшие в поток дня, нумеруются в порядке событий и до любых потерь следующих этапов.

Почему

По читаемому номеру сразу виден день заказа. Один номер соединяет две проекции одной покупки. Генераторы кликстрима и бэкенда не согласуют его отдельно.

Присвоение до потерь сохраняет номера остальных заказов: исчезновение одного события не должно перенумеровывать чужие покупки и разрывать связь с бэкендом.

Отклонено

Присваивать номера после внесения потерь: одна потеря сдвинула бы все следующие номера за день и разорвала бы связь уже созданных проекций.

Следствия

purchaseID и order_id изначально совпадают. Из-за расхождения событие может исчезнуть после присвоения номера, но номера сохранившихся заказов не меняются.

Решение принято при исполнении тикета #40 и зафиксировано в спеке этапа 2, раздел 9.

2.1 KiB Raw Blame History