textmachine/docs/BACKEND_MINIRUN_SESSION_PROMPT.md

19 KiB
Raw Blame History

Промт бэкенд-сессии: МИНИ-ПРОГОН ~10 глав — сквозной тест всего построенного (гигиена → прогон → верификация в ОДНОЙ сессии)

СТАТУС: РАЗМОРОЖЕН, ЗАПУСК САНКЦИОНИРОВАН ВЛАДЕЛЬЦЕМ (25.07). Цель — доказать, что построенное РАБОТАЕТ, поэтому проверяется и канал банкноты, который до сих пор ни разу не стрелял (D39.36: гейт выключен, в промпте переводчика блока нет, а распарсенные записи код выбрасывает). Но проверяется ОТДЕЛЬНЫМ дешёвым проходом (ШАГ 3), а не включением в главный прогон — правка промпта переводчика меняет сам черновик, и главное измерение (остаток дефектов) перестало бы отвечать на свой вопрос. Два прохода, два ответа, ничего не смешано.

ОДНА СЕССИЯ ДЕЛАЕТ ВСЁ (решение владельца): гонит, проверяет, отчитывается. Цена решения названа честно: наш принцип author ≠ reviewer снят, а по переписи инцидентов проекта самоотчёт — доминирующий канал ошибок (62 из 180). Три компенсации обязательны и не обсуждаются: (1) пре-регистрация ДО первой траты — что меряем, пороги, и ЧТО МЫ ЗАРАНЕЕ НАЗОВЁМ ПРОВАЛОМ, пишется первым разделом отчёта и потом НЕ переписывается (прогон, у которого критерий успеха дописан после результата, ничего не доказывает); (2) заявление = команда — каждое число и каждое «отработало» сопровождается командой/артефактом, которым получено; (3) приёмка оркестратора идёт по СЫРЬЮ — БД, логи, экспорт — и ре-ранит твой манифест; твои выводы принимаются только вместе с фактурой.

Что важнее всего понять про эту работу

Если что-то пошло не так — это ЦЕННЫЙ результат прогона, а не то, что надо сгладить. Прогон затевался, чтобы узнать правду о построенном, а не чтобы получить зелёный отчёт. Дефект, найденный на 10 главах за $0.15, дешевле дефекта, найденного на книге в 2284 раздела.

ШАГ 0 — ГИГИЕНА ДО ПРОГОНА ($0-код, лендится этим же паком)

  1. ОБЯЗАТЕЛЬНЫЙ флип Gates.RegressionGuard.Enabled. D38.4 п.5 ратифицировал: «Оркестратор при сборке единого resnapshot ОБЯЗАН включить Gates.RegressionGuard.Enabled, иначе построенная наблюдаемость на пере-прогоне не сработает». Проверено (D39.34): ключа regression_guard нет ни в одном шиппинг-конфиге ⇒ гейт false, и rerun2 прошёл без него. Включить, покрыть тестом, что гейт реально стреляет.
  2. Два нита общности — берём (условность снята D39.35: терять нечего, снапшот и так разошёлся): множитель expectedHours := n * 2 (internal/checks/checkers.go) → данные пары; Detail-строки чекеров → шаблоны из данных. Байт-нейтральность больше НЕ требуется — но каждую сдвинутую версионную ось назови в отчёте строкой.
  3. Опционально, если дёшево: проекция пере-оплаты в tmctl status (спека D15.2 §9: заменить булев ConfigDrift числом «N чанков, ~$X»). Не тянуть, если раздувает пак.

