DeepSeek больше не даёт выбирать модель: radiogroup Instant / Expert /
Vision (div[data-model-type][role="radio"]) со страницы исчез, оставшаяся
модель универсальна и разбирает в том числе картинки. Вместе с выбором
отпали и три роли — think, search, vision, — а с ними отдельный чат под
каждую: теперь чат один.
Заодно выяснилось, что тумблеры DeepThink и Search больше не пропадают
после первого сообщения — они видны и переключаются в любом чате, в том
числе начатом. На их исчезновении держалась вся прежняя схема с чатами
под роль, так что нужда в ней отпала и по этой причине тоже.
DeepThink выключается перед каждым вопросом: он только показывает
размышления модели и раздувает ответ. Search не трогаем намеренно — это
тумблер человека: как поставлен во вкладке, так мост и спрашивает.
Попутно два бага, которые вылезли на живом прогоне:
- data-virtual-list-item-key у вопросов теперь отрицательные (-4, 2, -11,
8 для двух обменов подряд), и __firstMsg сортировкой по возрастанию
отдавал последний вопрос вместо первого. Правка уходила в чужое
сообщение. Берём порядок DOM — список рисуется сверху вниз.
- Вопрос с картинкой уходил новым сообщением в рабочий чат и ломал
уговор «в чате ровно один обмен», на котором держится правка первого
сообщения. После такого чат оставался из двух обменов, и наружу
отдавался ответ на предыдущий вопрос. Теперь картинка всегда открывает
новый чат, а старый удаляется как обычно.
Снаружи: /api/tags отдаёт одну модель deepseek:chat, имя присланной
клиентом модели не смотрится вовсе, ключ defaultRole из config.json убран,
chats.json стал {"id": "..."} вместо карты ролей. /api/probe показывает
положение тумблеров.
Проверено живым прогоном: обычный вопрос, вопрос с картинкой, снова
обычный — ответы верные, чат ротируется, сайдбар чистится.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ez8B2cR3mbm1fjmAMa8JXS
Проверено вживую: браузер убит через 10 с после начала запроса. Сокет умирал
честно, браузер поднимался, но повтор падал на «кнопка New chat не найдена» —
ensureBrowser возвращался, едва отладочный порт отозвался. У холодного
браузера адрес задан аргументом командной строки, поэтому вкладка есть
в списке сразу, а разметки нет ещё несколько секунд, и ветка с ожиданием
после /json/new в этом случае не выполнялась вовсе.
Теперь ensureBrowser в обоих случаях ждёт поле ввода — примету того, что
страницей можно пользоваться, — и отдельно распознаёт страницу входа, где
ждать нечего. После правки тот же опыт даёт полный ответ: запрос пережил
смерть браузера и вернул 9888 символов за 140 с.
DevTools берёт всё, что стоит после '?' в /json/new, как сам адрес целиком —
это не параметры запроса. Строка 'url=https%3A%2F%2Fchat.deepseek.com%2F'
честно считалась адресом, и открывалась about:blank. Место срабатывает
только когда браузер жив, а вкладки с чатом нет, поэтому лежало незамеченным.
Заодно ensureBrowser теперь проверяет, что открылось именно то: беззвучный
промах в этом файле уже был один раз, с кнопкой New chat.
Лог обрывался на «Браузер не отвечает, поднимаю...» и дальше молчал даже
при успехе — со стороны неотличимо от зависшего сервиса. Теперь ensureBrowser
говорит, что браузер поднялся и что вкладка открыта.
Заодно окно в трее больше не советует Ctrl+C: консоли там нет, останов —
«Выход» в меню значка.
Три вещи, и первая - настоящая дыра, а не удобство.
1. Смерть вкладки посреди запроса вешала сервис насмерть. У Session не было
ни обработчика close, ни таймаута на вызов: закрылась вкладка в момент
ожидания - обещание не разрешалось НИКОГДА. Запрос висел, очередь за ним
стояла, сервис при этом выглядел живым и молчал. Теперь close отклоняет
всё висящее, у каждого вызова протокола потолок 60 с, у подключения 10 с,
а мёртвый сокет отказывает сразу, а не копит вызовы.
2. ask() повторяет запрос один раз, если вкладка пропала посреди работы.
Повтор безопасен именно из-за правки первого сообщения: вопрос не
добавляется к чату, а заменяет его содержимое, поэтому дважды он
не задастся.
3. Сторож: раз в 30 с проверяет браузер и вкладку и поднимает, не дожидаясь
вопроса. Раньше восстановление жило внутри запроса, и клиент платил за него
15-60 секундами своего времени. Ходит через ТУ ЖЕ очередь, что и запросы,
иначе полез бы в браузер, пока DeepSeek дописывает ответ. Пропускает свой
черёд, если запрос уже идёт. При неудаче отсрочка удваивается до 300 с:
обычная причина (профиль открыт другим окном без отладочного порта) сама
не лечится, и долбиться каждые полминуты значит плодить процессы.
Выключается ключом watchdog в config.json.
Добавлен GET /api/state - дешёвый снимок для индикаторов: браузер, готовность,
занятость, длина очереди, секунды текущего запроса, последняя ошибка и время
последней проверки. Вкладку не трогает, спрашивать можно хоть раз в секунду.
ВАЖНО для будущего окна с индикаторами: снимок обновляет сторож, поэтому он
устаревает на срок до watchdogSec - смотреть на поле checked, а не только
на ready.
Проверено вживую: сервис поднялся, /api/state отдал ready; браузер убит дважды
- в логе "сторож: Браузер не отвечает, поднимаю...", checked идёт каждые 30 с,
состояние возвращается в ready.
НЕ проверено вживую: восстановление после смерти вкладки ПОСРЕДИ запроса
(пункты 1 и 2). Код компилируется, разбор формата проходит, но подгадать
момент не пробовал.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Раньше сервис был обёрткой: каждый запрос спавнил ollama_orchestro/ask.mjs
дочерним процессом, гонял вопрос и ответ через временные файлы и читал
чужой config.json ради профиля браузера. Работать это могло только рядом
с установленным DeepShim.
Теперь всё своё. browser.mjs — перенесённый из ask.mjs движок: CDP-сессия,
помощники страницы со всем, что удалось выяснить про разметку DeepSeek,
отправка с подтверждением, ожидание ответа по состоянию кнопки, работа
с чатами. Пульт, разбор патчей и git остались в DeepShim, сюда не поехали.
Побочно ушли дочерний процесс на каждый запрос и временные файлы: вопрос
и ответ теперь просто переменные. Файл на диске остался только для картинки —
<input type="file"> иначе не наполнить.
Свои настройки вместо чужих: browserExe, profileDir и cdpPort в config.json,
рядом config.local.json для путей конкретной машины (в репозиторий не идёт).
Свой chats.json, тоже не в репозитории: это рабочее состояние, оно
переписывается при каждой смене чата. Образец — chats.example.json.
Добавлен GET /api/probe: что видно во вкладке прямо сейчас.
ВАЖНО: профиль браузера должен быть отдельный. Перед каждым вопросом сайдбар
подчищается от всего, чего нет в своём chats.json, поэтому две программы
на одном профиле удаляют чаты друг друга. Проверено вживую, описано в README.
Проверки: node test.mjs; сквозной прогон с нуля — свой чат заведён сам,
ответ верный; пять правок в одном чате, на шестом запросе новый чат, старый
удалён, сайдбар не растёт.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
