S3 Next — непрерывный план production readiness, parity и развития /new

Статус: EXECUTING — единый план координации работ, а не разрешение на production-изменения. Снято 07.08.2026. Прежний тотальный запрет («пока P1B-3 natural evidence не принято — не менять S3 runtime, не деплоить, не менять cron, не запускать вручную collector/reference sync/build_all») не соблюдался с 15.07: выкладки шли, обёртка деплоя обновлялась 06.08. Правило, которое никто не исполняет, делает недостоверной всю остальную документацию — по ней становится нельзя понять, что разрешено. Действующие ограничения перечислены в карте ограничений и держатся техникой, а не текстом. Требования самого P1B-3 к доказательству естественного цикла сохраняются — см. P1B-3 runbook; отменена именно широкая формулировка, а не сам гейт. Точный live SHA брать только из mcp__gwptd__repo_status. Версия: 2.5 · дата: 2026-07-15 · владелец решения: Anton. Рабочая ветка Next: next/spec-platform. Архитектурный канон: S2 Canon / S3 Next Cleanroom. Живое состояние: SPEC-PLATFORM-STATUS.md (выведен в архив: docs/_archive/docs-archive-2026-08-rod.zip) и S3-NEXT-AUTONOMOUS-RUNBOOK.md. Cutover: только по WAVE-7-S2-CUTOVER-RUNBOOK.md, после всех гейтов и отдельного явного подтверждения владельца. Текущая директива владельца от 2026-07-15: S2 не изменять; там допустимы только read-only evidence и сравнение. Единственная пишущая сессия — текущий Coordinator/Integrator. Разрешены commit/push ветки next/spec-platform, root-side recovery S3, штатный deploy, необходимые миграции S3-БД и ручной catch-up пропущенных задач на S3 под штатными locks. S2 остаётся строго read-only справочником API/данных; изменение S2 и production-cutover этим разрешением не разрешены.

1. Назначение документа

Этот документ переводит архитектурный Cleanroom-план в непрерывную исполняемую программу. Программа должна довести s3 Next до состояния, в котором он:

1. воспроизводит все необходимые функции, расписания, данные и бизнес-процессы действующего s2 Canon;
2. не наследует legacy-дубли и silent fallback;
3. превосходит S2 по корректности, наблюдаемости, скорости, расходу API, сопровождаемости и восстановлению;
4. содержит новые процессы Spec Platform и ассортиментную матрицу в /new;
5. проходит доказанный cutover и только после стабилизации становится новым production-каноном.

До завершения программы s2 остаётся production-каноном и путём отката. Этот документ не разрешает запись на S2, изменение его cron/secrets, cutover или другое owner-gated действие.

2. Связь с другими документами

Документ	Роль
S2-CANON-S3-NEXT-CLEANROOM-PLAN.md	Архитектурные границы, cleanroom, parity и интегральные гейты
SPEC-PLATFORM-STATUS.md (выведен в архив: docs/_archive/docs-archive-2026-08-rod.zip)	Изменчивые текущие факты, SHA, счётчики и прогресс волн
S3-NEXT-AUTONOMOUS-RUNBOOK.md	Эксплуатация автономного runtime S3
S3-NEXT-PARITY-REGISTER.md	Текущий W0 baseline, девять data-gates и G11 streak
CANON-LEGACY-ATTESTATION-DESIGN.md (выведен в архив: docs/_archive/docs-archive-2026-08-rod.zip)	Обязательный S3-only proof legacy producer и условия включения schema-3
SCHEMA3-COMPARISON-EVIDENCE.md	Реализованный shadow-контракт evidence v3, hard-disable и критерии активации
../domain/ACCEPTED-DIFFERENCES.md	Единственный owner-controlled ledger допустимых отличий
WAVE-7-S2-CUTOVER-RUNBOOK.md	Единственная инструкция будущего production-cutover
../matrix/plan.md	Полное бизнес-ТЗ ассортиментной матрицы
../matrix/p5.3/action-plan.md (выведен в архив: docs/_archive/docs-archive-2026-08-rod.zip)	Исторический план §5.3; его UI-архитектура заменена этим документом
../domain/DO-NOT-REGRESS.md	Неподвижные бизнес-решения
../domain/STATUS-SEMANTICS.md	Каноническая семантика data_status

Изменчивые числа не следует копировать из этого файла в другие каноны. После каждого подтверждённого изменения runtime обновляется SPEC-PLATFORM-STATUS.md, а этот файл меняется только при изменении этапов, гейтов или ответственности.

3. Definition of Done

Цель считается завершённой только когда одновременно выполнены все условия:

1. Существует проверяемая карта всех обязательных функций, endpoint'ов, расписаний, таблиц, ETL-преобразований, отчётов и бизнес-процессов S2 с их реализацией либо документированным эквивалентом в S3.
2. Все активные ProductSpec, их outputs, pointer-set и расписание имеют exact-set validation; silent fallback на legacy отсутствует.
3. Все девять наборов Returns, Analytics, Finance, Orders, Prices, Rating, Stocks, Storage, Turnover имеют статус green либо утверждённый владельцем accepted_difference на сопоставимых закрытых окнах.
4. Первичные факты подтверждены раньше производных: Orders, Stocks, Prices, Returns — до Rating, Turnover и комплексной аналитики.
5. Все scheduled endpoint'ы контролируются freshness; DB lease и host lock действительно работают; нет необъяснённых duplicate runs, пропусков и unexpected partial.
6. Amazon работает в согласованном малом режиме, а расход API и длительность сопоставимой нагрузки измерены. S3 не имеет необъяснимой деградации против S2.
7. Формулы имеют business rule, machine-readable представление, версию и golden cases. Код не становится единственным источником бизнес-семантики.
8. Ассортиментная матрица реализована в Data API и обязательном интерфейсе /new; права действуют на API/export-уровне, а непроверенные метрики не показываются пользователю как достоверные.
9. Документация, parity-register, accepted-difference ledger, runbooks, расписания, мониторинг и rollback позволяют новой агентской сессии продолжить работу без восстановления контекста по исходному коду.
10. Пройден канонический Gate G11: не менее 14 последовательных зелёных дней, aggregate delta < 0.5%, stale Canon = 0, без сбросивших streak событий.
11. Владелец отдельно разрешил production-cutover; cutover исполнен по Wave 7, rollback rehearsal был успешным, а после переключения завершено окно усиленного наблюдения.
12. S2 выведен из роли канона только после наблюдаемого подтверждения, что реальные сборы, ETL, отчёты, /new, матрица, мониторинг и права работают штатно на новом production-контуре.

Успешный код, тест или один зелёный comparator run не является завершением цели.

4. Воспроизводимый W0 baseline

Авторитетный снимок сохранён в evidence/w0/W0-BASELINE-2026-07-14.json и воспроизводится одной read-only командой:

scripts/docs/capture-backend-runtime.sh \
  --output docs/remediation/evidence/w0/W0-BASELINE-2026-07-14.json

Снимок 2026-07-14T12:43:21Z не запускал collectors, не писал на серверы и не содержит secrets/raw business rows. Он фиксирует full Git SHA, installed/versioned cron digests, endpoints, pointers, lease, freshness, hard invariants и последний сохранённый comparator run. Управленческий статус девяти наборов находится в S3-NEXT-PARITY-REGISTER.md, а не выводится из одного поля rawStatus.

4.1. Контуры

Параметр	S2 Canon	S3 Next
Git snapshot	master@cc3bc20, clean	next/spec-platform@5684fb3, clean
Назначение	production-канон	автономный staging/Next
Collector	legacy collector.py	next_collector.py + ProductSpec/plugins
ProductSpec / endpoint'ы	67 endpoint'ов	79 ProductSpec; 77 endpoint'ов уже имеют run
Runtime selection	возможен legacy fallback	exact pointer-set, fail-closed
Concurrency	host flock; DB lease store недоступен	host flock + доступный DB lease store
Freshness	freshness OK в 12:00 UTC	freshness OK в 10:45 UTC
Secrets	найден tracked wrapper	root-owned runtime env
Installed cron	18 строк; содержит все 9 versioned V3 rows и 9 production/legacy rows	25/25, exact digest match
Pointer-set	not applicable	79/79 next, digest 79/79
Hard invariants	invariant gate passed 13 июля в 13:15 UTC	invariant gate passed 14 июля в 09:19 UTC

Это исторический W0-снимок, а не утверждение о текущем freshness. Инцидент F-64/F-65 от 15 июля разобран отдельно: неуспешный deploy/recovery держал root cron в fail-closed quarantine и пропустил Ozon, YM и Lamoda. Это не ошибка их общих API. Ручной catch-up Ozon завершился успешно 18/18 в 12:59 UTC; YM core дал 16 success + 1 false partial при фактически полных 973/973 строках ym.realization, а quota-heavy ym.competitors_position сознательно не входил в core-run. Lamoda запущена в 12:58 UTC строго после завершения одноимённого процесса S2; к 13:23 UTC шесть endpoint'ов завершились success, а lamoda.status_dates продолжал работу. Общий API не получил конкурирующих одноимённых запусков.

По измерению другой сессии S3 уже быстрее на сопоставимых задачах: WB примерно 29 против 48 минут, основной Ozon-цикл 17 против 40 минут, 1С 20 против 126 секунд. Это baseline-кандидат, а не финальное доказательство: сравнение повторяется на одинаковом scope после чистого суточного цикла.

4.2. Последний сохранённый parity run, окно 2026-07-05..2026-07-11

Run 07c3382f-699c-4202-aeff-6b73b2afc92d выполнен 2026-07-13 14:52:22 UTC. Он предшествует первой штатной работе текущего spec-driven comparator и не содержит source/spec/formula digests. Поэтому ни один результат из него не начинает G11; текущий streak всех наборов равен нулю.

Набор	Raw status	Product parity	Максимальное/структурное расхождение
Returns	green	unverified	0 из 24 групп
Analytics	mismatch	blocked	1 из 14, до 1.7714%
Finance	mismatch	blocked	1 из 14, до 2.4165%
Orders	mismatch	blocked	2 из 47, до 6.808%
Prices	mismatch	blocked	10 из 24, до 100%
Rating	mismatch	blocked	5 из 5, до 212.4985%; run старее spec v1.1.0
Stocks	mismatch	blocked	8 из 58, до 100%
Storage	mismatch	blocked	2 из 7, до 1.238%
Turnover	mismatch	blocked	25 из 28, до 100%

Известные ожидаемые различия оформляются отдельно:

• Golden Apple (mp=10) есть только на S3;
• S3 хранит дополнительные исторические срезы turnover;
• часть различий Ozon связана с историей и осознанной дедупликацией.

Кандидаты описаны в ACCEPTED-DIFFERENCES.md, но принятых отличий сейчас нет. Ожидаемое отличие не становится accepted_difference автоматически: нужны воспроизводимое объяснение, точный scope и утверждение владельца.

4.3. Исполняемый checkpoint 2026-07-15

Это состояние отмечает уже выполненную работу и открытые live-gates; оно не заменяет Definition of Done. Колонка «снято из активной очереди» сохраняется как evidence, но перечисленные в ней code-задачи повторно не планируются.

Статус	Поток	Снято из активной очереди	Активный остаток
✅ CODE / ⏳ LIVE	Universal collector	79 active ProductSpec, единый runtime/plugins/runner, legacy endpoint-файлы не активны, exact pointer/fail-closed contracts	естественные scheduled циклы после восстановления runtime
✅ CODE / ⏳ LIVE	YM F-59	двухстадийный run_yandex_daily.sh: core раньше quota-heavy competitors; единый hardened lock и DB-free fault tests	первый полный штатный YM-цикл без ручного запуска
✅ LIVE f2c606c	Deploy F-60	recovery, enum, index-order, CREATE/CHECK normalization и portable privilege audit закрыты; run 29402638900 полностью зелёный	снято из активной очереди; сохранять failure-atomic contracts и evidence
✅ LIVE RECOVERED	Recovery F-60	bundle v2 восстановил af70917→ca38823; exact прежние app/API healthy с restart=unless-stopped, cron digest ced1a527… восстановлен, checkout clean, все sentinel-файлы удалены; no-DML DB proof после recovery 79/79, audit delta 0; sanitized evidence	снято из активной очереди; bundle и fault contracts сохраняются как rollback evidence
✅ LIVE PROOF	DB compatibility	schema-3 43 columns, rating audit 14, exact indexes/CHECKs, trigger count 0, grant audit green, pointers 79/79/79	снято из активной очереди; schema-3 execution остаётся hard-disabled до отдельных Canon-attestation gates
✅ CI / ✅ LIVE	Tests and deploy	V3 882 passed / 26 skipped; повторный workflow 29414892910 полностью green. Commit a59efaab79d856ea0fbe5180b38864f5f5ac7f11 штатно deployed 15 июля в 12:42 UTC; branch/HEAD/checkout, app/API, wrapper, cron, systemd generator/drop-ins и sentinels доказаны exact	сохранять full-history и pinned MCP/Qdrant dependency contracts; новый diff снова проходит полный CI
✅ LIVE ACTIVATED	Runtime S3	phase-0 завершён штатным deploy; app/API healthy, cron exact 61 строк (37dfd1f1…), MCP service/timer active, active generation 13127 points, marker/receipt exact commit a59efaa, rollback generation 12915 points	дождаться успешного естественного timer-run после освобождения codebase lock и выполнить новый off-host backup/drill
✅ DESIGN / ▶ NEXT	Architecture F-61	collector legacy surface 0, duplication 2.1155%; дизайн разделил product baseline af70917 и assurance/operations baseline f23be76	total/non-ambiguous classifier, frozen ceilings + previous-commit ratchet, protected paths и CI exit 0/1/2; затем декомпозиция без удаления safety/evidence
✅ CODE / ✅ LIVE / ⏳ BACKUP F-62	MCP reindex atomicity, deploy and recovery	единый supervisor и COW contract прошли штатный deploy; live alias/marker/receipt/rollback/count exact; exact MySQL inventory/compare, truthful encryption scope, continuous Qdrant→DB lock и durable post-cleanup receipt реализованы локально	доставить recovery diff → естественный timer-run → новый off-host backup → archive-only drill и durable receipt proof
⏸ DEFER F-63	ETL generation patch	отдельный read-only review подтвердил применимость и тесты подготовленного commit a4644d2	не интегрировать как есть: сначала clean-checkout proof, inherited locks во всех прямых writers, failure-atomic deploy tests и decomposition файлов >500 строк
🔧 REPAIR F-64/F-65	Freshness incident	45 stale = Goldapple 1 + WB paid storage 1 + Lamoda 7 + Ozon 18 + YM 18. Причина cron quarantine, а не разные API. Ozon 18/18 success; YM core 16 success + 1 false partial с полными данными; Lamoda продолжает status_dates. Commit e70e6fc прошёл CI и ждёт Lamoda-lock перед deploy	завершить Lamoda/deploy; доставить устранение sticky async partial и quota-heavy competitors fail-closed; точечно повторить ym.realization и competitors; затем exact freshness и естественный цикл

Ближайший порядок: завершить Lamoda → дать ожидающему deploy e70e6fc пройти → зафиксировать и доставить async/recovery hardening → точечно повторить ym.realization/competitors и доказать exact freshness → получить естественный timer-run → новый off-host backup и archive-only drill с exact inventory/ durable receipt → F-61 architecture ratchet → исправленная F-63 integration → декомпозиция. F-60 recovery, повторный CI, deploy и MCP live activation сняты из активной очереди.

4.4. Новые находки и очередь от быстрого к долгому

Порядок	Находка	Решение / gate
1	RESOLVED: MySQL печатает explicit CHARACTER SET utf8mb4 после ALTER	7339de3: token-scoped normalization только при exact unicode table default; incompatible charset/collation и DEFAULT/COMMENT literals значимы
2	RESOLVED: rollback assertion генерировал SQL с balance +1	7339de3: скобка закрыта, quote-aware balance scanner и реальный rollback rehearsal зелёные
3	RESOLVED: recovery profile устарел после collation DDL	pinned profile v2 доказал facts/grants/Git/container/journal; no-DML recovery af70917→ca38823 успешно committed
4	RESOLVED IN CODE / LIVE GATE: MCP reindex мог долго держать lock и частично менять live index	F-62 реализовал единый COW supervisor, exact read-back, alias/marker/receipt recovery, deadline/heartbeat/TERM и inactive-only cleanup; закрывается после штатного deploy и естественного live-run
5	Measurement называет неполные четыре зоны всей кодовой базой и не защищает достигнутое снижение	F-61: classifier exact-path→longest-prefix, отдельные product/assurance/operations, frozen checkpoint ceilings и previous-SHA ratchet
6	Assurance-код временно растёт из-за parity/recovery; общий LOC ceiling стимулировал бы удалить тесты	Для assurance LOC только отчётный, но protected-path floor не уменьшается; product/operations LOC и duplicates не растут без versioned exception
7	Подготовленный ETL-generation patch не доказывает чистый runtime и позволяет direct writers обходить lock/generation invalidation	F-63 остаётся deferred; перенос только поверх зелёного F-60 с обязательным clean-checkout proof и единым inherited-lock entrypoint
8	Крупнейшие зоны остаются лоскутными: Filament 25.62%, Data API 9.39%, kernel и deploy/parity растут	После instrumentation gate: shared Page/Grid/ReportSpec, query primitives и разбиение rating/deploy/evidence по доменам; не смешивать с incident recovery
9	Общий whitespace normalizer исторически схлопывает пробелы также внутри quoted DEFAULT/COMMENT literals	Текущие три F-60 contract tables таких literals не имеют; добавить token-aware whitespace normalization до расширения этого helper на новые схемы
10	RESOLVED: outer sh -lc '…' съедал кавычки в трёх enum metadata literals	752df16: exact uppercase HEX(column_type); tests декодируют constants и запрещают raw enum literals
11	RESOLVED: MySQL index и CHECK order ошибочно считались семантикой CREATE	50eb196 задаёт deterministic PRIMARY-first index order; 3554205 сортирует только contiguous named CHECK block, сохраняя полные definitions
12	RESOLVED: privilege audit маскировал SQL error как несовместимые права	f2c606c: routine grants читаются из поддерживаемой mysql.procs_priv; audit query имеет отдельный fail-closed error; live audit rc=0
13	RESOLVED IN CODE: MCP sync_and_index допускал checkout git pull и destructive legacy --recreate	Все entrypoint'ы направлены в supervisor; checkout mutation отсутствует, recreate отвергается, raw worker требует inherited lock FD
14	Freshness alert представлял один оборванный YM batch как 15 stale endpoint'ов	F-64 хранит causal batch evidence; Goldapple уже green, YM закрывается только естественным двухстадийным циклом без ручного запуска
15	F-62 worker вырос до ~1.4k строк и смешивает Git, embedding, COW, receipt/recovery и GC	После live proof разложить на durable state, Qdrant transaction, Git/input preparation и тонкий job entrypoint; behavioral fault suite сохранить как protected floor
16	Прежний off-host backup не содержал Qdrant/marker/receipt и MCP .venv	В коде добавлены shared-lock snapshot export, durable orphan receipt, pinned-image archive, exact Git bundle, venv и disposable restore; gate закрывается только успешным реальным backup+drill
17	MCP transport на localhost использует отключённую DNS-rebinding protection для существующего tunnel/proxy	Exact MCP 1.27.0 закреплён и API attested; после F-62 live proof заменить disable на проверенный allowlist Host без потери Happy/MCP-доступа
18	RESOLVED IN CODE / LIVE GATE: production Qdrant container не имел versioned clean-host definition	Добавлены digest-pinned compose, offline recovery override, exact live inspect attestation и archive-first disposable drill; закрывается после штатной установки contract-файлов и реального off-host drill
19	RESOLVED IN CODE: marker уже равнялся HEAD, но receipt отсутствовал, поэтому прежний incremental делал noop и backup навсегда оставался заблокирован	No-change без receipt теперь обязан snapshot-clone active→candidate, atomically swap alias и создать distinct immediate rollback + receipt; live read-only preflight подтвердил legacy baseline 12915 points, marker=HEAD, receipt absent
20	RESOLVED IN CODE: COW bootstrap внутри rollbackable deploy мог разойтись с откатом checkout; reboot мог поднять MCP по незавершённому sentinel	Bootstrap перенесён после control-plane commit, но до outer completion; запуск MCP/timer происходит только после durable удаления sentinel через ConditionPathExists и backward-compatible path unit, поэтому первый deploy не зависит от уже запущенных старых bytes wrapper
21	RESOLVED IN CODE: archived receipt ссылался на rollback generation, snapshot которой не входил в clean-host backup	Archive receipt остаётся capture evidence, но не восстанавливается как live state; drill восстанавливает active snapshot и выполняет unchanged COW bootstrap, создавая новый truthful active/rollback/receipt contract
22	RESOLVED IN CODE: pg_dumpall restore с ON_ERROR_STOP конфликтовал с уже существующими bootstrap role/database	Disposable PostgreSQL поднимается с уникальными временными role/database, стандартный postgres предварительно удаляется и создаётся самим dump; неожиданные SQL ошибки по-прежнему фатальны
23	RESOLVED IN CODE / LIVE GATE: backup/drill могли пересечься с deploy, терять image tags при signal и оставлять disposable ресурсы	Оба процесса держат host deploy lock весь lifecycle; HUP/INT/TERM завершают операцию, теги восстанавливаются exact, strict cleanup доказывает отсутствие containers/volumes/network/runtime; закрывается реальным drill
24	RESOLVED IN CODE: verifier допускал marker < HEAD, а существующий receipt отключал reindex нового commit	Staging теперь возвращает reindex_required; activator запускает incremental и при stale marker, а strict start/backup/activation требуют exact marker == HEAD и receipt этого HEAD
25	RESOLVED IN CODE / ONE-TIME LIVE GATE: новый wrapper гасит writers до checkout, но фактически установленный predecessor f2c606c (SHA-256 22e1…f6e) переходит на новый checkout раньше нового inner barrier	До push один раз запустить scripts/deploy/quiesce-s3-legacy-mcp-phase0.sh на старом checkout: он под legacy→host→codebase locks отключает MCP/timer/cron, дожидается legacy lock, доказывает writer-absence и пишет durable marker; новый inner откажется от first rollout без этого proof
26	RESOLVED IN CODE / LIVE GATE: обрыв после control-plane commit оставлял blocked runtime; второй workflow-call мог повторить полный deploy	General same-SHA finalizer вынесен из historical BOOTSTRAP_MARKER, требует exact tested SHA, exact installed wrapper и durable activation evidence; без evidence падает fail-closed, workflow заканчивается --verify-activation
27	RESOLVED IN CODE / LIVE GATE: последовательная установка трёх drop-ins имела reboot gap	Early bootstrap сначала атомарно ставит gwptd-deploy-sentinel systemd generator, который одним запуском добавляет condition всем MCP writer units; постоянные drop-ins остаются inspectable-копией; закрыть live systemctl cat proof
28	RESOLVED IN CODE: Qdrant backup exporter мог принять единственный чужой snapshot за свой при ошибке до capture baseline	Cleanup включается только после durable create_requested собственного поколения; prevalidation failure не удаляет snapshots, response-loss reconciliation использует только доказанный baseline/receipt
29	RESOLVED IN CODE / LIVE GATE: MinIO архивировался live raw volume, а shell trap не переживал SIGKILL/reboot	MinIO имеет logical inventory, stop-before-tar, root-owned durable marker, временный restart=always и permanent recovery timer; recovery идемпотентен для stopped и already-running container, возвращает unless-stopped, readiness и durable removal marker. PostgreSQL сравнивается exact по DB/schema/table/row inventory
30	RESOLVED IN CODE / LIVE GATE: backup/drill доверял mutable Docker tags и hard-coded MinIO volume path	Архив получает временные refs exact running image IDs всех шести containers; drill проверяет IDs и запускает их. MinIO /data Source извлекается из live inspect и только этот stopped mount попадает в tar
31	RESOLVED IN CODE: watchdog subshell наследовал FIFO writer FD и мог навсегда зависнуть с remote holder	Watchdog явно закрывает inherited FD8/FD9; behavioral FIFO test доказывает EOF, exit holder/watchdog и normal release без orphan lock
32	RESOLVED IN CODE: TERM Bash-parent откладывался до завершения foreground `ssh	zstd`, поэтому stream мог продолжиться без lock
33	RESOLVED IN CODE: MinIO recovery безусловно вызывал docker start и падал, если restart=always уже поднял container	Recovery делает start только для stopped state; behavioral tests покрывают crash-before-stop/reboot-already-running и ordinary stopped recovery
34	RESOLVED IN CODE / LIVE GATE: restore заявлял from archive itself, но orchestration/helpers брались из текущего checkout	Backup включает exact-SHA recovery-tools; любой внешний drill сразу re-exec'ит архивный orchestrator, verify/PG/MinIO helpers берутся только из архива; закрыть реальным archive-only drill
35	SUPERSEDED BY 42: timestamp-only disposable names могли совпасть, а lock-busy cleanup — удалить чужие resources	Timestamp/PID + 64-bit nonce закрыли практическую коллизию имён, но локального RESOURCES_OWNED было недостаточно для remote ownership; окончательное решение — exact Docker labels в finding 42
36	RESOLVED IN CODE: cancel во время flock -w 21600 мог зависнуть на wait remote SSH	До acquisition CODEBASE_LOCK_ACQUIRED=0; release явно TERM-ит waiting SSH, после acquisition normal EOF завершает holder
37	RESOLVED IN CODE / LIVE GATE: host deploy lock не исключал collectors из PG/MinIO backup window	Qdrant снимается под собственным exclusive lock, затем backup держит exclusive collector/codebase lock до конца DB/object/config streams; внезапную смерть обоих remote holders ловят watchdogs
38	RESOLVED IN CODE: watchdog под set -euo pipefail завершался на rc=1 исчезнувшего ps до аварийного abort	Оба watchdog tolerantly читают пустой process state, затем исполняют fail-closed abort; behavioral tests отдельно покрывают normal FIFO release и неожиданное исчезновение holder
39	RESOLVED IN CODE: первый legacy rollout вызывал barrier повторно из installer после удаления одноразового phase-0 marker	Inner deploy вызывает mutating barrier ровно один раз до schema/image work; installer не потребляет marker повторно и fail-closed доказывает exact installed generator/condition и effective contract каждого writer unit
40	RESOLVED IN CODE: plain inherited GWPTD_NEXT_DEPLOY_OUTER_PHASE_PROTOCOL мог ошибочно отменить phase-0 для legacy wrapper	Exact root-owned predecessor wrapper распознаётся по pinned SHA-256 и всегда требует marker; phase-0 также отказывается работать с любыми другими installed bytes
41	RESOLVED IN CODE / LIVE GATE: сбой phase-0 после остановки units мог оставить MCP выключенным без proof-marker	Phase-0 сначала требует pinned live pre-state: service/timer active+enabled и cron bytes exact versioned source. До первой мутации durable marker получает preparing; после absence proofs — quiesced. Повторный prepare завершает операцию, rollback восстанавливает этот exact pre-state, пока deploy sentinel отсутствует
42	RESOLVED IN CODE / LIVE GATE: nonce уменьшал коллизию drill-ресурсов, но локальный флаг не доказывал remote ownership при cleanup	Все disposable containers, volumes и network получают exact run-token Docker label; cleanup проверяет label до удаления и fail-closed сохраняет любой foreign resource
43	RESOLVED IN CODE / LIVE GATE: существующий либо race-created volume мог быть смонтирован до поздней label-проверки cleanup	Restore block использует set -eu, preflight absence, получает network ID и сразу доказывает labels всех volumes/network до первого container; mounts используют --mount, который не auto-create отсутствующий volume; container labels проверяются сразу после start
44	RESOLVED IN CI / RETRY GATE: deploy run 29414580464 упал до deploy на трёх F-62 tests — MCP/Qdrant modules не были установлены, а shallow checkout не позволял attest historical predecessor wrapper	Deploy test job устанавливает exact rag-tools/requirements.txt, включает его в pip cache key и получает full Git history; safety-tests и pinned predecessor proof не ослабляются; закрыть только зелёным повторным run exact follow-up SHA
45	RESOLVED LIVE: повторный workflow мог снова остановиться до deploy	Run 29414892910 green; exact a59efaa activated, app/API/MCP/cron/systemd/sentinels и counts доказаны на S3
46	Deploy/recovery quarantine может пропустить daily cron без отдельного API-сбоя	С 06.08 первично gwptd-collection-quiet-check: при молчащем сборе full deploy проходит вне часов; окно 12:30–22:00 UTC (воскресенье после 14:30, окно monthly Amazon) — запасной путь. Отдельно действует ночной запрет 02:00–09:15 UTC, см. карту ограничений. Unsafe invocation не меняет checkout/state/cron
47	RESOLVED LIVE: WB paid storage имел фиксированный предел 30×10s, хотя успешная S3-задача уже длилась 21 минуту	S3 получил 180×10s; live run 2640 завершился success, 12 515/12 515, skipped/error 0, lease освобождён
48	RESOLVED LIVE: GA analytics/price/table дважды исчерпал 30s, хотя остальные 28/29 slices свежие	Legacy-compatible GET timeout 120s; optional failure сохраняется audit-row, но не poison'ит snapshot. Live run 2639: success, 29/29, GA kernel stocks 2079, prices 4144
49	Текущие 45 stale смешивают причинно разные события	Сохранять breakdown: cron quarantine (Ozon/YM/Lamoda), настоящий async timeout WB и optional timeout GA; закрывать каждый класс отдельным live proof
50	RESOLVED IN CODE / LIVE GATE: backup не имел exact MySQL inventory и мог доказать наличие dump, но не идентичность четырёх БД после restore	Реализованы deterministic schema/table/view identity, FTWRL-consistent exact row counts четырёх БД, validate и exact restore compare; закрыть новым backup+drill
51	RESOLVED IN CODE / LIVE GATE: drill завершался терминальным OK, но не оставлял durable receipt; host-lock release/cleanup order доказан не строго	Реализован порядок capture evidence → cleanup → strict host-lock release → atomic sibling receipt → full manifest/receipt verify → remove trap → OK; receipt вне immutable archive и содержит восстановленный index receipt
52	RESOLVED IN CODE / LIVE GATE: runbook называл архив зашифрованным, хотя age покрывает только secrets tar, а DB/MinIO/Qdrant/Git/images/runtime plaintext/compressed	Добавлены machine-readable encryption-scope.json и fail-closed classification manifest; ExFAT не считается зашифрованным. Закрыть реальным archive verify
53	Reindex state показывает только текущий файл и не даёт total progress (files_done/total)	После incident/backup gates добавить bounded progress fields без изменения atomic alias contract
54	GitHub actions всё ещё исполняются на deprecated Node 20 в старых major checkout/setup-python	Отдельно обновить до текущих major после зелёного collector recovery; не смешивать с freshness hotfix
55	RESOLVED LIVE: recovered submit 420 и временный poll failure оставляли sticky partial; submit loop спал после последней попытки, а внешний 429 умножал retry BaseCollector	Async runtime разделяет владельцев. Live ym.realization run 2641 восстановил реальный 420 одним retry и завершился success, 973/973, skipped/error 0, lease освобождён
56	RESOLVED LIVE: ym.competitors_position мог закончить все generate/poll/download попытки и остаться success 0, а 429 повторялся двумя вложенными циклами	Single-owner retry и fail-closed no-report. Quota-safe live run 2642: один usable rotated report, success, 60/60, skipped/error 0, lease освобождён
57	MySQL FTWRL timeout мог навсегда удержать host/codebase locks; между Qdrant exporter и DB backup существовал lock-handoff gap	Не получившийся holder TERM→bounded KILL; MySQL session lock_wait_timeout=30; один exclusive codebase holder непрерывно покрывает Qdrant и все DB/object streams, exporter доказывает внешний exclusive lock
58	Archive verifier зависел от caller Git cwd, а ошибка после atomic rename receipt могла оставить видимый status=ok	Bundle проверяется в disposable bare repo из любого cwd; post-rename durability failure удаляет visible receipt; финализатор заново проверяет каждый SHA256SUMS entry и полный file-set
59	Stateful ym.competitors_position оставлял BaseCollector daily cache включённым: первый 420 либо PROCESSING мог переигрываться из файла во всех workflow attempts	Для этого report-плагина cache принудительно отключён, как для http.async_task; regression test фиксирует live-state transport
60	ExFAT noowners представляет приватный receipt как mode 0700, тогда как writer требовал буквально 0600 и удалял доказательство после успешного drill	Writer и verifier используют один filesystem-aware контракт: owner-only 0600/0700 допустим, любые group/other bits запрещены; regression test фиксирует target-disk семантику
61	lamoda.status_dates имел SLA буквально 24h при daily cadence и observed runtime до 3272s: следующий штатный run мог честно обновлять данные, когда предыдущий success уже старше 24h	ProductSpec использует общий daily SLA 27h; глобальная freshness-семантика не ослаблена: незавершённый run не считается свежими данными, а running >2h остаётся отдельным stuck-alert
62	Cron quarantine/restore не ведёт durable ledger пропущенных slots: восстановленный crontab не переигрывает уже прошедшие 05:00–08:00/GA/monitor окна	Создать machine-readable schedule registry, атомарный collector_schedule_slot ledger и persistent systemd reconciler; slot закрывается только exact expected endpoint-set со success после scheduled_at, иначе bounded retry через штатные locks
63	Scheduled marketplace run при занятом scope-lock получает 75 с default wait=0 и теряется; live --all не получал ни одного marketplace-lock	Live --all уже fail-closed запрещён до DB/pointer access (--all --dry-run сохранён); остаток: reconciler сохраняет slot pending после 75/8, а scheduled claim не дублирует уже покрытый slot
64	Full deploy разрешён до 22:00 UTC, но после cron quarantine inner deploy не имеет absolute deadline и теоретически может пересечь следующий 02:00 slot	До первой мутации вычислять durable absolute deadline; inner deploy обязан завершиться до него либо выполнить точный rollback/cron restore; fault test с зависшим inner process доказывает отсутствие потерянного cron
65	S2 lamoda.status_dates быстрее только потому, что обрезает список на 200/449 страниц и ошибочно пишет success; полный S3 дополнительно ждал 1.5s после каждого медленного ответа	Полноту 449 страниц сохранить; общий transport считает rate-limit между стартами через monotonic clock, включая retry/binary download. Это сохраняет 40 starts/min и сокращает чистый Lamoda run примерно с 55 до 43 минут; закрыть live canary
66	RESOLVED IN CODE / LIVE GATE: первый off-host backup после исправлений падал до dump: generic stdout.strip() удалял финальный TAB пустого CREATE_OPTIONS и превращал последний валидный metadata-row MySQL из пяти полей в четыре	MySQL batch transport удаляет только CR/LF, сохраняя field delimiters. Regression test и read-only live inventory подтверждают exact 162 объекта: intake 104, kernel 22+3 views, monitoring 10, next_app 23; закрыть повторным backup+drill
67	RESOLVED IN CODE / LIVE GATE: второй off-host backup собрал все streams и прошёл SHA256, но verifier ожидал только classic Docker Config=<digest>.json; Docker 29 сохраняет тот же exact config digest как blobs/sha256/<digest>	Verifier принимает только два канонических имени одного ожидаемого image-config digest и по-прежнему требует exact archive tag, шесть уникальных images и совпадение Qdrant image ID; закрыть новым exact archive verify+drill
68	RESOLVED LIVE HOTFIX / DEPLOY GATE: Qdrant 1.17.0 возвращал recover_snapshot(wait=true) при ещё не применённых 45 WAL operations; immediate count дважды видел transient candidate 13203 вместо source 13201 и корректно оставлял весь S3 в quarantine	Worker теперь ждёт bounded recovery convergence: source остаётся immutable, update_queue.length=0 и exact candidate count равен source в двух последовательных наблюдениях. Доказанный cleanup.deleted=true снимает только собственную завершённую candidate-транзакцию без ложного tombstone. Проверенный hotfix 376e5c3… штатно восстановил exact 13201/13201, marker/receipt=4e57d41, app/API/MCP/cron; закрыть standard deploy этого commit и затем отдельно поднять pinned Qdrant до 1.17.1 во всех backup/drill contracts

