From 72e6e5a12776bd639af38f93c0569628473daf26 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E2=80=9CNaeel=E2=80=9D?= Date: Thu, 25 Jun 2026 08:26:34 +0400 Subject: [PATCH] =?UTF-8?q?v1.0.177:=20=D1=80=D0=B5=D0=B2=D1=8C=D1=8E=20?= =?UTF-8?q?=D0=BF=D0=BB=D0=B0=D0=BD=D0=B0=20=D0=9E=D0=BF=D1=83=D1=81=D0=B0?= =?UTF-8?q?=20=E2=80=94=20=D1=86=D0=B5=D0=BB=D0=B8=D0=BA=D0=BE=D0=BC=20?= =?UTF-8?q?=D1=80=D0=B5=D0=BD=D0=B4=D0=B5=D1=80=D0=B8=D1=82=D1=8C,=203=20?= =?UTF-8?q?=D1=83=D1=82=D0=BE=D1=87=D0=BD=D0=B5=D0=BD=D0=B8=D1=8F?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../llm-analysis/opus-decoupling-review.md | 32 +++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 History/llm-analysis/opus-decoupling-review.md diff --git a/History/llm-analysis/opus-decoupling-review.md b/History/llm-analysis/opus-decoupling-review.md new file mode 100644 index 0000000..a55a91e --- /dev/null +++ b/History/llm-analysis/opus-decoupling-review.md @@ -0,0 +1,32 @@ +# Ответ Opus на decoupling — моё мнение + +## По трём открытым вопросам + +### 1. Перерисовывать целиком vs точечно? +**Целиком.** Для ~50KB JS и десятка DOM-элементов перерисовка всей карточки/таблицы — доли миллисекунды. Точечные патчи создают ровно те баги, которые мы сегодня чинили (затирание, рассинхрон). `render(state)` должен тупо пересобрать всё заново. + +### 2. Промпты/чат/showText в scope? +**Нет**, отдельная итерация. Они изолированы (модалки), не участвуют в пайплайне. Не добавлять сложности. + +### 3. Node-тесты на чистые билдеры? +**Да.** После Фазы 2, когда появятся `buildFileRowHTML(state)` и `buildGroupCardHTML(group)`. Прогнать на фикстурах — уберёт регрессии на рендеринг. + +## По плану в целом + +**Согласен с порядком фаз.** Фаза 0 (каркас) → Фаза 1 (files) → Фаза 2 (groups) → Фаза 3 (SSE). Это правильный порядок от простого к сложному. + +**Согласен с удалением `markGroupDone`.** Чтение `bodyEl.innerHTML` из DOM — это то самое «состояние размазано по DOM», которое мы лечим. `state.groups[gi].compare.status === 'done'` — правильный источник истины. + +**Дополнение по SSE.** Opus правильно отметил что SSE-события мутируют state + render(). Но есть нюанс: `EventSource` и таймеры нужно привязывать к `state._activeCompare`. При старте нового сравнения проверять `if (state._activeCompare) { state._activeCompare.es.close(); }` — это уберёт гонки на уровне state, а не DOM. + +**Дополнение по рендерингу.** `render(state)` должна быть идемпотентной: повторный вызов с тем же state даёт тот же DOM. Это гарантирует что «лишний render()» не сломает ничего. + +## Есть ли ещё вопросы к Опусу? + +Три уточнения: + +1. **`fileInput change` handler** — ~200 строк, самая сложная функция. Как разбить на под-actions: `selectFiles`, `removeOrphans`, `uploadOne`, `parseOne`? Или оставить монолитом но внутри state? + +2. **SSE-дублирование.** `runCompareForGroup` и `llmBtn` имеют ~80% одинакового кода (extract_start, llm_done, applied). Унифицировать в `runCompare(state, contractId)` с флагом `scope: 'group' | 'all'`? + +3. **`status` в state.files.** Сейчас это HTML-строка (`'✓ 25 эл. (0.0с)'`). Заменить на структуру `{ ok: true, elements: 25, time: 0.0 }` и рендерить через `renderFileStatus(file)`?