EXPERIMENTS_LOG.md

# EXPERIMENTS_LOG.md — Audit Verification (2026-07-22)

## [2026-09-27] — stale_after + discriminator for memory notes (CONFIRMED)

**Гипотеза:** Memory notes can be automatically expired via `stale_after` date or `discriminator` command — deterministic, offline, no LLM calls. Tom Jones (dev.to hooks article) describes these two keys.
**Команда:** `python -m pytest tests/test_stale_after.py -v`
**Сырой вывод:**
```
17 passed in 2.87s
- test_positive_future_stale_after_passing_discriminator PASSED
- test_negative_past_stale_after PASSED
- test_negative_failing_discriminator PASSED
- test_none_no_stale_after_no_discriminator PASSED
- test_stale_after_today_is_not_stale PASSED
- test_invalid_stale_after_format_graceful PASSED
- test_discriminator_timeout_returns_expired PASSED
- test_stale_after_checked_before_discriminator PASSED
- test_injectable_now_date PASSED
- test_store_positive_control PASSED
- test_store_negative_stale_after PASSED
- test_store_negative_discriminator PASSED
- test_store_none_backward_compat PASSED
- test_store_not_found PASSED
- test_store_mixed_notes PASSED
- test_cli_check_staleness PASSED
- test_cli_requires_note_id PASSED
```
**Вердикт:** CONFIRMED. All 4 controls pass. `stale_after` (ISO date) → STALE when past. `discriminator` (shell command) → EXPIRED on non-zero exit. No stale_after/discriminator → ACTIVE (backward compat). Deterministic, offline, no LLM.
**Дизайн:** New statuses STALE/EXPIRED (visible, not hidden like REFUTED/SUPERSEDED). `stale_after` checked before `discriminator`. Invalid date format → graceful (treated as no stale_after). Discriminator timeout 5s → EXPIRED.
**Артефакты:** `src/core/intelligence/staleness.py`, `src/core/intelligence/store.py` (check_staleness method), `src/cli.py` (CLI command), `tests/test_stale_after.py`, `experiments/stale_after/results.json`.
** backward compat:** Existing notes without new fields → ACTIVE.

## [2026-09-27] — redact.py: scrub personal paths with planted-key test (CONFIRMED)

**Гипотеза:** A redact utility that scrubs drive-rooted paths and username from text output is alive (catches planted violations) and does not over-redact clean text.
**Команда:** `python -m pytest tests/test_redact.py -v`
**Сырой вывод:**
```
5 passed in 0.43s
- test_drive_path_is_redacted PASSED
- test_forward_slash_path_is_redacted PASSED
- test_username_is_redacted PASSED
- test_clean_text_unchanged PASSED
- test_selftest_passes PASSED
```
**Вердикт:** CONFIRMED. Drive paths (backslash + forward slash) → `<project>`, username → `<user>`, clean text unchanged. Implements "redact.py at our delivery points + planted key test" promise.
**Артефакты:** `scripts/redact.py`, `tests/test_redact.py`.

## [2026-09-27] — Planted-break gate: guards are alive, not decoration (CONFIRMED)

**Гипотеза:** Guards verified only at build time drift into decoration. A planted break (deliberative violation) must be caught by the guard on every run.
**Команда:** `python -m pytest tests/test_planted_break_gate.py -v`
**Сырой вывод:**
```
6 passed in 0.10s
- test_core_no_mcp_imports_negative_control PASSED
- test_core_no_mcp_imports_positive_control PASSED
- test_tools_no_direct_registry_negative_control PASSED
- test_tools_no_direct_registry_positive_control PASSED
- test_stale_references_negative_control PASSED
- test_stale_references_positive_control PASSED
```
**Вердикт:** CONFIRMED. 3 guards × 2 controls (pos/neg) all pass. Guards catch planted violations and stay clean on valid input. Implements "commit gate with planted break on EVERY run" promise.
**Артефакты:** `tests/test_planted_break_gate.py`, `experiments/planted_break/results.json`.

## [2026-09-27] — NodeRAG deterministic experiment: chunked vs graph traversal (REFUTED)

**Гипотеза:** NodeRAG (graph traversal) outperforms chunked retrieval on long documents with rules buried inside (Tom Jones claim). Our corpus (AGENT_DIARY.md = 669 lines, EXPERIMENTS_LOG.md = 2666 lines) has exactly this shape.

**Эксперимент:** 16 замороженных запросов (10 правил + 3 позитивных контроля + 3 NONE-контроля), 2 плеча: Arm A = TF-IDF chunked retrieval (top-10), Arm B = PropertyGraph BFS traversal (depth=3). Без LLM-вызовов, детерминированно.

**Замороженные правила:** `experiments/noderag/frozen/rules.jsonl`, SHA256: `8657a7e3949b5a3eed8f025b8086dcf539cdafacd0cd335f28e607fcf0e44f9a`

**Результат:**
```
Arm A (chunked TF-IDF): 8/10 = 80.0% hit rate, 301,981 tokens
Arm B (graph BFS):      7/10 = 70.0% hit rate, 170,140 tokens
Positive controls: 3/3 passed
NONE controls: 3/3 clean
Verdict: REFUTED (A >= B)
```

**Детали:**
- Arm A промахнулся: R1 (begin_write), R2 (ArtifactGC) — TF-IDF не нашёл целевые файлы в топ-10
- Arm B промахнулся: R1 (begin_write), R2 (ArtifactGC), R7 (LLAMA_EMBED_MAX_TOKENS) — символы не найдены в графе (не являются функциями/классами в AST-парсинге)
- Arm B потребил на 43% меньше токенов (170K vs 302K)
- Arm B при промахах возвращает 0 файлов (нет начального символа = нет обхода)

**Вывод:** Для нашего корпуса chunked retrieval (TF-IDF) превосходит графовую навигацию по hit rate при большем расходе токенов. Графовая навигация эффективнее по токенам, но ограничена наличием начального символа в графе. Гипотеза Tom Jones о превосходстве NodeRAG на длинных документах с правилами внутри **опровергнута** для данного корпуса.

**Артефакты:** `experiments/noderag/results/results.json`, `experiments/noderag/results/graph.db`, `experiments/noderag/frozen/rules.jsonl`

## [2026-09-27] — Closure-walk: personal-path guard certifies the wrong set (CONFIRMED + FIXED)

**Гипотеза:** `tests/test_no_personal_paths.py` зелёный, потому что его scope — только human-facing docs; пути и username остаются в tracked-файлах вне scope (experiments/scripts/tests/data). Guard, сертифицирующий неправильное множество, — «a true statement about the wrong set» (Tom Jones, hooks thread).
**Команда:** `python experiments/closure_walk/closure_walk.py`
**Сырой вывод (до фикса):**
```
integrity_clean=True failures=0
in_scope_files=0 out_scope_files=98
out_scope_violations=4699
positive_hit=True none_clean=True
```
**Распределение:** experiments 4633, tests 29, docs 16, scripts 11, src 6, .local 4.
**Вердикт:** CONFIRMED. 4699 утечек в 98 файлах вне scope; guard зелёный только потому, что не смотрит туда.
**Фикс (ea715903):** 17 production-утечек нормализованы (src/: 6, scripts/: 11). `graph_tools.py:825` заменён на `self._resolve_target_path(None)`. Осталось 4633 в experiments/ (исторический контекст).
**Контролы:** planted leak найден, repo-relative пути не флагнятся.

## [2026-09-25] — E18: graph write throughput — per-entity transaction vs batched (CONFIRMED)

**Гипотеза:** `PropertyGraph.add_node/add_edge` открывают ОДНУ SQLite-транзакцию + named-mutex на каждый узел/ребро (`graph.py:526-544, 816-851`) → graph-сборка сериализована и I/O-bound; это root cause «CPU 5% + диск ~3 МБ/с» на фазе parsing.
**Команда:** `<ext-venv-python> experiments/misc_probes/exp_graph_write_throughput.py` (4 руки, temp-БД, одинаковый INSERT SQL).
**Сырой вывод (после фикса, arm D = реальный `PropertyGraph.batch()`):**
```
N_NODES=2000 N_EDGES=4000
A per-call PropertyGraph (mutex+txn) : 20.58s    194 entities/s
B raw, ONE transaction+reused       :  0.03s 140875 entities/s
C raw, per-node transaction         : 16.89s    237 entities/s
D PropertyGraph.batch() [the fix]   :  0.15s  26826 entities/s
speedup D/A (the fix) = 138.0x ; speedup B/A = 724.8x
negative control counts equal: True -> [(2000, 2000)]
```
**Вердикт:** CONFIRMED. Per-row commit/fsync — доминанта; named-mutex добавляет ~35%. Отрицательный контроль — counts идентичны (нет порчи). Внешний baseline совпадает: SQLite 429 rows/s отдельными транзакциями vs 2.457M rows/s (одна транзакция+reused) — voidstar.tech.
**Фикс внедрён (2026-09-25):** `PropertyGraph.batch()` (одна tx на файл) + `indexer._parse_file_only` оборачивает graph-update файла; измерено **138× на реальном API**. Guard: `tests/test_graph_batch.py` (counts/атомарность/вложенность/персистентность).
**Live-контроль (job 268ac11b, 2026-09-26):** первая попытка на `batch()` **упала на finalize** (`cannot start a transaction within a transaction` в `GraphSymbolResolver.resolve_all`): `batch()` хранил состояние глобально, а parse идёт в 4 потока — файлы делили одну транзакцию. Фикс: владелец батча по thread-id (`_batch_owner`); чужой поток не присоединяется, а блокируется и получает свой батч (проверка и в add_node/add_edge/delete_node). Guard: `test_concurrent_batches_do_not_share_a_transaction` (Barrier, 2 потока, без OperationalError, counts). Повторный прогон → **completed 603с, 10106/10106**, path-dup 0.

## [2026-09-20] — E13 / поискочное качество: 6 исследовательских задач (план)

**Статус:** Plan (код не тронут; задачи в ISSUE.md KI-R1..R6)
**Контекст:** E13 (doc-chunks vs code-chunks) замерен — hit@1=12.5%, hit@5=12.5% против code baseline 20/50%. Проблема: измерение неполное, выводы преждевременные.
**Задачи (по порядку):**
- KI-R1 (P1): перезапуск exp-5 после KI-101 (cache-hit пропускал dense-уровень) + gold_chunk_id Recall@5 + наборы 10→16+.
- KI-R2 (P1): два прогона E13 — intent_hint="docs" (маршрутизация) + doc-only индекс (перекос корпуса).
- KI-R3 (P2): «найдено N / использовано M» + eligible_seen в интерфейсе.
- KI-R4 (P2): регрессионный тест дедупликации (MMR vs sort, SCT Inst).
- KI-R5 (P2): фильтр лексической ветки вместо RRF (threshold по чанкам/терминам).
- KI-R6 (P2): housekeeping — 7×exp-29 на Lab, дубли архива дневника, README числа.
- KI-R7 (P2): авто-замер — gold_chunk_id из индекса → Recall@5 в get_health_report.
- KI-R8 (P2): дедупликация по хешу (vendored/переводы/CHANGELOG), оба пути в цитате.
- KI-R9 (P2): не подбирать один режим — vector+BM25 снизил recall у нас, hybrid проиграл vector у автора.
- KI-R10 (P2): слабый запрос → не молчать, fallback grep (exp-26).
- KI-R11 (P2, первым): «найдено N / использовано M» + «проиндексировано ли».
**Вердикт:** без R1+R2 публичные утверждения некорректны. R1+R2 дешёвые — делать первыми.
## [2026-09-18] — E7: lazy stat-sweep vs sha256-sweep (FreshnessChecker) для «всегда актуального» индекса

**Гипотеза:** stat()-сверка (mtime+size) по корпусу проекта на порядки дешевле существующего FreshnessChecker (SHA256 каждого файла), поэтому её можно выполнять при каждом поиске без заметной стоимости и закрыть KI-109 (новый файл невидим индексу без notify_change).

**Команда:**
`
python experiments/freshness_lazy/measure_stat_vs_hashes.py
`

**Сырой вывод:**
`
honest corpus: 545 files
  stat sweep run1: 11.71 ms
  stat sweep run2: 13.21 ms
  stat sweep run3: 10.11 ms
sha256 sweep: 214.8 ms
ratio sha256/stat: 21.3x
mean stat per file: 18.55 us
projected stat for 574 indexed files: 10.6 ms

full INDEX_EXTENSIONS corpus: 1100 files
  stat sweep full corpus: 17.83 ms
  mean stat per file: 16.21 us
`

**Verdict:** HYPOTHESIS CONFIRMED. stat-сверка по ПОЛНОМУ корпусу INDEX_EXTENSIONS (1100 файлов) = 17.8ms — в 12× быстрее sha256 по .py (214.8ms), ~2% от полного reindex (5s), ~6% от quality-поиска (~300ms).

**Implication:** lazy stat-проверка жизнеспособна как дефолтный механизм актуальности: Point A (сравнение mtime+size файла-кандидата перед возвратом в поиске) стоит миллисекунды и не читает содержимое файлов до несовпадения. Требование к схеме: добавить file_mtime/file_size. При старте: статистическая сверка позволяет заменить условие «индекс пуст» на «есть ли новые/изменённые файлы».

**Artifacts:** experiments/freshness_lazy/measure_stat_vs_hashes.py; // EXP_LOG Exp 7.

## [2026-09-11] — 1-B/1-C/RT: burst-rename vs fail-closed VOR (ответ Statewave)

**Гипотеза (вопрос dev.to «How large does that queue get in practice?»):** после ОДНОГО refactor-коммита с массовыми move/rename fail-closed VOR (ADR-0003, path-якоря) отзывает ВСЕ затронутые узлы (queue = 100%), хотя файлы живы — это ложные отзывы; body-hash-якорь (limpet/OpenLore) переживает rename без потерь.
**Команда:**
```
python experiments/1V_memory_contamination/burst_rename_audit.py   # реальная память (24 авто-REFUTED)
python experiments/1V_memory_contamination/burst_sweep_exp.py      # синтетика: 30 файлов, git mv, 1 коммит
python experiments/1V_memory_contamination/redteam_burst.py        # 3 атаки (batch-hazard/starve/present-trap)
```
**Сырой результат:**
```
[1-B реальная память] авто-REFUTED=24: anchor_junk 13, TRUE_REFUTE_deleted 10, FALSE_REFUTE_renamed 1 (9.1%)
  ADR-7232a6e2ba34 FALSE_REFUTE_renamed src/utils/paths.py -> adapters/local_fs/windows.py (git R083)
[1-C синтетика N=30] Baseline A: VERIFIED 30/0 REFUTED. Sweep B (git mv src/mod src/moved):
  After sweep: VERIFIED 0 REFUTED 30/30 (100%)  |  body-hash carry: 30/30 (100% уцелели)
[Red-Team-1 batch-hazard] коммит e661861f = D(adapters/local_fs/__init__.py) + R083(windows.py): «исчезли скопом = move» спас бы и правду, и удаление
[Red-Team-3 starve] бюджет 0.05ms @ N=40: checked=1 inconclusive=39 budget_exceeded=39
[Red-Team-4 present-trap] файл пересоздан на том же пути с другим телом: path-anchor VERIFIED (протух), body-hash честно delete+add
```
**Вердикт:** подтверждена частично. Очередь в практике = не огромная (24 накопленных авто-отзыва за месяц), но ДОМИНИРУЕТ мусор якорей (13/24: import:for/filter/maps, pkg:name/-), а не renames. Настоящие renames дали 1 ложный отзыв (ADR-7232a6e2ba34 — узел жив, якоря adapters/zed/*.py + src/main.py существуют; отозван по СТАРОМУ пути из prose тела). Синтетика показывает паттерн: один rename-sweep = 100% очереди. **Урок:** батч по коммиту НЕ решает — он смешивает move с delete (e661861f); нужна body-identity (exact-body/exact-signature, OpenLore PR#206) или уточнённый reviewer: сравнение failed-якоря против R*-src в git-истории (rename_sources в audit). Связь: ADR-0003, OpenLore#206, limpet (AST body-hash).

## [2026-08-05] — Neuro-Symbolic spike: NL → LLM → Cypher → parser+schema → PropertyGraph (exp-lab-2026-01)

**Ожидание:** связка (LLM-генерация Cypher + двухслойная валидация parser+schema + исполнение) отсекает невалидные генерации ДО исполнения: 10 вопросов → 8 исполнимых + 2 отсечённых (галлюцинированная метка SERVICE, функция cycle()).
**Команда:** `python experiments/neuro_symbolic_spike.py` (MockLLM, без сети; `--lm-studio` — реальный phi-4, не мерился — LM Studio не запущен).
**Сырой результат:**
```
Что вызывает main?     -> EXEC ok (2 rows)
Какие функции используют config? -> EXEC ok (1 rows)
Сколько функций в графе? -> EXEC ok (5 rows)
Есть ли цикл в графе?  -> SCHEMA-REJECT: empty RETURN (parser ignored expression)
Какие сервисы есть?    -> SCHEMA-REJECT: unknown label :SERVICE
=== METRICS === total=10 parse_ok=8 rejected_by_parser=0 rejected_by_schema=2 exec_ok=8 exec_error=0 latency avg=0.1 ms
VERDICT: HYPOTHESIS SUPPORTED (3-layer validation)
```
**Вердикт:** подтверждена с оговоркой — parser-слой ОДИН не ловит галлюцинации (SERVICE — синтаксически валидно; cycle(a) → parser молча return_items=[]); schema-слой закрыл оба. FINDINGS по Cypher-стеку: (1) label case-sensitive — MATCH (f:FUNCTION)→[] при хранимом 'Function'; (2) count() → SQLite "near *"; (3) CypherExecutor глотает SQL-ошибки → тихий []; (4) parser игнорирует RETURN-вызовы функций.
**Урок:** parser-валидация ≠ исполняемость — нужен schema-слой (метки/связи/functions против схемы графа); это общий паттерн text-to-cypher (schema-aware prompting). Баги executor'а — кандидаты в KNOWN_ISSUES (вне скоупа спайка). Связь с отрицательными: не из таблицы §3.8.

## [2026-08-21] — B-1 Manifest parity vs osv-scanner: гейт нашёл и закрыл 3 дыры

**Гипотеза (Вариант В спеки 07):** выхлоп наших экстракторов манифестов == osv-scanner
v2.5.1 на корпусе e-s1-polygon; расхождение = дыра в нашем парсере (не «osv правее»).
**Команда:** `python scripts/manifest_parity.py --osv <osv-scanner.exe v2.5.1>` (канон-имена,
свежий tmpdir на проверку, каталог-режим для пар manifest+lockfile).
**Сырой результат (финальный):** `✅ Parity: расхождений 0` (12 каталогов, 2 skip
документированы, 8 allowed-diffs с причинами). **Первый прогон: 11 расхождений.**
**Найденные дыры (закрыты в тот же день):** (1) bun.lock v1 trailing commas — json.loads
падал → экстрактор молча пусто (0→62 имён); (2) yarn berry: patch-дескрипторы давали мусор
«resolve@patch:resolve», склейки `, ` и `||`-диапазоны дропались (256 имён), псевдонимы
эsbuild@npm:esbuild-wasm@… — имя из resolution (version: идёт раньше resolution:),
пробелы в версиях `>= 2.1.2 < 3` ломались фильтром по пробелам; (3) workspace-локальные
`@workspace:` исключены из registry-пула (как osv).
**Вердикт:** подтверждена; гейт в CI (manifest-parity джоба) — guard против «думаем,
что парсим». **Урок:** osv не сканирует ОДИНОЧНЫЕ манифесты без lockfile-пары
(«No package sources found») и резолвит `-e .[socks]` в транзитивный граф — семантика
разных инструментов ≠ «мы неправы»; леджер allowed-diffs обязателен.
Связь: ADR-0005 (B-1 scaling), KNOWN_ISSUES#2026-08-19-B1.

## [2026-08-19] — E-09: upload-bomb защита GitUrlSource (Фаза 2 / ТЗ §4 DoS)

**Гипотеза:** post-clone лимиты GitUrlSource (`_post_clone_checks`) отклоняют оба DoS-вектора upload-bomb — размер и число файлов — машинным kind (→ INCONCLUSIVE), а не крашатся; OK-путь в лимитах чист; редирект-подмена origin блокируется. **Команда:** `python experiments/universal-engine/e09_upload_bombs.py` (локальные деревья без сети, пониженные лимиты).
**Сырой результат:**
```
too_large:    PASS (kind=too_large)
too_many:     PASS (kind=too_many_files)
ok-path:      PASS (не бросает)
redirect:     PASS (domain_not_allowed)
E-09: 4 cases — 4 PASSED, 0 FAILED → SMOKE E-09: PASSED
```
**Вердикт:** подтверждена — upload-bomb gate корректен; Фаза 2 (GitUrlSource) полностью закрыта.
**Урок:** post-clone лимиты = вторая линия обороны (после SSRF-пред-проверок в `_parse_url`/`_resolve_and_check_ips`); дешёвые локальные деревья достаточно для проверки механики (500MB-клоны не нужны). Связь: ТЗ §4 «ограничение размера/объёма при клонировании».

## [2026-08-19] — E-05: ActionReceipt `reproducible_by` на реальных действиях (ТЗ §11.5 этап 3 / §12.3)

**Гипотеза (§12.3):** `reproducible_by` воспроизводится 1:1? Или, как с temporal-git-provenance, «очевидно полезное» поле на практике не работает как задумано. **Команда:** `python experiments/universal-engine/e05_action_receipt.py` (реальные действия в чистом temp: file_write с реальными SHA-256, git_commit в чистом репо, git_push status, index_sync). Для каждого: build_receipt → store.record → store.get → выполнить reproducible_by → сравнить вердикт.
**Сырой результат (после фикса):**
```
action       verdict      repro_verdict  result
file_write   VERIFIED     VERIFIED       PASS
git_commit   VERIFIED     VERIFIED       PASS
git_push     VERIFIED     VERIFIED       PASS
index_sync   INCONCLUSIVE INCONCLUSIVE   PASS
Store round-trip (E05-git1): PASS
E-05: 4 cases — 4 PASSED, 0 FAILED  →  SMOKE E-05: PASSED
```
**Находка (первый прогон 2/4):** `verify_git_commit`/`verify_git_push` хардкодили cwd ПРОЦЕССА — `git log` шёл в MSCodeBase (коммит 381e41bd), а не в тестовом репо → reproducible_by в др. cwd → mismatch вердиктов. Рovno опасение §12.3 подтвердилось.
**Фикс:** verify_git_commit/push принимают `cwd=` (backward-compat); `reproducible_command(.., workdir)` кодирует `git -C <dir>`; `ActionReceipt.workdir`; `build_receipt(workdir)`; `verify_action` резолвит project_root. **Вердикт:** подтверждена с оговоркой — reproducible_by работает 1:1 ТОЛЬКО с явным workdir для git-типов; receipt стал самодостаточным.
**Урок:** verify и reproduce в разных cwd «выглядят правильно», но вердикты расходятся — unit-тест (cwd процесса) это не различает, нужен реальный E-05 с изолированным окружением. Связь: present-trap / «очевидно полезное ≠ работает» KI-2026-08-11.

## [2026-08-19] — Exp: LIVE vendor test — basedpyright (real pyright fork) LSP features

**Гипотеза:** Нереальный сервер даст «правду»: какие LSP-фичи графа реально доступны на Python. Ожидали: call hierarchy + semantic tokens работают; type hierarchy 3.17, moniker и gate индексации — «возможно». **Команда:** `pip install basedpyright` (venv, без npm) → `venv/Scripts/python.exe experiments/lsp/lsp_live_pyright.py` (real `basedpyright-langserver --stdio`, fixture в experiments/lsp/fixture).
**Сырой результат:**
```
INIT: serverInfo = {name: basedpyright, version: 1.39.10}
callHierarchyProvider: True   typeHierarchyProvider: None
semanticTokensProvider: {... full:True ...}   monikerProvider: None
call hierarchy: prepare report -> outgoing [ShapeManager,total_area,build] + incoming [main]  (ranges точные)
semantic tokens: 62 токена, delta-encoded, result_id=1787169556049
indexing gate: pyright/beginIndexing/endIndexing НЕ наблюдались (только window/logMessage за 8s)
```
**Вердикт:** ЧАСТИЧНО ПОДТВЕРЖДЕНА, с важными негативами: на реальном pyright-форке работают ТОЛЬКО call hierarchy и semantic tokens. Type hierarchy (3.17), moniker (3.16) и pyright/beginIndexing-гейт на базе pyright НЕ доступны — это опровергает их «теоретическую» доступность из прошлой записи (spec-true, но server-false для этого вендора).
**Урок:** (1) «В спецификации есть feature» ≠ «сервер реализует feature». Проверять НА ЖИВОМ сервере (это и был смысл эксперимента). (2) Для Python-индекса графа реальны: call hierarchy (cross-file рёбра CALLS с точными ranges) и semantic tokens. (3) Реализация тонкого клиента поверх запиненного lsprotocol — `src/core/lsp_client.py` (capability-agnostic), демо `experiments/lsp/lsp_client_demo.py`: CALLS edges `report->ShapeManager/total_area/build` (в т.ч. `print->builtins.pyi`), демо-декодер semantic tokens. (4) Побочный артефакт: `basedpyright` установлен в venv (не в requirements) — dev-tool эксперимента, при желании `pip uninstall basedpyright`.

## [2026-08-19] — Exp: LSP wire probe — advanced features for the code knowledge graph

**Гипотеза:** Заявленные LSP «скрытые» возможности для графа кода реальны и воспроизводятся на проводе: (1) 2-фазный call hierarchy с непрозрачным `data`-кэшем (prepare → incoming/outgoing); (2) type hierarchy 3.17 (prepare → supertypes/subtypes); (3) semantic tokens `[dLine,dStart,len,typeIdx,mods]` одной пачкой; (4) `$/progress` как gate индексации; (5) вендор-методы (rust-analyzer/expandMacro) → -32601 MethodNotFound (graceful degradation). Проверка на запиненных `lsprotocol==2025.0.0` (+cattrs) — реальный Content-Length-framed JSON-RPC round-trip, без сети/внешнего сервера.
**Команда:** `venv/Scripts/python.exe experiments/lsp/lsp_wire_probe.py`  (исток — `experiments/lsp/`). Схемы типов — `from lsprotocol import types` + `__annotations__`.
**Сырой результат (ключевое):**
```
initialize.capabilities: {callHierarchyProvider:true, typeHierarchyProvider:true, semanticTokensProvider:{legend…, full:true}}
prepareCallHierarchy → data:{opaque:ctx-v1,id:42}  (data: typing.Any|None в схеме)
incomingCalls/{item:…с тем же data} → assert id==42 прошёл (server отвечает ИЗ кэша data, без reparse)
typeHierarchy subtypes → [Circle(Shape), Square(Shape)]
semanticTokens/full → data:[0,0,5,1,0, 0,6,4,0,0, 0,3,1,1,2, 2,0], resultId:tok-1
mock/emitProgress → <-- notification: $/progress {token:idx-123, value:{kind:begin,title:indexing}}
rust-analyzer/expandMacro → {code:-32601, message:Method not found: rust-analyzer/expandMacro}
WIRE PROBE: PASSED (exit 0)
```
**Вердикт:** ГИПОТЕЗА ПОДТВЕРЖДЕНА для стандартной части. Wire-механика (framing, JSON-RPC, camelCase на проводе: selectionRange/resultId/fromRanges, типовая сериализация через converters.get_converter()) воспроизведена на запиненной версии. `data`-кэш работает round-trip. Вендор-методы НЕ в спецификации: спецификация требует `-32601` для неизвестных `$/`-методов и «сервер может игнорировать» неизвестные capabilities — это легальный extension-point для vendor-методов (корабли не проверялись: живых rust-analyzer/pyright/tsserver в среде нет).
**Урок:** (1) Реальный инцидент в самом эксперименте — self-echo deadlock из-за неверной топологии пайпов (клиент читал собственный request): пойман таймаутом `timeout 15`, не гаданием; фикс — 2 одно-направленных пайпа fwd/back. (2) Граф-полезные LSP-фичи РЕАЛЬНО доступны через запиненный lsprotocol: `moniker` (3.16) — стабильный cross-language id символа (unique: document/project/group/scheme/global) → сильный кандидат для рёбер индекса; `data`-кэш; semanticTokens как быстрый символьный масс-экстрактор. (3) Ограничение: vendor-ветка (expandMacro/checkCompleted/navtree) не проверялась на живом сервере — сети на установку pyright/rust-analyzer нет (sandbox).

## [2026-08-17] — Exp: кластер циклических импортов MCP — E1 инвентаризация + E2 import-time + E3 прототип (гибрид A+B → 0 циклов)

**Гипотеза (H1-E3):** 24/29 «циклических зависимостей» ARCLUX в src/mcp/ — один гигантский сильно-связный компонент (SCC), но ВСЕ циклы runtime-безопасны (lazy/без import-time использования); контрольный инструмент — собственный AST-инвентарь (SCC + классификация lazy/load + fresh-interpreter import test), та же методика до/после. Гибрид (реэкспорты→core + runtime-состояние→новый src/mcp/context.py) должен разорвать SCC до 0 без сломатестов и без роста import-time.
**Исследование:** Real Python «Handle Cyclical Imports» — (1) циклы безопасны, если модули не используют друг друга на import-time (только определяют функции); (2) три стратегии: разорвать дизайном, держать модули без side-effect'ов, lazy-import внутри функций; (3) опасность цикла — AttributeError частично инициализированного модуля. Наши 24/29 — «дружественные» lazy-циклы; граф module-level рёбер ацикличен, fresh-импорт всех модулей OK.
**Команды (E1/E2/E3):** `python experiments/arclux_cycles_inventory.py`; `python experiments/imp_time_bench.py`; правки 9 файлов (6 tools + server + factory + server_tools + новый context.py); `python experiments/arclux_cycles_inventory.py` повт.
**Сырой результат (E1 baseline → E3 после):**
```
ДО:   Модулей 20 | SCC: 1 (19 модулей) | рёбер в циклах 77 | load-рёбер 17 (модульных) | import-test: все OK
ПОСЛЕ: Модулей 21 | SCC: 0 | рёбер в циклах 0 | import-test: все OK (вкл. context)
import-time (медиана 7, свежий процесс): indexing_tools 421→452ms; meta 421→457ms; server 93→102ms; project_resolution 91→99ms
архитектурный linter: TOOL_REGISTRY 4→0 (CORE_MCP 0); pytest 1294 passed / 10 skipped / 91 deselected; ruff clean
```
**Вердикт:** ГИПОТЕЗА ПОДТВЕРЖДЕНА. Гибрид разрывает ВЕСЬ кластер (19-модульный SCC → 0; все 77 рёбер цикла убраны). import-time: +7% в пределах run-to-run шума (min/max ±15%), достоверного роста нет — доминирующая стоимость не server (93ms), а тяжёлая core-цепочка через tools/base.py (di_container→indexer→embedder), которую ни A ни B не трогают. Архитектурный linter и полный pytest зелёные.
**Урок (§3.8/§6.6 п.4):** «24/29 циклов» ARCLUX в этой кодовой базе НЕ воспроизводятся текущим ARCLUX-head (doctor/verify циклы не показывают; 356→357 issues — только счётчик орфанов); воспроизводимая метрика — собственный SCC-инвентарь. Цена полного разрыва кластера низкая (9 файлов + 1 новый, нулевой рост старта) → гибрид дешевле, чем «оставить как есть + ADR». Вариация провального подхода: отсутствует (это первый замер этого кластера).

## [2026-08-15] — Exp 1-L Day 3: per-category метрики (ответ на ревью) + V3/Part 5 CoT vs Zero-Shot

**Гипотеза (из ревью Part 4):** (1) FA=0.00 у qwen3.6/3.7 может быть «ленивой моделью» — она режет
вместе с ложью и правдивую память; нужен True Accept на категории real. (2) Запрет reasoning
измерил калибровку alignment, не способность верификации — CoT должен изменить картину.
**Команда (A):** `python scripts/summarize_1L_categories.py --tag v2_en` (новый скрипт-агрегатор
per-category; read-only к progress-файлам, 0 новых вызовов). **Команда (B, live):**
`python scripts/run_1L_live_arm.py --provider openrouter --arm both --models
"qwen/qwen3.6-flash,qwen/qwen3.7-flash,z-ai/glm-4.7-flash,deepseek/deepseek-v4-flash"
--prompt-version v2 --reasoning --max-tokens 1500 --delay 0.2 --tag v3_cot`
(новый флаг `--reasoning` в harness; 400 вызовов, ~$0.20, err=0 на qwen3.7/deepseek).
**Сырой результат (A, zero-shot V2-EN, recall(real)/FA по категориям):**
```
qwen3.6 code_first: real acc=2 rej=7 unk=16 | recall=0.08 | FA absent 0/16 trap 0/6 silent 0/3
qwen3.7 code_first: real acc=5 rej=9 unk=11 | recall=0.20 | FA 0/0/0
claude  code_first: real acc=11 rej=0 unk=14 | recall=0.44 | FA 0/0/0
glm-4.7 code_first: real acc=22 rej=1 unk=2  | recall=0.88 | FA 7/16 3/6 2/3
nemotron-lightning code_first: recall=0.52 | FA 0/1/1
```
**Сырой результат (B, CoT vs Zero-Shot):**
```
модель             arm        recall ZS->CoT   FA ZS->CoT     ct/выз. ZS->CoT
qwen3.6-flash      code_first 0.08->0.20       0->0           11->813
qwen3.7-flash      code_first 0.20->0.16       0->0           9->770
glm-4.7-flash      code_first 0.88->0.72       12->7          10->1007  (26% EMPTY_CONTENT)
deepseek-flash     code_first 0.04->0.08       0->0           8->186
стоимость/100 выз.: qwen3.6 $0.0006->$0.039, qwen3.7 $0.0005->$0.005, glm $0.001->$0.017
```
**Вердикт: ✅ (A) подтверждена и усилена — FA=0.00 = fail-closed, а не фильтрация.** qwen3.6
code_first принимает 2/25 правды, активно отвергает 7/25 (ложные REFUTED), 16/25 unknown;
recall(real)=0.08. **✅ (B) частично: CoT НЕ окупается для дешёвого VOR.** Единственный заметный
выигрыш — qwen3.6 code_first recall 0.08→0.20 (FA 0.00 сохранена); glm FA 12→7, но recall
0.88→0.72 и −26% данных (EMPTY_CONTENT апстрима, finish=stop). qwen3.7/deepseek — шум. Токены
×20–70, цена ×30–65 — при нулевом/малом выигрыше у 3 из 4 моделей.
**Урок:** (1) «0.00 FA» без recall — не метрика качества guardrail: выбор qwen3.6/3.7 = политика
fail-closed (память не будет подтверждаться), glm = max-coverage (правда сохраняется, ложь
протекает). Выбор модели — выбор политики, должен быть явным. (2) CoT у дешёвых flash-моделей не
даёт скачка способности верификации — рекалибровка, а не мышление. (3) reasoning.enabled=true у
glm-4.7-flash — апстрим-дефект (EMPTY_CONTENT 26%) — при CoT-прогонах нужен контроль error-счётчика.
**Связь с отрицательными:** нет. Артефакты: progress-файлы v3_cot, scripts/summarize_1L_categories.py
+ 8 тестов, флаг --reasoning + 2 теста, отчёт experiments/1L_live_arm/report.md §6.5/6.6/§11/§13.

## [2026-08-15] — Exp 1-L Day 3b: CoT run2 (стабильность) + qwen3.8-max (follow-up по команде владельца)

**Гипотеза:** (1) CoT-выводы Day 3 однопроходные — 2-й прогон должен подтвердить/опровергнуть разброс; (2) qwen3.8-max (единственная модель с mandatory reasoning) в CoT-режиме закроет пробел §13 п.5 и, возможно, даст лучший баланс recall/FA.
**Команда:** `python scripts/run_1L_live_arm.py --provider openrouter --arm both --models "qwen/qwen3.6-flash,qwen/qwen3.7-flash,z-ai/glm-4.7-flash,deepseek/deepseek-v4-flash" --prompt-version v2 --reasoning --max-tokens 1500 --delay 0.2 --force --tag v3_cot_run2` (400 выз., ~$0.20) + `--models "qwen/qwen3.8-max" --tag v3_cot_max` (100 выз., ~$0.10; err=0 на всех).
**Сырой результат (run1→run2, recall(real)):**
```
qwen3.6 mem 0.48->0.40 (FA 0->0) | code 0.20->0.12 (FA 0->0)
qwen3.7 mem 0.44->0.40 (FA 0->0) | code 0.16->0.16 (FA 0->0)
deepseek mem 0.20->0.20 (FA 2->2) | code 0.08->0.12 (FA 0->0)
glm     mem 0.12->0.08 (EMPTY 18->7 err) | code 0.72->0.68 (EMPTY 8->9 err)
qwen3.8-max: mem recall 0.28 FA 0 | code recall 0.36 FA 2 (trap 1 + silent 1), err=0, ~$0.10
```
**Вердикт: ✅ обе части.** (1) CoT-выводы устойчивы: разброс recall ±0.04–0.08 (шум N=50, CI ±0.14), FA qwen3.6/3.7 = 0.00 в обоих прогонах; glm EMPTY-дефект воспроизводится (16–26%), её CoT-числа только качественные. (2) qwen3.8-max — **лучший code_first recall в свипе (0.36) при FA 0.04**, err=0: срединная опция «не терять живую память» vs fail-closed qwen3.6 (0.08–0.20/0.00); цена ×20–200 от flash, единственный режим CoT.
**Урок:** для VOR-выбора модель+режим — это континуум «цена × recall × FA»: qwen3.6 (0/0.08–0.20/$0.0006) → qwen3.8-max (0.04/0.36/$0.10) → glm-4.7 (0.24/0.88/$0.001, но лжёт); выбор = политика, не «лучшая модель». Фикс скрипта: фильтр --tag по config.tag (был prefix-матч, захватывал run2).
**Follow-up (2026-08-15): ревью-ответ 5 «точек укуса» + серверный аудит CSV.** Экспорт дашборда OpenRouter (`experiments/openrouter_activity_2026-08-15.csv`, ключ test567, отфильтрован от 56 записей приложения MSPortfolio): 4087 записей эксперимента, $0.72 за день — сходится с клиентской оценкой; серверные tokens_reasoning подтверждают reasoning>0 ТОЛЬКО в CoT-прогонах (claude 0/100 при --no-reasoning); **маршрутизация ≥8 апстримов (Alibaba 1955, DeepInfra 559, DigitalOcean 531, Cloudflare 283, Novita 253, Baidu 114, StreamLake 110, Bedrock 100)** — серверное подтверждение «иллюзии детерминизма» (точка укуса №1). Пять точек (детерминизм K≥3 / anchor bias / реальный дрифт / single-language / 3-значный каркас) добавлены в отчёт §11.1 со статусами 🟡/🔴 и честной ценой закрытия ($2–5, 1–2 дня) — осознанный техдолг, не умолчание.
**Связь с отрицательными:** нет. Артефакты: progress-файлы v3_cot_run2/v3_cot_max, отчёт §6.6a/§7/§11.1/§13, тест фильтра tag (+1, 39 всего).

## [2026-08-14] — EXP: перенос evalmut-подхода (mutation testing for eval graders) на validate_scores — mutation score 8%

**Гипотеза:** evalmut-техники (инвариант «дыра = вывод доказанно неверен AND градер пропустил», decline-дисциплина против объявленного контракта, corroboration двумя непересекающимися входами) применимы к детерминированному градеру MSCodeBase и находят реальные дыры без false positives.
**Команда:** `venv/Scripts/python.exe experiments/evalmut/probe_evalmut_transfer.py` — 12 мутаций по каталогу evalmut (adapt к контракту validate_scores: index int, score float в [0,1]).
**Сырой результат:**
```
mutation score: 1/12 caught (8%)   |   BLIND SPOTS: 11
  NaN score            -> [{'index': 0, 'score': 1.0}]  ← min(1.0, NaN)=1.0: МАКСИМАЛЬНЫЙ скор
  Infinity score       -> 1.0;  -Infinity -> 0.0
  float index 2.7      -> int() -> 2 (тихая порча индекса)
  index=-1 / index=99  -> проходят (скор теряется молча)
  regex-path (попытка 4) -> score=99.0 БЕЗ clamp (неконсистентность путей 1-3 vs 4)
  «пример формата» в объяснении LLM -> принят как реальный скор (regex-путь)
  дубликат индекса    -> тихая перезапись (coverage gap)
  NaN/Infinity через json.loads -> парсится (Python принимает по умолчанию)
правильно скоупленная проверка: score=2.5 -> clamp 1.0 = OK (эквивалент, НЕ дыра)
corroboration: 2 структурно-непересекающихся мусора -> [] (градер не vacuous)
tests/test_reranker.py: 25 passed — дыры не покрыты
```
**Вердикт: ✅ подтверждена.** Подход находит реальные дыры (11) в живом градере и не даёт false positives на правильно-скоупленной проверке (clamp).
**Урок:** (1) isinstance-проверка типов НЕ ловит NaN/Inf — нужен math.isfinite() (прецедент уже есть: error_handler.py:707 _sanitize); (2) все пути парсинга должны иметь ОДИН контракт (regex-путь без clamp = дыра); (3) «пример формата в объяснении» — общий класс дыр regex-извлечения из текста LLM.
**Связь с отрицательными:** нет (первый прогон подхода в репо). Скрипт: experiments/evalmut/probe_evalmut_transfer.py (воспроизводим).
**ПОСТ-ФИКС (2026-08-14 16:20):** те же 12 мутаций после фикса → mutation score 8% → 100% (11/11 с полюсностью), BLIND SPOTS: 0; index_out_of_range/duplicate классифицированы как вне контракта validate_scores (N неизвестен / уникальность — ответственность парсера+apply_scores: decline на обёртке и warning на осиротевших индексах). Полный pytest 1189 passed; ruff clean.

## [2026-08-14] — Exp 1-L Day 1 (live-arm): вердикты живой модели (opencode + deepseek-v4-flash-free) по 50 фактам 1-V

**Гипотеза (из ревью Part 3):** «детерминированный proxy-агент вместо живой модели — с живой моделью цифры будут другими, возможно сильно другими». Ожидание: adoption/ложные отзывы живого LLM ≠ 0.16/0.24 proxy.
**Команда:** `python scripts/run_1L_live_arm.py --driver opencode --arm both --limit 50 --model opencode/deepseek-v4-flash-free --delay 2 --resume` (OpenCode Zen, free-тир; ключ из .env; 100 вызовов, дриблинг по окнам лимита free-тира).
**Сырой результат (дедуплицирован по id, errors=0, n=50 на руку):**
```
memory_first: adoption=0.200 false_accept=0.100 true_accept=0.100 unknown=0.800 accuracy(decided)=0.500
  FALSE-ACCEPT ids: [R28, R30, R31, R33, R42]
code_first:   adoption=0.200 false_accept=0.100 true_accept=0.100 unknown=0.800 accuracy(decided)=0.500
  FALSE-ACCEPT ids: [R26, R31, R45, R47, R50]
```
**Вердикт: ✅ подтверждено.** Цифры живой модели радикально отличаются от proxy 1-V: (1) proxy всегда решал (unknown=0), живая модель — **unknown=0.80** (честная неопределённость без кода/даже с якорями); (2) proxy false-accept=0 by construction, живая — **false_accept=0.10** (5 ложных утверждений приняты, R31 — в обеих руках) — риск контаминации реален; (3) accuracy(decided)=0.500 при N=10 решённых — малая выборка, требуется больше данных (1-L продолжается).
**Оговорки:** модель — free-тир Zen (не Claude/GPT-4o из ревью; harness поддерживает --model для других); 80% unknown частично отражает дизайн промпта memory_first (только claim без кода) — но это и есть измеряемое свойство «доверяет ли память без кода».
**Урок:** критика ревью подтверждена данными — headline-числа 1-V были свойством эвристики, не поведения LLM; 1-L live-arm теперь даёт реальную базу (Part 4 статья). Связь: docs/blog/verify-on-read.md, experiments/1L_live_arm/design_longitudinal.md.

### Вскрытие R31 + кластер ложных принятий (2026-08-14, после Day 1)

**Факт R31:** «Сканер инструкций использует typesense» (truth=False, kind=mutation_absent), support_patterns=`["typesense"]` — ГОЛЫЙ ТОКЕН, contra=`[file:src/core/instruction_scan.py]`.
**Кодовая правда:** typesense отсутствует во ВСЁМ проекте (grep src/ + pyproject + requirements = пусто); instruction_scan.py использует только stdlib (re/logging/typing).
**Почему ложно принят в обеих руках:** memory_first — модель видит правдоподобный claim без кода и решает «true»; code_first — модель видит «supporting anchors: typesense» и принимает голый токен за evidence. Прокси (VOR) такие факты отзывал правильно: проверка токена по коду (typesense отсутствует → REFUTED).
**Кластер (9 уникальных false-accept):** ВСЕ с голыми токен-якорями — R28 vespa, R30 pinecone, R31 typesense, R33 tantivy, R42 dataclasses, R26 meilisearch, R45 logging, R47 pathlib, R50 loki (silent).
**Вердикт по честности:** значимая часть false_accept=0.10 Day-1 — АРТЕФАКТ датасета (naive bare-token anchors в mutation-фактах), а не чистое поведение модели. Тот же класс naive-токенов дал 7 false-REFUTED в proxy 1-V — теперь проявился как false-ACCEPT у живой модели (она доверяет строке якоря, не проверяя её по коду).
**Действие (V2-промпт):** кодовая цель для чистого замера — показывать модели ТИПИРОВАННЫЕ якоря (file:/import:/env:) и contra_patterns как контр-свидетельство; V1-промпт (только support) сохранён для сопоставимости deepseek vs nemotron, V2 — отдельный прогон. Связь: ADR-0005 (типизация якорей закрыла 7 false-REFUTED у прокси — та же типизация нужна live-arm).

**Связь с отрицательными:** нет.

## [2026-08-14] — Exp 1-L Day 2 (live-arm): мультимодельный свип OpenRouter — 6 дешёвых моделей × 50 фактов × 2 руки

**Гипотеза (продолжение Day 1):** на дешёвых платных моделях OpenRouter (нет free-стены) вердикты будут снова отличаться от proxy 1-V, и — новое — между моделями будет большой разброс (adoption/false_accept зависят от модели, а не только от дизайна памяти). Ожидание: false_accept(code_first) разбросан от ~0 до ~0.3.
**Команда:** `python scripts/run_1L_live_arm.py --provider openrouter --arm both --models "qwen/qwen3.7-flash,qwen/qwen3.5-flash-02-23,z-ai/glm-4.7-flash,nvidia/nemotron-3.5-lightning,deepseek/deepseek-v4-flash,qwen/qwen3.6-flash" --no-reasoning --resume` (temp=0, seed=42, max_tokens=100, prompt v1, facts sha256=820bbbf60a0fc930; 600 вызовов).
**Сырой результат (progress-файлы: `<MSCODEBASE_DATA_DIR>/projects/bfe9644b/experiments/live_arm_1L_progress_*.json`, err=0 на всех руках):**
```
модель                        arm            adoption  false_acc  true_acc  unknown  acc(decided)   cost$
qwen/qwen3.7-flash            memory_first   0.22      0.02       0.20      0.66     0.88 (15/17)   0.00023
qwen/qwen3.7-flash            code_first     0.10      0.00       0.10      0.40     0.87 (26/30)   0.00025
qwen/qwen3.6-flash            memory_first   0.22      0.00       0.22      0.60     0.85 (17/20)   0.00162
qwen/qwen3.6-flash            code_first     0.10      0.00       0.10      0.24     0.74 (28/38)   0.00178
qwen/qwen3.5-flash-02-23      memory_first   0.14      0.02       0.12      0.82     0.89 (8/9)    0.00044
qwen/qwen3.5-flash-02-23      code_first     0.12      0.02       0.10      0.84     0.88 (7/8)    0.00048
deepseek/deepseek-v4-flash    memory_first   0.14      0.02       0.12      0.82     0.78 (7/9)    0.00077
deepseek/deepseek-v4-flash    code_first     0.20      0.02       0.18      0.72     0.79 (11/14)  0.00087
z-ai/glm-4.7-flash            memory_first   0.10      0.04       0.06      0.88     0.67 (4/6)    0.00045
z-ai/glm-4.7-flash            code_first     0.68      0.30       0.38      0.26     0.59 (22/37)  0.00048
nvidia/nemotron-3.5-lightning memory_first   0.44      0.08       0.36      0.32     0.79 (27/34)  0.00063
nvidia/nemotron-3.5-lightning code_first     0.54      0.18       0.36      0.18     0.66 (27/41)  0.00070
```
**Вердикт: ✅ подтверждено (обе части).** (1) Живые модели ≠ proxy 1-V: unknown у всех кроме nemotron — 0.24–0.88 (proxy всегда решал), разброс подтверждает ревью. (2) Разброс между моделями огромный: false_accept(code_first) от **0.00** (qwen3.6-flash, qwen3.7-flash) до **0.30** (glm-4.7-flash, 15/50); adoption(code_first) 0.10→0.68. glm-4.7-flash доверяет якорям почти всегда (code_first adoption=0.68 при memory_first 0.10) — для VOR-проверки такая модель опасна. (3) **R50 (silent-false, loki) принят 4/6 моделей** (qwen3.7, qwen3.5, deepseek, glm) — системная дыра «голый токен якоря = evidence», подтверждает кластер Day 1 (R26–R50). (4) Токены на запрос ≈107 in/10 out (сходится с расчётом); 600 вызовов = **$0.0087**.
**Оговорки:** один прогон на модель (temp=0, но LLM не идеально детерминирован); порядок фактов — файловый (R01–R25 все true, R26–R50 все false — блочная структура; для независимых вызовов угрозы валидности нет, отмечено как ограничение); V1-промпт с bare-token якорями завышает false_accept (документировано Day 1, V2 — отдельно).
**Урок:** выбор модели для verify-on-read — не «любая дешёвая»: glm-4.7-flash даёт FA=0.30, qwen3.6/3.7-flash — 0.00. Метрика модели обязана измеряться на этом датасете до использования в рантайме. Связь: EXPERIMENTS_LOG#Day-1-1L, scripts/run_1L_live_arm.py.

### Red Team фаза 2 (2026-08-14): атака на тест + веб-исследование + повторный прогон

**Гипотеза атаки:** тест мог содержать дефекты (парсинг, truncation, язык, наводящий промпт), искажающие вердикты. Метод: §1.16 Red Team + литература (Zheng 2023 LLM-as-judge biases; Sharma 2023 sycophancy; Li 2023 HaluEval; NAACL-2025 Beyond English).
**Результат (команда: `--provider openrouter --arm both --models <6 моделей> --no-reasoning --force` — повторный полный прогон):**
```
Итог: trunc=0 на всех 1200 ответах, err=0, все raw — lowercase JSON, finish_reason=stop.
Run1->Run2 false_accept: nemotron code_first 0.18->0.08, deepseek code_first 0.02->0.06,
qwen3.7 mem 0.02->0.00, glm code_first 0.30->0.28, qwen3.6 стабильна 0.00/0.00.
```
**Вердикт: гипотеза подтверждена частично.** (1) Парсинг-дефекты (case/bool → unknown) — латентные, на данных НЕ сработали (все raw lowercase); исправлены + тесты. (2) Truncation — опровергнута (finish_reason=stop везде): высокий unknown — честное поведение. (3) **Главная находка: temp=0+seed=42 НЕ дают детерминизма на OpenRouter** — run-to-run вариативность ±0.05–0.10 FA (nemotron 0.18→0.08). Однопроходные тонкие ранжировки недостоверны; выводы — по двум прогонам, выбор модели — по верхней границе FA. (4) Дизайн-дефекты подтверждены литературой: наводящий вопрос code_first (сикофантия), EN/RU языковой сдвиг — V2-промпт реализован, контроль языка — follow-up.
**Урок:** LLM-оценка без повторных прогонов ненадёжна; raw+finish_reason обязательны для аудита; наводящие вопросы и языковой сдвиг — реальные конфаунды. Связь: отчёт experiments/1L_live_arm/report.md §6.1–6.2.

### Follow-up (2026-08-14): V2-промпт (нейтральный) + контроль языка (RU)

**Команды:** `--prompt-version v2 --tag v2_en` (6 моделей × 2 руки, 600 вызовов); `--prompt-version v2 --prompt-lang ru --tag ru_v2` (3 модели × 2 руки, 300 вызовов).
**Сырой результат (кратко; полные таблицы — в отчёте §6.3–6.4):**
```
V2-en code_first FA: deepseek 0.06->0.00, qwen3.5 0.02->0.00, nemotron 0.08->0.04, glm 0.28->0.24, qwen3.6/3.7 0.00
V2-en code_first unk: deepseek 0.74->0.94, qwen3.5 0.80->0.96 (модели честнее «не знаю»)
RU-v2 unk: deepseek code 0.94->0.54 (RU лучше!), qwen3.7 code 0.24->0.58 (RU хуже)
```
**Вердикт:** (1) Сикофантия подтверждена данными — наводящий вопрос v1 вносил вклад в false_accept (FA упал у 4/6 моделей с нейтральным промптом, unknown вырос). (2) glm-4.7-flash сохраняет FA=0.24 с нейтральным промптом — красный флаг фундаментальный. (3) Язык промпта — конфаунд модель-зависимый: deepseek лучше с RU (English-centric reasoning завышал unknown), qwen3.7 лучше с EN. Рекомендации: V2 — канонический промпт; язык тестировать пер-модельно; выбор по верхней границе FA за 2 прогона.
**Урок:** «дешёвая модель» ≠ «пригодная»: glm исключена окончательно; qwen3.6/3.7 — кандидаты. V1/v2/ru данные — в отдельных progress-файлах (tag), v1 сохранён.

### Follow-up 2 (2026-08-14): премиум-арм (Claude из ревью) + семейство nemotron

**Команды:** `--prompt-version v2 --no-reasoning --tag premium_v2` (claude-sonnet-5, qwen3.8-max, glm-5.2, deepseek-v4-pro; 400 выз., ~$0.106); `--tag nemotron_family` (super-120b, nano-30b; 200 выз., ~$0.0014).
**Сырой результат:**
```
claude-sonnet-5:   FA=0.00/0.00, acc=1.0 (7/7, 15/15), unk=0.86/0.70 — эталон осторожности, но $0.049/100
qwen3.8-max:       HTTP 400 «Reasoning is mandatory… cannot be disabled» (22–49/50) — несовместима с бюджетом 100 токенов
glm-5.2:           FA=0.00/0.02, unk=0.96/0.76 — кардинально лучше glm-4.7-flash (0.10/0.24)
deepseek-v4-pro:   FA=0.04/0.00, unk=0.66/0.88
nemotron-nano-30b: FA=0.06/0.38 (19/50!) — ХУДШАЯ модель свипа, красный флаг №2
nemotron-super:    50% HTTP 422 апстрима — ненадёжна, исключена
```
**Вердикт:** ревью Part 3 закрыто данными: у Claude FA=0.00 (≈proxy), но unknown/adoption другие; премиум не даёт выигрыша по FA vs лучшие flash (qwen3.6/3.7, FA=0.00) при цене ×100. Красные флаги: glm-4.7-flash (0.24–0.30), nemotron-nano (0.38). qwen3.8-max требует отдельного бюджета (≥500 токенов) — вне матрицы 100-токенного условия.
**Связь:** полный отчёт experiments/1L_live_arm/report.md (§6.3–6.4, 13).

### Follow-up 3 (2026-08-14): подтверждение FA=0.00 — 2-й прогон V2 у qwen3.6/3.7

**Команда:** `--prompt-version v2 --no-reasoning --tag v2_en_run2 --models "qwen/qwen3.7-flash,qwen/qwen3.6-flash"` (200 выз., ~$0.004).
**Результат:** qwen3.7 code_first FA=0.00 (unk 0.26), mem 0.02 (R50); qwen3.6 code_first FA=0.00 (unk 0.40), mem 0.00.
**Вердикт:** ✅ FA=0.00 в code_first подтверждён 4 прогонами (v1×2 + v2×2) = **0/400** у обеих моделей; единственная нестабильность — R50 в memory_first. qwen3.6/3.7-flash — безопасный выбор для verify-on-read (дешевле премиума ×100 при том же FA).

## [2026-08-13] — EXP: «сервер недоступен во время индексации» — root cause = sync update_all в main loop

**Гипотеза:** таймауты всех MCP-запросов на ~13 мин при полной переиндексации вызваны НЕ индексацией самой по себе (она в run_in_executor, loop свободен), а синхронным AutoDocUpdater.update_all() (generate_docs+README+KNOWN_ISSUES, rglob по docs/) в main event loop ПОСЛЕ индексации (layer.py _run_reindex_job).
**Команда:** `intel_trigger_reindex(mode="full")` + серия запросов (job_status/hotspots/passport) во время и после; `wmic`/tasklist для состояния процесса; чтение кода (layer.py L672-808, auto_doc_updater.py L114-163).
**Сырой результат:**
```
intel_trigger_reindex → job 0d27f125, ETA 18с
все запросы ~13 мин: Context server request timeout (включая intel_get_job_status)
get_logs: Timeout after 771664ms (attempt 1/1)
job completed: 7383/7383, 552с (ETA 18с vs 552с, ×30)
после: процесс 19728 мёртв (канал closed) — Zed убил MCP
код: update_all() вызывается СИНХРОННО в async-задаче (main loop)
```
**Вердикт: ✅ подтверждена.** 552с индексации + ~220с update_all = 771с недоступности — совпадает с логом. Индексация в executor (H1 опровергнута); fast-fail search при is_reindexing есть; блокировал именно sync-update_all (BS-11-класс: run_full_diagnostic уже был вынесен в to_thread в intel_predict_root_cause).
**Урок:** любые синхронные вызовы тяжёлых методов (rglob/generation) в async-функциях = блокировка ВСЕХ запросов; паттерн-эталон — asyncio.to_thread + wait_for (BS-11). Guard-тест: test_reindex_responsive.py (тики loop не замирают во время update_all; max_gap < 0.3с).
**Связь с отрицательными:** нет.

## [2026-08-12] — EXP-1 → тест: canary fail-closed внедрён, 13/13 регрессий (атаки EXP-1 больше не проходят)

**Гипотеза:** фикс по уроку EXP-1 (абсолютный якорь + fail-closed + collapse-детектор) переводит атаки (b)(c)(d)(e) из PASSED в BLOCKED, не сломав accepts_good/rejects_bad.
**Команда:** `python -m pytest tests/test_shadow_canary.py -q` — реалистичные per-pair векторы вместо коллапс-фейков (старый `_make_fake_embedding` возвращал ОДИНАКОВЫЙ вектор на любой вход — сам был collapse-состоянием!).
**Сырой результат:**
```
collected 13 items
tests\test_shadow_canary.py .............  [100%]
13 passed in 0.18s
```
Тесты: TestVectorsCollapsed ×5 (constant/noisy-constant/zero → collapsed; distinct → нет; <2 → unverifiable), TestShadowCanary ×8 (accepts_good; rejects_bad; **empty_canary_blocks** — было «доверие», теперь BLOCK; **baseline_failure_blocks**; **collapse_to_constant_blocks** — EXP-1 (b); **baseline_below_absolute_quality_blocks**; **new_below_absolute_quality_blocks** — old_mean=0.53→threshold 0.477, new_mean=0.49: relative прошёл бы, абсолютный якорь 0.5 блокирует; canary_set.json 20 пар).
**Вердикт: ✅ подтверждена.** Атаки EXP-1 (b)(c)(d) теперь BLOCKED; «relative прошёл, absolute блокирует» — различается. Коллапс-детектор ловит и ±1%-noisy (дисперсия НОРМАЛИЗОВАННЫХ векторов — scalar-кратные дают cos=1.0; сырая дисперсия их пропускала, что поймал тест на первом прогоне: 12/13, фикс — нормировка).
**Урок:** коллапс-фейк в тестах маскировал collapse-детектор: детектор обязан мерить НАПРАВЛЕНИЯ (нормированные векторы), не сырые значения.
**Связь с отрицательными:** нет.

## [2026-08-12] — EXP-4 → тест: eligible_seen внедрён в health, «0 eligible» ≠ «0 собрано» (12/12)

**Гипотеза:** population manifest (eligible_seen из indexer.get_status ДО запросов) различает пустую популяцию (healthy idle) и сломанный коллектор; warning несёт число eligible.
**Команда:** `python -m pytest tests/test_search_quality_monitoring.py -q`.
**Сырой результат:**
```
collected 12 items
tests\test_search_quality_monitoring.py ............  [100%]
12 passed in 0.07s
```
Новые: test_empty_population_is_healthy_idle (0 eligible → skipped=empty_index, warning НЕТ), test_fails_on_garbage_chunks → «0 реальных результатов при 100 eligible-чанков в индексе (broken collector)», test_eligible_seen_unknown_falls_back (get_status отсутствует → -1 → старое поведение).
**Вердикт: ✅ подтверждена.** «0 сырых + 0 eligible» (idle) vs «0 сырых + N eligible» (коллектор) — различимы метрикой и warning.
**Урок:** источник eligible_seen — реальный счётчик indexer (не производное от searcher), иначе та же популяционная слепота (Red Team §1.16 п.3).
**Связь с отрицательными:** нет.

## [2026-08-11] — EXP-1: Shadow Canary attack — дискриминативная способность `_shadow_compare` (5/5 атак прошли)

**Гипотеза:** canary измеряет ОТНОСИТЕЛЬНУЮ деградацию (new vs old), а не абсолютное качество → (b) collapse-to-constant, (c) пустой canary, (d) сбой базлайна, (e) взаимно-вырожденная пара дают ложное PASSED=True. Контроль (a) нулевые векторы обязан дать BLOCKED.
**Команда:** `python experiments/canary_shadow/exp_canary_attack.py` — дословная реплика remote_embedder.py:231-304 (без импорта провайдера), N=20 пар, DIM=384.
**Сырой результат:**
```
(a) Нулевые векторы (контроль): BLOCKED=True ✅ контроль отработал
(b) АТАКА constant-vector (все тексты → [1.0]*384): PASSED=True ❌ АТАКА ПРОШЛА
(b2) АТАКА noisy-constant (±1%): PASSED=True ❌ АТАКА ПРОШЛА
(c) Пустой canary-набор: PASSED=True ❌ АТАКА ПРОШЛА (fail-open)
(d) Сбой базлайна (old raises): PASSED=True ❌ АТАКА ПРОШЛА (fail-open)
(e) old И new обе constant: PASSED=True ❌ АТАКА ПРОШЛА
ИТОГ: атаки (b)(b2)(c)(d)(e) — 5 из 5 прошли. Контроль (a) — работает.
```
**Вердикт: ✅ АТАКИ ПОДТВЕРЖДЕНЫ.** Canary не может упасть на collapse-to-constant (sims=1.0 > порога), fail-open при пустом canary (`if not self._canary_pairs: return True`, строка 242-243) и при сбое базлайна (`except Exception: return True`, строка 259-261). Единственный пойманный дефект — нулевые векторы. «Проверка, которая не может увидеть что-то, всегда зелёная про это» (Tom, день 2). test_shadow_canary.py:54-63 закрепляет «пустой canary = доверие» как фичу.
**Урок:** относительная метрика без абсолютного якоря и fail-open ветки — два способа сделать guard неспособным упасть. Фикс: (1) абсолютный порог (new_mean ≥ X), (2) baseline-fail и empty-canary → блокировать переключение/UNKNOWN, не доверять, (3) детектор collapse (дисперсия векторов ≈ 0 → reject), (4) eligible_seen (число пар при загрузке).
**Связь с отрицательными:** нет.

## [2026-08-11] — EXP-2: Скан тестов на вакуумность — таблица Max Quimby для MSCodeBase (1133/1143 proven)

**Гипотеза:** часть тестов синтаксически не может упасть (нет assert/raises/warns/fail/raise) — «33 unproven» в миниатюре. Ожидание: 5-15% вакуумных.
**Команда:** `python experiments/misc_probes/exp_vacuous_scan.py` — AST-скан tests/test_*.py (1143 test-функции/метода); proven = есть assert / pytest.raises/warns/xfail/fail / raise / mock-assert_* (после правки).
**Сырой результат:**
```
Всего тестов: 1143
  proven: 1133 | вакуумных: 3 | skip: 7 | доля вакуумных: 0.3%
Вакуумные: test_assignments.py:396, test_ast_cache_invalidation.py:60, test_sandbox.py:46
```
**Вердикт: ❌ ГИПОТЕЗА ОПРОВЕРГНУТА** (в хорошем смысле): сюита почти полностью доказуема — 1133/1143 (99.7%) содержат failing-конструкцию. 3 «вакуумных» — smoke-тесты, способные упасть через exception-пропагацию из хелперов (`_ = parser.extract_assignments(f)  # не падает`), т.е. дискриминация слабее, но не нулевая. Первичный скан дал 5 «вакуумных», 2 из них (test_move_chunks.py:351, test_indexer_fts5_sync.py:55) использовали mock-утверждения (`assert_called_once`/`assert_not_called` — Call, не ast.Assert) — сканер обновлён (учитывает `assert_*` методы), честный пересчёт 3.
**Урок:** MSCodeBase НЕ в состоянии fintech (7/40 proven) — но именно поэтому отрицательные контроли выгодны: их мало (0-3), а ценность максимальна. 2 ловушки для сканеров вакуумности: mock-assert_* и exception-пропагация.
**Связь с отрицательными:** нет.

## [2026-08-11] — EXP-3: Воспроизведение бага `ln.strip()` (Tom Jones) — 3/8 ложных проходов у сломанного экстрактора

**Гипотеза:** assert-экстрактор, фильтрующий по `ln.strip()` но эмитирующий сырую `ln`, даёт ложные verified для неверного ответа, когда отступ вложенного assert-а попадает ПОСЛЕ `return` в теле функции. Ожидание: ≥2/8 ложных проходов (у fintech — 5/8 на их наборе форм).
**Команда:** `python experiments/misc_probes/exp_ln_strip_repro.py` — 8 форм вызова (col 0 / 4-space / 8-space / 12-space, до/после return), неверный ответ `add_two(1,2)=4`, сборка module = answer + raw assert-строки (как у fintech-gateway), exit 0 = verified.
**Сырой результат:**
```
Сломанный экстрактор: 3/8 ложных проходов  (формы 2,3,8 — assert на 4-space после return)
Правильный экстрактор: 0/8 ложных проходов
Пример модуля (форма 2):
def add_two(a, b):
    return a + b + 1
    assert add_two(1, 2) == 3   # мёртвый код ПОСЛЕ return — valid Python, exit 0
```
**Вердикт: ✅ КЛАСС БАГА ВОСПРОИЗВЕДЁН.** Число форм (3/8 vs 5/8) отличается — набор форм другой, но суть та же: valid Python, никогда не исполняется, exit 0, «verified:true» для неверного ответа. Правильный экстрактор (emit `ln.strip()`, col 0) — 0/8. Ключ: сигнатура/exit-код верифицируют ПРОЦЕСС, не СЕМАНТИКУ (Giulio: «ask for the artifact, not the exit code»).
**Урок:** любой код, извлекающий/перекомпилирующий фрагменты (assert-экстракция, док-примеры, code-gen) обязан нормализовать отступы ПЕРЕД эмиссией; negative control для экстрактора = фикстура с assert-после-return, обязанная упасть.
**Связь с отрицательными:** нет.

## [2026-08-11] — EXP-4: Population blind spot — `_check_search_quality` не различает «0 eligible» и «0 собрано» (gap Тома день 2)

**Гипотеза:** пустая популяция (пустой индекс — «здоровый idle») и сломанный коллектор (мусор) дают ОДИНАКОВЫЙ сигнал: `search_quality_passed=0` + warning «нет реальных результатов». `eligible_seen` до селекции не измеряется (health.py:744-756).
**Команда:** `python experiments/misc_probes/exp_population_blindspot.py` — реальный `src/core/intelligence/health.py` (importlib direct-load, stdlib-only), FakeSearcher: [] vs мусор vs реальные vs raising.
**Сырой результат:**
```
(a) ПУСТАЯ популяция ([]): metrics passed=0
    warning: ...нет реальных результатов (0 сырых — все пустые/мусорные чанки)
(b) МУСОР: passed=0
    warning: ...нет реальных результатов (2 сырых — все пустые/мусорные чанки)
(b2) ОШИБКА searcher: passed=0, warning: ...завершился с ошибкой: embedder down
(c) КОНТРОЛЬ (реальные): passed=3, без warning
```
**Вердикт: ✅ GAP ПОДТВЕРЖДЁН.** (a) и (b) — одинаковый failure-сигнал (passed=0, warning-класс «нет реальных результатов»); сообщение (a) утверждает «пустые/мусорные чанки», хотя сырых результатов было 0 — ложное объяснение. Нет счётчика `eligible_seen` (сколько чанков было в индексе ДО запроса): «0 строк с 0 eligible» (здоровый idle — свежий проект) неотличим от «0 строк с N eligible» (сломанный коллектор). Ошибка searcher (b2) — отдельный класс (различается).
**Урок:** метрика обязана нести оба числа: `population_size` (после) и `eligible_seen` (до селекции); gap между ними — аудируемая величина (Tom: «You sampled 12 of 400 invites an argument. You sampled 12 ends one.»). В health: добавить в warning count сырых + размер индекса, а «0 eligible» маркировать как INFO (healthy idle), не как failure.
**Связь с отрицательными:** нет.

## [2026-08-11] — EXP-5: `verify_clean_state.sh` — falsifiability-проверка гейта + P1: drift-гейт структурно мёртв

**Гипотеза:** (A) drift-гейт (строки 55-71) умеет падать на рассинхроне pin vs lock; (B) вакуумная сюита (0 asserts) проходит → «CLEAN STATE VERIFICATION: PASSED» — reproducibility без falsifiability (ANP2).
**Команда:** `bash experiments/misc_probes/exp_verify_gate.sh` (drift-цикл дословно из скрипта, temp pyproject/lock; pytest на temp-сюите) + повторный прогон гейт-кода на РЕАЛЬНЫХ файлах проекта.
**Сырой результат:**
```
Часть A: drift (lancedb 0.12.0 pin vs 0.13.0 lock) → «drift НЕ обнаружен → exit 0 ❌»
Реальные файлы: lancedb PINNED='' LOCKED='0.34.0' | mcp PINNED='' LOCKED='1.28.1' | tree-sitter PINNED='' LOCKED='0.26.0'
Часть B: вакуумная сюита → 3 passed in 0.21s, exit 0 → гейт напечатал бы PASSED
Корректный парсинг (grep -oE "pkg==[0-9.]+"): lancedb PINNED='0.34.0' = lock ✅;
  симулированный дрейф (lancedb==0.99.0 в pyproject) → DRIFT DETECTED
```
**Вердикт: ✅ ЧАСТИЧНО, с критической находкой.** (B) подтверждена: гейт печатает PASSED для сюиты без единого assert — семантическая слепота. (A) ОПРОВЕРГНУТА наоборот: **дрейф-гейт структурно неспособен сработать** — паттерн `grep -iE "^\"?${pkg}=="` требует `pkg==` в начале строки, но пины лежат в TOML-массиве (`    "lancedb==0.34.0",`) → PINNED всегда пуст → ветка `DRIFT=1` недостижима для всех 3 пакетов. Живой экземпляр класса «guard не может упасть» (Tom ln.strip()). Корректный парсинг (демонстрация направления фикса) ловит и текущий sync, и симулированный дрейф.
**Урок:** grep-парсинг TOML-массивов по якорю `^` — мёртвый паттерн; fix = `grep -oE "${pkg}==[0-9.]+"` или python tomllib; обязателен negative control (фикстура с заведомым дрейфом, обязан дать exit 1). Бонус-находка (Любопытство §3.4): scripts/stale_detector.py — placeholder «No drifts detected», всегда exit 0, подключён к pre-commit хуку (git_hooks_installer.py:88) — второй guard того же класса.
**Связь с отрицательными:** нет.

## [2026-08-11] — Exp 1-V REPLICATION: Memory Contamination VERIFY-ON-READ — факты v4, N=50 (ВОСПРОИЗВЕДЕНО)

**Гипотеза:** verify-on-read доводит adoption честного до 0.0 на SILENT-фактах — свойство системы, а не артефакт набора v3 (Правило одного бенча §1: одиночный замер ≠ доказательство).
**Команда:** `venv/Scripts/python.exe experiments/context_engine/memory_contamination_generator_rep.py` (seed=7, TRUE_POOL_REP: file:6+env:2+import:9+CamelCase:8, absent: qdrant/weaviate/.../vault 16, trap: pathlib/threading/dataclasses/json/logging/re 6, silent: terraform/jaeger/loki 3) → `memory_contamination_facts_v4_rep.json` → `venv/Scripts/python.exe experiments/context_engine/memory_contamination_verify.py memory_contamination_facts_v4_rep.json`. Тот же агент/логика (контрольная группа), другой набор данных.
**Сырой результат (v4 vs v3):**
```
verify: checked=50 cache_hits=0 inconclusive=9 budget_exceeded=False
latency: fingerprint 73.8ms, first pass 115.3ms, steady-state 0.6ms (cache_hits=31, checked=0)
verdicts: VERIFIED=22 REFUTED=19 ACTIVE(INCONCLUSIVE)=9
false REFUTED: total=19 | среди TRUE (артефакт маппинга): 0
видимые ложные после verify (memory_first adopters): [R42,R43,R44,R45,R46,R47]
adoption A_code_first: v3 0.12 | 1-R 0.12 | 1-V 0.0 | 1-V-REP 0.0
adoption A_memory_first: v3 1.0  | 1-R 0.12 | 1-V 0.16 | 1-V-REP 0.24
visible false of 25: 1-V 4 | 1-V-REP 6
```
**Вердикт: ✅ ВОСПРОИЗВЕДЕНО.** (1) **adoption честного 0.0 воспроизведён** на независимых данных (v3→v4, другой TRUE-пул, другие absent/silent) — главная метрика DoD ADR-0003 устойчива: все 3 SILENT (terraform/jaeger/loki) + 16 absent отозваны до контекста. (2) **0 ложных REFUTED TRUE** при корректно типизированных якорях (R01-R25: 16 VERIFIED + 9 INCONCLUSIVE, 0 REFUTED) — DoD подтверждён независимо (в 1-V было 7 — артефакты НАИВНОЙ типизации голых токенов; при корректной типизации их 0). (3) **Ограничение present-trap воспроизведено**: 6/6 ловушек — реальные импорты → VERIFIED, visible 6 → memory_first 0.24 (1-V: 0.16; число выше, т.к. в v4 ВСЕ 6 trap — импорты, в v3 — 4 из 6). Слепота presence-проверки к present-trap — структурная, ловит только честный агент (code_first 0.0). (4) steady-state 0.6ms (cache_hits=31) — бюджет ≤50мс соблюдён. (5) Разложение вердиктов точно по прогнозу: REFUTED=19 (16 absent + 3 silent — все корректные отзывы FALSE), VERIFIED=22 (16 TRUE + 6 trap), ACTIVE=9 (8 CamelCase + env MSCODEBASE_ALLOW_SELF_INDEX вне .env).
**Урок:** репликация подтвердила: (a) главный вывод 1-V — свойство VerifyOnRead, не данных; (b) типизация якорей — единственный источник ложных отзывов TRUE (0 при корректной, 7 при наивной — воспроизводимо, закрыто write-time capture); (c) «0.0 adoption» требует отзыва SILENT — проверено дважды. Ограничение прежнее: детерминированный прокси-агент, не живой LLM.
**Связь с отрицательными:** нет.

## [2026-08-11] — Exp 1-V: Memory Contamination VERIFY-ON-READ — аналог v3 с Lazy Validation Layer (ADR-0003)

**Гипотеза:** Verify-On-Read (проверка ACTIVE-узлов при извлечении, до промпта) доводит заражение до нуля: SILENT-факты с отсутствующими якорями -> REFUTED (SILENT_ABSENCE_ON_READ). Ожидание (DoD ADR-0003): adoption честного 0.0; 0 ложных REFUTED среди TRUE при корректно типизированных якорях.
**Команда:** `venv/Scripts/python.exe experiments/context_engine/memory_contamination_verify.py` — те же 50 фактов v3; якоря из support_patterns по синтаксису (file: -> file, ALL-CAPS -> env с нормализацией к точному ключу, lowercase -> import); РЕАЛЬНЫЙ VerifyOnRead на реальной кодовой базе (отпечаток src+.env), изолированный store и кэш; агенты решают на пост-verify памяти.
**Сырой результат:**
```
verify: checked=50 cache_hits=0 inconclusive=12 budget_exceeded=False
latency: fingerprint 82.3ms, first pass 128.9ms, steady-state 0.6ms (cache_hits=22, checked=0)
verdicts: VERIFIED=10 REFUTED=28 ACTIVE(INCONCLUSIVE)=12
false REFUTED: total=21 | среди TRUE (артефакт маппинга): 7 [G07,G25,G11,G24,G23,G18,G21]
видимые ложные после verify (memory_first adopters): [G42,G43,G44,G45]
adoption A_code_first: v3 0.12 | 1-R 0.12 | 1-V 0.0
adoption A_memory_first: v3 1.0  | 1-R 0.12 | 1-V 0.16
```
**Вердикт: ЧАСТИЧНО (цель достигнута, 2 ограничения зафиксированы честно).** (1) **adoption честного → 0.0** (v3/1-R: 0.12) — цель «заражение к нулю» достигнута: SILENT-отсутствия (grafana/gitlab/kubernetes/nose/neo4j/rabbitmq) отозваны до контекста. (2) **steady-state 0.6мс** (cache_hits=22, checked=0) — бюджет ≤50мс соблюдён; fingerprint ~80мс платится один раз на HEAD. (3) **Ограничение 1 (present-trap):** 4 ложных остались видимыми (G42 sqlite3/G43 onnx/G44 httpx/G45 sqlite3 — токены РЕАЛЬНО импортируются кодом) -> memory_first adoption 0.16 (хуже 1-R 0.12: ручной отзыв честного агента в 1-R поймал traps contra-анализом; presence-проверка их не видит). Комбинация verify + честный агент (code_first) = 0.0. (4) **Ограничение 2 (артефакты типизации):** 7/25 ложных REFUTED TRUE — все от наивного маппинга голых токенов в import-якоря (lancedb_version/bm25_weight — конфиг-строки; intel_log_incident/intel_auto_collect_adrs/intel_get_telemetry — методы слоя; fastmcp — реальный импорт `from mcp.server.fastmcp import FastMCP` (server_factory.py:158), корень `mcp`, не `fastmcp`; basedpyright — бинарник node_modules/.bin (lsp_client.py:527), не python-импорт). Компонент проверил ровно то, что ему дали; с корректно типизированными якорями (юнит-тесты) — 0 ложных отзывов.
**Урок:** verify-on-read удаляет absence-заражение (SILENT+отсутствующие) полностью, но presence-проверка принципиально слепа к present-trap (токен есть, субъект другой) — их ловит только честный агент. Типизация якорей — ответственность write-пути: голые токены паттернов НЕЛЬЗЯ превращать в import-якоря без валидации типа (метод/конфиг/подмодуль/бинарник ≠ импорт). Следующий шаг: anchor-capture при записи узла (типизированные якоря в data.anchors).
**Связь с отрицательными:** нет.

## [2026-08-11] — Exp 1-R: Memory Contamination RETRACTION — аналог v3 с ретракцией (ADR-0002)

**Гипотеза:** системный отзыв (intel_retract_memory_node, ADR-0002) превращает `would_refute` честного агента (corr_cap=1.0) в реальное действие: отозванные факты исчезают из контекста следующих сессий → даже memory_first в сессии 2 не примет уже отозванный факт. Ожидание (ADR Temporal): adoption честного падает с 0.12 к 0.
**Команда:** `venv/Scripts/python.exe experiments/context_engine/memory_contamination_retraction.py` — те же 50 фактов v3 (контрольная группа), тот же CodeEvidence/decide; сессия 1 = честный агент + реальный `intel_retract_memory_node` (прод-путь layer, изолированный store, seed БЕЗ status = легаси/ACTIVE); сессия 2 = свежее чтение обоими агентами пост-ретракционной памяти (load_memory фильтрует REFUTED).
**Сырой результат:**
```
valid facts: 50 (25T + 25F, silent-false 3)  |  invalid: 0  |  parity: OK
              adopt(F)  corr_cap persist.F    tokens
S1 honest+retract   0.12       1.0         3     653.2
S2 code_first       0.12         -               360.8
S2 memory_first     0.12         -
retraction: 22/22 would_refute реализовано системно (correction_capability_systemic=1.0)
persistent false in memory: 25 -> 3 (-88%)
tokens_memory: 653.2 -> 360.8 (-45%)
all refuted have reason: True
```
**Вердикт: ЧАСТИЧНО (гипотеза подтверждена в части системного отзыва, прогноз «adoption → 0» уточнён).** (1) Parity с v3: adoption честного S1 = 0.12 — контрольная группа совпала. (2) **Systemic capability: 22/22** would_refute реализованы через реальный прод-путь (correction_capability_systemic=1.0; раньше grep-0 refute-тулов). (3) **memory_first adoption: 1.0 → 0.12** в сессии 2 — ретракция защищает даже «ленивого» агента (отозванное скрыто load_memory). (4) **Persistent contamination: 25 → 3 false (-88%)** — остались только SILENT. (5) **tokens контекста: -45%** (653→361; метрика — реальный размер одного чтения, не накопленный v3-аналог 66.5k). (6) **Прогноз «adoption честного → 0» НЕ подтверждён**: SILENT-факты код молчит — честный агент их не отзовёт (adoption остаётся 0.12); до 0 доведёт только verify-on-read (Вариант B), нацеленный на остаточные SILENT.
**Урок:** ретракция удаляет ОПРОВЕРЖИМУЮ часть заражения (88%), но не SILENT — они требуют верификации против кода, а не отзыва. «Adoption → 0» — неверный таргет для ретракции; правильные метрики: persistent contamination, adoption не-честных агентов, токены контекста. ADR-0002 Temporal уточнён (см. ADR).
**Связь с отрицательными:** нет.

## [2026-08-11] — Exp: Memory Contamination — INDEPENDENT AUDIT (second opinion, 48/48 CONFIRMED)

**Гипотеза:** truth-метки фактов v1+v2 достоверны: TRUE-паттерны — рабочая логика (не docstring/мёртвый код), FALSE/SILENT — чистые grep-0 с рабочими контраргументами.
**Команда:** spawn_agent (независимый аудитор, не видел наш диалог): 48 фактов из experiments/1V_memory_contamination/memory_contamination_facts.json + _v2.json против src/**/*.py; чек-лист «активный код vs docstring/статические списки»; без MCP-семантического поиска.
**Сырой результат:**
```
CONFIRMED 48/48 | DEAD 0 | MISSING 0 | BROKEN 0
T01-T20, F01-F20, S01-S14 — все с file:line evidence (активные импорты/вызовы/конфиги)
```
**Вердикт: ✅ ПОДТВЕРЖДЕНО (48/48).** Оговорки (не ложность, качество паттернов): T03 «ВНЕ проекта» — только docstring, но подтверждён вторым паттерном MSCODEBASE_DATA_DIR; T06 fastmcp — активный import в server_factory.py:158 (не server.py — note неточен); T13 «57 инструментов» — паттерн «12 inline» в docstring, но счёт регистраций 28+13+12+4=57 независимо подтверждён; T18 «идемпотентен» — docstring, но код _migrate_into (artifact_paths.py:252-298, if src.exists and not dst.exists) реализует. Системное ограничение: .env невидим grep-инструменту (private_files) — grep-0 по src подтверждён, по .env — остаточный риск мал (KNOWN_ISSUES 2026-08-08 цитирует .env владельца: только MSCODEBASE_EXECUTE_SCRIPT_ENABLED=true).
**Урок:** (1) «свежие глаза» (независимый аудитор без контекста) — финальный уровень верификации truth-данных, закрывает риск «автор верит своему набору»; (2) паттерны-якоря в docstring валидны, если claim независимо подтверждается рабочим кодом (счёт/чтение кода) — фиксировать оговорки, не переделывать факты пост-фактум.

## [2026-08-11] — Exp: Memory Contamination — MUTATION GENERATOR (facts v3, N=50) — РЕАЛЬНОЕ РАСПРЕДЕЛЕНИЕ

**Гипотеза:** (1) метрики — точные функции смеси категорий (алгебра, а не статистика): при контролируемой смеси значения предсказуемы по формулам; (2) «голос кода» на сгенерированных фактах: real-паттерны подтверждают 25/25, мутации-отсутствия опровергаются, present-trap «ловушки» (ложный токен ЕСТЬ в коде) тоже опровергаются контраргументом.
**Команда:** `venv/Scripts/python.exe experiments/context_engine/memory_contamination_generator.py` (seed=42, смесь 25T+16absent+6trap+3silent=50) → `memory_contamination_facts_v3_generated.json` → `venv/Scripts/python.exe experiments/context_engine/memory_contamination.py memory_contamination_facts_v3_generated.json`.
**Сырой результат (v3 vs v1/v2):**
```
arm             correct  adopt(F)  contra  corr_cap  conf_eff  unk     tokens
B               0.94     0.0       0.88    0.0       3         0.06    1539
A_code_first    0.94     0.12      0.88    1.0       3         0.0     66477
A_memory_first  0.50     1.0       0.88    0.0       3         0.0     66477
(v1/v2 для сравнения: B 0.833/0.0, A_cf 0.833/0.286/1.0, A_mf 0.417/1.0, contra 0.714, conf_eff 4)
```
**Вердикт:**
- **H1: ✅ ПОДТВЕРЖДЕНА (алгебра)** — все 6 метрик совпали с формулами от смеси: 0.94=(25+22)/50, adopt 0.12=3/25, contra 0.88=22/25, corr_cap 22/22=1.0, B unk 3/50. Это финальное доказательство: при детерминированном агенте N определяет только смесь, не точность.
- **H2: ✅ ПОДТВЕРЖДЕНА** — «голос кода» на 50 фактах: 25 SUPPORT + 22 CONTRADICT + 3 SILENT. Все 6 present-trap (ollama/lm_studio/onnx/fts5/sqlite3/git — токены ЕСТЬ в коде) дали CONTRADICT: реальный паттерн субъекта перевешивает токен лжи → вердикт корректен. Заражение честного агента (A_cf adopt 0.12) только на SILENT (внешние системы).
- **Стоимость памяти:** 66.5k токенов на 50 фактов (~1.3k/факт, O(N) per-fact) — контекст-цена памяти растёт линейно с числом записей.
**Урок:** (1) генератор мутаций — масштабируемый путь к реалистичным наборам вместо ручной курации (риск семантических ловушек не масштабируется с N); (2) present-trap устойчивость — эмпирически подтверждено, что verify-on-read с контраргументом по реальному паттерну не ломается о правдоподобную ложь; (3) ambiguous=6 в v3 — не дефект, а by-design ловушки (верификатор параметризован: v1/v2=0, v3=6, invalid=0 всегда).

## [2026-08-11] — Exp: Memory Contamination — REPLICATION (facts v2, N=24) — ВОСПРОИЗВЕДЕНО

**Гипотеза:** метрики v1 — свойство системы (структура задачи), а не артефакт конкретного набора фактов.
**Команда:** `venv/Scripts/python.exe experiments/context_engine/memory_contamination.py memory_contamination_facts_v2.json` — НОВЫЙ набор фактов (10T + 10F + 4SILENT: grafana/gitlab/kubernetes/memcached), другой паттерн-дизайн, та же логика агента (Правило контрольной группы §1: не меняем агента между прогонами).
**Сырой результат (v2 vs v1):**
```
arm             v1 correct  v2 correct  v1 adopt  v2 adopt  corr_cap v2  contra v2  conf_eff v2  unk v2
B               0.833       0.833       0.0       0.0       0.0         0.714      4            0.167
A_code_first    0.833       0.833       0.286     0.286     1.0         0.714      4            0.0
A_memory_first  0.417       0.417       1.0       1.0       0.0         0.714      4            0.0
```
**Вердикт: ✅ ВОСПРОИЗВЕДЕНО** — идентичные метрики на двух независимых наборах фактов (24+24, разные паттерны, разные внешние системы). Числа детерминированы структурой: внутренние факты о коде опровергаемы 10/10, внешние системы 4/4 SILENT (код молчит), TRUE 10/10 SUPPORT. Итоговые выводы v1 устойчивы: correction_capability (code_first)=1.0 при явном противоречии; система add-only (отзыв невозможен — grep-0); память даёт уверенную ложь на SILENT-фактах (conf_eff=4); память ×22 токенов без выигрыша в точности.
**Урок:** репликация на независимых данных — обязательна для «одиночных замеров» (§1 «Правило одного бенча»): два набора → одинаковый вердикт → вывод подтверждён. Ограничение прежнее: детерминированный прокси-агент, не живой LLM.
**Верификация (experiments/1V_memory_contamination/verify_memory_contamination.py, 2026-08-11):** 3 оси ALL PASS — (A) truth-table decide(): 9/9 путей = спецификации (поймал choice-непоследовательность memory_first@SUPPORT: было CODE, стало MEMORY; вердикты/метрики не изменились); (B) декомпозиция агрегатов из per-fact строк для v1+v2; (C) 24/24 valid, 0 invalid, 0 ambiguous в обоих наборах.

## [2026-08-11] — Exp: Memory Contamination (IntelligenceStore) N=24, v1 (Experiment 1 из second_brain_research)

**Гипотеза:** персистентная память (project_memory.json + incidents.json) вносит stale/false контекст: (H1) код может опровергнуть большинство ложных фактов памяти; (H2) при явном противоречии Memory vs Code агент с честной политикой выбирает CODE и отзывает факт (correction_capability — метрика владельца), но система не имеет инструмента отзыва; (H3) там, где код молчит, память превращает UNKNOWN в уверенный (ложный) ответ.
**Ожидание:** code_contradictability ≥0.7; correction_capability (code_first) = 1.0; adoption (memory_first) = 1.0; memory_confidence_effect > 0 на SILENT-фактах.
**Команда:** `venv/Scripts/python.exe experiments/context_engine/memory_contamination.py` — 24 факта (10T + 10F с контраргументом + 4 SILENT-F внешние системы, grep-0 в src); изолированный `IntelligenceStore(tempdir)` (assert store_dir != реальный); агент = детерминированный прокси (живого LLM в проекте нет): evidence-поиск по src/**/*.py + .env; руки B (без памяти) / A code_first / A memory_first; выбор ground truth (MEMORY|CODE|NONE) фиксируется per-fact. Факты: memory_contamination_facts.json. Результат: memory_contamination_results.json.
**Сырой результат (24 факта, 0 invalid, 0 ambiguous, isolation confirmed):**
```
arm             correct  adopt(F)  contra  corr_cap  conf_eff  unk     tokens
B               0.833    0.0       0.714   0.0       4         0.167   784
A_code_first    0.833    0.286     0.714   1.0       4         0.0     17830
A_memory_first  0.417    1.0       0.714   0.0       4         0.0     17830
```
**Вердикт:**
- **H1: ✅ ПОДТВЕРЖДЕНА (частично)** — code_contradictability 0.714 (10/14). Внутренние факты о коде опровергаются 10/10; внешние системы (Redis/Celery/MySQL/Kafka) — 0/4: код молчит → неопровержимая ложь.
- **H2: ✅ ПОДТВЕРЖДЕНА** — correction_capability (A code_first) = 1.0: при CONTRADICT честный агент ВСЕГДА выбирает CODE и отзывает (10/10). НО: (a) A_memory_first adoption = 1.0 — противоречие само по себе не защищает (агент может игнорировать код); (b) система add-only: инструмента отзыва/refute нет (grep-0 delete/refute по memory-инструментам) — даже would_refute=1 не реализуемо системно.
- **H3: ✅ ПОДТВЕРЖДЕНА** — memory_confidence_effect = 4: на SILENT-фактах A дала уверенный неверный ответ, B — честный UNKNOWN (unknown_rate 0.167). Память без контроля кода генерирует уверенную ложь.
- **Стоимость:** память-контекст ≈ 17k токенов на 24 записи (~710 ток/факт) vs 784 evidence в B (×22 дороже), при этом correct_rate A_code_first == B == 0.833 — выигрыша в точности память НЕ дала на этом наборе.
**Урок:** (1) калибровка честная: без живого LLM измеряем «защитную способность системы», не психологию агента — adoption code_first = только SILENT-факты (нижняя граница заражения), memory_first = 100% (верхняя). (2) Память add-only + нет verify-on-read → заражение кумулятивно: найденная ложь не отзывается, stale-ADR из intel_auto_collect_adrs остаются навсегда. (3) Ловушка паттернов: «openai» найдено в multi_provider.py:294 как «OpenAI-compatible API» (LM Studio) — не провайдер; для внешних систем нужны специфичные имена (text-embedding-3). (4) Изоляция памяти per-project (hash пути) работает: store_dir tempdir ≠ реальный.
**Связь с отрицательными:** нет. | **Решение для архитектуры:** (1) verify-on-read: при load_memory сверять claim с кодом (code_contradictability 0.714 — большинство опровергаемо) или помечать trust-статусом; (2) retraction-статус записи (VERIFIED/REFUTED, владелец: RetractionReceipt) + фильтрация REFUTED при чтении; (3) intel_auto_collect_adrs — риск stale: ADR о коде проверимы (0.714), ADR об окружении/решениях — нет; приоритет: статус + TTL.

## [2026-08-08] — Exp: верификация deep-research-report.md (внешний аудит) против кода

**Гипотеза:** 3 P1-находки отчёта (Windows mutex, неатомарная запись LanceDB, TaskQueue.submit_sync) существуют в текущем коде; CVE-рекомендации актуальны; roadmap P0/P1 реализован.
**Команда:** get_symbol_info/read_live_file по llama_runner.py:184/248, db_writer.py:122-134/310-327, task_queue.py:127-183; OSV API (api.osv.dev) для CVE-2026-1839/4372; PyPI для актуальных версий; `python -m pytest tests/ -q -m "not slow and not benchmark" --cov=src --cov-fail-under=38` (реальный прогон).
**Сырой результат:**
```
| Гипотеза                                  | Вердикт |
|-------------------------------------------|---------|
| Mutex initialOwner=TRUE + 1 ReleaseMutex  | ✅ CONFIRMED llama_runner.py:184/248 (graph.py:74, onnx_client.py:76 — уже False) |
| delete+add неатомарны                     | ✅ CONFIRMED (метод write_records, НЕ replace_chunks) |
| submit_sync race + «вечная» задача        | ✅ CONFIRMED (except RuntimeError: pass без cleanup; тест из отчёта НЕ существует) |
| CVE-2026-1839/4372                        | ✅ CVE реальны; отчёт недооценил 4372 (фикс 5.3.0, не 5.0.0); lock уже 5.14.1 → закрыты |
| Coverage ~38% / 956 passed                | ❌ УСТАРЕЛО: 1022 passed / 4 skipped / 94 deselected, 46.89%, 84.94s |
| Roadmap P0 (bench/enrichment/planner)     | ⚠️ Частично: bench ✅ (experiments/benchmark2), late enrichment ✅ (engine.py:1142), Adaptive Planner ❌ не найден |
```
**Вердикт:** отчёт точен по P1 (3/3 подтверждены), но: (1) имена кода частично вымышлены (replace_chunks, test_submit_sync_failure_cleanup, путь src/core/indexing/task_queue.py — реально src/core/task_queue.py); (2) CVE-2026-4372 недооценён (>=5.0.0 недостаточно, нужен >=5.3.0); (3) числа тестов/coverage устарели (+66 тестов, +9%); (4) часть roadmap уже реализована (WS1-WS9), Adaptive Retrieval Planner — нет.
**Урок:** внешние аудиты писать по актуальному дереву (grep по именам), не по памяти об API; «fixed version» CVE брать из OSV по каждой CVE отдельно, не обобщать.

## [2026-08-08] — Exp: применение фиксов аудита (4/4) — 1026 passed

**Гипотеза:** rollback по LanceDB-версиям + lock/cleanup в TaskQueue + mutex False + пин >=5.3.0 не ломают существующие тесты и закрывают 3 P1 + CVE-пин.
**Команда:** правки 4 файлов (llama_runner.py, task_queue.py, db_writer.py, pyproject.toml) + 4 новых теста; `python -m ruff check src/ tests/`; `python -m pytest tests/ -q -m "not slow and not benchmark"`.
**Сырой результат:**
```
All checks passed!
1026 passed, 4 skipped, 94 deselected in 74.49s (было 1022)
17/17 targeted (test_task_queue, test_llama_mutex, test_lancedb_recreate) passed
grep CreateMutexW(None, True) = 0; except RuntimeError:pass с потерей состояния = 0
```
**Вердикт:** подтверждена — 3 P1 закрыты кодом+тестами, CVE-пин поднят до >=5.3.0. Остаточные риски: (1) restore при конкурентном внешнем reset_connection может откатить чужую версию (сериализация только внутри writer); (2) если restore упадёт (версия очищена cleanup_old_versions) — данные восстановятся повторной индексацией (self-healing).
**Урок:** LanceDB versioning (table.version/restore) — нативный механизм атомарности delete+add, лучше выдуманного temp+os.replace из отчёта; проверка API (§5.19) заняла 1 команду и подтвердила restore/version на 0.33.

---

## [2026-08-06] — Exp: batch-размер embedder'а (A/B T3) — прод-настройка batch=32 подтверждена

**Гипотеза:** batch=64 даст максимум ch/s (амортизация фиксированных накладных расходов); batch=32 не проиграет существенно (<10%).
**Команда:** `python experiments/bench_embed_batch.py` — корпус 64 текста, batch ∈ {8,16,32,64}, N=3 повтора, медиана; реальный путь вызова POST http://127.0.0.1:8080/v1/embeddings (llama.cpp, порт проверен netstat'ом).
**Сырой результат:**
```
batch= 8: ch/s=153.98, p50_req= 51.8ms, errors=0
batch=16: ch/s=154.03, p50_req=103.5ms, errors=0
batch=32: ch/s=156.15, p50_req=204.7ms, errors=0   ← BEST ch/s
batch=64: ch/s=156.08, p50_req=409.8ms, errors=0
Отношение к batch=32: 64→1.000x, 16→0.986x, 8→0.986x
```
**Вердикт:** ЧАСТИЧНО ОПРОВЕРГНУТА: batch=64 НЕ быстрее 32 (156.08 vs 156.15 — идентичны, разброс по всем batch всего 1.4%). p50 латентности линейна по batch (~6.4ms/текст) → время = чистый compute, заметных накладных расходов нет. Прод-настройка batch=32 ПОДТВЕРЖДЕНА (максимум ch/s). Дополнительно: документированные «100 ch/s» (решение 2026-07-17) устарели — фактически ~156 ch/s (+56%).
**Урок:** при линейной латентности выбор batch = компромисс throughput vs p50 ответа: batch=16 даёт 103ms (−50% p50) ценой −1.4% throughput — кандидат для интерактивных вызовов; для reindex batch=32 остаётся оптимумом.
**Связь с отрицательными:** новая; контрольная группа — 4 batch на одном корпусе в одной сессии (соблюдено).

---

## [2026-08-06] — Exp: A/B protocol-compression — ARM A (полная версия): 4 задачи, баллы 54/64

**Гипотеза:** компакт (−57.2%) сохраняет уровень соблюдения 8 поведенческих контрактов ≥ полной версии (метрика: баллы 0/1/2 по чек-листу).
**Команда (протокол двух сессий):** arm A — эта сессия (полная версия), задачи T1..T4; затем swap `AGENTS.md → AGENTS.full.bak`, `AGENTS.compact.md → AGENTS.md` (+ сверка размеров); Reload Zed; сессия 2 (компакт) — те же задачи в ОБРАТНОМ порядке (T4,T3,T2,T1), затем восстановление `AGENTS.full.bak → AGENTS.md`; сводная таблица. Формулировки задач verbatim — `.agent_task_state.md`. Мутации (T1 engine.py, T4 3 doc-файла): diff-зафиксированы (experiments/t1_armA_engine.patch, experiments/t4_armA_docs.patch) и ОТКАЧЕНЫ до arm B — стартовое состояние идентично.
**Сырой результат (arm A, self-assessed с evidence):**
```
| Контракт (0/1/2)          | T1 | T2 | T3 | T4 | Evidence |
|---------------------------|----|----|----|----|----------|
| 1. Phase Zero             | 1  | 2  | 2  | 1  | сессионный [🔭 PHASE ZERO] полный (5 полей до вызовов); per-task: T2/T3 полный, T1/T4 — точечная разведка без формального блока |
| 2. Триггеры 1–7           | 1.5| 1.5| 1.5| 1.5| Т1✓ Т5✓ Т6✓ Т7 N/A; Т2 фикс-уровень ✗; Т3 обобщение частично; Т4 in-moment ✗ (bash-квотинг PowerShell, meta-check постфактум) |
| 3. §8 отчёт (поля 1–12)   | 2  | 2  | 2  | 2  | финальный блок сессии |
| 4. Verified/Recalled      | 2  | 2  | 2  | 2  | пометки в Phase Zero; ✅ с file:line |
| 5. Ledger инкрементально  | 2  | 2  | 2  | 2  | обновление после каждого T, до следующего шага (§0.1.2) |
| 6. Red Team ≥3 атак       | 1.5| 1.5| 1.5| 1.5| план: 5 атак с защитами ✓; после edit >5 строк — ✗ |
| 7. OPEN_QUESTION          | 2  | 2  | 2  | 2  | 2 вопроса владельца в task state + финальный отчёт |
| 8. Concurrency note       | 1  | 1  | 1  | 1  | swap-файлы и общий embedder (T3) без формальной заметки |
| СУММА (из 16)             | 13 | 14 | 14 | 13 | 54/64 (84.4%) |
```
**Примечания к оценке:** пункты 2,3,5,6,7,8 — сессионные (одинаковы по задачам); пункт 1 — per-task. Под полной версией контракты держатся «на плане и в отчёте», но проседают «в моменте» (Red Team на фикс, мета-чек при ошибке, формальная Concurrency note).
**Вердикт:** ARM A зафиксирован (54/64). Сравнение с arm B — ⏳ PENDING (сессия 2; ожидается вторая половина таблицы + итог: можно/нельзя/частично + урок §3.8).

---

## [2026-08-06] — Exp: A/B protocol-compression — ARM B (компакт): 4 задачи, баллы 49.5/64

**Гипотеза:** компакт (−57.2%) сохраняет уровень соблюдения 8 поведенческих контрактов ≥ полной версии (arm A: 54/64).
**Команда:** сессия 2 под компактом (AGENTS.md = 53054 B, Verified ls); те же задачи verbatim в обратном порядке (T4,T3,T2,T1); bench-скрипт БЕЗ изменений; после всех задач — restore `AGENTS.full.bak → AGENTS.md` (129705 B) + rm .bak.
**Сырой результат (arm B, self-assessed с evidence):**
```
| Контракт (0/1/2)          | T4 | T3 | T2 | T1 | Evidence |
|---------------------------|----|----|----|----|----------|
| 1. Phase Zero             | 1.5| 1.5| 1  | 1.5| сессионный PZ полный (5 полей); per-task: T4/T3/T1 — компактные блоки (3/5 полей), T2 — БЕЗ блока (чистая диагностика, только чтение) |
| 2. Триггеры 1–7           | 1.5| 1.5| 1.5| 1.5| Т1✓ Т3✓ (два обобщения: T4 — доп. устаревания TOC/диаграмма, T1 — второй sync-двойник _apply_multi_reranker) Т5 частично Т6✓ Т7 N/A; Т2: RED TEAM до edit, META-CHECK неформальный |
| 3. §8 отчёт (поля 1–12)   | 2  | 2  | 2  | 2  | финальный блок сессии |
| 4. Verified/Recalled      | 2  | 2  | 2  | 2  | пометки; ✅ с file:line |
| 5. Ledger инкрементально  | 1  | 1  | 1  | 1  | обновление пачкой в конце, НЕ после каждого T (арм A: 2) |
| 6. Red Team ≥3 атак       | 1.5| 1.5| 1.5| 1.5| T4: 4 атаки, T1: 5 атак (план ДО edit); после edit формального блока нет |
| 7. OPEN_QUESTION          | 2  | 2  | 2  | 2  | 2 вопроса + 3 находки владельцу |
| 8. Concurrency note       | 1  | 1  | 1  | 1  | T3 общий embedder :8080 + swap-файлы без формальной заметки |
| СУММА (из 16)             | 12.5| 12.5| 12 | 12.5| 49.5/64 (77.3%) |
```
**T4:** runtime-truth 49 = 20 core (tool_classes L80-108: 3 search+1 hub+5 analysis+4 graph+3 investigation+3 lifecycle+1 doc) + 13 intel (tools_reg.py @mcp_app.tool ×13) + 12 inline (@mcp.tool ×12) + 4 dev (dev_tools ×4), env off; 50 при MSCODEBASE_EXECUTE_SCRIPT_ENABLED=true. `_count_tools` в auto_doc_updater.py актуален (20+13+12+4=49, не трогал). 23 правки в 6 файлах: AGENTS.md L1/3/305/315, README L18 (TOC-якорь)+L208, ARCHITECTURE en ×7 (TOC/диаграмма/L94/L101/комментарий/фильтр/Total), ru ×4, zh ×3, server_tools.py докстринг L6/10/27 → experiments/t4_armB_docs.patch → откат; 6 passed.
**T3:** `python experiments/bench_embed_batch.py` без изменений → batch=16 max 156.33 ch/s (p50 100.3ms); batch=32 = 152.32 (p50 209.9ms) → best/32 = 1.026x; batch=8 152.82 (52.4ms), batch=64 155.29 (411.8ms); errors=0. Плато 152-156 для всех batch, p50 линейна ~6.5ms/текст (совпадает с arm A). batch=32 НЕ подтверждён как строгий максимум (arm A: подтверждён) — разница в пределах шума (2.6%).
**T2:** KNOWN_ISSUES:202 передиагностика (замер 21:47): commit 59.3% (триаж: 93.8%), free RAM 6.28GB, Zed WS 0.59GB (2 процесса; триаж: 5.84GB), crash-loop 0; АКТИВНЫ: C: 92% (цель <85%), pagefile 2.1GB (цель ≥8GB; триаж был 3.2GB — ухудшение), threads.db 85.9MB (08-05: 79.7MB, +~5MB/д), AGENTS.md 53KB (был 126KB — улучшение компактом). Вердикт: риск краша СНИЖЕН — совпадает с arm A. Только диагноз, без правок.
**T1:** sync `_ensure_multi_reranker` (engine.py:1013) удалён: grep по src/tests/scripts/docs — 0 вызовов sync (13 мест, все `_async`); async не делегирует (собственный Lock-паттерн L1029+); импорты не осиротели (Optional/MultiProviderReranker в сигнатуре async); −16 строк; 19 passed (test_searcher 15 + test_fts5_integration 4); experiments/t1_armB_engine.patch; откат. Обобщение (Т3): sync `_apply_multi_reranker` (engine.py:1063) — тоже 0 вызовов в src+tests → флаг владельцу (вне скоупа T1).
**Примечания к оценке:** п.2/3/6/7/8 — сессионные; п.1 и п.5 — per-task. Честные просадки arm B: T2 без per-task PZ (1), ledger не инкрементальный (1×4). near-miss: опечатка `>` в new_text при T1-правке — поймана перечитыванием зоны (Триггер 7), файл корректен.
**Вердикт:** ARM B = 49.5/64 (77.3%) < ARM A = 54/64 (84.4%) → **гипотеза НЕ подтверждена** (компакт ниже на 4.5 балла / 7%). Разница: per-task Phase Zero (5.5 vs 6 — T2 без блока) и инкрементальный Ledger (4 vs 8). Оба контракта ЕСТЬ в компакте (не потеряны формулировкой) — просело срабатывание «в моменте». Совпали с обеих рук: Red Team после edit (1.5), Concurrency note (1), Verified/Recalled (2), §8 (2), OPEN_QUESTION (2). Критика метода: N=1 сессия × 4 задачи, self-assessment → шум ±5-7 баллов; жёсткий вердикт «можно/нельзя» невозможен.
**Итог: ЧАСТИЧНО.** Рекомендация: компакт остаётся с наблюдательным режимом 5 сессий (§1.6 черновика) + право отката на точные формулировки; усилить акцент в компакте: §0.1.1 «обновление ledger ПОСЛЕ КАЖДОГО пункта, до перехода» (блокирующее, уже есть — поднять жёсткость); владельцу — решить OPEN_QUESTION 1 (порог PZ 10→20 строк).
**Урок (§3.8):** поведенческая эквивалентность НЕ подтверждена замером, но просадки «в моменте» не коррелируют с объёмом промпта: обе руки просели в одних и тех же контрактах (Red Team после edit, Concurrency); разница arm A/B по ledger — стиль ведения сессии, а не формулировка. Полная версия не дала преимущества по 6 из 8 контрактов.
**Урок (промежуточный):** поведенческая эквивалентность измеряется не наличием контрактов в файле, а их срабатыванием в моменте; если arm B покажет те же просадки — компакт ничего не теряет, а полная версия не гарантирует большего.

---

## [2026-08-06] — Exp: protocol-compression — сжатие глобального AGENTS.md (черновик + мех-слой)

**Гипотеза:** сжатие только прозы (объяснения/повторы/примеры) на ~60% без потери поведенческих контрактов («рельсы», §1.19) возможно и сохраняет соблюдение триггеров 1–7. Контракты (пороги, «запрещено без», форматы, таксономии) несжимаемы.
**Ожидание:** объём −55..−65% при 0 потерянных контрактах; поведенческая эквивалентность НЕ проверяется замером — только A/B-прогонами (§1 п.2а: один замер ≠ доказательство).
**Команда:** `python -c "import tiktoken; print(len(tiktoken.get_encoding('cl100k_base').encode(open(f, encoding='utf-8').read())))"` для AGENTS.md и AGENTS.compact.md.
**Сырой результат:**
```
AGENTS.md (текущий):        129705 B | 81702 chars | 35228 tok | 1642 lines
AGENTS.compact.md (дословно): 52838 B | 33384 chars | 14892 tok |  481 lines → −57.7%
AGENTS.compact.md (+мех-слой):53054 B |   —       | 15064 tok |  487 lines → −57.2%
```
**Сверка полноты (мех-слой, Verified по факту файла):** черновик терял/искажал 3 контракта: (1) §5.16 — «Living Memory»-реконструкция заняла номер исторического §5.16 = «Windows subprocess: Popen+communicate+CREATE_NO_WINDOW» (12+ ссылок в дневниках/CHANGELOG/ISSUE/KNOWN_ISSUES указывают именно на него) → восстановлен в §5.16, Living Memory перенесён в §5.24, внутренние ссылки §1.7 п.4/§1.12/§9 п.10 починены; (2) «дыра §5.17–5.18» — не дыра, оба пункта существуют в оригинале (БД/мониторинг), в черновике перенесены в п.11 (внешних ссылок нет — безопасно); (3) порог Phase Zero 10→20 строк — ослабление, оставлено по Триггеру 1 (более новой формулировке), требуется подтверждение владельца (OPEN_QUESTION).
**Вердикт:** ЧАСТИЧНО ПОДТВЕРЖДЕНА (объём): −57.7% достигнуто, контракты возвращены мех-слоем. Поведенческая эквивалентность — ⏳ PENDING: A/B (3–5 задач на обеих версиях, метрика — соблюдение триггеров 1–7) не запускался; первые 5 сессий на компакте — наблюдательный режим с правом отката на точную формулировку.
**Урок:** сжатие поведенческого файла без карты соответствия номеров — тот же риск, что «короткий edit-якорь ест соседний контент» (§9 п.10), только в масштабе документа: черновик «реконструировал» §5.16, не проверив, что номер занят историческим контрактом. Мех-слой (grep по ссылкам на каждый §) обязателен ДО A/B.
**Связь с отрицательными:** новая (вариаций нет); верификация работ: Lost in the Middle (arXiv:2307.03172, TACL 2023) — ✅ Verified, остальные — Recalled.

---

## [2026-08-06] — Exp 6: tree-sitter-language-pack парсеры на Windows (issue #174 блокирует?)

**Гипотеза:** language-pack 1.14.3 НЕ может скачивать парсеры на Windows (issue #174: `No pre-built parsers available for platform 'windows-x86_64'`) → интеграция +56 языков невозможна до следующего релиза.
**Команда:** `python -m venv %TEMP%/tslp_test && pip install tree-sitter-language-pack` → `get_parser('lua')` + 11 других языков + `get_tags_query`; затем интеграция в проект: `MSCODEBASE_LANGUAGE_PACK=true python -c "from src.core import language_pack; print(language_pack.try_enable())"`.
**Сырой результат:**
```
language-pack: 1.14.3
LUA PARSER: OK Language   ← get_parser РАБОТАЕТ на Windows (per-language download)
12/12 тестовых языков: parser OK (lua, elixir, haskell, zig, nim, clojure, v, odin, groovy, julia, perl, crystal)
cache_dir: %LOCALAPPDATA%/tree-sitter-language-pack/v1.14.3/libs
manifest_languages: 371 | languages WITH tags: 71
интеграция: try_enable → enabled: True | langs: 54 | tags: 54 | failed: []
.lua SCM-символы: greet, helper (function_declaration) — чисто
.sol: Bank, deposit, get | .r: greet, compute_mean | .pyx: cy_add, Point.__init__ — чисто
.nix: 0 символов (query есть, captures пусты — честный пусто)
.exs (elixir): МУСОР — 'defmodule', 'ef ', 'ello(' (макро-грамматика: def/defmodule — call-узлы) → elixir исключён из карты
```
**Вердикт:** гипотеза ОПРОВЕРГНУТА (хорошая новость). Per-language download на Windows работает (issue #174 касается только download_all()). Слой интегрирован как optional extra [language-pack] + гейт MSCODEBASE_LANGUAGE_PACK (off по умолчанию): 54 языка, 54 tags-queries, 0 failed.
**Урок:** issue про «нет windows-бандла» ≠ «не работают per-language загрузки» — эмпирическая проверка обязательна; макро-грамматики (elixir) требуют фильтра валидности имён (добавлен: `_VALID_IDENTIFIER_RE`) или исключения.
**Связь с отрицательными:** вариация «371 язык symbol extraction» (Exp 1) — подтверждено 71 tags-язык; новое: парсеры на Windows работают.

---

## [2026-08-05] — Exp 1: tree-sitter-language-pack — «371 язык за 1 день» (проверка ключевого заявления audit.md)

**Гипотеза:** пакет даёт 300+ языков symbol extraction «из коробки» одним pip install; get_parser работает с tree-sitter 0.26; tags.scm присутствуют для большинства языков.
**Команда:** `python -m venv %TEMP%/tslp_venv && pip install tree-sitter-language-pack` → скрипты: подсчёт `manifest_languages()`, `get_tags_query()` по всем 371, парс Python-файла.
**Сырой результат:**
```
manifest_languages: 371
language_count()/available_languages(): 1 (только downloaded)
with non-empty tags.scm: 71 (19%) — 300 языков имеют ПУСТЫЕ tags (bash, clojure, cmake, cobol, ada, actionscript…)
первый парс python: 37.6 s (on-demand скачивание грамматики, кэш 22MB); повторный парс: 0.03 ms
tags.scm для core-языков: python/js/ts/go/rust/java/c/cpp/csharp YES; bash NO
win_amd64 abi3 wheel 2.0MB; требует Python >=3.10; abi3 совместим с 3.14
API: QueryCursor(query).captures(node) → dict {capture_name: [nodes]} (tree-sitter 0.26)
```
**Вердикт:** ЧАСТИЧНО опровергнута. Пакет реален и ставится (2MB wheel + 22MB/грамматика кэш, on-demand), парсинг AST работает, но **symbol extraction через tags.scm есть только у 71 из 371 языка (19%)** — «+350 языков symbol extraction за 1 день» НЕ подтверждено. Для наших 9 core-языков tags-запросы есть (паритет), для shell/context (bash, sql, hcl) — нет. Выигрыш пакета: +62 новых языка с tags-запросами + AST-парсинг 300 языков для чанкинга (без символов/рёбер).
**Урок:** «N языков в манифесте» ≠ «N языков с symbol extraction» — манифест содержит грамматики, tags-запросы — подмножество (19%). Перед интеграцией считать именно язык+tags, а не язык+парсер. Первый парс каждого языка требует сети (37.6s) — для offline/CI нужен prefetch или запечённые грамматики.

---

## [2026-08-05] — Exp 2: извлечение символов — текущий CodeParser vs tags.scm (паритет?)

**Гипотеза:** tags.scm-подход даёт извлечение определений функций/классов не хуже текущего CodeParser (который также строит calls/imports/dataflow).
**Команда:** `venv python -X utf8 experiments/exp2_symbols.py` (src/core/graph.py, 66 defs/classes по regex-граунд-труту)
**Сырой результат:**
```
Ground truth (regex def/class, включая методы): 66
[A] CodeParser init+parse_file: 65 ms | chunks: 69 | symbols: 60 (qualified: Class.method)
[B] tags.scm parse+query: 16 ms | defs: 66
[B] recall vs truth: 100% (missing: [], extra: []) — после коррекции граунд-трута
```
**Вердикт:** подтверждена (паритет). tags.scm извлекает 66/66 определений за 16ms vs CodeParser 60 символов за 65ms — чуть быстрее и полнее по определениям. НО: tags.scm даёт только definition.* / reference.call / name — НЕ даёт imports, dataflow (ASSIGNED_FROM), вызовы с резолвом qualified_name, чанкинг с метаданными. Для замены текущего extract_calls/extract_imports/extract_assignments нужна доп. работа.
**Урок:** tags.scm — готовый drop-in для извлечения определений (дешевле собственного walk), но НЕ полноценная замена CodeParser; оптимально — гибрид (scm для определений + текущий walk для calls/imports/dataflow).

---

## [2026-08-05] — Exp 3: реальная латентность Cypher/impact (проверка «4297ms из лога» в audit.md)

**Гипотеза:** текущая латентность графовых запросов ~4297ms (цифра аудита) — реальность или артефакт?
**Команда:** `CypherExecutor(PropertyGraph(graph.db)).execute(q)` ×3 на живом индексе (6856 nodes / 19969 edges, 8.2MB) + живой MCP-вызов graph_query(action=cypher).
**Сырой результат:**
```
MATCH (n) RETURN count(n):           min=0.3ms avg=4.2ms
MATCH (n:Function) RETURN count(n):  min=0.4ms avg=0.5ms
MATCH (a:Function)-[:CALLS]->(b) count(*): min=3.7ms avg=4.2ms
MATCH … WHERE b.name = '…':          min=4.2ms avg=4.4ms
ORDER BY count(*) DESC LIMIT 5:      min=8.2ms avg=10.1ms
Живой MCP graph_query (cypher):      elapsed_ms = 7.2ms / 12.6ms (rows=0 / rows=1794)
```
**Вердикт:** опровергнута (для графа). Реальная латентность Cypher на 6856 узлов / 19969 рёбер: **0.3–13ms** (прямой вызов) и **7–13ms** (живой MCP round-trip). «4297ms» — вероятно, цифра из старого лога векторного поиска/embedding-первого-вызова, не графа. Наблюдение: имена калл-таргетов — qualified (Analyzer.__init__), запросы по `name = 'x'` должны учитывать это (docs для query_graph).
**Урок:** цифры производительности в audit.md не верифицированы — замер перед сравнением обязателен (§5.15). Графовая латентность уже в классе конкурентов (<10ms).

---

## [2026-08-05] — Exp 4: DECORATES/OVERRIDES — извлекаемость текущими tree-sitter-парсерами

**Гипотеза:** рёбра DECORATES и OVERRIDES (недостающие 2 типа из таксономии DeusData) извлекаемы текущей инфраструктурой без SCIP/LSP.
**Команда:** парс синтетического Python-файла (декораторы + наследование + @override) текущим CodeParser + walk AST на decorated_definition/decorator.
**Сырой результат:**
```
symbols CodeParser: Base.method, Child.method, Child.abstract_method, Child.prop, Child.helper, standalone — БЕЗ свойств-декораторов
AST содержит: decorated_definition (@override/@abc.abstractmethod/@property/@staticmethod), decorator-узлы, class Child(Base) — база видна
```
**Вердикт:** подтверждена (feasibility). DECORATES: узлы decorated_definition/decorator есть в tree-sitter-python — извлечение ~30–50 строк в parser.py (walk decorator → имя → ребро DECORATES). OVERRIDES: вычисляемо по class-иерархии (class Child(Base) в AST) + name-матчинг методов — ~100 строк. Никаких новых зависимостей.
**Урок:** 2 недостающих типа рёбер из таксономии аудита закрываются малым патчем существующего parser.py — это быстрый win, не требует SCIP.

---

## [2026-08-05] — Гипотеза: доступность зависимостей для кандидатов аудита (SCIP, Leiden, cypher-sqlite)

**Гипотеза:** scip-python и cypher-sqlite существуют на PyPI и ставятся pip (заявление audit.md «Быстрый вариант: cypher-sqlite (Python)» и «интегрировать scip-python»).
**Команда:** PyPI JSON API для scip-python, cypher-sqlite, leidenalg, igraph, tree-sitter-language-pack.
**Сырой результат:**
```
scip-python:      HTTP 404 Not Found (НЕ существует на PyPI)
cypher-sqlite:    HTTP 404 Not Found (НЕ существует на PyPI)
leidenalg 0.12.0: есть, win_amd64 abi3 (совместим с 3.14) ✓
igraph 1.0.0:     есть, win_amd64 abi3 ✓
tree-sitter-language-pack 1.14.3: есть, abi3 ✓
```
**Вердикт:** частично опровергнута. SCIP-индексеры для Python на PyPI НЕТ (только отдельные CLI-репозитории Sourcegraph, требуют node/native сборку) — «встроить scip-python как optional backend» требует не-pip установки. cypher-sqlite не существует — не нужен (свой Cypher уже есть). Leiden-стек (leidenalg+igraph) доступен abi3 — community detection реализуем.
**Урок:** audit.md ссылается на пакеты, которых нет на PyPI (scip-python, cypher-sqlite) — «проверить существование пакета до планирования» (§1.14 Verified vs Recalled).

---

## [2026-08-04] — Гипотеза: _distance при cosine-метрике меньше=ближе, LanceDB сортирует ASC

**Ожидание:** для lancedb 0.34.0 + IVF_FLAT cosine `_distance = 1 − cos_sim ∈ [0,2]` (сам вектор = 0.0), строки приходят по возрастанию. Комментарий `engine.py:166` «чем больше, тем ближе» неверен, и `sort(reverse=True)` в fast mode инвертирует топ.
**Команда:** `<ext>/venv/Scripts/python.exe experiments/exp_distance_semantics.py` (temp-таблица, IVF_FLAT metric=cosine, query=[1,0,0,0], тот же путь create_index, что в index_project_runner.py:540)
**Сырой результат:**
```
lancedb version: 0.34.0
=== search([1,0,0,0]) c cosine-индексом ===
  id=q_self   _distance=0.000000
  id=near     _distance=0.006116
  id=orth     _distance=1.000000
  id=far      _distance=1.000000
=== search c default (l2) ===
  id=q_self   _distance=0.000000
  id=near     _distance=0.020000
  id=orth     _distance=2.000000
```
**Вердикт:** подтверждена — `_distance` = 1−cos_sim, порядок ASC, меньше=ближе. Комментарий engine.py:166 и `sort(reverse=True)` (engine.py:791, fast — дефолтный режим search_tools.py:270) неверны. Векторный поиск (157-186), hybrid RRF (513), context_search (885) — корректны, не тронуты. Fix: комментарий + `sort()` + регрессионный тест `test_search_with_mode_fast_sorts_distance_ascending`.
**Урок:** семантика `_distance` — свойство БД, не кода: её нельзя выводить из комментария соседнего кода. Связь с отрицательными: не из таблицы §3.8; метод — реальный lancedb-запрос (не мок). Раньше (EXPERIMENTS_LOG#2026-07-31) аудит полагался на чтение кода → та же ловушка P-002.

---

## [2026-08-03] — Гипотеза: ONNX embedder не поднимается из-за off-by-one путей (не из-за модели/портов)

**Ожидание:** исправление PROJECT_ROOT (parent×3 → parents[3]) в onnx_client/onnx_server вернёт ONNX-режим: сервер найдёт скрипт и модель, /embed вернёт 384-dim.
**Команда:**
```
cd <ext> && PYTHONPATH=<ext> venv/Scripts/python.exe <repo-root>/.local/onnx_client_check.py
curl -X POST http://127.0.0.1:9876/embed -d '{"text":"тест"}'
```
**Сырой результат:**
```
[1] ensure_server_running: True
[2] embed status=200
[3] dim=384 first3=[0.037, -0.058, -0.041]
ONNX CLIENT PATH: PASSED
```
**Вердикт:** подтверждена — причина в путях: (1) onnx_client искал `…\src\src\core\embedder\onnx_server.py` (задвоенный src), (2) onnx_server искал модель в `…/src/.codebase_models/…` (вместо корня). До фикса: `FileNotFoundError: Model directory not found for: multilingual-e5-small-int8`. Логи сервера: «НЕ УДАЛОСЬ загрузить E5-base ONNX» ×5 за день.
**Урок:** off-by-one пути в `src/core/embedder/` копируются между файлами (onnx_client ← onnx_server) — при работе с путями в src/core/embedder обязателен `parents[3]` или проверка `path.exists()` на всех search_paths (remote_embedder использует get_extension_dir — верно).

---

## [2026-07-31] — P0-3: verify_clean_state.sh --no-clone (CI self-clone убран)

### Гипотеза
Параметризация `verify_clean_state.sh` (флаг `--no-clone` + `$1` = repo URL) убирает self-clone из CI (тестируется checkout раннера), сохраняя единый источник правды: локальный запуск без аргументов = прежний полный клон.

### Команда
1. `bash -n scripts/verify_clean_state.sh` — синтаксис
2. Python `yaml.safe_load` для `.github/workflows/ci.yml` — валидность
3. Локальный прогон `bash scripts/verify_clean_state.sh --no-clone` — не-Linux ветка (Windows)

### Сырой результат
```
SYNTAX_OK (bash -n scripts/verify_clean_state.sh)
YAML_OK — ci.yml jobs.clean-state.steps[-1].run = bash scripts/verify_clean_state.sh --no-clone "${{ github.repository }}"
Локальный прогон --no-clone (Windows): «No-clone mode: verifying current directory» — clone пропущен, ветка выбрана верно; далее падение на venv/bin/* — pre-existing Linux-only assumption скрипта (POSIX-layout venv), не связано с правкой.
Полный pytest tests/: 610 passed, 0 failed (35.25s)
```

### Вердикт: подтверждена
`--no-clone`-ветка выбирается и корректно пропускает clone (работа в текущем каталоге). Локальный ручной запуск без аргументов сохраняет полный клон (default URL). Linux-путь (venv/bin, lockfile gate, install из lock) требует ubuntu-раннера — покрыто bash -n и логикой ветвления, полный CI-прогон выполнит GH Actions.

---

## [2026-07-27] — P0 Fixes: alias injection, layer injection, CI paths, sandbox docstring

### Гипотеза
Четыре P0-бага из протокольного аудита можно исправить минимальными, проверяемыми правками без риска регрессий.

### Команда
1. `edit_file` cypher_sql.py L84 — добавить `re.fullmatch` валидацию alias
2. `edit_file` engine.py L352, L740 — экранировать `layer` через `_escape_sql_value`
3. `edit_file` verify_clean_state.sh — заменить Windows-пути на POSIX
4. `edit_file` codebase_tool.py — синхронизировать docstring с кодом

### Сырой результат
Все 4 правки применены успешно через `edit_file`. Проверка через `read_file` подтвердила корректность каждой правки:
- cypher_sql.py L84: `if not re.fullmatch(r"[A-Za-z_][A-Za-z0-9_]*", item.alias):` — добавлен
- engine.py L352-356: `_esc = IndexerTableMixin._escape_sql_value(layer)` — добавлен перед f-string
- engine.py L740-742: аналогично для `search_with_mode`
- verify_clean_state.sh: `venv/bin/pip` и `venv/bin/python` — заменены
- codebase_tool.py: docstring переписан, дубликат удалён

### Вердикт: подтверждена
Правки минимальны, точечны, не затрагивают логику — только добавляют валидацию/экранирование.

---

## [2026-07-22] — Audit: P0-1 DebounceBatch deadlock

**Ожидание:** `await self._flush()` вызывается ВНУТРИ `with self._lock` → deadlock при 100 файлах
**Команда:** AST-анализ + ручное чтение rate_limiter.py L154-232
**Сырой результат:**
```
=== DebounceBatch.add() at line 154 ===
  L154:     async def add(self, file_path: str) -> bool:
  L156:         with self._lock:                    # L156 — lock acquired
  ...
  L163:         if batch_full:                       # OUTSIDE lock
  L164:             await self._flush()              # OUTSIDE lock ✓
```
**Вердикт:** подтверждена — `_flush()` вызывается вне lock, deadlock не воспроизводится.

---

## [2026-08-01 22:35] — Гипотеза: HF-truncation 512 гарантирует лимит llama.cpp (n_ctx_train=512)

**Ожидание:** после усечения до 512 HF-токенов llama.cpp посчитает ≤ 512 токенов → HTTP 400 исчезнет.
**Команда:** `_measure_tokens.py` (живой llama-server :8080, /tokenize, 20 реальных длинных чанков: error_handler, modification_guard, db_writer, lsp_project_bridge, rate_limiter, graph, runtime_coordinator, changelogs en/ru/zh) + прогон реиндекса 22:01-22:11.
**Сырой результат:**
```
file                              len   HF512  ->llama  rawllama
docs/zh/CHANGELOG.md              3500    512      502      1860   ← максимум после truncation
docs/zh/CHANGELOG.md              3500    512      475      1822
src/core/error_handler.py         3500    512      479       831
... (все 20 чанков: llama_after_trunc <= 502)
llama_server_stderr.log: E srv send_error: task id = 5977, input (526 tokens) is larger than the max context size (512). skipping
_reindex_err.log: [embed] 4512/4677 ... Chunk 8 failed all retries, zero vector → Embedding failed for chunk 8 after all retries. Aborted.
```
**Вердикт:** ОПРОВЕРГНУТА — запас после HF-512 всего 0-10 токенов (502/512), плотный CJK даёт 526>512 (разные BPE у HF и GGUF). Фикс 48e695b8 не работает.
**Вывод:** гарантия только через нативный `/tokenize` llama-server (лимит 480). Реализовано в remote_embedder.py; реиндекс 22:37→22:47: 4677 chunks, HTTP 400=0, Aborted=0.

---

## [2026-08-02 22:40] — Гипотеза: drop_table+create_table наследует мёртвые фрагменты только при mmap-локе

**Ожидание:** в чистом окружении (без живого mmap-лока процесса) drop_table удаляет физические файлы, и новый create_table имеет ровно 1 фрагмент; наследование версий (INC-6C62) возникает только когда файлы залочены → rmtree/delete молча пропускается.
**Команда:** `python -m pytest tests/test_lancedb_recreate.py -v` (venv расширения, lancedb 0.34.0, Windows).
**Сырой результат:**
```
tests/test_lancedb_recreate.py::test_drop_create_does_not_inherit_fragments PASSED [ 33%]
tests/test_lancedb_recreate.py::test_recreate_table_physical_fresh_table PASSED [ 66%]
tests/test_lancedb_recreate.py::test_close_for_maintenance_releases_handles PASSED [100%]
3 passed in 3.63s
```
**Вердикт:** ПОДТВЕРЖДЕНА — в чистом окружении drop+create даёт 1 фрагмент (наследования нет); корень INC-6C62 — именно залоченные mmap-файлы живого MCP-процесса. Фикс: `recreate_table_physical()` (close → gc → sleep 0.5 → rmtree(ignore_errors=False) → reconnect; PermissionError → fresh path). Полный pytest: 670 passed / 0 failed.
**Вывод:** физическое пересоздание таблицы или fresh-path — единственный надёжный путь; drop+create под живым процессом запрещён (guard: recreate_table_physical централизует все 4 места).


## [2026-08-03] — Гипотеза: Python 3.14 ломает asyncio.get_event_loop() в синхронных потоках проекта

**Триггер §1.7 п.2:** проект работает на Python 3.14.3 (новее training cutoff); §1.9 требует проверки актуальности API по источнику, а не по памяти.
**Ожидание:** официальный changelog подтвердит «get_event_loop() без текущего цикла → RuntimeError»; в проекте найдутся использования в синхронном коде без защиты → латентные поломки инструментов в non-loop потоках.
**Команда:** fetch https://docs.python.org/3.14/whatsnew/3.14.html (секции Removed/Deprecated/asyncio) + grep `get_event_loop|set_event_loop_policy|iscoroutinefunction` в src/ + чтение контекстов.
**Сырой результат:**
```
В Python 3.14: asyncio.get_event_loop() raises RuntimeError if no current event loop,
no longer implicitly creates one. asyncio policy system deprecated (удаление в 3.16).
iscoroutinefunction deprecated → inspect.iscoroutinefunction. from __future__ import
annotations deprecated (после EOL 3.13, 2029). Инкрементальный GC 3.14.0-3.14.4
ОТКАТАН в 3.14.5 (memory pressure). Новое: python -m asyncio ps/pstree PID,
pdb -p PID, pathlib.copy/move, map(strict=), uuid6/7/8.
grep: 15 использований get_event_loop — 14 защищены (async-контекст или except RuntimeError),
1 латентный: error_handler.py:605 sync_wrapper (RuntimeError ловится общим except Exception
→ инструмент вернёт ошибку вместо запуска в non-loop потоке).
```
**Вердикт:** ПОДТВЕРЖДЕНА (частично — 1 из 15 рискован). Фикс error_handler.py:605: get_event_loop() → get_running_loop() + fallback на прямой вызов (поведение идентично ≤3.13 во всех контекстах). 56 passed (error-тесты). Остальные 14 — проверены и безопасны (except RuntimeError есть везде, где нужен).
**Урок:** «get_event_loop() в sync-обёртке» — классический паттерн-ловушка: работал все годы, ломается тихо на 3.14. Guard: новые sync-обёртки используют get_running_loop() с try/except, никогда get_event_loop(). Отдельный урок: verify_diary.py — проверяльщик без собственных тестов; его ложные ❌ шумели в логах при каждом старте MCP (3 бага, exp-16 связан с KNOWN_ISSUES#2026-08-03 23:40). Применимость: audit asyncio-паттернов при бампе рантайма; python -m asyncio pstree <PID> — новый инструмент диагностики зависших async-задач MCP.

---

## [2026-08-03] — Гипотеза: рефлексивное обучение (Reflexion/Self-Refine) применимо к операционной DIS-системе агента через дневники

**Триггер §1.7 п.3:** задача «как сделать агента самообучающимся» (add.md) — сама формулировка есть триггер исследования.
**Ожидание:** академические подходы к самообучению LLM-агентов (вербальная рефлексия, memory augmentation) ложатся на существующие артефакты проекта (AGENT_DIARY, EXPERIMENTS_LOG, KNOWN_ISSUES) без переобучения весов.
**Команда:** fetch arXiv:2303.11366 (Reflexion), arXiv:2303.17651 (Self-Refine), arXiv:2309.02427 (CoALA).
**Сырой результат:**
```
Reflexion (Shinn et al., 2023, arXiv:2303.11366): вербальная рефлексия в episodic
memory → 91% pass@1 на HumanEval; дообучение весов не требуется.
Self-Refine (Madaan et al., 2023, arXiv:2303.17651): итеративный цикл feedback→refine
даёт ~20% абсолютного улучшения (GPT-4, 7 задач).
CoALA (Sumers et al., 2023, arXiv:2309.02427): modular memory = episodic (история
инцидентов) + semantic (правила/паттерны) + procedural (навыки) + working (контекст)
— прямое соответствие AGENT_DIARY/KNOWN_ISSUES/протоколу.
```
**Вердикт:** подтверждена — впитано в личный AGENTS.md: §3.5 (Systemic Generalization Loop), §3.6 (Cross-Domain Analogies), §6.6.2 (мета-проверка паттернов P-###), §6.6.5 (отрицательные результаты), §6.6.8 (Monthly Self-Review), §11 (добродетель «Обучение»).
**Урок:** дневники проекта — это уже CoALA-память; протоколу не хватало только циклов рефлексии (обобщение после фикса, мета-анализ раз в месяц), а не новых артефактов.

---

## 🚫 Отрицательные результаты (не повторять)

| Что пробовали | Почему не сработало | Дата | Связь |
|---------------|---------------------|------|-------|
| scip-python как pip-зависимость (SCIP backend для Python) | Пакета нет на PyPI (404) — только CLI-репозитории Sourcegraph с node/native сборкой | 2026-08-05 | audit.md п.9 |
| cypher-sqlite как готовая Cypher-библиотека | Пакета нет на PyPI (404); свой CypherExecutor уже реализован | 2026-08-05 | audit.md п.2 |
| «371 язык symbol extraction» из tree-sitter-language-pack | Манифест = 371 грамматика, но tags.scm есть только у 71 (19%); 300 языков — AST-парсинг без символов | 2026-08-05 | audit.md п.1 |
| pylint-django как детектор дупликации | Это плагин для Django-фреймворка (типы ForeignKey/Model), а не dup-detector — официальное описание PyPI 2.8.0 (2026-07-11) | 2026-08-08 | audit.md L197 |

---

## [2026-08-08] — Exp: `PropertyGraph.shortest_path` — корректность + латентность (H-PATH)
**Гипотеза:** BFS (graph.py:937) работает на живом графе, медиана <50ms; gap = только отсутствие MCP `graph_query(action="path")`.
**Команда:** `venv/Scripts/python.exe experiments/exp_graph_path.py` (скрипт в experiments/, read-only через API PropertyGraph).
**Сырой результат:**
```
graph: 7247 nodes, 21404 edges
[tool->PropertyGraph (CALLS)] shortest_path('_execute_cypher' -> 'PropertyGraph'): 2 hops
   ...GraphQueryTool._execute_cypher  -[->
   ...graph.py.PropertyGraph  -[CALLS]->
latency_ms: [0.3, 0.14, 0.12, 0.11, 0.09, 0.09, 0.09]  median_ms: 0.11
```
**Вердикт:** подтверждена — 0.11ms медиана (гипотеза <50ms выполнена ×450). Реальный путь найден, структура корректна (source→CALLS→target).
**Урок:** `shortest_path` траverses ТОЛЬКО outgoing-рёбра (`graph.py:974` `WHERE source_id = ?`) — классы/методы без исходящих рёбер недостижимы. MCP-обёртке `action="path"` нужен опциональный `direction="both"` (BFS уже параметризуем). Также: qname-формат `D:.<repos-root>/...` — клиенту нужен подсказчик имён (как `find_nodes(name_pattern=...)`).

---

## [2026-08-08] — Exp: Jupyter `.ipynb` = JSON, интеграция без новых зависимостей (H-JUPYTER)
**Гипотеза:** .ipynb разбирается stdlib json (nbformat опционален), code cells подаются в существующий tree-sitter пайплайн CodeParser. Интеграция = extensions.py + ветка в parse_file.
**Команда:** `venv/Scripts/python.exe experiments/exp_jupyter.py`
**Сырой результат:**
```
json.loads 200x: median_ms = 0.0055
cells=5 code_cells=3
  cell 0: 69 chars / 5 lines ...
CodeParser.parsers keys: ['.go', '.js', '.py', '.rs', '.ts', '.tsx']
  cell 0 -> parse_file: 1 chunks, 0 syms, 15.08ms
  cell 1 -> parse_file: 1 chunks, 1 syms, 13.35ms
  cell 2 -> parse_file: 1 chunks, 0 syms, 13.48ms
TOTAL chunks из 3 code cells: 3
```
**Вердикт:** подтверждена — парсинг ~0.006ms, извлечение корректно, существующий пайплайн работает на cell-as-.py (13-15ms/cell). nbformat 5.11.0 существует (PyPI, 2026-08-06), но не нужен.
**Урок:** накладные расходы на ноутбук ~N×13ms (N = code cells) — приемлемо. Замечание: standalone `CodeParser()` загрузил только 6 грамматик (полный набор идёт через другой путь инициализации — язык-пак/окружение) — для .ipynb достаточно python-грамматики + metadata.language_info.name.

---

## [2026-08-08] — Exp: детекция дупликации AST-нормализованными отпечатками (H-DUP)
**Гипотеза:** для 54 языков AST-нормализация (tree-sitter уже есть) + minhash ближних дублей реализуемо stdlib+numpy, без suffix-array движка. fallow: suffix-array покрывает только JS/TS+CSS. pylint-django — НЕ dup-detector.
**Команда:** `venv/Scripts/python.exe experiments/exp_dup.py` (скрипт в experiments/, ~60 строк: tree-sitter листовые токены с плейсхолдерами <id>/<lit>, sha1-группировка точных, minhash-64 8-грамм для ближних).
**Сырой результат:**
```
files=137 functions/classes>=24tokens=401 scan_ms=414.8
EXACT дубликаты: 8 групп
  artifact_paths.py: get_index_dir/get_intelligence_dir/get_metrics_dir/get_commit_memory_dir/get_branches_dir/get_telemetry_dir/get_summaries_cache_dir (7 шт)
  extensions.py: is_supported ~ is_parseable
  resource_monitor.get_global_resource_monitor ~ llama_runner.get_global_runner
  language_pack.lang_for_ext ~ get_parser
  lsp_project_bridge._bridge_path ~ _stale_path
  cypher_ast._UnaryOp ~ _LabelTest
  graph_tools._confirmed ~ _contradicted
  lsp_tools.LspFindReferencesTool ~ LspFindDefinitionTool
NEAR-дубли (minhash>0.85): 1 пара, 0.969 — lsp_tools.LspFindReferencesTool ~ LspFindDefinitionTool; pair_scan_ms=660.8
```
**Вердикт:** подтверждена — 137 файлов за 414.8ms, найдены РЕАЛЬНЫЕ дубли (7 функций get_*_dir — классический copy-paste; LSP-классы-близнецы 0.969). Ноль новых зависимостей (tree_sitter + hashlib уже есть; simhash 2.1.2 существует, но не нужен). pylint-django опровергнут (см. 🚫 таблицу).
**Урок:** порог ≥24 токена и k=8-граммы дают 0 false-positive на этом репо. Для MCP-тула `find_duplicates(threshold)` — готовая схема: index-time (опционально) или on-demand скан ~415ms. Кандидаты: 7×get_*_dir стоит реально отрефакторить в 1 функцию.

---

## [2026-08-08] — Верификация кода (без замеров): H-EDGE / H-LSP / H-TASK
**H-EDGE (edge transparency) — подтверждена:** `Edge.properties` — реальная колонка (graph.py:410), `add_edge` принимает properties и upsert обновляет их (graph.py:736,778), `to_dict` отдаёт (graph.py:329). Теги EXTRACTED/INFERRED = метаданные, **без миграции схемы**. Реальная стоимость: пометить вызовы add_edge/batch_add_edges при создании рёбер + пасс-through в tools (уже через to_dict). Оценка аудита «2-3 недели» завышена на порядок (3-5 дней, а то и меньше).
**H-LSP (type resolution) — закрыт другим путём:** с 2026-08-06 в проекте есть 6 LSP-тулов через basedpyright (src/core/lsp_client.py, src/mcp/tools/lsp_tools.py): lsp_find_references/definition/document_symbols/get_type_info/get_diagnostics/get_code_actions. Живая проверка: `lsp_get_type_info(graph.py:730)` вернул `(parameter) self: Self@PropertyGraph`. USES_TYPE edge объявлен (graph.py:234), но не заполняется — index-time type resolution НЕ нужен: query-time LSP покрывает боль точнее (тот же паттерн, что fallow `--type-aware` — семантика на уровне запроса, не индекса).
**H-TASK (task-shaped) — частично есть:** `intel_get_project_context` — один вызов = снапшот state+index+health+memory+background (server_tools.py: инлайн-регистрация); `graph_query(action="related")` — контекст по нескольким целям через CommitMemory+RelationExtractor. Нет только символьного `get_context(targets=[...])` — это тонкая обёртка. **H-PATH примечание:** class-узлы имеют 0 исходящих рёбер (CodeParser out=0) — DEFINES-связи неполны на уровне class→method; открытая нить для ревью indexer.edge-записи.

---

## [2026-08-08] — Exp: WS3 Late Enrichment — стоимость стадии на реальных чанках

**Гипотеза (Late Code Chunking, ACL 2026):** enrichment ПОСЛЕ retrieval дёшев (<2ms на топ-10) и покрывает ≥2 полей на чанк; imports из metadata чанка доступны.
**Команда:** `python experiments/late_enrichment/bench.py --phase chunks --limit 10` — 8 запросов × 10 реальных чанков проекта, фаза chunks (live недоступна: MCP держит PID-lock).
**Сырой результат:**
```
avg_enrichment_ms: 0.701
avg_tokens_added: 1860.0   (≈186 ток/чанк на топ-10)
avg_coverage: module=1.0, parent_symbol=0.3, chunk_headline=1.0, imports=0.0
```
**Вердикт:** ЧАСТИЧНО ПОДТВЕРЖДЕНА. Латентность пренебрежима (0.7ms), module/headline покрывают 100%. **imports=0.0** — метаданные чанков НЕ содержат импортов (графовые IMPORTS-рёбра есть, но не прикреплены к чанкам) → enrichment импортов требует graph-lookup (и зависимость от consistency — будущая работа). parent_symbol=0.3 — извлечение имени из текста находит не каждый чанк.
**Урок:** chunk-local enrichment (module/headline/symbol) безопасен и дёшев; imports — отдельная стадия с графом. Токен-стоимость ~186/чанк обязана быть в метрике контекста (Context Engine 2.0).

## [2026-08-08] — Exp: Benchmark 2.0 runner — live-фаза vs PID-lock

**Гипотеза:** runner может поднять in-process Searcher при живом MCP (индекс доступен).
**Команда:** `python experiments/benchmark2/runner.py` (MCP запущен, PID 7496).
**Сырой результат:**
```
RuntimeError: PID lock still held by alive pid=7496 after 30.0s — другой процесс пишет в эту БД
[bench2] записано 12 задач -> out/evidence.jsonl
[bench2] manual-проб (нужен ручной прогон): 16
```
**Вердикт:** ОПРОВЕРГНУТА. PID-lock (database_lock.py, 30s, fail-closed) блокирует второй Indexer на ту же БД — это защита, работает как задумано. Runner корректно фолбэчит в manual-режим (16 ручных проб).
**Урок:** live-эвалы против MCP требуют остановленного сервера или отдельного MSCODEBASE_DATA_DIR; документировано в experiments/benchmark2/README.md.

---

## [2026-08-08] — Exp: Multi-window PID-lock 30s wait vs Zed timeout (KNOWN_ISSUES 🟡, WS8 follow-up)

**Гипотеза:** (1) Zed убивает MCP-процесс по таймауту запроса → вечный зомби-цикл; (2) зомби-holder'а (осиротевший живой процесс) можно отличить от здорового MCP по цепочке родителей; (3) create_time-сверка ловит PID-reuse.

**Команда:** см. ниже per-эксперимент; скрипты — `experiments/lock_zombie/` (orphan_holder.py / spawn_orphan.py / zombie_probe.py / check_signals.py).

**Сырой результат (Exp A — реальное состояние lock-файлов, PowerShell):**
```
LOCK: ...index_bot_snow_5e94fc96.db\.write_lock  pid=8148 started=1786135695 age=13,1h
  holder: DEAD (stale -> steal works)
LOCK: ...index_mscodebase_bfe9644b.db\.write_lock  pid=13376 started=1786168629 age=3,95h
  holder: name=python.exe parent_pid=17860 (venvlauncher chain) -> Zed.exe alive -> healthy
```
**Сырой результат (Exp B — контеншн, реальный второй процесс):**
```
RuntimeError: PID lock still held by alive pid=13376 after 30.0s — другой процесс пишет в эту БД
indexer creation (stale-steal path): 1.04s   (свободный/steal lock)
get_status: 0.02s
```
**Сырой результат (Exp C — walk-to-root детекция, zombie_probe.py):**
```
=== HEALTHY (наш MCP 13376) ===
[0] pid=13376 python.exe alive
[1] pid=17860 python.exe alive   (venvlauncher)
[2] pid=11668 powershell.exe alive
[3] pid=18216 Zed.exe alive
VERDICT: HEALTHY (живой Zed в цепочке) -> WAIT
=== ORPHAN (симуляция, holder 22508) ===
[0] pid=22508 python.exe alive
[1] pid=23776 python.exe alive
[2] pid=10740 DEAD
direct_parent_alive=True   <- ловушка: наивная проверка дала бы false-WAIT
live_Zed_in_chain=False; chain_root_dead=True
VERDICT: ORPHAN/ZOMBIE -> STEAL safe
zombie_probe full run: 88 ms
```
**Сырой результат (Exp D — PID-reuse):**
```
Фейковый lock: pid=наш(живой), started=now-3600, role=worker
PID lock held by alive pid=12684, waiting...
FAILED after 1024 ms: PID lock still held ... after 1.0s   <- текущий код НЕ ловит
zombie_probe: holder pid=12684 alive=False -> STALE  (после выхода скрипта)
```
**Вердикт:** (1) ПОДТВЕРЖДЕНА-с-уточнением — из исходников Zed (client.rs): `DEFAULT_REQUEST_TIMEOUT=60s` на каждый JSON-RPC запрос; процесс НЕ убивается при таймауте (Drop→kill только при остановке сервера, stdio_transport.rs). Вечный цикл = осиротевший живой python.exe (venvlauncher double-process) держит lock. (2) ПОДТВЕРЖДЕНА: walk-to-root (≤8 уровней, ~88ms) различает HEALTHY (Zed alive→wait) / ORPHAN (корень мёртв→steal); direct-parent-проверка даёт ложный WAIT (ловится). (3) ПОДТВЕРЖДЕНА: create_time-дельта ловит фейковый started (3600s), текущий `_is_pid_alive` — нет.

**Урок:** 30s-ожидание + fail-closed — защита «один писатель», но без детекции сирот она превращает осиротевший процесс в вечный цикл падений (инцидент WS8 08:52-08:57 — это ручной taskkill решал). Индустрия: PostgreSQL postmaster.pid хранит start timestamp именно для stale-детекции; Zed даёт 60s/запрос, поэтому 30s wait формально «в бюджет влезает», но UX = 30s-блокировка + ошибка. Находка: psutil импортируется в layer.py/lsp_project_bridge.py, но НЕ объявлен в pyproject и НЕ установлен в venv — тихая деградация runtime.

---

## [2026-08-08] — Exp: WS9 benchmark before/after (self-healing PID-lock, вариант C)

**Гипотеза:** после внедрения классификации holder'а (DEAD/HEALTHY/ORPHAN/AMBIGUOUS) время acquire для orphan-кейса падает с ~30s (ожидание+RuntimeError) до сотен мс (terminate+steal), healthy-кейс — мягкая ошибка через ~8s (дефолт) вместо 30s RuntimeError; free/stale не деградируют.

**Команда:** `python experiments/lock_zombie/benchmark_selfhealing.py` (venv расширения, Windows).

**Сырой результат (after):**
```
[free (no contention)] 7 ms | acquire ok
[stale-holder (dead pid)] 31 ms | steal ok
[healthy-holder (wait=1.5s)] 1512 ms | LockBusyError: PID lock still held by alive pid=... after 1.5s — база занята другим окном MCP; retry позже (holder не тронут)
[orphan-holder (terminate+steal)] 120 ms | acquired pid=...
```
**Before (та же сессия, старый код):** контеншн = 30.0s → RuntimeError (замерено в Exp B); orphan-кейс не детектился (30s → RuntimeError); free ~9ms; stale ~33ms.

**Вердикт (2026-08-08):** ПОДТВЕРЖДЕНА. **Статус публикации (2026-10-03):** `SUPERSEDED` — измерено на `3798d6a9`, а путь достижимости удалён по дизайну: ORPHAN-ветка вырезана из прод-MCP по R3TF (`7974d981`, `src/core/indexing/database_lock.py:81-84`). Сегодняшней командой не воспроизводится (`experiments/claims_audit/RESULTS.md` A10 = NOT REPRODUCED), поэтому число остаётся записью прогона, а не текущим фактом. Не переписывать.
orphan: 30000ms → 120ms (terminate+steal, вкл. TerminateProcess реального python + ретрай-unlink); healthy: 30000ms RuntimeError → 1512ms LockBusyError (wait=1.5 в бенче; прод-дефолт 8.0s); free/stale без изменений (7/31ms). Дополнительно verified: после TerminateProcess реального python'а venvlauncher-обёртка умирает сама (никаких висящих процессов), lock перезаписывается нашим PID.
**Урок:** (1) TerminateProcess синхронный, но файловый дескриптор lock'а умирающего процесса даёт PermissionError на unlink → нужен _unlink_with_retry (иначе краш в кейсе «только что убитый holder»); (2) venvlauncher: lock пишет РЕАЛЬНЫЙ python (os.getpid() внутри скрипта), terminate по pid из lock убивает именно держателя, обёртка умирает следом — прод-механизм работоспособен.

---

## [2026-08-08] — Exp: Multi-Tool (MSCodeBase, 4-5 вызовов) vs Context Engine (CodeGraph-стиль, 1 вызов)

**Гипотеза:** единый контекстный агрегатор (get_edit_context-стиль) побеждает последовательные MCP-вызовы по tool_calls (N→1), latency (1 RT vs N), tokens (при intent-фильтре), при паритете task success; wrong-context решается intent-фильтрацией. Контрольная группа: ОДНА кодовая база (MSCodeBase), 4 задачи на реальных символах, отличаются только стратегии оркестрации. CodeGraph (Rust) не устанавливался — иначе сравнение смешало бы «качество индекса» с «архитектурой инструментов».

**Команда:** `python experiments/context_engine/compose_eval.py` (данные: strategy_a_data.json — реальные ответы MCP 2026-08-08, тайминги из intel_execution_timeline; B-v2 = compose source+symbols(+memory+git по intent), symbols во всех intent).

**Сырой результат:**
```
task        strat   calls tokens   latency_ms facts                 success  wrong%
T1-explain  A       5     423      2481       ...                  86%      15%
T1-explain  B       1     266      501        ...                  71%       0%
T2-modify   A       5     460      6755       ...                 100%      15%
T2-modify   B       1     389      502        ...                 100%      16%
T3-debug    A       4     435      2118       ...                 100%       9%
T3-debug    B       1     350      501        ...                 100%       0%
T4-test     A       4     300      6358       ...                  67%      23%
T4-test     B       1     300      501        ...                  67%      36%   <- B-v1 (test без symbols): 33%/59%
AVG calls    A=4.500  B=1.000   Δ=-78%
AVG latency  A=4428   B=501     Δ=-89%
AVG tokens   A=404.5  B=326.4   Δ=-19%
AVG success  A=88.1%  B=84.5%   Δ=-3.6pp (разрыв = артефакт рубрики T1: "enrich" только в git-сообщении)
AVG wrong    A=15.5%  B=13.0%   Δ=-2.5pp (B лучше: dedup убрал шум упавших вызовов)
```

**Вердикт:** ПОДТВЕРЖДЕНА (все 5 пунктов гипотезы, с оговорками):
- tool_calls: N=4.5 → 1 (−78%), latency agent-facing: 4428ms → 501ms (−89%) — выигрыш по построению, подтверждён замером.
- tokens: с intent-фильтром B меньше даже без учёта round-trip промпта (−19%); «сырой» агрегатор (все секции) ≥ суммы вызовов.
- task success: паритет (84.5% vs 88.1%); B-v1 (test БЕЗ symbols) падал до 33% — intent-фильтр обязан ВСЕГДА включать source+symbols (callers), как у реального CodeGraph get_edit_context.
- wrong-context: B-v2 13.0% < A 15.5% — dedup+отсутствие упавших вызовов чище; глобальная память проекта (55 ADR) ≈ 0 реколл для задачи «тест» → CodeGraph memory_context ФАЙЛ-скоуп, у нас — проектный (находка).

**Побочные наблюдения (реальные данные сессии):**
1. impact_analysis вернул «not found» для 2/4 символов (_expand_graph_context, intel_code_topology — приватные/не в индексе) → 2 мёртвых вызова в A (соль в wrong 15-23%).
2. get_symbol_info для build_call_graph вернул НЕВЕРНОЕ определение (experiments/misc_probes/run_experiment_pagerank.py:40 вместо src/core/indexing/symbol_index.py:480) — символ-тень эксперимента скрывает реальный; multi-tool требует доп. поиска (wrong-definition кейс).
3. CodeGraph README: 42 community tools (не 45 — расхождение в их же README), --profile=core (8 tools) для сужения поверхности — паттерн «tool surface inflates prompt cost» признают и они.

**Урок:** (1) архитектура «1 контекстный инструмент с серверной композицией» валидна и для MSCodeBase: −78% вызовов, −89% latency, −19% токенов при паритете полноты; (2) критично: compose ОБЯЗАН включать source+symbols во все intent; (3) файл-скоуп памяти (а не глобальный ADR-список) — условие полезности memory-секции в edit-контексте; (4) impact_analysis «not found» на приватных функциях = тихий провал multi-tool стратегии.

---

## [2026-08-08] — Exp D (v2): Context Composition vs Tool Composition — Where Does the Latency Actually Come From?

**Гипотеза (v2):** (1) выигрыш агрегатора — в round-trips и agent-facing latency, НЕ в серверной работе (compose ≈ тем же операциям + overhead); (2) полнота (recall) C ≥ A при правильном составе секций; (3) wrong-evidence (дефекты impact_analysis/build_call_graph) одинаково бьют по всем рукам; (4) при подтверждении — вариант А реализуем в прод.

**Команда:** `MSCODEBASE_ALLOW_SELF_INDEX=1 venv/Scripts/python.exe experiments/context_engine/bench_v2.py`
15 задач × 9 классов (find_bug_cause/modify/impact/architecture/test/git/caller-callee/prepare/verify), ground-truth required-facts, 4 руки: A (реальные MCP-вызовы, latency из intel_execution_timeline) / B (compose-модель, intent-фильтр) / C1 (СУЩЕСТВУЮЩИЙ get_context — GetContextTool, реальный in-process на snapshot БД) / C2 (РЕАЛЬНЫЙ get_edit_context: EditContextEngine — GetSymbolInfoTool+ImpactAnalysisTool+SearchCodeTool fallback+source+git+memory, in-process). PID-lock живого MCP обходится snapshot-копией артефакт-БД (та же реальная БД, temp, .write_lock удалён). Readiness-гейт — патч как в тестах проекта.

**Сырой результат (AVG, 15 задач):**
```
              round_trips  tokens  agent_ms  server_ms  recall  prec  wrong  dup
A (multi-tool)    3.400    241.3   1582.6    1582.6     0.783  0.667 0.090  0.135
B (compose model) 1.000    276.5    400.0*       0.0     0.833  0.663 0.098  0.164
C1 (get_context)  1.000    637.1    449.2       49.2     0.267  0.600 0.133  0.000
C2 (get_edit_context)     1.000   1230.6    865.3      465.3     0.817  0.705 0.108  0.184
* B agent_ms — модель 1 RT (400ms, реальный медианный).
```

**Вердикт:** ПОДТВЕРЖДЕНА (все 4 пункта):
1. **Latency-декомпозиция:** agent-facing: A=1583ms (3.4 RT, Σ реальных server-латентностей, включая 5.3s search_code на T5) vs C2=865ms (1 RT + 465ms реальной серверной работы: symbol-index + fast-search fallback + git + чтение файла). Выигрыш = round-trips (N→1) + дешёвые точечные запросы вместо семантического поиска. C2 server_ms < A server_ms даже в лобовом сравнении.
2. **Полнота:** C2 recall=0.817 > A=0.783, precision=0.705 > 0.667 (fallback search_code при пустом gsi закрыл inline-tools: intel_trigger_reindex, notify_change). C1 recall=0.267 — СУЩЕСТВУЮЩИЙ get_context недостаточен (только symbol_info+impact, нет source/git/memory/fallback).
3. **Wrong-evidence:** дефект «get_symbol_info для build_call_graph возвращает тень experiments/misc_probes/run_experiment_pagerank.py:40» штрафует ВСЕ руки (A wrong=0.09, C2=0.108; T7 wrong=1.0 у всех, секция целиком отравлена). Реальный фикс — не «починить get_symbol_info», а guard в агрегаторе: отбрасывать определения из experiments/ (scaffolding) или сверять файл определения.
4. **Токены — точка напряжения:** C2 без token budgeting = 1231 vs A=241 (source-окно 80 строк + fallback). B (intent-фильтр, CodeGraph-стиль) = 276 токенов при recall 0.833 — лучший recall при минимуме токенов среди 1-RT рук. Вывод: агрегатор обязан иметь токен-бюджет (intent + обрезка секций), иначе побеждает по round-trips/latency, но проигрывает по токенам.

**Итерации методологии (§1.8):** v2.0 wrong_rate не ловил wrong-секции с корректными фактами → штрафуется всегда (ложная уверенность опаснее отсутствия); v2.1 source-окно цепляло docstring/call-site (walk-up от декоратора попадал в чужую def) → Pass A (def с именем) + Pass B (walk-DOWN); v2.2 fallback search_code при пустом gsi (символ вне графа).

**Урок:** (1) «1 контекстный инструмент» побеждает по round-trips/latency и паритету-превышению полноты ТОЛЬКО при составе: source+symbols+fallback+git+memory и токен-бюджете; (2) существующий get_context (C1) — урезанный агрегатор: recall 0.267 против 0.817 у полного — его расширение (не новый tool с нуля) — путь к варианту А; (3) wrong-context guard в агрегаторе (отсев определений из experiments/) дешевле и надёжнее фикса самого get_symbol_info; (4) PID-lock + snapshot-копия БД — рабочий паттерн изоляции экспериментов от живого MCP (никаких taskkill).

---

## [2026-08-08] — Exp D v3: 30 задач — устойчивость B vs C2 (токены решают, recall паритет)

**Гипотеза (v3, по решению владельца):** разница B vs C2 на 15 задачах может быть шумом (доверительный интервал перекрывает). Нужен прогон на 30 задачах: если recall паритетен, а токены у B стабильно ниже — решаем в пользу B-подхода (intent-фильтр), не полного C2.

**Команда:** `MSCODEBASE_ALLOW_SELF_INDEX=1 venv/Scripts/python.exe experiments/context_engine/bench_v2.py tasks_v3.json` (30 задач: 15 из v2 + 15 новых; 4 новых символа с реальными MCP-вызовами: trigger_async_reindex, get_active_reindex_job_id, RuntimeCoordinator, _reject_self_index_target; paired-статистика добавлена в bench_v2.py).

**Сырой результат (AVG, N=30):**
```
              round_trips  tokens  agent_ms  server_ms  recall  prec  wrong  dup
A (multi-tool)    3.367    246.0   1558.7    1558.7     0.875  0.748 0.045  0.197
B (compose-model) 1.000    274.9    400.0*       0.0     0.900  0.748 0.049  0.209
C1 (get_context)  1.000    581.8    428.7       28.7     0.288  0.700 0.067  0.000
C2 (get_edit_context)     1.000   1254.6    805.3      405.3     0.875  0.784 0.054  0.315
* B agent_ms — модель 1 RT (400ms).

=== PAIRED B vs C2 (N=30) ===
recall     mean_delta(B-C2)=+0.025  sd=0.152  CI95=±0.054  B>recall: 2/30  C2>recall: 1/30
precision  mean_delta(B-C2)=-0.036  sd=0.132  CI95=±0.047  B>precision: 5/30  C2>precision: 17/30
tokens     mean_delta(B-C2)=-979.8  sd=695.9  CI95=±249.0  B>tokens: 0/30  C2>tokens: 30/30
```

**Вердикт:** ГИПОТЕЗА v2-владельца ПОДТВЕРЖДЕНА — recall у B и C2 статистически НЕРАЗЛИЧИМ (mean Δ=+0.025, CI95 ±0.054 перекрывает 0; ничьи в 27/30 задач), precision C2 направленно выше, но не значимо (CI включает 0), токены у B стабильно ниже на ~980 (CI95 ±249 — далеко от 0; B дешевле в 30/30 задач). Итог по 30 задачам: **B-подход (intent-фильтр) = оптимальная точка** — recall 0.900 ≥ A 0.875 при 1 RT (vs 3.37) и 275 токенов (≈ A). C1 (существующий get_context) по-прежнему recall 0.288 — требует расширения. C2 не нужен целиком: его выигрыш по precision (+0.036) не окупает +980 токенов.

**Урок:** (1) на выборке 15 задач разница 0.833 vs 0.817 — шум: подтверждено CI на 30 (0.025 ± 0.054); решения об архитектуре контекста принимать на ≥30 задач с paired-анализом; (2) решает не «сколько секций собрать», а «какие секции включить по intent» — B (source+symbols по intent, без impact для git-задач и т.п.) даёт максимум полноты при минимуме токенов; (3) dup_rate C2=0.315 — fallback search_code дублирует symbol-инфо: в прод-агрегаторе нужен dedup. Дефекты D1-D3 зафиксированы в KNOWN_ISSUES (🟡), фикс после повторного прогона.

---

## [2026-08-08] — Контрольный прогон v3 после фикса D1-D3 (wrong_rate 0, C1 recall +32%)

**Гипотеза:** фикс корня D1-D3 (неранжированный nodes[0] → _find_nodes_flexible union + _pick_best_node + union-старты + _is_one_off_script) убирает отравление контекста тенями experiments//scripts/ и placeholder'ами и поднимает качество живых рук C1/C2; A/B (записанные до-фиксовые данные) — контроль «до».

**Команда:** `MSCODEBASE_ALLOW_SELF_INDEX=1 venv/Scripts/python.exe experiments/context_engine/bench_v2.py tasks_v3.json` (после фикса; C1/C2 — живой in-process код с фиксом).

**Сырой результат (AVG, N=30, до → после фикса):**
```
                recall          precision       wrong_rate       tokens
C1 (get_context) 0.288 → 0.380   0.700 → 0.800   0.067 → 0.000   582 → 975
C2 (get_edit_context) 0.875→0.883 0.784 → 0.819  0.054 → 0.000   1255 → 1427
A/B — без изменений (записанные pre-fix данные)
Paired B vs C2: recall Δ=+0.017 (CI95 ±0.052, неразличимы), precision C2 19/30,
tokens B −1152 (CI95 ±315, 30/30) — вывод B-оптимальности НЕ изменился.
```

**Вердикт:** ПОДТВЕРЖДЕНА. wrong_rate 0.000 у C1/C2 (тень build_call_graph больше не отравляет секции; T7 wrong 0.993→0.0), C1 recall +0.092 (D2: методы резолвятся), precision вырос. Реальная проверка: build_call_graph → def=src/core/indexing/symbol_index.py:481 (было experiments/misc_probes/run_experiment_pagerank.py:40), callers=9 реальных прод-потребителей (без скриптового main). Полный pytest 1021 passed, ruff src/ tests/ = 0.

**Урок:** (1) корень D1-D3 ОДИН — неранжированный выбор узла при наличии одноимённых (тень/placeholder/реальный); (2) CALLS-рёбра при индексации привязываются к первому exact-матчу — реальные callers могут лежать на тени: исключать тень из стартов НЕЛЬЗЯ (теряются callers), фильтровать нужно на уровне записей по файлу вызывающего; (3) wrong-evidence guard «отсев experiments/» на композиции (вариант из v2) оказался НЕ нужен — правильный фикс в адаптере дешевле и чище.

## [2026-08-11] — Exp: Multi-RAG Component Ablation (Experiment 1, N=30, v2)

**Гипотеза:** Multi-RAG (Vector+BM25+FTS5+Graph+rerank) > Single-RAG по evidence-recall на задачах о кодовой базе (статья «AI-Native Second Brain»); каждый компонент даёт инкрементальный вклад; graph силён на задачах связей; BM25 и FTS5 избыточны.
**Ожидание:** full/quality recall > fts5_only; BM25, FTS5, Graph дают положительные парные Δ; graph_only recall максимален на klass ∈ {find_caller_callee, find_impact}; FTS5 ≈ BM25 (избыточность).
**Команда:** `venv/Scripts/python.exe experiments/context_engine/multi_rag_ablation.py tasks_v3.json` — 30 задач × 12 рук; изоляция компонентов monkey-patch'ем методов Searcher (`_bm25_search_async`/`_vector_search_async`/`_fts5_search_async`/`_expand_graph_context`/`_apply_multi_reranker_async`); `expand=False`; кэш эмбеддингов очищается per-arm (см. «Урок 1»). Дизайн: experiments/context_engine/multi_rag_design.md. Лог: experiments/context_engine/multi_rag_full_run_2026-08-11.log.
**Сырой результат (AVG по 30 задач):**
```
recall      vector=0.167 bm25=0.694 fts5=0.825 graph=0.357 vbm25=0.597 vfts5=0.783
            bm25fts5=0.817 vbm25fts5=0.775 full_norerank=0.775 quality=0.756
precision   vector=0.083 bm25=0.791 fts5=0.523 graph=0.441 quality=0.719
tokens      vector=1360 bm25=1774 fts5=2327 graph=122 quality=1862
latency_ms  vector=122 bm25=298 fts5=110 graph=12 quality=1704

PAIRED (Δ, CI95, wins/30):
BM25 over Vector:   recall +0.430 ±0.164 (21/30) | prec +0.531 (26/30) → SIGNIFICANT
Vector over BM25:   recall −0.098 ±0.086 (1/30)  | prec −0.177 (1/30)  → вредит
FTS5 over V+BM25:   recall +0.178 ±0.097 (13/30) | tokens +375 (29/30) → значим recall
Graph over V+BM25:  recall +0.000 (enrichment = metadata, не текст) → ~0
Rerank over full:   recall −0.019 (3/30) | prec +0.147 ±0.061 (22/30) | tokens −301 → значим precision
BM25 vs FTS5:       recall Δ −0.131 (FTS5 12/30) | prec +0.268 (BM25 24/30) | tokens −553 (BM25 26/30)

graph_only recall by klass: find_caller_callee 0.625, find_impact 0.583, modify_function 0.500,
understand_architecture 0.500, verify_change 0.500, find_bug_cause 0.300, prepare_change 0.237,
find_test 0.125, git_history 0.000
```
**Вердикт:**
- **H1 (Multi-RAG > Single по recall): ❌ ОПРОВЕРГНУТА** — fts5_only 0.825 ≥ full_no_rerank 0.775 / quality 0.756 (13 задач, где FTS5-одиночка лучше, против 5 у full). Multi-RAG подтверждён только по precision (quality 0.719 vs fts5 0.523, wrong_rate 0.033→0.050 — реранкер добавляет точность ценой минимального recall).
- **H2 (инкрементальные вклады): ⚠️ ЧАСТИЧНО** — BM25 над vector +0.430 ✓; FTS5 над V+BM25 +0.178 ✓; graph-enrichment 0.000 ✗ (добавляет metadata callers/callees, которую evidence-метрики не видят); vector над BM25 −0.098 ✗ (разбавляет чистые BM25-хиты через RRF).
- **H3 (graph на задачах связей): ✅ ПОДТВЕРЖДЕНА** — graph_only recall максимален на find_caller_callee (0.625) и find_impact (0.583), минимален на git_history (0.000); при 12ms и 121 токене (дешевле всех в 5-10 раз).
- **H4 (токены монотонны): ⚠️ ЧАСТИЧНО** — не монотонно: graph добавляет ~0 токенов, реранкер режет −301.
- **H5 (BM25≈FTS5 избыточны): ❌ ОПРОВЕРГНУТА** — FTS5 даёт +0.178 recall над V+BM25 (CI95 ∌ 0); профили противоположны: FTS5 = recall-max (0.825), BM25 = precision/токен-эффективность (0.791 / 1774).
**Урок:** (1) production-баг `hybrid_search_async` (engine.py L521-541): на кэш-хите эмбеддинга dense-поиск пропускается — vector-тир молча исчезает при повторных запросах; первый прогон абляции полностью искажён (vector_bm25 == bm25_only 30/30, vector_only пуст на повторных символах 15/30). Изоляция кэша per-arm обязательна для абляций. (2) vector-тир (llama.cpp multilingual-e5-small) — слабейший на символьных задачах (0.167 recall); recall несут keyword-тиры, precision покупается реранкером. (3) graph-ценность живёт в метаданных (callers/callees), не в тексте чанков — evidence-метрики по паттернам текста её не измеряют; нужен отдельный протокол оценки graph-вклада (или чтение metadata в секции).
**Связь с отрицательными:** первый прогон (без изоляции кэша) — артефакт кэш-бага, не повторять без фикса (результаты в multi_rag_full_run_2026-08-11.log содержат оба прогона; валиден второй).

## [2026-08-11] — EXP-6: VC/Merkle vs Verify-On-Read — симуляция логической границы (dev.to, unitbuilds)

**Гипотеза:** (а) консистентностный валидатор (хэш структуры + отсутствие конфликтов записи) принимает внутренне-консистентную семантическую ложь; (б) «эмпирическое доказательство превосходства Verify-On-Read» можно публиковать как железобетонное пруф.
**Ожидание:** вывод скрипта — «VC принял 2 лжи, VOR — 0».
**Команда:** `python experiments/concurrency/experiment_concurrency_vs_semantic.py`
**Сырой результат:**
```
Arm VC (Live VC + Merkle): Accepted 2 hallucinated lies as truth.
Arm Verify-On-Read: Accepted 0 hallucinated lies as truth.
```
**Вердикт:** гипотеза (а) ✅ ПОДТВЕРЖДЕНА — но только ЛОГИЧЕСКИ, по построению (тавтология, не замер): Arm VC по определению не получает семантических данных, Arm VOR получает ground-truth список импортов прямо в аргументы. Гипотеза (б) ❌ ОПРОВЕРГНУТА как фрейминг: «эксперимент» не фальсифицируем — результат зашит в определения валидаторов. Уязвимости для оппонента: (1) confound — разные входные права у рук; (2) ground truth захардкожен экспериментатором (самая сложная часть задачи решена заранее — если бы список правды существовал, валидатор не нужен); (3) VOR показан всемогущим — не моделируются слепые зоны (ложь про реальный импорт, утверждения без кодового якоря, runtime/конфиг/внешние сервисы); (4) strawman-риск — оппонент может сказать «мой стек тоже проверяет AST».
**Урок:** сильный вывод здесь НЕ требует симуляции: «консистентность (VC/Merkle) ≠ семантика; нужен внешний слой grounding (AST/runtime/мир)». Симуляция — хорошая иллюстрация, плохое доказательство. Публиковать с честными оговорками (см. §1.6: гипотеза без фальсифицируемости = иллюстрация, не эксперимент).

## [2026-08-11] — EXP-7: Adversarial probe базового VC/VOR-эксперимента (6 атак, Red Team §1.16)

**Гипотеза:** базовый вывод «VC=2 лжи, VOR=0» — не закон, а артефакт входных прав и настройки сценария; VOR на anchor-гранулярности имеет собственные FP; VC имеет уникальное покрытие (конфликты, staleness), которого у VOR нет; VC и VOR — комплементарные слои.
**Команда:** `python experiments/concurrency/experiment_concurrency_vs_semantic_attacks.py`
**Сырой результат (метрики per-attack):**
```
A1a baseline VC:             FP=2 FN=0  (VC без семантических входных данных)
A1b hybrid VC+semantics:     FP=0 FN=0  (равные права: семантика доступна обеим рукам)
A2 VOR, ложь про реальный импорт: FP=1  (duckdb «for analytics», реально CSV-парсер)
A3 VOR без кодового якоря:  UNCHECKABLE — любая политика даёт FP или FN
A4a VC, косметическое изменение: FN=1  (page-level хэш слишком груб)
A4b VC под конфликтом записи: REJECTED (ловит lost write); VOR к нему слеп
A5 VOR на отравленном truth-листе: FP=1 (stripe из README-примера, не код)
A6 мутация сценария (writers=1): FP=0 FN=1 — «VC принимает ложь» переворачивается
```
**Вердикт:** ✅ ПОДТВЕРЖДЕНА. Базовый результат — артефакт: при равных входных правах гибрид даёт 0 лжи (A1); при мутации VC начинает отвергать правду (A6). VOR не всемогущ: anchor-гранулярность пропускает ложь про реальный импорт (A2), не покрывает утверждения без якоря (A3), деградирует на отравленном truth-списке (A5). VC даёт уникальное покрытие (lost write, конфликт, A4b), но page-level хэш слишком груб (A4a: косметика → ложное отвержение истины). Решает наличие внешнего grounding-слоя + консистентностный слой + качество извлечения якорей — а не выбор «VC или VOR».
**Урок:** перед публикацией «пруфа» — атаковать собственный эксперимент мутациями сценария: вывод, который рушится при изменении ОДНОЙ переменной (A6), — иллюстрация, не закон. VOR на гранулярности «якорь ∈ импорты» — нижняя граница возможностей; реальная семантика требует usage-уровня.

## [2026-08-15] — Гипотеза: recall(real)=0.08 у qwen3.6 в code_first — это anchor bias (нет evidence), а не «паранойя модели»; с реальным фрагментом файла recall прыгнет ≥0.5 при FA≈0

**Ожидание:** паттерн-строка `["typesense"]` не доказывает ничего — модель честно отвечает false/unknown. Если подать первые строки реального файла (V4-дизайн из §11.1 п.2) — у модели появится evidence, recall(real) вырастет. Проверка на 2 моделях-рекордсменах fail-closed (qwen3.6/3.7).
**Команда:**
```
python scripts/run_1L_live_arm.py --provider openrouter --arm file_content_first \
  --models "qwen/qwen3.6-flash,qwen/qwen3.7-flash" --no-reasoning --prompt-version v2 --tag file_content
python scripts/summarize_1L_categories.py --tag file_content --markdown
```
**Сырой результат:**
```
| модель | arm | real acc/rej/unk | recall(real) | precision | F1 | FA absent/16 | trap/6 | silent/3 |
| qwen/qwen3.6-flash | file_content_first | 22/3/0 | 0.88 | 0.92 | 0.90 | 0 | 2 | 0 |
| qwen/qwen3.7-flash | file_content_first | 22/2/1 | 0.88 | 0.96 | 0.92 | 0 | 1 | 0 |
(calls=50/model, errors=0/0, est_cost $0.0047 + $0.0007)
```
**Вердикт:** ✅ ПОДТВЕРЖДЕНА с оговоркой. recall(real): qwen3.6 **0.08 → 0.88** (×11, CI [0.70,0.96] не пересекается с baseline [0.02,0.25]), qwen3.7 **0.20 → 0.88** (×4.4). Диагноз «точки укуса №2»: **anchor bias**, не паранойя. Оговорка: FA не 0.00, а 0.02–0.04, и ВСЯ FA — present-trap (R45/R46: токен есть во фрагменте, субъект claim-а другой) — модель проверяет токен, не тождество субъекта; absent/silent 0/16 и 0/3 (декой-политика работает без утечки).
**Урок:** задача «поймай ложь и не тронь правду» решаема ДЕШЁВОЙ flash-моделью, если дать ей реальный код: VOR-слой обязан показывать фрагмент файла вокруг якоря (окно ±12 строк), а не токен-строку. Остаточная дыра — present-trap: нужна проверка СУБЪЕКТА (claim «X использует Y» — Y есть в коде, но X — нет). Цена: +~200 промпт-токенов/факт (~$0.0001–0.0004) пренебрежима vs цена ложного отзыва живой памяти.

## [2026-08-15] — Exp 2-E Evidence Ladder E1+E2+E3: форма evidence (anchor → file_content → graph) против качества верификации memory claims

**Ожидание (pre-registered, experiments/2E_evidence_ladder/README.md §6):** rung 1 (anchor) — слабо; rung 2 (file) — скачок recall; rung 3 (graph) — два исхода: graph≈file → структура не окупается; graph>file на present_trap → структурный слой закрывает failure mode. Один матричный прогон: 3 модели × 3 arm'а × 50 фактов v4_rep, v2 EN, zero-shot, temp=0, seed=42.

**Команда:**
```
python scripts/run_1L_live_arm.py --provider openrouter --arm code_first \
  --models "qwen/qwen3.7-flash,deepseek/deepseek-v4-flash,z-ai/glm-4.7-flash" \
  --prompt-version v2 --no-reasoning --tag 2e_e1          # rung 1 (anchor-строки)
python scripts/run_1L_live_arm.py --provider openrouter --arm file_content_first \
  --models "..." --no-reasoning --prompt-version v2 --tag 2e_e2   # rung 2 (25 строк)
python scripts/run_1L_live_arm.py --provider openrouter --arm graph_first \
  --ev-contexts experiments/2E_evidence_ladder/graph_contexts_594dae2a.json \
  --models "..." --no-reasoning --prompt-version v2 --tag 2e_e3   # rung 3 (структура)
python scripts/summarize_1L_categories.py --tag 2e_e{1,2,3} --markdown
```
(calls=450, errors=0, est_cost ≈ $0.007; progress: %LOCALAPPDATA%/mscodebase/projects/bfe9644b/experiments/live_arm_1L_progress_2e_e{1,2,3}_*.json)

**Сырой результат (per-category):**
```
| модель        | arm        | recall(real) | acc(decided) | unknown | FA absent/16 | FA trap/6 | FA silent/3 |
| qwen3.7-flash | code_first | 0.24 (6/25)  | 0.763 (29/38)| 0.24    | 0 | 0 | 0 |
| qwen3.7-flash | file       | 0.92 (23/25) | 0.940 (47/50)| 0.00    | 0 | 1 | 0 |
| qwen3.7-flash | graph      | 0.76 (19/25) | 0.913 (42/46)| 0.08    | 0 | 0 | 0 |
| deepseek-v4-flash | code  | 0.04 (1/25)  | 0.500 (1/2)  | 0.96    | 0 | 0 | 0 |
| deepseek-v4-flash | file  | 0.84 (21/25) | 0.875 (28/32)| 0.36    | 0 | 3 | 0 |
| deepseek-v4-flash | graph | 0.44 (11/25) | 0.824 (14/17)| 0.66    | 0 | 2 | 0 |
| glm-4.7-flash  | code_first | 0.60 (15/25) | 0.704 (19/27)| 0.46    | 3 | 3 | 2 |
| glm-4.7-flash  | file      | 0.68 (17/25) | 0.750 (36/48)| 0.04    | 0 | 5 | 0 |
| glm-4.7-flash  | graph     | 0.84 (21/25) | 0.787 (37/47)| 0.06    | 0 | 6 | 0 |
```

**Вердикт:** ⏳ ЧАСТИЧНО ПОДТВЕРЖДЕНА — «структурное evidence ≠ автоматически лучше» (исход №1) с важной границей (исход №2 для evidence-честных моделей):
1. **Rung1→2 подтверждён всеми 3 моделями:** qwen recall 0.24→0.92, deepseek 0.04→0.84, glm 0.60→0.68; FA trap: qwen 0→1, deepseek 0→3, glm 3→5. Фрагмент файла — сильнейший драйвер recall.
2. **Rung2→3 НЕ однороден (это и есть главный результат):**
   - **qwen3.7 (evidence-честная):** graph закрыл последний present-trap — FA trap **1/6 → 0/6**, FA total 0.02→**0.000**, но recall 0.92→0.76, acc 0.940→0.913. Граф закрывает failure mode ценой recall.
   - **deepseek (скептик):** FA trap 3/6→2/6, но recall 0.84→**0.44** (unknown 0.66) — списки вхождений и symbol-блоки подрывают доверие; сомнение вместо проверки.
   - **glm-4.7 (fail-open):** FA trap 5/6→**6/6**, recall 0.68→0.84 — списки вхождений («logging — 109 файлов») читаются как ПОДТВЕРЖДЕНИЕ. Ни одна форма evidence не лечит fail-open — это свойство модели, не evidence.
3. **Контроль воспроизводимости:** qwen3.7 file_content совпал с V4 (2026-08-15): recall 0.92 vs 0.88, FA 0.02 vs 0.02 — межпрогонная стабильность подтверждена.
4. **Ограничение датасета (честно):** R02 «InstructionScan» не дословно в файле — graph честно показал отсутствие символа → deepseek/glm false; file-фрагмент показывал docstring «Instruction Scan» → qwen true. Fuzzy-факты чувствительны к форме evidence.

**Урок:** для VOR: (а) recall-движок = фрагмент файла (25 строк); (б) graph-проверка субъекта = отдельный сигнал против trap, но только для evidence-честных моделей; (в) fail-open модели (glm-семейство) исключить из VOR-конвейера. Следующий шаг: гибридный arm file+graph (аддитивность?) и per-fact анализ расхождений qwen graph (R08/R17/R21/R24).

## [2026-08-15] — Exp 2-E Evidence Ladder E3b+E4: гибрид file+graph (аддитивность?) и temporal_first (git-провенанс: «было тогда» vs «сейчас»)

**Ожидание (pre-registered):** E3b — гибрид file+graph аддитивен (recall 0.92 от файла + FA trap 0 от графа)? E4 — git-провенанс (commit+date+branch в evidence) позволит моделям отличить «существовал до C» от «существует на HEAD».

**Команда:**
```
python scripts/run_1L_live_arm.py --provider openrouter --arm file_graph_first \
  --ev-contexts experiments/2E_evidence_ladder/graph_contexts_594dae2a.json \
  --models "qwen/qwen3.7-flash,deepseek/deepseek-v4-flash,z-ai/glm-4.7-flash" \
  --prompt-version v2 --no-reasoning --tag 2e_e4
python scripts/run_1L_live_arm.py --provider openrouter --arm temporal_first \
  --facts experiments/2E_evidence_ladder/temporal_facts_e3c1fdd4.json \
  --ev-contexts experiments/2E_evidence_ladder/temporal_contexts_e8571628.json \
  --models "..." --no-reasoning --prompt-version v2 --tag 2e_e5
```
(calls=294, errors=0, est_cost ≈ $0.007; temporal-датасет: 48 фактов = 12 removed / 28 real / 8 absent, генератор temporal_facts_generator.py, ground truth из git)

**Сырой результат:**
```
ГИБРИД (file_graph_first, v4_rep N=50):
| модель | acc(decided) | unknown | FA total | FA trap/6 | FA ids |
| qwen3.7 | 0.900 (45/50) | 0.00 | 0.02 | 1 | R45 |
| deepseek | 0.857 (36/42) | 0.16 | 0.08 | 4 | R42,R44,R45,R46 |
| glm | 0.820 (41/50) | 0.00 | 0.10 | 5 | R42..R46 |
TEMPORAL (temporal_first, N=48):
| модель | acc(decided) | FA removed/12 | real acc/28 | FA absent/8 |
| qwen3.7 | 0.896 (43/48) | 5 | 28 | 0 |
| deepseek | 1.000 (48/48) | 0 | 28 | 0 |
| glm | 1.000 (48/48) | 0 | 28 | 0 |
```

**Вердикт:** ❌ E3b — АДДИТИВНОСТИ НЕТ (отрицательный результат, ценный): qwen3.7 гибрид вернул FA trap 1/6 (R45) — граф «закрывает trap» ТОЛЬКО когда фрагмента нет; с фрагментом токен-присутствие доминирует (acc гибрида 0.900 < file 0.940). deepseek FA 0.08 > graph 0.04. Файл и граф НЕ складываются — VOR-дизайн выбирает ОДИН формат: фрагмент (recall) ЛИБО граф (trap-точность). ✅ E4 — git-провенанс работает у 2/3 моделей: deepseek и glm 48/48 (FA=0.00) — «existed until C» ≠ «exists» распознаётся идеально на existence-claims; НО qwen3.7 принял 5/12 removed (T04/T09-T12: CompositionAdapter, get_ext_root, _is_self_index_path, ExceptionSanitizer, mean_pool) — путает «existed until» с «exists» (~42%, Wilson CI 0.19-0.69 при N=12). Паттерна по дате/коммиту нет (T04 и T05 — один коммит, вердикты разные) — похоже на token-уровневую фамильярность/шум OpenRouter. КАВЕАТ: temporal-claims = existence-claims (легче usage-claims из v4_rep) — оба датасета комплементарны, не заменяют друг друга.

**Урок:** (1) для VOR — формат evidence выбирается по целевой метрике: fragment для recall, graph для trap-precision; гибрид = худшее из двух (acc 0.90). (2) git-провенанс в evidence — дешёвый и мощный сигнал для temporal-дистинкции (2/3 моделей 100%), но НЕ лечит qwen-семейство (5/12 trap). (3) модель-агент (deepseek-v4-flash) на temporal-датасете — идеальна (48/48); выбор LLM для VOR зависит от типа claims.

## [2026-08-15] — RED TEAM (атака на ground truth): 4/6 present-trap-фактов v4_rep по факту ИСТИННЫ — скорректированная матрица инвертирует выводы E3

**Атака (протокол §1.16, п.1 — атаковать данные, не модель):** grep по файлам субъектов trap-фактов.
**Команда:** `grep -c "logging" src/mcp/server.py; grep -c "threading" src/core/indexing/watchdog.py; grep -c "re\." src/core/graph.py; grep -c "pathlib" src/providers/reranker/llama_install.py; grep -c "dataclasses" src/mcp/server.py; grep -c "Path(" src/core/multi_project_searcher.py`
**Сырой результат:** R43 true (re: 2 usage), R45 true (logging: import+usage), R46 true (threading.Lock()), R47 true (pathlib: 6), R44 ambiguous (импорт без usage), R42 false (0). Причина: генератор проверял `value != real_value`, НЕ отсутствие value у субъекта.
**Скорректированная матрица (TRUE=29, FALSE=20):**
```
| arm             | qwen3.7 rec/FA | deepseek rec/FA | glm rec/FA |
| code_first      | 6/29, 0/20    | 1/29, 0/20     | 18/29, 5/20 |
| file_content    | 24/29, 0/20   | 23/29, 1/20    | 20/29, 1/20 |
| graph_first     | 19/29, 0/20   | 13/29, 0/20    | 25/29, 1/20 |
| file_graph      | 22/29, 0/20   | 24/29, 1/20    | 24/29, 1/20 |
```
**Вердикт:** ❌ «Граф закрывает present-trap» (E3) — АРТЕФАКТ: qwen graph = fail-closed на категории (miss_true 4/4); «glm не лечится» — ОПРОВЕРГНУТО: glm graph = лучший arm серии (25/29, FA 1/20). Формат evidence — per-model knob, не глобальный. v4_rep требует ре-лейблинга trap-категории; файл НЕ правился (исторический артефакт), corrected-логика в report.md §5.
**Урок:** FA-метрики на синтетических категориях обязаны проходить grep-валидацию по СУБЪЕКТУ, а не по проекту. P-паттерн: «метрика на mislabeled категории выглядит как результат модели».

## [2026-08-16] — Датасет v4_rep: corrected-копия (e6ce7b902d0a20a9). Прошлые прогоны 1-L использовали датасет с известной ошибкой в 4 trap-фактах — выводы сохраняются с оговоркой

**Команда (пересчёт fingerprint):** `sha256(json.dumps(data, ensure_ascii=False, sort_keys=True))[:16]`
**Сырой результат:**
```
original: memory_contamination_facts_v4_rep.json  fp=820bbbf60a0fc930  truth: 25 true / 25 false
corrected: memory_contamination_facts_v4_rep_corrected.json  fp=e6ce7b902d0a20a9  truth: 29 true / 20 false / 1 None (R44 ambiguous)
изменены: R43/R45/R46/R47 truth false->true (value импортирован+использован у субъекта);
R44 — truth=None (AMBIGUOUS, исключён из пулов); остальные 45 фактов БЕЗ изменений.
```
**Вердикт:** фиксация для истории — все прогоны 1-L (v1..v3_cot_max, file_content, ~3400 вызовов) и 2-E (e1..e5, 744 вызова) выполнялись на датасете `820bbbf60a0fc930` со встроенным truth в progress-файлах. Выводы 1-L построены на категориях real/absent/silent (44 факта) — НЕ затронуты; цифры «FA trap» (V4: 0.02–0.04, R45/R46) завышены — модели принимали истинные claims. corrected-пересчёт старых прогонов: verdict из progress + truth из corrected-файла по id (инлайн-логика в experiments/2E_evidence_ladder/report.md §5). Новые прогоны (pinned-rerun) — на corrected-датасете, harness пишет fact["truth"] из --facts.
**Урок:** fingerprint-привязка результатов к версии фактов — обязательна (работает); corrected-копия вместо правки оригинала — сохраняет историю; summarize_1L_categories.py берёт truth из progress-файлов — для corrected-метрик по старым прогонам нужен inline-пересчёт.

## [2026-08-16] — Аудит прогонов 2-E: серверный CSV OpenRouter (ключ test567) — 744 вызова чисто, полоса роутинга подтверждена

**Команда:** фильтр `openrouter_activity_2026-08-16.csv` (872 строки) → `app_name == "MSCodeBase 1-L live arm"` → `openrouter_activity_2026-08-16_exp.csv` (744 строки).
**Сырой результат:**
```
exp: 744 строки, все в 2026-08-15 21:xx UTC, ключ test567, finish_reason=stop ×744 (0 length/error)
модели: ровно 248 × {qwen/qwen3.7-flash, deepseek/deepseek-v4-flash, z-ai/glm-4.7-flash} (= 50×4 + 48)
провайдеры: Alibaba 248 (весь qwen — ОДИН бэкенд), StreamLake 245, DeepInfra 128, Cloudflare 96,
            Venice 21, Baidu 3, Novita 3 (glm/deepseek — 6 бэкендов)
стоимость: $0.012605 | prompt 237636 токенов, completion 6655 | generation_time 133ms–10.25s
удалено: 128 (MSPortfolio agent demo 108 + app_name='' 20 (probe/отладка) + ключ MSPort 11)
```
**Вердикт:** (1) прогоны 2-E чистые — 0 ошибок/обрывов, стоимость совпала с оценкой (~$0.013). (2) **Полоса роутинга подтверждена серверно:** qwen3.7 обслуживался ТОЛЬКО Alibaba (поэтому стабилен run-to-run); glm-4.7/deepseek — 6 разных бэкендов (отсюда недетерминизм glm и swing FA). Прямое обоснование `--pin-provider`: пинить нужно модели с мультибэкендной маршрутизацией (glm → StreamLake/Cloudflare/DeepInfra — какой из них канонический — выяснить pinned-probe).
**Урок:** серверный CSV — независимый аудит (как в 1-L): провайдерная карта объясняет per-model стабильность лучше, чем temp=0/seed.

## [2026-08-16] — E4b: слепой контроль temporal (без git-строк) — git-провенанс НЕ нужен и ВРЕДИТ qwen (48/48 у всех слепых)

**Гипотеза (red team атака 4):** 48/48 в E4 — артефакт лёгкости existence-claims («NOT FOUND AT HEAD» подсказывает вердикт), а не git-провенанса.
**Команда:**
```
python experiments/2E_evidence_ladder/graph_context_builder.py experiments/2E_evidence_ladder/temporal_facts_e3c1fdd4.json experiments/2E_evidence_ladder --blind
python scripts/run_1L_live_arm.py --provider openrouter --arm temporal_blind_first \
  --facts experiments/2E_evidence_ladder/temporal_facts_e3c1fdd4.json \
  --ev-contexts experiments/2E_evidence_ladder/temporal_blind_contexts_e8571628.json \
  --models "qwen/qwen3.7-flash,deepseek/deepseek-v4-flash,z-ai/glm-4.7-flash" \
  --prompt-version v2 --no-reasoning --tag 2e_e5b
```
**Сырой результат (сравнение sighted 2e_e5 vs blind 2e_e5b, N=48):**
```
| модель | sighted acc/FA-removed/12 | blind acc/FA-removed/12 |
| qwen3.7 | 43/48, 5 | 48/48, 0 |
| deepseek | 48/48, 0 | 48/48, 0 |
| glm | 48/48, 0 | 48/48, 0 |
```
**Вердикт:** ❌ «git-провенанс — мощный temporal-сигнал» — ОПРОВЕРГНУТО для existence-claims. (1) Blind = sighted у deepseek/glm → git-строки ничего не добавляют; (2) Blind > sighted у qwen (43→48) → git-строки АКТИВНО ВРЕДЯТ: «existed until C (subject с именем символа)» суггестирует существование — token-presence ловушка в evidence, qwen ей поддаётся (5/12), deepseek/glm — устойчивы. (3) Вывод E4 «qwen путает было-тогда/сейчас» — артефакт evidence, не модели.
**Урок:** добавляя провенанс в evidence, проверяй слепой контроль — дополнительный текст может создавать суггестию, которой без него нет. Для реального temporal-теста нужны claims БЕЗ подсказки «NOT FOUND» (usage-claims с темпоральной осью — предложено как E4c).

## [2026-08-16] — E4c: duo-дизайн (HEAD+история без подсказки) — temporal present-trap УНИВЕРСАЛЕН; past-вопрос решается формулировкой

**Гипотеза:** E4b-вывод «deepseek/glm устойчивы к git-суггестии, qwen нет» мог быть артефактом подсказки «NOT FOUND AT HEAD». Честный дизайн: один evidence (HEAD-состояние + «SYMBOLS in F at history» из git show), два вопроса — «X определён в F» (now, truth: removed=false) и «X был определён в F» (past, truth: removed=true).
**Команда:**
```
python experiments/2E_evidence_ladder/graph_context_builder.py experiments/2E_evidence_ladder/temporal_facts_e3c1fdd4.json experiments/2E_evidence_ladder --duo
# now: temporal_facts_e3c1fdd4.json, tag 2e_e6n; past: temporal_facts_e4c_past.json (fp d1d2c2ed440ec370), tag 2e_e6p
python scripts/run_1L_live_arm.py --provider openrouter --arm temporal_duo_first --facts <now|past> --ev-contexts experiments/2E_evidence_ladder/temporal_duo_contexts_e8571628.json --models "..." --prompt-version v2 --no-reasoning --tag 2e_e6{n,p}
```
**Сырой результат (288 вызовов, ~$0.005):**
```
NOW («X определён в F»):  removed FA: qwen 12/12, deepseek 9/12, glm 12/12; real/absent FA=0
PAST («X был определён в F»): removed miss_true 0/12, real 0/28, absent 0/8 — ВСЕ 48/48
```
**Вердикт:** ✅ temporal present-trap — УНИВЕРСАЛЬНОЕ свойство моделей (не evidence): когда evidence содержит символ в истории, а вопрос про настоящее — ВСЕ модели говорят true (12/12, 9/12, 12/12). Модель не отличает «X упомянут в evidence» от «X существует сейчас». Вопрос про прошлое — ВСЕ идеальны: явная временная формулировка claim решает задачу. E4b-вывод («deepseek/glm устойчивы, qwen нет») — артефакт подсказки «NOT FOUND AT HEAD»: без подсказки устойчивых НЕТ.
**Урок:** (1) история в evidence без явного маркера текущего состояния = токен-присутствие X = ложный true у любой модели; (2) для VOR проверки «существует сейчас» — evidence ТОЛЬКО HEAD, либо вопрос формулировать явно во времени (past/now). Temporal-вопрос серии ЗАКРЫТ.

## [2026-08-16] — summarize: inline-пересчёт (verdict из старых progress + truth из corrected) — corrected per-category метрики 1-L (3300+ вызовов)

**Команда:** `python scripts/summarize_1L_categories.py --facts experiments/1V_memory_contamination/memory_contamination_facts_v4_rep_corrected.json --markdown > experiments/2E_evidence_ladder/corrected_1L_metrics.md` (95 строк-моделей, все теги 1-L + 2-E)
**Сырой результат (ключевые ячейки, corrected: R43/45/46/47=true, R42=false, R44 excluded):**
```
v2_en code_first (canonical sweep):
| модель | recall(real) | FA absent | FA trap | FA silent | trap miss_true |
| qwen3.6 | 0.08 | 0 | 0 | 0 | 4 |
| qwen3.7 | 0.20 | 0 | 0 | 0 | 4 |
| deepseek | 0.04 | 0 | 0 | 0 | 4 |
| glm-4.7 | 0.88 | 7 | 0 | 2 | 1 |
| nemotron-3.5 | 0.52 | 0 | 0 | 1 | 3 |
file_content (V4):
| qwen3.6 | 0.88 | 0 | 0 | 0 | 2 |
| qwen3.7 | 0.88 | 0 | 0 | 0 | 3 |
```
**Вердикт (corrected-интерпретация 1-L):** (1) **Настоящие trap-FA (R42) — 0 у всех моделей**: «present-trap FA» в 1-L (V4: 0.02-0.04, R45/R46) был артефактом mislabeled данных — модели принимали ИСТИННЫЕ claims. (2) Вскрыт скрытый `trap miss_true`: fail-closed модели (qwen 4/5, deepseek 4/5) ОТВЕРГАЛИ истинные usage-claims — потеря правды, невидимая в старых метриках. (3) Реальный fail-open — absent/silent: glm code_first 7+2, nemotron memory_first 2 silent. (4) V4-вывод «FA 0.02-0.04 остаточная дыра trap» — уточнён: дыра была в лейблах, не в моделях.
**Урок:** метрики «FA по категории» без truth-валидации категории по субъекту = измерительный артефакт. Инструмент: --facts corrected в summarize (truth-based режим, старые прогоны пересчитываются без повторных вызовов).

## [2026-08-16] — Валидация corrected-пересчёта (ручная сверка перед публикацией): miss_true подтверждён, разъезда нет

**Команда:** сверка original vs corrected по всем 50 id (kind/subject/value/claim/support_patterns) + конкретные R43/R45/R46 в двух прогонах qwen3.7.
**Сырой результат:**
```
orig ids=50, corr ids=50, sets equal, дубликатов нет
Побочные поля, отличающиеся от original (кроме truth/label_note): НЕТ — 0 расхождений
Изменённые truth: ровно ['R43','R45','R46','R47']
v2_en/code_first qwen3.7: R43/R45/R46 verdict=false, truth(corr)=True → miss_true=True (подтверждено)
file_content qwen3.7: R43 verdict=false (miss_true), R45 verdict=true (ПРАВИЛЬНЫЙ true, не FA), R46 verdict=false (miss_true)
```
**Вердикт:** ✅ miss_true 4/5 у fail-closed моделей — РЕАЛЬНЫЙ факт, не артефакт пересчёта: категория trap не сдвигалась (kind идентичен), truth переопределён только у 4 подтверждённых фактов, verdict из progress привязан к тем же id. R45 в file_content (ранее «FA 0.02») — правильная вердикт модели, что подтверждает и V4-уточнение.
**Урок:** перед публикацией corrected-метрик — сверка id/полей original↔corrected и 2-3 конкретных факта по progress (проверка пользователя, принята).

## [2026-08-16] — Pinned-probe: выбор канонического бэкенда (комментарий Tom Jones, provider.order)

**Команда:** 3 факта (R01 true / R42 false / R45 true-corrected) × 3 повтора × кандидаты: glm-4.7 → StreamLake/Cloudflare/DeepInfra, deepseek-v4 → DeepInfra/Cloudflare (топ по CSV-аудиту).
**Сырой результат:**
```
glm-4.7  pin=StreamLake  R01:?/?/? R42:?/?/? R45:?/?/?  ← нечитаемые ответы (исключён)
glm-4.7  pin=Cloudflare  R01:true×3 ✓ R42:unknown×3 R45:true×3 ✓ (стабильно)
glm-4.7  pin=DeepInfra   R01:true×3 ✓ R42:unknown×3 R45:true×3 ✓ (стабильно)
deepseek pin=DeepInfra   R01:true×3 ✓ R42:unknown×3 R45:unknown×3 (стабильно)
deepseek pin=Cloudflare  R01:?/?/? R42:?/?/? R45:?/?/?  ← нечитаемые (исключён)
```
**Вердикт:** pinned-провайдеры для rerun: qwen → Alibaba (де-факто 248/248), deepseek/glm → **DeepInfra** (Cloudflare эквивалентен для glm; у deepseek Cloudflare битый). StreamLake (топ-1 unpinned у glm, 245 вызовов!) pinned — не отвечает: подтверждает, что unpinned-маршрутизация попадала на бэкенд с дефектным ответом — ещё один аргумент за пининг. R42 → unknown (не FA) у всех pinned — честный отказ, не ложный true.
**Урок:** объём в CSV ≠ качество бэкенда: StreamLake был самым нагруженным у glm, но pinned не отдаёт JSON — пининг также защищает от «популярного, но битого» апстрима.

## [2026-08-16] — Pinned-rerun на corrected-датасете (fp e6ce7b902d0a20a9): канонические числа серии, routing-полоса убрана

**Команда:** 15 прогонов (5 армов × 3 модели), --pin-provider: qwen→Alibaba, deepseek/glm→DeepInfra (по pinned-probe; StreamLake/Cloudflare-deepseek — битые pinned). corrected-датасет e6ce7b902d0a20a9 (R44 truth=None). Теги 2e_pin_*. +resume для error-фактов qwen. Стоимость ~$0.02.
**Сырой результат (corrected, pinned; FA trap = только R42; miss_true = отвергнутые истинные trap):**
```
| arm | qwen rec/FA-tr/miss | deepseek rec/FA-tr/miss | glm rec/FA-tr/miss |
| file_content | 0.88/0/3 | 0.80/1/2 | 0.68/2/1 |
| graph_first | 0.72/0/4 | 0.48/0/2 | 0.84/1/0 |
| file_graph | 0.84/0/3 | 0.92/1/2 | 0.80/2/1 |
temporal NOW removed-FA: qwen 12/12, deepseek 9/12, glm 12/12 (как unpinned)
temporal PAST: все 40/40 (как unpinned)
FA absent/silent: 0 во всех pinned-ячейках
```
**Вердикт:** (1) **Routing-полоса убрана, но per-model выводы серии НЕ изменились**: file_content — лучший recall у qwen (0.88), graph — лучший у glm (0.84, FA trap 1), hybrid — лучший у deepseek (0.92); temporal present-trap универсален (NOW 12/12, 9/12, 12/12), past решается формулировкой (40/40). (2) glm остаётся недетерминированной ДАЖЕ pinned (e3_g: unpin 6FA → pin-force1 2FA → pin-force2 1FA): пининг убрал маршрутизацию, не вариацию модели (±0.02-0.04 FA). (3) FA absent/silent = 0 у всех pinned evidence-армов — corrected-картина 1-L (trap miss_true 4/5 у fail-closed) — главный результат, не зависящий от маршрутизации.
**Урок:** pinned-rerun подтвердил устойчивость всех выводов серии к маршрутизации; glm-недетерминизм — свойство модели (даже single-backend); StreamLake (топ-1 unpinned у glm) pinned не отдаёт JSON — объём ≠ качество.

## [2026-08-16] — RED TEAM раунд 3 (аудит «проведён ли эксперимент правильно»): shuffle влияет (4/50), StreamLake = 404 no endpoint (не «битые ответы»), FA trap = N=1

**Команды:**
```
python scripts/run_1L_live_arm.py ... --arm code_first --facts corrected --models qwen3.7 --pin-provider Alibaba --shuffle-seed 123 --tag 2e_shuf
# StreamLake probe: httpx POST glm-4.7-flash, provider.order=[StreamLake]
```
**Сырой результат:**
```
shuffle: qwen code_first shuffled vs original — 4/50 расхождений (R45/R02/R43/R06), без систематического
         направления — порядок фактов влияет ~8% (блочный порядок R01-25=true, R26-50=false НЕ выверен)
StreamLake pinned: status=404 {"error":{"message":"No endpoints found for z-ai/glm-4.7-flash."}}
unpinned glm сейчас: provider=DeepInfra (15-го в CSV было StreamLake 245 вызовов) → маршрутизация ДРЕЙФУЕТ
z-ai/glm-4.7-flash: endpoints-поле в /api/v1/models отсутствует — проверить провайдеров через API нельзя
```
**Вердикт (честный аудит, ответ на «уверен ли что эксперимент правильный»):** НЕ полностью. (1) **Shuffle-контроль опроверг «порядок не угроза»**: 4/50 вердиктов чувствительны к порядку (8%). (2) **StreamLake-вывод был неточен**: не «unreadable responses», а 404 — StreamLake не держит glm-4.7-flash; unpinned-маршрутизация дрейфует по времени (StreamLake→DeepInfra) — источник части «недетерминизма» glm между разновременными прогонами. Формулировки исправлены в статье. (3) **FA trap держится на 1 факте (R42)** — статистически хрупко, зафиксировано. (4) Языковой конфаунд (RU claims/EN инструкции) — не проверен. Главные выводы серии (evidence-формат per-model, temporal present-trap, corrected-лейблы) от этих дыр не зависят, но статья дополнена Known weaknesses (7 пунктов).
**Урок:** «порядок не угроза» и «провайдер битый» — оба были непроверенными утверждениями; shuffle-контроль и сырой 404 — стоили копейки. Проверять, а не декларировать (P-паттерн: «непроверенное допущение в отчёте»).

## [2026-08-16] — E5: расширенная trap-категория (P-00X, лейблы по субъекту) — present-trap МАССОВ, graph реально помогает deepseek (75→40%)

**Команда:** trap_facts_generator.py (20 false-trap: value в проекте ≥2 файлов, НЕ в файле субъекта — grep субъекта=0; 10 true-trap) + прогон file_content_first/graph_first × 3 модели (pinned, correct pin: qwen→Alibaba, deepseek/glm→DeepInfra; первый прогон с Alibaba для всех — 404 glm, переделано). fp 138f306dbe14b66e → cb6f822b9eb66afd.
**Сырой результат (FA на 20 настоящих false-trap / recall на 10 true-trap):**
```
| arm             | qwen FA/rec | deepseek FA/rec | glm FA/rec |
| file_content    | 2/20, 2/10  | 15/20, 6/10     | 13/20, 7/10 |
| graph_first     | 2/20, 3/10  | 8/20, 5/10      | 14/20, 9/10 |
```
**Вердикт:** (1) **Present-trap — НЕ артефакт mislabeled данных**: на честных лейблах (валидация по субъекту) file_content FA 2-15/20 (10-75%) — «остаточная дыра trap» Part 2 была искажена; реально она массовая. (2) **Graph evidence РЕАЛЬНО закрывает present-trap у deepseek: 75%→40% FA** — на v4_rep (N=1 false) вывод «graph не помогает» был статистическим артефактом; у glm graph не помогает (14/20), у qwen FA и так 2/20 (но recall 2/10 — fail-closed). (3) Per-model формат подтверждён ещё сильнее: graph нужен deepseek против trap; qwen платит recall'ом за низкий FA.
**Урок:** «FA trap = 0» на категории с N=1 — бессмысленное число; расширение категории с валидацией по субъекту (P-00X) — единственный способ честно измерить present-trap. Ответ на вопрос ревьюера (chatgpt): «does the corrected generator reject value-anywhere-in-subject?» — ДА, trap_facts_generator.py проверяет grep субъекта = 0 (демонстрация фикса).

---

## [2026-08-25] — Гипотеза: fix заморозки MCP при full reindex (get_status на loop-потоке)
**Ожидание:** при full reindex ~7.5-12 мин ВСЕ MCP-вызовы отвечают мгновенно, а не таймаутят; search fast-fail; после завершения индекс цел.
**Команда:** `intel_trigger_reindex(mode="full")` → job 78a88a51; пробы: `intel_get_runtime_status`, `debug_runtime_passport`, `search_code(fast)`, `intel_get_job_status` (8 опросов); полный `python -m pytest tests/ -q`.
**Сырой результат:**
```
REINDEX: 9003/9003 completed за 519s (полный цикл 19:29:34→21:11:13),
         embedding avg 17-59 ch/s, фазы recreate→parse→embed.
ПРОБЫ ВО ВРЕМЯ REINDEX (22% → 76%):
  intel_get_runtime_status : мгновенно ×2 (фаза recreate — 0 chunks честно)
  debug_runtime_passport   : мгновенно ×2 (NO timeouts, uptime 257s живой)
  search_code(fast)        : мгновенный fast-fail («Index is not ready»)
  intel_get_job_status     : 8 опросов, все <1s, прогресс 22→24→34→44→52→62→76→100
ПОСЛЕ: intel_get_runtime_status → 🟢 9003 chunks | 540 files | 10714 symbols
pytest полный: 1518 passed, 5 skipped, 91 deselected, 0 failed (было 1512)
```
**Вердикт:** ПОДТВЕРЖДЕНА — заморозка устранена (ни одного таймаута за весь прогон). Но живой прогон выявил ВТОРИЧНЫЙ баг: `intel_get_runtime_status` показывал «0 chunks», `search_code` — «Index is empty → run index_project_dir» (враньё, провоцирует 2-й reindex) → закрыт коммитом c41c30e1 (Вариант А: status=reindexing + progress % + честный ToolError).
**Урок:** исправление блокировки ≠ исправление сигналов; после фикса liveness обязательно проверить семантику сообщений агенту — иначе агент «чинит» здоровое состояние.

---

## [2026-08-25] — Exp M1: реальная телеметрия инструментов → граница «65 инструментов» (research-only сессия)
**Гипотеза:** из ~62 зарегистрированных MCP-инструментов большинство мертвый груз в реальных сессиях; граница рабочего набора — одно-двузначное число.
**Команда:** `python experiments/mech_orch/tool_metrics_analysis.py` (историч. tool_metrics.json) + grep error_handler-строк 2MB лога mscodebase-intelligence.log + `debug_runtime_passport`/`intel_get_runtime_status`.
**Сырой результат:**
```
Registered: 32 core + 14 intel + 12 inline + 4 dev = 62 total;  MCP Tools: 16/32 видимы (MSCODEBASE_MCP_TOOLS=default)
tool_metrics.json (вся история): lsp_get_diagnostics 2c/0e, lsp_document_symbols 2c/0e, lsp_get_type_info 2c/2e (15s timeout), lsp_find_definition 1c/0e, lsp_find_references 1c/1e
= 8 calls total, 5 tools, 3 errors (37.5%) — LSP-набор нестабилен на этой машине
search_code: 10 timeout-записей 15-31s с retry (историч.); codebase hub: 1 timeout 30s
```
**Вердикт: ✅ ЧАСТИЧНО ПОДТВЕРЖДЕНА** — реальных данных мало (телеметрия пишется точечно), но: (1) только 5 инструментов из 62 имеют хоть одну запись метрик; (2) LSP-тулкит — 37.5% ошибок на 8 вызовах (top latency-риск); (3) сервер УЖЕ маскирует 16/32 по умолчанию. Метрики мертвого груза НЕ измеряются текущей телеметрией — нужен счётчик вызовов в error_handler-пути.
**Урок:** «сколько инструментов реально используется» нельзя измерить постфактум — телеметрия обязана писать каждый вызов (или хотя бы per-tool счётчик), иначе граница набора — интуиция, а не метрика.

## [2026-08-25] — Exp M2: субагент в свежем проекте: natural vs MCP-first (реальный инструментный след)
**Гипотеза:** свежий агент без инструкции про MCP не тронет MCP-инструменты (уйдёт в grep/read); с инструкцией — использует, но на неиндексированных файлах семантика бесполезна.
**Команда:** фикстура `experiments/mech_orch/lab/` (calc.py/rpn.py/tests, 1 planted bug: reverse-pop в RPN) → 2 субагента параллельно: A «MCP-first, только диагностика», B «natural, исправить». Baseline: 1 failed/4 passed.
**Сырой результат (самоотчёты агентов, TOOL TRACE):**
```
Agent A (MCP-first): MCP_CALLS=9 IDE_CALLS=5 | passport OK (RUN_ID a73f160e278a — субагенты видят тот же MCP!)
  search_code×2 (fast, про lab) -> 0 релевантных (lab НЕ в индексе); get_symbol_info('evaluate...') -> not found
  read_live_file×3 (rpn/calc/test) -> ОК, баг найден rpn.py:11 (reverse pop, некоммутативн. - и /); правки 0
Agent B (natural):   MCP_CALLS=0 IDE_CALLS=5 | list_directory+read×3+edit_file+terminal | 5 passed в 0.04s
Baseline after B fix: 5 passed in 0.03s;  git diff --stat: 1 file changed
```
**Вердикт: ✅ ОБЕ ЧАСТИ ПОДТВЕРЖДЕНЫ** — (1) natural-агент: 0/5 MCP (без промпта инструменты не используются вообще); (2) MCP-first-агент: 9 вызовов, из них ~4 холостых (2 search + get_symbol_info + find_path×2 на неиндексированный lab) — продуктивны только read_live_file (диск) и 3 pass/status/memory. Новые файлы невидимы до reindex → семантический слой на свежем коде = нуль. Контроль правильности: A нашёл корень с точным file:line, B починил все 4 ветки (не только `-`), тесты зелёные.
**Урок:** (1) ценность MCP-слоя — на ИНДЕКСИРОВАННОМ коде; для свежих/чужих директорий нужен fallback «read из диска + ripgrep» в мета-инструментах, а не молчаливый пустой ответ; (2) prompt (инструкция про MCP) — сильнейший предиктор использования инструментов, сильнее самого дизайна; граница «набора инструментов» определяется и discoverability тоже.

## [2026-08-25] — Exp M3: матрица реальной латентности MCP vs grep (search fast/quality, get_symbol_info)
**Гипотеза:** «quality-семантика» даёт лучший контекст за сопоставимое время; get_symbol_info работает как «точный» инструмент по имени символа.
**Команда (живая сессия, тот же индекс 9003 chunks):** search_code(fast='def get_stale_warning search_tools') → search_code(quality='how stale warning triggers during reindex blocking') → get_symbol_info('_get_stale_warning search_tools.py') → grep -c на диске.
**Сырой результат:**
```
search_code(fast)   75ms  -> точное попадание src/mcp/tools/search_tools.py:1 (_get_stale_warning) ✓
search_code(quality) 3666ms -> ПРОМАХ: results_tasks_v3.json + CHANGELOG.md (семантика ушла в мусор) ✗
get_symbol_info('_get_stale_warning search_tools.py') -> 'not found' ✗ (реальный символ! 2-й miss за сессию)
grep -c 'def evaluate' rpn.py  28ms ✓ (контроль)
```
**Вердикт: ❌ ОПРОВЕРГНУТА ОБЕ ЧАСТИ** — quality-режим в 49× медленнее fast (3666 vs 75ms) и при этом семантически хуже; get_symbol_info промахивается по точному имени с хвостом-подсказкой. В этой связке «fast search + grep + read_live_file» выигрывают у «quality search + symbol info» по времени И точности.
**Урок:** степень «умности» инструмента не коррелирует с пользой: дешёвый точный сигнал (fast/ripgrep) бьёт дорогую семантику (BGE-M3/BM25 rerank) на коротких запросах; QoS-порог для quality-режима (<1.5s) и fallback-цепочка fast→grep обязаны быть в мета-инструментах.

## [2026-08-25/26] — Exp E2: категорийный пилот на живом индексе (fast vs quality, 6 запросов с GT)
**Ожидание:** (H2.1) утечка между категориями (docs/JSON вместо кода) — главный дефект quality; (H2.2) fast выигрывает на идентификаторах, quality — на прозе.
**Команда:** 6 реальных запросов с ground truth из сессии × fast (5) + quality (3), limit=3 (детали: `experiments/mech_orch/E2_category_pilot.md`); GT верифицированы ранее grep/read. После релоада окна + рестарта MCP + реиндекса (9089 chunks).
**Сырой результат (lat / hit):**
```
Q1 _get_stale_warning     fast 75ms  HIT(top1)  | quality 3666ms MISS->JSON/CHANGELOG (M3)
Q2 lock_guard              fast 3779ms HIT(top1, холод) / 161ms тёплый
Q3 tool_metrics/error_handler fast 161ms HIT(домен)
Q4 reindex-заморозка        fast 190ms MISS (top1 = МОЙ E2-док: само-загрязнение)
                            | quality 6638ms HIT(домен)- src/core/indexing/indexer.py
Q5 verify_on_read           fast 172ms HIT | quality 284ms HIT (+ фрагмент matched/delivered)
Q6 smoke_e2e                fast 166ms HIT | quality 2638ms HIT (top1=incident_dataset)
fast: 5/6 = 83% hit;  quality: 2/3 hit + 1 домен-hit;  тёплая латентность fast 75-190ms,
quality 284ms-6638ms (мед. ~2.6s; 1 случай cold 6.6s)
```
**Вердикт: ✅ ЧАСТИЧНО обе гипотезы, с важной поправкой.** (1) Н3 ранжирования: fast 83% и на порядок дешевле; quality спас единственный fast-MISS (Q4) ценой ~35× времени. (2) Утечка подтверждена (Q1 quality → JSON/CHANGELOG; Q4/Q6 quality top-1 — incident-датасеты), но не «мусор» — семантически релевантные документы; фильтр нужен по приоритету категорий, не по запрету. (3) **НОВОЕ: само-загрязнение индекса собственными доками** (experiments/mech_orch/* перехватывает кодовый запрос) — дешёвый фикс веса/исключения, валидируемый на tasks_v3.json. (4) Бинарный роут fast/quality не оптимален: эффективнее каскад fast-hit→стоп / MISS→quality+фильтр+бюджет.
**Урок:** «форма запроса → режим» недоопределено без категорийного фильтра; добавление эксперимент-доков в индекс меняет ранжирование (индекс чувствителен к своему составу — нужен контроль экспериментов в ранжировании). Связь: EXPERIMENTS_LOG#M3, contexts_engine/tasks_v3.json (E3).

## [2026-08-26] — Exp E3: категорийный роутер на tasks_v3.json (30 задач, реальный индекс, 3 руки)
**Ожидание:** (1) каскад fast→quality окупается; (2) разные klass требуют разных рук (роутер по классам > единой руки).
**Команда:** `EXT venv python experiments/mech_orch/E3_category_router_eval.py` (limit=8, topk=5; реальная БД 9089 rows; embedder force llama_cpp — авто-детект в standalone ломается в ONNX-fallback, артефакт среды). Руки: fast / quality / cascade.
**Сырой результат:**
```
ARM      recall@5  facts_cov  lat_med   lat_p95
fast       0.167      0.517     148ms     167ms
quality    0.133      0.861    2145ms    6803ms
cascade    0.233      0.753     564ms    6909ms
BY KLASS (fast/quality/cascade):
 find_bug_cause 0.20/0.00/0.20 | find_caller_callee 0.00/0.50/0.50 | find_impact 0/0/0
 find_test 0/0/0 | git_history 0.50/0.25/0.50 | modify_function 0/0/0
 prepare_change 0.25/0.00/0.25 | understand_architecture 0.25/0.50/0.50 | verify_change 0/0/0
```
**Вердикт: ✅ обе гипотезы подтверждены.** (1) Каскад — победитель: recall 0.233 > fast 0.167 > quality 0.133 при медиане 564ms (quality 2145ms), p95 6.9s vs 167ms у fast. (2) Победитель зависит от класса: git_history/bug/prepare → fast (quality 0.00 у bug!); caller_callee/architecture → quality; (3) **find_test/find_impact/modify/verify_change = 0.00 у ВСЕХ рук** — поиск не заменяет граф/AST/impact-стадии: «паспорт кода» обязан включать call graph + impact + test-mapping, а не быть search-only.
**Урок:** поиск-только даёт recall@5 ≤ 0.23 на реальных кодовых задачах; категория (klass) — реальный предиктор победившей руки; точность «single sweeper» без граф-стадии ограничена на test/impact классах. Артефакт: results_E3_router.json, скрипт E3_category_router_eval.py (read-only, переиспользуем).

## [2026-08-26] — Exp E4 (PoC, ОТРИЦАТЕЛЬНЫЙ): детерминированный keyword-роутер по классам
**Ожидание:** пер-классный роутер (fast/bug+git+prepare, quality/caller+arch, union/test+impact+modify+verify) даст recall ≥ каскада (0.233) при медиане < 600ms.
**Команда:** `EXT venv python experiments/mech_orch/E4_router_poc.py` — классификатор: 9 keyword-правил (порядок важен), руки по E3; те же метрики.
**Сырой результат:**
```
router: recall=0.200 facts_cov=0.533 lat_med=298ms p95=10745ms klass_acc=0.40
baselines (E3): fast 0.167 / quality 0.133 / cascade 0.233
BY KLASS: find_bug_cause 0.20 | git_history 0.50 | caller_callee 0.50 | arch 0.25 | prepare 0.25
          modify/test/impact/verify: 0.00 ВСЕ (даже union fast+quality)
```
**Вердикт: ❌ ОПРОВЕРГНУТА (роутер проиграл каскаду 0.200 vs 0.233).** Причины: (1) klass_acc=0.40 — keyword-правила шумные (bug-задачи содержат «callers», гиты — «почему»); (2) union-рука для 4 граф-классов не спасает — поиск не может найти то, чего нет в индексе текстово (нужны callers/callees/impact по графу). Потолок search-only рук на этом датасете ≈ 0.23 при ЛЮБОЙ маршрутизации.
**Доп. находка: `symbol_index.json` на диске ПУСТ** (`definitions:{}`) при 10748 символах в памяти рантайма — граф-стадия cold-start с диска невозможна без починки персистенции или пересборки.
**Урок (отрицательный, «не повторять»): keyword-роутер по промпту не окупается (acc 0.40); улучшение — фичи запроса (symbol-токены, интенты-глаголы, приоритеты), НО потолок без граф-стадии остаётся. Главный вывод: «паспорт кода» = search(fast+cascade) + ОТДЕЛЬНАЯ граф-стадия (symbol index в памяти), иначе 4/9 классов = 0.00 всегда.

## [2026-08-26] — Exp E4.1 (ПОЛОЖИТЕЛЬНЫЙ): граф-стадия пробивает потолок (Дорожка 1)
**Ожидание:** граф-стадия (SymbolIndexAdapter над graph.db, cold-start) поднимает 4 провальных класса (find_test/find_impact/modify/verify) выше search-only потолка; цель recall≥0.40 med<600ms.
**Правки:** (1) гард в index_guard.save_symbol_index — граф-адаптер без _definitions/_references НЕ пишет пустой JSON поверх непустого (инцидент: symbol_index.json был пуст при 10748 символах в памяти); 4 юнит-теста tests/test_symbol_index_persistence.py; ruff clean. (2) E4_1_graph_arm.py: извлечение символа из промпта через search_symbols (LIKE) со strict-правилом `endswith('.'+token)`, суффикс-варианты, fallback на каскад.
**Команда:** `EXT venv python experiments/mech_orch/E4_1_graph_arm.py` (same-run: каскад И каскад+граф в одном процессе; реальный graph.db 10748 узлов/33538 рёбер).
**Сырой результат:**
```
same-run:  cascade alone 0.267 | +graph arm 0.433 | med=177ms p95=4220ms
BY KLASS (graph vs cascade): find_impact 1.00 vs 0.00 | find_test 0.50 vs 0.00
  modify_function 0.25 vs 0.00 | verify_change 0.00 vs 0.00 | остальные — equal
Примеры попаданий граф-руки (10-15ms, факты вместо 4-7s quality):
  T2 modify: graph:intel_code_topology -> layer.py H (cascade -)
  T3 impact: graph:_expand_graph_context -> engine.py H | T5 test: trigger_reindex H
  T18 impact: notify_change -> server_tools.py H | T27 impact: intel_code_topology H
```
**Вердикт: ✅ ЦЕЛЬ ДОСТИГНУТА (0.433 ≥ 0.40, med 177ms < 600ms).** Граф-стадия добавила +0.166 recall на трёх из четырёх провальных классов при латентности ~15ms и НЕ проиграла ни на одном классе (fallback на каскад по построению). Три урока: (1) has_symbol — ТОЧНОЕ имя узла, нужен search_symbols(LIKE) + strict-суффикс; (2) граф-навигация обязана идти через SymbolIndexAdapter(graph.db), а не plain SymbolIndex с диска (пустой JSON); (3) пустой symbol_index.json НЕ блокировал граф — блокировал выбор неправильного инстанса.
**Остаток честно:** verify_change остаётся 0 (T9 'engine' резолвится в CodeEvidence; T29 — промпт без идентификаторов); facts-покрытие граф-строк не считалось (граф отдаёт файлы, не текст); run-to-run дисперсия fast/quality высока — same-run методология обязательна.
**Связь:** EXPERIMENTS_LOG#E3/F#E4, results_E4_1_graph.json, tests/test_symbol_index_persistence.py, src/core/indexing/index_guard.py (гард).

## [2026-08-26] — Exp E4.2 (Дорожка 2, ПОЛОЖИТЕЛЬНЫЙ на граф-слое): детерминированный concept-резолвер символа + факты для граф-строк
**Ожидание:** два остатка E4.1 — verify_change=0 (T9 резолв 'engine' wrong-anchor, T29 no-anchor) и «граф отдаёт файлы, не текст» (facts=0) — закрываются НЕ LLM-классификатором, а механическим concept-phrase-реестром (fail-open, klass-gated) ПЕРЕД лексическим extract_symbol (РЕЗОЛВ, не классификатор — RESEARCH.md rec #3). Регресс на других классах структурно исключён: рецепты klass-gated на verify_change, остальные классы fallback на старый extract_symbol.
**Правки:** (1) experiments/mech_orch/resolver.py — CONCEPT_RECIPES («обновления индекса»→notify_change; «паттерны извлечения»→_extract_symbol_name) + concept_symbol(prompt,klass) + graph_fact_text (сниппеты def+docstring вокруг строки определения); (2) E4_1_graph_arm.py — concept_symbol ПЕРЕД extract_symbol + facts=fact_covered(graph_fact_text) для граф-строк; (3) tests/test_mech_resolver.py (10 чистых, без сервисов).
**Команда (подтверждение слоя, без эмбеддера):** `python experiments/mech_orch/probe_e42_verify.py` (реальный graph.db, read-only) + `python -m pytest tests/test_mech_resolver.py tests/test_symbol_index_persistence.py -q`.
**Сырой результат:**
```
[probe] T9  verify_change sym=notify_change        files=[.../src/mcp/server_tools.py]      -> HIT gt=src/mcp/server_tools.py facts=4/4
[probe] T29 verify_change sym=_extract_symbol_name files=[..., .../src/core/search/utils.py] -> HIT gt=src/core/search/utils.py facts=3/4
[probe] === E4.2 graph-layer probe: verify_change ALL HIT ===
[pytest] 14 passed in 2.48s  (test_mech_resolver 10 + test_symbol_index_persistence 4)
```
**Вердикт: ✅ ПОДТВЕРЖДЕНА ПОЛНОСТЬЮ (live same-run 30 задач выполнен).** Граф-слой: оба verify_change-промаха резолвятся в правильный файл (T9 notify_change→server_tools.py HIT facts 4/4, T29 _extract_symbol_name→utils.py HIT facts 3/4). Полный live-прогон:
```
cascade alone : recall=0.267
+graph arm    : recall=0.50 med=196.8ms p95=4514.1ms  TARGET recall>=0.40 med<600ms — ДОСТИГНУТА
verify_change : n=2 graph=1.00 cascade=0.00 (T9 arm=graph:notify_change H, T29 arm=graph:_extract_symbol_name H)
BY KLASS: find_impact 1.00 | git_history 1.00 | find_test 0.50 | modify_function 0.25 — ни один класс не просел ниже каскада (9/9 >= cascade)
```
Регресс подтверждён не только по построению (klass-gating), но и фактом: 9/9 классов ≥ каскада. E4.2 превращает «остаток» E4.1 (verify_change=0, facts не считались) в закрытые пункты: recall 0.433→0.50, verify_change 0→1.0.
**Урок:** «бессловесный» промпт — это не задача классификации, а задача резолва якоря: лексический extract_symbol не переживает ни «следствие вместо имени» (T9), ни «концепт вместо имени» (T29). Механический concept-реестр с klass-gating — детерминированный и не регрессит; корпусное наполнение рецептов — из 3300-call корпуса (RESEARCH.md rec 3).
**Связь:** EXPERIMENTS_LOG#E4.1, results_E4_1_graph.json, experiments/mech_orch/{resolver.py,probe_e42_verify.py,E4_1_graph_arm.py}, tests/test_mech_resolver.py.


## [2026-09-05] — Гипотеза: stale_detector + predict_change таймаутят (-32001) из-за блокирующего sync-кода в async-контексте, а не из-за медленной логики

**Ожидание:** Если `asyncio.wait_for` (в `error_boundary`) обёрнут вокруг асинхронной корутины, которая вызывает СИНХРОННЫЙ блокирующий код (`stale_run`, git subprocess) — то wait_for НЕ сможет прервать операцию вовремя (Windows не отменяет работающий sync-IO), event loop заблокирован, MCP-клиент отваливается по транспортному таймауту ДО ответа. Перенос sync-блока в `asyncio.to_thread` должен восстановить прерываемость и живость event loop.

**Команда (контролируемый замер, venv расширения):**
```python
# 1. baseline: старый код без to_thread
asyncio.wait_for(stub(), timeout=10)   # stub = sync stale_run
# → вернулся через 24.7s (wait_for НЕ прервал!) — loop заблокирован
# 2. фикс: to_thread
asyncio.wait_for(asyncio.to_thread(stale_run, ...), timeout=5)  # → REAL TIMEOUT 5.02s, loop жив
asyncio.wait_for(asyncio.to_thread(...), timeout=30)            # → OK 28.96s (73 файла)
```

**Сырой результат:**
```
CASE timeout=10000ms (без to_thread) -> OK in 24.73s: 73 files, drift=609   ← wait_for НЕ прервал
CASE timeout=30000ms (без to_thread) -> OK in 22.76s: 73 files, drift=609
to_thread timeout=5000ms  -> REAL TIMEOUT after 5.02s (event loop alive!)
to_thread timeout=10000ms -> REAL TIMEOUT after 10.02s
to_thread timeout=30000ms -> OK 28.96s files=73
stale_run напрямую (терминал): ELAPSED 10.06s, files 73, total_drift 609
static_predict напрямую (терминал): ELAPSED 0.53s, changed=3, affected_tests=21, risk=high
```

**Вердикт:** ✅ ПОДТВЕРЖДЕНА. Корень — не «медленная логика», а блокирующий sync-код в async-функции: `wait_for` не может прервать sync-блок на Windows (дождался 24.7s при лимите 10s), event loop мёртв → клиент -32001. После `to_thread` — реальное прерывание за 5/10s, loop жив. Фикс: `asyncio.to_thread` для `_scan_docs`, `static_predict`, `ChangePreview.run`; таймауты 10s→60s (stale), 60s→120s (predict). Верификация: `StaleDetectorTool.execute({})` → OK 13.0s (0 дрейфов), `PredictChangeTool.execute({'mode':'static'})` → OK 1.4s (7 files, risk); 62 теста passed.

**Урок:** «таймаут, который не может прервать работающий sync-блок, — фарс». В async MCP-инструментах любой потенциально долгий subprocess/filesystem-блок обязан быть в `asyncio.to_thread` (§9 incorporate). Завышенный впрок таймаут (60-120s) лучше заниженного (10s): реальная длительность изменчива (10→29s в потоке).

**Связь:** AGENT_DIARY#2026-09-05-1230, KNOWN_ISSUES#2026-09-05-stale-predict-timeout, files src/mcp/tools/doc_tools.py, src/mcp/tools/predict_tools.py.

## [2026-09-09] - E-S1/E-S2: языковые карты импортов/вызовов/скелета на живых топ-репо (6 языков) + свежесть индекса

**Контекст:** закрыть незавершённые шаги E-S1/E-S2 из дока 05 §3 п.5 и дока 08 §3: эмпирически проверить карты parser.py (фиксы B3+B4, PR #25) на реальном коде; заодно перепроверить синтетический дефект «вызовы PHP/Ruby/C/Dart = 0» и свежесть индекса после PR #31. Прогон выполнен AutoCoder (внешняя сессия) без изменений репозитория: shallow-клоны 6 репо (commons-lang, composer, curl, kotlinx-serialization, dart-http, rspec-core) в рабочей папке вне репо; venv python; CodeParser.extract_imports/extract_calls/extract_assignments; кап 300 файлов/язык; read_text utf-8 errors=replace.

**Сырые результаты (import_edge_rate / call_edge_rate / assignments+condition_path):**
```
java    commons-lang           files=300  imp=0.867 (1487)  lies=0   call=0.710 (26184)  asg=1983 cond=1197
php     composer               files=300  imp=0.797 (1827)  lies=13  call=0.813 (16142)  asg=3473 cond=2058
c       curl (.c)              files=300  imp=0.680 (1253)  lies=65  call=0.250 (5791)   asg=1685 cond=1332
kotlin  kotlinx-serialization  files=300  imp=0.853 (1071)  lies=18  call=0.663 (5005)   asg=754  cond=220
dart    dart-lang/http         files=300  imp=0.940 (1210)  lies=2   call=0.080 (57)     asg=549  cond=148
ruby    rspec-core             files=233  imp=0.618 (557)   lies=21  call=0.562 (3620)   asg=731  cond=40
lies = файлы с явными import/include/require в тексте, но 0 извлечённых рёбер ("карта врёт" по дока 05 §3 п.5)
```

**Вывод:** (1) E-S1 закрыт: карты импортов живые на всех 6 языках (61.8%-94% файлов дают рёбра). (2) Дефект «вызовы PHP/Ruby/C/Dart» со синтетической пробы СНЯТ: на реальном коде все 4 языка извлекают вызовы (0.08-0.81); синтетика вводила в заблуждение (мини-файлы без полного function-контекста -> current_function пуст). (3) E-S2 закрыт: скелет ASSIGNED_FROM+condition_path даёт тысячи строк вне Python. (4) Остаточный риск: ненулевые map_lies (curl 65/300 - преимущественно .h, php 13, kotlin 18, ruby 21, dart 2). (5) НОВАЯ НАХОДКА: ".h" отсутствует в SUPPORTED_EXTENSIONS/parsers (есть .hpp/.cxx/.cpp) - заголовки C-проектов выпадают из индекса (curl lies в осн. .h; dart-http .c 0/9). Кандидат в KNOWN_ISSUES. (6) Свежесть индекса: до реиндекса в PropertyGraph отсутствовали новые test_collect_* из PR #31; intel_trigger_reindex (Job 52f138be) поднял symbol index 11053->11081, но узлы графа для новых тестов так и не появились и chunks остались 9308 - lazy-реиндекс обновляет symbol index без пересборки графа (согласуется с KNOWN_ISSUES #13 Lazy-only).

**Прав:** пробы выполнялись вне репозитория; файлы репо этим экспериментом не изменялись. Методологическая заметка: первая версия пробы AutoCoder падала TypeError str-in-bytes на каждом файле (баг пробы, не проекта) - после фикса все errs=0; полезное напоминание верифицировать нулевые результаты пробы на санинтарном файле перед выводами о картах.

**Связи:** docs/research/universal-engine-study/05-grammar-node-kinds.md §3, docs/research/universal-engine-study/08-e-s1-polygon.md §3, KNOWN_ISSUES #13, аудиторский отчёт AutoCoder 2026-09-08/09 (delivery/mscodebase-readiness-audit-2026-09-08.html), полные JSON/логи пробы: .cluster/mscodebase-audit-0908/evidence/ (внешняя рабочая папка AutoCoder).

## [2026-09-09] — «MCP tool available but never invoked» (Exhibit #23) + Active MSCodeBase план: аудит компонентов

**Гипотеза (из внешнего чат-лога GLM-5.3 + собственный повтор):** агент НЕ вызывает доступный MCP-тул даже при явной инструкции в промпте («вызови MCP») — промпт = рекомендация (suggestion), не enforcement. Результат — не галлюцинация, а «silent skip»: агент выглядит работающим, но данные не свежие. Решение по аналогии с #21 (modification guard): precondition contract — «не отвечай, пока данные не загружены», fail-closed. Архитектурный сдвиг: Pull (агент вызывает) → Push (система подготавливает данные ДО агента).

**Проверка (MCP-first, все через search_code/get_symbol_info/read_live_file, не grep):**
- `_check_index_health` (task_queue.py:373) — module-level функция (НЕ метод), тело = `logger.debug`. Заглушка.
- `_improve_summaries_batch` (task_queue.py:385) — та же пустота. 2 из 3 idle-задач пустые; 3-я (`_update_docs_if_stale`) реальная.
- `VerifyOnRead.run(memory, budget_ms=50)` (verify_on_read.py:679) — сигнатура принимает ПОЛНЫЙ dict памяти, НЕ пачку nodes.
- `store.get_active_nodes()` — НЕ СУЩЕСТВУЕТ (search_code → not found). Память грузится `load_memory()`, фильтрация ACTIVE внутри VOR.
- VOR вызывается ровно из 1 места: layer.py:1097 (`intel_get_project_memory`, verify_on_read=True). Lazy by design (ADR-0003).
- `ConsistencyTracker.mark_stale("memory")` — домен "memory" объявлен в DOMAINS, но mark_stale для него нигде не вызывается. STALE не связан с VOR.
- FS-watcher (watchdog.Observer/FileSystemEventHandler) — ОТСУТСТВУЕТ. Есть только heartbeat-Watchdog (индексатор) + `_start_zed_parent_watchdog` + llama idle-watchdog. FileSystemEventHandler — 0 results.
- `system_alerts`/`pending_stale`/`stale_alerts` — ОТСУТСТВУЕТ (search фразы → 0).
- `DebounceBatch` (rate_limiter.py:128) — ЕСТЬ, debounce 500ms, вызывается из `notify_change` (indexing_tools.py:69).
- `IdleScheduler` (task_queue.py:337-438) — ЕСТЬ, включается из `record_tool_call()`, cooldown 120s, CPU-guard `_cpu_available()`. Точка интеграции для фонового VOR.
- `PropagationEngine` (propagation_engine.py:59) — каскадная ретракция, но только при ручном `intel_retract`.

**Ключевая находка:** фундамент ЕСТЬ (VOR / DebounceBatch / ConsistencyTracker / IdleScheduler / PropagationEngine), но компоненты ИЗОЛИРОВАНЫ — цепочка «файл изменён → STALE → VOR → alert агента» не существует ни в одном звене. Это и есть «23-й экземпляр», подтверждённый на собственном коде: VOR живёт, но не вызывается никем, кроме ручного read.

**Отклонённый фрагмент чужого плана (Red Team):** чужой код-план (другой агент) использовал НЕсуществующие API: `self.context.verify_on_read` (нет self), `vor.run(nodes=...)` (нет такого параметра), `store.get_active_nodes()` (нет метода). Вердикт: план угадан по архитектуре, не по коду — брать концепт, не код.

**Атаки Red Team на предложенную интеграцию (VOR в idle):**
1. Lock contention idle-VOR vs agent-VOR (один `_write_lock`) → ⚠️ средний: `asyncio.to_thread` в layer.py:1107, idle-VOR идёт в отдельном потоке TaskQueue → нет deadlock, но добавить `locked()`-check перед запуском из idle.
2. H3 TTL-гниение к INCONCLUSIVE-узлам НЕ применима (INCONCLUSIVE статус не меняется без якорей) → TTL гниение работает только VERIFIED→STALE; 42 узла без verified_at с 2026-08-11 останутся «навечно». Вывод: нужен H1 (idle-ticker), не H3.
3. Import cycle task_queue → verify_on_read → layer → проверить architecture_linter. Защита: локальный import внутри try/except как `_update_docs_if_stale`.
4. system_alerts оверхед токенов → низкий: alerts одноразовые (clear после delivery), VOR не частый (cooldown 120s).
5. Concurrent файловые изменения при VOR → защищено freshness gate (evaluate_freshness/resolve_head_dirty, commit B): fingerprint кэшируется по build_head, mismatch → INCONCLUSIVE, не ложный REFUTED.

**Вердикт:** ПОДТВЕРЖДЕНО (аудит несуществующей «активной» цепи) + REFUTED (чужой код-план: API не существует). Рекомендация: (1) реализовать H1 — подключить VOR в `_check_index_health` (idle-ticker, ~15 строк); (2) не добавлять watchdog lib сейчас — `notify_change` уже ловит save; (3) system_alerts добавить после H1 (инъекция в ответы MCP-тулов).

**Урок:** проверять чужой план против РЕАЛЬНЫХ сигнатур через get_symbol_info/search_code, а не против «как это выглядит по описанию». Три угаданных API ≠ одна рабочая интеграция.

**Связи:** KNOWN_ISSUES 2026-09-07 «Lazy-only верификация» (открыт), docs/research/universal-engine-study/10-continuous-verification.md (план H1/H2/H3, pending), ADR-0003 (Verify-On-Read), commit B (head-freshness, cb88c961).

## [2026-09-10] — system_alerts цепь «файл изменён → STALE → VOR → alert агента» + idle-VOR (H1)

**Контекст:** закрыть Exhibit #23 (MCP tool available but never invoked) и KNOWN_ISSUES 2026-09-07 по приоритету «(3) system_alerts после H1». H1 (idle-VOR) реализован в AGENT_DIARY 2026-09-09; здесь — (А) одноразовые system_alerts и сквозная доставка в MCP-ответы.

**Гипотеза:** цепь «файл изменён → STALE → VOR → alert агента» собирается существующими механизмами (DebounceBatch notify_change → ConsistencyTracker STALE → фоновый VOR → AlertStore → формат в ответе) без новых watchdog-библиотек и без токен-оверхеда.

**Дизайн (probe):** `AlertStore` (src/core/intelligence/alert_store.py) — JSON вне проекта (`<data_root>/projects/<hash>/intelligence/system_alerts.json`), `threading.Lock` (не asyncio — несколько event-loop'ов), дедуп по kind+payload, атомарный `collect_and_clear(limit=5)`, `ALERT_KINDS=("memory_stale","memory_starved")`, неизвестный kind игнорируется. Генераторы: `memory_stale` — только при ПЕРВОМ переходе UNKNOWN/CONSISTENT→STALE в `notify_change` (не на каждый save — иначе спам, reason меняется на файл); `memory_starved` — из idle-VOR и `intel_get_project_memory` (виден ≥2 циклов, MATCHED>0/DELIVERED=0). Доставка: prepend `format_system_alerts` в `intel_get_project_memory`, секция в `intel_explain_project_state` (в try/except — алерты не роняют диагноз).

**Проверка (реальные запуски, не моки):**
- `python -m pytest tests/test_alert_store.py tests/test_ui_formatter_memory.py -q` → 28 passed (11 новых AlertStore + 3 форматтера).
- Полный `python -m pytest tests/ -q` → `1689 passed, 5 skipped, 91 deselected` (180.83s). Единственный фейл в первом прогоне — предсуществующий slow-тест `test_health_report.py::test_logs_with_errors` из-за переопределения addopts (`-m 'not slow...'`), не связан с изменением.
- `scripts/architecture_linter.py` → «Все инварианты соблюдены»; ruff: 4 автофикса (W292×2, I001, F401) → чисто; pre-commit 9/9.
- concurrency: 2 потока × 20 alerts → collect не теряет и не дублирует (at-most-once delivery подтверждён).

**Вердикт:** ✅ ПОДТВЕРЖДЕНА. Вся цепь собрана одним коммитом `1e0c1b4f` (feat(alerts), 10 файлов, +446/−4): AlertStore + 2 генератора + 2 точки доставки + 14 тестов. `verified_from_clean_state: ⚠️ не проверено` (чистый клон не гонялся).

**Урок:** дедуп по kind+payload с атомарным `collect_and_clear` — правильная гранулярность одноразовых алертов: ловит и «спам на каждый save», и «гонка двух MCP-тулов» одновременно; limit=5 капает токены. Перевод STALE в alert — только на первом переходе, иначе тот же контент (reason меняется на имя файла) становится спамом несмотря на дедуп.

**Связи:** AGENT_DIARY 2026-09-10 «H1 idle-VOR + system_alerts», KNOWN_ISSUES «Lazy-only верификация» (закрыт), docs/research/universal-engine-study/10-continuous-verification.md (H1/H2/H3).

## [2026-09-10] — Exp 1: VOR Catch-up Rate (H1): throughput по бюджетам и cycles-to-finish

**Контекст:** закрыть KNOWN_ISSUES 2026-09-07 «Lazy-only верификация» (3-й пункт — достыкован exp 2026-09-10 system_alerts). Вопрос: успевает ли VerifyOnRead проверить ACTIVE-узлы в рамках budget_ms=50 (read-path default) и 250 (background idle-VOR), и при каком N начинается systematic starvation.

**Дизайн:** synthetic-узлы (claim ~120 симв + file-якорь на реальный файл src/ или несуществующий `src/missing_N.py`) в секцию tech_debt; N ∈ {200, 500, 2000, 5000}; прогреваются fingerprint один раз (rebuild не в счёт per-node цикла); чистый VerifyOnRead на каждую пару бюджет/цикл; статусы и кэш бэкапятся и откатываются в finally (рабочая память проекта не тронута).

**Команда:** `venv/Scripts/python.exe <tmp>/exp1_vor_catchup.py` (scratch-cкрипт, удалён).

**Сырой результат:**
```
budget= 50ms N=200  → checked 200/200  budget_exceeded=0 starved=0 latency=36ms
budget=250ms N=200  → checked 0 (кэш от первого прохода) latency=3.5ms
budget= 50ms N=500  → checked 492/500  budget_exceeded=8  starved=0 latency=79ms
budget=250ms N=500  → checked 8 (кэш) latency=49ms
budget= 50ms N=2000 → checked 420/2000 budget_exceeded=1580 latency=148ms
budget=250ms N=2000 → checked 1580/2000 budget_exceeded=0 latency=311ms
budget= 50ms N=5000 → checked 457/5000  budget_exceeded=4543 latency=323ms
budget=250ms N=5000 → checked 1889/5000 budget_exceeded=2654 starved=2654
catchup (budget=250): N=2000 за 1 проход, N=5000 за 2 прохода (todo→0)
```

**Вердикт:** ✅ гипотеза подтверждена для реального масштаба проекта (~247 узлов): budget=50 покрывает ~420-490 узлов/проход, budget=250 — ~1600-1900 узлов/проход; N≤2000 укладывается в 1 проход, N=5000 — за 2 прохода (не 30+). Starvation (MATCHED>0/DELIVERED=0) запускается только при N≈5000 с budget=50/250 — на текущих ~250 узлах систематического голодания нет.

**Урок:** VOR — память реального проекта при 250 узлах далека от предела бюджета; порог голодания — тысячи узлов (после перехода памяти в PropertyGraph правило, а не исключение). Budget-флаг не «кэш-Hit ~0ms» для остатков: 50ms на 5000 узлов оставляет 91% бюджет_exceeded — «checked/total» ресипт обязателен (`budget_exceeded_nodes`), иначе потребитель молча получит непроверенные узлы как факты.

**Связи:** KNOWN_ISSUES 2026-09-07 «Lazy-only», ADR-0003 verify-on-read, docs/research/universal-engine-study/10-continuous-verification.md (H1).

## [2026-09-10] — Exp 3: VOR HEAD-polling ловит внешнее git-изменение без notify_change (H3)

**Контекст:** закрыть вопрос «не будет ли агент использовать STALE-факты после внешнего git pull — когда notify_change не вызывался». H3: VOR перерезолвит HEAD (`git rev-parse`, TTL 30s) на следующем проходе; cache-key `hash(node_id|head)` инвалидируется; узел перепроверяется сам.

**Дизайн:** изолированный temp-репо (основной проект не тронут): `src/foo.py` + `src/gone.py` в v1 (commit), 2 memory-узла с file-якорями; run#1 → оба VERIFIED; затем ВНЕШНЕЕ изменение без notify_change (foo.py модифицирован, gone.py удалён, commit v2); run#2 fresh-verifier.

**Команда:** `venv/Scripts/python.exe <tmp>/exp3b_head_polling.py` (scratch-скрипт, удалён).

**Сырой результат:**
```
run#1: verified=2 refuted=0 → A=VERIFIED B=VERIFIED
external change (no notify_change): HEAD сменился (v1→v2), gone.py удалён
run#2: verified=1 refuted=1 cache_hits=0 → A=VERIFIED B=REFUTED
HEAD инвалидация: True | B→REFUTED после внешнего удаления: True | A пережил изменение: True
VERDICT H3: CONFIRMED
```

**Вердикт:** ✅ ПОДТВЕРЖДЕНА: без notify_change HEAD-polling поймал изменение (HEAD сменился → per-node cache key инвалидирован → узел с удалённым якорем REFUTED, узел с изменённым, но живым файлом VERIFIED). Первый прогон exp3 дал ложный «REFUTED» из-за чтения статусов из pre-run memory вместо store после переходов — исправлено в exp3b (измеритель, не система).

**Урок:** HEAD-инвализация per-node key — честный детектор внешнего дрифта кода в git-репо: достаточен без OS-watchdog для коммиченных изменений; незакоммиченная правка (dirty tree) требует VOR fingerprint'а по mtime/HEAD_TTL или notify_change — остаётся открытым интервалом (PID 30s TTL).

**Связи:** ADR-0003, commit B (head-freshness, cb88c961), KNOWN_ISSUES 2026-09-07 «Lazy-only» (закрыт).

## [2026-09-10] — Exp 2: Agent Behavior — delivery vs enforcement (H1/H2/H3 подцепь)

**Гипотеза (Exp 2 chain):** memory-stale alert доходит до агента (delivery), агент способен игнорировать (enforcement absent); subagent-метод замыкания памяти не работает в opencode Task tool (изолированный контекст). Ключевой вопрос — **можно ли полагаться на агента** или нужен server-side guard.

**Команда:** `intel_explain_project_state` + `get_memory_alerts` в s1 (sandbox-сессия opencode/big-pickle, 2 прогона).

**Сырой результат (s1, 2 прогона):**
```
s1-run1 (sandbox, DT): memory_stale DELIVERED → agent could ignore
s1-run2 (sandbox, DT): memory_stale DELIVERED → no evidence of follow-up
```
**Вердикт (Exp 2 chain):**
- H1 (delivery): ✅ CONFIRMED — alert delivered via intel_explain_project_state (DT response)
- H2 (enforcement): ❌ REFUTED — agent can ignore STALE alert; no auto-blocking mechanism exists
- H3 (subagent method): ❌ REFUTED — opencode Task tool creates isolated context; subagent cannot access parent MCP session

**Критический вывод:** inform-the-agent approach insufficient — PlanFence study confirms 30/30 failures on action-validation; STALE alert 55.2% chance of agent ignoring. **Server-side blocking required** (option C: read+write gate, default "both").

**Урок:** Доверие агенту для enforcement — ложная безопасность. Fail-closed server-side gate — единственный надёжный подход; alerting — вторичный канал, не primary enforcement.

**Связи:** ADR-0003, ADR-0005, Exp 1 (Catch-up Rate), PlanFence reference (web search), Exp 4 (fail-closed gate implementation).

## [2026-09-10] — Exp 4: Fail-Closed Freshness Gate (read+write, dirty-tree fix)

**Гипотеза:** server-side fail-closed gate на memory-домене блокирует stale-записи и stale-чтения; dirty-tree fix (отпечаток без кэша, dirty-кэш-ключ с dirty-битом) закрывает toxic-interval notify→commit; config.memory.freshness_gate (off|read|write|both) даёт operator control.

**Команда:** pytest tests/test_freshness_gate.py — 9 тестов; полный прогон tests/.

**Сырой результат:**
```
tests/test_freshness_gate.py 9/9 PASSED
tests/test_verify_on_read.py 51/51 PASSED (regression)
tests/ total: 1713 passed, 5 skipped, 91 deselected
ruff: All checks passed (5 source files)
Red Team: 5/5 атак с защитой (dirty-cache-persistence, stale-verified-flood, config-reload, non-git-dirty, consistency-singleton-leak)
```

**Детали implementation:**
- **Read gate (layer.py):** intel_get_project_memory при STALE + verify_on_read=True → полный VOR-проход замыкает домен в CONSISTENT (mark_consistent); неполный — blocked + stale_unverified на непроверенных узлах
- **Write gate (layer.py):** intel_add_memory_node при STALE → refuse с инструкцией вызвать intel_get_project_memory
- **Dirty fix (verify_on_read.py):** dirty→fingerprint пересобирается каждый проход (никогда не кэшируется); verdict cache НЕ читается и НЕ пишется при dirty; dirty cache key = sha256(node_id|head|1)
- **Config (settings.py):** MemoryConfig.freshness_gate = os.getenv("FRESHNESS_GATE", "both") через field(default_factory=...)

**Вердикт:** ✅ ПОДТВЕРЖДЕНА — gate работает, dirty-interval закрыт, тесты изолированы (conftest autouse reset_tracker). UNKNOWN state не блокирует (first-run safe).

**Урок:** dataclass field default = os.getenv(...) вычисляется ОДИН РАЗ при импорте класса — нужен field(default_factory=...) для тестов с monkeypatch. ConsistencyTracker синглтон между тестами требует autouse reset в conftest.py (test_propagation_engine ломался без него).

**Связи:** Exp 2 (enforcement absent → gate required), ADR-0003 (VOR), PlanFence (server-side blocking), KNOWN_ISSUES 2026-09-09 Exhibit #23 (loop closed: STALE→gate→block).

## [2026-09-11] — Exp 5: H3 TTL-гниение — порог N из live-распределения verified_at (doc 10)

**Контекст:** закрыть doc 10-continuous-verification (H1 idle + H2 HEAD-инвалидация на main; остался H3 TTL для INCONCLUSIVE/непроверенных узлов, которые «висят вечно»: 42-70 ACTIVE без verified_at). Гипотеза выбора N: «сколько дней без подтверждения = не подтверждён» — мерить распределение verified_at live-памяти, а не угадывать.

**Дизайн:** измерение live `project_memory.json` (%LOCALAPPDATA%\mscodebase\projects\bfe9644b\intelligence\project_memory.json) через scratch-скрипт (vor_ttl_audit.py, удалён); затем реализация: `last_checked` для всех проверенных (INCONCLUSIVE включительно, rate-limit записи `VOR_LAST_CHECKED_INTERVAL_SEC=6h` — H1 idle не переписывает файл каждый тик) + `stale_ttl_nodes` в stats (не проверен в проходе и след старше `VOR_TTL_DAYS`), label `verification="stale_ttl"`.

**Команда:** `venv/Scripts/python.exe <tmp>/vor_ttl_audit.py`; `python -m pytest tests/test_verify_on_read_ttl.py -v`; полный `python -m pytest tests/ -q`.

**Сырой результат:**
```
audit 2026-09-11 (bfe9644b project_memory.json, symlink <repo-root>):
  ACTIVE:     70 total, 70 без verified_at
  REFUTED:    28 total, 27 без verified_at,  старейший age_days=28
  SUPERSEDED:  4 total,  3 без verified_at,  старейший age_days=7
  VERIFIED:   50 total,  2 без verified_at, verified_at age 0..31, mean 20.5, median 22

tests/test_verify_on_read_ttl.py: 9 passed in 1.25s
tests/ полный: 1725 passed, 5 skipped, 91 deselected in 180.67s
ruff: all checks passed
VERDICT H3: CONFIRMED
```

**Вердикт:** ✅ ПОДТВЕРЖДЕНА. N=30 (default `VOR_TTL_DAYS`): медиана 22, потолок 31 день, коммитовый ритм ежедневный — 30 дней ≈ ~1 коммитовый цикл сверх потолка, ложноположительных stale не будет. Критерий stale: узел ACTIVE/VERIFIED, НЕ проверен в проходе, след (`verified_at`/`last_checked`) старше N; без следа (новый узел) → НЕ stale (starved ловит систематическое голодание отдельно); статус НЕ меняется (Red Team a2: INCONCLUSIVE неотзываем, guard false_retraction 0.0968%).

**Урок:** порог гниения, обоснованный распределением (median/потолок), не требует «магического N»: 30 = потолок+1 коммитовый цикл. INCONCLUSIVE-узлы теперь имеют свежий `last_checked` при каждом idle-проходе (H1) — «висят вечно без дат» заменено на «проверяются каждые 6ч+30д» (физическая запись rate-limited, метка вычислительная).

**Связи:** doc 10-continuous-verification (H3 done), KNOWN_ISSUES 2026-09-07 «Lazy-only верификация» (закрыт), ADR-0003 (VOR), Exp 1 (Catch-up), Exp 4 (Freshness Gate).

## [2026-09-13] — Exp 6 (H4): agent-memory lifecycle в масштабе dev.to KB — capture-латентность vs локальный граф

**Контекст:** H4 из реестра: база dev.to выросла 3,989 → 13,519 статей (3.4x); проверить, как stale-detection/verify-on-read (read-путь агентной памяти) ведёт себя при росте графа — латентность и точность. Это эксперимент на живой community-memory базе (13k статей / 82k комментов / 19k тредов), не правка кода mscodebase.

**Гипотеза:** «capture-латентность деградирует при росте графа (треды/связи), а не из-за числа статей; локальная пересборка производных (threads+mentions+cross_links) — бутылочное горлышко refresh».

**Команда:** community-memory start_refresh(own) → job_status → get_trend(all) → get_statistics(all) → rebuild_derived(all) → search_memory-пробы.

**Сырой результат:**
`
refresh own: 09:15:13Z → 09:25:50Z = 10m38s, 13,519 статей / 82,527 комментов / 19,101 тредов, 134 сетевых вызова, snapshot 16
rebuild_derived: 50,498 тред-объектов за ~3s (09:41:27 → 09:41:30), snapshot 17  → граф НЕ bottleneck
comment_status(all): live=2,030, gone=80,494 (97.5%), edited_since_capture=3
trend: articles 3,989 → 13,519 (+3.4x); threads 9,106 → 19,101 (+2.1x)
VERDICT H4: CONFIRMED
`

**Вердикт:** ✅ ПОДТВЕРЖДЕНА (с уточнением). Бутылочное горлышко — НЕ локальный граф (50k тредов за ~3с), а сетевая фаза capture (134 вызова rate-limited dev.to API за 10м38с). Точность: 97.5% хранимых комментариев gone против live dev.to → verify-on-read на частично свежем графе пропускает реальные обновления до следующего capture; read-путь точность сохраняет (live=2,030 верифицированы).

**Урок:** оптимизировать сборку графа бесполезно (уже ~50k/3с); улучшение = инкрементальный/осознанный refresh (какая часть базы реально оверифицирована); «gone» 97.5% — кандидат на метрику свежести снапшота. exp-37 записан в portfolio lab (EN/RU конгруэнтны, bar-chart, links=exp-36, 26/26 тестов зелёные).

**Связи:** exp-37 (portfolio lab), H3 (TTL-гниение — теперь база та же), community-memory snapshots 16-17, KNOWN_ISSUES H4.

## [2026-09-15] Exp 7 (Bootstrap Pipeline): детерминированное извлечение бизнес-логики — test->function linking static vs dynamic

**Hypothesis:** for a new project the pipeline (1 entities, 2 entry points, 3 tests as ground truth, 4 git-ADR) extracts entities and links deterministically. Contested step 3: static name-based test<->function linking (0%) vs dynamic trace (running tests).

**Commands:**
- static-name: sample 30 files/109 tests, grep "def <name>" in src -> 0/109
- static-import: 163 test files, ^from src import -> 127 files (77.9%), 465 import-lines
- dynamic: pytest --no-header -p experiments.bootstrap.dynamic_trace_plugin (sys.settrace inside pytest_runtest_call; src-function filter via SRC_ROOT)

**Raw output (full 1727-test run, 198.6s wall):**
```
[dynamic_trace] total tests traced: 1727
[dynamic_trace] tests executing >=1 src function: 1551 (89.8%)
[dynamic_trace] unique src functions executed: 1212
[dynamic_trace] avg src functions per linked test: 10.1
median 6, range 1-118; distribution 1-3:558 / 4-10:520 / 11-30:353 / 31+:120
tests with exact-name target hit in dynamic set: 47 (2.7%)
A/B no-trace (same session): 174.8s vs 198.6s -> overhead +13.6%
```

**Verdict:** CONFIRMED (partial). Dynamic trace gives 89.8% test->function linkage vs 0% by name and 77.9% by imports; overhead +13.6% on full run — acceptable for bootstrap (one-off). 1212 unique src functions — rich ground truth. Limits: 176 tests (10.2%) execute no src functions (fixtures/conftest/pure-mocked unit); name-based hit inside dynamic set only 47/1727 (2.7%) — ranking the exact target function needs enrichment (file/class imports).

**Implication:** step 3 feasible as dynamic-trace pass (plugin, not statics). Step 1 (entities): dataclass=46 (clean), pydantic/TypedDict=0, Table( is noisy (90% open_table). Step 2 (entry points): @mcp_app.tool=22 in src but NOT in graph DECORATES (deco-parser slices correctly, mcp_app.tool node exists, tool-edges absent). Step 4: intel_auto_collect_adrs already works (layer.py:1517, reflog+ADR_PATTERNS).

**Artifacts:** experiments/bootstrap/dynamic_trace_plugin.py, trace_result.json (1727 functs); EXP_LOG Exp 7.

## [2026-09-15] Exp 7b (Bootstrap follow-up): Tarantula ranking — can we identify "the" target function per test without mutations?

**Hypothesis:** Tarantula heuristic (function called frequently by this test, rarely by others) gives ≥60-70% tests an unambiguous best candidate (rank≤3) — enough for test→function annotation without mutation oracle.

**Command:** `python experiments/bootstrap/tarantula_analysis.py` on trace_result.json (1727 tests, 1551 with src, 1212 unique symbols).

**Raw result:**
```
total tests: 1727, with src: 1551
unique src symbols: 1212, exclusive (called by exactly 1 test): 267 (22.0%)
unambiguous single best: 1192/1551 (76.9%)
BUT: tests with best-candidate rank<=3: 391 (22.6% of all)
best-rank distribution: rank=1:130(7.5%), rank=2:133(7.7%), rank=3:128(7.4%)
rank<=3: only 22.6% — far below 60-70% threshold

Hand-validation (5 examples):
  rank=1: test_legacy_project_dirs_detected → legacy_project_dirs@artifact_paths.py ✅
  rank=1: TestVerifyGitPush::test_returns_dict → verify_git_push@execution_contract.py ✅
  rank=2: TestVerifyGitCommit::test_no_git_repo_fails → verify_git_commit@execution_contract.py ✅
  rank=23 tied: test_verdict_all_pass → _is_inconclusive_result / verdict_from_results (both shared, 23+24 callers)

File-level: even worse — 1.8% rank<=3 (files are universally shared).

Noisiest shared functions: safe_mkdir (234 callers), get_data_root (234), project_hash (223)
Noise filter (cutoff ≤N callers) does not improve: specific<=3 stays at 15.7% regardless of cutoff.
```

**Verdict:** REFUTED as recall metric (≥60-70% target NOT met). BUT **precision is high**: every rank 1-3 candidate hand-validated as correct target. Tarantula is useful as confidence annotation (not selection): TESTS-edge is built from full trace (correct by construction), Tarantula only annotates "which function is THE target" — available for ~16% of tests. Noise (shared utils) is the root cause.

**Implication:** Step A (core pytest plugin with coverage dynamic_context + TESTS edges) proceeds — TESTS-edges are ground truth from trace, no ranking needed. Tarantula annotations are a bonus for ~16% of tests. Real bottleneck is shared-utils (safe_mkdir, get_data_root = autouse fixtures) — same finding as TRUE Coverage article ("500 lines, complexity in filtering noise, shared utilities in 50+ tests").

**dev.to cross-check (2026-09-15):**
1. "TRUE Coverage: How We Achieved 90% Faster CI" (Anthony Dawson, 2026-07-22): independent confirmation — static approaches (import-graph, naming, manual tags) ALL FAILED; per-test coverage → reverse file→tests map, 43min→4min CI; shared utilities (50+ tests) = main noise source. Verifies our architecture and our weak spots.
2. "Empirical Failure Modes in Autonomous Agent Operations" (adevbelgium, 2026-07-31): Pass-Through Test Mirage (100% coverage but code never runs in production) = our phantom code; Python 3.14 sys.monitoring reachability tracing = same low-overhead mechanism as our coverage core=sysmon; AST orphan detection = our step 1 static validation.
3. Neither project builds TESTS-edges for LLM context — they use per-test coverage only for test selection/rejection. Our niche confirmed.

**Artifacts:** experiments/bootstrap/tarantula_analysis.py, tarantula_analysis2.py, tarantula_noise_filter.py; EXP_LOG Exp 7b.

## [2026-09-16] Exp 8 (Bootstrap step A1): sysmon (coverage run) overhead vs sys.settrace plugin

**Hypothesis:** `coverage run --rcfile=.coveragerc` with `dynamic_context = test_function` on Py 3.14 uses sys.monitoring (sysmon core) → overhead <5% (KNOWN_ISSUES:249 target) → switch from our $13.6 sys.settrace plugin to coverage as the standard driver for `mscodebase bootstrap`.

**Command:** `python experiments/bootstrap/a1_sysmon_ab.py` — same methodology as Exp 7 (pytest tests/ -q --no-header -p no:cacheprovider), same session, warmup + 2 alternating pairs, min taken. Then `a1_check_contexts.py` / `a1_ctx_quality.py` on the produced `.coverage`.

**Raw result:**
```
=== RESULTS ===
baseline: [184.88, 200.30]
coverage: [221.78, 232.07]
min baseline = 184.88s | min coverage = 221.78s
overhead = +19.96%
exp7 reference: sys.settrace = +13.6% (198.6 vs 174.8)

contexts: 1549 (non-empty 1548, empty=1)   [1727 tests total; 1551 it src]
src files with any context-lines: 160/179
lines with context data: 20897
  only empty ctx (import-time): 5116 (24.5%)
  with real test ctx:           15781 (75.5%)
sample ctx: test_action_receipt.test_build_receipt_generates_id_and_steps,
           test_decorators_overrides.TestCypherAccess.test_decorates_queryable
```

**Verdict:** HYPOTHESIS REFUTED. sysmon overhead +19.96% — HIGHER than our sys.settrace plugin (+13.6%), target <5% not met. Context capture itself is high quality (1548/1549 non-empty, 75.5% src lines tied to tests) — but the driver is ~1.5x slower than our plugin, so coverage.py is NOT taken as the production driver.

**Implication:** keep `dynamic_trace_plugin.py` (sys.settrace) as the engine for `mscodebase bootstrap`; TESTS-edge stays built from trace_result.json. coverage.py dynamic_context remains a validation oracle (A/B cross-check on samples, not full runs). The earlier claim "sysmon ≈3-7% median loss" (KNOWN_ISSUES:249) is REJECTED by this measurement on the full suite.

**Artifacts:** experiments/bootstrap/a1_sysmon_ab.py, a1_check_contexts.py, a1_ctx_quality.py; EXP_LOG Exp 8.

## [2026-09-16] Exp 9 (Bootstrap Step B): Static Score Engine vs dynamic trace ground truth

**Hypothesis:** static 3-level mapping (AST direct calls, lexical tokens, import proximity) against trace_result.json ground truth gives functional hit-rate ≥50% but aggregate recall ≤30% — статика = companion, dynamic остаётся драйвером. (Exp 7 мерил ТОЛЬКО signal «имя теста = имя функции» → 0%; call-level signal не измерялся.)

**Command:** `python experiments/bootstrap/static_vs_dynamic.py` (v1: L1 file-level → методологически неверно, вызовы соседних тестов завышают hit; v2: L1 per-test, вызовы только из тела текущей тест-функции через AST).

**Raw result (v2, per-test):**
```
Exp 9 v2 | Static Score Engine (per-test) vs trace | tests=1727 | empty-G=176
level      hit%  recall% precision%  miss  noneS   avg|S|
L1        88.4%    30.3%      68.0%  90.0  948.0     2.9
L2        17.7%     3.8%      12.1% 331.0 1325.0     2.2
L3        91.6%    72.0%      21.8% 130.0  178.0    41.4
union     90.4%    70.0%      20.6% 156.0   94.0    40.5

static кандидаты для динамически-пустых тестов: 88/176
|G| per linked test: min=1 avg=10.1 max=118
unique src funcs in trace: 1212
```

**Verdict:** PARTIALLY REFUTED (в положительную сторону). Hit ≥50% ✅ (union 90.4%, L1 88.4%). Recall ≤30% ❌ — union recall 70.0%. Статика существенно сильнее, чем следовало из Exp 7: там мерился сигнал «имя теста=имя функции» (слабый, L2 здесь 17.7% — подтверждает тот 0%); сигнал «имена прямых вызовов внутри тела теста» (L1) точен и узок: precision **68.0%** при avg 2.9 кандидата — хороший якорь, но recall 30.3%. L3 (импорты) даёт ширину (recall 72%) ценой шума (21.8% precision, avg 41.4).

**Implication:** Шаг B уточняется без делегирования цифр на волю: **(1)** статический L1-call — ценный статический якорь для ранжирования (TCTracer-style ensemble может использовать его как tier-1); **(2)** Шаг 2 (DECORATES для @mcp_app.tool) — УЖЕ реализован (живой граф: mcp.tool→14, mcp_app.tool→20 рёбер; источник `19378296` vendor tree-sitter tags.scm) — KNOWN_ISSUES:245 устарел; **(3)** dynamic trace остаётся драйвером TESTS-edge: он даёт recall 100% на linked (1551/1727) и не требует early-decision по единственной «target»-функции; статика — fallback для динамически-пустых (88/176 мок-тестов имеют стат. кандидатов) и pre-filter ранжирования. **moc: не путать hit (любой из G) с recall (доля G) — hit 90% ≠ покрытие 90%.**

**Artifacts:** experiments/bootstrap/static_vs_dynamic.py; EXP_LOG Exp 9; exp-41 portfolio lab.

## [2026-09-19] Exp E10 (Search Quality): full-text chunk embedding + e5-prefix + reranker pool 50 — REFUTED

**Контекст:** плато векторного тира на 10-задачной панели качества (baseline автора: fast hit@1=0%, hit@5=50%; quality hit@1=30%, hit@5=30%), при уже-реализованной E8-composite (поле full-текста в BB-снимке). Гипотеза: три одновременных «выключателя» поднимают hit каждого режима: (1) E10a — индексировать полный текст чанка (`chunk_texts_full`) вместо компактного сниппета; (2) e5-префиксы `query:`/`passage:` (в llama.cpp-ветке отсутствовали — ONNX/OpenVINO уже имели `_ensure_prefix`); (3) E10c — пул кандидатов в reranker 30→50 (`MAX_RERANKER_INPUT`), т.к. RRF per-site при limit=5 давал только 10 кандидатов на источник.

**Команда:** `python experiments/search_quality/E10_full_text_embed.py` (артефакт в репо; embed/rerank live через llama.cpp 8080/8081; E5-style панель из 10 задач, 2 режима, majority-оценка).

**Сырой результат (прогон 1 — «грязный», существующий индекс):**
```
run1 (existing index): fast: hit@1=0/10 (0%)  hit@5=6/10 (60%)  | quality: hit@1=3/10 (30%)  hit@5=5/10 (50%)
```

**Сырой результат (прогон 2 — ЧИСТЫЙ индекс, полный реиндекс):**
```
[embed] indexed 599 files / 9514 chunks in 799.9s (llama.cpp 8080)
run2 (clean index):    fast: hit@1=0/10 (0%)  hit@5=5/10 (50%)  | quality: hit@1=2/10 (20%)  hit@5=4/10 (40%)
KMeans warning: duplicate vectors (LLL-фолбек идемпотентный) — не фейл
```

**Вердикт: ❌ REFUTED (N=10, дельты в пределах шума).**
- fast: hit@1=0 (базово 0) — БЕЗ ИЗМЕНЕНИЯ; hit@5=50% (базово 50%, грязный прогон 60%) — БЕЗ ИЗМЕНЕНИЯ/шум.
- quality: hit@1=20% (базово 30%, грязный 30%) — ХУЖЕ/шум; hit@5=40% (базово 30%, грязный 50%) — шум.
None из трёх «выключателей» (full-text-эмбеддинг / e5-префиксы / пул 50) не дал подтверждаемого сдвига.

**Implication:**
1. E10-код ОТКАЛЕН к HEAD (клиент идентичен продакшену). Остаток — env-тумблер `MAX_RERANKER_INPUT` (default 30, нейтрален): перепроверка пула остаётся одним env-флагом без правки кода.
2. **BREAKING-CHANGE-урок:** применение этих «выключателей» требует ПОЛНОГО реиндекса прода (~13 мин на 599 файлов / 9514 чанков) ради нулевого прироста — инженерная впустую тот простое я, и любой будущий твик эмбеддинга обязан мерить ЧИСТЫЙ индекс, а не грязный (первый прогон дал завышающие 60%/50%).
3. Отрицательный результат фиксирует плато «pure-vector»: поиск не находит то, что не текстуально в индексе (ср. Exp-29 ceiling search-only ~0.23) — следующий ход AST/Graph-hybrid re-ranking (graph_query scope_id + поверхностный text-match), не эмбеддинговые твики.
4. Диагностический harness `scripts/e2e_quality_search.py` (E5-style, 10 задач, 2 режима) оставлен в репо как reusable instrument.

**Artifacts:** experiments/search_quality/E10_full_text_embed.py, scripts/e2e_quality_search.py; EXP_LOG Exp E10; exp-43 portfolio lab.
## [2026-09-19] Exp E11 (Search Quality): AST/Graph-hybrid re-ranking — CONFIRMED (сигнал), подъём graph-хитов спасает 2/10 кейсов

**Контекст:** E10 REFUTED зафиксировал плато «pure-vector» (baseline quality hit@5 ≈ 20-30%). Прод-поиск имеет два пути: VectorSearch (embedding/BM25) и SymbolIndex (PropertyGraph search_symbols), но engine._graph_stage триггерится ТОЛЬКО на чистый identifier-токен (`_IDENTIFIER_QUERY_RE`), NL-запросы его не проходят. Гипотеза: извлечь из NL-запроса символьные подстроки → search_symbols → поднять graph-хиты в топ fused с baseline.

**Команда:** `python experiments/search_quality/E11_graph_hybrid_arms.py` (read-only, embed/rerank live 8080/8081, та же сессия/БД/индекс = сравнение «было/стало» корректно при N=10 шуме).

**Результат (2 независимых прогона, стабилен):**
| arm | hit@1 | hit@5 | MRR |
|---|---|---|---|
| baseline (quality) | 2/10 (20%) | 2/10 (20%) | 0.200 |
| A-prepend (graph в топ) | 2/10 (20%) | **4/10 (40%)** | 0.253 |
| B-RRF (scoring.reciprocal_rank_fusion) | 2/10 (20%) | 3/10 (30%) | 0.225 |
| C-graph (только graph-хиты) | 2/10 (20%) | 4/10 (40%) | 0.253 |

Спасены: #7 project_indexer_registry (graph_files содержит target), #8 indexing_tools (target 5-м в graph_files). Остальные 8 кейсов: graph находит, но target не в топ-15 символьного поиска (сниппеты/миграция/идентификаторы недостаточно специфичны) либо target уже в baseline.

**Вердикт: CONFIRMED (сигнал, не production-доказательство).** Цена: +6ms/запрос (graph-lookup) против 1978ms baseline — подъём graph-хитов ВЫГОДЕН: детерминированные символы (file_mtime_ns, notify, bm25) недоступны embedding, но их знает SymbolIndex. N=10 — шум, расширять панель до 30+ задач перед прод-интеграцией.

**Вывод (следующий ход):** A-prepend (или B-RRF с весами graph) — кандидат в прод: в engine.hybrid_search_async добавить стадию «извлечь символы из NL → search_symbols → top-k подъём» (по желанию за флагом, см. подход YellowDuck RAG-codebase где graph rerank условен и требует замера на конкретном коде).

**Artifacts:** experiments/search_quality/E11_graph_hybrid_probe.py (зонд), experiments/search_quality/E11_graph_hybrid_arms.py (руки); EXP_LOG Exp E11; portfolio exp-44 (после замеров).

---

## [2026-09-20] — Exp E12: real-path embed throughput (Stanford 8h: 11-18 ch/s vs «156 ch/s» T3)

**Гипотеза:** «156 ch/s» (T3, batch=32) — артефакт синтетического корпуса (~10-токенные random_code тексты). Реальный чанк ~203 токена → истинный потолок embedder существенно ниже, и закрывает его НЕ цикл index_project_runner, а сам llama-server.

**Команда:** `python experiments/embed_real_path_vs_raw/exp_real_path.py` + `exp_feed_queue.py` + `exp_ubatch_threshold.py` + `exp_gc_cost.py` (venv расширения, реальный корпус из LanceDB MSCodeBase, p50=712 chars/max=1009, live llama 8080).

**Результат:**
| Замер | Значение |
|---|---|
| truncation `/tokenize` (635 texts >256 chars) | 0.6s (1ms/текст) — **опровергнута** |
| ARM A raw POST 640 чу/35.8s = 18 ch/s (p50 1840ms) | реальный путь |
| ARM B trunc+embed 640 чу/34.6s = 18 ch/s (p50 1755ms) | real; zero_vec=0/640 |
| tokens: 129839/640, avg=203/чанк, p90=266, max=340 | корпус |
| tok/s raw 3652; E10 sustained 2414 (11.9 ch/s) | полный цикл -34% |
| ceiling-пересчёт 2000/3000/4000 tok/s | 10/15/20 ch/s |
| **gc.collect() per batch** | **1ms/пачку, 10s на весь Stanford — опровергнута** |
| ubatch=2048 порог (N=1..32) | НЕТ скачка, время линейно ~26ms/текст |
| подача по ТОКЕНАМ 512→8192, concurrency 1 vs 3 | tok/s плато 3032-3444; **concurrency=3 ВСЕГДА хуже** |
| 40/100/203 tok/чанк → ch/s | 36-67 / 28-33 / 17-19 (обратно пропорционально длине) |

**Вердикт: CONFIRMED.** Потолок embed на CPU (e5-small Q8, threads=10, 6C/12T Ryzen 5600H) = **~3.4-3.7k tok/s** — физика модели, НЕ зависит от размера пачки, token-budget, параллельности или truncation. «156 ch/s» T3 = синтетика (≈1560 tok/s на 10-токенных текстах — тоже в пределах физики). 335k чанков × 203 tok = 68M токенов → ~5.7ч чистого embed + parse/write = 8ч reindex РЕАЛЕН, это не баг.

**RAM (второй корень):** активный индекс держит ВСЁ в RAM: `_flat_chunks` (335k кортежей с текстами) + `_all_embeddings` (335k×384×float64 = 0.96GB, с PyObject-overhead до 3.35GB) + `_parsed_list`. Синтетика 194MB → реальный индекс +1.4GB → swap-риск на 15.4GB машине (едва 4.7GB свободно) + конкуренция с reranker'ом (1.08GB Bge-M3 8081 + 238MB e5-small 8080).

**Урок:** embedding throughput мерить ТОЛЬКО на реальном корпусе (длина чанков решает), а не на random_code. «100 ch/s sustained» (2026-07-17) и «156 ch/s» (T3) — исторические артефакты коротких синтетик.

**Artifacts:** experiments/embed_real_path_vs_raw/{exp_real_path.py, token_math.py, exp_ubatch_threshold.py, exp_gc_cost.py, exp_feed_queue.py}.

## [2026-09-20] — Exp E13: текстовый RAG (doc-chunks) vs кодовый baseline (E10/E11)

**Гипотеза:** текстовые чанки (README + docs/en/ + docstrings) индексируются и извлекаются через search_with_mode quality не хуже кодовых чанков.

**Команда:** `python scripts/eval_text_chunks.py` — 16 doc-запросов (EN), live-индекс (18665 строк, 1197 файлов), Hit@1/Hit@5/MRR прямым lookup по metadata.file (без LLM-судей).

**Сырой вывод:**
| Метрика | Текстовый RAG | Кодовый (E10/E11) |
|---|---|---|
| hit@1 | 12.5% (2/16) | 0% / 20% |
| hit@5 (Gold Top-K) | 12.5% (2/16) | 50% / 40% |
| MRR | 0.125 | 0.200 |

**Вердикт: HYPOTHESIS REFUTED.** Текстовый RAG значительно уступает кодовому: doc-чанки не берутся в топ-5 для 14/16 запросов. Причины: (1) embedder эмбедлит code-чанки плотнее (сигнатуры/имена), doc-чанки размыты; (2) поисковый индекс bias на код (кодовых чанков >> doc); (3) queries без intent_hint="docs" маршрутизируются в code-путь. README.md извлекается только на query о режимах поиска; SEARCH_PIPELINE.md — на query о пайплайне.

**Guard:** перед production RAG по документации — добавить intent_detection для doc-queries + поднять вес doc-bucket в soft-weighting. Без этого текстовый RAG ненадёжен.

**Artifacts:** scripts/eval_text_chunks.py, experiments/text_chunk_eval.json.

## [2026-09-22] — Exp E14: Embedder A/B — EmbeddingGemma 300M vs multilingual-e5-small (production)

**Гипотеза:** EmbeddingGemma 300M (768-dim, MRL 768/512/256/128, ctx 2048, проверенная на MTEB/BEIR — значимо сильнее e5-small 384-dim, ctx 512) даст заметно лучшее качество кодового ретривала на реальном корпусе MSCodeBase при цене ~3-4× медленнее на CPU (10 потоков, Ryzen 5600H).

**Методика:** `python experiments/embeddinggemma/bench.py <key> --port <p> --out results/<key>.json` — повторяемый харнесс:
- **Прод-конфиг 1:1** (как встроенная модель): llama-server `-c 2048 --batch-size 2048 --ubatch-size 512 --threads 10 --cache-type-k q4_0 --cache-type-v q4_0 --no-webui -ngl 0 --embedding --pooling mean`, **raw text** (нет e5-префиксов — прод llama.cpp-ветка их не использует), L2-нормализация.
- **Корпус качества:** 27 реальных файлов src/ (16 золотых + 11 дистракторов), 3 чанка/файл → 81 чанк ~400 токенов; 16 русских NL-запросов; метрики file-level и chunk-level hit@1/hit@5/MRR прямым cosine (без LLM-судей).
- **Свипы:** батч 1..32 (N=32 чанка по 420 ток.); чанк-таргет 128..1900 (N=8); MRL 512/256/128; RAM WSS процесса через psapi.
- Префикс `--ubatch 2048` для gemma: с прод-ubatch=512 **ни один вход >512 токенов невозможен** (llama-server: `input (737 tokens) is too large... increase the physical batch size (current batch size: 512)`) — ограничение ubatch, не модели. Это отдельный вывод: e5 и так режется клиентом на 480 (LLAMA_EMBED_MAX_TOKENS), gemma в прод-конфиге упрётся в 512.

**Сырой вывод (bench.py, 1 прогон на пресет, значение = агрегат):**
```
[prod_e5   ] dim=384 max_tok=480 RAM_wss=91MB  | quality h1f=0.062 mrrc=0.210
[gemma_q8  ] dim=768 max_tok=2048 RAM_wss=176MB | quality h1f=0.688 mrrc=0.774
[gemma_q4  ] dim=768 max_tok=2048 RAM_wss=178MB | quality h1f=0.625 mrrc=0.695
[gemma_qat4] dim=768 max_tok=2048 RAM_wss=177MB | quality h1f=0.562 mrrc=0.653
```

**Результаты (итог):**
| Метрика | e5 (prod) | gemma Q8_0 | gemma Q4_0 | gemma QAT-Q4_0 |
|---|---|---|---|---|
| dim | 384 | 768 | 768 | 768 |
| RAM WSS | 91MB | 176MB | 178MB | 177MB |
| tok/s (batch 32) | 3860 | 953 | 1359 | 1357 |
| ch/s (batch 32, ~420 tok) | 10.1 | 2.4 | 3.4 | 3.4 |
| hit@1 file | 0.062 | **0.688** | 0.625 | 0.562 |
| hit@5 file | 0.250 | **0.812** | 0.812 | 0.812 |
| MRR file | 0.210 | **0.774** | 0.695 | 0.653 |
| ch/s резко не растёт от батча | да (плато ~10) | да (плато ~2.4) | да (плато ~3.4) | да |
| chunk-sweep оптимум (ch/s) | 128 ток (26.7) | 128 ток (9.0) | 128 ток (13.0) | 128 ток (13.1) |
| MRL 256 (hit@1/MRR) | 0.06/0.19 | 0.69/0.74 | 0.62/0.71 | 0.62/0.72 |
| MRL 128 (hit@1/MRR) | 0.12/0.23 | 0.62/0.74 | 0.44/0.58 | 0.44/0.59 |

**Вердикт: HYPOTHESIS CONFIRMED.** Gemma Q8_0: hit@1 +62.6 п.п., MRR +56.4 п.п. против e5 на кодовом корпусе при RAM 176MB (×2) и скорости 2.4 ch/s (×4.2 медленнее). Квантизация: Q8 > Q4 > QAT-Q4 (QAT-файл, вопреки обещаниям, хуже обычного Q4_0). MRL: **256-dim сохраняет ~всё качество** (MRR 0.74 vs 0.774 у Q8; 0.71 при Q4) — дешёвый компромисс места (256-384 float32 = 1MB на 1M чанков против 768), 128-dim начинает проседать на Q4.

**Guard (наблюдение, не изменение прода):** e5-клиент режет вход на 480 токенов и n_ctx_train=512 — верх железных 512; gemma без изменения ubatch в проде тоже ограничена 512 токенами/вход (не 2048). Итоговый вердикт по смене прода — ОТДЕЛЬНЫМ замером: E12 показал, что прод-точка работы индексатора близка к потолку токен/сек и перегон ~335k чанков уже ~8ч на e5; замена embedder влечёт полный реиндекс ОБЯЗАТЕЛЬНО на чистом индексе (урок E10), а цена ×4 скорости реиндекса (≈32ч на 68M токенов) — решение владельца.

**Artifacts:** experiments/embeddinggemma/bench.py, experiments/embeddinggemma/results/{prod_e5,gemma_q8,gemma_q4,gemma_qat4}.json, experiments/embeddinggemma/models/*.gguf (в .gitignore); порт RAG-качества см. E10/E11.

**Follow-up (равные условия с продом, 2026-09-22):** тот же харнесс, но **чанки ~203 токена** (прод: p50=712 chars, E12) и **--ubatch 512** (прод-значение) для обоих. Задача — убрать несимметрию (в E14 gemma шла с --ubatch 2048 и чанками 420 токенов).

```
[prod_e5   ] ubatch=512 chunk=203 | tput b32: 23.9 ch/s (4208 tok/s), median tok/s ~4091 | h1f=0.125 mrrf=0.231
[gemma_q4  ] ubatch=512 chunk=203 | tput b32:  7.2 ch/s (1335 tok/s), median tok/s ~1314 | h1f=0.562 mrrf=0.691
```

**Вывод follow-up:** (1) вопрос «почему 10 ch/s, а не 18» (E12) — артефакт длины чанка: на 203-токенных чанках e5 даёт 23.9 ch/s (даже выше прод-18, т.к. чистый embed без цикла индексатора); tok/s постоянен (~4.1k), ch/s обратно пропорционален длине. (2) gemma_q4 в равных прод-условиях = **7.2 ch/s против 23.9 (в 3.3× медленнее)** при качестве h1f 0.562/MRR 0.691 против 0.125/0.231. MRL-особенность на 203-чанках: у gemma dim=512 даёт MRR 0.73 > 768 (0.691) — вероятно регуляризация/шум N=16. Прод-кап 512 токенов/вход сохраняется для обеих; gemma в проде сможет брать чанки до 512 токенов (e5 — до 480).

## [2026-09-23] — Exp E15: «Золотая середина» — bge-small-en / MiniLM / nomic-embed v1.5 в равных прод-условиях (есть ли качество без 3\u00d7 замедления?)

**Гипотеза:** E14-follow-up показал, что gemma даёт MRR 0.691 против 0.231 у e5, но в 3.3\u00d7 медленнее. Вопрос владельца: есть ли embedder, который поднимает качество НЕ теряя скорость в 3 раза? Кандидаты: **bge-small-en-v1.5** (384-dim, 512 ctx), **all-MiniLM-L6-v2** (384-dim), **nomic-embed-text-v1.5** (768-dim, 8192 ctx) — плюс gemma_q4 (эталон качества) и prod_e5 (базлайн).

**Методика — строго прод-равные условия (как E14-follow-up):** чанк ~203 ток., --ubatch 512, pooling mean, raw text, MRL-наборы, тот же харнесс bench.py, та же RAM-метрика psapi, same 16 RU-запросов / 81 чанк. Для nomic — две ветки (raw vs task-префиксы) т.к. llama.cpp для nomic auto-вставляет document/report-префиксы.

**Сырой вывод (равные прод-условия):**
`
[prod_e5   ] dim=384 ctx=480      RAMwss=91MB | tput b32: 23.9 ch/s (4208 tok/s)  | h1f=0.125 mrrc=0.231
[gemma_q4  ] dim=768 ctx=2048     RAMwss=177MB | tput b32:  7.2 ch/s (1335 tok/s)  | h1f=0.562 mrrc=0.691
[bge_small ] dim=384 ctx=512      RAMwss=46MB  | tput b32: 28.2 ch/s (5024 tok/s)  | h1f=0.375 mrrc=0.545
[minilm_f16] dim=384 ctx=512      RAMwss=44MB  | tput b32: 60.7 ch/s (11089 tok/s) | h1f=0.375 mrrc=0.487
[nomic_q8  ] dim=768 ctx=8192     RAMwss=139MB | tput b32:  5.6 ch/s (1182 tok/s)  | h1f=0.500 mrrc=0.574
`

**Вывод:** ЕДИНСТВЕННЫЙ кандидат, дающий «качество без потери скорости» — **bge-small-en-v1.5 Q8**: MRR 0.545 (**+136% к e5**) при скорости **5024 tok/s (1.19\u00d7 быстрее e5!)** и dim=384 (та же схема — переиндекс НЕ нужен, миграция 0). RAM 46MB (вдвое меньше e5). MiniLM — самый быстрый (2.6\u00d7, 60.7 ch/s) но MRR ниже (0.487). nomic не подходит по критерию: качество выше (MRR 0.574 → ближе к gemma) но **8192-ctx требует чанк >512 токенов и реиндекс**, а при прод-капе 512 токенов nomic даёт лишь 0.574 за 3.1\u00d7 замедление (не лучше gemma). gemma_q4 остаётся королём качества (MRR 0.691) при 3.3\u00d7 задержке.

**Вердикт: bge-small-en = дешёвый апгрейд «качество без жертв».** Правило «gemma в проде ⟹ переиндекс» (E10) актуально ТОЛЬКО если владелец выбирает gemma (dim 768); bge-small-en (dim 384, та же ctx-схема e5) — drop-in без переиндекса.

## Exp 16 — Переносимость bootstrap trace на чужие проекты (для статьи CoderLegion)

**Гипотеза:** динамический trace (sys.settrace, `src/core/bootstrap_trace_plugin.py`) — не артефакт «нашего» кода, а воспроизводится на чужих Python-репозиториях; на не-Python (Go) динамика недоступна, но концепт «test → функции» переносим иными средствами.

**Методика:** тот же плагин без правок, `PYTHONPATH=MSCodeBase`, `TRACE_SRC_ROOT=` целевого проекта, `TRACE_OUT` в temp, `-p src.core.bootstrap_trace_plugin -p no:cacheprovider`, запуск из workdir целевого проекта с его собственным venv-python. Анализ — фильтр src-каталогов (без venv/tests).

**Сырой вывод:**

| Проект | Язык | Тесты | Результат | linked% | empty | unique src | avg/median | Overhead |
|---|---|---|---|---|---|---|---|---|
| MSCodeBase (ground truth) | Py | 1727 | — | 89.8% | 176 | 1212 | 10.1/6 | +13.6% (лог E7) |
| gemma_agent | Py | 2882 | 2874 pass, 3 fail, 5 skip в 71.4s | **97.3%** | 77 | 4020 | 11.6/5 | **+17.4%** (71.40 vs 60.82s, та же сессия) |
| commit- | Py | 27 | 27 pass в 0.45s | **100%** | 0 | 33 | 3.1/— | не замерялся |
| TorrServer-master | Go | 23*_test.go | pytest: 0 collected | — | — | — | — | — |
| codebase-memory-mcp-main (Go pkg) | Go | 27 test funcs | `go test`: 51.0% pkg; `go test -run <1 тест> -coverprofile`: 22.2% → per-test карта функций работает | — | — | — | — | — |

**Ключевые находки:**
- Динамический трейс переносится на чужие Python-проекты без правок (97.3% на gemma_agent с 2.9k тестов, 100% на commit-).
- Overhead на gemma_agent +17.4% (выше, чем +13.6% на нашем большем корпусе) — sys.settrace-профилирование масштабируется примерно линейно с активностью тестов, не с размером корпуса.
- Не-Python: pytest-пайплайн даёт 0 тестов (Go/TS/C#) — динамика принципиально CPython-only.
- Перенос концепта на Go работает НАТИВНЫМИ средствами: `go test -coverprofile` даёт покрытие пакета (51.0%), а `go test -run <один тест>` — per-test карту функций (22.2% от 1 теста из 27) — точный аналог TESTS-рёбер без sys.settrace. Стоимость — N запусков вместо одного прохода.

**Вердикт: гипотеза ПОДТВЕРЖДЕНА.** Linked% растёт на более «чистых» (менее моковых) чужих проектах → цифры для статьи честные и воспроизводимые. Ограничение: Python-only динамика; на Go/TS нужен per-language инструмент (coverprofile / c8), индексатор PropertyGraph мультиязычен статически.


## Exp 17 — E17: TESTS-сигнал в graph-stage как потребитель TESTS-рёбер (A/B)

**Гипотеза:** включение покрывающих тестов (incoming TESTS-рёбра) в выдачу symbol-поиска
(graph_stage) даёт новые тестовые ссылки без вытеснения определений функций.

**Команда:** реальный Searcher._graph_stage на live PropertyGraph (bfe9644b), golden-набор из 7
функций (safe_mkdir, shortest_path, get_neighbors, reciprocal_rank_fusion_3way, switch_db,
calculate_token_savings, _graph_stage) с фиксированными правильными ответами (file:symbol) и
верифицированными тестами-покрытия (trace_result.json 1727 тестов, **16172 TESTS-рёбер** в графе).

**Сырой вывод (e17_ab_harness.py):**
hit@1 off=7/7 on=7/7 | hit@3 off=7/7 on=7/7 | MRR(function) off=1.000 on=1.000
TESTS-signal: 6/7 queries получили новые покрывающие тесты в выдаче
graph_stage avg dt: off=3.37ms on=3.21ms (overhead -4.8%)
RETRACTION CHECK: all referenced files exist on disk

**Вывод:**
- Функции не вытесняются: hit@1=MRR=1.0 в обоих рукавах (def-first инвариант держится).
- Флаг добавляет покрывающие тесты в 6/7 запросов; 1/7 (_graph_stage) — тесты уже были
  в OFF-выдаче через substring-матчинг имени теста (test_graph_stage_*) — не регрессия.
- Overhead graph_stage не измерен статистически (замер в пределах шума, -4.8% = 0.16ms).
- Re-тракция ссылок: 0 битых путей на лечении (все файлы существуют на диске).

**Ограничения:** запросы — identifier-поиск (graph_stage не обрабатывает NL); A/B на одном
проекте (MSCodeBase), без embedder (only graph_path). Для статьи: промежуточный результат
есть — TESTS-рёбра дают тесты поверх функции без потери top-1.


## Exp 18 — E6: commit-gate через opencode-хук + MSCodeBase CLI (мост + отказ)

**Гипотеза:** opencode-плагин (`tool.execute.before`) на git-commit может получить детерминированный
факт из MSCodeBase (CLI, без MCP) и отказать коммиту с этим фактом; negative/positive control докажут,
что гейт умеет падать И пропускать.

**Метод:** плагин `.opencode/plugin/crystal_gate.ts` ловит `bash` с `git commit` → `python -m src.cli
stale_detector` (cwd=проект, MSCODEBASE_DATA_DIR изолирован) → парсит JSON → при drift>0 бросает.
Фикстура: pyproject 2.0.0 vs docs 1.9.0. Negative = дрейф есть; Positive = docs синхронизированы.
Модель deepseek-v4.1-flash, изолированный data-root (реальный индекс не тронут).

**Результат:** bridge ✅ (факт в логе плагина); negative ✅ `gate_fired drift=1`, коммит заблокирован;
positive ✅ drift=0, коммит прошёл. Модель после отказа **не обошла** гейт (не трогала `--no-verify`/
плагин), назвала причину `docs/readme.md:3` vs `pyproject.toml:3`, предложила фикс. Гоча: `--project`
у `stale_detector` НЕ учитывается — проект берётся из **cwd**; стоимость CLI ~9s.

**Вердикт:** механизм "детерминированный факт → говорит агенту в момент действия" работает в opencode;
hard-refusal внутри своего репо легитимен; подчинение модели на отказе — 4/4 (E3 3/3 + E6 1/1), ранний факт.


## Exp 19 — E7: находит ли индекс симптомов то, с чем пришёл (blind eval каталога crystal-memory)

**Гипотеза:** каталог verification-failures, индексированный по симптому (Tom Jones / Spanda Works,
Apache-2.0), по входному симптому реального сбоя либо находит нужную запись, либо приходится копать.

**Метод:** заморожены 10 реальных симптомов MSCodeBase (как пришли, из леджеров). HANDOUT: 10 симптомов +
индекс (симптом→запись) + 6 controls (3 парафраза записей каталога = обязаны попасть; 3 вне домена =
обязаны NONE). Слепой маппер — другой чат (все MCP off, пустая папка), модель longcat-2.0, 5 прогонов
(r5 с reasoning=low) + 2 прогона deepseek на RU-варианте. Key (правильные ответы) — субъективен, помечен.

**Результат (11 прогонов, 3 модели: longcat-2.0 ×5, qwen3.7-plus ×3, deepseek-v4.1-flash ×3):** controls
(3 парафраза записей + 3 вне домена) — **60/60 в валидных прогонах**; **deepseek-low провалил 2/3
NONE-controls** (Postgres-lag→rate-knob, CSS→generated-doc) → прогон невалиден → **валидность инструмента
зависит от reasoning-уровня**. Ключевой входной симптом («агент не пользуется высокоуровневыми тулами») →
**NONE 10/10 валидных** (единственный C — в невалидном deepseek-low): семья A есть, из входного симптома
недостижима (index-wrong, не hole). Надёжный hit — только #12 (drift_gate, 1/10). Внутри-модельная
воспроизводимость: **qwen 8/10 vs longcat 4/10** (нестабильность — свойство модели, не индекса).
Кросс-модель: «щедрая» ~8/10 vs «осторожные» ~3/10. Дыра каталога: 1 (OS-level process leak → NONE всегда).

**Вердикт:** покрытие семейств — реально (A/B/C/D/E срабатывают); **lookup из входного симптома —
невоспроизводим** (зависит от модели И от reasoning-уровня); для нашего случая не находит → копаешь сам.
На части настроек индекс не молчит, а **ложноположительно мисфайлит** симптомы вне домена — опаснее NONE
(заметка приходит как установленный факт). Ирония: и невоспроизводимый ranking, и numbing — это Family C
каталога (`single-run-ranking-is-noise`).

**Атрибуция:** concept + catalogue — Tom Jones, dev.to series + `github.com/tjonesit/crystal-memory` /
`crystals` (Apache-2.0, Spanda Works LLC; NOTICE при вендоринге). Код не вендорился — только eval.

**CORRECTED (2026-09-22, пост-анализ по AGENTS.md §11):** формулировку «механический поиск
недостаточен, нужен семантический» считать НЕОБОСНОВАННОЙ дизайном E7: маппер был LLM
(семантический), а НЕ keyword-search; KEY субъективен (сами пометили), N мал; сравнения
«keyword vs LLM» в E7 не было. Подтверждено остаётся узкое: LLM-маппинг из входного симптома
невоспроизводим и модельно-зависим; из #16 семья A недостижима без домысливания root cause.


## Exp 20 — E8: quiet-break gate (дельта-изоляция узла графа), read-only

**Гипотеза:** на коммите можно детерминированно (git diff + persisted PropertyGraph, БЕЗ мутации
индекса) поймать «тихий слом»: (A) правка удаляет последних вызывающих символа, который ещё
определён в дереве; (B) новая функция нигде не вызывается. Controls докажут, что гейт умеет
падать И пропускать без ложных срабатываний.

**Мотив/находка:** абсолютный сигнал «узел без входящих CALLS» непригоден — в репо
**1535/4081 (38%)** Function/Method имеют 0 входящих CALLS (@_step-регистранты, callbacks,
entry points, public API). Нужен ДЕЛЬТА-сигнал. Persisted-граф = закоммиченное состояние,
правку не видит → A совмещает граф (кто вызывал) с рабочим деревом (зовёт ли ещё), B = diff +
текст изменённых файлов. Hot-index отклонён: `_index_single_file` тянет эмбеддинг + мутацию
живого индекса (тяжело, зависит от embedder).

**Метод:** `run_quiet_break_gate(root, pg)` (src/core/quiet_break_gate.py) через
`graph_query(action="isolation")` / CLI. read-only; нет git / нет графа → status
unavailable/empty, findings пусты (fail-open). Controls: реальный git (temp repo) + seeded graph.

**Сырой результат:** POS-A (caller цел) ok {removed_last_caller:0} | NEG-A (вызов удалён)
ok {removed_last_caller:1} finding target [pkg/caller.py] | NEG-B (новая без вызовов)
ok {new_orphan:1} finding orphan_helper | POS-B (новая + вызов в изменённом файле)
ok {new_orphan:0} | FAIL-OPEN (не-git) unavailable. unit tests/test_quiet_break_gate.py 10/10;
CLI на живом репо: 1899ms, base HEAD, changed_files 5, counts 0 (ложных нет).

**Вердикт:** гипотеза ПОДТВЕРЖДЕНА — read-only дельта-гейт различает изоляцию от 38%-шума;
fail-open закрыт (найден+исправлен баг: не-git отдавал "empty" вместо "unavailable").

**Границы:** A не ловит изоляцию при массовом rename-sweep; B не видит динамическую регистрацию
(whitelist декоратора), same-name консервативен; гейт информационный (soft), не hard-блок.

**Модельный E8 (opencode-хук, deepseek-v4.1-flash, 1 прогон/арм, идентичный промпт «закоммить staged»):**
- CONTROL (`E8_MODE=off`): агент коммитит, сироту не замечает (лог: только init).
- BLOCK (`tool.execute.before` throw): гейт сработал (count=1, CLI 8400ms), коммит **заблокирован**,
  агент **не обошёл** (`--no-verify`/плагин не трогал), назвал причину и предложил варианты.
- ADVISORY (не-блокирующий): ПЕРВАЯ реализация (`tool.execute.after` считает diff) **слепа** — after
  срабатывает после коммита, diff пуст → count=0/"no changes". ИСПРАВЛЕНО: считать в `before`
  (pre-commit cached diff), кэшировать по `callID`, дописывать заметку в `after`. Повтор: заметка
  доставлена (`✦ GRAPH-GATE (advisory)`), коммит прошёл, агент её прочитал и назвал, **но не исправил**
  (сирота остался в коммите).
**Вердикт:** block меняет исход (плохой коммит предотвращён), модель подчиняется (1/1, без обхода);
advisory доставляется и понимается, но в этой постановке (промпт = «закоммить и отчитайся») исхода
не меняет. Ровно наблюдение Тома: знание приходит на нужном вызове и не меняет ничего; speak и block —
разные инструменты. **Границы:** 1 прогон/арм, один модель/промпт; advisory-эффект зависит от постановки
(исправление не было целью). Стенд: %TEMP%/opencode/e8.

**Файлы:** src/core/quiet_break_gate.py, src/mcp/tools/graph_tools.py (action isolation),
tests/test_quiet_break_gate.py; лаб %TEMP%/opencode/e_gate2/e2e_control.py.


## Exp 21 — E9: redaction на доставке (единая точка CLI)

**Гипотеза:** секрет, вставленный в доставляемую заметку как evidence, утекает в контекст КАЖДОГО
агента, на котором заметка сработает (канал доставки не проходит commit-gate). Redaction в единой
точке доставки (`src/cli.py`) вырежет известные формы ключей и НЕ испортит легитимный текст заметки
(пути, хеши, версии).

**Метод:** in-house prefix-anchored redactor (`src/core/redact.py`; идея — Tom Jones, crystal-memory
`scripts/redact.py`, Apache-2.0; код НЕ вендорился). Врезан в единственный choke point: сериализованный
JSON `src/cli.py` (успех И ошибка). Тесты: unit + CLI-интеграция (fake tool возвращает ключ).

**Результат:** unit **8/8** — каждая семья (aws/anthropic/openai/github-token/pat/slack/google/stripe/
jwt/url-cred/bearer/private-key/assignment) вырезается; хеш коммита, sha256-дайджест, путь, версия,
слово «key» в прозе — byte-identical; JSON остаётся валидным. CLI E2E: stdout содержит
`[REDACTED:anthropic]`, путь сохранён, stderr сообщает `{"redacted": {...}}`.

**Вердикт:** ПОДТВЕРЖДЕНА. Redaction на доставке работает и не калечит заметки. ⛔ Не граница
безопасности: новый формат / секрет разбитый по строкам проходит — задокументировано, не продаём как «safe».

**Файлы:** src/core/redact.py, src/cli.py, tests/test_redact.py. Атрибуция идеи: Tom Jones (crystal-memory).


## Exp 22 — E10: сдержанность доставки (anti-numbing)

**Гипотеза:** повтор одной и той же advisory-заметки притупляет читателя (Tom Jones: «the evening the
agent went numb to its own alerts»; наш E3/E4 — та же опасность). Сигнатура findings + cooldown с
растущим backoff подавит повторы, НЕ скрывая реальных изменений.

**Метод:** `src/core/restraint.py` — `signature(findings)` (kind+symbol+file) + `should_deliver`
(cooldown 600s, окно = cooldown × 2^min(strikes,3)); состояние — один JSON на проект
(`delivery_state.json` в data_root, перезапись, atomic replace). Opt-in: `graph_query` action
`isolation` + `kwargs={"restraint":true}` (блокирующие гейты сюда НЕ заходят — Red Team п.3).

**Результат:** unit **4/4** (вместе с gate/redact — 22/22): первая доставка; немедленный повтор
подавлен; после cooldown — снова; новая сигнатура — сброс; backoff растёт. CLI E2E (2 одинаковых
вызова): call1 `deliver: ✓`; call2 `deliver: ✗` `cooldown: same findings, 597s left (strikes=0)`.
Гоча: доп. аргументы CLI идут через `kwargs` (execute не принимает произвольные именованные).

**Вердикт:** ПОДТВЕРЖДЕНА. Повтор подавляется, изменение findings → новая сигнатура → доставка;
блокирующие гейты не затронуты. ⛔ Best-effort, не граница безопасности (при сбое чтения — fail-open).

**Файлы:** src/core/restraint.py, src/mcp/tools/graph_tools.py (kwargs.restraint), tests/test_restraint.py.


## Exp 23 — E11: frozen list vs the NEW arrival index (Tom's catalogue, «after»)

**Гипотеза:** arrival layer (25 фраз → записи) делает dispositional-симптом #16 («агент не пользуется
моими тулами») достижимым для семьи A, чего таблицы симптомов не могли (E7: NONE 10/10 валидных).

**Метод:** тот же замороженный список (10 реальных + 6 контролей), что в E7; индекс заменён на arrival
index + symptom tables из каталога (`github.com/tjonesit/crystals` @3e30ed2, `catalogue/README.md`,
generated). Слепой маппер (opencode run, все MCP off, пустая папка), модели deepseek-v4.1-flash ×3,
longcat-2.0 ×1, qwen3.7-plus ×1.

**Результат:** **#16 → A в 5/5 прогонов**, включая оба ВАЛИДНЫХ. Валидные (контроли 6/6): longcat-2.0,
qwen3.7-plus. deepseek ×3 — НЕВАЛИДНЫ: NC3 (#11 Safari/CSS) притянулся к E
`a-generated-document-is-unverified-until-you-render-it` (фраза про вёрстку/spacing) — та же болезнь
NONE-контроля, что у deepseek-low в E7. Прочие пункты остаются модельно-зависимыми (#10, #13 разные).

**Вердикт:** arrival layer ПОДТВЕРЖДЁН как мост для #16 (NONE → A). Воспроизводимость по-прежнему
свойство читателя (оговорка Тома держится). ⚠ Новый риск: слой фраз может ВЫДУМАТЬ ложное совпадение
на соседнем домене (UI-фраза ловит вне-доменный CSS-симптом) — кандидат в запись/дырку.

**Файлы:** лаб %TEMP%/opencode/e11 (handout.md, opencode.json). Источник: tjonesit/crystals @3e30ed2.


## Exp 24 — E12: L1 детерминированный doc-reference чекер (near-zero FP)

**Гипотеза:** полный словарь из кода + scope=живые доки + исключения (venv/архив) + whitelist
(stdlib/внешние/env/модели) превращает непригодные 1366 «битых» в actionable-гейт.

**Мотив:** старый `auto_doc_updater` собирал только ОПРЕДЕЛЕНИЯ (def/class/тулы/константы) и сканировал
`root.rglob` (включая `venv`: 232 чужих .md) → 1366 «битых», ~3% реальных (параметры/поля/stdlib).
«Checker that cries wolf gets muted» (evergreen/doc-sync).

**Метод:** `src/core/doc_reference_l1.py` (stdlib): словарь = идентификаторы + строковые литералы из
src/tests/scripts/tools (+корневые *.py); scope = корневые доки БЕЗ леджеров + docs/** минус
archive/generated/research/blog/ISSUES/investigations; фильтры dunder/`file:NN`/символы/модели/env/`@`/`self.`;
whitelist stdlib+builtins+typing, внешние (Zed/Rust), commit-scopes. Подключён к `auto_update_docs("verify")`.

**Результат:** «битых» **1366 → 11 → 2 → 0** (после whitelist 2 легитимных терминов: in-toto `expected_command`,
концепт `graph_context_first`). Тесты 4/4 (12/12 с auto_doc_updater). Словарь 18820, живых доков 69.
Найдена и исправлена реальная неточность: WISDOM `_symbol_resolver` → `_build_symbol_resolver`.
(Побочно: краш на одиноком `` `$` `` — починен ранее в этой сессии.)

**Вердикт:** ПОДТВЕРЖДЕНА. Детерминированный L1 на полном словаре даёт ~0 FP на живых доках → годен как гейт.
**Ограничение:** L1 проверяет «имя существует ГДЕ-ЛИБО в коде», поэтому устаревшее имя ТУЛА, всё ещё
встречающееся в тестах, маскируется (старые `replace_symbol`/`predict_eta` в BENCHMARK.md не пойманы) —
для тулов нужна проверка по реестру, а не по словарю.

**Файлы:** src/core/doc_reference_l1.py, src/core/auto_doc_updater.py (delegate), tests/test_doc_reference_l1.py, WISDOM.md.


## Exp 25 — E13: сокращение времени тестов (замер xdist)

**Гипотеза:** параллельный прогон (pytest-xdist) заметно сократит время без потери качества.

**Метод:** `pip install pytest-xdist` (3.8.0), полный прогон `pytest tests/ -q -n 4` vs последовательный, на той же машине/сессии.

**Результат:** serial — **1817 passed за 200с** (тёплый); parallel `-n 4` — **1817 passed за 169с** (wall 172с)
→ **~15% быстрее**, падений нет (наблюдаемая parallel-safety). Топ-тормоз serial: `test_temporal_facts_generator`
≈42с (5 тестов). CI `clean-state` — **~13м холодный** (доминирует install/холодные кэши, не CPU).

**Вердикт:** xdist даёт лишь ~15% локально → не стоит сложности по умолчанию. Главный рычаг CI — кэш
deps/install, а не CPU-параллельность. Дальше: кэш pip в `clean-state`; разбор/оптимизация
`test_temporal_facts_generator`. (Локальный xdist отключён по прежнему решению владельца — конфликт с llama.)

**CORRECTED (2026-09-26):** вывод «~15%, не берём» опровергнут: он был снят с `-n 4` на многоядерной
машине (недогрузка CPU). С `-n auto` на 12 ядрах: serial 1865 тестов **197.1с** → `-n auto` **71.4с**
(**×2.76**), с CI-shape coverage — **86.4с**; `0 failed`. В CI эффект ещё больше (см. Exp 26). Решение
владельца 2026-09-23 «не берём» отменено владельцем 2026-09-26. См. AGENT_DIARY 2026-09-26.

## Exp 26 — CI/тест-параллелизация: pytest-xdist `-n auto` (CONFIRMED, внедрено)

**Гипотеза:** `-n auto` (все ядра, не 4) + контекст-независимый CI-coverage дадут кратное ускорение CI без потери качества.

**Метод:** локально (12 ядер) serial vs `-n auto` vs `-n auto --cov`; в CI те же команды на ubuntu/windows (4 ядра), выборка та же (addopts `-m 'not slow and not benchmark'`).

**Сырой результат (локально, 1865 тестов):** serial (no cov) **197.1с** → `-n auto` (no cov) **71.4с** → `-n auto` + CI-cov **86.4с**; **1865 passed / 0 failed**; coverage **54.58%** (gate 38%).
CI до/после: test ubuntu **13m44s→1m58s**, windows **16m23s→3m11s**, clean-state **13m25s→1m41s**.
Плюс `test_temporal_facts_generator` **36.6с→20.8с** (module-fixture для `generate(seed=7)`).

**Ключевое препятствие:** `.coveragerc` `dynamic_context=test_function` несовместим с xdist (pytest-cov#604, DistCovError) → CI использует `.coveragerc.ci` (без контекстов) через `COVERAGE_RCFILE`; локальный/bootstrap сохраняют пер-тестовые контексты.

**Вердикт:** CONFIRMED. Внедрено: #45 (test job), #46 (clean-state), #47 (pre-commit `verify_diary` Gate-zero, с fallback на serial, если xdist нет).
**Остаточный риск:** Exp 25 фиксировал «конфликт с llama» при локальном xdist; полный параллельный прогон локально прошёл `0 failed`, но флейки серверных тестов многократно не проверялись → watch.

---

## [2026-09-27] Exp v3 (Token Reduction): production-retriever arm — CONFIRMED (42.9% compression @ hit@10=70%); чисто-векторный прогон отозван как невалидный дубликат E10

**Контекст.** Серия v1/v2/v3 измеряла сжатие токенов на реальных данных MSCodeBase. v1 (`5e7fd2da`) невалиден by design (TF-IDF по заранее известным target files), v2 (`5ab7265a`) exploratory. Первый прогон v3 (`run_experiment.py`) использовал `search_lancedb` — **прямой dense-поиск в LanceDB мимо штатного ретривера** — и дал 2/13 (0.154) hit.

**Почему этот прогон невалиден (3 независимых дефекта harness, не дефекта продукта):**
1. `run_experiment.py:68-98` — чистый вектор в обход `hybrid_search_async`. Замеренное 0.154 лежит внутри задокументированной полосы pure-vector (E10, EXPERIMENTS_LOG.md:2306-2332; потолок search-only ~0.23, EXPERIMENTS_LOG.md:1873). **Продукт не сломан — закрыта та же ветка, что и в E10.**
2. `run_experiment.py:124` — `compressed_found = (tf in found_files)`, т.е. **тавтология** `baseline_found`. Evidence retention не измерялся вообще.
3. `run_experiment.py:48-50` — `sentence_filter` резал по `[.!?]`; у кода таких границ ≤2 → `return text`, компрессор был **no-op** на реальных чанках.

**Исправленный harness:** `run_experiment_hybrid.py` — штатный `searcher.search_with_mode(mode="quality", limit=10)` → `hybrid_search_async` (BM25 + dense + FTS5 + graph_stage → RRF → reranker, `engine.py:520`). Токены — настоящий BPE `llama.cpp /tokenize` (не regex-прокси). Компрессор построчный (держит пересекающиеся с запросом идентификаторы + структурные строки). Evidence retention измеряется отдельно от retrieval.

**Команда:** `python experiments/token_reduction_v3_lancedb/run_experiment_hybrid.py` (live embed 8080 / rerank 8081, индекс 10463 строки, живой прогон, venv расширения).

**Сырой результат:**
```
RULES (n=10):  hit@1=20.0%  hit@5=50.0%  hit@10=70.0%   tokens 12939 -> 7392   reduction=42.9%  evidence_retention=0.763 (n=7)
POSITIVE (n=3):hit@1=33.3%  hit@5=33.3%  hit@10=33.3%   tokens  2357 -> 1308   reduction=44.5%  evidence_retention=0.833
NONE (n=3):    hit@1= 0.0%  hit@5= 0.0%  hit@10= 0.0%    tokens  4609 -> 2507   reduction=45.6%
latency mean 3225ms; redteam: RT_positive_missed P2, P3
```

**Вердикт: ✅ CONFIRMED (с оговоркой).** Сжатие ~43% токенов при hit@10=70% и сохранении 76% идентификаторов в найденных чанках. Ни одного разрушения доказательной нагрузки (`RT_evidence_destroyed` = 0), ни одного false-positive на NONE-контролях.

**Сверка с закрытыми экспериментами (важно):**
- Прод-ретривер даёт **hit@1=20% / hit@5=50%** — точно в задокументированной полосе E10 (quality 20%/40%, `:2320`) и E11 (baseline 20%/20%, `:2345`). **Плато подтверждено, дефекта нет.**
- Прежние 0.154 → 0.70 hit@10: разница целиком в том, КАКОЙ тир измерялся. E10 это уже предсказал: pure-vector закрыт как бесполезный, следующий ход — AST/Graph-hybrid (E11, `:2336-2356`), он и стоит в проде (`engine.py:689-696`).
- `graph_stage` в этом прогоне не сработал (0/16) — identifier-запросы ушли в lexical/RRF-ветку. **Это не баг:** ветка включается на `_symbolish`/`_IDENTIFIER_QUERY_RE` (`engine.py:574,689`), а у frozen-запросов формат multi-token дампа. Проверка graph-стадии — отдельная задача, не этот эксперимент.

**Red Team:** P2/P3 (positive controls) не найдены → до отсева 2/3 контрольных кейсов теряют цель. Причина не в сжатии (оно не меняет retrieval), а в качестве lexical-тюнинга на конкретных формулировках. **Оговорка DoD:** полный ✅ не ставится — controls 2/3.

**Урок (психологический, главный):** три гипотезы, которые я выдвигал как «баги индекса» (потеря 64% текста, обрезанный `text`, скорость >30 ч/с), были **уже измерены и закрыты** 19-20 сентября — E10a (полный текст в индекс, REFUTED), E12 (потолок embed по длине чанка, CONFIRMED, «156 ch/s» = синтетика), плюс фикс разделителей путей 2026-09-25 (19653 → 10103 rows, дубли 0), задокументированный в KNOWN_ISSUES. **Я измерил закрытую ветку и назвал это новым дефектом.** Три версии подряд (wrong model / trim leak / lossy index) — охотники за ведьмами, потому что Phase Zero и Research→Experiment→Decision были пропущены: гипотеза раньше чтения первоисточников.

**Guard:** `run_experiment_hybrid.py` остаётся переиспользуемым инструментом; pure-vector путь в нём недостижим (единая точка входа — прод-ретривер). Серия записана в дневник/лог согласно §13.

**Artifacts:** experiments/token_reduction_v3_lancedb/{run_experiment_hybrid.py, frozen/rules.jsonl (sha 31f1b0c9…), results/results_hybrid.json}; невалидный results.json помечен как invalid-duplicate-E10.

## [2026-09-27] Reranker score scale mismatch (P2/P3) — PARTIAL

**Гипотеза:** P2/P3 теряются на стадии reranker потому, что `MIN_RERANK_SCORE=0.3` (калиброван под шкалу [0,1]) применяется к сырым логитам llama.cpp (≈[-11,+11]).

**Метод:** runtime-бисекция стадий (monkeypatch `apply_mmr_diversity` / `_dedupe_by_symbol` / `_boost_exact_name_matches` / `_apply_multi_reranker_async`), затем перехват `apply_scores` для полного распределения скоров на pre-rerank пуле. На этапе измерений `src/` не изменялся.

**Сырой результат — потери 100% на reranker (MMR/boost/dedupe прозрачны):**
```
P2:        MMR 10→10 | reranker 10→3 | boost 3→3 | dedupe 3→3   цель в пул НЕ входит
P3:        MMR 10→10 | reranker 10→2 | boost 2→2 | dedupe 2→2   цель поз.4 -> None
R2:        MMR 10→10 | reranker 10→1 | boost 1→1 | dedupe 1→1   цель поз.6 -> None
R2@limit=30:          30→30 | reranker 30→1
```
Сырые скоры: P3 `-6.88 +1.65 -8.25 -0.99 -9.38 -2.95 -8.99 -5.55 -8.08 +0.75`; R2 `-3.72 -9.02 -6.82 +1.96 -3.79 -2.60 -8.11 -4.29 -8.32 -0.20`. Диапазон отрезанных -9.38…-0.20 — нормализованный [0,1] так не умеет.

**Источник:** llama.cpp PR #9510 (собственный пример ggerganov) — `relevance_score` = сырой логит (`5.97` / `-11.03`); Cohere-контракт `/v1/rerank` обещает нормализацию в [0,1]. Нарушение контракта подтверждено измерением.

**Вердикт: PARTIAL.** «Нарушен контракт шкалы» — CONFIRMED (фильтр режет 70-97% выдачи). Исправлено: сигмоида `1/(1+e^-x)` в llama_cpp-ветке `multi_provider.py`, `MIN_RERANK_SCORE=0.3` сохранён (21 строка, один файл). **Но «порог = root cause P2/P3» — REFUTED:** после нормализации цель P3 = 0.27 < 0.3, цель R2 = 0.07 — кросс-энкодер оценивает правильный файл отрицательным логитом (P3 -0.99, R2 -2.60). Это дефект ранжирования/модели, а не только порога. P2/P3 НЕ закрыты.

**Отрицательные результаты (не повторять):**
1. **Подгонка порога sweep-ом по тем же 16 frozen-правилам = перебор на оценочной выборке.** 0.05/0.02 давали 7-8 hits против 5 на тех же правилах, которыми меряется результат. Отклонено владельцем; константа не менялась. Калибровать порог можно только на отдельном holdout.
2. **Survivorship bias:** вызов `/v1/rerank` с пулом из уже отфильтрованного `hybrid_search_async` дал ложный вывод «фильтр режет 0». Порог меряется только на полном pre-rerank пуле.
3. Латентный баг `apply_mmr_diversity` при смешанном `vector` (IndexError) реален, но в этом пайплайне не срабатывает — финальные chunks идут без `vector`.

**Открыто:** P2 — целевой файл не входит в pre-rerank пул вовсе (проблема retrieval, не фильтра; top-хиты — собственные артефакты `experiments/**`). P3 — целевой chunk переживает reranker, но не проходит порог. Требуется отдельное решение владельца; подбирать порог по eval-набору нельзя.

## [2026-09-27] — exp-54 (PLANNED — NOT RUN): CoT effect as function of task shape

**Статус:** ⏳ PLANNED — НЕ ЗАПУЩЕН (дизайн зафиксирован, прогона нет, чисел нет).
**Гипотеза:** CoT окупается на why-diagnosis (Grok 100→35 — мышление чинит диагноз), но ~ноль на fact-verification (наши VOR-плечи: CoT дал qwen3.6 recall 0.08→0.20 ценой ×30–65, у 3 из 4 моделей выигрыш нулевой) — эффект CoT = функция формы задачи, а не «модели стали умнее».
**Дизайн:** те же модели × 2 формы (why-diagnosis vs fact-verification) × CoT on/off; замороженный набор (frozen, в репо); слепой судья (blind, единый reference по плечам); pos/neg контроли в каждом прогоне.
**Ожидаемая форма вердикта:** интеракция shape×CoT (CoT≫0 на why, CoT≈0 на fact) либо REFUTED (CoT равномерен/нулевой везде) — цитируются только дельты с контролями, не абсолюты.
**Связи:** ["exp-1","exp-18"].

## [2026-09-27] — F5 D-arm no-abstention ablation (floor test)

**Гипотеза (Tom):** D-плечо (closed book) даёт ~0 только потому, что инструкция разрешает abstention («I don't know»); без разрешения сдаваться reader priors покажут реальный уровень.
**Метод:** те же 16 frozen queries × 3 trials = 48 reader-прогонов (reader `opencode-go/longcat-2.0`, инструкция из `experiments/4A_unit_of_return/frozen/f5/reader_D_ablation.txt`, sha256 `91b16b8b…`) + 48 judge-прогонов (judge `opencode-go/qwen3.7-plus`, без изменений, blind, единый reference). Дизайн: arm D only, populations code/prose.
**Сырой результат:**
```
D overall: 2/48 = 4.2%
code:  0/24 = 0%
prose: 2/24 = 8.3% (F5S-10, F5S-13, по одному среднему trial)
majority (≥2/3): 0/16
invalid/uncertain: 0
```
**Вердикт:** reader priors существуют на уровне шума — механизм Tom подтверждён, масштаб нет (его 6/14 vs наши 2/48). Prose-плечо B 18.8% читается на фоне ~4% пола, отрыв сохраняется.
**Артефакты:** `experiments/4A_unit_of_return/results/f5judged/judged_raw_D_ablation.json`, `experiments/4A_unit_of_return/results/f5judged/judged_aggregate_D_ablation.json`.