5. Неподвижные правила исполнения

1. S2 — production-канон до G11, owner approval и успешного Wave 7.
2. Разработка идёт local/worktree → S3. Запись и deploy на S2 — только по явному OK.
3. Comparator read-only: он не запускает collectors и не меняет Canon.
4. Первичные факты исправляются раньше производных метрик.
5. Нельзя получать green ослаблением tolerance, ignored fields или scope.
6. incomparable, stale, неполный snapshot и process exit 0 без доказательства результата не являются green.
7. После изменения расписания, окна, дедупликации или formula hash streak начинается заново.
8. Непроверенные показатели не маскируются под 0 и не публикуются как достоверные.
9. Канонический data_status остаётся ok | no_data | stale | error. Parity хранится отдельно как verified | accepted_difference | unverified | blocked.
10. Legacy PHP и старые collectors не развиваются; по текущей директиве владельца S2 не получает даже минимальных эксплуатационных изменений — только read-only evidence. Изменить это правило может лишь новая явная директива владельца.
11. Перед значимым рефакторингом создаётся стабильный Git/runtime checkpoint.
12. Ни одна необратимая операция не выполняется без backup, restore/rollback проверки и отдельного полномочия.

6. Приоритеты и потоки работ

P0 — канон, baseline и безопасность действующего контура

