textmachine/platform/docs/archive/PLATFORM_SESSION_PROMPT_2026-08-04.md

⚠ ПРОМТ ОТРАБОТАН — исторический, не задание. По нему прошли ЧЕТЫРЕ сессии: P0 (скелет, принят D39.107), P1 (вход OIDC, кредитный леджер, админ-CLI, деплой-юнит), P2 (очередь приёмки P1 + два своих ревью) и P3 (фикс-лист приёмки P2 целиком, передан запиской D39.111). P1+P2 приняты D39.109 (fcdab81), фикс-пак P3 — D39.114 (99f049c, девять строк закрыто). Состояние зоны, решения и открытые дефекты: platform-PROGRESS.md (раздел «Ратификация приёмкой P2») + DEFECT_REGISTER.md ⚠ Перечень живых строк здесь НЕ дублируется (норма D39.112 «один носитель на факт»: рукописная копия перечня разошлась с реестром на первом же фиксе). Живые строки — python3 docs/scripts/counts.py плюс сам DEFECT_REGISTER.md. Следующий промт зоны (реконсилятор · тейлер журнала · транзиентные юниты прогона) выдаётся по слову владельца — D39.107 п.3(3). Ниже — текст, по которому работали; исполнять его заново не нужно.

Промт: платформа-сессия P0 — стек, скелет, дизайн-ответы контракту

Ты — первая платформенная сессия TextMachine. Зона записи — только platform/. backend/, frontend/, docs/, eval/ — read-only; расхождения и вопросы — в ЗОННЫЙ журнал platform/docs/platform-PROGRESS.md (решение владельца 04.08: весь прогресс зоны — там, в docs/PROGRESS.md платформа не пишет). Сессия не коммитит — лендит оркестратор: дерево доводится до зелёного и передаётся. Git-канон — CLAUDE.md §Гардрейлы (никаких git add -A, reset --hard, перезаписи истории; чужие незакоммиченные файлы не трогать).

Промт написан оркестратором №12 (D39.100). Ратифицирует правки — он же. Вся документация проекта ведётся ИИ-сессиями и может ошибаться: несущие утверждения проверяй по коду/спеке сам, находки расхождений — в журнал зоны.

Что за продукт и где твоё место

TextMachine — SaaS издательского художественного перевода больших текстов (zh/ja/en→ru) мультиагентным LLM-пайплайном. Движок (backend/) — Go-CLI tmctl: процесс-на-прогон, свой SQLite на книгу, никакого сервера внутри (ратифицировано D39.81/D39.85 — HTTP в движок не тащить). Фронт (frontend/) — SPA ридер-IDE, работает на моках, ждёт живой API. Ты — control plane между ними: пользователи · сессии · очередь · воркер, супервайзящий процессы tmctl · материализация статуса в Postgres · HTTP/SSE для фронта.

Обязательное чтение ДО кода (порядок; жаргон — docs/glossary.md)

1. Корневой CLAUDE.md — канон целей и гардрейлы (⚠ .env не читать НИКОГДА).
2. docs/research/23-engine-platform-seam.md — ратифицированный шов движок↔платформа (D39.85) — приоритетный канон зоны: NDJSON-поток событий движка → идемпотентный апсерт (run_id, seq) в Postgres (Reporting Database) → SSE фронту из Postgres; ре-синк на обрыве — tmctl status --json; анти-паттерны запрещены: живой SQLite движка не читать · event-sourcing/реплей истории не строить · read-пакет из ядра не выносить.
3. docs/architecture/14-api-contract/ — ратифицированный контракт API v0 (D39.99): openapi.yaml — нормативная поверхность, которую ты обязан отдать; README.md — провенанс каждого решения и открытые К-вопросы. Твои: К-4 (ревизия чтений: одна сквозная или пер-ресурсная) · К-7 (пагинация: 2284 главы / 1200 терминов) · К-12 (завершение экспорта: пуш событием или опрос).
4. platform/BACKLOG.md — П-1..П-5: твой зонный трекер (аутентификация П-1 ратифицирована D39.84 + frontend/docs/STACK_DECISIONS.md §5: ОДНА серверная сессия в Postgres, __Host-кука браузеру · Bearer десктопу/CLI · principal создаётся ТОЛЬКО в middleware · CSRF только на cookie-пути).
5. frontend/docs/STACK_DECISIONS.md §5 — транспорт-решения фронта (SSE-дисциплина, heartbeat ~20 c, Last-Event-ID, отказ от WebSocket) — твой контрагент по проводу.
6. Grep по D-номерам в docs/architecture/05-decisions-log.md: D39.81 · D39.84 · D39.85 · D39.99 · D39.100 (целиком файл НЕ читать).

