NODEDC_1C/docs/TECH/history_colibration.md

Да, тут уже напрашивается не просто “ещё одно поле в автопрогонах”, а нормальная управляющая схема. То есть у вас должно быть не только “модель ответила / оценка 5-балльная”, а три опоры:

1. эталон идеального поведения ассистента;
2. ручная разметка результата прогона с управленческим смыслом;
3. канонический файл возможностей ассистента по отработанным маршрутам 1С.

И тогда автопрогоны перестают быть просто логами, а становятся контуром развития системы.

Ниже я собрал это так, чтобы можно было почти целиком отдать в Codex.

---

Как я бы это сформулировал концептуально

1. Нужен отдельный блок: «Эталон поведения ассистента»

Это не просто описание “каким хотелось бы видеть ответ”. Это должен быть формальный канон, который понимают:

• сам ассистент;
• система автопрогонов;
• пост-анализ;
• Codex, который потом дорабатывает маршруты и поведение.

То есть это не prose-блок “идеальная работа”, а именно Assistant Canon / Behavior Canon.

Что в нём должно быть

А. Что такое хороший ответ

Хороший ответ ассистента:

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

Б. Что такое плохой ответ

Плохой ответ ассистента:

• выдумывает функцию, которой нет;
• делает вид, что может точно ответить, когда не может;
• отвечает внутренним техническим языком;
• сухо отказывает без пользы;
• валит пользователя в огромный список умений;
• не понимает, когда вопрос надо передать в “не покрыто, но рядом”;
• не различает безопасный общий ответ и рискованный прикладной совет.

В. Какой идеал поведения на границе покрытия

Вот это вообще ключевой блок.

Ассистент должен:

• честно понимать границу своих возможностей;
• не маскировать отсутствие маршрута;
• не ломаться;
• не отвечать “не поддерживается” в лоб;
• не уходить в системные сообщения;
• давать человекочитаемое ограничение;
• предлагать ближайший полезный путь.

Это и есть ваш эталон.

---

2. Нужна ручная разметка не только по качеству, но и по судьбе вопроса

Вот это очень сильная мысль. Пятибалльная оценка сама по себе почти бесполезна, потому что она не говорит, что делать дальше.

Нужна ещё одна сущность:

Decision Markup / Route Decision Markup

То есть по каждому прогону вы размечаете не только “норм / не норм”, а каково управленческое решение по классу вопроса.

Я бы добавил в UI не просто кнопку, а выпадающий классификатор

Например:

• covered_ok — кейс нормальный, покрывается, поведение ок;
• covered_but_bad_answer — кейс должен покрываться, но ответ плохой;
• good_question_to_implement — хороший вопрос, его надо брать в отработку;
• out_of_scope_but_answer_softly — вопрос не планируется покрывать, но нужно мягко и полезно отвечать;
• unsafe_question_limit_strictly — вопрос рискованный, на него нужно отвечать осторожно и ограниченно;
• bad_test_case — сам тестовый вопрос мусорный / нерелевантный;
• needs_routing_extension — нужен новый маршрут или расширение маршрутизации;
• needs_capability_registry_update — кейс выявил дыру в файле возможностей;
• needs_dialog_policy_fix — маршрут, возможно, не нужен, но политика ответа плохая.

Вот это уже даст системе смысл.

Если хочется совсем по-простому

Можно ввести более короткий список:

• Отрабатывается
• Должно отрабатываться
• Не будет отрабатываться
• Отвечать мягким ограничением
• Высокорисковый вопрос
• Плохой тест-кейс

Но я бы всё-таки оставил более инженерный набор, а в UI уже сделал человекочитаемые названия.

---

3. Нужен канонический файл возможностей ассистента

Да, это обязательно. И это должен быть не просто текстовый файл “что умеем”. Это должен быть Capabilities Registry / Supported Routes Registry.

И он должен быть источником истины для трёх вещей:

• ответа ассистента;
• классификации покрываемости;
• автопрогонов и анализа.

Что там должно быть

Для каждого маршрута / домена:

• код маршрута;

• человекочитаемая группа;

• краткое описание;

• что реально умеется;

• что не умеется;

• обязательные параметры;

• типовые формулировки вопросов;

• похожие смежные сценарии;

• безопасные альтернативы;

• подсказка, где это обычно смотреть в 1С;

• уровень риска;

• статус зрелости:

  • production-ready
  • partial
  • planned
  • deprecated

Пример групп

Не надо сразу показывать всё пользователю. Надо хранить глубоко, а наружу отдавать по группам.

Например:

• НДС
• Контрагенты
• Задолженности
• Деньги и остатки
• Платежи и движения
• Аналитика по периодам
• Справочные бухгалтерские вопросы

А дальше уже внутри группы:

• что умеется конкретно.

То есть если юзер спрашивает “что ты можешь по НДС?”, ассистент отвечает не списком из 80 пунктов, а компактной группой возможностей по НДС.

---

4. Надо отдельно зафиксировать правило раскрытия возможностей

Это тоже очень важный продуктовый момент.

Ассистент не должен

• автоматически вываливать весь список поддерживаемого;
• отвечать каталогом без запроса;
• перегружать пользователя техническими деталями маршрутов.

Ассистент должен

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

То есть: “Могу помочь с НДС, остатками и движением денег, контрагентами и задолженностями, а также с частью аналитики по периодам. Если хочешь, могу уточнить отдельно по любому из этих блоков.”

А уже потом: “По НДС могу показать суммы, динамику по периодам, сверку по организации, сравнительные разрезы...”

---

5. Нужен отдельный тип разметки: «вопрос хороший, но ещё не покрыт»

Это, по сути, мост между автопрогоном и roadmap.

То есть если в прогоне всплыл вопрос:

• он адекватный;
• он реально нужен;
• пользователь его точно задаст;
• сейчас он не покрыт,

то это не просто “ответ плохой”. Это кандидат на новый маршрут / на расширение текущего покрытия.

Поэтому в ручной разметке должен быть отдельный флаг:

• candidate_for_implementation или
• planned_route_gap

Именно его потом должен видеть Codex и дальше использовать как список задач на развитие.

---

6. Надо разделить две разные проблемы

Сейчас у тебя в одном описании смешаны две вещи, а их лучше развести.

Проблема 1. Функциональное покрытие

Что система реально умеет по данным и маршрутам.

Проблема 2. Поведенческая зрелость

Как система ведёт себя, когда вопрос:

• вне покрытия;
• частично в покрытии;
• опасный;
• слишком общий;
• смежный;
• абстрактный.

То есть даже если маршрут не реализован, поведение всё равно может быть:

• хорошим;
• плохим;
• опасным;
• слишком техническим;
• бесполезным.

И автопрогоны должны это различать.

---

Ниже — готовая мини-ТЗшка для Codex

Мини-ТЗ: эталон поведения ассистента, ручная разметка прогонов и канонический файл возможностей

Цель

Доработать систему автопрогонов бухгалтерского ассистента так, чтобы она оценивала не только качество конкретного ответа, но и соответствие эталонному поведению ассистента, а также позволяла вручную размечать судьбу вопроса: покрывается, должен быть отработан, не будет отрабатываться, должен обрабатываться мягким ограничением, требует нового маршрута или требует доработки политики ответа.

---

1. Ввести отдельную сущность: Assistant Behavior Canon

Нужен канонический блок, описывающий эталонную работу ассистента.

Требования

Создать отдельную структуру/файл, который будет использоваться:

• в логике ответа ассистента;
• в пост-анализе автопрогонов;
• в интерфейсе разметки прогонов;
• в дальнейшей работе Codex по развитию маршрутов и поведения.

В Assistant Behavior Canon зафиксировать:

1.1. Поведение на покрытых кейсах

• отвечать уверенно и по существу;
• не уходить в лишние оговорки;
• не использовать технические внутренние формулировки.

1.2. Поведение на частично покрытых кейсах

• явно разделять, что ассистент может сделать, а что нет;
• не маскировать ограничения;
• предлагать полезное продолжение.