ШАГ 1 — ПОДГОТОВКА (без трат)

  • Бэкап обязателен: cp rerun2/*.db в сторону ДО первой write-команды. БД стенда на схеме v9, бинарь ждёт v10 — первая write-команда мигрирует необратимо, а rerun2 — единственный носитель фактуры того прогона.
  • Новый проект, а не поверх старого: свой book.yaml + своя БД + срез глав 110 из исходного guzhenren-gb18030.txt (GB18030, книга и производные ВНЕ git). Прогон сквозной: ingest → чанкер → волна черновика → майнинг-стоп → волна редактуры → чекеры → экспорт.
  • Потолки: книжный и дневной выставить осознанно (ожидание $0.100.35 на один арм; ставь потолок с запасом, но не «бесконечность» — гейт должен быть способен выстрелить).
  • Пре-рег в отчёт: что мерим (список ниже), пороги, что считаем провалом.

ШАГ 2 — ПРОГОН И ЧТО ИМЕННО ДОКАЗЫВАЕМ

Каждый пункт — утверждение, которое обязано быть подтверждено сырьём (лог/строка БД/файл), а не «отработало нормально»:

  1. Гейт согласия на пере-оплату (пак-18) СРАБОТАЛ ЖИВЬЁМ. Снапшот стенда разошёлся по трём осям (D39.35), значит на резюме/redrive гейт обязан показать проекцию и потребовать --accept-rebill. Зафиксируй: сумму проекции, число единиц, отказ без флага, проход с флагом. Это первое живое исполнение механизма.
  2. Майнинг-стоп остановил прогон и потребовал подпись владельца; reject-set и промоушен отработали (mined_rejects). Сколько кандидатов, что подписано.
  3. Чекеры и QualityReport: какие классы дефектов сработали, сколько на 10 главах. Read-only скан остатка ремонта ($0) — это ГЛАВНОЕ измерение прогона: он даёт владельцу цифру для решения о включении платной петли (D39.24).
  4. RegressionGuard после флипа реально даёт наблюдаемость (число/omission-гард виден в отчёте).
  5. Лейбл-путь = no-op: книга без лейблов, поэтому маршрут обязан быть тождественен конфиговому. Докажи (резолвнутые модели = конфиговые, ни одной строки content_routing_problems).
  6. Деньги durable: finish=stop доля, echo-класс (ожидание 0), reserve→settle одной транзакцией, итог против потолка. Сравни фактическую стоимость с моей оценкой ($0.02 драфт + $0.080.15 редактура на арм) и скажи, где я ошибся.
  7. escalation_model (пак-18): если эскалация случится — поле держит ОТВЕТИВШУЮ модель, а не попробованную.

Армы: один арм (deepseek-v4-pro) — база. Второй арм (glm-5, итерация №2) — ТОЛЬКО если владелец скажет отдельно: он стоит ещё ~$0.1 и упирается в принятый им риск Z.AI (D39.30 п.2).

ШАГ 3 — ПРОБА БАНКНОТЫ (отдельный дешёвый проход, ≈$0.02; делается ПОСЛЕ главного прогона)

Цель: доказать, что канал WHAT физически работает от промпта до парсера — то, чего не проверял ни один прогон.

  • Отдельный проект, ТОЛЬКО волна черновика. Проверено оркестратором: CheckRunnable гейтит только core (C0/C1) и fanout — стадия редактора НЕ обязательна, поэтому конфиг из одной draft-стадии исполним. Свой book.yaml, своя БД, те же 10 глав.
  • Копия промпта переводчика (НЕ шиппинг-файл) + инструкция выдавать блок ⟦TM-BANK-v1⟧ табличными строками, бюджет ≤12 строк на чанк (bankMaxLines). Формат сверь по internal/pipeline/banknote.go — парсер уже написан, подстраивайся под него, а не наоборот.
  • gates.banknote.enabled: true только в этом проекте.
  • LOG_LLM_BODIES включить — записи парсера код выбрасывает (D39.36), поэтому единственный способ увидеть САМИ предложения модели — сырые тела ответов. Без этого проба даст только счётчики.
  • Что доказываем: модель вообще выдаёт блок · парсер его принимает (n_banknote_lines > 0, parse_fail = 0, truncated = 0) · блок корректно срезается (в чистом черновике сепаратора нет) · насколько осмысленны предложения — глазами, на выборке 1015 терминов.
  • Чего НЕ делаем: не чиним разомкнутый шов (это следующая работа), не трогаем шиппинг-промпт и шиппинг-конфиг, не гоним редактуру.

ШАГ 4 — ВЕРИФИКАЦИЯ (та же сессия; проверяем КОД по сырью, а не по собственным впечатлениям)

Каждый пункт — по СЫРЬЮ (БД, логи, экспорт); «отработало» без артефакта не принимается. Проверяй так, будто отчёт писал не ты:

  1. Гейт согласия на пере-оплату — первое живое срабатывание. Обязан показать проекцию (N единиц, ~$X) и отказать без флага. Проверь по логам и по коду, что отказ случился до первой резервации денег, а не после. Сверь сумму проекции с фактической тратой прогона — расхождение объясни.
  2. Майнинг-стоп. Прогон остановился перед волной редактуры; подписная карта записана; после подписи владельца дельта опустела и стоп не повторился. Сколько кандидатов, сколько промоутнуто/отклонено. Проверь, что термы приходят БЕЗ dst — это ожидаемое сегодня поведение (D39.36), зафиксируй его как факт, а не как аварию.
  3. Банк памяти в работе. Из retrieval_state: попадания, «липкие» переносы, промахи пост-чека с деталями. Сверь независимо: возьми 23 термина из глоссария, найди их в исходнике главы и проверь глазами, что в финальном тексте стоит канонная форма — или что промах честно записан. Ориентир прошлого прогона: 107 попаданий / 3 промаха на 10 чанков.
  4. Чекеры и остаток дефектов — ГЛАВНОЕ ИЗМЕРЕНИЕ. Read-only скан остатка по классам ($0). Эта цифра — вход в решение владельца о включении платной петли ремонта (D39.24). Дай её честно: сколько кандидатов на починку, каких классов, сколько из них — ложные срабатывания на глаз. Ложняки считай отдельно: решение принимается по чистому остатку, а не по сырому счётчику.
  5. RegressionGuard после включения реально даёт наблюдаемость (длина/числовой дрейф видны), а не молчит.
  6. Путь content-лейблов = no-op. Книга не помечена ⇒ маршрут обязан быть тождественен конфиговому: резолвнутые модели = конфиговые, ни одной строки проблем маршрутизации.
  7. Деньги durable. Доля finish=stop, эхо-класс (ожидание 0), резервации и списания, итог против потолков. Проверь, что резерв и списание живут одной транзакцией (по строкам БД, не по коду).
  8. Слаги и цены живые (правило двух направлений): перед платными вызовами — /models и вендор-дока; ре-чек ToS по D39.32 (для этого прогона достаточно строки «проверено, изменений нет»).
  9. Канал WHAT. По сырью пробы: n_banknote_lines > 0, parse_fail = 0, truncated = 0 · сепаратор ⟦TM-BANK-v1⟧ отсутствует в чистом черновике (срезался) · сами предложения читаемы и осмысленны — оцени выборку 1015 терминов ГЛАЗАМИ по сырым телам ответов и скажи прямо, годятся ли они как основа канона или это шум. Это вход в решение о починке шва — от твоей оценки зависит, стоит ли она работы.

«РОВНО ТАК»

  • Судья НЕ вызывается (D39.32: детерминированный скорер первым; судья — только когда от вердикта зависит решение).
  • Петля ремонта остаётся enabled: false — меряем остаток, не чиним.
  • Майнинг-стоп не обходить: подпись владельца — часть протокола, не формальность. Дошёл до стопа — остановись и пингуй.
  • Никаких 18+ и лейблов: книга не помечена, лейбл-путь проверяется как no-op.
  • Сессия НЕ коммитит (ни код, ни прогонные артефакты); книга и производные — вне git.
  • Аномалия провайдера (404, новый finish_reason, игнор параметров) → вендор-дока и /models, НЕ гадание. Правило двух направлений.
  • Ре-чек ToS перед платными вызовами (D39.32 п.4): триггеры — головной Google ToS 30.07.2026 и любая правка accepts_labels; для этого прогона достаточно строки «проверено, изменений нет».

Сид-дельта (данные книги) — что можно, что ждёт владельца

Проверено оркестратором по guzhenren-seed-v2.yaml: 春秋蝉 («Весенне-осенняя цикада») и 资质 («талант») уже в сиде; 学堂家老 отсутствует; 赤城 есть только внутри имени 古月赤城; семейство 元 расщеплено元海 = «море истинной ци», 真元 = «истинная ци», 元石 = «первобытный камень». Единый корень (предложение «изначальн-») — решение владельца, ждём. Если ответа к старту нет — гони как есть и зафиксируй это как ИЗВЕСТНЫЙ разрыв канона, чтобы чтение результата не приписало терминологию качеству перевода.

Приёмка

Отчёт docs/archive/reports/MINIRUN_REPORT_<дата>.md: пре-рег первым разделом · по каждому пункту ШАГА 4 вердикт + артефакт · фактические деньги против оценки ($0.100.17 главный проход + ≈$0.02 проба) · цифра остатка дефектов с ОТДЕЛЁННЫМИ ложняками (решение владельца о платной петле принимается по чистому остатку, не по сырому счётчику) · оценка предложений банкноты глазами — годятся ли как основа канона или это шум · девиации отдельным разделом · раздел «что прогон НЕ проверил» — он честнее списка успехов. Сессия НЕ коммитит.

Канал вопросов: непонятно / конфликт промта с кодом → пинг оркестратору через владельца, НЕ тихая интерпретация.