GWPTD Remediation — план работ по шагам (основа ТЗ)

HANDOFF-2026-08-10-noch.md — ЧИТАТЬ ПЕРВЫМ утром 10.08: интерфейс с заглушками готов и проверен, но не выложен — обычный путь закрыт брошенным прогоном сбора. Там одна команда, которая всё закрывает, и почему она требует решения владельца.

DEFEKT-BROSHENNYY-PROGON-BLOKIRUET-VYKLADKU.md — читать при отказе выкладки s3 со словами «Идёт прогонов сбора»: брошенный прогон блокирует любую выкладку навсегда, и закрыть его по устройству нечем. Там же предлагаемое исправление и что делать до него.

⭐ Состояние работ — читать ПЕРВЫМ в новой сессии

HANDOFF-2026-08-10.md — начинать отсюда. Интерфейс для менеджеров: старый /admin скрыт (и как его вернуть — три способа), три площадки работают, остальное закрыто заглушкой. Там же разбор потери 16 300 строк, правило «правка описания требует одного свежего сбора» и почему выкладка s3 четыре раза роняла службу.

HANDOFF-2026-08-09.md — разворот JSON-блобов приёма в колонки: состояние (23 непокрытых листа из 1266, 67 падений в наборе), чем измеряется работа и в чём предел измерителя, три перегородки, порядок работы с роем, грабли и закрытые решения владельца. Там же — что идёт у роя прямо сейчас и что делать дальше по порядку. Начинать отсюда.

Прежнее состояние того же дня

Состояние работ на 09.08.2026 — читать ПЕРВЫМ в новой сессии

HANDOFF-2026-08-09-utro.md — разворот JSON-блобов приёма в колонки: где мы по числам, что изменилось в устройстве работы (колонки заводит порождающий скрипт, манифест различает приём и вход ядра, заполнение прошлого), что идёт прямо сейчас и чем проверять приёмку. Там же — чего приёмка НЕ видит.

⭐ Действующий план перестройки ядра данных (06.08.2026)

PLAN-CORE-REBUILD-2026-08-06.md — читать первым при возврате к работе над новой моделью данных. Решения владельца, где живёт мастерская и где приёмка, что уже готово и переделывать не надо, единое правило денежных колонок, порядок этапов с гейтами.

Заменяет порядок этапов из review-пакета Codex; целевая модель оттуда остаётся действующей.

Целевая эксплуатационная модель: s2 Canon / s3 Next Cleanroom (2026-07-13)

Утверждённый план разделения production s2 и чистой Next-системы на s3, автоматической межсерверной сверки и отдельного documentator frontend/backend: S2-CANON-S3-NEXT-CLEANROOM-PLAN.md. Он дополняет технический Spec-Driven план ниже и имеет приоритет для размещения runtime, архивации s3, веток, parity и публикации Next-документации. Автономный runtime S3 уже развёрнут; текущая топология и эксплуатация описаны в S3-NEXT-AUTONOMOUS-RUNBOOK.md.

Широкий план доведения S3 до production readiness, включая межсерверный parity, минимальное укрепление S2, data-gates ассортиментной матрицы, разделение агентских сессий и Definition of Done: S3-NEXT-PRODUCTION-READINESS-PLAN.md. Он не заменяет Cleanroom-архитектуру и Wave 7 runbook; для collector recovery он является архитектурным/бэклоговым контекстом, а не источником статуса gate-ов.

Разбор суток 04.08: RETRO-2026-08-04.md — авария выкладки, ошибочные гипотезы и машинные проверки; читать после инцидента и перед следующей выкладкой.

Фокусный план восстановления collector-контура по фактическому runtime S2, разделяющий API collection, потерянные scheduler-slots, kernel build и row-level parity: S2-REFERENCE-S3-COLLECTOR-RECOVERY-PLAN.md. Он имеет статус APPROVED / EXECUTION IN PROGRESS и является единственным каноном фактического статуса и переходов P0–P7 collector recovery: работа разрешена в next/spec-platform и на S3, а S2 остаётся строго read-only oracle. Ручные collector-runs и deploy выполняются только по gate-ам самого плана.

Реестр и обратимый порядок сворачивания накопившихся agent-веток/worktree: BRANCH-WORKTREE-CONSOLIDATION-2026-07-20.md (выведен в архив: docs/_archive/docs-archive-2026-08-history.zip). Он не меняет collector gates и не разрешает массовое удаление без сохранения уникальных незакоммиченных работ.

