New adaptation policy

README.md

@@ -1,31 +1,35 @@
 # Universal Container
 
-Экспериментальный C++20-контейнер индексируемой последовательности, который во
-время работы выбирает представление и его геометрию:
+Экспериментальный C++20-контейнер индексируемой последовательности с двумя
+представлениями. Текущая default-policy привязывает все автоматические
+перестройки к изменению логической вместимости:
 
 ```text
-contiguous vector <-> segmented tiered storage
-                         |
-                         +-> leaf 64 / 128 / 256 / 512 / 1024
-                         +-> минимально достаточная глубина каталога
+capacity boundary
+    |-- grow:   capacity *= 2 when the current capacity is exhausted
+    `-- shrink: capacity /= 2 at 12.5% occupancy
+              |
+              +-- small N: contiguous vector
+              `-- large N: tiered storage, leaf = ceil(sqrt(N))
 ```
 
-Это не контейнер с одним «лучшим» размером блока. `CostModelPolicy` собирает
-выборочную статистику чтений и полную статистику структурных изменений,
-оценивает стоимость кандидатов и выдаёт `AdaptationDecision`: целевой режим и
-`TieredConfig`. Переход выполняется, только если прогнозируемая экономия на
-будущем горизонте превышает стоимость O(N)-перестройки с запасом.
+Между изменениями вместимости контейнер не меняет ни представление, ни размер
+leaf. На границе вместимости auto-mode заново выбирает `vector` или tiered,
+поэтому обратный переход `tiered -> vector` также возможен. Focused cutoff
+равен 4096 элементов; он выбран по baseline focused-run 7 x 100000 для
+текущего `uint32_t` workload и остаётся калибруемой, а не универсальной
+константой.
 
-Проект исследовательский. Сохранённые измерения показывают, что оптимальный
-leaf действительно меняется с `N`, размером элемента и локальностью правок, но
-пока не доказывают превосходство adaptive-варианта во всех или в среднем по
-финальной holdout-матрице. Ограничения честно перечислены в
+Поиск по значению не удалён: `AdaptiveSequence<T, true>` использует flat hash.
+Число hash buckets рассчитывается из логической вместимости с запасом под
+worst-case load не выше 70% и пересматривается только на той же границе
+вместимости. Это исключает независимый rehash посреди обычной серии операций.
+
+Старые многомерные benchmark-матрицы и сделанные по ним выводы сохранены только
+как **historical / retired**. Активная постановка и ограничения описаны в
+[docs/benchmarking.md](docs/benchmarking.md) и
 [docs/findings.md](docs/findings.md).
 
-`std::deque` и `std::list` присутствуют только как внешние benchmark-baselines.
-Они не являются режимами контейнера: `AdaptiveSequence` переключается только
-между contiguous vector и tiered storage.
-
 ## Быстрый старт
 
 Из обычной командной строки Windows:
@@ -50,7 +54,8 @@ C++». `build.bat` сам находит комплектный CMake из Visua
 
 - `uc_demo.exe` — минимальный пример;
 - `uc_tests.exe` — differential/property-тесты;
-- `uc_bench.exe` — benchmark runner.
+- `uc_focused_bench.exe` — текущий focused benchmark runner;
+- `uc_bench.exe` — historical / retired matrix runner.
 
 Все Release-цели собираются с `/O2` и статическим MSVC runtime (`/MT`). Профиль
 `scalar` — проверенный для MSVC 19.51 режим `project-novec`: внутренний ключ
@@ -61,16 +66,27 @@ AVX2-тестов и benchmark выполняется проверка CPU/OS;
 безопасно пропускается. Подробности приведены в
 [docs/benchmarking.md](docs/benchmarking.md).
 
-Полный воспроизводимый запуск:
+Текущий воспроизводимый запуск:
 
 ```bat
-benchmark.bat smoke
-benchmark.bat quick
-benchmark.bat full
+benchmark.bat
 ```
 
-Для multi-core сравнения `std::vector`, пяти fixed-tiered geometry и adaptive
-вплоть до 100 миллионов `uint32_t`:
+Он собирает и тестирует только профиль `baseline`, создаёт timestamp-папку и
+один раз запускает `uc_focused_bench` с 100000 операций и 7 повторами. В
+benchmark сравниваются три варианта одного типа
+`AdaptiveSequence<uint32_t, true>`: forced vector, forced tiered и auto-mode;
+flat hash включён у всех трёх. Mixed trace содержит 97% индексных чтений, 1%
+hash-поисков `find_one` (50% hit / 50% miss), 1% вставок и 1% удалений. Runner
+также печатает медианную пропускную способность каждого типа операций отдельно.
+
+Raw CSV, metadata и медианная таблица `summary.md` сохраняются в
+`results\benchmarks\<timestamp>-focused\`. Подтверждённая таблица публикуется
+вместе с результатами запуска, а не вшивается в документацию до завершения
+серии.
+
+Следующие команды относятся к **historical / retired benchmark matrix** и не
+являются текущим способом калибровки:
 
 ```bat
 large_benchmark.bat smoke 12
@@ -78,13 +94,9 @@ large_benchmark.bat full 12 3
 large_benchmark.bat full 12 3 huge
 ```
 
-Третий аргумент ограничивает число одновременно работающих N=100M-ячеек;
-значение 3 — эвристически более безопасный вариант для машины с 32 GiB RAM.
-Четвёртый аргумент оставляет в матрице только N=100M.
-
-Каждый запуск создаёт отдельную timestamp-папку в `results\benchmarks\`, куда
-пишутся raw CSV, сводки и описание окружения. `out\` полностью игнорируется
-Git, результаты исследования — намеренно нет.
+Старые CSV оставлены для аудита истории, но напрямую не сравнимы с focused
+постановкой: в ней другой workload и hash обязателен у каждого кандидата.
+`out\` полностью игнорируется Git, результаты исследования — намеренно нет.
 
 ## API
 
@@ -100,7 +112,7 @@ auto x = values[0];
 values.force_vector_mode();
 values.force_tiered_mode({256, 64, 4});
 values.enable_auto_mode();
-values.adapt_now();             // явная безопасная maintenance point
+values.adapt_now();             // default-policy не меняет mode между resize
 ```
 
 Опциональный flat hash index со stable IDs: