Промт: НОВАЯ оркестратор-сессия — АРХИТЕКТУРНЫЙ РЕСЕТ + разбор накопленных концернов владельца (2026-07-13)

Зачем эта сессия (мета — читать первым)

Владелец остановил текущий раунд. Появилось ощущение, что оркестратор «тупит» в главном: КАК строить проект правильно — архитектурно чисто, расширяемо, и чтобы он решал ГЛАВНУЮ поставленную задачу (издательский художественный литературный перевод крупных текстов zh/ja/en→ru; победить «нехудожественность»/translationese — см. CLAUDE.md, START_PROMT.MD). Пошло тактическое латание (санитайзер-класс тут, промпт-атом там) вместо архитектурного мышления с первых принципов.

Плюс всплыла «проблема сломанного телефона»: полигон ИССЛЕДУЕТ → оркестратор делает ВЫВОДЫ → бэкенд РЕАЛИЗУЕТ, и по дороге теряется/искажается. Триггер: владелец сам вернулся к «умному чанкованию» — иначе оркестратор о нём вообще не вспомнил бы, хотя это несущий рычаг. Значит в цепочке теряется и другое.

Эта сессия = РЕСЕТ. Твоя задача — НЕ продолжать латать, а: (1) синкануть сессии, (2) разобрать 5 концернов владельца ниже (ничего не потерять), (3) выстроить ПРАВИЛЬНЫЙ архитектурный план под главную задачу. Пере-прогон глав и дальнейшая постройка — только ПОСЛЕ этого.

Первым делом — СИНК (прямое условие владельца)

Владелец: «оркестратору надо синкануться с полигон-сессией, а полигону — с бэкендерами».

Оркестратор ← полигон: пойми, что полигон РЕАЛЬНО исследовал (правила/особенности переводов, «искусство промтинга», чанкование, translator/editor) и что осталось НЕДОнесённым/недоделанным.
Полигон ← бэкенд: полигон сверяется с бэкендом — реализовал ли бэкенд РОВНО исследованное (не хуже/не иначе), залендено ли чисто.
Текущее состояние: онбординг по CLAUDE.md → docs/architecture/05-decisions-log.md (D1–D38.5) → docs/PROGRESS.md CURRENT-STATE. Залендено в текущем раунде: дискурс-editor (v3, P1a+чэнъюй+few_shot-тумблер — 0ac5f7a), reseed-сид (eb409f2), инфра-пак санитайзер/экспорт/гард (d5beefc). Пере-прогон 3–10 глав был предложен — ПРИОСТАНОВЛЕН этим ресетом (гнать текущий конфиг = слабый тест, ключевые рычаги не построены).

КОНЦЕРНЫ ВЛАДЕЛЬЦА — разобрать КАЖДЫЙ, ничего не терять

1. Разделение труда ПЕРЕВОДЧИК ↔ РЕДАКТОР (где рождается структура/абзацы)

Владелец посмотрел бэкенд-фиксы: фикс абзацев лёг на плечи РЕДАКТОРА. А что с самим ПЕРЕВОДЧИКОМ?
Понятно, что редактор должен следить за смыслом. Но как осуществляется сам перевод? Почему он не делается сразу «около-правильным» и структурированным?
Похоже, редактор переписывает ВСЮ ГЛАВУ? (неэффективно/рискованно — если так).
Тестировал ли полигон вообще что-то на этот счёт (переводчик даёт структуру vs редактор-переписыватель)?
Архитектурный вопрос: правильное разделение — переводчик должен отдавать ~корректный+структурированный черновик, а не сваливать всё на редактора.

2. Чанкование НЕТРИВИАЛЬНО (оркестратор его недооценивает)

Сейчас чанкование простое и захардкожено (targetChunkTokens=1500, chunker.go:47; SplitChunks без параметра). Это факт.
НО чанкование влияет на структуру абзацев И на логику/смысл оригинала — обрезав где-то по чанку, можно что-то потерять. Именно поэтому задача нетривиальна.
НЕЛЬЗЯ опираться на предположение «все китайские книги такие, просто грузим главы в модель».
Глава может быть НАМНОГО БОЛЬШЕ допустимого загружаемого в модель чанка → главу надо нарезать по чанкам, по ЛОГИЧЕСКИМ чанкам.
Задача реально сложная; решать со стороны СТАТИЧЕСКОГО КОДА (а как ещё? не модель-вызовами размечать чанк — это дорого).
НАТРАВИТЬ ИССЛЕДОВАНИЕ: как правильно чанковать текст (в т.ч. поиск в интернете best-practices), фоллбеки в коде, логика вида «книга сама пишет мелкими главами, где 1-2-3-4 главы целиком влезают в чанк» (это ПРОСТЕЙШИЙ пример — рассмотреть ВСЕ кейсы).
Контекст: research/18 + exp14 (кривая нарезки, P1c глава-целиком лучше+дешевле — направленно), Voita ACL2019 (кросс-предложенческий контекст чинит дейксис/когезию = суть претензии-2). Тег «D35.7» (декаплинг draft=чанк/edit=глава) цитируется в PROGRESS/exp14/research18, но записи в D-логе НЕТ — формализовать.

3. «Сломанный телефон»: как лендили полигон-ресёрч в бэкенд

Владельца смущает, КАК залендили результаты полигон-исследований в бэкенд.
Проверить, что решение в бэкенде сейчас: (а) работает нормально/адекватно, (б) написано чисто, расширяемо, правильно, (в) ГЛАВНОЕ — залендено ли ПРАВИЛЬНО.
Риск: полигон выдал ресёрч X → оркестратор сделал выводы Y → бэкенд понял Z и реализовал не то, что логически работает ХУЖЕ или даже неправильнее, чем код, который писал сам полигон.
Аудит недавних лендингов (дискурс-editor + few_shot-тумблер, reseed-enforce, инфра-пак-санитайзер) на соответствие ИНТЕНТУ исследования + чистоту/расширяемость. Владелец отдельно отметил: «сейчас в бэкенде код приземлён кое как» (п.4) — проверить общую чистоту кода.

4. Промты: ПЕР-ЯЗЫК + где держать правила языковых пар

Полигон активно гуглил правила/особенности переводов, «искусство промтинга» — этого накопилось много.
Q1 (рождён из START_PROMT.MD п.5): промты сейчас заточены под zh→ru и содержат даже ПРИМЕРЫ (few-shot). Насколько это актуально — кейсов правильных переводов не напасёшься (очевидно), а в промте они зачем-то есть. Насколько такой подход вообще нормален?
Владелец считает: промты для переводов должны быть под каждый язык свой. Вопрос — ГДЕ держать условные «правила языка» для zh→ru, en→ru и т.д.: везде в промты инжектятся свои правила / особенности / академ-исследования. Всё это должно быть правильно РАЗМНОЖЕНО, правильно написано, на ПРАВИЛЬНЫХ языках. Ничего такого сейчас нет.
V4-п.5 (START_PROMT.MD, добавлен владельцем): система сейчас РУССКО-центрична — промт-запросы в модель идут на русском, target=ru. Глупо делать бэкенд только под русский. Возможно, запросы надо слать на языке TARGET (на который переводим), или на языке ОРИГИНАЛА — «вообще не точно». При zh→en русский вообще не должен участвовать (чтоб не сбивать вероятностный прогон модели). → Архитектура обязана поддерживать произвольный source→target с пер-парными правилами/промтами; язык самого промта — открытый архитектурный вопрос.

5. ДЫРА в передаче знаний (что ещё забыли?)

«Если бы я не вернулся к чанкованию — ты, такое ощущение, вообще не знал об этом. Это прям проблема».
Значит в полигон-сессии могло остаться ещё недонесённое: оркестратор «тупо не знает/не понимает», а полигон «не знает, как это залендили в прод код». Прям дыра.
Нужен механизм, чтобы находки не терялись: систематический ledger находок → диспозиция (как разовый аудит D38.4, но как ПРОЦЕСС), сквозной по цепочке полигон→оркестратор→бэкенд. Пройтись по полигон-сессии(ям) и выгрести ВСЁ незакрытое.

Что от новой оркестратор-сессии (курс)

НЕ латать тактически. Мыслить архитектурно с первых принципов: чисто, расширяемо, правильно, решает ГЛАВНУЮ задачу (художественность, не инфра-галочки).
Синк полигон↔оркестратор↔бэкенд — устранить сломанный телефон (концерны 3, 5).
По каждому из 5 концернов — план: что ИССЛЕДОВАТЬ (полигон/интернет), что и КАК строить, как правильно разложить (промты пер-язык, чанкер-модуль, translator/editor-контракт).
Чанкование (концерн 2) и translator/editor-разделение (концерн 1) и пер-язык-промт-архитектура (концерн 4) — вероятно, требуют полигон-исследования ПЕРЕД постройкой.
Пере-прогон глав — НЕ раньше, чем эти три продуманы архитектурно (иначе снова слабый тест на голом текущем конфиге).
Держать самопроверку/адверсариал (мандат CLAUDE.md) и грунтовать выводы file:line — но не подменять этим архитектурное решение.

Дисциплина / состояние (короткая справка)

Контракт: D-лог D1–D38.5. Дискурс-editor (0ac5f7a) / reseed (eb409f2) / инфра-пак (d5beefc) залендены — но под аудит (концерн 3), не считать «готовым и верным» по умолчанию.
Флаги для формализации: «D35.7» без записи в D-логе (концерн 2); un-built рычаги из аудита D38.4 (inversion-защита = editor-swap; крупная edit-единица; word↔word число-дрейф Ф2; чэнъюй долгосрочно = Ф2 Annotator-маски).
Мультисессия жива: возможен бэкенд-WIP; git-дисциплина — общий PROGRESS.md проверять git diff ПЕРЕД стейджем (per-file недостаточно для общего файла); no reset/rewrite/checkout поверх грязного дерева; коммиты en ≤30 слов; .env не читать; books//corpus — только по прямой задаче.
START_PROMT.MD содержит V4-идеи владельца (в т.ч. п.5 про языки [концерн 4] и п.1 про параллелизм/скорость перевода) — НЕ потерять при планировании V4.
Роль оркестратора — docs/ORCHESTRATOR_SESSION_PROMPT.md (этот файл — АГЕНДА ресета поверх роли, не замена).

15 KiB Raw Blame History Unescape Escape