> **⟶ ОТРАБОТАН, ЗАКРЫТ D39 (2026-07-13, оркестратор №6).** Синк-аудит проведён (`architecture/08-sync-audit-ledger.md`, 65 находок / 0 refuted); все 5 концернов разобраны + целевая 7-слойная архитектура и фазовый план — `architecture/09-target-architecture.md`; ратификация — D-лог **D39**. Решения владельца: фазово (трек A build-now ∥ трек B ресёрч) + слой пар = сеам/zh→ru. Выданы хендофф-промты `BACKEND_TRACKA_PACK1_SESSION_PROMPT.md` (трек A) + `RESEARCHER_CHUNKING_COHESION_SESSION_PROMPT.md` (трек B). Архивная копия.

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

---

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

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

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

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

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

Владелец: «оркестратору надо синкануться с полигон-сессией, а полигону — с бэкендерами».
1. **Оркестратор ← полигон:** пойми, что полигон РЕАЛЬНО исследовал (правила/особенности переводов, «искусство промтинга», чанкование, translator/editor) и что осталось НЕДОнесённым/недоделанным.
2. **Полигон ← бэкенд:** полигон сверяется с бэкендом — реализовал ли бэкенд РОВНО исследованное (не хуже/не иначе), залендено ли чисто.
3. **Текущее состояние:** онбординг по `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` (этот файл — АГЕНДА ресета поверх роли, не замена).
