textmachine/docs/research/31-harness-independent-critique.md

**Независимая критика подхода TextMachine — 06.09.2026**

> **⟶ СТАТУС (проставлен оркестратором 06.09): ФАКТУРА, НЕ РАТИФИЦИРОВАНА.** Отчёт заказан владельцем
> у независимой сессии Codex и заландён оркестратором как есть — правок в тело не вносилось.
> ⛔ **Полная ревью-шапка «что доказано / что СНЯТО / что не проверено» ещё НЕ написана — долг
> оркестратора.** До неё ни одно утверждение отсюда не цитируется как ратифицированное.
>
> ⚠ **ЧЕМ ЭТОТ ОТЧЁТ ОТЛИЧАЕТСЯ ОТ `research/29`/`30` и почему его нельзя читать как их продолжение:**
> те мерили ВНЕШНИЙ мир и сверяли его с нами; этот судит НАШ СОБСТВЕННЫЙ выбор архитектуры и прямо
> называет кандидатов на пересмотр. Его вердикт — «главная гипотеза остаётся ОТКРЫТОЙ» — противоречит
> тону, в котором смена 05–06.09 принимала паки, и это противоречие разрешает ВЛАДЕЛЕЦ, а не я.
>
> ⚠ **Одно его утверждение задевает уже проставленную ревью-шапку `research/30` — эррата внесена
> 06.09 в неё саму** (о трейсе размышления, п.5 этого отчёта).

Автор: Codex. Заказ: оценить способ достижения издательского качества, верхнеуровневую архитектуру и направление развития. Статус: исследовательское мнение для оркестратора; не ратификация и не задание менять код.

**Пересмотр после замечания владельца, 06.09:** прежняя рекомендация безусловно сохранить две волны была сверхвыводом. Локальные гарантии исполнения не доказывают правильность переводческой топологии. Формулировки ниже сужены; конкретные альтернативы и проверка их предшественников — в [продолжении](32-harness-architecture-alternatives.md).

Основа проверки: рабочее дерево при HEAD `6ace7e1be67ca20525736e8e64c35c525a8f01b4`, включая незакоммиченную работу над структурой глав. Код и оплаченные прогоны не изменялись. Числа старых экспериментов ниже — из их отчётов, не новый замер автора. Внешние первоисточники проверены 06.09.2026.

**Вердикт.** Движок содержит полезные механизмы контролируемого исполнения, но это не основание считать выбранную архитектуру перевода сильной целиком. Главная гипотеза — «этот харнесс устойчиво даёт лучший литературный перевод книги за приемлемую полную цену» — остаётся открытой. Опасный сдвиг курса: считать соблюдение канона и отсутствие механически видимого брака достаточной заменой сохранению смысла, голоса и авторских решений. Глобальный барьер волн и ранняя фиксация канона — кандидаты на пересмотр.

**Что следует сохранить как требования к любой архитектуре.** Ограничение повторов, воспроизводимое происхождение запросов, сохранение оплаченного ответа вместе с учётом расхода, явное владение состоянием. Конкретные волны, банк и границы snapshot этими требованиями не предопределены. Подпись термина уже допускает бесплатное переиспользование незатронутых фрагментов — утверждение «любая правка банка перепокупает всю книгу» неверно (`backend/internal/pipeline/stagerun.go:91`, `backend/internal/store/ledger.go:178`).

Рабочая схема — C1, черновик → редактор, с банковым контуром и детерминированными проверками. Судья-селектор в рабочем пути отсутствует: `CheckRunnable` запрещает `role=judge` и fanout > 1 (`backend/internal/config/pipeline.go:492`). Это допустимое упрощение; оно означает, что обещания смыслового контроля нельзя обосновывать нарисованной ролью судьи.

**1. Самая срочная поправка — измерять верность оригиналу, а не верность черновику.**

В свежем протоколе первичный показатель точности задан относительно черновика. Судья получает черновик и два редакторских результата; китайский оригинал ему не предъявлен (`eval/dovodka/blind-read/PREREG-2-BLIND-READ.md:62`; `PREREG-BLIND-READ.md:27`, `:77`). Ограничение честно записано, но такая проверка не может разрешать вопрос о смысловой безопасности редактора.

