SEO AI Tool

app.py

@@ -1,13 +1,7 @@
 # app.py - Hugging Face Spaces entry point
 
-import json
-import threading
-import uuid
-from queue import Empty, Queue
-
 from fastapi import FastAPI, Request
-from fastapi.responses import HTMLResponse, StreamingResponse
-from fastapi.staticfiles import StaticFiles
+from fastapi.responses import HTMLResponse
 from fastapi.templating import Jinja2Templates
 import uvicorn
 import torch
@@ -25,7 +19,6 @@ from models import (
     UserAgentsResponse,
     OptimizerRequest,
     OptimizerResponse,
-    OptimizerCancelRequest,
 )
 import logic
 import nlp_processor
@@ -38,13 +31,6 @@ import optimizer
 
 app = FastAPI(title="SEO AI Editor MVP")
 
-_static_dir = os.path.join(os.path.dirname(os.path.abspath(__file__)), "static")
-if os.path.isdir(_static_dir):
-    app.mount("/static", StaticFiles(directory=_static_dir), name="static")
-
-_OPTIMIZER_JOBS_LOCK = threading.Lock()
-_OPTIMIZER_CANCEL_EVENTS: dict = {}
-
 # Подключаем папку с шаблонами
 templates = Jinja2Templates(directory="templates")
 
@@ -272,75 +258,6 @@ async def run_optimizer(request: OptimizerRequest):
     except Exception as e:
         return OptimizerResponse(ok=False, error=str(e))
 
-
-@app.post("/api/v1/optimizer/cancel")
-async def optimizer_cancel(body: OptimizerCancelRequest):
-    with _OPTIMIZER_JOBS_LOCK:
-        ev = _OPTIMIZER_CANCEL_EVENTS.get(body.job_id)
-    if ev is not None:
-        ev.set()
-    return {"ok": True}
-
-
-@app.post("/api/v1/optimizer/run-stream")
-async def run_optimizer_stream(request: OptimizerRequest):
-    """SSE: события прогресса + финальный JSON. Клиент ведёт локальный лог, без глобального лоадера."""
-    job_id = str(uuid.uuid4())
-    cancel_ev = threading.Event()
-    payload = request.model_dump()
-    q: Queue = Queue()
-
-    with _OPTIMIZER_JOBS_LOCK:
-        _OPTIMIZER_CANCEL_EVENTS[job_id] = cancel_ev
-
-    def worker():
-        try:
-            def progress_cb(data):
-                q.put(("progress", data))
-
-            result = optimizer.optimize_text(
-                payload,
-                progress_callback=progress_cb,
-                cancel_event=cancel_ev,
-            )
-            q.put(("done", result))
-        except Exception as e:
-            q.put(("error", str(e)))
-
-    threading.Thread(target=worker, daemon=True).start()
-
-    def gen():
-        try:
-            yield f"data: {json.dumps({'event': 'job', 'job_id': job_id})}\n\n"
-            while True:
-                try:
-                    kind, data = q.get(timeout=0.3)
-                except Empty:
-                    yield ": ping\n\n"
-                    continue
-                if kind == "progress":
-                    yield f"data: {json.dumps(data)}\n\n"
-                elif kind == "done":
-                    yield f"data: {json.dumps({'event': 'complete', 'result': data})}\n\n"
-                    break
-                elif kind == "error":
-                    yield f"data: {json.dumps({'event': 'error', 'error': data})}\n\n"
-                    break
-        finally:
-            with _OPTIMIZER_JOBS_LOCK:
-                _OPTIMIZER_CANCEL_EVENTS.pop(job_id, None)
-
-    return StreamingResponse(
-        gen(),
-        media_type="text/event-stream",
-        headers={
-            "Cache-Control": "no-cache",
-            "Connection": "keep-alive",
-            "X-Accel-Buffering": "no",
-        },
-    )
-
-
 # Hugging Face Spaces использует порт 7860
 if __name__ == "__main__":
     port = int(os.environ.get("PORT", 7860))

docs/FULL_FUNCTIONAL_DOCUMENTATION.md

@@ -24,7 +24,7 @@
    - смысловой поиск по словам и фразам
    - сравнение с конкурентами (включая таблицу мощных терминов)
 
-3. **LLM Optimizer** (`POST /api/v1/optimizer/run` или в UI — SSE `run-stream`)
+3. **LLM Optimizer** (`POST /api/v1/optimizer/run`)
    - итеративная локальная оптимизация текста
    - многокритериальный скоринг с защитой от деградации
    - каскад уровней правок (от минимальных к более широким)
