Проекция заказа: второй выход commerce, user_id и деньги #90

New Issue

2026-08-17T22:54:54+03:00

ddmitry commented

2026-08-17 22:54:54 +03:00

Part of #5.

Цель

Торговая половина дня-функции уже посчитала корзину, цены, купон и номер
заказа; этот тикет учит генератор смотреть на неё глазами бэкенда: заказ —
проекция покупки, а не второе порождение. Учебный результат: два источника
согласованы по построению, а не сверкой.

Что войдёт

Второй выход commerce: заказы дня готовой структурой; в торговый
подпоток не добавляется ни одного нового броска.
Синхронная модель: строка заказа создаётся синхронно с покупкой, день
рождения заказа равен дню создания строки; order_id равен клиентскому
purchaseID.
Подпоток заказной стороны заводится здесь: позиция DISCREPANCIES = 2 в
seeds.py переименовывается в имя заказной стороны (имена мертвы — из
них никто не бросает, переименование ничего не сдвигает; LATECOMERS = 3
не трогать — позиция событийной стороны, её наполнит этап 6). Ветвление —
по дню рождения заказа.
Деньги заказа, в целых копейках: items_total — из корзины; discount —
из промокода события по готовой таблице «код → скидка» (число мира
этапа 2); delivery — бросок заказной стороны по таблице целых весов, на
полную длину дня; total = items_total − discount + delivery.
person_id — последний обычный бросок когорты; вторая кука пары
повторяет ID своего человека; заказ показывает его как user_id
(UInt64, значение ниже 2^53). В событие Метрики ни person_id, ни
user_id не попадают.
K = 7 — константа мира в конфигурации, рядом с D0 и поясом.

Границы

Судьба заказа (исход, моменты, дельта) — #91; здесь у заказа ещё нет
статуса.
Сериализация и отправка — #92.
Опоздание и событийная сторона порчи (потеря, дубль) — этап 6 (#8);
хвост порядка бросков заказной стороны остаётся открытым для дописывания
(правило порядка бросков).
Числа таблицы доставки — черновая калибровка; финальная фиксация — этап 7.

Сначала прочитать

docs/architecture/orders/snapshot.md — откуда берётся заказ,
случайность;
docs/architecture/orders/identity.md — человек, person_id, user_id;
docs/architecture/orders/fate.md — правило формы броска;
docs/architecture/orders/code-rules.md;
docs/specs/2026-08-01-generator.md — иерархия зёрен, правило порядка
бросков, «Чем меряется генератор»;
мастер-спека docs/specs/2026-07-30-stand-v2-realism.md, разделы 2 и 4 —
поля слепка, ориентиры долей;
generator/src/clickstream_generator/seeds.py и
generator/tests/test_seeds.py — занятые позиции подпотоков.

Проверка

Всё — в generator/: make lint, make typecheck, make test. Проверять
свойства, а не текст вывода; инструменты — POSIX (ripgrep на машине стенда
нет).

У каждого заказа дня ровно одно событие purchase; order_id равен
purchaseID; корзина, суммы и купон совпадают с торговой половиной.
События дня при включении заказной стороны не меняются байт в байт.
На каждом заказе total = items_total − discount + delivery.
Обе куки пары дают один user_id; user_id не попадает в событие
Метрики.
Повторный прогон того же дня даёт те же заказы (детерминизм).

Part of #5. ## Цель Торговая половина дня-функции уже посчитала корзину, цены, купон и номер заказа; этот тикет учит генератор смотреть на неё глазами бэкенда: заказ — проекция покупки, а не второе порождение. Учебный результат: два источника согласованы по построению, а не сверкой. ## Что войдёт - Второй выход `commerce`: заказы дня готовой структурой; в торговый подпоток не добавляется ни одного нового броска. - Синхронная модель: строка заказа создаётся синхронно с покупкой, день рождения заказа равен дню создания строки; `order_id` равен клиентскому `purchaseID`. - Подпоток заказной стороны заводится здесь: позиция `DISCREPANCIES = 2` в `seeds.py` переименовывается в имя заказной стороны (имена мертвы — из них никто не бросает, переименование ничего не сдвигает; `LATECOMERS = 3` не трогать — позиция событийной стороны, её наполнит этап 6). Ветвление — по дню рождения заказа. - Деньги заказа, в целых копейках: `items_total` — из корзины; `discount` — из промокода события по готовой таблице «код → скидка» (число мира этапа 2); `delivery` — бросок заказной стороны по таблице целых весов, на полную длину дня; `total` = `items_total` − `discount` + `delivery`. - `person_id` — последний обычный бросок когорты; вторая кука пары повторяет ID своего человека; заказ показывает его как `user_id` (`UInt64`, значение ниже 2^53). В событие Метрики ни `person_id`, ни `user_id` не попадают. - K = 7 — константа мира в конфигурации, рядом с D0 и поясом. ## Границы - Судьба заказа (исход, моменты, дельта) — #91; здесь у заказа ещё нет статуса. - Сериализация и отправка — #92. - Опоздание и событийная сторона порчи (потеря, дубль) — этап 6 (#8); хвост порядка бросков заказной стороны остаётся открытым для дописывания (правило порядка бросков). - Числа таблицы доставки — черновая калибровка; финальная фиксация — этап 7. ## Сначала прочитать - `docs/architecture/orders/snapshot.md` — откуда берётся заказ, случайность; - `docs/architecture/orders/identity.md` — человек, `person_id`, `user_id`; - `docs/architecture/orders/fate.md` — правило формы броска; - `docs/architecture/orders/code-rules.md`; - `docs/specs/2026-08-01-generator.md` — иерархия зёрен, правило порядка бросков, «Чем меряется генератор»; - мастер-спека `docs/specs/2026-07-30-stand-v2-realism.md`, разделы 2 и 4 — поля слепка, ориентиры долей; - `generator/src/clickstream_generator/seeds.py` и `generator/tests/test_seeds.py` — занятые позиции подпотоков. ## Проверка Всё — в `generator/`: `make lint`, `make typecheck`, `make test`. Проверять свойства, а не текст вывода; инструменты — POSIX (ripgrep на машине стенда нет). - [x] У каждого заказа дня ровно одно событие `purchase`; `order_id` равен `purchaseID`; корзина, суммы и купон совпадают с торговой половиной. События дня при включении заказной стороны не меняются байт в байт. - [x] На каждом заказе `total` = `items_total` − `discount` + `delivery`. - [x] Обе куки пары дают один `user_id`; `user_id` не попадает в событие Метрики. - [x] Повторный прогон того же дня даёт те же заказы (детерминизм).

ddmitry referenced this issue

2026-08-17 22:55:00 +03:00

Заказная судьба: исход, моменты и дельта #91

ddmitry added a new dependency 2026-08-17 22:55:03 +03:00

#91 Заказная судьба: исход, моменты и дельта

ddmitry added the ready-for-agent label 2026-08-17 22:55:58 +03:00

ddmitry referenced this issue

2026-08-17 22:56:34 +03:00

Этап 3: заказы и каталог #5

ddmitry referenced this issue

2026-08-17 22:58:28 +03:00

Нарезать тикеты этапа 3 по принятой спеке #89