Пример: переводчик перепутал действующего персонажа. Редактор A сохранил ошибку, B исправил по оригиналу. Проверка на верность черновику способна наградить A и наказать B. Это неверно выбранная опора, которую не исправит увеличение числа судей.

Есть и второе смешение. D39.198 связывает консистентность с банком, выдумки с редактором (`docs/architecture/05-decisions-log.md:2231`). Это разумные места начала диагностики, но не установленные причины: ошибочный факт может прийти из черновика, банка или редакторского прохода.

**Коррекция:** сохранить раздельные приоритеты владельца, но оценивать конечный перевод по оригиналу; происхождение дефекта устанавливать сравнением `source → draft → final` с фактически поданным банком. Неизвестное происхождение так и обозначать. Русскую читаемость оценивать отдельно. В существующую карточку дефекта достаточно добавить источник ошибки и ссылки на соответствующие фрагменты — новая роль движка для этого не нужна.

**2. Борьба с ложными доказательствами сама породила ложное опровержение.**

В `RESULT-2-BLIND-READ.md:9–20` два случайных перевода одного режима объявлены обязанными получить ничью; выбор победителя в 29/30 оценок трактуется как неисправность прибора. Вывод неверен: два разных результата одного режима могут действительно иметь разное качество. Нулевая гипотеза касается среднего преимущества режима, а не обязательной ничьей каждой пары. В `:65–67` сам отчёт признаёт различие конкретных реализаций.

Это не доказывает исправность судьи. Это снимает именно предъявленное основание его дисквалификации. По нему уже предложено не покупать судейские панели (`docs/research/30-arhitektura-otvet.md:345`). Также правило `PREREG-2-BLIND-READ.md:89` разрешает вывод «не хуже», если значимый вред не найден; результат в `RESULT-2-BLIND-READ.md:87` уже правильно запрещает такое заключение.

**Коррекция:** разнести три проверки: одинаковые тексты и перестановки позиций проверяют оценщик; повторные генерации измеряют разброс генератора; заведомо испорченные и проверенные хорошие переводы проверяют чувствительность к качеству. Неухудшение требует заранее выбранной допустимой потери и доверительного интервала. Сохранить честный итог текущего замера: превосходство не показано; равенство также не установлено. Не выводить из этого отказ от сравнительной оценки вообще.

**3. Банк обеспечивает единообразие решения, но может размножать единообразную ошибку.**

Банковская строка, отобранная для инъекции и содержащая перевод, подаётся обязательным правилом независимо от подписи (`backend/internal/membank/memory.go:826`). Это осознанная политика против расхождения параллельных фрагментов. Но `mempostcheck.go:11–16` обещает ловить даже подчинение неверному банковскому переводу, тогда как реализация проверяет присутствие этого самого перевода и при наличии принимает его (`:116–125`). Данным алгоритмом такое обещание невыполнимо.

Это уже не только теоретический риск: в небольшой прежней пробе ошибочная строка была принята в 6/6 окон и вытеснила правильную в 5/6 (`docs/research/24-bank-arbitration.md:253–269`). Это результат конкретной модели и материала; процент нельзя переносить на нынешний полный движок. Он достаточен, чтобы перестать считать послушание проверкой правильности.

**Коррекция:** единый канон сохранить; различать соблюдение формы, правильность выбранного значения и правильность привязки к персонажу/контексту. Сравнить автоматический банк, независимо проверенный банк и отсутствие банка; добавить несколько правдоподобно ошибочных записей. Считать ущерб по последующим употреблениям сущности, а не только по числу строк. Если вред подтверждается, исправлять допуск и пересмотр банковского решения. Возвращение маркера «проверь» само по себе уже не имеет убедительной поддержки этой пробы.