Текущий тёмный контракт P3-B (activation/slot/fence/pre-seal provenance без активации scheduler-а) описан отдельно в P3-SCHEDULE-SLOT-LEDGER-CONTRACT.md. P3-C trust split (scheduler USAGE only и typed Unix control API) описан в P3-SCHEDULE-CONTROL-PLANE-CONTRACT.md. Он уже развёрнут на S3 в состоянии DEPLOYED / DARK / NOT ACTIVATED: exact principal/grant/credential attested, но socket/service, launcher, reconciler, cron mutation и scheduler activation отсутствуют. Историческая сверка P3.7 bootstrap-receipt также завершена, однако live proof для SIGKILL -> PDEATHSIG, MCP retry и lock contention остаётся открытым.

Машиночитаемая стартовая матрица endpoint-контрактов из этого плана: generated/S2-S3-ENDPOINT-CONTRACT-MATRIX.md. Она привязана к immutable read-only S2 source SHA, разделяет 67 common endpoint и 12 extensions S3 и честно показывает строки, которые ещё ждут field-level review.

Побайтно проверяемая история всех редакций этого плана, исходные пакеты Spec-Driven Platform, первые implementation/G10 checkpoints и команды воспроизведения собраны в отдельном history/ (выведен в архив: docs/_archive/docs-archive-2026-08-rod.zip). Исторические снимки не являются исполняемыми инструкциями.

Текущий воспроизводимый W0 baseline и девять data-gates: S3-NEXT-PARITY-REGISTER.md. Числа берутся из машиночитаемого evidence/w0/W0-BASELINE-2026-07-14.json; принятые владельцем расхождения ведутся только в docs/domain/ACCEPTED-DIFFERENCES.md.

Технический schema-3 shadow-контур описан в SCHEMA3-COMPARISON-EVIDENCE.md, а обязательная аттестация legacy producer — в CANON-LEGACY-ATTESTATION-DESIGN.md (выведен в архив: docs/_archive/docs-archive-2026-08-rod.zip).

🧭 Spec-Driven Marketplace Platform (исходный план 2026-07-12)

Программа задаёт универсальный контракт от внешнего API до адаптивной страницы /new: SPEC-DRIVEN-MARKETPLACE-PLATFORM.md (выведен в архив: docs/_archive/docs-archive-2026-08-rod.zip). Это исходный архитектурный план, а не текущий runtime-status. Ревизия 2 (2026-07-12): принятые усиления интегрального ревью вшиты в план, новые места помечены «(R2)». Universal collector и ProductSpec-контур уже реализованы; общая цель трёхкратного уменьшения поверхности изменений остаётся незакрытой и контролируется отдельным G10-gate.

Интегральное ревью плана (Codex-план + Fable-ревью + идеи Gemini) — читать ВМЕСТЕ с планом при owner-review и доработке: SPEC-DRIVEN-MARKETPLACE-PLATFORM-REVIEW.md (выведен в архив: docs/_archive/docs-archive-2026-08-rod.zip) (38 усилений по структуре/эффективности/долговечности, топ-5, 9 несостыковок, §4 — вердикты по всем идеям Gemini; сверено с кодом через mcp-gwptd @ 1f8dc23 и V3-доками; 🔴-пункты вшить до Epic 1 — они меняют язык спеков). Исходные идеи Gemini: SPEC-DRIVEN-PLATFORM-IDEAS.md (выведен в архив: docs/_archive/docs-archive-2026-08-rod.zip) — поглощены интегральным ревью (его §4), отдельно не развивать.

Статус исполнения программы (что сделано / что предстоит, волны, %): SPEC-PLATFORM-STATUS.md (выведен в архив: docs/_archive/docs-archive-2026-08-rod.zip) — живой журнал, читать при продолжении работ. Волны 0–5 закрыты (2026-07-13); versioned bundle содержит 79 ProductSpec и 59 PageSpec, а deploy синхронизирует точный набор collector pointers с bundle. Волна 6 — автономный S3 burn-in и ежедневная read-only межсерверная сверка S2 Canon ↔ S3 Next; live-результат каждого deploy фиксируется в runbook; Волна 7 — WAVE-7-S2-CUTOVER-RUNBOOK.md, читать ПЕРЕД cutover'ом s2, исполнять только по явному OK владельца.

Детальная проработка реализации (исходные факты кода @ 1f8dc23, DDL, схемы спеков, шаги): spec-platform-design/ — индекс + 4 файла; читать при реализации: 01 — Epic 1 (канон/capabilities/язык), 02 — Epic 2–3 (runtime/lease/backfill), 03 — Epic 5 (Data API executor), 04 — Epic 3.5/6–7 (страницы + вертикальный срез wb.stocks).

✅ СТАТУС ИСПОЛНЕНИЯ (2026-07-03)