1.3. Поведение на непокрытых, но близких кейсах

• не выдумывать поддержку функциональности;
• мягко и по-человечески объяснять ограничение;
• предлагать ближайший поддерживаемый сценарий;
• при уместности подсказывать, где это обычно посмотреть в 1С.

1.4. Поведение на высокорисковых вопросах

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

1.5. Поведение при вопросе “что ты умеешь”

• не вываливать весь список возможностей сразу;
• раскрывать возможности по крупным группам;
• углубляться только после уточнения;
• использовать человекочитаемые продуктовые группы, а не внутренние названия маршрутов.

---

2. Ввести канонический файл возможностей ассистента

Нужен отдельный реестр отработанных возможностей ассистента по маршрутам 1С.

Назначение

Этот файл является источником истины для:

• определения покрытия вопроса;
• ответа ассистента на вопросы о своих возможностях;
• similarity-логики;
• автопрогонов и пост-анализа;
• Codex при дальнейшем развитии маршрутов.

Для каждого маршрута / домена хранить:

• route_code
• group_code
• group_title
• title
• description
• supported_operations
• unsupported_operations
• required_entities
• optional_entities
• typical_queries
• related_routes
• safe_alternatives
• one_c_hints
• risk_level
• maturity_status (production_ready, partial, planned, deprecated)

Требования к пользовательскому раскрытию возможностей

Ассистент должен уметь:

• сначала показывать верхнеуровневые группы;
• по запросу раскрывать детали внутри выбранной группы;
• не использовать длинные технические перечни без необходимости.

---

3. Доработать интерфейс автопрогонов: ручная управленческая разметка

Существующую 5-балльную оценку оставить, но дополнить отдельной выпадающей ручной классификацией результата прогона.

Добавить новое поле:

manual_case_decision

Возможные значения:

• covered_ok
• covered_but_bad_answer
• candidate_for_implementation
• needs_routing_extension
• out_of_scope_but_answer_softly
• unsafe_question_limit_strictly
• needs_dialog_policy_fix
• needs_capability_registry_update
• bad_test_case

Смысл значений

• covered_ok — кейс уже покрыт, поведение нормальное;
• covered_but_bad_answer — кейс покрывается, но ответ/диалог плохой;
• candidate_for_implementation — хороший пользовательский кейс, которого пока нет, его стоит брать в разработку;
• needs_routing_extension — нужен новый маршрут или расширение существующего;
• out_of_scope_but_answer_softly — кейс не планируется покрывать, но нужен качественный мягкий ответ без техничности;
• unsafe_question_limit_strictly — кейс относится к рискованным, и ассистент должен ограничивать себя особенно строго;
• needs_dialog_policy_fix — проблема не в маршруте, а в стиле/логике ответа;
• needs_capability_registry_update — реестр возможностей неактуален или недостаточно формализован;
• bad_test_case — вопрос мусорный, нерелевантный или бесполезный для развития системы.

Дополнительно

Для каждой ручной метки предусмотреть:

• короткий комментарий;
• автора разметки;
• timestamp;
• возможность использовать эту разметку в пост-анализе и отборе задач для Codex.

---

4. Доработать логику пост-анализа прогонов

После прогона система должна уметь отделять:

• ошибки покрытия;
• ошибки маршрутизации;
• ошибки политики ответа;
• хорошие, но ещё не покрытые кейсы;
• мусорные тест-кейсы;
• высокорисковые кейсы;
• кейсы на обновление файла возможностей.

На выходе пост-анализа нужны агрегаты:

• список кейсов на доработку маршрутов;
• список кейсов на доработку policy;
• список кейсов на обновление capabilities registry;
• список кейсов, которые сознательно не будут покрываться, но требуют мягкого ограничения;
• список кейсов, пригодных для новых regression suites.

---

5. Встроить связь между ручной разметкой и дальнейшей работой Codex

Codex должен видеть не только сам диалог и оценку, но и управленческое решение по нему.

Требование

При выгрузке данных для дальнейшего анализа и доработок обязательно передавать:

• question / dialog trace;
• current route / current coverage decision;
• 5-балльную оценку;
• manual_case_decision;
• комментарий аналитика;
• ссылку на ближайший домен из capabilities registry;
• признак: нужно ли брать кейс в маршрутную отработку.

Ожидаемое поведение

Если кейс помечен как:

• candidate_for_implementation или needs_routing_extension — Codex рассматривает его как материал для новой/расширенной маршрутной логики;
• out_of_scope_but_answer_softly — Codex улучшает не маршруты, а policy-слой ответа;
• needs_capability_registry_update — Codex актуализирует реестр возможностей;
• unsafe_question_limit_strictly — Codex усиливает безопасное поведение и ограничения;
• covered_but_bad_answer — Codex чинит существующий покрываемый сценарий, а не создаёт новый.

---

6. Добавить в эталон обязательное правило минимизации технических ответов

Это отдельное критичное требование.

Ассистент не должен

• отвечать внутренними техническими терминами;
• ссылаться на отсутствие маршрута, домена, интента, пайплайна, классификатора;
• создавать ощущение поломки системы.

Ассистент должен

• говорить естественно;
• объяснять ограничения человеческим языком;
• сохранять полезность даже при отказе;
• ориентировать пользователя в доступных соседних возможностях.

---

7. Добавить в эталон обязательное правило сегментированного раскрытия возможностей

Если пользователь спрашивает:

• “что ты умеешь?”
• “что можешь по НДС?”
• “что можешь по остаткам?”
• “что умеешь по деньгам / поставщикам / задолженностям?”

ассистент должен отвечать через иерархию:

Уровень 1

Крупные продуктовые группы:

• НДС
• Контрагенты
• Задолженности
• Деньги и остатки
• Движение и платежи
• Аналитика по периодам
• Справочные бухгалтерские вопросы

Уровень 2

Уточнение по выбранной группе:

• что внутри группы реально доступно;
• какие ограничения есть;
• что можно сделать следующим шагом.

Уровень 3

Точечный ответ по конкретному запросу.

---

8. Критерии приёмки

1. В системе появился отдельный канонический блок эталонного поведения ассистента.
2. Появился отдельный файл/реестр возможностей по маршрутам 1С.
3. В UI автопрогонов добавлена ручная управленческая разметка результата.
4. Ручная разметка сохраняется в логах и участвует в пост-анализе.
5. Система умеет отделять “не покрыто, но стоит реализовать” от “не покрыто и не планируется, но нужно мягко отвечать”.
6. Ассистент перестаёт отвечать внутренним техническим языком на границе покрытия.
7. Ассистент умеет раскрывать свои возможности по группам, а не полным списком.
8. Codex получает достаточно данных, чтобы понимать, что чинить: маршрут, policy, capabilities registry или сам тест-кейс.

---

Что я бы ещё добавил от себя

Я бы прямо выделил в ТЗ отдельный артефакт:

assistant_canon.md

В нём:

• идеал поведения;
• анти-паттерны;
• примеры хороших ответов;
• примеры плохих ответов;
• правила раскрытия возможностей;
• правила мягкого ограничения;
• правила поведения на рискованных вопросах.

И отдельно:

capabilities_registry.json

или capabilities_registry.yaml

И ещё:

manual_case_decision_schema.json

Чтобы UI и пост-анализ работали по одному словарю значений.

---

Если совсем коротко, в чём суть

Тебе сейчас нужен не просто “ещё один контрол в модалке”, а вот такая конструкция:

Эталон ассистента → задаёт идеальное поведение

Файл возможностей → задаёт фактическое покрытие

Ручная разметка кейса → задаёт управленческое решение, что с этим вопросом делать дальше

Codex → уже понимает, нужно ли:

• чинить ответ,
• расширять маршрут,
• обновлять capabilities,
• улучшать мягкий отказ,
• или вообще выкинуть тест-кейс.

Если хочешь, я следующим сообщением могу собрать это ещё в более прикладной форме: короткое ТЗ на 30–40 строк для прямой отправки в Codex, без пояснений и лирики.