На длинной книге есть второй вопрос: сохраняется ли полезный банк при порционном переводе. Лимит майнера применяется до части фильтров, авто-банк пересобирается, банковые батчи при новых свидетельствах могут менять запрос и покупаться повторно (`backend/internal/miner/miner_emit.go:119`; `backend/internal/pipeline/mining.go:697`; `backend/internal/pipeline/terminologist.go:775`, `:849`). Проверка роста 10 → 50 → 200 глав против обработки того же текста сразу должна считать удержанные решения, новые ошибки и общую цену. Расширять майнер до такого сравнения необязательно.

**4. Словарь книги пока не заменяет понимание её повествования.**

Редактор получает исходник и черновик собственной единицы. Подбор банка у редактора идёт без предыдущего sticky-контекста (`backend/internal/pipeline/waverun.go:689–706`); вход рендера не несёт соседнего повествования (`render.go:178–210`). Профили голосов заведены, но их инъекция намеренно не включена (`bankmaterialize.go:290–307`). Следовательно, наличие банка и таблиц голосов ещё не означает передачу межглавных связей и индивидуальной речи модели.

Контрпример проверен исполнением: две книги различаются персонажем в предыдущей главе; следующая начинается одинаковым «终于答应了» — «наконец согласился/согласилась». Реальный `TranslateBook` с текущими zh→ru промптами и подставным провайдером дал разные запросы предыдущих единиц и побайтно одинаковые запросы текущих переводчика и редактора. Условия: пустой одинаковый банк, майнинг выключен, банкнота включена; две главы и две редакторские единицы на вариант. Это проверка доступности информации; частоту неправильных переводов живой модели она не устанавливает. Артефакт и воспроизведение — в конце документа.

Отрицательные результаты carryover не закрывают весь класс: в exp15 широкое чтение, lookahead и состояние сцены остались неисполненными (`docs/experiments/15-segmentation-empirics.md:489`). Сам target-architecture ограничивает перенос результатов классом исследованных книг (`docs/architecture/09-target-architecture.md:138`=`НИКОГДА не переносится в продукт`). Работа над структурой глав полезна, но она отвечает на другой вопрос.

**Коррекция:** проверить зависимости через границы редакторских единиц: субъект, адресат, намеренная неоднозначность, смена регистра, позднее раскрытие смысла термина. Сначала сравнить текущий вход с минимальным необходимым исходным контекстом; затем выбирать окно, поиск исходных фрагментов или состояние сцены. Не начинать со строительства универсальных summaries/графа. В строке 80 бэклога (`docs/PROGRESS.md:153`) уточнить: ссылка на исходник проверяется детерминированно, её семантическое толкование — нет. Требование безошибочного детерминированного толкования заранее заблокирует исследование этой задачи.

**5. Черновик → редактор — рабочая гипотеза, которую нельзя превращать в неприкосновенную основу.**

Польза редактора поверх слабого черновика измерена; утверждение «всё построено без экспериментов» неверно. Но это другой вопрос, чем выигрыш у сильной модели, переводящей непосредственно с оригинала при сопоставимом контексте и цене. Сравнения уже были, однако их ограничения и поздние отзывы не позволяют объявлять вопрос закрытым (`docs/experiments/21-role-topology.md:958`; `23-editor-tier.md:7322–7385`).

Два аргумента в `docs/research/30-arhitektura-otvet.md:136–142` не следуют из данных. Наличие текста будущего ответа в reasoning сильной модели не делает внешний дешёвый черновик эквивалентным её собственной работе. И зависимость нынешнего терминолога от черновика не доказывает невозможность добывать банк из оригинала. Это свойство реализации, не необходимость предметной области.

**Коррекция:** держать прямой сильный перевод обязательным соперником. Одинаковый готовый банк уравнивает банковые условия; для выделения эффекта черновика также уравнять финальную модель, усилие, содержательное задание и исходный контекст. Даже такое сравнение НЕ доказывает, что можно бесплатно убрать производство черновика из банкового контура. Отдельно сравнить полные конфигурации, включая вариант с извлечением банка из оригинала и всю его цену. Если проще получается не хуже в заранее заданных пределах и дешевле по полной стоимости, сокращать стадии. Если связка выигрывает — сохранять по этому результату.