Все 10 эпиков реализованы, влиты в master (merge e346dd5), развёрнуты на s3 dev (kernel ETL — крон на новом коде). Тесты зелёные: data_api 27, v3 59, kernel-golden 14.

Отложено по стратегии (не баг, осознанное решение):

epic-10/01 — удаление доказанно мёртвого кода (после cutover, старый код держим для сверки).
epic-10/07 — единообразие идиом (замороженный PHP не трогаем до удаления старого слоя).

Owner-gated (действия на s2/инфраструктуре, не код):

Миграция net-колонок, .env на s2, ротация паролей (readonly2026, MySqlMarket10), GWPTD_API_TOKENS, токен WB Finance API.

Полный журнал волн исполнения: _execution-log.md (выведен в архив: docs/_archive/docs-archive-2026-08-history.zip).

Иерархия задач, полученная разворачиванием сводного ревью gwptd-code-review-consolidated-2026-07-02.md (вне репозитория, рядом с ним: /Volumes/2TB-64/NEW_MP/) (коммит 422473a). Каждый файл-задача — атомарный шаг, написанный так, чтобы его мог выполнить даже примитивный агент: цель, точные файлы, текущее/целевое поведение, пошаговые правки, критерий приёмки с тестом.

Старт для любого исполнителя: сначала 00-conventions.md — как работать (MCP-first, пайплайн local→s3→s2, single-file, тест обязателен). Шаблон новой задачи — _TEMPLATE.md.

🎯 Целевая архитектура (стратегия владельца, 2026-07-02) — ЧИТАТЬ ПЕРВЫМ

Инвестируем в НОВОЕ, старое замораживаем и в конце выключаем/стираем.

Целевая = новый интерфейс /new + новые API (Python Data API + kernel ETL). Всё чиним/переписываем ТУТ.
Старый PHP-слой (/admin, RatingService.php, TurnoverCalculationService.php, getSaleCondition, старые SalesResource, старый коллектор marketplace-collector/) — ЗАМОРОЖЕН, не трогаем. Оставляем только для сверки «было→стало» (легко перещёлкиваемся, ловим ошибки).
Через 2-3 дня доп-сверки → выключаем старый интерфейс полностью. В будущих итерациях — стираем старый код из кодовой базы.
Коллектор — только новый (V3). Старый коллектор перестанет работать вместе со старым кодом.
Сейчас же: разметить все старые функции комментарием «идёт на удаление, не модифицировать» — задача epic-10/08-annotate-old-for-deletion.md (выведен в архив: docs/_archive/docs-archive-2026-08-history.zip).

Переприцеливание формул на kernel (✅ подтверждено Fable по коду — `_fable-pass-3-kernel-retarget.md`)

epic-05 (формулы) переприцелен на kernel ETL (marketplace-collector-v3/kernel/etl/). Баги реальны и в новом слое: build_fact_rating.py:137-138 сознательно повторяет дубль Ozon (saved_mp 3 и 5 по группе {3,4,5}, «как legacy»); build_fact_turnover.py:118 берёт все статусы (спрос, не «продано»); возвраты НЕ вычитаются (build_fact_returns.py есть, но рейтинг/оборачиваемость его не джойнят). Вычет возвратов — обязателен (решение владельца) → новая задача epic-05/07. Единый realized-канон → epic-05/08.

⚠️ Kernel скопировал 2 legacy-бага «для парности сверки» (Ozon-дубль, все-статусы turnover) → их фикс рвёт сверку 1:1 с legacy. Порядок жёсткий: финальное окно сверки → снапшот-baseline → фикс формул.

⚠️ «Лёгкий выключатель»: интерфейс — да, система — нет (Fable §5)

Репозиторий и Filament-панель одни на оба деплоя; «/new» = тот же код с INTERFACE_VARIANT=new. Гейт canAccess()==='new' есть только у 16 *ApiPage — старые страницы (11 шт.) и все Resources НЕ загейчены и работают в /new. Перещёлкнуть вариант просто, но полному выключению мешают: (1) незагейченные старые страницы → нужен гейт OldInterfaceOnly (epic-10/08); (2) новая ShipmentDistributionApiPage пишет через legacy ShipmentService в shipments; (3) corrective-отгрузка есть только в старой ShipmentPage → нужен порт (epic-05/05); (4) auth/users /new-клона — та же MySQL. Вывод: выключаем интерфейс и коллектор, но БД и часть shared-сервисов живут до перевешивания на kernel.

