43 KiB
Пересмотр архитектурного вывода и конкретные альтернативы — 06.09.2026
⟶ СТАТУС (проставлен оркестратором 06.09): ФАКТУРА, НЕ РАТИФИЦИРОВАНА. Отчёт заказан владельцем у независимой сессии Codex и заландён оркестратором как есть — правок в тело не вносилось. ⛔ Полная ревью-шапка «что доказано / что СНЯТО / что не проверено» ещё НЕ написана — долг оркестратора. До неё ни одно утверждение отсюда не цитируется как ратифицированное.
⚠ ЧЕМ ЭТОТ ОТЧЁТ ОТЛИЧАЕТСЯ ОТ
research/29/30и почему его нельзя читать как их продолжение: те мерили ВНЕШНИЙ мир и сверяли его с нами; этот судит НАШ СОБСТВЕННЫЙ выбор архитектуры и прямо называет кандидатов на пересмотр. Его вердикт — «главная гипотеза остаётся ОТКРЫТОЙ» — противоречит тону, в котором смена 05–06.09 принимала паки, и это противоречие разрешает ВЛАДЕЛЕЦ, а не я.⚠ Одно его утверждение задевает уже проставленную ревью-шапку
research/30— эррата внесена 06.09 в неё саму (о трейсе размышления, п.5 этого отчёта).
Автор: Codex. Продолжение первого отчёта по замечанию владельца: нужны решения основной задачи, а не только критика измерений; нельзя заново предлагать уже пройденные идеи. Статус: предложения, не ратификация и не заказ менять движок. Сверено с рабочим деревом при HEAD 6ace7e1be67ca20525736e8e64c35c525a8f01b4; активные изменения структуры глав учтены. Платные эксперименты не запускались.
Мой прежний вывод «ядро сильное, две волны сохранить» был недостаточно обоснован.
Я поставил рядом полезные гарантии исполнения и спорную организацию перевода. Атомарное сохранение ответа с оплатой обосновано конкретным отказом между двумя записями. Из этого не следует, что правильно сначала перевести всю разрешённую порцию дешёвой моделью, затем выбрать общий канон, затем отдать текст редактору. Терминолог уже получает контексты оригинала и сам принимает решения — представлять банк простым копированием первого черновика тоже было бы ошибкой. Вопрос в порядке и пересматриваемости решений, а не в полном отсутствии проверки источника.
Сохранять следует свойства: учёт расхода до и после запроса, сохранение оплаченного ответа, известное происхождение входов, ограничение повторов и явное владение состоянием. Я больше не объявляю неприкосновенными текущую схему банка, глобальный барьер волн, идентичность единицы перевода и правила принятия результата. Хорошо работающая реализация неверного представления задачи остаётся неверным представлением.
Сам проект содержит контрсвидетельство моей прежней уверенности: research/19-chunking-cohesion.md:556–561 назвал глобальную консолидацию качественно лучшей по аналогии с резюме, но research/20-bank-mining.md:250–259 уже ограничил перенос: именно превосходство глобальной реконсиляции банка не было установлено. Положительные результаты отдельных редакторских проходов не проверяют этот барьер отдельно.
Где архитектура подменяет предметную задачу.
| Нынешний контракт — проверено кодом | Что он реально обеспечивает | Чего из этого не следует |
|---|---|---|
Совпала исходная строка → подать банковый перевод законом. backend/internal/membank/memory.go:585–612, :925–936 |
Выбрать набор словарных указаний для фрагмента | Что найдено именно нужное значение/лицо и что каждое употребление переведено правильно |
Две matchable записи одного src с разными sense/dst в пересекающихся окнах запрещены. membank/memseed.go:201–228 |
Не допустить противоречивых инструкций нынешнему сопоставителю | Что полисемия внутри главы исчезла из предметной области. Представление не умеет выразить часть легитимных случаев |
Банк определяется до редакторской волны; банкноты извлекает переводческая роль. pipeline/waverun.go:173, :536–550 |
Один набор общих решений для параллельной редактуры | Что наиболее содержательное редакторское чтение может исправить общее решение: автоматического обратного пути здесь нет |
Резервируется очередной вызов; весь допущенный draft идёт до edit. store/ledger.go:44–80, pipeline/waverun.go:139–181 |
Соблюдать текущий денежный потолок на допуске | Что бюджет будет вложен в законченные главы: остановка внутри draft не переходит к редактору |
Последняя запись chunk_status заменяет прежние FinalHash/Disposition; export читает текущую финальную стадию. store/chunkstatus.go:64–88, pipeline/export.go:278–299 |
Отдать текущее вычисленное состояние | Что это последняя принятая редакция книги и что неудачная повторная редактура не ухудшила доступный результат |
Главная проблема логики: фиксируется не только перевод, но и способ истолковать книгу — часто до того чтения, которое могло бы это истолкование опровергнуть. Затем проверки лучше видят подчинение принятому решению, чем ошибку самого решения. Увеличение числа гейтов такой контур не исправляет.
Проверенные исторические развилки: где мог закрепиться неверный поворот.
Историю нельзя свести к «раньше ошиблись, теперь надо наоборот». Ниже различены слабое основание решения, чрезмерное обобщение и неполностью проведённый пересмотр.
| Цепочка | Что именно не выдерживает проверки | Что пересмотреть |
|---|---|---|
Глобальная консолидация: заказ владельца на параллельные волны (research/19:534–540) → дополнительное качественное обоснование research/19:556–561 → оговорка research/20:250–259 → D39.12/17 → нынешний waverun.go |
Это не история «ложные данные заставили построить волны»: выбор отвечал заказу скорости и организации работы. Ошибка — придать ему дополнительный статус качественного превосходства по исследованию резюме. Оговорка о непроверенности переноса была известна; я сам потерял её в отчёте 31 | Сохранить глобальные волны как действующий вариант, но снять их привилегию при сравнении с другим расписанием. Их качество не доказано отдельно от редактора/банка |
| Контекст: исправленный exp15 → D39.7/8 от 18.07 → отказ строить carryover → отсутствие его канала в нынешнем входе | Начальный брак рига был исправлен ДО ратификации — обвинять решение в использовании тех старых чисел неверно. Но читательское «подтверждение null» объявлено при нарушенной слепоте и разных объёмах, которые сам отчёт признаёт (experiments/15-segmentation-empirics.md:538–544). Проба прямо не устанавливает бесполезность carryover как механизма |
Разрешать повторное исследование при новом классе реально потерянной зависимости. Не возвращать удалённые мёртвые ручки автоматически. «Тогда не строить» допустимо; «любому тексту контекст не нужен» из этого не следует |
Полисемия: D16.1 → запрет совпадающего src с разными смыслами → D39.193 п.3 от 04.09 признаёт два подписанных канона законными → рендер изменён, входные ограничения остались |
Пересмотр уже СОСТОЯЛСЯ в решении, но не проведён через весь путь. Рендер-тест вручную создаёт две записи 青山 (membank/render_test.go:178–188), а штатный seed/свод/дверь запрещают соответствующую коллизию (memseed.go:201–228; pipeline/bankmaterialize.go:142; membank/decisions.go:914). Поле sense и зелёный тест рендера создают впечатление возможности, которой нет у обычного входа |
Согласовать предметный контракт и поддерживаемый путь целиком. Просто удалить запрет опасно: matcher всё ещё не разрешает употребления, а postcheck проверяет наличие формы где-нибудь в единице |
Q4a: сравнение flash/pro на смысловых ловушках → D39.9 → обоснование размещения структуры у редактора в architecture/10-prompt-architecture.md:13 |
На свежем flash не было провалов для расчёта доли исправлений (experiments/15-segmentation-empirics.md:644–655). Отказ платить дороже без наблюдаемого выигрыша разумен. Но этот опыт не измерял, какой роли поручить структуру: 09-target-architecture.md:111–114 сам называет такой контракт неизмеренным |
Снять с Q4a функцию доказательства распределения структурных задач. Сохранить узкое решение по тем моделям и тому срезу. Асимметрия существовала раньше; замер её не породил, но стал чрезмерным оправданием её сохранения |
Точные тела первых двух решений: docs/archive/architecture/05-decisions-D39-arch-reset.md:154, :166, :200, :7. Последнее переосмысление полисемии — docs/architecture/05-decisions-log.md:2060. Это конкретные основания пересмотреть степень уверенности и совместимость решений; они не доказывают, что все нынешние переводы хуже возможных.
Полисемия проверена исполнением, бесплатно. Каждый из двух подписанных смыслов отдельно загружается; вместе — отказ. Разнести их по двум файлам не помогает: общий проверяющий свода также отказывает. При входе ниже загрузчика настоящие Materialize → Select → Render сохраняют оба смысла. Контроль с непересекающимися окнами глав успешно загружается и выбирает по одному смыслу. Это подтверждает расхождение контрактов, не утечку запрещённого банка в реальный прогон. Исходник пробы сохраняется отдельно от кода продукта; воспроизведение — в конце.
Практический вывод для оркестратора: следующая проверка должна идти от решения к его предпосылке и всем зависимым ограничениям, а не только от свежего пака к его тестам. Для этих четырёх развилок уже названы и исходные основания, и текущие последствия. Нового общего процесса с десятками правил для этого не требуется.
Что я исключил из списка «новых гипотез».
| Идея | Где уже была | Почему не предлагаю как новую |
|---|---|---|
| Банк из оригинала, затем сильный прямой перевод | START_PROMT.MD, V6; research/17-external-critique.md:61; research/30-arhitektura-otvet.md:110 |
Есть постановка и несколько связанных сравнений. Полный вариант не закрыт, но идея старая |
| Соседний контекст, lookahead, состояние сцены | research/19-chunking-cohesion.md:191–224; experiments/15-segmentation-empirics.md:489 |
Часть вариантов измерена, часть не исполнена. «Не измерено» не означает «никто не предлагал» |
| Граф упоминаний, раздельные сущности/значения, адресные исходные свидетельства | research/17-external-critique.md:41–63; research/30-arhitektura-otvet.md:271–279 |
Это подходящий ответ на часть проблем нынешнего банка, но уже известное направление. Индекс сам по себе не меняет объект действия канона |
| Плейсхолдеры имён и поздняя морфологическая подстановка | research/15-voice-and-state.md:188; research/13-memory-bank-validation.md:133–136 |
Уже названы и принцип, и условие безопасной подстановки. Формат с ID/падежами был бы уточнением, не новым подходом |
| Предварительный смысловой разбор, Annotator, смысловой скелет | experiments/09-pilot-protocol.md:155; research/29-harness-topology-survey.md:263 |
Есть предшественники и отрицательный результат конкретной двухпроходки. Скрыть draft до первого прочтения — интересная отдельная интервенция, но не новое семейство архитектур |
| Критик → локальный фиксер; patch/diff | V6; exp20/21; research/30-arhitektura-otvet.md:104–110; D39.117 |
Конкретная дешёвая замена редактора не прошла. Отрицательный результат не закрывает все варианты, но повторять общий совет нельзя |
| Отбирать фрагменты для дорогой редактуры | experiments/21-role-topology.md:1039–1066 |
Уже измеряли конкретные отборщики и получили слабую экономику |
| Возражение к банку, рецензент спорных кластеров, quarantine | research/17-external-critique.md:191–193; research/24-bank-arbitration.md:291–292; D39.102/104 |
Сам по себе «канал апелляции» — конкретизация старого намерения, а не новая гипотеза |
| Разделить идентичность ответа и вердикта | backend/docs/D15.2-content-addressed-resume-spec.md:1–15 |
Давно спроектировано. В первом отчёте это была рекомендация приоритета, не новая идея |
| Неизменяемый экспорт; принятие/отклонение правок человеком | platform/internal/exports/exports.go:19–23; research/16-reader-ide-alignment.md:235–241 |
Файлы экспорта уже неизменяемы; человеческое принятие давно обсуждалось |
Ниже — три конкретных изменения логики, полного эквивалента которых в проверенном корпусе я не нашёл. Это ограниченное утверждение о просмотренной истории, не доказательство мировой новизны. Ближайший предшественник и отличие указаны у каждого.
Гипотеза 1. Выбирать канон вместе с его реализациями в книге. Мой первый выбор для прототипа.
Сейчас процедура приблизительно такова: выбрать dst → закрепить его → независимо переделать затронутый текст. Предлагаю единицей принятия сделать вариант общего решения вместе с согласованным набором его реализаций. Новый перевод термина — кандидат до проверки того, что он делает с книгой.
Пример: название артефакта сначала понято буквально, поздняя сцена раскрыла второе значение, существенное для сюжета. Красиво перевести одно позднее употребление недостаточно. Нужно проверить, остаются ли ранние реплики правдивыми, сохраняется ли намёк и не раскрывается ли разгадка раньше времени.
Исполнимый поток:
- Триггер — конкретное противоречие с исходником или предложенная правка пользователя. Не непрерывное «поищи ещё улучшения».
- Сформировать два кандидата: действующее решение и одну альтернативу. Каждый содержит область применимости, исходные свидетельства и перечень затронутых единиц. Для начала брать однозначно установленную сущность/семью; не выдавать строковый поиск за решённую кореференцию.
- Создать кандидатные версии только затронутых фрагментов под альтернативой. Обычный редактор сохраняется; обязательный diff-протокол не вводится. Старый текст остаётся доступным.
- Проверить оба комплекта по исходным употреблениям: ранним, поздним и тем, где новое решение может навредить. Первому прототипу достаточно независимой двуязычной проверки. Если такого проверяющего нет, автоматическое принятие смысловой ревизии пока не обосновано.
- Принять одной группой новую версию банкового решения и все необходимые редакторские результаты либо сохранить прежний комплект. Ошибка одного re-edit не должна оставлять читательскую редакцию наполовину на новом каноне.
Минимальный новый артефакт: revision = base_revision + bank_delta + affected_units + candidate_hashes + decision. Рабочие checkpoint остаются прежним механизмом оплаты; отдельный указатель определяет принятую редакцию. При изменении исходника или слиянии сущностей зависимые места нужно переопределить — совпадение прежнего списка не доказывает полноту. Пока их перечень не установлен, частичное переключение общего решения запрещено. Состояние «проверяется» не делает прежнюю ошибку правильной: известный дефект остаётся обозначенным и в старой редакции. Запрос текущего частичного результата по действующему экспортному контракту можно продолжать обслуживать отдельно.
Содержательное отличие от старых идей: keyword retranslation и семейный батчинг уже есть (research/05-memory-glossary.md:82; research/24-bank-arbitration.md:396–410). Но там сначала принимают термин, затем приводят текст к нему. Здесь результат применения к тексту участвует в выборе самого термина, а принятие относится ко всему связанному изменению. Неизменяемый EPUB-файл также не решает эту задачу: требуется состав принятой редакции до сборки файла.
Внешний источник механики — Lehrer/Docent, §4, LCCO: несколько связанных лексических замен выполняются одной поисковой операцией. По одной они могут не улучшать оценку документа; вместе — улучшать. Перенос на пару «банковое решение + LLM-тексты» — моя гипотеза. Статья про старый en→es SMT и ограниченную оценку, не доказательство литературного zh→ru. Её функцию оценки и требование одинаковой лексики переносить не предлагаю.
Что покупаем: возможность исправить первичную интерпретацию по последствиям её применения; согласованность повторной редактуры; сохранение уже принятой работы при неудачном кандидате. Это не обещает автоматически узнать правильное значение.
Цена и риск: нужны зависимости между решением и текстами; неверно найденный набор употреблений даст неполное исправление; согласованная альтернатива тоже может быть ложной. Частая сущность затронет сотни глав — такой случай выходит за бюджет первой пробы. Начать с одного спорного решения, одной альтернативы и малого известного множества употреблений. Подписанное решение автоматически не менять.
Как опровергнуть: при одинаковых кандидатах и сопоставимом бюджете сравнить нынешний порядок «сначала выбрать банк» с выбором по комплектам. Для приписывания улучшения банку нужен также свежий re-edit под ПРЕЖНИМ банком: улучшить текст могла сама повторная редактура. Если комплект не позволяет принять лучшее смысловое решение, либо новые ошибки/цена съедают выигрыш, качественную гипотезу закрыть. Отдельная бесплатная проверка отказа: прервать одну связанную редактуру — принятая редакция не должна переключиться частично. Это проверяет только согласованность публикации.
Гипотеза 2. Направлять исправление по результату ограниченной интервенции, а не по объяснению критика.
Вместо схемы «критик назвал причину → исправляем названный узел» — диагностический режим для уже подтверждённого дорогого дефекта. У него три возможных подозреваемых: ложное банковое указание, якорение на черновике, неверное прочтение самого исходника.
Исполнимый протокол:
- Зафиксировать исходный проблемный запрос и способ проверки конкретного дефекта. Например, кто именно отказался от предложения в исходнике; не общий балл художественности.
- Получить контрольные повторения прежнего запроса и ограниченные варианты с удалением одного основания: спорной банковой записи или всего черновика. Модель, исходный контекст и остальные параметры сохраняются. Контроль и вмешательства перемешиваются в одном временном блоке, чтобы изменение сервинга не было принято за эффект вмешательства.
- Сравнить частоту исправления конкретного дефекта и появления новых. Исчезновение ошибки в одном случайном ответе — не диагноз. Число повторов определяется допустимой ценой и необходимой различимостью; при нехватке данных результат
unknown. - Выход — рекомендация адресата ремонта с уликами. Устойчивое улучшение без банкового правила направляет случай к гипотезе 1; без черновика — к другому режиму генерации данного места. Ничего не меняет автоматически в подписанном каноне. Диагностические тексты сами по себе не публикуются.
Что здесь новое относительно просмотренного: абляции и контрфактуалы уже применялись на полигоне; source-grounded проверка давно предложена. Не нашёл в текущем маршруте и его постановках использования интервенции после обнаружения дефекта для выбора того, что именно исправлять. Это отличается от exp21 G: там отборщик заранее предсказывал, где редактура окупится; здесь проверяется чувствительность конкретного сбоя к конкретному входу.
Что покупаем: меньше бессмысленных повторных редактур под тем же неверным основанием. Чего не покупаем: строгого доказательства причинности одним вызовом или автоматической смысловой истины. Изменение длины запроса и взаимодействие нескольких оснований также могут влиять на ответ; вывод относится к вмешательству в данный запрос.
Если оба одиночных удаления не помогают, нельзя объявлять виноватым понимание источника: банк и draft могут независимо поддерживать одну ошибку. Нужен совместный контроль либо unknown. Удаление draft также меняет редакторскую задачу; положительный эффект показывает пригодность другого маршрута, но сам по себе не устанавливает психологический механизм якорения.
Риск и предел: дополнительные вызовы способны стоить дороже обычной прямой перегенерации. Поэтому это режим редкого сложного случая, не проход по каждой главе. Как опровергнуть: если при том же бюджете простая повторная редактура или прямой сильный перевод исправляют не меньше случаев и вносят не больше вреда, диагностический режим не нужен.
Гипотеза 3. Деньги на завершение начатого результата должны быть недоступны для новых черновиков.
Это решение проблемы порядка исполнения, а не средство улучшить литературность. Сейчас платформенный запас k × expected + stepMax [+ bookOnce] уже существует (platform/internal/pricing/pricing.go:166–212). Предлагать «добавить запас на редактора» заново было бы ошибкой. Но в движке он становится общим потолком: Reserve не различает деньги для новой черновой работы и деньги для завершения уже начатой.
Новый контракт допуска: перед началом порции определить бюджет её предусмотренного завершения — банковой работы, если нужна, редакторских вызовов и ограниченных повторов. Связать его с этой порцией; другие черновики не могут его занять. Новая порция допускается только из остатка после этих обязательств. Сначала завершается уже начатая работа; после settle неиспользованный запас освобождается. Этот фонд не прибавляет денег к пользовательскому потолку и не изображается фактической тратой.
Порция и её завершающий путь должны быть определены до допуска. Если фиксированная банковая фаза требует большего бюджета, чем доступно, резервирование само её не удешевляет: нужен меньший исполнимый заказ либо явный останов до покупки черновиков. Для максимального охвата всей книги может быть выбран прежний глобальный порядок, но его цена тогда становится осознанным выбором. Не следует молча сокращать уже обещанный пользователю объём.
Новизна: резерв отдельного вызова, повышенный платформенный холд и последовательный цикл всех стадий уже были. Не нашёл целевого обязательства, зарезервированного до начала порции и защищённого от расходования другими порциями. Это изменение admission-политики. Оно совместимо с разными расписаниями и не требует сразу строить граф всех зависимостей книги.
Цена и риск: меньшая параллельность, слишком осторожные оценки могут оставить деньги неиспользованными. Неизвестная фактическая стоимость или исчерпанный бюджет повторов всё ещё могут остановить работу. Гарантируется ограничение расходования назначенного фонда, а не хороший перевод и не безусловное завершение.
Как опровергнуть: при одинаковом общем потолке и заданных ответах/ценах подставного провайдера сравнить долю денег в незавершённых заготовках, число полных юнитов и задержку первого. Если на реалистичных распределениях нынешний запас уже снимает проблему либо потеря параллельности перевешивает пользу, новую политику не строить. Живой платный прогон для первого сравнения не нужен.
Как бы я изменил ближайший курс.
Начал бы с прототипа совместного пересмотра одного канонного решения и его текстовых последствий, используя существующие сохранённые материалы и редакторский путь. Это проверяет другую единицу принятия решения и непосредственно касается цели книги. Сначала установить, помогает ли она выбирать лучше; затем проектировать постоянное хранение принятых редакций. Диагностические интервенции — следующая, более рискованная ветка. Защищённый бюджет — самостоятельная альтернатива расписания, если при ограниченном бюджете важны законченные главы.
Есть старый, но необходимый долг перед расширением такого контура: канон относится к сущности/значению в данном употреблении, а не просто к одинаковым буквам. Его не выдаю новой идеей. При нынешнем запрете нельзя явно задать и проверить два одновременно действующих канона одной поверхности. Более сильная модель иногда разберётся сама, но не исправит этим контракт данных; различать нужно способность случайно получить хороший перевод и способность выразить и проверить требование.
Моё актуальное суждение: реализация содержит полезные инженерные механизмы; переводческое ядро пока чрезмерно опирается на раннюю фиксацию строкового канона и одностороннее движение решения к финальному тексту. Именно это я предлагаю поставить под изменение. Наличие тестов, принятых паков и объяснений в D-логе не даёт оснований заранее сохранять эту форму.
Как проверялась история и где предел уверенности. Повторно прочитаны собственный отчёт, стартовый бриф и относящиеся архитектурные документы; независимо разобраны код волн, банка, резервов, текущего export и версияции; сопоставлены research 05/13–24/29/30, старый 12-architecture-as-antipattern, актуальная доводка и относящиеся эксперименты. Решения проверялись через индекс и тела D16, D39.102/104/117/144/158/198/205, а не через один пересказ. Поиск включал архивные решения, отчёты, промпты и документы платформы. Это не заявление о построчной вычитке каждого файла репозитория и не абсолютная гарантия отсутствия забытой формулировки.
Для проверки новизны сравнивался механизм, не только имя: поэтому placeholders, граф упоминаний, предразбор и апелляция исключены. Внешний поиск дополнительно дал документный noisy-channel reranker: совместный выбор переводов по вероятности исходника при переводе и вероятности целевого документа. В корпусе его не нашёл, но в ближайшие рекомендации не включаю: это новостной zh→en, а доступный качественный вероятностный scorer нашей пары не установлен. Новизна сама по себе не оправдывает новую подсистему.
Воспроизведение контракта полисемии. В отдельной копии backend поместить приложенную пробу в internal/membank/polysemy_contract_audit_test.go. Из корня копии:
GOCACHE=/tmp/textmachine-engine-logic-audit-gocache go test ./internal/membank -run '^(TestAuditPolysemyLoaderVersusRenderer|TestTheLawBlockGivesOneOrderPerSourceTerm)$' -count=1 -v
Исполнено в /tmp/textmachine-engine-logic-audit-09z7llyi: обе проверки PASS. memseed.go, memory.go, render_test.go временной копии сверены SHA256 с рабочим деревом. Ключи, сеть и платные модели не используются. Сам тест не утверждает, что обе записи проходят штатный вход: он намеренно различает загрузчик и нижележащий renderer.