W0. Координация и доказательства

Статус: BASELINE COMPLETE / CONTINUOUS REFRESH. Исторический W0 snapshot, parity-register, accepted-difference ledger, checkpoints и single-writer режим уже созданы; повторно планировать их создание не нужно. Открыт только регулярный read-only refresh после exact commit/deploy и каждого закрытого суточного окна:

• обновлять snapshot S2/S3 без ручного запуска collectors;
• фиксировать exact SHA, schedule, active pointers, последние runs, freshness, lease, hard invariants и полный parity report;
• сохранять новые checkpoints перед значимым рефакторингом;
• поддерживать parity-register и accepted-difference ledger по evidence;
• единственный writer/integrator назначен; owner production-cutover — Anton.

Готово, когда: любой показатель baseline воспроизводится из артефакта с SHA, timestamp и командой read-only проверки.

W1. Минимальное укрепление S2 — FROZEN / OUT OF SCOPE

Не исполнять в рамках текущей цели. По прямой директиве владельца S2 остаётся неизменяемым production-каноном и rollback-контуром. Допустимы только read-only Git/cron/log/DB evidence, не меняющие его состояние. Возврат любого пункта ниже в работу потребует отдельного изменения цели владельцем, а не обычного инженерного решения агента.

1. Перевести Amazon S2 в согласованный малый режим.
2. Одновременно привести freshness к новому schedule.
3. Убрать credentials из tracked wrapper и ротировать их; удаление строки без ротации не закрывает задачу.
4. Восстановить рабочий DB lease.
5. Расширить freshness до полного active schedule.
6. Исправить permission errors архива Ozon XLSX.

Список сохранён только как исторический операционный backlog и не является разрешением на действие. Текущая программа достигает превосходства S3 без изменений S2; ни один из этих пунктов не блокирует безопасную S3-разработку.

P1 — parity S3 и технический MVP матрицы

W2. Первичные данные S3

Порядок разбора: Orders → Stocks → Prices → regression Returns.

Для каждого набора проверяются одинаковые window/timezone/scope/grain, counts, sums, missing/extra/duplicate keys, max delta и source-to-target lineage.

Schema-3 остаётся hard-disabled до dedicated SELECT-only Canon principal и непрерывной legacy/build attestation. Schema-2 продолжает работать; его green не начинает G11 без schema-3 proof.

Готово, когда: нет необъяснённых расхождений, а статус — green либо утверждённый accepted_difference.

W3. Финансовые и аналитические факты

Порядок: Finance → Analytics → Storage.

Готово, когда: можно доказать происхождение каждой денежной метрики и отличить неполноту источника от ошибки parsing/dedup/ETL.

W4. Производные факты

Только после W2/W3 пересчитываются и сравниваются Turnover и Rating. Нельзя независимо подгонять производные формулы под S2. Семантика net realized и другие DNR остаются каноном даже когда корректная новая формула намеренно отличается от загрязнённого legacy.

W5. S3 runtime readiness

Статус: CODE BASELINE READY / LIVE GATES OPEN. Уже реализованы fail-closed ProductSpec, exact pointer-set, immutable bundle, DB lease, host/codebase locks и полный freshness monitor; эти code-задачи сняты из очереди. Осталось доказать на exact deployed commit, а не реализовать повторно:

• полный freshness после естественных active-schedule циклов;
• отсутствие duplicate/concurrent runs при реально работающих DB lease и locks;
• чистые daily/weekly/monthly циклы и измеренный SLA/API-budget;
• успешные off-host backup, archive-only restore drill и rollback rehearsal;
• алерт на падение самого comparator/monitoring и наблюдаемый natural recovery.

W5.1. Architecture ratchet после incident recovery

Статус: READY — DESIGN COMPLETE. F-60 recovery и штатный redeploy завершены; реализация gate начинается после F-62 live activation и backup/drill proof.

F-60 сохранён как завершённый воспроизводимый checkpoint, а не активный recovery поток. После деплоя exact F-62 SHA и переиндексации MCP запускается:

python3 scripts/architecture/measure_next_change_surface.py --current HEAD --check

Сейчас --check лишь строит метрику и проверяет непустой контракт; regression budget он не enforce'ит. Безопасный baseline разделяется: product берётся из af70917, а assurance/operations — из code-checkpoint f23be76; между ними все недокументные метрики должны совпасть. Существующий workflow next-change-surface.yml нужно усилить до ratchet-gate:

Текущий воспроизводимый baseline f7d08cd измеряет только четыре зоны, а не всю платформу: Collectors 8 864 LOC / 2.1155%, Data API 14 812 / 9.3919%, Filament 22 897 / 25.6189%, Kernel 9 336 / 5.2968%; их сумма 55 909 LOC не включает deploy/ops и часть monitoring/parity dependencies. Цель G10 25 466 LOC остаётся направлением сокращения product surface, но не оправдывает удаление rollback, parity или evidence-кода.