@@ -44,9 +44,7 @@
 - `search.py` — смысловой поиск в графе (фразы + слова).
 - `url_fetcher.py` — извлечение текста/title из URL с выбором user-agent.
 - `optimizer.py` — LLM-оптимизация с обратной связью от метрик.
-- `docs/TEXT_OPTIMIZER_PRINCIPLES.md` — живой регламент принципов оптимизатора (stage-пайплайн, допуски, guardrails).
-- `templates/index.html` — разметка UI.
-- `static/js/app.js` — вся клиентская логика (подключается как `/static/js/app.js`; без гигантского inline-скрипта — см. `docs/HF_SES_AND_UI.md`).
+- `templates/index.html` — frontend (UI + клиентская логика JS).
 
 ---
 
@@ -166,32 +164,16 @@
 ### Вход (`OptimizerRequest`)
 - аналитические данные: `target_text`, `competitors`, `keywords`, `language`, `target_title`, `competitor_titles`
 - LLM: `api_key`, `api_base_url`, `model`, `temperature`
-- стратегия: `max_iterations`, `candidates_per_iteration`, `optimization_mode`, `phrase_strategy_mode`, `bert_stage_target`
-  - `phrase_strategy_mode`: `auto | distributed_preferred | exact_preferred | ensemble`
-  - `ensemble`: в пределах итерации циклически пробует несколько phrase-стратегий и ранжирует кандидаты общей utility-функцией.
-  - `bert_stage_target`: пользовательский порог завершения этапа A (BERT), например `0.61` вместо `0.70`.
+- стратегия: `max_iterations`, `candidates_per_iteration`, `optimization_mode`
 
 ### Выход (`OptimizerResponse`)
-- `optimized_text` — итоговый body (target)
-- `optimized_title` — итоговая строка для поля **Title**; в ответе она берётся из снимка `title_analysis.target_title` (тот же текст, что учитывался в метрике Title BERT), с запасным вариантом из переменной оптимизатора. В `final_metrics` дополнительно есть `resolved_title` с тем же смыслом (удобно для UI/fallback).
+- `optimized_text`
 - `baseline_metrics`, `final_metrics`
 - `iterations[]` (подробный лог шагов)
 - `applied_changes`
 - `optimization_mode`
-- `phrase_strategy_mode`
-- `bert_stage_target`
-- `stopped_early`, `stop_reason` — при ручной остановке (частичный результат)
 - `error` (если есть)
 
-### `POST /api/v1/optimizer/run-stream` (SSE)
-Тело как у `run`. Поток `text/event-stream`, события `job` (с `job_id`), `preparing`, `started`, `step_start`, `llm_call`, затем `complete` с полем `result` или `error`.
-
-### `POST /api/v1/optimizer/cancel`
-Тело: `{"job_id": "..."}`. Только флаг отмены; клиент дочитывает SSE до `complete`.
-
-### UI и HF/SES
-Клиентский код: **`static/js/app.js`** + `GET /static/js/app.js`. Прогресс оптимизатора — **локальная панель с текстовым логом** (и тонкая полоса), **без** `#loader`. Подробности про SES и «мёртвые кнопки»: `docs/HF_SES_AND_UI.md`.
-
 ---
 
 ## 5) Подробная алгоритмика по модулям
@@ -442,15 +424,9 @@ HTML extraction pipeline:
 
 ### Генерация кандидатов
 - `_llm_edit_chunk` — отправляет structured prompt в OpenAI-compatible API.
-  - роль модели в prompt: **semantic-vector optimizer for SEO**, а не общий “copy editor”.
   - учитывает `cascade_level` и тип операции (`rewrite`/`insert`)
   - явно требует грамматически корректный и естественный текст
   - ограничивает число предложений по уровню
-  - для BERT динамически выбирает стратегию по длине целевой фразы:
-    - короткие цели: допустим один natural exact match;
-    - длинные multi-word цели: приоритет у distributed semantic coverage (части фразы/леммы/близк��е формулировки), без forced exact match.
-  - exact phrase не должен повторяться: при неестественном звучании он запрещается в пользу распределённой формулировки.
-  - для `rewrite` явно требует сохранить исходный смысл `sentence-by-sentence` и не менять субъект/ключевую сущность без необходимости.
 
 ### Применение правок
 - `_replace_span` — замена диапазона предложений.