Скоуп P0 — фундамент, и ни шагом дальше

1. Стек с live-сверкой (версии по памяти не называть — проверять live; пины точными числами, таблицей в зонный док platform/docs/STACK_DECISIONS.md с датами релизов и «зачем нам»): Go (та же мажорная линия, что у движка — сверься с backend/go.mod), Postgres, HTTP-роутер/библиотеки (предложи минимум, stdlib-first — ратифицирует оркестратор), River (очередь, уже назван П-3/STACK §5 — пин подтверди). Библиотеки сам не ратифицируешь — таблица уходит оркестратору при передаче.
2. Layout модуля. ⚠ Ревью-гард D39.85: путь Go-модуля платформы никогда не вкладывать под путь движка — иначе доступ к backend/internal/* по правилу префикса. Отдельный platform/go.mod уже заведён — наполни. ⚠ Корневой go.work (мандат D39.85) НЕ создавай — корень вне твоей зоны, его заведёт оркестратор при лендинге.
3. Скелет, который компилируется и поднимается: HTTP-сервер + /healthz · каркас session-auth по П-1 (схема Postgres + middleware, без UI регистрации) · драфт схемы read-model под контракт (books/runs/chapters/units/bank/notes/events + ревизии) · интерфейс NDJSON-ингест воркера (супервизия процесса tmctl, апсерт (run_id, seq), ре-синк status --json) — интерфейс и типы, живой прогон НЕ нужен: NDJSON-эмиттер в движке ещё НЕ построен (строка 103 единого бэклога) — формы событий проектируй по словарю research/23 §7 и контракту §6, из tmctl потока сегодня не получить.
4. Зонная батарея: свой check (build · vet · lint · test) одной командой; пины линтера точные. Образец дисциплины — backend/Makefile (агрегатная цель там зовётся battery) и фронтовый npm run check.
5. Дизайн-ответы К-4 · К-7 · К-12 + форма П-5 (API лимитов/использования + оповещение «перевод остановлен: лимиты исчерпаны», D39.100/ПТ-35; суммы денег на провод НЕ идут — статус использования, не доллары). Каждый ответ — ПРЕДЛОЖЕНИЕ с обоснованием в зонном журнале; ратифицирует оркестратор, спеку правит фронт-сессия после ратификации.

Не в скоупе: П-2 (брокер рейт-лимитов — гейт «до второго пользователя») · стройка очереди П-3 целиком (дизайн-заметки можно) · деплой/TLS/домены · UI чего угодно · любые вызовы LLM-провайдеров. Бюджет сессии $0.

Жёсткие ограничения

• Движок не править и не форкать; tmctl дёргать можно только read-only командами и только в интеграционных пробах ($0); живой SQLite движка не открывать.
• Деньги: суммы/цены не попадают в API-ответы (канон D39.84); в логи уровня INFO — тоже (норма ЭТОГО промта, не D-лога); лимиты-СТАТУС — П-5, отдельная поверхность.
• ПТ-34: ни один байт пользовательского перевода — на индексируемый URL (X-Robots-Tag, Cache-Control: no-store уже в контракте — соблюсти в реализации).
• Пары/языки: платформа языко-агностична; никакой логики по конкретной паре/книге.

Как работать

1. Ревью исполнением — мандат проекта (решение владельца 12.07): каждый деливерабл проверяется запуском (сервер поднялся и ответил · тест сработал · линт чист), не чтением.
2. Адверсариальная самопроверка перед финишем (author≠reviewer): пройди по своим решениям с установкой опровергать; особо — схему read-model против спеки контракта (каждое поле ответа API обязано иметь источник в схеме или в артефакте шва).
3. Спорное с каноном / новое продуктовое — НЕ решать: вопрос в зонный журнал, работу продолжать там, где вопроса не требуется.
4. Комментарии в коде — «почему», не «что»; файлы малые; stdlib-first.

Готово — это когда

• Дерево компилируется, зонная батарея зелёная, /healthz отвечает живым запуском.
• platform/docs/STACK_DECISIONS.md — пины live-сверены, таблица полная.
• Дизайн-ответы К-4/К-7/К-12/П-5 лежат в platform/docs/platform-PROGRESS.md с обоснованиями.
• Журнал зоны обновлён: что построено · что предложено · что спрошено; BACKLOG-строки получили диспозиции.
• Ничего не закоммичено — дерево передано оркестратору.