Сюда же относится задача борьбы с translationese: «живой литературный русский» и обязательная гипотактическая перевёрстка (`backend/prompts/zh-ru/editor.md:15–19`) могут помогать плоскому построчному тексту, но не являются универсальным стилем всех авторов. Повторы уже частично защищены промптом. Остальную авторскую намеренность следует проверять на контрастных книгах, а не максимизировать гладкость, разнообразие или длину абзаца.

**6. Следующий полезный инфраструктурный шаг — удешевить изменение решения о качестве.**

Snapshot волны входит в адрес оплаченного ответа; бесплатный перенос через изменение snapshot сейчас разрешён для банкового изменения, но не для изменения гейта (`backend/internal/pipeline/render.go:369`; `repin.go:44–48`). Изменение проверки, включённой в snapshot, поэтому способно потребовать повторных запросов при прежних входных сообщениях. Это не относится к каждой наблюдательной ручке: например, включение `regression_guard` не двигает snapshot. Такая связь оплаты с вердиктом удорожает обучение проекта на уже оплаченных книгах.

Направление D15.2 — отделить идентичность запроса/ответа от версии вердикта — правильное и уже запланировано. Его стоит поднять относительно новых проверяющих ролей. Старую спеку нельзя исполнять буквально: она предшествует нынешним волнам и предусматривает миграционную перепокупку (`backend/docs/D15.2-content-addressed-resume-spec.md:3`, `:479`). Критерий нового дизайна: изменение только проверки переоценивает сохранённые ответы без LLM-вызовов. Сохранение черновика при смене только редактора уже обеспечено раздельными снапшотами волн (`backend/internal/pipeline/snapshot.go:224`) — эту гарантию сохранить. Совместимость со старыми оплаченными артефактами — часть задачи.

**Положение относительно конкурентов.**

Это сравнение публично подтверждённых возможностей, не испытание чужого качества. Закрытые реализации не проверены; маркетинговые проценты точности не приняты за результаты.

| Система и первоисточник | Что уже существует публично | Следствие для TextMachine |
|---|---|---|
| [Translate a Book](https://translateabook.com/) | Анализ книги, редактируемый справочник персонажей/терминов/стиля, референсный перевод, саморедактура и карточки проверки; русский заявлен | «Глоссарий + редактор + референсы» уже не уникальное предложение |
| [EditBook.ai](https://editbook.ai/auth/examples/translation) | План по всей рукописи, перевод глав, редактура, межглавная проверка терминов, сопоставление с оригиналом и ручные правки | Литературный IDE и многоэтапность также заняты; качество и поддержка нашей пары требуют отдельной проверки |
| [LinguaGacha](https://github.com/neavo/LinguaGacha/blob/main/README_EN.md) | Открытый переводческий инструмент с глоссарием и рабочим местом проверки, в том числе для книг | Соперники включают готовые специализированные инструменты, а не только голые API |
| [DelTA](https://arxiv.org/abs/2410.08143) | Документный перевод с памятью собственных имён, двуязычными резюме и предыдущими переводами | Работа с контекстом шире глоссария уже исследуется; это ещё не доказательство необходимости именно такого решения у нас |
| [LAIT, §2.1 и §3](https://arxiv.org/html/2606.26040v1) | Сильный агентный конвейер с локальными и общими проверками; отдельная читательская оценка | Авторы не считают выбор сложной схемы доказательством её решающего превосходства; качество требует проверки людьми, а число проходов его не устанавливает |

TextMachine содержит проверяемые механизмы исполнения; сравнения надёжности архитектур на одинаковой нагрузке здесь не было. По доказанному качеству длинной книги лидерство не установлено. По части доступных пользовательских возможностей конкуренты уже предъявляют то, что у нас остаётся планом. И заявления «впереди всех», и заявления «конкуренты переводят лучше» сейчас выходят за имеющиеся данные. Перечни функций в research/02 и 22 нельзя использовать как рейтинг качества или себестоимости.

**Ближайший цикл решения, который я рекомендую оркестратору.**

1. Исправить смысл трёх существующих утверждений: опора оценки — оригинал; случайные реализации не обязаны получать ничью; postcheck проверяет соблюдение банковской формы. Это работа с текущими протоколами и описаниями, без нового конвейера.
2. После уже идущих блокирующих работ провести ограниченное сравнение текущего полного движка и сильного прямого перевода на нескольких свежих книгах. Нужны связные отрывки с переходами между главами и поздними появлениями сущностей; ещё одна языковая пара проверяет переносимость отдельно от zh→ru. Не подменять такую проверку одними синтетическими сценами или известной модели вебновеллой.
3. Раздельно получить: ошибки смысла по оригиналу; сохранение авторского/персонажного голоса; соблюдение и правильность канона; время человеческой доводки; полную цену вместе с банком, повторными вызовами и исправлениями. Не сводить это в один произвольный балл. Часть оценки должен сделать независимый двуязычный читатель; согласие нескольких LLM не заменяет его.
4. Заранее определить допустимое ухудшение и правило выбора. Группировать результаты по книгам и исходным единицам: дополнительные голоса судей не увеличивают число независимых текстов. На части материала повторить генерацию обеих схем для оценки разброса внутри конфигурации. При неопределённом результате решение остаётся управленческим, с явной ценой неопределённости. Малый тест выявляет крупный провал и направляет следующий шаг; он не доказывает отсутствие редких ошибок на тысячах глав.
5. Новую память, критика или ремонтный проход строить под обнаруженный класс остаточных ошибок и проверять сравнением с вариантом без него. Для банка дополнительно измерить внесённый вред; для контекста — доступность нужного факта; для редактора — пользу и новые ошибки одновременно.

**Сигнал менять направление:** простой соперник выигрывает при той же планке готовности; автоматический банк увеличивает смысловые ошибки; выигрыш остаётся только в знакомой книге/разметке; новые проходы уменьшают флаги, но увеличивают ручную доводку. При этих исходах надо упрощать или менять соответствующий механизм. Архитектурные ограничения представления можно устанавливать кодом ещё до такого замера; конкретные альтернативы разобраны в продолжении. Сохранять полезные гарантии исполнения не означает заранее сохранять топологию.

**Границы этой проверки.** Прочитаны стартовый бриф, промпт оркестратора, основные архитектурные документы и актуальные планы; исследовательский корпус о переводе, памяти, нарезке, голосах, топологиях и конкурентах; отчёты экспериментов и свежая доводка. Журнал решений читался через индекс и конкретные ноты. Длинные технические хроники backend/docs и контрактное research/28 разобраны по решениям, итогам и остаткам, не построчно целиком. Код проверялся по существенным маршрутам; полного код-аудита и повторения оплаченных экспериментов не было. Независимые параллельные чтения помогли найти противоречия, но не считаются независимостью обучающих корпусов моделей. Архивная критика не принималась за факт текущего дерева; активные правки структуры глав и уже построенная проводка цены учтены.

**Воспроизводимый артефакт к пункту 4.** [Исходник пробы](31-harness-audit/context_probe_test.go.txt) сохранён отдельно от тестов продукта. В отдельной копии `backend` без ключей поместить его в `internal/pipeline/engine_logic_audit_test.go` и выполнить из корня этой копии:

```sh
go test ./internal/pipeline -run '^TestAuditContextAcrossEditUnits$' -count=1 -v
```

Исполнено в `/tmp/textmachine-engine-logic-audit-09z7llyi`: PASS, восемь вызовов подставного клиента, без сетевых/платных LLM-вызовов. Тест проверяет границы настоящего манифеста и сравнивает все поля `LLMRequest`. Совпавшие запросы: переводчик — 3910 байт, SHA256 `f852ea316880644b60124500cbcc9b2ba10b9c0bb2d791e4a7ba543b62e1ea1f`; редактор — 7008 байт, SHA256 `e733dbca09e807d29bc4b3b36bb780be03afd00e71356a01c1169281b6e72c80`. Это снимок указанных промптов и фикстуры, не обещание неизменных хешей после их правки. Конфигурация использует инфраструктуру тестов движка; это не полный боевой C1-прогон и не оценка качества синтетических ответов.