@@ -460,37 +436,20 @@ HTML extraction pipeline:
 - `_goal_improved`:
   - для BERT: улучшение score целевой фразы минимум на `BERT_GOAL_DELTA_MIN=0.005` **или** снижение `bert_low_count`;
   - для других целей: профильные метрики улучшения.
-- `_candidate_utility`:
-  - многоцелевая функция полезности кандидата с динамическими весами;
-  - учитывает одновременно `bert_phrase_delta`, `chunk_goal_delta`, `score_delta`;
-  - добавляет мягкие штрафы за регрессии по BM25/BERT-low/N-gram/SemanticGap/Title;
-  - в BERT-push режиме (когда фраза ниже порога) усиливает вес phrase-level прогресса.
 - `_is_candidate_valid`:
   - hard constraints (не ухудшать критичные метрики сверх допустимого);
   - режимы `conservative/balanced/aggressive` задают пороги регрессии;
   - решение учитывает и `goal_improved`, и общий `delta_score`.
-- `_is_stage_complete` для `bert`:
-  - этап считается завершённым только когда **каждая** отслеживаемая ключевая фраза достигает `bert_stage_target` (проверка по `min(bert_phrase_scores)`);
-  - достижение порога одной «сильной» фразой больше не завершает BERT-этап.
-  - унифицированный цикл по целям: базовые параметры запроса `max_iterations` и `candidates_per_iteration` задают «якорь», но для **каждой** цели вычисляется эффективный бюджет (`_per_goal_budget`): число попыток и ширина пула кандидатов **масштабируются по дефициту** до таргета — для BERT по разрыву score до порога, для semantic по `semantic_gap`, для n-gram по отставанию/перегрузу относительно целевого счётчика, для BM25 по «лишним» вхождениям слова, для title по разрыву `title_bert_score`. После исчерпания лимита по текущей цели оптимизатор переходит к следующей цели той же стадии.
-- `_validate_candidate_text`:
-  - отклоняет некачественные/спамные кандидаты (дубли слов/сущностей, подозрительные склейки токенов);
-  - добавляет anti-stuffing фильтр для цели BERT (повторы exact phrase и чрезмерные повторы focus-термов).
 
 ### Главная функция `optimize_text`
 Итерационный цикл:
 1. baseline metrics.
-   - общий бюджет шагов оценивается как **сумма эффективных итераций по всем целям** (`_estimate_total_loop_budget`: для каждой цели — `_per_goal_budget`, затем сумма по стадиям с верхней отсечкой), то есть масштабируется и по числу целей, и по величине отставания от таргета. В SSE-событии `step_start` дополнительно передаются `goal_budget_iter` и `goal_budget_candidates` для текущей цели.
 2. выбрать goal.
 3. выбрать пул чанков и операцию каскада.
-   - **Этап `title`:** если средняя BERT-близость Title к ключам (`title_bert_score`) ниже порога (`TITLE_TARGET_THRESHOLD` ≈ 0.65), цель — **только переписать текст из поля Title** (`target_title`), а не абзац основного текста. LLM получает текущий title, выдержку из body и ключевые слова; метрики пересчитываются с новым title. Пакетные правки по body с title не смешиваются.
-   - **Проверка деплоя:** в debug кандидата для шага `title` в `llm_prompt_debug` должно быть `"operation": "title_rewrite"`, а `chunk_text` — короткая строка текущего Title. Если видите `"operation": "rewrite"` и длинный `chunk_text` из body — на сервере старая версия `optimizer.py` (или не пересобран образ).
    - на шаг выбирается несколько span-кандидатов (multi-chunk selection), а не один;
    - ранжирование учитывает `focus_terms/avoid_terms`, chunk-level relevance и шумовые эвристики (menu/CTA/header penalties);
-   - для **n-gram** целей предложения ранжируются через **скользящие перекрывающиеся окна** из 2–4 предложений (шаг 1): каждому предложению присваивается лучший балл среди окон, оценка штрафует локальные повторы фразы и шумовые блоки;
-   - для BERT-целей ранжирование не ограничивается участками с already-present вхождениями: дополнительно приоритизируются релевантные участки с недопредставленными core-термами, где их можно добавить естественно;
    - используется `attempt_cursor` по цели и `attempted_spans`, чтобы избежать циклов по одному и тому же участку.