1. legacy collector files = 0; collector duplication имеет hard ceiling < 3% и одновременно не растёт выше baseline 2.1155%.
2. Исправить классификатор surface: включить реально вызываемые spec_runtime/comparison_*, MetricSpec, deploy/ops и monitoring/parity, а не называть неполную сумму «всей активной кодовой базой»; выводить отдельно product core, parity/evidence assurance и deploy/operations.
3. До исправления classifier действуют ceilings: Data API 9.3919%, Filament 25.6189%, Kernel 5.2968%; LOC каждой зоны не растёт без versioned allowlist, owner/причины и срока удаления. После каждого реального улучшения baseline только понижается.
4. Новый marketplace добавляется ProductSpec/plugin; стандартный read-only UI — через общие Page/Grid/ReportSpec renderers, а не копированием collector/page. Сложный workflow может иметь bespoke implementation только по versioned architecture exception.
5. Новый либо расширяемый executable-файл свыше 500 строк требует decomposition note либо временного allowlist с owner и сроком удаления. Tests, docs, migrations и generated artifacts этим механическим порогом не режутся.
6. После стабилизации разложить deploy-s3-next.sh, parity/evidence export и build_fact_rating.py по отдельным тестируемым доменам; frontend и Data API сокращать общими render/query primitives.
7. Manifest получает architecture_contract с immutable full SHA, строгой классификацией exact path → longest prefix, protected F-60 paths и versioned exceptions (owner, reason, absolute ceiling, remove_by).
8. Ratchet одновременно сравнивает frozen checkpoint и previous SHA: product и operations не отрастают после улучшения; assurance может расти тестами, но не может терять protected contracts. Unclassified/ambiguous/ref drift даёт exit 2, regression — 1, green — 0.
9. Новый или увеличенный product/operations executable >500 SLOC блокируется; неизменённые checkpoint-файлы grandfathered, tests/migrations/generated/docs этим механическим лимитом не режутся.

Gate должен быть монотонным ratchet от подтверждённого checkpoint, а не массовым rewrite во время production incident.

W5.2. MCP reindex atomicity and liveness — F-62

Исторический baseline до F-62 имел общий codebase lock, но incremental reindex делал delete/upsert через активный alias, а entrypoint'ы имели разные правила запуска. Реализованный целевой контракт и ещё открытые live-gates:

1. timer, MCP reindex(), sync_and_index и weekly compatibility path вызывают один supervisor и никогда не делают git pull/checkout mutation;
2. incremental копирует active physical collection в неактивный candidate, применяет prune/upsert и exact sanity checks только там;
3. alias переключается атомарно, marker двигается только после swap, прежняя physical collection остаётся доступной для rollback;
4. timeout либо failure удаляет только доказанно неактивный candidate; active alias и последний подтверждённый marker не ухудшаются;
5. hard deadline 40m, heartbeat 60s, TERM grace 30s, timeout rc 124; systemd TimeoutStartSec=2700, KillMode=control-group;
6. timer использует OnUnitInactiveSec=15min, чтобы длинный job не вызывал немедленный повтор;
7. supervisor удерживает общий FD lock до завершения worker и cleanup; heartbeat не наследует FD; timeout/failure создают отдельный alert;
8. legacy destructive indexer.py --recreate и прямой mutable weekly path удаляются из исполняемой поверхности либо становятся fail-closed wrappers единого supervisor.
9. staging различает receipt bootstrap и stale commit; service-start контракт допускает только marker == HEAD, exact receipt и distinct rollback generation;
10. старый MCP/timer/worker останавливается и проверяется до checkout mutation;
11. post-control-plane activation имеет durable pending/failure/success evidence, same-SHA resume и отдельный workflow proof exact tested SHA;
12. sentinel bridge переживает rollback и retry/reboot, а unit-state MCP не восстанавливается journal до удаления sentinel;
13. Qdrant exporter удаляет только snapshot доказанного собственного поколения;
14. backup/drill доказывают stopped MinIO mount+inventory, exact PostgreSQL database/schema/table/row inventory и exact running OCI image IDs;
15. первый rollout с установленного f2c606c predecessor wrapper разрешён только после отдельного phase-0 на старом checkout и durable proof-marker;
16. systemd generator атомарно накрывает condition все MCP writer units до установки обычных drop-ins и тем самым закрывает reboot gap;
17. general same-SHA finalizer требует exact tested SHA, exact installed wrapper и durable activation evidence, не повторяя полный deploy;
18. host/codebase lock holders имеют watchdogs, которые не наследуют FIFO writer FD, переживают исчезновение ps под errexit/pipefail и прерывают активные foreground streams при неожиданной смерти holder;
19. MinIO stop-window имеет root-owned digest marker, временный restart=always и постоянный recovery timer для crash/SIGKILL/reboot;
20. backup содержит exact-SHA self-contained recovery-tools, а drill создаёт только nonce-unique ресурсы и удаляет их лишь после доказанного ownership.

Code-checkpoint 2026-07-15: реализованы единый supervisor, proven inherited shared lock OFD, COW snapshot/recover, exact count/vector/payload gates, lost-response alias read-back, strict marker/receipt reconciliation, mandatory no-change receipt bootstrap, durable pending GC, backup snapshot receipt и late-candidate tombstone. COW mutation выполняется только после commit журнала, а MCP/timer запускаются после durable удаления outer deploy sentinel; старый wrapper первого rollout покрыт monotonic path+retry transition. Durable activation receipt и same-SHA resume закрывают сбой между journal commit и service start. Новый wrapper гасит legacy writers до checkout; единственный переход со старого f2c606c predecessor закрывается отдельным phase-0, выполняемым до push на ещё старом checkout. Целевые tests доказывают timeout 124 с TERM→KILL и real cleanup child, внешний TERM, child-75 invariant, post-swap marker failure/recovery, COW source immutability, corrupted stored vectors/payload, third-alias protection, snapshot crash recovery, rejection unlocked/impostor FD и сохранение внешнего FD9 после borrowed bootstrap.

Готово, когда: уже выполненные local commit, push и контролируемый prepare → rollback → prepare доказали exact phase-0 state diff и recovery; повторный CI и штатный deploy проходят one-time legacy barrier; post-commit bootstrap создаёт согласованные alias/marker/receipt/rollback; первый естественный timer-run подтверждает периодический путь; повторный trigger не starvation-ит deploy/recovery; live proof подтверждает atomic generator и отсутствие orphan writer/lock; stopped и already-running MinIO recovery проходят; отдельный disposable collision test доказывает отказ cleanup удалять foreign-labeled resource; затем off-host backup и запуск только архивного orchestrator на label-owned nonce-unique ресурсах подтверждают exact Qdrant count, vector/schema, PostgreSQL/MinIO inventories, Git marker, exact OCI images и pinned runtime. До этого F-62 остаётся CODE, не LIVE.

W5.3. Freshness incident — F-64

Alert 2026-07-15 03:45 UTC имел две разные причины:

• goldapple.snapshot run 2565 был partial из-за двух ReadTimeout на /analytics/price/table; естественные runs 2569 в 04:20 и 2592 в 08:20 завершились success;
• 15 YM endpoint'ов — не 15 independent failures. Daily batch 14 июля успел выполнить analytics/boost, затем quota-heavy competitors получил HTTP 420 и был остановлен; хвост registry не стартовал. Цикл 15 июля 07:00 был пропущен, пока cron находился в deploy quarantine.

По директиве владельца 15 июля выполнен контролируемый catch-up S3 под штатными locks; S2 оставался read-only. Ozon восстановлен 18/18, Lamoda 7/7. Exact deploy edf2f5c прошёл CI, app/API/MCP/cron activation. После него четыре точечных canary закрыли оставшиеся причины: GA run 2639 — 29/29, WB run 2640 — 12 515/12 515, YM realization run 2641 — 973/973 после восстановленного HTTP 420, YM competitors run 2642 — 60/60 из одного usable rotated report. Все четыре имеют status=success, skipped/error 0, exact runtime commit и освобождённые leases. Notification-free проверка в 2026-07-15 14:56 UTC вернула freshness OK — все endpoints свежие.

Прямой incident закрыт. F-64 остаётся под естественным суточным наблюдением до следующего полного scheduled exact-set: это проверяет не только исправленные endpoint'ы, но и отсутствие нового пропуска cron/lock без ручного catch-up.

W5.4. Durable schedule reconciliation — F-66

Исторический draft, superseded для исполнения. Этот раздел сохраняет исходную проблему и целевые acceptance criteria, но его формулировки про «две InnoDB-таблицы в gwptd_intake» и закрытие slot-а по любому позднему success больше не являются схемой реализации. Канонический P0–P7 статус и protocol принадлежат S2-REFERENCE-S3-COLLECTOR-RECOVERY-PLAN.md; текущий P3-B использует шесть связанных таблиц в gwptd_monitoring, fresh activation generation и pre-seal binding source collection_run. Детали границы: P3-SCHEDULE-SLOT-LEDGER-CONTRACT.md.

Простой restore crontab не переигрывает слоты, прошедшие во время quarantine, а scope-lock code 75 сейчас также не имеет durable retry. Целевой контракт:

1. schedules/s3-next.yaml становится единственным registry всех 25 текущих cron jobs; committed crontab генерируется и CI проверяет byte-for-byte.
2. Collector jobs обязаны покрывать exact 75 freshness-enabled ProductSpec; exact unscheduled set остаётся amazon.buybox, amazon.sales_ranks, amazon.weekly_reports, wb.stocks.
3. Две InnoDB-таблицы в gwptd_intake хранят job watermark и UTC slot ledger. Первый rollout начинает watermark со времени deploy, а не переигрывает исторические недели.
4. Slot закрывается только если каждый expected endpoint имеет новый collection_run.status=success после scheduled_at; run_id/spec digest/ runtime commit сохраняются как completion evidence.
5. Уже выполненный ручной или естественный exact-set закрывает slot без нового API-вызова; repair запускает только missing endpoints. Exit 75/8 оставляет slot pending с bounded retry, claim token/lease не позволяют старому worker завершить перехваченный slot.
6. Persistent systemd timer и generated cron вызывают один reconciler; MySQL conditional claim гарантирует одного исполнителя. Generic ETL/monitor jobs имеют явные accepted exit codes и документированную at-least-once семантику.
7. Rollout строго двухфазный: commit A устанавливает deadline-aware outer deploy wrapper и fault tests; только после его live proof commit B включает registry/tables/reconciler/timer/generated cron.
8. Absolute restore deadline — 01:30 UTC: inner deploy получает TERM/KILL до следующего 02:00 slot, а существующий failure-atomic handler обязан доказать exact checkout/crontab rollback либо сохранить fail-closed quarantine.

F-66 закрывается только после live proof: 25 job rows, exact cron digest, timer active/enabled, отсутствие expired leases и один полный естественный цикл без потерянных/дублированных slots. S2 остаётся read-only.

W6. Matrix Backend

1. Зафиксировать business rules, Formula/MetricSpec и golden cases.
2. Вынести единый текущий расчёт себестоимости: (price_buy_usd + 3) * 1.47 * current_cbr_usd_rub.
3. Переключить новый shipment-контур на общий helper с доказанной числовой эквивалентностью. Исторический kernel-rating и legacy PHP не менять.
4. Создать тонкий GET /reports/matrix: бренд, период, marketplace, стабильная сортировка/пагинация, totals и явная provenance каждой метрики.
5. Добавить отдельный verification_status для полей, зависящих от parity-gates.

W7. Matrix UI /new

Начинается после заморозки первого API-контракта.

• использовать существующие UniversalReportPage, PageSpec/GridSpec и ui_preferences;
• не создавать matrix_custom_views;
• не писать отдельный большой Blade/JS-grid для MVP;
• сначала выпустить staging-пресет «Обзор»;
• затем добавить пять пресетов, ручной assortment_model_status, brand-level enforcement, экспорт и общие GridSpec-renderers;
• pinned columns, фото/hover, sparklines, row rules и density реализовывать как переиспользуемые возможности общей платформы.

P2 — product completeness и production promotion

W8. Новые процессы после матрицы

• карточка модели именно в /new;
• рекомендации к перезаказу;
• lost sales с различением OOS и отсутствующего snapshot;
• контроль РРЦ и лента «Требует внимания»;
• дашборд бренда;
• supplier metadata, возраст стока из 1С, сезонность и прогноз 18 месяцев;
• promo effectiveness, price elasticity, sell-out, клиенты/территории, silhouette rollup и интеграция ХИТ — только после появления источников.

W9. Документация и интеграция

• обновлять главный индекс, business canon, machine rules и golden cases;
• поддерживать разделы «сделано / осталось / следующий шаг»;
• после каждого merge фиксировать SHA, тесты и evidence;
• не редактировать вручную генерируемый DOCUMENTATION-CATALOG.md;
• сводить ветки только через назначенного интегратора.

W10. Dual-run, cutover и стабилизация

1. Три последовательных сопоставимых закрытых окна используются как ранний инженерный gate, но не заменяют G11.
2. После полного parity начинается канонический 14-дневный green streak.
3. До cutover выполняется rollback rehearsal и фиксируется RTO/RPO.
4. Владелец отдельно даёт OK на Wave 7.
5. После переключения идёт усиленное наблюдение; S2 сохраняется готовым к rollback.
6. Вывод S2 из роли канона — отдельное решение после стабилизации.

7. Зависимости ассортиментной матрицы от parity

Набор	Что зависит	Gate
Orders	продажи, ABC, sell-through, покрытие, lost sales	рабочий MVP
Stocks	остатки, OOS, давление стока, покрытие, GMROI	рабочий MVP
Prices	маржа, GMROI, РРЦ и переоценка	финансовый MVP
Returns	возвраты; процент возвратов также требует Orders	рабочий MVP
Turnover	оборачиваемость, перезаказ, overstock	полный §5.3
Rating	рейтинг и health score	полный §5.3
Finance	комиссии, прибыль и полная маржа	полный финансовый вид
Analytics	агрегированные KPI	полный §5.3
Storage	contribution margin с хранением	полный финансовый вид

Matrix Gate A — технический preview

Разрешены API-контракт, PageSpec/GridSpec, права, ручные статусы и интерфейс. Непроверенные значения скрыты либо явно имеют verification_status=unverified.

Matrix Gate B — рабочий MVP

Обязательны подтверждённые Orders, Stocks, используемый источник закупочных и продажных цен, Returns, справочник моделей/брендов, курс и helper себестоимости.

Matrix Gate C — полный §5.3

Дополнительно подтверждены Turnover, Rating, Finance, Analytics, Storage. Только после этого становятся достоверными GMROI, полная маржа, оборачиваемость и комплексные рекомендации.

8. Методика parity

Каждый ComparisonSpec обязан задавать:

• закрытое source window и timezone;
• marketplace/account/scope;
• grain и natural/semantic key;
• фильтры и правила дедупликации;
• count, sums, missing/extra/duplicate keys и max delta;
• допустимые отклонения по конкретному полю;
• версии collector/spec/ETL/formula;
• статус green | accepted_difference | blocked | incomparable;
• путь к воспроизводимому отчёту и исходным digest/artifact.

accepted_difference может утвердить только владелец после доказательства причины. Автоматический comparator не принимает бизнес-решение самостоятельно.

9. Разделение между агентскими сессиями

Активный режим от 2026-07-15: единственный writer/integrator — текущая сессия на next/spec-platform. Все остальные агенты выполняют только read-only review/измерения. Подготовленные worktree/ветки не merge'ятся и не push'ятся самостоятельно. Таблица ниже остаётся целевой моделью для будущих независимых волн только после новой директивы владельца.

Сессия	Ветка/worktree	Владеет	Не трогает
Coordinator / Integrator	next/spec-platform	все текущие code/docs/schema изменения, план, gates, commit/push, разрешённые S3 recovery/deploy и итоговая приёмка	S2, ручные collector runs и production cutover
S2 Operations — DISABLED	отдельная ветка от master только после новой owner-директивы	сейчас только read-only evidence; любые будущие Amazon/secrets/lease/freshness/Ozon изменения требуют нового явного OK	любые записи/деплой S2 при текущей директиве
S3 Parity	next/parity-*	ComparisonSpec, comparator, Orders/Stocks/Prices, затем derived fixes	UI и бизнес-правила Matrix
Matrix Backend	next/matrix-backend-*	себестоимость, /reports/matrix, golden cases	schedules и collector runtime
Matrix UI	next/matrix-ui-*	PageSpec/GridSpec, /new, shared renderers	Data API до фиксации контракта
Docs / Evidence	next/docs-*	индексы, parity-register, evidence и handoff	runtime и production deploy

Модель с несколькими writers сейчас отключена. Вернуться к ней можно только по новой директиве владельца; тогда одновременно рекомендуется не более трёх пишущих сессий: S3 Parity, Matrix Backend и один независимый поток. Matrix UI стартует после freeze контракта.

9.1. Правила против конфликтов

Ниже описан будущий multi-writer режим. Пока действует текущая owner-директива, единственная рабочая ветка — next/spec-platform, остальные сессии только рецензируют и не создают commit/push.

1. Отдельная branch/worktree на каждую пишущую сессию.
2. Один владелец DB migrations и один интегратор.
3. Один владелец изменяющих действий на каждом сервере.
4. Никаких одновременных ручных collector runs.
5. Matrix Backend/UI не выполняют production deploy.
6. S2 hotfix не переносится целиком в S3; общие решения портируются отдельным review.
7. API schema замораживается до начала UI; изменение schema требует уведомить UI-сессию.
8. Короткие тематические коммиты, tests/evidence до handoff.
9. Merge-order: primary facts → derived facts → Matrix Backend → Matrix UI → docs/status.
10. При конфликте runtime-факта и документа побеждает повторная read-only проверка; документ затем исправляется.

9.2. Обязательный handoff сессии

Session / owner:
Branch + worktree:
Baseline SHA:
Working tree: clean | dirty (exact paths):
Checkpoint commit:
Scope and files owned:
Changes made:
Tests and commands:
Evidence / report paths:
Data and product gates affected:
Known risks / blockers:
Next safe action:
Server mutations actually performed: none | exact approved action

10. Rollback и условия остановки

