Промт: ресёрч-сессия «Ридер-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 мин)

CLAUDE.md → docs/README.md → CURRENT-STATE в docs/PROGRESS.md.
docs/architecture/05-decisions-log.md: D2 (disposition/skip+flag+continue), D12 (три класса отказов, паспорт главы, status --json, «не строить» — SSE/реалтайм), D15 (resume/snapshot-дисциплина — human_override её пересекает!), D21 (minimal-diff арм — синергия с правками редактора).
Код read-only: backend/internal/pipeline/status.go (read-model: ChunkState/паспорта/вердикты pass|attention|fail — это сырьё цветов), chunker (lossless), eval/refusal_bench.py::split_sentences (предложенческий оракул уже есть).
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 и приёмка

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

12 KiB Raw Blame History Unescape Escape