-4. сгенерировать `N` кандидатов для каждого выбранного span (`N` зависит от эффективного бюджета кандидатов для цели и каскада, см. `_per_goal_budget` и деление по span).
+4. сгенерировать `N` кандидатов для каждого выбранного span.
 5. pre-validation (формат/качество/длины).
 6. chunk-level оценка:
    - вычисляется `chunk_goal_delta` (релевантность чанка до/после к текущей цели);
@@ -503,7 +462,6 @@ HTML extraction pipeline:
    - если локально улучшает чанк, но глобально не проходит — кандидат кладется в queue.
    - для BERT учитывается прямой документный `bert_phrase_delta` по целевой фразе: даже небольшой положительный рост считается полезным шагом при отсутствии регрессий по guardrails.
    - если нет `promotable` кандидата, но есть guardrail-valid кандидат с `local_chunk_improved`, применяется режим `applied_local_progress`: правка принимается локально и оптимизация переходит к следующему чанку (накопительная стратегия).
-   - ранжирование и выбор best-кандидата дополнительно учитывают `candidate_utility`, чтобы BERT-оптимизация не вредила следующим этапам по другим метрикам.
 9. batch-логика queue:
    - optimizer пробует совместно применить комбинации из 2..4 локально сильных не конфликтующих правок;
    - batch принимается только при прохождении глобальных ограничений и положительном совокупном локальном приросте.
@@ -514,13 +472,12 @@ HTML extraction pipeline:
    - `L4`: более широкий rewrite окна (до 5 предложений с вариативным охватом).
 11. вести подробный лог по каждому кандидату.
    - в debug-таблице фиксируются и chunk-level сигналы (`local+`, `chunk Δ`, `rel before->after`) наряду с глобальными (`Δ score`, `valid`, `goal+`);
-   - для каждого кандидата сохраняется `llm_prompt_debug` (операция, цель, фокус-термы, chunk и ближайший контекст), что позволяет анализировать фактический вход в LLM;
-   - LLM возвращает поле `rationale` (1 строка) — краткое объяснение, почему правка должна повысить релевантность цели.
+   - для каждого кандидата сохраняется `llm_prompt_debug` (операция, цель, фокус-термы, chunk и ближайший контекст), что позволяет анализировать фактический вход в LLM.
    - также сохраняется `metrics_delta` (вклад BM25/BERT/Semantic/N-gram/Title в общий сдвиг), включая `semantic_gap_sum` и изменение состава gap-термов (`semantic_gap_terms_added/removed`), чтобы видеть, за счет чего падает или растет `score`.
 
 ---
 
-## 6) Frontend (`templates/index.html` + `static/js/app.js`)
+## 6) Frontend (`templates/index.html`) — сценарии и функции
 
 ## 6.1 Ввод данных и URL import
 - `loadUserAgentOptions` — загрузка пресетов UA.
@@ -549,12 +506,9 @@ API-ключ оптимизатора в persist-состояние не сох
 
 ## 6.4 Сводка и оптимизатор
 - `renderActionSummary` — агрегирует рекомендации BERT/BM25/N-grams/Title/Semantic в табличный формат.
-- `runLlmOptimization` — `POST /api/v1/optimizer/run-stream` (SSE); локальная панель **лога** + тонкий progress bar; **без** `#loader`.
-- `requestStopOptimizer` — `POST /api/v1/optimizer/cancel`; поток дочитывается до `complete` (частичный результат).
-- `optimizerLogAppend` / `applyOptimizerStreamEvent` — текстовый ход работы.
-- `renderOptimizerResults` — итог и debug-лог; баннер при `stopped_early`.
+- `runLlmOptimization` — запуск оптимизации.
+- `renderOptimizerResults` — итог и debug-лог по шагам/кандидатам.
 - `applyOptimizedText` — перенос optimized текста в `target_text`.
-- `nv(v, d)` — nullish-fallback без операторов `??` (SES на HF).
 
 ## 6.5 Сортировка таблицы мощных терминов
 - `setSemanticTermSortBy`

docs/HF_SES_AND_UI.md

