Добавлена карточка «Guard (условие перехода)» в раздел терминов:
формат JSON, описание полей, пример require_legal_rep из new_booking.
Guard добавлен в список защитных механизмов. Обновлён callout статуса.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- check_guards() в state_machine.py: проверяет guards_json шага при переходе;
trigger_slot/trigger_value/required_slots; нормализует "true"/"false"-строки
- qualify step: guard require_legal_rep — блокирует переход в present, если
is_child=true и не заполнены legal_rep_name / legal_rep_phone
- Промпт qualify обновлён: инструкции по is_child, legal_rep, requested_doctor,
waitlist_flag, needs_surgologist_first
- ensure_seed_guards() патчит guards_json существующих шагов при старте
- Sandbox: блок валидации показывает guard_name + missing_slots + description
- Settings: обновлён лейбл поля guards с примером формата
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Бейджи в Песочнице:
- Каждый бейдж теперь с русским префиксом-меткой (ветка/шаг/роутер предложил/решение/тип ответа)
- Тег «многошаговая» на бейдже ветки при is_state_machine или наличии step_code
- Шаг: сначала русское название, потом код в скобках (Повод и специалист (qualify))
- get_thread_detail обогащает старые meta: подтягивает step_name и is_state_machine из БД
Документация:
- «Удержание в ветке» — пошаговый разбор sticky-механизма, явно что не второй роутер
- Новая карточка «Боковой вопрос (soft_insertion)» — откуда берётся, счётчик, nudge
- Блок под схемой «Что происходит на каждой реплике»: почему бейджи на ответах ассистента
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Добавлена /docs.html — обзор мультиагентной системы для оператора. Все
термины в формате «русский (english)», жирным: ветка (intent), маршрутизатор
(router), пошаговый сценарий (state machine), шаг (step), допустимые
переходы (allowed_next), слоты (slots), условия выхода (exit conditions),
переключение ветки (hard handoff), удержание в ветке (sticky state machine),
структурированный ответ (structured output), отложенный сценарий
(suspended/resume), защита от петли (routing loop guard), состояние диалога
(thread state). Плюс пошаговая схема обработки реплики и резюме защитных
механизмов. Ссылка «Документация» добавлена в шапку всех страниц.
Унификация заголовков под стиль «Версии» в правом сайдбаре Настроек: убран
uppercase, переход на 13px / var(--fg) / font-weight 600 / зажатый
letter-spacing. Применилось к .col-head во всех колонках, .field label в
редакторе, .section-header в списке веток, заголовкам столбцов на странице
Отладки и заголовкам секций RAG-результата. Бейджи (АКТИВНАЯ, система)
оставлены прежними — это статусные метки, не заголовки.
Переименование ветки escalate_human для согласованности с русским UI:
«Эскалация на оператора» → «Перевод на оператора», описание тоже. Точечная
миграция при старте (intent_service.migrate_intent_copy) обновляет
существующие записи в БД, только если поле в точности совпадает со старым
значением — операторские правки не затираются.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Блок A2: вынос условий выхода из основного промпта в отдельное поле
agent_configs.exit_conditions_text. compose_full_system_prompt склеивает
system_prompt + rules_text + exit_conditions_text перед отправкой в модель.
Одноразовая миграция данных при старте: пытаемся выделить блок «Условия
выхода» из хвоста существующих system_prompt-ов и перенести в новое поле
(поддерживаются три формы заголовка: «## Условия выхода», «**Условия
выхода**», просто «Условия выхода:»). В UI «Настройки» — третья textarea
с подсказкой ⓘ на отдельной кнопке.
Блок B: защита от петель маршрутизации (v2 §4.3). В thread_state добавлена
колонка handoff_count, инкрементируется на каждом hard-handoff: либо когда
роутер переключает не-sm-ветку (state reset), либо когда sm-ветка сама
выдаёт [INTENT_CHANGE: …] (bouncing). При превышении HANDOFF_CAP=3 диалог
автоматически уводится в escalate_human с шаблонным ответом «Уточню детали
с администратором клиники, свяжемся с вами в течение ближайшего часа», LLM
не вызывается, handoff_count сбрасывается. В Песочнице видны счётчик
«переключений ветки в диалоге» и красная плашка при срабатывании защиты.
Также пофикшен баг: для не-sm-веток snapshot.current_intent_code теперь
финализируется на served_code, иначе на следующей реплике prev_intent_code
терялся и handoff_count не считался.
Блок C: suspended_intent / resumable_step_code / resumable_slots_json в
thread_state (v2 §4.4). При hard-handoff из sm-ветки через [INTENT_CHANGE]
текущий сценарий запоминается (если suspended ещё не занят). Когда роутер
на следующих репликах возвращает intent = suspended_intent — RESUME:
восстанавливаем current_intent_code, current_step_code, slots; suspended_*
очищается, handoff_count=0. Возврат имеет приоритет над sticky-логикой.
В Песочнице — синяя плашка «📌 отложен сценарий X (шаг Y)» во время detour'а
и зелёная «↩️ возврат к отложенному сценарию» в момент resume. Routing-loop
guard и роутер-driven handoff не теряют suspended (только при authoritative
сценариях вроде эскалации он сбрасывается).
Прогон вручную: detour из new_booking/qualify в price_question и обратно
восстанавливает name=Алексей, reason=болит ухо на исходном шаге.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Заменили строковый тег [STATE: ...] из Спринта 5 на структурированный выход
ветки в виде JSON-блока в хвосте ответа: {state_after, slots_updated}, парсимый
балансировкой скобок. Шаги state machine вынесены из монолитного промпта в
таблицу intent_steps (intent_id FK, code, name, order_index, system_prompt,
allowed_next JSON, guards JSON) и редактируются через UI. Валидатор переходов
сверяет state_after с allowed_next и блокирует невалидные прыжки.
Базовый промпт new_booking разбит на base + 6 файлов шагов (intro/qualify/
present/offer_time/book/close), которые сидятся при старте через
ensure_seed_steps. В chat_service промпт собирается как base + step + блок
[ТЕКУЩЕЕ СОСТОЯНИЕ].
Попутно реализован мини-блок G (sticky state machine): когда диалог идёт по
sm-ветке и роутер на новой реплике предлагает другую — state НЕ сбрасывается,
в системный промпт ветки подаётся блок [ПОДСКАЗКА РОУТЕРА], LLM сама решает
(STATE_JSON или INTENT_CHANGE). Это сняло ключевую дыру Спринта 5: «Меня
зовут Алексей» / «болит ухо» внутри записи больше не сбрасывают сценарий.
Промпт ветки new_booking ужесточён: бытовые жалобы — это повод записи (слот
reason + сочувствие), не повод уводить в medical_question. Шаг present теперь
использует reason в формулировке. Промпт _router расширен живыми примерами
для всех 6 веток, особенно для reschedule («не смогу подойти», «перенесите»).
Надёжность внешнего LLM:
- ретрай в LLMClient с паузой 500 мс + новое исключение LLMUnavailableError;
- ретрай в RouterClient (DeepSeek периодически моргает);
- /chat при ошибке делает session.rollback() и возвращает 503 с понятным
сообщением — больше не остаётся «диалогов-призраков» с одной репликой;
- UI убирает свой пузырь и возвращает текст в поле ввода для повторной отправки.
UI «Настройки» — добавлена вкладка «Шаги» для веток с state machine: список
шагов chip-ами, редактор промпта/имени/allowed_next/guards, сохранение через
PATCH /intents/{code}/steps/{step_code} без версионирования. Иконка ⓘ возле
поля «Правила» открывает popover с пояснением, что туда писать.
UI «Песочница»:
- блок «Состояние диалога» показывает имя шага из intent_steps (а не сырое
число), для не-sm-веток пишется «без пошагового сценария»;
- подсветка illegal-переходов (валидатор отклонил state_after) и parse_error
для sm-веток;
- блок «Решение роутера» развёрнут в три исхода: «попал в ту же ветку» /
«удержались в ветке» / «ветка сама передала управление через INTENT_CHANGE»;
- секция «Найденные фрагменты» сворачивается, карточки чанков раскрываются
по клику — правый сайдбар стал компактнее.
Терминология (по договорённости — простой русский в UI):
- «тред» → «диалог» в текстах для оператора (в коде/API thread_id оставлен);
- «sticky state machine» → «удержались в ветке»;
- «state machine» → «пошаговый сценарий» в видимых местах.
SPRINTS.md: блок G в Спринте 6b сокращён — sticky-логика уже сделана здесь,
осталась только вторая линия (передача thread_state в системный промпт самого
роутера для ещё более точной первичной классификации).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Добавлен GRAPH_ARCHITECTURE_v2.md (уточнения v1 после анализа скрипта записи в
вике клиники: различение soft-insertion и hard-handoff, защита от петель через
handoff_count, resumable state, guards в new_booking, подписка ветки на разделы
вики как альтернатива отдельным коллекциям Chroma, per-step RAG, eval-набор до
Спринта 5, разбивка Спринта 5 на 5a/5b).
SPRINTS.md переработан:
- Спринт 5 закрыт как «ядро v1» с явным списком того, что не вошло из v2.
- Спринт 6 разбит на 6a (структурированный выход + intent_steps + валидатор
переходов + exit_conditions_text + handoff_count + suspended/resumable) и 6b
(soft-insertion + guards + reason в escalate_human + умный роутер + 8 ручных
сценариев).
- В каждом блоке — UI-чекпойнт и явное «что проверяем глазами», чтобы можно
было смотреть результат после каждого шага, а не в конце спринта.
- Мульти-RAG (Спринт 7) делается до мини-eval (Спринт 8), чтобы наборы в eval
проверяли поведение уже с per-intent retrieval.
- Зафиксированы 4 принятых решения: момент обновления current_step, cap на
soft-insertion, сверка шагов new_booking с вики, формат структурированного
выхода — JSON-блок в хвосте ответа.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Таблица thread_state (intent, step, slots) ведётся per-thread. В системный
промпт ветки дописывается текущее состояние, LLM возвращает служебный тег
[STATE: step=N; slots={...}] после основного ответа — парсер в chat_service
вырезает его и обновляет состояние. Если ветка решила, что тема ушла в другую,
она выдаёт [INTENT_CHANGE: code] — делаем один повторный вызов LLM с новой
веткой и сброшенным state (bouncing, MAX_BOUNCES=1). Если роутер сам выбрал
другую ветку, чем в thread_state, — state тоже сбрасывается. Промпт new_booking
переписан под 6-шаговый сценарий (имя → повод → специалист → время → подтверждение
→ запись), в «Песочнице» появился блок «Состояние треда» с intent/step/slots
и списком переходов.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Первый шаг графовой архитектуры из GRAPH_ARCHITECTURE.md. Заменили
«один активный промпт на всё» на «свой промпт на каждую ветку +
роутер выбирает ветку на каждой реплике».
Данные:
- Новая таблица intents (code, name, description, is_enabled,
order_index). Коды с префиксом `_` — системные (не responder).
- В agent_configs добавлен intent_id (nullable, FK SET NULL); убрана
глобальная уникальность version, вместо неё UniqueConstraint
(intent_id, version) — у каждой ветки свой счётчик версий.
- В messages добавлен intent_id (nullable, FK) — фиксируем, какую
ветку выбрал роутер для каждой реплики.
- Миграция cd0a88ef9080 в batch-режиме (SQLite не умеет ALTER для
constraints напрямую).
Сид:
- Стартовые 7 веток: new_booking, reschedule, price_question,
medical_question, general_info, escalate_human + `_router` как
системная ветка для промпта классификатора.
- Для каждой ветки — свой v1-промпт из prompts/intents/{code}.md.
- migrate_legacy_config_to_general_info: старый v1 из Спринта 3
(без intent_id) переносится на general_info с сохранением версии.
- ensure_seed_intents досиживает недостающие коды, существующие не
трогает — безопасно при добавлении новых веток.
Оркестрация и роутер:
- services/router_client.RouterClient — отдельный класс от LLMClient
(под будущую смену модели на более дешёвую). Метод classify(session,
history, text) возвращает {code, version}. Промпт классификатора
подтягивается из активного конфига ветки `_router`, fallback —
prompts/intents/_router.md. При сомнении/ошибке возвращает
general_info.
- services/chat_service.send_message теперь идёт через router.classify
→ берёт активный конфиг выбранной ветки → llm.chat. В сообщения
пишется intent_id, в треде фиксируется начальный agent_config_id.
В ответе — intent_code, intent_name, config_version, router_version.
API:
- GET /intents, GET /intents/{code}, PATCH /intents/{code} —
список веток со счётчиком версий, получение и переключение
is_enabled.
- /configs теперь требует intent_code как Query-параметр
(GET /configs, GET /configs/active) — выборка версий в рамках
ветки. POST /configs принимает intent_id.
- get_thread_detail JOIN-ит Intent — каждая реплика возвращает
intent_code + intent_name.
UI:
- settings.html переработан в 3-колоночный макет: слева список веток
с подгруппой «Системные» для `_router` (пометка «система» вместо
свитча), в центре редактор промпта/правил активной версии выбранной
ветки, справа список версий с активировать/удалить/загрузить.
Каждая ветка редактируется независимо — своя история версий,
своя активная.
- sandbox.html: у каждой реплики бейдж с intent_code, в отладке новый
блок «Решение роутера» (подсвеченный зелёным) с названием ветки,
версией её активного конфига и версией промпта роутера. Старый
«активная: v1» индикатор убран — он больше не имеет смысла (активная
у каждой ветки своя).
E2E проверено: разные реплики уходят в корректные ветки, каждая
отвечает по своему узкому промпту, промпт роутера редактируется в UI
как v2/v3 и откатывается — классификация сразу использует новую
версию.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
После Спринта 3 и обсуждения с пользователем зафиксирован разворот
на графовую архитектуру (GRAPH_ARCHITECTURE.md, коммит 907fdbe).
Обновляем SPRINTS.md под новое направление.
Статусы закрытых спринтов уже стояли ✅; здесь главное — план 4–7:
- Вставлена секция «Архитектурный разворот после Спринта 3» сразу
после Спринта 3. В ней зафиксированы принятые решения по 5
открытым вопросам из GRAPH_ARCHITECTURE.md: фреймворк (вручную,
без LangGraph/n8n), модель роутера (DeepSeek + отдельный
RouterClient), exit conditions (свободный текст + роутер на каждой
реплике как подстраховка), эскалация (одна ветка escalate_human с
полем reason), confidence score (не в первый спринт).
- Старые Спринт 4 (сценарии) и Спринт 5 (экспорт) заменены новыми
четырьмя спринтами:
- Спринт 4. Фундамент графа — intents + роутер + переключение веток.
Задачи: таблица intents, миграция agent_configs с intent_id, seed
6 стартовых веток, router_client, оркестрация в chat_service,
UI настроек по веткам, отображение intent в отладке Песочницы.
- Спринт 5. State machine + exit conditions (bouncing). Первая
реальная state machine — в ветке new_booking (6 шагов). Парсер
[INTENT_CHANGE: ...] + роутер на каждой реплике как подстраховка.
UI показывает состояние треда и timeline переходов.
- Спринт 6. Мульти-RAG. Фабрика коллекций в vectorstore, привязка
коллекции к intent, селектор ветки при загрузке документа.
- Спринт 7. Сценарии + экспорт графа. Старый план, но адаптирован:
сценарии фиксируют ожидаемый intent на реплику; экспорт —
снапшот всего графа (intents + активные промпты + коллекции).
- Бэклог дополнен: confidence score, визуализация графа, вынесение
роутера на более дешёвую модель, структурированные exit conditions.
Пункт про «раздельные правила по доменам» помечен как перекрытый
архитектурой.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Фиксируем направление, в которое движется проект после пилота
Спринтов 1–3. Перепланировка спринтов будет сделана отдельно.
Ключевая идея: отказаться от «мега-промпта», где один системный
промпт знает про всё (запись, перенос, цены, ДМС, детский приём,
хирургию), и перейти на graph-based routing — входная реплика идёт
через LLM-роутер, который определяет намерение и передаёт диалог в
узкую изолированную ветку со своим промптом, своей базой знаний и
своим шагом state machine. Роутер продолжает незримо присутствовать
в диалоге и перекидывает тред между ветками, когда срабатывают
exit conditions (пациент меняет тему на лету).
Документ описывает:
- Почему мега-промпт перестаёт работать по мере роста сценариев.
- Роутер как отдельный дешёвый вызов LLM на каждой реплике.
- Узкие ветки (new_booking, reschedule, surgery, medical_question,
general_info, escalate_human).
- State machine внутри ветки с хранением шага и собранных слотов.
- Exit conditions и bouncing между ветками через служебные сигналы
модели ([INTENT_CHANGE: ...]).
- Передача человеку не как «сброс», а как квалификация лида с
полным контекстом.
- Что меняется в данных (таблицы intents, thread_state, routing_log;
agent_configs привязывается к intent_id; несколько RAG-коллекций).
- Что меняется в UI (Настройки по веткам; в Песочнице виден
текущий intent, шаг, история переходов).
- Открытые вопросы: фреймворк оркестровки (LangGraph/n8n или
вручную), выбор модели для роутера, формат exit conditions,
граница бот/человек по хирургии, работа с уверенностью.
Направление подтверждает memory-записку project_future_architecture
от 2026-04-23 (мульти-пользователи, мульти-промпты, несколько
специализированных RAG + RAG-маршрутизатор) и детализирует её.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Операторы получают веб-редактор: правят системный промпт и правила,
сохраняют как новую версию, активируют, откатываются. Активная версия
используется в «Песочнице» на каждый /chat.
Принципы, согласованные заранее:
- Сохранённые версии не редактируются — только создание новой. Честный
откат: v1 всегда та же, что была при создании.
- Правила на этом этапе — свободный markdown (textarea). Переход на
структурированные правила (pattern → instruction) — в бэклог.
- Файл prompts/system_prompt.md становится сид-источником: при первом
старте, если таблица agent_configs пустая, из него создаётся v1 и
активируется. Дальше правда идёт из БД, файл не трогаем.
- rules_text конкатенируется с system_prompt в один system-message
через compose_full_system_prompt: "{prompt}\n\nДополнительные
правила:\n{rules}".
- Активную версию удалить нельзя — сначала активируют другую.
Модель и миграция:
- db/models/AgentConfig: id, version (unique/indexed), name (nullable),
system_prompt, rules_text, is_active (indexed), created_at.
Без updated_at — версии неизменяемы.
- Миграция b4450e33664d_add_agent_configs_table.
Сервисы и роутеры:
- services/config_service: ensure_seed (seed v1 из файла),
list/get/get_active/create (version=max+1, при activate атомарно
сбрасывает is_active у остальных и ставит новой),
activate_config (та же схема), delete_config (возвращает причину
отказа: not_found / active), compose_full_system_prompt.
- services/chat_service.send_message: берёт active_cfg, собирает
system_prompt через compose_full_system_prompt, пишет
thread.agent_config_id при создании треда (колонка была nullable
ещё со Спринта 2 — пригодилась именно здесь).
- routers/configs: GET /configs, GET /configs/active, GET /configs/{id},
POST /configs (activate-флаг), POST /configs/{id}/activate,
DELETE /configs/{id} (404 / 400 если активная).
- Pydantic: AgentConfigCreateRequest, AgentConfigInfo, ListResponse,
DeleteResponse.
- main.py: ensure_seed в lifespan после инициализации БД/Chroma/LLM.
UI:
- static/settings.html — трёхблочная страница: имя версии, textarea
промпта, textarea правил, «Сохранить как новую» + галка
«Сразу активировать», «Загрузить активную в редактор». Справа —
список версий с бейджем «активная», действиями «Активировать» /
«Удалить» (disabled у активной) / «Загрузить в редактор». При
первом заходе активная версия автоматом подгружается в редактор.
- В nav на index.html и sandbox.html добавлена ссылка «Настройки».
- В шапке «Песочницы» — зелёный кликабельный бейдж «активная: vN · имя»
(ведёт на /settings.html), обновляется раз в 15 с.
E2E проверено: создана v2 с правилом «ВСЕГДА начинай со слов СПАСИБО
ЗА ВОПРОС», активирована; следующий /chat вернул ответ, начинающийся
ровно с этой фразы; assembled_prompt содержит блок «Дополнительные
правила». После отката на v1 тест-v2 удалена.
SPRINTS.md: Спринт 3 помечен закрытым.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
README переписан под текущее состояние — был TBD со времён init:
- Статус: Спринты 1–2 и доработки (2.5) закрыты, что именно уже
работает (RAG, многошаговый диалог, переиндексация, две страницы).
- Запуск: команды для установки, старта, ручного наката миграций и
создания новых. Автомиграции на старте отмечены.
- Использование: табличка API-эндпоинтов (/documents, /query, /chat,
/threads, /reindex), описание двух веб-страниц и правки системного
промпта через prompts/system_prompt.md.
- Структура: актуальное дерево директорий с назначением каждого
модуля (db/, prompts/, routers/, services/, static/).
SPRINTS.md: Спринт 2.5 помечен закрытым — все пять задач пройдены
(логи, системный промпт в файле, markdown-рендер, чистка чанков +
reindex, README).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Чанкер тащил в базу markdown-мусор: навигационные блоки «Вернуться на:»
со списками ссылок, инлайн-ссылки [текст](url) в теле, служебные
пометки _Источник: .../file.md_, лишние пустые строки. Всё это ело
контекст LLM и засоряло правую панель отладки.
- services/text_cleanup: clean_markdown_text — удаляет навигационные
строки, строки-только-ссылки (обычно это меню), служебные _Источник:_,
раскрывает инлайн-ссылки [x](url) → x, сжимает 3+ переносов до 2.
- services/document_processor: process_document теперь возвращает
(id, raw_text, sections, chunks); чистку применяем к заголовкам и
телам секций; чанки короче 20 символов выбрасываем с пересчётом
индексов. Вспомогательная rechunk_raw_text — для переиндексации.
Чтобы переиндексировать без повторной загрузки файла, нужен исходный
текст. Вводим отдельный слой:
- новая таблица SQLite documents (id, name, file_type, raw_text,
created_at, updated_at) + миграция Alembic 7ee7296ccd6d.
- db/models/Document + регистрация в db.models.__init__.
- services/document_service: save/get/list/delete для raw_text.
- routers/documents.upload: сохраняет raw_text в SQLite перед
индексацией в Chroma; delete убирает и из SQLite, и из Chroma.
- Новые эндпоинты POST /documents/{id}/reindex и
POST /documents/reindex-all — берут raw_text из SQLite, пропускают
через rechunk_raw_text, заменяют чанки в Chroma.
Существующие 4 документа были перезалиты вручную (решение: не делать
одноразовый backfill, проще залить заново). Старая Chroma очищена,
новые чанки прошли через чистку — мусор ушёл.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Три подряд доработки по плану Спринта 2.5.
1) Логи. Проблема: uvicorn ставит handlers на root-logger до того, как
отработает наш lifespan, поэтому logging.basicConfig там был no-op, и
logger.exception ничего не писал. Переносим basicConfig на уровень
импорта main.py с force=True — наш StreamHandler перебивает
uvicorn-овский root, остальные логгеры (uvicorn.access, uvicorn.error,
alembic, chromadb) остаются со своими форматами. В lifespan
basicConfig больше не зовётся.
2) Системный промпт вынесен из services/llm_client.py в
prompts/system_prompt.md. LLMClient читает файл при импорте модуля
через _load_system_prompt(); если файла нет — пустая строка + warning.
Это задел под Спринт 3, где промпт будет редактируемым и
версионируемым — физически положить его как файл дешевле, чем
держать в исходниках.
3) Markdown в ответах ассистента. Подключены marked и DOMPurify с
CDN в sandbox.html. Рендер через renderMd(text): marked.parse +
DOMPurify.sanitize — защищает от <script> на случай, если LLM вернёт
сырой HTML. Реплики пациента остаются plain text (esc). Добавлены
стили для p/ul/ol/code/pre/a/h1-h3/blockquote внутри .msg.assistant,
чтобы всё выглядело уместно в пузыре. Обёртка msg-body введена,
чтобы разделить контент и msg-meta.
План в SPRINTS.md уточнён по переиндексации — будет отдельный
endpoint.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
По итогам Спринтов 1–2 накопился технический долг и несколько косяков,
которые видно при живой работе в «Песочнице». Выделяем промежуточный
спринт-доработок перед заходом на Спринт 3:
- Качество RAG: чанкер тащит в базу markdown-ссылки, блоки навигации
вроде «Вернуться на:», дубликаты меню — из-за этого в LLM уходит
мусор вместо полезного контекста.
- UI: ответ ассистента рендерится plain text с сырыми ** и дефисами
списков — в чате это читать тяжело.
- Системный промпт зашит в services/llm_client.py — перед Спринтом 3
(редактор промпта) его логично вынести в отдельный файл.
- Логи: logger.exception сейчас съедается конфигом uvicorn, traceback
при 500-х не виден — диагностика вслепую.
- README не обновлялся с init-коммита, не отражает ни Спринта 1, ни 2.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Завершающий кусок Спринта 2 — UI для ведения диалогов.
static/sandbox.html:
- Трёхколоночная раскладка во всю высоту экрана.
- Слева: список сохранённых диалогов (имя, дата последнего обновления,
счётчик сообщений, превью первой реплики), кнопка «+ новый»;
на каждой карточке — «переименовать» (prompt) и «удалить» (confirm).
- Центр: чат в привычной стилистике (пузыри, user справа, assistant
слева), Enter — отправить, Shift+Enter — перенос строки. Заголовок
сверху показывает имя активного треда.
- Справа: отладка ответа — найденные фрагменты со score в процентах
+ собранный промпт в моноширинном блоке на светлом фоне.
- При отправке первой реплики тред создаётся автоматически, API
возвращает thread_id и thread_name — дальше реплики уходят в тот
же тред.
static/index.html: в шапке добавлены ссылки «Отладка» / «Песочница»,
подсветка активной страницы; тот же стиль nav-ссылок продублирован
в sandbox.html.
routers/chat: detail сообщения ошибки теперь включает тип исключения
(удобнее при диагностике), trace пишется через logger.exception.
SPRINTS.md: Спринт 2 помечен как закрытый.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Второй кусок Спринта 2: агент теперь помнит контекст. RAG-retrieval
делается по последней реплике пациента, в LLM уходит системный промпт +
последние 20 сообщений треда + новая реплика + найденные фрагменты.
Backend:
- services/chat_service: send_message — создаёт тред при необходимости
(auto-имя из первой реплики + UTC-дата), сохраняет user-реплику до
вызова LLM (чтобы не потерять при сбое), делает retrieval, грузит
историю треда (desc/limit 20 → reversed для хронологии), зовёт
llm.chat, сохраняет ответ ассистента вместе с sources_json и
assembled_prompt, обновляет thread.updated_at. Плюс list_threads с
JOIN-выборкой превью первой реплики и счётчика сообщений,
get_thread_detail через selectinload, rename_thread, delete_thread
(CASCADE на FK делает уборку сообщений автоматически, но
explicit delete оставлен для подсчёта удалённых).
- services/llm_client.chat: принимает history=[{role, content}, ...],
собирает messages = [system, ...history, user-с-RAG]; assembled_prompt
дампит всю цепочку в виде [SYSTEM]/[USER]/[ASSISTANT]-блоков для
отображения в Debug UI.
- routers/chat: POST /chat, обрабатывает LookupError → 404.
- routers/threads: GET /threads, GET /threads/{id}, PATCH /threads/{id}
(переименовать), DELETE /threads/{id}.
- models: ChatRequest, ThreadRenameRequest; ChatResponse, ThreadInfo,
ThreadListResponse, ThreadDetailResponse, MessageInfo,
ThreadDeleteResponse.
Запуск:
- В lifespan main.py: автоматический alembic upgrade head через
asyncio.to_thread (сам alembic делает asyncio.run внутри, его нельзя
звать из уже работающего event loop). LLMClient инициализируется
один раз при старте — вместо создания на каждый запрос.
E2E проверено: новый тред → агент отвечает и просит представиться;
вторая реплика в том же треде — агент помнит контекст; PATCH
переименовывает; DELETE удаляет тред с каскадом на сообщения.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Расширяем просмотр документа, чтобы оператор видел не только текстовые
чанки, но и как они лежат в ChromaDB в виде векторов — по паттерну из
work-pcs-dr-cdss.
Backend:
- services/vectorstore.get_document_chunks теперь запрашивает
include=["embeddings"] и отдаёт вектор как list[float]. Chroma
возвращает numpy-массивы, поэтому проверка наличия embeddings
сделана через len(), без or-шортката.
- models.ChunkDetail: поля embedding: list[float] + embedding_dim: int.
- routers/documents прокидывает вектор и размерность в ответ.
Frontend (static/index.html):
- В карточку чанка добавлен блок .chunk-card-actions с кнопкой
«вектор (N dim)»; раскрывается в .embedding-box с полным списком
координат (округление до 6 знаков, моноширинный шрифт, скролл).
- Функция toggleChunkText переписана через .closest + querySelector,
чтобы не ломаться от новой обёртки кнопок.
- Добавлена toggleEmb(embId).
Проверено на загруженных документах — возвращается по 1024 координаты
(E5-large), совпадает с ожиданиями embedding-модели.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Уточнения к плану Спринта 2 по итогам обсуждения:
- Вторая отладочная страница /sandbox вместо расширения текущей (старый
Debug UI остаётся нетронутым).
- Все диалоги сохраняются навсегда, видны в левой колонке; можно открыть
старый тред, переименовать, удалить. Имя треда — автоматом по первой
реплике, с возможностью поменять.
- Стек хранилища: SQLite + SQLAlchemy 2.0 async + Alembic. Выбор под
будущий рост (мульти-пользователи, мульти-промпты, несколько спец-RAG).
- В таблицу threads сразу заводим nullable-колонки user_id и
agent_config_id — чтобы Спринты 3+ не тащили миграции задним числом.
- Набор эндпоинтов расширен: GET/PATCH/DELETE /threads, GET /threads/{id}.
В бэклог: хранение исходных файлов для переиндексации без повторной
загрузки.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Скоуп MVP: RAG-ядро + веб-инструмент настройки (загрузка wiki, песочница,
промпт/правила с версиями, сценарии, экспорт конфига). Интеграцию с каналами
(приложение, МАКС) делает другой разработчик.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
AR 15 M4