Триггеры rollback/stop:

• freshness/SLO regression;
• unexpected partial, duplicate or missing scheduled run;
• parity regression либо изменение formula/spec digest во время streak;
• schema/bundle/pointer drift;
• ошибочные числа Matrix, потеря access enforcement или export leak;
• невозможность доказать источник изменения;
• отсутствие проверенного backup/rollback перед production mutation.

Точный production rollback выполняется по Wave 7. Право разрешить cutover, accepted difference, rotation secrets и изменение production S2 принадлежит владельцу.

11. Протокол непрерывной работы

1. Единственный Coordinator/Integrator изменяет код, Git и S3; остальные агентские сессии выполняют только read-only аудит и передают findings. Coordinator поддерживает очередь атомарных задач со статусами pending | in_progress | blocked | verified | accepted.
2. После завершения задачи агент берёт следующую безопасную незаблокированную задачу, пока Definition of Done не выполнен.
3. Если один поток заблокирован внешним источником, работа продолжается по независимым потокам; blocker фиксируется с owner и требуемым входом.
4. Задача не получает verified без теста или доказательства.
5. Перед существенным merge создаётся checkpoint и обновляется handoff.
6. Агент обязан остановиться и запросить решение только для нового полномочия, секрета, необратимого production-действия, изменения business canon, принятия accepted_difference, cutover или rollback.
7. Непрерывность не расширяет полномочия: ожидание календарного gate не разрешает самовольный production-mutating шаг.
8. Цель нельзя завершить после аудита, написания плана, локальных тестов или staging-MVP. Завершение — только по Definition of Done этого документа.

12. Готовая формулировка непрерывной цели

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

Создай непрерывную цель и управляй агентскими сессиями до её
фактического выполнения.

Цель: довести GWPTD S3 Next до состояния, в котором он полностью выполняет все
необходимые функции, расписания, сборы, ETL, отчёты и бизнес-процессы действующего
S2 Canon, но превосходит S2 по корректности, надёжности, наблюдаемости, скорости,
расходу API, сопровождаемости и восстановлению; реализовать новые spec-driven
процессы и ассортиментную матрицу в обязательном интерфейсе /new; пройти
доказанный production cutover и сделать S3 новым рабочим каноном.

Канонический исполняемый план и Definition of Done:
docs/remediation/S3-NEXT-PRODUCTION-READINESS-PLAN.md.
Архитектурные границы:
docs/remediation/S2-CANON-S3-NEXT-CLEANROOM-PLAN.md.

Не останавливайся на аудите, диагностике, рекомендациях, первом исправлении,
локальных тестах или staging-MVP. Назначь ровно одну пишущую сессию
Coordinator/Integrator; остальные агенты только читают и проверяют, не меняя
файлы, Git и серверы. Реализуй и проверяй изменения, собирай evidence и продолжай все безопасные
незаблокированные потоки до полного Definition of Done. Если поток заблокирован,
зафиксируй причину и продолжай независимые задачи.

S2 остаётся production-каноном и rollback-путём до прохождения всех parity-gates.
Не изменяй S2, production cron, secrets, данные или трафик и не выполняй cutover,
rollback либо другое необратимое действие без моего отдельного явного разрешения.
Не ослабляй tolerances ради green. Производные показатели исправляй только после
первичных фактов. Непроверенные данные не выдавай пользователям как достоверные.

Не отмечай цель завершённой, пока не выполнены все условия Definition of Done,
включая 14 последовательных зелёных дней, отдельное разрешение владельца на
cutover, успешное переключение, проверенный rollback и подтверждённую работу
сборов, ETL, /new, матрицы, прав и мониторинга на новом production-контуре.

13. Журнал изменений плана

Дата	Версия	Изменение
2026-07-15	2.6	Добавлен finding 68: доказана гонка Qdrant 1.17.0 snapshot/WAL recovery (13203→13201), реализован bounded update-queue settle gate и зафиксировано штатное live recovery exact SHA без ручного удаления sentinel/receipt
2026-07-15	2.5	Исправлен фактический breakdown 45 stale и зафиксирован Ozon 18/18, YM false-partial и Lamoda progress. Findings 50–52 переведены в code/live gates; добавлены 55–65: async retry/cache, exact backup/drill, корректный daily SLA и full-data pacing Lamoda, а также P1-gates durable schedule replay, scope-lock retry и absolute deploy deadline
2026-07-15	2.3	Зафиксирован безопасный CI-only отказ run 29414580464 до deploy и фактический phase-0 quiesced state S3. Добавлен finding 44: deploy CI теперь устанавливает pinned MCP/Qdrant requirements и получает full Git history для exact predecessor attestation; выполненные phase-0 шаги сняты из очереди
2026-07-15	2.2	Сняты повторные W0/W5 code-задачи и оставлены точные live-gates. F-62 дополнен обязательным pre-push phase-0 для exact legacy wrapper, durable prepare/quiesce/rollback state, single-call atomic systemd generator/barrier, general same-SHA finalizer, fail-closed lock watchdogs, crash-durable MinIO recovery, self-contained archive-only recovery kit и preflight-proven label-owned drill resources; добавлены findings 25–43
2026-07-15	2.1	Выполненные F-60 задачи окончательно сняты из очереди; F-62 усилен strict marker=HEAD, pre-checkout legacy-writer barrier, durable activation/same-SHA resume и monotonic post-sentinel bridge. Добавлены и закрыты в code находки foreign Qdrant snapshot, live MinIO copy, слабый PostgreSQL drill, mutable OCI tags и hard-coded MinIO mount; live backup/drill gate остаётся открыт
2026-07-15	2.0	F-62 дополнен обязательным receipt bootstrap, proven borrowed FD9, post-journal COW и post-sentinel systemd transition; backup/drill сериализованы с deploy, clean-host restore создаёт новый truthful receipt, PostgreSQL restore исключает bootstrap role/database collision. Новые P0 сняты в code, live-gate остаётся открыт
2026-07-15	1.9	F-62 переведён из design в code/live-gate: единый COW supervisor, crash-safe alias/marker/receipt, durable GC/snapshot/candidate recovery, behavioral fault tests и полный Qdrant/Git/venv backup+restore contract. Добавлены отдельные follow-up для decomposition worker и transport Host allowlist
2026-07-15	1.8	F-60 закрыт успешным deploy f2c606c / run 29402638900 и независимым Git/runtime/HTTP/DB/cron proof. Завершённые recovery/schema fixes сняты из активной очереди; F-62 расширен до atomic COW supervisor, добавлен causal freshness gate F-64 и запрещаемые legacy MCP mutation paths
2026-07-15	1.7	Третий deploy 29400237198 безопасно откатился на schema-3 contract gate; доказано live 43/43, найдена shell-quoting ошибка в трёх enum metadata checks и подготовлены точные HEX-контракты с regression tests
2026-07-15	1.6	Зафиксирован второй fail-closed deploy 29397100051, точные причины MySQL contract/rollback SQL и успешный no-DML recovery af70917→ca38823 через profile v2; выполненное снято из активной очереди. Добавлены F-62 reindex lock budget, F-63 ETL-generation proof gaps и полный дизайн F-61 product/assurance/operations ratchet
2026-07-15	1.5	Recovery/deploy patch и единый test/docs checkpoint зафиксированы в f23be76; локально завершённые задачи переведены из PATCH в CODE, активными оставлены только root recovery, push/redeploy и live evidence
2026-07-15	1.4	Выполненное снято из активной очереди, а остаток превращён в явные live-gates. Добавлены F-61, точный неполный architecture baseline/ratchet, Git metadata trust boundary recovery и безопасный порядок local commit → recovery → push → standard deploy
2026-07-15	1.3	Отмечен executable checkpoint и единственный writer; владелец разрешил commit/push и S3 recovery/deploy/DB migration при неизменяемом S2. Добавлены pinned external recovery bundle, independently held digests, ca38823 one-shot bridge, SHA-candidate image build, DB boundary proof и post-incident architecture ratchet/decomposition
2026-07-15	1.2	Зафиксирован fail-closed incident F-60: historical schema-2 collation, generic journal restore defect и безопасная изоляция runtime; добавлен exact no-DML preimage recovery contract. Live-gate остаётся открытым до отдельного owner-разрешения, recovery и успешного redeploy
2026-07-15	1.1	Добавлены fail-closed checkout/control-plane/image deploy transaction, exact tested-SHA и атомарный wrapper bootstrap; schema-2 final contract и schema-3 hard-disable; исторический rating override audit; двухстадийный YM после freshness-инцидента. Runtime-gates остаются открыты до deploy и наблюдаемого scheduled evidence
2026-07-14	1.0	Создан единый execution-план: parity 1/9, укрепление S2, Matrix gates, разделение сессий, непрерывная цель и DoD