Icebox свипа идей: отложенное и убитое (с причинами)

[lemone112]

Архив свипа 2026-07-23 (81 идея → 20 кластеров → адверсариальные вердикты). Здесь — то, что НЕ идёт в работу сейчас, с условиями пере-открытия. Полные вердикты Tier-1/2 — в #235–#243.

Отложено (weak, с условием возврата)

• CSS-tier компилятора («0 B JS»): замер показал — байты просто переезжают в CSS (385 B CSS-форма против 392 B JS-литерал gzip), выигрыш одноразовый ~0.5 KB и только для all-static приложений; «доказанность mount-семантики» дырява (контрпример: статический вызов внутри onClick анимировал бы при загрузке). Жив как opt-in выходной формат после facade-erasure (Facade-erasure: static lowering полного ./animate в compiled-путь (замерено 776 B против 12466) #240); честный бонус — entrance играет до загрузки JS. Новизна uncommon (Animate.css-жанр существует с 2013; автоматическое понижение императивных вызовов — действительно ничьё).
• Бинарный wire артефактов (Δ²-zigzag-varint + декодер ~120–160 B в шве): паритет через реконструкцию (decode → Number → linear(${arr}) бит-в-бит) — приём валиден; но после портфеля строк Compiler-портфель строк: min-link коридор + DP байт-оптимум + percent-элизия + shortest-decimal (один versioned-релиз с имплементацией #228) #238 узлов останется мало и post-gzip дельта сожмётся. Мерить ПОСЛЕ Compiler-портфель строк: min-link коридор + DP байт-оптимум + percent-элизия + shortest-decimal (один versioned-релиз с имплементацией #228) #238; порог в компиляторе (packed ≥ plain → plain) обязателен.
• Ленивый split main-unit из initial-графа фасада (−2…3.5 KB заявлено): сначала esbuild-metafile разбор exclusive-веса ветки (общий channels.ts может утянуть выигрыш); bundlers потребителей часто инлайнят dynamic import (выигрыш тихо испаряется); async-загрузка на первом не-композитном кадре против контракта детерминизма — цена тестов реальна. Возврат — по цифре metafile ≥ 2 KB exclusive.
• inView → CSS scroll-driven animations (animation-timeline: view()): Chromium стабильно, Safari 26+, Firefox за флагом — ставка на 12–18 мес.; дуал-шип фолбека съедает выигрыш. Пере-оценить через 2 квартала. Родственный вариант с ближайшей ценностью: субпуть scroll-скраба (compiled spring linear() + ScrollTimeline, ~600–900 B, 0 JS на скролле против per-event JS у ScrollTrigger) — кандидат при спросе.
• τ-space ζ-канонизация горизонта (компиляция в безразмерном времени, ключ (ζ, v̂0, tol)): требует смены settle-закона → батчить с perf(compositor): локальная энергетическая сетка вместо global worst-case oversampling #228/Compiler-портфель строк: min-link коридор + DP байт-оптимум + percent-элизия + shortest-decimal (один versioned-релиз с имплементацией #228) #238, иначе двойной churn пинов. Дешёвый под-шаг (ключ LRU (k/m, c/m)) уже в Микрорантайм шва: bitmask-специализация + erasure результата + кросс-чанковый дедуп + build-кэш #239.
• LZ-primed выбор цифр (gzip-осознанный снап внутри certified-интервала): хвост хвоста, после Compiler-портфель строк: min-link коридор + DP байт-оптимум + percent-элизия + shortest-decimal (один versioned-релиз с имплементацией #228) #238 по убывающей; решает compression-oracle, не гадание.
• Квантование вывода + skip-write на хвосте (не трогать style при неизменной строке): перф-микровыигрыш, объединить с phase-shift-веткой Компоситорные перф-новеллы: аддитивный ретаргет суперпозицией, tail-handoff, phase-shift базис staggers #242 при профилировании.

Убито (не возвращаться без новых фактов)

• Self-extracting через CompressionStream: gzip-поверх-gzip — обе метрики стенда меряют gzip поверх доставки; gzip(base64(deflate(x))) ≈ 1.37·|deflate(x)| — минус по построению.
• Browser-as-parser цвета (getComputedStyle): форсит style-recalc на каждый парс + ломает SSR-контракт ./value (V2) — размен кода на runtime-стоимость и семантику.
• Compression-aware перебор seed'ов Terser: −0.3…1.5% gz, хрупко к любому изменению кода, невоспроизводимо между версиями терсера — не окупает сложность пайплайна.

Полный дамп свипа (81 идея с механизмами) — в session-scratchpad; ключевое перенесено сюда и в #235–#243.

[lemone112]

NO-GO — stable callback для injectable frame source (2026-09-06)

Exact base: main@19102c9b4898b9755e3f1e33fc0718184329d0c2.

Идея

Убрать per-reservation closure из createFrameRequester для пользовательского/injected requestFrame, переиспользуя один стабильный callback так же, как уже делает trusted native path. Ожидаемая выгода — убрать одну функцию-аллокацию на reservation/frame в headless keyframes/presets при инжектированном clock без изменения API.

Перед экспериментом сверены актуальный main, открытые PR и текущие perf/research issues. Идея не затрагивает незавершённые #309 (spring workspace), #306 (compositor grid), #299/#302 (transform binding/bench) или #297 (compiled Nano). Архитектурный frame остаётся единым read→update→render scheduler; benchmark-канон запрещает менять семантику ради synthetic win. На main workflow-файлы ci.yml/browser.yml/mutation.yml повреждены; их отдельный repair идёт в #295/#307. Это не использовано как причина NO-GO: кандидат опровергнут до CI.

Baseline и фальсификатор

Факт: src/internal/frame-requester.ts хранит monotonic reservation; hostile/injected path передаёт host уникальную closure (timestamp) => accept(owner, timestamp), а trusted path может передать стабильный deliverTrusted, который вызывает accept(reservation, timestamp). keyframes и presets включают unique-reservation режим именно когда requestFrame инжектирован.

Факт: уже существующий positive control test/frame-requester.test.ts требует, чтобы поздний callback старой reservation не мог поглотить следующую: после delivery 10, stale delivery 20 и fresh delivery 30 наблюдаемый trace обязан быть [10, 30].

Фальсификатор до кода: stable-callback кандидат допустим только если одновременно сохраняет этот stale-owner контракт, synchronous-host/throw/handle=0 semantics, не добавляет эквивалентную per-reservation allocation/bookkeeping и не требует нового публичного trust contract.

Результат

NO-GO по контракту, до production-кода. При одном и том же callback C для reservation r1 и r2 поздний вызов C от r1, пришедший когда pending уже принадлежит r2, неотличим для requester от настоящего вызова C от r2: callback получает только timestamp, а текущая mutable state уже содержит reservation=r2. Timestamp не является owner-id и контролируется host. Возвращаемый handle также не решает задачу: он не передаётся обратно callback и synchronous delivery разрешена до получения handle.

Следовательно, при текущем RequestFrameFn(cb) -> handle безопасное различение stale/fresh доставок требует уникальной per-reservation capability — identity callback/closure либо эквивалентного токена, который host вернёт при delivery. Стабильный callback без смены host-контракта неизбежно принимает stale delivery за текущую.

Локальный source-faithful минимальный positive control дал:

current unique callback: callbacks identical = false; ticks = [10, 30]
stable callback:         callbacks identical = true;  ticks = [10, 20]

То есть кандидат не просто «может быть рискован»: он меняет наблюдаемую frame ownership semantics и поглощает корректную fresh delivery.

Проход «радикально проще»

Он уже существует в production: trusted/native scheduler использует uniqueReservations=false и стабильный deliverTrusted, то есть zero-allocation callback path применяется ровно там, где host boundary это позволяет. Расширить его на arbitrary injectable clock без новой доверенной capability нельзя; вводить ещё один trust-tier/API ради этой микрооптимизации — новая сложность без доказанного продукта/финансирования.

Проверки

• ДА: immutable source/readback exact base; актуальные open PR/issues; architecture/benchmark contracts; source-level positive control уже существующего regression test; независимый локальный минимальный executable control для unique-vs-stable histories.
• НЕ БЫЛО: изменение production-кода, repository Vitest, build/size/pack, browser matrix, mutation, latency/allocation benchmark, exact-candidate remote gates. После доказанного нарушения observable semantics они не могут превратить вариант в Pareto-improvement.
• НЕ БЫЛО: PR/merge/auto-merge/default-branch mutation.

Что исключено

Не повторять идею «убрать callback allocation на injected clocks, просто переиспользуя callback/текущий reservation». Возврат к классу допустим только при новом явно доверенном scheduler contract, который несёт reservation identity обратно в delivery; это уже отдельное архитектурное решение и должно сначала доказать реальный consumer win. Текущий unique-vs-trusted split — минимальный корректный закон.

[lemone112]

NO-GO — reusable Reflect.apply args для native frame reserve (2026-09-06)

Exact base: main@19102c9b4898b9755e3f1e33fc0718184329d0c2.

Перед исследованием сверены актуальный main, открытые PR/issues, docs/architecture.md, docs/benchmark.md, workflow-gates и предыдущие GO/NO-GO. Кандидат не дублирует уже записанный здесь stable-callback NO-GO: identity fire остаётся уникальной на reservation; исследуется только аллокация массива аргументов на native host-вызове. Он также не пересекается с #309 (spring workspace), #306 (compositor grid), #299/#302 (transform binding/bench) или #297 (compiled Nano).

Baseline / гипотеза / фальсификатор

Факт baseline. src/frame/index.ts сохраняет динамический lookup native requestAnimationFrame, правильный globalThis receiver и hostile-host контракт через:

Reflect.apply(native, globalThis, [fire])

Уникальная fire closure нужна для stale-delivery ownership; предыдущий NO-GO это уже доказал. Отдельный существующий frame-loop test защищает global receiver и недоверие к подменному own .call host-функции.

Гипотеза. Сохранить весь этот контракт, но убрать literal [fire] на каждом reserve: держать один const nativeArgs = [fire] на FrameLoop, перед вызовом делать nativeArgs[0] = fire, затем Reflect.apply(native, globalThis, nativeArgs). Потенциальный выигрыш — одна author-side Array allocation на native frame reservation; callback identity, фазы, callbacks и browser API не меняются.

Фальсификатор. Кандидат — GO только если исчезновение transient allocation не покупается retained memory, latency или code/size ценой. Поскольку scheduler делает максимум один native reserve на кадр независимо от N subscribers, выигрыш обязан быть заметен именно на этой единичной границе, а не в искусственном N× loop.

Измерение до production-кода

Source-faithful V8 microbenchmark сравнил только форму вызова Reflect.apply(fn, receiver, [cb]) против args[0]=cb; Reflect.apply(fn, receiver, args). 32 позиционно-сбалансированных ABBA/BAAB блока, 3,000,000 вызовов на sample; один и тот же динамический callback/receiver/host. Среда: Node v22.16.0, Linux x86_64, AMD EPYC 9V74.

baseline median:  9.295 ns/call
candidate median: 14.295 ns/call
paired median:    +53.14% candidate/base
bootstrap 95% CI: +50.99% .. +58.98%
positive control (второй host-call): +63.41%

Это не browser-rAF latency claim: host здесь JS-функция, поэтому абсолютные ns нельзя переносить на Chromium/WebKit/Firefox. Но результат опровергает предположение, что reusable array автоматически дешевле для V8: короткоживущий literal оптимизируется лучше, чем mutation long-lived array.

Отдельный --expose-gc retained-heap control создал 200,000 эквивалентных closures в изолированных процессах, 7/7 одинаковых замеров:

baseline: 111.989 B / closure
candidate: 151.991 B / closure
Δ:        +40.002 B / closure retained

Это тоже не универсальный JS object-size ABI, но направление структурно неизбежно: reusable variant добавляет живой Array, удерживаемый lifetime FrameLoop; baseline такого объекта не удерживает.

Pareto verdict

NO-GO до изменения production-кода. Защищённая retention-метрика ухудшается по конструкции, а V8 control вместо latency-win показывает устойчивую регрессию. Даже если конкретный browser JIT дал бы иной micro-result, scheduler резервирует только один rAF на кадр, поэтому здесь нет системного N-множителя, способного профинансировать дополнительное долгоживущее состояние/байты.

Проход «радикально проще»

• native.call(globalThis, fire) убрал бы arg-array без retained state, но нарушает уже защищённую hostile-host границу: production намеренно не доверяет own .call нативной/подменной функции, и test пинит этот контракт.
• Стабильная fire closure могла бы дать более крупную экономию, но уже отдельно доказанно ломает stale-reservation ownership (предыдущий комментарий этого issue).
• arguments/rest/helper только перемещают или возвращают allocation и не дают более простого закона.

Следовательно, текущий Reflect.apply(..., [fire]) — более сильный вариант на этой границе: ephemeral аргумент не превращается в retained scheduler state и сохраняет receiver/host contract.

Проверки

• ДА: exact immutable source/readback main; актуальные open PR/issues; architecture/benchmark/CI contracts; предыдущие frame/perf NO-GO.
• ДА: 32-block paired V8 control + bootstrap CI + positive control; отдельный 7-run retained-heap control.
• НЕ БЫЛО: production-code изменение, repository Vitest, pnpm build/size, packed consumer, browser differential, remote exact-SHA gates. После доказанной Pareto-неприемлемости candidate в production не вносился, поэтому эти проверки не симулировались и не объявляются зелёными.
• НЕ БЫЛО: PR/merge/auto-merge/default-branch mutation.

Что исключено

Не возвращаться к «reuse mutable args array для Reflect.apply(requestAnimationFrame, ...)» как zero-allocation win без нового факта, одновременно снимающего retained-state цену и показывающего product-level browser benefit. Простое устранение синтаксической [fire] allocation само по себе улучшением системы не является.

[lemone112]

NO-GO — убрать per-model clampT closure в createDecay (2026-09-06)

Exact base: main@19102c9b4898b9755e3f1e33fc0718184329d0c2.

Гипотеза и фальсификатор

Факт: non-reduced createDecay() на current main создаёт отдельную вложенную clampT closure на каждый model; valueAt и velocityAt обе удерживают её. Для объявленного numeric-domain правило эквивалентно t > 0 ? t : 0: NaN, -Infinity, отрицательные числа и ±0 дают +0, положительные числа сохраняются, +Infinity остаётся +Infinity.

Гипотеза: удалить отдельную closure и встроить это одно сравнение прямо в valueAt/velocityAt. Это может уменьшить retention/cold construction без новой state/ветки/абстракции; steady-state sampling не должен ухудшиться.

Фальсификатор: любой Object.is drift на валидном number domain, отсутствие устойчивого memory benefit, защищённая size/runtime регрессия либо невозможность получить обязательные exact-SHA gates => не принимать production change.

Перед экспериментом перечитаны current main, открытые PR/issues, docs/architecture.md, docs/benchmark.md, current workflow contract и предыдущие GO/NO-GO. Открытые runtime PR сосредоточены в compositor/projection/value/compiler; decay-overlap не найден. Current merge-plane отдельно чинится в #307/#308; дублировать этот CI-fix в perf-ветке нельзя.

Source-faithful эксперимент

Кандидат не добавлялся в repository. Локально сравнивались буквальные current-main формулы createDecay с единственным изменением: удалён nested clampT, а два caller используют const ct = t > 0 ? t : 0.

Numeric characterization — ДА: 1,200,192 сравнений valueAt/velocityAt/isSettledAt на 4 конфигурациях, specials (NaN, ±Infinity, ±0, subnormal/extreme finite) и 100k deterministic finite times: 1,200,192 / 1,200,192 Object.is equal.

Дополнительная JS-host characterization нашла важную границу: вне объявленного t: number domain поведение не эквивалентно. Например t=undefined/'foo': baseline non-coercing Number.isNaN path доходит до finiteOr fallback, а t > 0 ? t : 0 трактует значение как zero-time. Это не использовано как единственная причина NO-GO, потому что публичный тип заявляет number, но без отдельного invalid-runtime-input contract такую разницу нельзя тихо переименовать в доказанный semantic parity.

Retention

Node v22.16.0, V8 12.4.254.21-node.26, Linux x64, AMD EPYC 9V74, --expose-gc. Каждый sample — отдельный свежий process, 200,000 реально удерживаемых models после forced GC; 5 независимых samples на вариант.

baseline bytes/model: 502.835, 503.424, 503.186, 503.778, 503.476
candidate bytes/model: 428.864, 429.075, 428.371, 428.925, 428.762
median: 503.424 -> 428.864 B/model
Δ: -74.560 B/model (-14.81%)

Это сильный source-excerpt retention signal, не package-level browser claim. Межпроцессный baseline range <1 B/model, то есть наблюдаемая дельта значительно больше собственной вариативности этого memory harness.

Runtime sampling

Positive-time model sampling (valueAt + velocityAt + isSettledAt), 80 paired blocks × 300 repetitions × 1024 timestamps после warmup:

candidate/base median: -1.21%
p10: -3.68%
p90: +2.92%

byte-identical baseline/control median: +0.36%
p10: -3.15%
p90: +4.50%

Следовательно, никакого steady-state speedup не заявляется: эффект находится внутри шума и сильно ниже 5% practical threshold из docs/benchmark.md.

Отдельный create-latency harness сначала показал большую дельту, но его byte-identical control обнаружил order/GC bias (median +21.6%, широкий знак-пересекающий диапазон). Этот замер ОТВЕРГНУТ и не используется как evidence.

Проход «радикально проще»

Кандидат уже является удалением абстракции: отдельная nested closure исчезает, новой state/utility/branch не появляется. Хранить общий helper ради двух caller как раз возвращает retention, которую гипотеза пытается убрать. Более сложный cache/last-sample путь не нужен и ухудшил бы модель.

Вердикт

NO-GO на current base. Есть сильный локальный сигнал по retained heap (−14.81%, −74.56 B/model) и bit-exact parity на объявленном numeric-domain, но Pareto-admission не доказан в авторитетной среде: package size/import-cost, actual built artifact, browser behavior и mandatory remote exact-SHA gates не проверены. На current main CI workflow contract повреждён, а native merge-plane repair уже идёт отдельным #307/#308; включать его в perf PR означало бы конфликтовать с незавершённой работой и подменять одну итерацию двумя.

Production-код, тесты, thresholds, default branch и PR не менялись; cleanup не требуется.

Проверки

• ДА: current main SHA повторно сверён; open PR/issues, architecture, benchmark contract, workflow/gate state, previous NO-GO прочитаны; decay-overlap среди open PR не найден.
• ДА: 1,200,192 valid-number bit-exact comparisons; independent fresh-process retained-heap series; repeated paired sampling + byte-identical performance control.
• НЕТ: create-latency benchmark как evidence — harness провалил byte-identical control, результат отброшен.
• НЕ БЫЛО: repository Vitest/fuzz/mutation, pnpm build, pnpm size, pack/consumer, browser differential, actual-package heap profile, required remote exact-SHA gates.

Что это исключает / условие возврата

Не заявлять clampT inline как speed optimization: steady-state sampling win не доказан. Возвращаться к этому exact candidate имеет смысл только после восстановления native exact-SHA CI graph на main, и тогда начинать с actual-package memory + canonical size/pack/browser checks; локальный retention signal сам по себе недостаточен для PR.

[lemone112]

Autoresearch 2026-09-06 — lazy CompositorSpring snapshot scratch — NO-GO

Exact base: main@19102c9b4898b9755e3f1e33fc0718184329d0c2 (tree 6e38368f2077275d30e2d48b62d72d0c72154bb3). main повторно прочитан после эксперимента и остался на том же SHA. Production-код не оставлен; ветка/PR не создавались.

Факт → гипотеза → фальсификатор

Факт. CompositorSpring на текущем main создаёт per-controller scratch { value, velocity } заранее, хотя он нужен только _snapshot() при interrupt/retarget/handoff. Обычный непрерванный compositor-run этот объект не использует.

Гипотеза. Ленивое создание scratch на первом _snapshot() может снизить retained memory обычного compositor owner без изменения его start/frame/finish semantics.

Проверенный минимальный кандидат был только:

private _sample: { value: number; velocity: number } | undefined;

// в _snapshot():
this._sample ??= { value: 0, velocity: 0 }

Фальсификатор был задан до admission: любой semantic/ownership diff; перенос allocation из cold construction в latency-sensitive interrupt/retarget/handoff; любой protected size/import regression; либо отсутствие устойчивого lifecycle memory-win после первого retarget.

Перед выбором сверены актуальный main, открытые PR/issues, docs/architecture.md, docs/benchmark.md, обязательные workflow-гейты и прошлые GO/NO-GO. Кандидат намеренно не пересекается с #309 (MainUnit/spring workspace), #306 (compositor grid), #297 (compiler runtime) и #307/#295 (CI repair).

Среда и baseline

Git clone из execution-среды не был доступен по DNS, поэтому exact source восстановлен из read-only Actions evidence: run 34003820731, artifact 9980299707 (cohort-source-bab3ac8a6622487afb5f41a082f11120fbd4fa01). Архивные SHA-256 проверены; repo.bundle содержит exact 19102c9b…. Использован Node 24.20.0, pnpm/tool snapshot из того же artifact. Все baseline/candidate сравнения выполнены в одной фиксированной среде и на одном source base.

Baseline exact-main source реально собран. scripts/size-gate.mjs на baseline прошёл без изменения порогов; среди зафиксированных import-cost: nano 1011/915, animate 15520/14115, animate+compositor 17464/14487 B gzip/Brotli.

Repeated retained-memory lifecycle

node --expose-gc, по 5,000 controllers на process, 6 независимых процессов на baseline и candidate; одинаковый fake host/target и spring. Измерялись GC-retained deltas по фазам construct → start → first retarget.

Median B/controller:

phase	baseline	candidate	delta
construct	440.5584	400.4560	−40.1024 B (−9.10%)
start increment	16.3080	16.4392	+0.1312 B
first-retarget increment	51.2216	91.2944	+40.0728 B (+78.23%)
total after retarget	508.2032	508.1896	−0.0136 B (−0.0027%)

Это и есть positive control класса: примерно 40 B не устранены — они почти один-в-один переезжают из constructor в первый interrupt/retarget. Для непрерываемого owner retained memory действительно ниже; для owner, которому понадобился snapshot, итог практически идентичен, но allocation теперь происходит именно в latency-sensitive ownership handoff.

Отдельный 50,000-controller construct-only control дал тот же устойчивый сигнал порядка −40 B/controller (примерно −10.9%), то есть результат lifecycle не объясняется случайным отсутствием heap-effect.

Size

На побайтно одинаковом build procedure для dist/compositor/index.js:

                 raw   canonical gzip   Brotli-11
baseline        15844       6110           5595
candidate       15846       6112           5593
Δ                  +2         +2             -2 B

Full size-gate остаётся ниже потолков, но это не non-regression: защищённый canonical gzip ухудшен 6110 → 6112 B. По текущему benchmark-контракту threshold headroom нельзя считать выигрышем, а смешанное gzip↓/Brotli↑ или наоборот не является size victory.

Семантика / проверки

На candidate реально выполнены и зелёные:

• build + declaration emit;
• test/compositor-retarget.test.ts;
• test/compositor-handoff.test.ts;
• test/compositor-host-owner.test.ts;
• test/compositor-retention-gc.test.ts;
• итого 67/67 tests;
• scripts/size-gate.mjs — PASS существующих budgets;
• 6+6 process lifecycle heap measurements и отдельный construct-only positive control.

НЕТ: Pareto-admission. Кандидат ухудшает protected allocation placement на первом retarget/handoff и canonical compositor gzip на 2 B. Эти два falsifier независимы.

НЕ БЫЛО: полный Vitest, mutation, packed-consumer, Chromium/Firefox/WebKit candidate matrix, exact-candidate-SHA remote CI, независимый final review. После детерминированного нарушения Pareto они не могут превратить этот вариант в GO, поэтому дальнейшее расходование гейтов было бы тест-театром.

Текущий remote workflow plane main всё ещё ремонтируется #307/#295; это не причина NO-GO этой итерации — кандидат отвергнут раньше и сильнее по собственным измеренным регрессиям.

Проход «радикально проще»

Текущий eager scratch оказался более простым законом для существующего контракта: snapshot/retarget остаётся allocation-free. Function-local scratch был бы хуже (allocation на каждый snapshot). Lazy persistent — уже минимальная tested форма и лишь переносит allocation. Новый module/global mutable scratch ради удаления этих ~40 B создаёт ownership/reentrancy/import-retention цену и не финансируется доказанным system win; строить его как обход фальсификатора не следует.

Вердикт / что исключено

NO-GO. Не повторять «lazy-allocate per-controller _sample» как самостоятельную оптимизацию: −40.10 B/controller cold retention оплачивается +40.07 B/controller на первом retarget, total после retarget неизменен, плюс canonical gzip +2 B. Возврат к классу оправдан только если в архитектуре появится уже существующий owner-owned workspace, который даёт snapshot без новой handoff-allocation и одновременно доказывает size non-regression; отдельный global scratch ради этого не строить.

Экспериментальный production-код полностью удалён; локальный checkout возвращён к clean exact base 19102c9b…. PR/merge/auto-merge/default-branch mutation — НЕ БЫЛО.

[lemone112]

NO-GO — убрать повторную нормализацию уже finite-сэмплов в VelocityTracker.velocity() (2026-09-06)

Exact base: main@19102c9b4898b9755e3f1e33fc0718184329d0c2.

Перед экспериментом повторно сверены актуальный main, открытые PR/issues, docs/architecture.md, docs/benchmark.md, обязательный ci-gate.yml, фактический повреждённый ci.yml на main и предыдущие GO/NO-GO. Открытые runtime PR сейчас сосредоточены в spring/compositor/compiler/transform/CI; незавершённого изменения velocity tracker, с которым этот эксперимент конфликтовал бы, не найдено.

Факт → гипотеза → фальсификатор

Факт. createVelocityTracker.push() всегда сохраняет {x,y,t} после finite(...). Поэтому внутри velocity() значения a.x/a.y/b.x/b.y уже конечны. Текущий путь тем не менее вызывает finiteSub(b.x, a.x), а finiteSub снова делает finite(a) и finite(b) перед вычитанием. Для двух осей это четыре повторных проверки Number.isFinite на каждый velocity().

Гипотеза. Только внутри VelocityTracker.velocity() заменить

finiteSub(b.x, a.x)

на

finite(b.x - a.x)

(и аналогично для y). Внутренний finite после вычитания сохраняется: он нужен для overflow разности. Потенциальная выгода — меньше проверок на pointer/pan hot path без новой state, allocation, API или абстракции.

Фальсификатор до кода. Кандидат допускается только если (1) bit-exact сохраняет velocity на полном runtime-domain после push-санитизации, включая overflow, и (2) даёт не синтетический helper-win, а практически значимое улучшение хотя бы source-faithful tracker update+read workload. По канону docs/benchmark.md практическая граница — 5%; CI, пересекающий zero или не достигающий этой границы, не является speed win.

Characterization + positive control

Локальный source-faithful harness воспроизводит текущие finite, finiteSub, advanceSlidingWindow, push и velocity; candidate отличается только указанным выражением. Среда: Node v22.16.0, V8 12.4.254.21-node.26, Linux 6.18.35 x64, AMD EPYC 9V74.

Deterministic adversarial corpus (NaN, ±Infinity, ±0, subnormal, ±MAX_VALUE, ±1e308 и seeded log-domain finite values; hostile/non-monotonic timestamps) дал:

candidate vs baseline: 200,000 / 200,000 velocity components Object.is-equal
mismatches: 0

Oracle имеет positive control. Более агрессивный вариант finite((b.x-a.x)/dt), то есть без обязательного clamp до деления, детерминированно ломается:

a.x = -MAX_VALUE, b.x = +MAX_VALUE, dt = 2
baseline: 8.988465674311579e307
mutant:   1.7976931348623157e308

Следовательно, безопасно убирать только повторную нормализацию operands; overflow clamp разности — контракт, не лишняя защита.

Performance

Сначала проверен изолированный velocity() inner path: 24 позиционно-сбалансированные пары, 10,000,000 вычислений/sample после warmup.

baseline median:  67.603 ms
candidate median: 53.779 ms
paired median improvement: 20.19%
bootstrap 95% CI median: 18.78% .. 20.65%

Это сильный micro signal, но не продуктовый результат.

Затем тот же candidate измерен в source-faithful tracker workload push + sliding-window maintenance + velocity на каждом событии (то есть ближе к реальному pan, где tracker.velocity() читается после каждого push). 24 чередующиеся AB/BA пары × 2,000,000 событий/sample после warmup:

baseline median:  180.951 ms
candidate median: 180.572 ms
paired median improvement: 1.46%
bootstrap 95% CI median: -1.65% .. +4.98%
range: -18.99% .. +18.59%

CI пересекает zero и даже его оптимистичная граница не достигает 5% practical threshold. Поэтому 20% helper-win полностью растворяется в реальном владельце стоимости — sanitization, push, sliding-window maintenance, object/result handling. Называть это системной оптимизацией было бы оптимизацией benchmark-фрагмента по Гудхарту.

Проход «радикально проще»

Сам candidate уже является минимальной локальной заменой без нового состояния. Ещё более короткий путь — удалить post-subtraction finite — не допустим: positive control выше показывает изменение наблюдаемой экстремальной velocity. Контекстные fast/slow branches или отдельный «trusted finite tracker» добавили бы код/maintenance ради эффекта, который в representative slice неотличим от шума.

Вердикт

NO-GO. Четыре повторные finite-check действительно существуют и их удаление bit-exact на sanitized domain; изолированный helper ускоряется примерно на 20%. Но source-faithful push+velocity не показывает практически значимого выигрыша: paired median +1.46%, 95% CI −1.65…+4.98%. Значимой защищённой метрики не улучшено доказанно — production diff не финансируется.

Production-код, тесты, thresholds и workflows не менялись; временного Git-кода нет, PR не создавался.

Проверки

• ДА: актуальный exact main, open PR/issues, architecture/benchmark/CI contracts и предыдущие GO/NO-GO прочитаны.
• ДА: 200,000-component bit-exact characterization + overflow positive control.
• ДА: 24-pair isolated microbenchmark и отдельный 24-pair source-faithful tracker update+read benchmark с paired bootstrap CI.
• НЕ БЫЛО: repository Vitest/property/fuzz/mutation, pnpm build, canonical pnpm size, packed-consumer, browser differential, actual-package allocation profile, remote exact-SHA gates. После фальсификации единственной заявленной product-пользы production candidate не создавался; отсутствующие проверки не объявляются зелёными.
• НЕ БЫЛО: branch/PR/merge/auto-merge/default-branch mutation.

Что исключено

Не возвращаться к «уберём повторные finite у уже sanitized velocity samples» как к самостоятельной performance-оптимизации: текущий evidence показывает только локальный helper-win, а не системный. Возврат имеет смысл лишь как бесплатная часть более крупного, уже доказанного упрощения tracker hot path, где canonical size и product-level latency не ухудшаются.