From 0cdef67c1f9317d471e1225df7cdbc3158787817 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E2=80=9CNaeel=E2=80=9D?= <tazet@narod.ru>
Date: Mon, 13 Jul 2026 12:41:08 +0400
Subject: [PATCH] =?UTF-8?q?docs:=20=D0=BE=D1=82=D0=B2=D0=B5=D1=82=20Sonnet?=
 =?UTF-8?q?=20=E2=80=94=20TMP-=D1=84=D0=B0=D0=B9=D0=BB=D1=8B=20=D0=BE?=
 =?UTF-8?q?=D1=82=20=D1=81=D1=82=D0=B0=D1=80=D0=BE=D0=B3=D0=BE=20=D0=BA?=
 =?UTF-8?q?=D0=BE=D0=B4=D0=B0,=20=5Fnext=5Ftoken()=20=D1=87=D0=B8=D1=81?=
 =?UTF-8?q?=D1=82?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ...13-sonnet-response-obfuscation-analysis.md | 70 +++++++++++++++++++
 1 file changed, 70 insertions(+)
 create mode 100644 History/2026-07-13-sonnet-response-obfuscation-analysis.md

diff --git a/History/2026-07-13-sonnet-response-obfuscation-analysis.md b/History/2026-07-13-sonnet-response-obfuscation-analysis.md
new file mode 100644
index 0000000..6243ec2
--- /dev/null
+++ b/History/2026-07-13-sonnet-response-obfuscation-analysis.md
@@ -0,0 +1,70 @@
+# Sonnet: анализ обфускации — TMP-файлы vs текущий код
+
+**Дата:** 2026-07-13
+
+---
+
+## Главный вывод
+
+**TMP-файлы созданы СТАРОЙ версией кода.** Они не были сгенерированы текущим `_next_token()`-кодом. Это не баг в текущем коде — это артефакт предыдущей реализации.
+
+---
+
+## Доказательства
+
+### 1. Имена файлов — старый формат
+
+Текущий `obfuscator.py` генерирует имена вида `договор-НУБЕС001-03700.md` (меняет расширение). TMP-файлы: `договор-XXX001-03700_obfuscated.md` — суффикс `_obfuscated` и `XXX`-маскировка в имени. Текущий код так не делает.
+
+### 2. Тип `text` — fallback из builder.py, не из сканера
+
+`build_mapping_csv()` определяет тип постфактум по паттернам. Если ни один не совпал → `"text"`. Типа `text` нет в `TYPE_POOLS` scanner.py. Значит строки вида:
+```
+text,Исполнителем Заказчику Сторонами,Кузнецов О.В.
+```
+попали из старого кода, который не фильтровал роли (Исполнитель, Заказчик) — текущий LLM-промпт их явно исключает.
+
+### 3. Одна сущность → разные замены
+
+```
+email,info@nubes.ru,ypiorej@company.local   ← файл 1
+email,info@nubes.ru,qifdckke@org.example.ru ← файл 2
+```
+
+Текущий `TwoPassObfuscator` гарантирует глобальную согласованность. Старый код обрабатывал файлы по одному — отсюда расхождения.
+
+### 4. Реалистичные замены невозможны из `_next_token()`
+
+```python
+TYPE_POOLS = {
+    "phone": (["+7_000_000"], "phone"),  # → "+7_000_000_0001"
+    "email": (["email"], "email"),        # → "email_0001"
+}
+```
+
+`+7 (495) 906-87-80` или `ypiorej@company.local` физически не могут выйти из этих пулов.
+
+---
+
+## Ответ на главный вопрос
+
+> Кто и где генерирует замены в обход `_next_token()`?
+
+**Никто в текущем коде.** Это артефакты старого кода (версии до v3). Текущий `_next_token()` написан позже.
+
+---
+
+## Что реально нужно проверить
+
+| Вопрос | Как проверить |
+|--------|---------------|
+| Работает ли текущий код? | Прогнать оригиналы через v0.0.12, посмотреть mapping.csv |
+| Regex ловит все сущности? | Проверить `config.py` паттерны на примерах из TMP |
+| Адрес `115404, г. Москва...` — почему не заменён? | `ENTITY_PATTERNS` не содержит тип `address` |
+| `ООО "НУБЕС"` в тексте не заменён? | Возможно кавычки — regex матчит `«»` но не `""` |
+
+---
+
+## Итог
+
+**Ложное противоречие** — сравнивались TMP-файлы (старый код) с текущим scanner.py. Нужно прогнать текущий код на тех же документах и посмотреть результат.