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

New Issue

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

ddmitry commented

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

Part of #5.

Цель

Судьба заказа решается при рождении и обязана уложиться в окно K либо не
случиться вовсе. Тикет наполняет заказную сторону: исход, моменты и дельту
суммы (класс C). Учебный результат: расхождение — часть мира, решённая при
рождении, а не грязь, добавленная потом.

Что войдёт

Исход — таблица долей из трёх строк: оплачен; оплачен и отменён; не
оплачен и отменён. Доля неоплаченных пишется явной строкой. На выходе из
окна заказ либо paid, либо cancelled; «навсегда created» не
возникает.
Моменты — таблица целых весов «сколько часов от рождения», строки 0…143,
плюс равномерная секунда внутри часа. Моментов бросается всегда два, на
полную длину дня; у одномоментных исходов второй выбрасывается; где два по
существу — ранний считается оплатой.
Дельта суммы (класс C) — вычеркнутая позиция: выбирается равновероятно,
заказ из одной позиции дельты не получает; items_total и total
уменьшаются на её стоимость во всех слепках заказа.
Броски ложатся в хвост подпотока заказной стороны после доставки (#90);
хвост остаётся открытым опозданию (этап 6).

Границы

Сборка слепка и состояние на границе суток — #92; судьба здесь — данные
(исход и моменты), не статусы в слепке.
Опоздание, потеря purchase (B), дубль (D) — этап 6 (#8).
Числа долей и весов — черновая калибровка; финальная фиксация — этап 7.
Проверок вида «отмен от 4 до 6 процентов» не заводить (правило владельца).

Кому что

Линию уместности на ревью держит Opus.

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

docs/architecture/orders/fate.md — целиком, это спека тикета;
docs/architecture/orders/snapshot.md — раздел «Случайность»;
docs/architecture/orders/code-rules.md;
мастер-спека, раздел 4 — ориентиры долей и приоритет классов.

Проверка

В generator/: make lint, make typecheck, make test.

У каждого заказа судьба лежит внутри его окна: на границе последнего
слепка заказ paid либо cancelled.
Заказ с дельтой короче клиентских массивов ровно на одну позицию;
однопозиционный заказ дельты не получает.
Повторный прогон того же дня даёт ту же судьбу каждого заказа.
Разовый опыт (с PYTHONDONTWRITEBYTECODE=1, результат — в тело PR):
правка таблицы долей исходов не меняет торговую половину дня байт в
байт и не сдвигает судьбу заказов других дней.

Part of #5. ## Цель Судьба заказа решается при рождении и обязана уложиться в окно K либо не случиться вовсе. Тикет наполняет заказную сторону: исход, моменты и дельту суммы (класс C). Учебный результат: расхождение — часть мира, решённая при рождении, а не грязь, добавленная потом. ## Что войдёт - Исход — таблица долей из трёх строк: оплачен; оплачен и отменён; не оплачен и отменён. Доля неоплаченных пишется явной строкой. На выходе из окна заказ либо `paid`, либо `cancelled`; «навсегда `created`» не возникает. - Моменты — таблица целых весов «сколько часов от рождения», строки 0…143, плюс равномерная секунда внутри часа. Моментов бросается всегда два, на полную длину дня; у одномоментных исходов второй выбрасывается; где два по существу — ранний считается оплатой. - Дельта суммы (класс C) — вычеркнутая позиция: выбирается равновероятно, заказ из одной позиции дельты не получает; `items_total` и `total` уменьшаются на её стоимость во всех слепках заказа. - Броски ложатся в хвост подпотока заказной стороны после доставки (#90); хвост остаётся открытым опозданию (этап 6). ## Границы - Сборка слепка и состояние на границе суток — #92; судьба здесь — данные (исход и моменты), не статусы в слепке. - Опоздание, потеря `purchase` (B), дубль (D) — этап 6 (#8). - Числа долей и весов — черновая калибровка; финальная фиксация — этап 7. Проверок вида «отмен от 4 до 6 процентов» не заводить (правило владельца). ## Кому что Линию уместности на ревью держит Opus. ## Сначала прочитать - `docs/architecture/orders/fate.md` — целиком, это спека тикета; - `docs/architecture/orders/snapshot.md` — раздел «Случайность»; - `docs/architecture/orders/code-rules.md`; - мастер-спека, раздел 4 — ориентиры долей и приоритет классов. ## Проверка В `generator/`: `make lint`, `make typecheck`, `make test`. - [x] У каждого заказа судьба лежит внутри его окна: на границе последнего слепка заказ `paid` либо `cancelled`. - [x] Заказ с дельтой короче клиентских массивов ровно на одну позицию; однопозиционный заказ дельты не получает. - [x] Повторный прогон того же дня даёт ту же судьбу каждого заказа. - [x] Разовый опыт (с `PYTHONDONTWRITEBYTECODE=1`, результат — в тело PR): правка таблицы долей исходов не меняет торговую половину дня байт в байт и не сдвигает судьбу заказов других дней.

ddmitry referenced this issue

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

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

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

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

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

#92 Команда snapshot: окно, граница суток, байты и опись

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

ddmitry referenced this issue

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

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

ddmitry referenced this issue