Раздел «Приоритет владельца» ниже дополняется этой стратегией: старое-side задачи (SQL-инъекция в старых SalesResource epic-08/01, старый мёртвый код epic-10) → в «заморозка/не трогаем». SQL-инъекцию закрывает гейт OldInterfaceOnly, а не фикс (идея Fable #3).

Приоритет владельца (важно)

Порядок эпиков отражает приоритеты владельца, а не абстрактную «серьёзность»:

Логика и потерянные/искажённые данные — важнее всего.
Секреты/захардкоженные креды — наименьший приоритет (эпик 09, в самом низу). Прод сейчас на data_api_ro с включённым auth — острота снижена; делаем в последнюю очередь.

Директивы и решения владельца (2026-07-02) — встроены в задачи

WB-финансы НУЖНО собирать — миграция на новый Finance API detailed (POST), спека в gwptd-analytics/docs/wb_finance_migration.md, дедлайн старого endpoint 15.07.2026 → epic-01/01-wb-finances-restore.md (выведен в архив: docs/_archive/docs-archive-2026-08-history.zip).
Номера маркетплейсов (mp_id) — аддитивно, не ломая историю → epic-02/00-mp-id-numbering-design.md (выведен в архив: docs/_archive/docs-archive-2026-08-history.zip).
Квоты корректирующей отгрузки — УТВЕРЖДЕНЫ (матрица mp_id→квота, mp7 опущен), Q1 разблокирован → epic-05/05-corrective-quotas.md (выведен в архив: docs/_archive/docs-archive-2026-08-history.zip).
Секреты/гигиена — в конец (эпик 09). Плюс понижены (прод за Nginx Basic Auth + data_api_ro): trustProxies('*'), пароль в GET у /auto-login, timing-attack в ApiTokenMiddleware, root/root в dev-конфигах → бэклог гигиены (epic-08 «hardening» / epic-09), НЕ P0.
Периметр API — остаётся P0 в части: закрыть /api/* авторизацией, allowlist /api/import, починить битые роуты, SQL-инъекция дат → epic-04/02 + epic-08.
/new больше НЕ обязан быть копией /admin — развивается как самостоятельный интерфейс; задача «привести /new к /admin» из P2 снимается (epic-10).
data_status: ok | no_data | stale | error — явный enum в контракте Data API (epic-01/04, /06).

Четыре независимых потока ревью (все на `422473a`)

Sonnet-рой + opencode/glm + GPT-5.5 + Gemini 3.5 (../analysis_results.md — с корректировками владельца). Пункт, подтверждённый несколькими потоками = высшая уверенность (напр. битые роуты — 4/4).

Карта эпиков (в порядке исполнения)

№	Эпик	Тема ревью	Почему здесь	Статус
01	Целостность данных (выведено в архив)	B1	Ошибки маскируются под нули/пустоту; WB-финансы не собираются	🔴 первично
02	Корректность данных коллекторов (выведено в архив)	B1/B3	V3-Ozon пишет FBO в mp_id=3; mp_id-нумерация; псевдозаказы	🔴 первично
03	Потеря данных: нормализация (выведено в архив)	B2	Товары тихо выпадают из рейтинга/отгрузки	🔴 первично
04	Транзакционная целостность (выведено в архив)	correctness	Неатомарный saveBatch; битые маршруты	🔴 первично
05	Семантика продаж/mp_id (выведено в архив)	B3	Искажены оборачиваемость/рейтинг/отгрузка	✅ разблокирован (все ответы есть); ждёт golden-тестов (07)
06	Граница Data API	B6	501-заглушки, прямой write Laravel→kernel	🟠
07	Тесты (выведено в архив)	B8	Enabler: без golden-тестов формулы менять нельзя	🟠 enabler
08	Безопасность периметра	B5	SQL-инъекция, auth на write, /api/import	🟠 среднее
09	Секреты	B4	Ротация кредов	⚪ низкий (по слову владельца)
10	Чистка структуры	B7/P2	Мёртвый код, доки, разбивка god-файлов	⚪ после тестов

Пере-сортировка NEW vs OLD (Fable §4) — что ДЕЛАЕМ, что ЗАМОРАЖИВАЕМ

ДЕЛАЕМ (новый контур — целевая):

epic-01 целиком (dual-mode виджеты new-сторона, compat/report-роутеры; WB-финансы V3 первым).
epic-02/02 (ozon_analytics views); epic-02/01 → назначить дату выключения Variant E dual-write (kernel-split уже верен, yaml не чиним).
epic-04/01 (ShipmentCalcApiPage::saveBatch, kernel.shipments), epic-04/02 (routes/api.php, битые роуты).
epic-05 целиком (переприцелен на kernel) + новые 07 возвраты, 08 canon.
epic-06 целиком (целевой контур; 06/03 RATING_SOURCE-дефолт обязателен до выключения старого).
epic-07 kernel-golden pytest (PHP-golden на замороженные формулы отменены).
epic-08/02, 08/03 (/api/import, write-auth — общий routes/api.php).
epic-09 дефолты нового контура (DB_KERNEL root/root); epic-10 10/08 (annotate+гейт), 10/01, 10/02, 10/05, V3-часть 10/04/10/06.

ЗАМОРОЗКА (old-only, не трогаем, размечаем @deprecated в epic-10/08):

epic-03/01,02,03 (читатели legacy для старых страниц); epic-03/04 понизить.
epic-05/03 (getSaleCondition mp4 — kernel покрывает), PHP-части 05/01,02,04.
epic-08/01 SQL-инъекция — закрывает гейт OldInterfaceOnly (не фикс), Resources доступны в /new.
PHP-коллекторы/Upsert* (10/04, 10/06 PHP-часть) — умирают со старым.

Легенда приоритетов в задачах

P0 — корректность данных / operator safety · P1 — семантика/граница/тесты · P2 — рефакторинг после тестов. ⛔ — блокер (нужен вход владельца до старта). ✅ CONFIRMED — находка верифицирована по коду.

Прогресс наполнения

✅ ВСЕ 10 ЭПИКОВ РАСКРЫТЫ + 3 прохода Fable вшиты. ~57 атомарных задач.

✅ ИСПОЛНЕНИЕ ЗАВЕРШЕНО (2026-07-03) — все 10 эпиков реализованы и влиты в master (e346dd5), см. статус-блок в начале файла и журнал _execution-log.md (выведен в архив: docs/_archive/docs-archive-2026-08-history.zip). Отложены по стратегии: epic-10/01, epic-10/07. Owner-gated: см. статус-блок выше.

Порядок исполнения (уточнён по 3-му проходу Fable — kernel-first):

epic-07/00 (kernel-golden pytest-харнесс, тест-схема intake) — САМЫЙ ПЕРВЫЙ + минимальный PHP для *ApiPage.
epic-05/08 canon (enabler) → профиль epic-05/06 (по fact_orders) → снапшот-baseline fact_rating/ fact_turnover «как legacy» → kernel-golden 07/01-03 (ДО правок формул/стоков).
P0 данные/безопасность (новый контур): epic-01 (degraded + WB-финансы V3), epic-02/02 + дата выключения Variant E, epic-04 (saveBatch/routes), epic-08/02-03 (/api/import, write-auth).
Семантика epic-05 (kernel): 04 (дубль Ozon, один PR со связкой shipment.py:838) → 01 (turnover realized) → 07 (вычет возвратов, вместе с 01) → 02 (distribution) → 05 (порт corrective — после ответа владельца).
Граница epic-06 → чистка epic-10 (10/08 annotate+гейт) → секреты epic-09 (+ ротация Basic Auth — 30 мин).

✅ 3 вопроса владельцу ЗАКРЫТЫ (2026-07-02):

Corrective — ✅ портируем в /new до выключения старого; запись дистрибуции пока на legacy shipments.
Возвраты — ✅ accrual по return_date + WB вычитаем for_pay (не розницу). Матчинг к продаже → v2.
Парность с legacy — ✅ порядок: окно сверки → снапшот-baseline → фиксы формул → выключение; после — 1:1 не держим.

⭐ Состояние работ — читать ПЕРВЫМ в новой сессии​

Прежнее состояние того же дня​

Состояние работ на 09.08.2026 — читать ПЕРВЫМ в новой сессии​

⭐ Действующий план перестройки ядра данных (06.08.2026)​

Целевая эксплуатационная модель: s2 Canon / s3 Next Cleanroom (2026-07-13)​

🧭 Spec-Driven Marketplace Platform (исходный план 2026-07-12)​

✅ СТАТУС ИСПОЛНЕНИЯ (2026-07-03)​

🎯 Целевая архитектура (стратегия владельца, 2026-07-02) — ЧИТАТЬ ПЕРВЫМ​

Переприцеливание формул на kernel (✅ подтверждено Fable по коду — _fable-pass-3-kernel-retarget.md)​

⚠️ «Лёгкий выключатель»: интерфейс — да, система — нет (Fable §5)​

Приоритет владельца (важно)​

Директивы и решения владельца (2026-07-02) — встроены в задачи​

Четыре независимых потока ревью (все на 422473a)​

Карта эпиков (в порядке исполнения)​

Пере-сортировка NEW vs OLD (Fable §4) — что ДЕЛАЕМ, что ЗАМОРАЖИВАЕМ​

Легенда приоритетов в задачах​

Прогресс наполнения​