@@ -1,28 +0,0 @@
-# Почему на Hugging Face «умирали» все кнопки (версии с прогресс-баром)
-
-По **фактам из консоли** (не гипотезы):
-
-## 1. `SES_UNCAUGHT_EXCEPTION: SyntaxError: missing : in conditional expression`
-
-На странице Space подключается **SES lockdown** (`lockdown-install.js`). Его парсер/конвейер для кода страницы **не эквивалентен** последнему движку Firefox/Chrome в части синтаксиса ES2020+.
-
-- Операторы **`??` (nullish coalescing)** и **`?.` (optional chaining)** в **одном исходнике** с большим inline-`<script>` давали ошибку разбора, интерпретируемую как **сломанный тернарный `? … :`** → *missing ':'*.
-- После этой ошибки **весь** клиентский скрипт приложения **не выполняется** → не регистрируются **ни** `onclick`, **ни** делегирование `data-app-action` → кажется, что «сломались все кнопки».
-
-**Исправление:** не использовать `??` / `?.` в коде приложения; вместо них — функция `nv(v, d)` и проверки `obj && obj.prop`.
-
-## 2. Глобальный `#loader`
-
-Если на время оптимизатора включать полноэкранный оверлей и по какой-то причине не снять `display` в `finally`, **все клики** уходят в оверлей. Это уже не SES, а логика UI.
-
-**Исправление:** во время LLM-оптимизации **не** трогать `#loader`; прогресс только в **локальной панели** под кнопками.
-
-## 3. Строки CSP про `inpage.js`, Stripe, `content.js`
-
-В логе часто идут **расширения браузера** и iframe HF, а не ваш `index.html`. На диагностику кнопок приложения они обычно не влияют.
-
-## Текущая схема (после правок)
-
-- Логика UI в **`/static/js/app.js`** (отдельный файл, не гигантский inline).
-- Прогресс оптимизатора: **панель с `<pre>`-логом** + тонкая полоса; **без** блокировки всего экрана.
-- Поток **`/api/v1/optimizer/run-stream`** (SSE) + **`/api/v1/optimizer/cancel`** для остановки с частичным результатом.

docs/TEXT_OPTIMIZER_PRINCIPLES.md

@@ -1,99 +0,0 @@
-# Text Optimizer Principles
-
-This document is a living spec for iterative text optimization behavior.
-Update it whenever optimization policy changes.
-
-## 1) Multi-objective optimization model
-
-- **Primary objective (by stage):**
-  - Stage A: BERT phrase relevance
-  - Stage B: BM25 remove cleanup
-  - Stage C: N-gram balancing
-  - Stage D: Semantic gap balancing
-  - Stage E: Title alignment
-- **Guardrails (always active):**
-  - Do not allow critical metric regressions beyond mode tolerances.
-  - Keep grammar, coherence, and non-spam writing.
-
-## 2) Stage order and skipping
-
-- Stage order:
-  - `bert -> bm25 -> ngram -> semantic -> title`
-- A stage is skipped if no actionable goal exists.
-- Plateau rule:
-  - If no primary progress for 3 steps, move to next stage.
-
-## 3) BERT stage policy
-
-- Default Stage A threshold: `0.70`.
-- User may set custom threshold via UI (`BERT target A-stage`), e.g. `0.61`.
-- Stage A is complete when max target phrase score reaches configured threshold.
-
-## 4) BM25 stage policy
-
-- Main target: reduce/remove over-optimization signals.
-- A stage is considered healthy when `bm25_remove_count <= 3`.
-
-## 5) N-gram stage policy (quantitative)
-
-- Goal: bring target counts closer to competitor average, not force exact equality.
-- Tolerance bands:
-  - if `avg >= 4`: acceptable range is `avg +/- 20%`
-  - if `avg < 4`: acceptable range is `avg +/- 50%`
-- N-gram signal is counted only when term is outside tolerance and present in enough competitors.
-- Selection rules (multi-competitor mode, `competitors > 1`):
-  - bi-grams and tri-grams are eligible when present in `>= 2` competitors;
-  - unigrams are eligible only if they are part of user keyword phrases and present in `>= 2` competitors.
-- Target ranking (which n-gram to work on next):
-  - sort eligible **underrepresented** rows by **Freq(K)** (`comp_occurrence`) descending,
-    then **Avg(K)** (`competitor_avg`) descending,
-    then **deviation** from competitor average descending (larger gap first).
-- Iteration behavior:
-  - optimizer works on one n-gram target at a time per step;
-  - per eligible n-gram target it allocates `3` attempts, then moves to the next target;
-  - if target list ends, stage advances to the next optimization stage.
-- **Global step budget:** the UI `max_iterations` cap still limits total loop iterations, but the
-  optimizer **adds** extra steps reserved for the n-gram stage (`targets × 3`, capped) so a low
-  `max_iterations` value does not stop the run after only three n-gram rows while many targets remain.
-- **Chunk selection (n-gram stage):** candidate sentences are ranked using **overlapping multi-sentence
-  windows** (stride 1). Each sentence receives the best window score; windows favor low local phrase
-  duplication, topical overlap with phrase tokens, and non-noisy prose. Document-level phrase count
-  remains the primary acceptance signal.
-
-## 5.1 Summary logic memory (current)
-
-- Summary recommendation triggers:
-  - BERT warning when phrase score `< 0.70`;
-  - BM25 warning when `REMOVE >= 4`;
-  - N-gram warning when term is underrepresented among competitors;
-  - Title warning when Title BERT `< 0.65`;
-  - Semantic warning when keyword terms are weaker than competitor average.
-- For N-grams in summary:
-  - summary renders top rows for readability, but optimizer runs against the full eligible candidate set.
-
-## 6) Local acceptance and batch accumulation
-
-- First evaluate candidate locally (chunk-level), then globally (document-level).
-- Locally improved candidates may be queued when global score does not move yet.
-- Non-conflicting queued edits can be applied as a batch (2-4 edits) if guardrails pass.
-
-## 7) Text quality constraints
-
-- Reject candidates with:
-  - duplicated entities/words,
-  - suspicious token joins,
-  - excessive sentence count for current cascade level,
-  - obvious stuffing/redundancy.
-- Keep narrative continuity and original subject/entity focus.
-
-## 8) Diagnostics requirements
-
-- For every iteration, store:
-  - stage, goal, cascade level,
-  - candidate validity, local improvement, metric deltas,
-  - selected strategy and prompt debug payload.
-- UI must show:
-  - stage progression,
-  - stage transitions,
-  - candidate strategy and reason for rejection.
-

