textmachine/docs/READER_IDE_RESEARCH_SESSION_PROMPT.md

# Промт: ресёрч-сессия «Ридер-IDE: выравнивание, статусы, HITL-редактура» (2026-07-10)

Скопируй в новую сессию Claude Code в `/home/ubuntu/projects/textmachine`.

---

## Кто ты и зачем ты

Ты — **исследовательская сессия** проекта **TextMachine**, по образцу «Валидация банка памяти» (research/13), «Адаптивная память» (research/14) и «Голос и состояние» (research/15): мультиагентный веб-ресёрч + адверсариальная верификация клеймов по первоисточникам + дешёвые $0-пробы. Зона записи: **`docs/research/16-reader-ide-alignment.md`** + своя секция в `docs/PROGRESS.md` («## Ридер-IDE», после §Голос и состояние). `architecture/*`, `backend/`, `eval/` — только чтение; механизмы и расхождения — пингами в журнале. **Ничего не коммитить** — оркестратор примет после ревью. Гардрейлы `CLAUDE.md` жёсткие (`.env` не читать; текст книги и производные — вне git; правило вендор-сверки аномалий).

## Постановка владельца (10.07)

Владелец планирует фронт Ф3 в духе VS Code: **слева** дерево/граф глав (как файловая панель); **в центре** две страницы параллельно — оригинал | перевод; **справа** панель управления (команды перевода; возможно чат-редактирование фрагмента с одним из провайдеров); **снизу** цветная полоса статуса всей книги с ползунком-позицией: зелёный — модели/гейты отработали чисто, жёлтый — сомнения (эскалации, glossary-miss, стиль-флаги — «первостепенная редактура»), красный — провал (не переведено). Философия — «возвращение недоверия к ИИ-переводу»: цвета из ДЕТЕРМИНИРОВАННЫХ вердиктов пайплайна (chunk_status/паспорта глав уже есть — D12 строил `--json` «для CI/IDE»; самооценка LLM исключена: logprobs у половины стека недоступны, research/14).

Открытые вопросы владельца (= твой мандат): как якорить соответствие оригинал↔перевод («страница в страницу»? абзацы дробятся, объём расходится ~1.9×); удобно ли такое редакторам/переводчикам; как это делают конкуренты. Рамка: **бэкенд-выхлоп под фронт = экспорт-артефакты (annotations/anchors/сборка), НЕ веб-сервер** (API/SSE — Ф3).

## Онбординг (~40 мин)

1. `CLAUDE.md` → `docs/README.md` → CURRENT-STATE в `docs/PROGRESS.md`.
2. `docs/architecture/05-decisions-log.md`: D2 (disposition/skip+flag+continue), **D12 (три класса отказов, паспорт главы, status --json, «не строить» — SSE/реалтайм)**, D15 (resume/snapshot-дисциплина — human_override её пересекает!), D21 (minimal-diff арм — синергия с правками редактора).
3. Код read-only: `backend/internal/pipeline/status.go` (read-model: ChunkState/паспорта/вердикты pass|attention|fail — это сырьё цветов), `chunker` (lossless), `eval/refusal_bench.py::split_sentences` (предложенческий оракул уже есть).
4. `docs/architecture/07-strategic-review.md` §4.6 (петля «флаг→человек» не смоделирована — ты её и проектируешь) + §5 (Mantra/Nuanxed = HITL-стандарт индустрии); `research/02-competitors.md`, `research/12-consumer-feedback.md`.

## Направления

### 1. Прайор-арт HITL-редактуры машинного перевода (центр мандата)
CAT-инструменты (memoQ / Trados / Phrase / Smartcat / MateCat): единица выравнивания (сегмент? абзац?), статусы сегментов и их цвета, QE/confidence-подсветка — как выглядит и на чём основана; издательские MT-пайплайны с UI (**Mantra Engine — ближайший аналог**, Nuanxed, Lexilit, TeaNovel, XL8); фан-стек (ридеры/редакторы GalTransl-экосистемы, LunaTranslator); параллельные читалки (bilingual e-readers, Immersive Translate — как они якорят). Ключевой вопрос: **что из UX доказанно помогает пост-редактору** (исследования post-editing: подсветка QE/ошибок ускоряет или мешает? влияние на качество/скорость PE; «жёлтая слепота» при перекалибровке порогов) — и что редакторов бесит (жалобы, форумы, отзывы).

### 2. Якорение оригинал↔перевод (главный технический вопрос владельца)
Гипотеза оркестратора на проверку: **«страница» — артефакт рендера, якорить надо не страницы, а чанк/абзац; страницы виртуальны, панели синхронизируются скроллом по ближайшему якорю (split-diff паттерн VS Code)**. Наш козырь против конкурентов: alignment у нас **рождается в пайплайне** (чанк = атом соответствия src_range↔dst_range; чанкер lossless; предложенческий оракул есть) — пост-хок выравнивание чужих текстов не нужно. Исследуй: (а) абзацная парность выхода LLM-переводчика — что известно + **$0-проба: посчитай парность абзацев src↔dst на СОХРАНЁННЫХ сырых выходах проекта** (read-only: `eval/data/*` результаты прогонов, `/home/ubuntu/books/gu-zhenren/research15-probes/probes/raw/` — там полные src/dst пары); (б) легитимный ре-параграфинг русской литературной нормы (разбиение прямой речи тире и т.п.) — когда N:M неизбежен и как деградировать якорь (глава→чанк→абзац→предложение); (в) пост-хок выравниватели (hunalign / vecalign / bertalign) — нам в пайплайн не нужны, но оцени как инструмент якорения КАНОНИЧЕСКИХ переводов для eval/пилота; (г) стоит ли принуждать переводчика промптом к сохранению абзацной структуры и/или завести дешёвый флаггер абзацной парности (класс наших стиль-флаггеров).

### 3. Визуализация доверия (цветная полоса)
Прайор-арт визуализации QE/статусов в MT-редактуре; семантика и гранулярность (чанк vs предложение vs абзац); маппинг наших детерминированных сигналов в зелёный/жёлтый/красный (эскалация была/ре-гейт прошёл → жёлтый? glossary-miss → жёлтый? где границы); калибровка «не всё жёлтое» (если жёлтого 80% — полоса бесполезна; какие пороги/приоритизация «что редактировать первым» — cost-of-fix ranking?); полоса книги целиком vs главы.

### 4. Контракт бэкенд→фронт (выход в пакет №4)
Синтезируй рекомендации: (а) схема `annotations.json` (per-chunk: src_range/dst_range/color/reasons[]/cost/versions; версионирование контракта); (б) сборка перевода в файл + **политика красных чанков** (плейсхолдер «[не переведено: reason]» vs пропуск vs исходник встык — плюсы/минусы для редактора); (в) **human_override** — пост-правка человека: как пинится чанк против redrive/resume/TM (пересечение со snapshot-дисциплиной Р6/D15 — самый контрактно-опасный кусок; скоуп и риски, НЕ полный дизайн — думать вместе с D15.2); (г) чат-редактирование фрагмента через провайдера (прайор-арт inline-edit: Cursor/Copilot-паттерны, MT-repair в CAT) — скоуп/цена/риски, не дизайн.

### 5. Креатив (гипотезы, помечать 🧪)
Правило прежнее: каждая идея указывает слот (экспорт-контракт / флаггер / паспорт / арм пилота / Ф3-бриф). Идеи «перестроить бэкенд под фронт» не принимаются без доказательства, что экспорт-артефактов не хватает.

## Метод и БАР

Дисциплина research/13–15: фан-аут → адверсариальная верификация несущих клеймов по первоисточникам (refute-by-default; вендор-клейм ≠ замер; скриншоты/доки CAT-тулзов — источник) → completeness-критик. Каждый факт — URL+дата. Вердикты CONFIRMED / PLAUSIBLE / REFUTED + «Честные слабые места». БАР рекомендации: {механизм → слот (экспорт-контракт/флаггер/Ф3-бриф) → цена (COGS ~0 — всё read-only) → как мерить → фаза}. Бюджет живых LLM-вызовов: **$0** (только чтение сохранённых выходов и веб).

## Deliverable и приёмка

1. `docs/research/16-reader-ide-alignment.md`: направления с вердиктами и источниками, результаты $0-пробы парности, таблица «вопрос владельца → ответ → рекомендация → слот → фаза», «Честные слабые места».
2. Пинги в PROGRESS (секция «## Ридер-IDE»): **оркестратору** — что ратифицировать (контракт annotations, политика красных, иерархия якорей, скоуп пакета №4); **бэкенду** — требования к экспорту (НЕ код сейчас); **полигону** — ТЗ, если парность-проба требует свежих прогонов.
3. Ничего не закоммичено; чужие зоны не тронуты.