textmachine/platform/BACKLOG.md

Бэклог платформы (зонный)

Ведёт зона platform/ (решение владельца 02.08, D39.84: фронт и платформа держат СВОИ бэклоги; единый бэклог docs/PROGRESS.md остаётся трекером движка/полигона/доков и фронт/платформа-строк не принимает). Нормы те же: ID стабилен навсегда, каждая петля получает диспозицию. Запросы к ДВИЖКУ сюда не пишутся — они заходят строками единого бэклога через оркестратора (пример: строки 99–102). Засеян оркестратором при лендинге D39.84 — дальше правит платформа-сессия.

Диспозиции после P1 (05.08) — в журнале зоны, раздел «Диспозиции бэклога зоны» (docs/platform-PROGRESS.md). Коротко: П-6 и П-8 ЗАКРЫТЫ, П-7 закрыт по схеме и операциям (постановка холда воркером — часть П-1), П-4 отменён и поглощён П-7, П-5 переопределён под кредитную модель и ждёт правки спеки, П-1 продолжена, П-2/П-3 не трогали. Дублировать их здесь не стали — у строки один источник истины.

ID	Хвост	Вес	Источник
П-1	HTTP/SSE-слой и сервисная обвязка (экс-строка 96 единого бэклога): read-API поверх готовых OpenReadOnly-путей движка; SSE-события ПУШИТ воркер, фронт read-model не опрашивает (каждый read-вызов движка — дорогой ре-ингест, до строки 100 единого); аутентификация ратифицирована D39.84: одна серверная сессия в Postgres — __Host-кука браузеру · Authorization: Bearer десктопу/CLI · principal создаётся ТОЛЬКО в middleware, CSRF только на cookie-пути; ⚠ порядок деплоя: read-путь движка схему НЕ мигрирует (store.go:135-143, «schema vN … expects vM») — после апгрейда бинарника по каждой книге первой идёт write-команда; форма потока ратифицирована D39.85 (docs/research/23): воркер-обёртка платформы супервайзит процесс tmctl, ингестит NDJSON-события идемпотентным апсертом (run_id, seq) в Postgres (Reporting Database, не полный CQRS), SSE — из Postgres; ре-синк на обрыве — tmctl status --json; живой SQLite движка НЕ читать (анти-паттерн, аргументы в research/23 §4); ревью-гард: путь Go-модуля платформы никогда не вкладывать под textmachine/backend/*	Ф3, после контракта API (строка 95 единого)	D39.81, D39.84, D39.85, STACK_DECISIONS §5
П-2	Глобальный брокер рейт-лимитов провайдеров (экс-строка 97): гарды движка per-процесс (pipeline/ratelimit.go:11, mistral ~48% отказов под параллелизмом), а лимит провайдера — на ВЕСЬ аккаунт: N прогонов = N независимых гардов против общего лимита; воркер отпрашивается у платформы перед вызовом	ДО второго параллельного пользователя	D39.81, D39.84
П-3	Очередь и конкурентность по книге: River на том же Postgres, сериализация по book_id + пиннинг книги к одному хосту на MVP, лизы book_leases с heartbeat — вежливое ожидание вместо аварии	Ф3-пак платформы	STACK_DECISIONS §5, D39.84
П-4	Учёт токенов/денег per-user + бюджет-гейт ДО старта задачи (сырьё уже считает движок: request_log + internal/ledger; помнить: леджер = нижняя граница — строка 78 единого)	Ф3-пак платформы	platform/README, D39.84
П-6	OAuth-вход популярных провайдеров (Google первым) + модель аккаунта (направление владельца 04.08): authorization code + PKCE, валидация ID-токена, связывание аккаунта по ПОДТВЕРЖДЁННОЙ почте; собственная серверная сессия сохраняется (D39.84) — OAuth даёт только СОБЫТИЕ входа. Форма и библиотеки — по ресёрч-пакету направления (ратифицирует оркестратор); писатель куки с __Host-атрибутами и dev-профиль — здесь же (PD-8)	P1, вместе с П-1	владелец 04.08
П-7	Кредитный баланс и фри-тир (решения владельца 05.08; ПРОДАЖИ НЕТ — бета на предоплаченных ключах владельца): append-only леджер в целых микро-долларах, грант фри-тира из админки (дефолт $5, настраиваемый), холд ДО спавна прогона + пер-книжный потолок движку (жёсткий стоп исполняет движок), расчёт на границе попытки. ⚠ Окон с обнулением НЕТ — баланс, а не подписка: черновик usage_windows в подписочной форме заменяется. Платёжный провайдер не проектируется до решения продавать. Разбор — docs/PLATFORM_DIRECTION.md §2	P1+, после П-6	владелец 04–05.08
П-8	Минимальная админ-поверхность: начислить/списать кредиты аккаунту (одна запись леджера), посмотреть баланс и состояние прогонов. Защищённая ручка либо CLI — форму предлагает сессия. Без неё фри-тир неуправляем	вместе с П-7	владелец 05.08
П-5	API лимитов/использования + оповещение стопа по потолку (решение владельца 04.08, D39.100/ПТ-35, механизм «как Claude Code»): страница лимитов в настройках читает СТАТУС использования (не суммы — деньги на провод не идут, D39.84); стоп по потолку → статус paused + оповещение «перевод остановлен: лимиты исчерпаны»; сырьё у движка есть (request_log/ledger, потолки конфига), форму API предлагает P0	Ф3, вместе с П-1	D39.100, ПТ-35, контракт К-8
П-9	Загрузка книги POST /books (multipart) — единственная ручка контракта 0.2.0, которую пак раннера НЕ взял. Причина названа, а не умолчана: это не «ещё один хендлер», а хранилище (куда лёг файл, кто его чистит при отказе), разбор (статусы uploading/parsing/rejected существуют в схеме и ни одним писателем не заполняются), каталог проекта движка (кто пишет book.yaml — платформа его НЕ правит, D39.110) и пер-маршрутный потолок тела вместе с тестом, которого ждёт PD-72. Пока её нет, книги заводятся дев-инструментом tmplatformctl book add, и библиотека читает их так же, как читала бы загруженные: read-model один. ⚠ PD-72 закрывается ВМЕСТЕ с этой ручкой, не раньше	Ф3, следующий пак	сессия P4 (границей промта D39.119 §5а)
П-10	Честная оценка «$/глава» от ДВИЖКА. Сейчас ставка — константа платформы ($0.03, провенанс exp08 v2 через D30.4, STACK_DECISIONS §20), и это осознанная бета-мера: движковой поверхности оценки не существует, а выдумывать её запрещено. Ставка решает только ДЛИНУ шкалы (деньги защищены холдом и потолком движка), но на книге, которая заметно дороже или дешевле средней, шкала врёт пользователю о том, сколько глав он покупает. Нужна оценка от движка по конкретной книге — запрос уходит строкой ЕДИНОГО бэклога через оркестратора, не сюда	когда-нибудь (до первого платящего)	сессия P4
П-11	Наблюдаемость раннера. Метрик и трейсинга в зоне нет вовсе (грепнуто: ни prometheus, ни otel, ни expvar, ни pprof), а у раннера появились величины, которые без них не видны: глубина очереди, возраст незакрытых холдов, число прогонов в карантине, отставание тейлера, длительность свипа. Сегодня всё это читается только глазами по логам и SQL. Связано с PD-115 (у зоны нет внешнего эталона ни по одной оси, кроме безопасности)	Ф3	сессия P4