models.py

@@ -82,12 +82,6 @@ class OptimizerRequest(BaseModel):
     language: str = "en"
     target_title: str = ""
     competitor_titles: List[str] = Field(default_factory=list)
-    # Base for highlighting what changed in this optimization run.
-    # - diff_from_input: compare with `target_text` passed in this request (snapshot before optimization)
-    # - diff_from_original: compare with `original_target_text` from the first snapshot in session
-    diff_mode: str = "diff_from_input"  # diff_from_input | diff_from_original
-    original_target_text: Optional[str] = None
-    original_target_title: Optional[str] = None
 
     api_key: str
     api_base_url: str = "https://api.deepseek.com/v1"
@@ -97,41 +91,14 @@ class OptimizerRequest(BaseModel):
     candidates_per_iteration: int = 2
     temperature: float = 0.25
     optimization_mode: str = "balanced"
-    phrase_strategy_mode: str = "auto"  # auto | exact_preferred | distributed_preferred | ensemble
-    bert_stage_target: float = 0.70
-    # Optional stage control. If empty -> default full pipeline order.
-    enabled_stages: List[str] = Field(default_factory=list)  # bert|bm25|ngram|semantic|title
-    # Per-stage manual goal selection and custom additions.
-    # Example:
-    # {
-    #   "bm25": {"mode":"mixed","selected":["canadian online casino"],"custom_add":["online casinos canada"]},
-    #   "bert": {"mode":"manual","selected":["best payout casinos"],"custom_add":[]}
-    # }
-    stage_goal_overrides: Dict[str, Dict[str, Any]] = Field(default_factory=dict)
 
 
 class OptimizerResponse(BaseModel):
     ok: bool = True
     optimized_text: str = ""
-    optimized_title: str = ""
     baseline_metrics: Dict[str, Any] = Field(default_factory=dict)
     final_metrics: Dict[str, Any] = Field(default_factory=dict)
     iterations: List[Dict[str, Any]] = Field(default_factory=list)
     applied_changes: int = 0
     optimization_mode: str = "balanced"
-    phrase_strategy_mode: str = "auto"
-    bert_stage_target: float = 0.70
-    diff_mode: str = ""
-    # HTML with <mark class="diff-changed"> around changed parts.
-    diff_body_html: str = ""
-    diff_title_html: str = ""
-    # List of (type/from/to) blocks for "что именно поменять".
-    diff_changes: List[Dict[str, str]] = Field(default_factory=list)
-    diff_title_changes: List[Dict[str, str]] = Field(default_factory=list)
-    error: str = ""
-    stopped_early: bool = False
-    stop_reason: str = ""
-
-
-class OptimizerCancelRequest(BaseModel):
-    job_id: str = Field(..., min_length=8)
+    error: str = ""