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: прежняя рекомендация безусловно сохранить две волны была сверхвыводом. Локальные гарантии исполнения не доказывают правильность переводческой топологии. Формулировки ниже сужены; конкретные альтернативы и проверка их предшественников — в продолжении.

Основа проверки: рабочее дерево при 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) уточнить: ссылка на исходник проверяется детерминированно, её семантическое толкование — нет. Требование безошибочного детерминированного толкования заранее заблокирует исследование этой задачи.

⚠ ИСПР. 17.09 (пометка, текст отчёта не трогаю): ссылка выше противоречит сама себе и адресом, и целью. Она говорит «в строке 80 БЭКЛОГА», а адрес даёт на ЖУРНАЛ ПРОГРЕССА (docs/PROGRESS.md:153); предмет — ряд трекера 80, и искать надо там. Сам адрес на журнал сегодня мёртв: на этой строке другой текст, журнал с тех пор резался и правился многократно. ⚠ Гейт якорей об этом молчал законно — адрес голый, без токена.

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	Анализ книги, редактируемый справочник персонажей/терминов/стиля, референсный перевод, саморедактура и карточки проверки; русский заявлен	«Глоссарий + редактор + референсы» уже не уникальное предложение
EditBook.ai	План по всей рукописи, перевод глав, редактура, межглавная проверка терминов, сопоставление с оригиналом и ручные правки	Литературный IDE и многоэтапность также заняты; качество и поддержка нашей пары требуют отдельной проверки
LinguaGacha	Открытый переводческий инструмент с глоссарием и рабочим местом проверки, в том числе для книг	Соперники включают готовые специализированные инструменты, а не только голые API
DelTA	Документный перевод с памятью собственных имён, двуязычными резюме и предыдущими переводами	Работа с контекстом шире глоссария уже исследуется; это ещё не доказательство необходимости именно такого решения у нас
LAIT, §2.1 и §3	Сильный агентный конвейер с локальными и общими проверками; отдельная читательская оценка	Авторы не считают выбор сложной схемы доказательством её решающего превосходства; качество требует проверки людьми, а число проходов его не устанавливает

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

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

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

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

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

Воспроизводимый артефакт к пункту 4. Исходник пробы сохранён отдельно от тестов продукта. В отдельной копии backend без ключей поместить его в internal/pipeline/engine_logic_audit_test.go и выполнить из корня этой копии:

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-прогон и не оценка качества синтетических ответов.