Working memory

2026-09-25: pretrain v21 trained on constant b’x’ filler — refill() silently fabricated data when the corpus was unreadable; now panics loudly + size floor at construction (data crate). 2026-09-25: upstream burn pre.4 WORKS on sm_120 (isolation smoke green) — the pre4-branch cuEventCreate-700 bug is OUR fork port (vendor/cubecl-fix), fix in flight. 2026-09-25: NASA P10 Rule 5 mandates ~2 assertions/function (research/2026-09-25-nasa-burn-rust-practices.md); –guard is exactly the mandated recovery action. 2026-09-25: fused/ step-time killers ranked (research/2026-09-25-fused-rewrite-plan.md): per-iteration inner-AD arms re-forward + 16 syncs, grad D2H→H2D snapshot round trip, then naive mm; “direct” adjoint kernels were unusable as written (byte-reserialize + host round trip each). 2026-09-25: burn perf playbook = autotune everything (CUBECL_AUTOTUNE_LEVEL only scales benchmarking), comptime Line vectorization, device-derived CubeDim, memory_persistent_allocation + pre.3 CUDA graph capture; pre.4 #5673 = DispatchAutodiffContext contract in extension glue. 2026-09-25: audit cuts landed (dead config fields, max_iter=4 default, max_seq_len wired, loud sidecar/grad asserts); ADR-0009 fused rungs (kill switch: Rung1 >=1s/step, Rung2 parity vs fusion-on burn), ADR-0010 corpus v2 (eval never trains), ADR-0011 loud failures (P10 R5). 2026-09-26: pre4-migration MERGED to main (c15dd4a); the GPU blocker was the MSA arm, not the fork (pre.4 topk feeds garbage indices -> gather OOB; ADR-0012, presets use_msa=false, official baseline runs without MSA). Merged main green on GPU; bench gate alive (first canary row 4081ms). 2026-09-26 AWAY: fusion-flip parked — under fusion burn’s Tensor is the dispatch type; vendored crates downcast bare CubeBackend (48 unsatisfied DispatchKindConversion). Port = per-crate Rung work. bf16 A/B is flag-only, running it at ckpt-1000. 2026-09-26 AWAY: corpus v2 is DOMAIN-SORTED (filter preserves input order: math walls, title junk, code — in blocks). Train CE collapse (0.17) is the model acing the local domain; held-out stays 5.5. Fix: shard.rs routes docs by FNV into 64 files -> ByteStream file-shuffle mixes domains per batch. bf16 compute blocked twice: llvm path strips bf16 mma features (by design — no bf16 registers in the dialect), cpp/NVRTC path broken (150s/step, loss-scalar crash). fp32+llvm+autotune is the working config. 2026-09-26 AWAY night: train-CE collapse is NOT a bug — the 24M-row Engram is an n-gram memorizer (15K row-touches/step, row-level Adam); it legitimately drives mixed train CE to ~0 while held-out stays hard. Judge ONLY by eval BPB. Watch: if eval stalls >7.0 by step 5k, check engram/core gradient balance. corpus v3 (sharded) baseline RUNNING (official_v3, fp32, 1433ms/step, autotune restored). 2026-09-26 AWAY: bf16 compute doubly blocked (llvm strips bf16 mma by design; cpp/NVRTC path broken+slow 150s/step). fp32+llvm+autotune = working config; bf16 returns when upstream llvm dialect gains bf16-lowering. Fused gradcheck: stack overflow in checkpointing interplay — daytime item. 2026-09-26: architecture v2 written into PLAN (fixed-depth core default; MoR routers = PonderNet replacement candidate; MA value-path memory replaces the gated engram arm; FlashLoop/self-play/Rufus-Air mapped). official_v4 running (fixed-depth, no-engram, aux on, corpus v3, 3e-4, 100k). 2026-09-26: byte-LM recipe research (research/2026-09-26-byte-lm-recipes.md): single-pass 20GB @7.5M is off-recipe everywhere — published recipes fix a horizon (1-4GB), subset D_u=T/4..T (≤4 epochs free, ~16 max, shuffle/epoch), warmup+constant+cooldown to ~0.1× peak. BLT ablation: hash n-grams work as INPUT features, n=3-4 first, diminishing returns past 300-500K rows (24M Engram rows ~50× past it). No published n-gram BPB table for mixed text+math — compute our own over the eval tail. 2026-09-26 night: eval anchor ladder over eval_2m_v2 — uniform 8.0 / unigram 5.17 / 5-gram+backoff 2.572 (24-line counter beats our 7.5M pipeline today). official_v4 resumed cleanly from ckpt 1000 THROUGH the skip_bytes fix (first production validation). WSD cooldown already existed (research verdict resolved by code read). PonderNet deleted (ADR-0013); random-depth + MoR queued as re-entry arms. 2026-09-27: cubecl Bool->Float cast is BROKEN (returns 0 for true) - never build a numeric indicator from bool_tensor.float(). Use mask_fill on a float tensor instead (zeros_like().mask_fill(mask, 1.0)). Found via the NaN firewall miscounting (50/50 window) and killing a healthy run at step 2000. burn’s NdArray path is correct, so CPU-only tests CANNOT catch this class of bug - run the gate with –features cuda. 2026-09-27: fixed per-step cost ~465 ms at 7.5M params (4x tokens costs only 1.47x time); GEMMs are 2-5% of a step, and opt/retr/ema do NOT scale with N (84->85 ms at 1.6x params) - they are launch-bound. Overhead-bound below ~80M params, GEMM-bound above. CUDA-graph capture EXISTS in burn 0.22.0-pre.4 (Backend::graph_prepare/start_capture/stop_capture/replay) but burn’s optimizers are FUNCTIONAL (new param tensors every step), so a graph would write to dead buffers - in-place param updates are the prerequisite. 2026-09-29 CORRECTION to the line above (it is the source of the ~465 ms in 10+ docs): THE 465 ms IS NOT A MEASURED CONSTANT and the 2-5% arithmetic share is wrong - both were fitted to STEP-0 readings. Warm (release, quiet card, CUBECL_AUTOTUNE_LEVEL=3, –timers, step>50): 249/240/250 ms at steps 50/100/150, i.e. ~245 ms, and a step-0 step is 5549 ms in the SAME config - 23x, because the cubecl autotune cache benchmarks every candidate at runtime over the first steps. --timers PRINTED on step % 50 == 0 only and was NOT tied to –log-every, so a short run could only see step 0 - that defect is FIXED in b8a47ee, the cadence is now step == 0 || step % log_every == 0 (lib.rs:1196) and a warm step is reached by step 2; every reading quoted in this line predates the fix. THE ~465 ms LINE’S CONCLUSION IS CONFIRMED ANYWAY, with an instrument: the GPU is 13.3% utilised, 142/180 samples at <=5% (nvidia-smi 2 Hz, 150-step warm run, batch 32). Launch-bound, measured rather than inferred. Arithmetic share is ~16%, not 2-5% (~40 ms GEMM / 245 ms step). The opt/retr/ema 84->85 ms sub-figure is superseded: warm it is opt 43-47, retr 52-61, ema 0.0 - and retr is a FIXED cost (8x data = 1.2x retr). CUDA-graph capture is CONFIRMED 5/5 on this GPU (vendor/cubecl-fix/cubecl-cuda/tests/graph.rs), not wired; blocker is that a capture window refuses stream reads/syncs/handle writes (client.rs:1288-1296) and a step needs all three, so capture ONE stage. The in-place-param prerequisite above is STILL TRUE and is now the binding one. 2026-09-27: the 1B GEMM answer, measured on this GPU: cuBLAS f16-in/fp32-accumulate 43.7 TFLOP/s vs cuBLAS fp32 13.2 vs our cubecl f32 3.5-7.6 (TF32 only 17.5 - pointless on consumer Blackwell). A hand-rolled WMMA kernel gets 8.4 and LOSES to plain SGEMM. So: route big matmuls through cuBLAS, do not write kernels. Integration crux: a burn tensor’s buffer is a cubecl Handle, not a raw pointer, and cubecl-runtime 0.11.0-pre.4 has no pointer-resolution API. 2026-09-27: held-out eval was unsound for A/B - the stream advanced between evals, so the same checkpoint scored 6.443 and 6.551 depending on position. Fixed: rewind() per eval + –eval-batches 20 (100 KB) + the byte count printed in the eval line. Eval forwards must use Module::valid() (no autodiff) or 20 batches of never-backwarded graph nodes OOM the 16 GB card. Numbers before this commit: comparable only within a run, never across runs/resumes. 2026-09-27: OWNER DECISION on KDA - it stays and both stacks go to SOTA optimization. “KDA is the best linear we have; our implementation is GDN2 and KDA, and KDA is built on GDN2, so send agents to bring BOTH projects to SOTA optimization.” So: no replacement, no cut, no quality A/B against a cheaper mixer. Three agents own it - GDN2 core (per-op dissection of fwd+bwd, which kernel the trainer really runs, the cheapest fixes), the SOTA ceiling (FLA/FlashKDA/Qwen3-Next reference numbers, our fraction of roofline, three routes ranked), and the precision path (the fused chunked kernel is f32-only, so –bf16 falls back to tensor ops and is SLOWER than fp32 on this box - that is the missing 2-4x). 2026-09-27: THREE STRUCTURAL BUGS found by the critic + reviewer on my own diff, all fixed. (1) The loop did not loop: every iteration ended with h = h_ctx, so the block output never reached the next iteration - 4 weight-tied passes over x + sum(e_k), ~2 effective layers, 4x the fwd/bwd for ~1x capacity. (2) residual_scale was initialized to 0, so dL/dy = 0 and the KDA arm, all three expert FFNs and both controller gates had NO gradient at init (ReZero specifies identity init = 1). (3) The NaN firewall masked the loss SCALAR only, which does not stop a NaN that came from an activation - backward still produced NaN grads and the optimizer wrote them into the weights; the step is now SKIPPED entirely. Plus: burn’s clone() shares the device buffer and mask_fill goes in-place on CUDA at 2 handles, so the “raw” logging copy read the masked 0.0 (ce=0.000 in the log, best stuck at 0 forever). 2026-09-27: ByteStream’s parquet branch returned the full arrow batch length WITHOUT copying it into the read buffer, and both callers slice to that length - reading ANY .parquet corpus panicked or ingested garbage. books (2.1 GB) and qa (2.4 GB) have never been trainable. Found by chasing a suspicious anchor number; the same bug made the anchors tool measure the thrift/snappy container, which is where my wrong “books is the highest-entropy domain” claim came from (real: 4.602/2.482, not 7.006/6.759). 2026-09-27: the EMA JEPA teacher was fed targets (the one-byte-shifted LABELS) with hashed_ids=None, so its Engram arm was inert too - the wrong target on every step of every run since the aux objectives shipped, invisible to every finite/closeness test (f8bd6ed fixes it: the teacher now consumes the student’s three inputs, the offline precompute_jepa_targets definition). Every prior JEPA/aux-vs-pure-CE A/B conclusion is VOID, and a resume across it is a different objective. DSpark’s window tokens are the label sequence too (one-position shift, named in the commit, NOT fixed - needs its own A/B). 2026-09-27 (env, two landmines): /home hit 100% mid-build (356 MB free) - deleting target/debug/incremental/* older than the live sessions freed 2.2 GB and unstuck mold; a linker failure that says “Disk full?” is the disk, not the patch. And raw n-gram keys (fnv as u32 as i64) PANIC on the Flex CPU backend (checked i64->i32, burn-std cast.rs:218) where CUDA wraps - that is 5 red model_seam tests today; mask the low 30 bits in CPU fixtures (the 12-bit slot mask is untouched, so the row read is the same). 2026-09-27 (ADR-0016): TWO of the three “backend precision bugs” were not bugs. bool.float() is CORRECT on cuda (raw AND dispatch path, both backends) - line 15’s cause is wrong; the real one was clone()/mask_fill aliasing (line 20, since fixed). f16 matmul is CORRECT too (matches fp32 to 1e-2) - only the f16 tensor-core CANDIDATE dies (builtin.fp16 to implement dyn SizedType) and the autotuner falls back SILENTLY, so a panic in a log is not a failed matmul. Only bf16 is a real gap: the LLVM dialect (our default backend - cubecl-cuda’s cpp feature is off, so we are on pliron/nvptx, not NVRTC) has no bf16 type. The gate that settles all three: cargo test -p backend-parity --features cuda --test backend_parity. 2026-09-27 (env): 5+ agents sharing one target dir means the cargo build-dir lock, not CPU, is the bottleneck - a 3-line test crate waited 25 min for a slot. Do NOT enable a burn feature your crate does not need (flex re-fingerprints the whole stack for everyone; ndarray is already unified). And never pkill -f <pattern> where the pattern matches your own command line - it kills the shell mid-script, silently skipping the rest. 2026-09-28: the JEPA mask seam (aux::set_mask_stream) was a pair of PROCESS-GLOBAL AtomicU64s, so the mask was a function of (seed, step, whatever any other thread last stored) - mask_is_a_function_of_seed_and_step was red 15 runs in 40 and green 30/30 alone. The derivation was right; the WIRING was shared state. It is now a thread_local! Cell + a no-ambient-state mask_from(seed, step, ..) with a pinned FNV golden, so the cross-process claim is assertable without a second process. Called once per step at train/src/lib.rs:1002, before the loop. 2026-09-28 (pre-existing, NOT aux): mor::tests::selects_exactly_k_per_position_with_a_floor_of_one and mor::tests::bce_label_is_a_fresh_topk_of_the_current_scores are red on the CPU/flex gate - argtopk returns 0 or 2 picks for k=1. Red with a pristine aux.rs, unrelated file; nobody owns it. 2026-09-29 (statistics, cost me a red test): a uniformity band must be sized for the FAMILY of bins, not for one bin. burn-engram’s 0.75..1.25x on 257 bins is a 2.4-sd bound, which fires on a perfectly uniform hash ~1 run in 3 - it did, on a bin at 1.15x, while the histogram’s chi2 was 235/256 (uniform). 257 bins need ~3.7 sd; 997 bins need ~4.2 sd. Always report the measured chi2, never a “N sigma” figure that forgot to multiply by the bin count. 2026-09-29 (multi-agent hazard, bit me): chore(vendor): carry the library's uncommitted work into a commit (4a5f639) swept up another agent’s in-flight edits, and chore(vendor): delete the 8 library crates no product manifest can reach (3d5c883) then DELETED burn-fastblt - mid-task, under me, work included. In a shared checkout assume your uncommitted diff can be committed by someone else and your crate can be deleted; commit early, and re-check git log + ls vendor/burn-fused/crates/ before the last mile. Corollary: cargo fmt -p <pkg> reformats OTHER agents’ files in the same crate - harmless (CI wants it) but it lands in their diff, so do not git checkout them back. 2026-09-29: Tensor::set_require_grad(true) is a HARD PANIC on a non-autodiff backend, and on an autodiff one it silently UN-FREEZES a frozen param — burn-spectral’s retract forced it, so retract was uncallable on plain NdArray and re-tracked masters the caller had frozen (ADR-0011 class). Mirror is_require_grad() instead of forcing it. Also: a [[test]] required-features WITHOUT a file-level #![cfg] still builds an empty binary and prints a green 0 tests ... ok — need both, or the false green survives. 2026-09-29 (bf16, measured, sharpens AGENTS.md 2.1): the bf16-matmul refusal is ONE failure wearing four costumes — burn casts matmul’s rhs to lhs’s dtype, so “bf16 x f32” reports rhs=Float(BF16) and dies identically; and f32->bf16 CAST works fine (only the f32 READBACK is refused, Err(DTypeMismatch{expected:F32,actual:BF16})). So “does bf16 matmul work” is not a per-shape question and the cast dying is not a thing that happens. 2026-09-28: RETRACTS the 2026-09-25 line above it. The cuEventCreate 700 is NOT the cubecl fork: it is cubek-reduce 0.3.0-pre.4’s top-k index kernel, whose pre.4 fast-path guard reaches asks “is this candidate at least the k-th value?” and cannot tell an EMPTY slot (min_value seed) from one holding -inf, because -inf < min_value is a TRUE comparison. The unfilled slot then emits its u32::MAX seed coordinate AS AN INDEX and the caller’s gather reads out of bounds. pre.3 had no guard, so this is a pre.3->pre.4 regression. vendor/cubek-fix (ADR-0015) fixes the OOB (measured: zero out-of-range indices on every fixture, masked rows included); the picked SET on a partially-masked row is still wrong (trailing slots repeat one column) and the gate is #[ignore]d with that reason. 2026-09-28: two facts about burn’s argtopk that cost an hour: it ASSERTS k < n (orderable.rs:614, so k == n is not writable in one call), and the index dtype is backend-defined (I64 from ndarray, I32 from cubecl) so a consumer must convert rather than cast-assert. 2026-09-29 (corrects the 2026-09-28 “nobody owns it” line above): both mor::tests are GREEN and owned — they were fixed in 143a2c9, which found TWO defects in the same six lines (burn-mor hard-cast its top-k indices to I64 while the device Int dtype is I32, so the mask comparison read bytes and a k=1 mask came back with two slots set; and the one-hot was summed over the size-1 axis instead of the k axis, so only the k=1 case ever ran). cargo test -p dormouse-core --lib is 37/37. If you read a red mor test, re-run it before believing it. 2026-09-29 (sm_120, measured today): the ADR-0015 argtopk fix is NOT green on this box — cargo test -p backend-parity --features cuda --test topk_gather_parity fails “masked: 2 row(s) picked the wrong k”, i.e. -inf-masked score rows still mispick (the ndarray arm passes). So anything that routes through burn_mor::topk_gather / topk_indices_last is riding a primitive that fails its own gate today; burn-mor’s topk_indices (argsort_descending + narrow, topk.rs:44) is the one that works, and core/src/mor.rs:59 rides that one on purpose. 2026-09-29 (measured, tools/mor_ab.sh preflight, small + mor, batch 20 x seq 512, fp32, pure CE, release, quiet card, window 204 800 B): a steady step is 1068 ms (fwd 251 / bwd 674 / opt 73 / retr 69; the 14.1 s at step 0 is autotune), so a 2k-step arm is ~36 min and the 3x2 sweep is ~3.5 GPU-h — the queue’s cost is NOT what blocks it. What blocks it: fused kda=64/0 in BOTH arms, i.e. the release binary’s attention arm still has zero backwards (AGENTS.md 3.2), so a control re-baseline is a precondition, not a formality. The MoR arm’s rung-1 smoke is clean: 0 NaN, held-out 8.048 -> 7.575 -> 7.024 -> 6.780 over 100 steps (the collapse canary is not firing), router BCE finite and present (weighted aux=0.0337 at step 0 = 0.05 x 0.674 raw), depths d1 6.731 / d2 6.668 / d3 7.189 / d4 7.216 at step 75. 2026-09-29: 21 feature-gated test files in vendor/burn-fused (16 in burn-gdn2, 4 in burn-kda, 1 in burn-sct) had NO [[test]] target, so the default cell built each one, #![cfg]-compiled it away and printed a green running 0 tests ... ok — 20 of those lines in cargo test -p burn-kda -p burn-gdn2. tools/test_targets.py now fails on the class (a file that runs nothing on the default cell must declare a target whose required-features covers every non-default feature its cfgs name). Adding the targets exposed TWO tests that had never run and are RED: autodiff_nested_balanced::the_op_declines_a_nested_graph_and_the_ops_path_carries_the_gradient (the op still builds a node over an all-intermediate graph, so the output is a leaf — the 8fa5d4c defect is LIVE on ndarray, which is the CPU proxy for AGENTS.md 3.3’s open “does the attention arm train”) and test_chunk::test_chunk_vs_reference (4880/4880 cases fail, max_diff 1.38e-2 against a 1e-2 global, identical at all 5 chunk sizes). 2026-09-29 (oracle, the two papers’ own code): deepseek-ai/Engram@main engram_demo_v1.py and deepseek-ai/DeepSpec@main config/dspark/dspark_qwen3_4b.py are fetchable and runnable headless (stub transformers/tokenizers; torch 2.14 CPU is enough). Both are now wired to tests that consult them: burn-engram/tests/engram_oracle.rs (gate: that is NOT in tools/wt.sh test, which is --lib on the three crates) and dormouse-core/src/dspark_oracle.rs (in the gate). Cost me a day of the same lesson: an f32 golden constant needs NINE significant digits — format(v, "g") is six and silently truncated every column to 0.49975, which fails a test on CORRECT code. And the claim is “agrees to N”, never “bit-for-bit”: the Engram gate agrees to 1e-5 on the gate, 2e-5 on the module forward, 1e-5 on the conv, EXACTLY on the prime ladder. 2026-09-29 (measured, both oracles): add_scalar(1e-6) vs the reference’s clamp_min(1e-6) is 1.04e-4 at |s|=1e-6, and |s| is bounded by sqrt(D) so the band just above 1e-6 is not a fixture choice, it is the ONLY place the two formulas are separable. Below 1e-6 the reference’s own f32 answer moves by 5e-4 when the 64-term dot is summed the other way round — clamp_min floors the radicand at 1e-3, so the gate there is sigmoid(±1e-3) and depends on the SIGN of pure cancellation noise. Those rows are unresolvable and must be EXCLUDED, not covered by a wider tolerance. 2026-09-29 (the library’s gate, measured cold in wt/libgate off 46abc68): cargo test --workspace --exclude burn-fused-benches --exclude cpu-probe --exclude launch-probe --no-fail-fast from INSIDE vendor/burn-fused runs 34 binaries / 253 tests and is RED on 3: burn-engram/tests/engram_oracle.rs:293 (lib.rs:234 add_scalar(1e-6) vs the reference’s clamp_min, 1.036e-4 vs a 1.709e-5 bar - a REAL bug, already in the 2026-09-29 line above), burn-fused/tests/facade.rs:150 (gen_facade.py –check: burn-gdn2’s default is now [“std”,“binary-tests”] and the generated facade still assumes [“std”] - stale generated file, the drift detector working), and burn-gdn2/tests/autodiff_nested_balanced.rs:339 (ORACLE.md 6.1’s undiagnosed one). 1401 s wall cold, 686 packages, 41 GB of target on a /home that filled up TWICE. burn-spectral’s 3 retract panics (TEST-AUDIT.md finding 2) are FIXED at HEAD - 42/42 green. 2026-09-29 (the same run, two facts that are invisible to any guard): (1) the three required-features = ["autodiff"] targets run with NO feature flag, because burn-spectral/Cargo.toml:37 depends on burn-kda with features = ["autodiff"] and that cascades to burn-gdn2 - a green line resting on an unrelated crate’s manifest, which tools/test_targets.py structurally CANNOT see (it compares required-features against the file’s own cfgs, not against what other packages enable). (2) an explicit --features burn-gdn2/autodiff,burn-kda/autodiff cell re-ran all 10 of those binaries for 781 s and added ZERO tests - so the second cell CI does not have is not worth its cost either way. burn-fused/tests/gpu_production_shape.rs is a measured 0-test target (no [[test]] block) and test_targets.py misses it because it only walks vendor/burn-fused/crates/*, not the meta crate at vendor/burn-fused/burn-fused/. 2026-09-29 (desktop, this box: niri + noctalia 5.2.0 + nvidia 615 + 2 external monitors): /sys/class/backlight is EMPTY for nvidia-drm, so every sysfs-brightness path (noctalia’s included) reports “brightness control unavailable” out of the box — the only control is DDC/CI, which needs ddcutil + i2c-tools (NOT installed by default; ddcutil’s 60-ddcutil-i2c.rules tags /dev/i2c-N with uaccess, so no group membership and no re-login). With ddcutil 3.0.2 noctalia’s own ddcutil backend is BROKEN: every up/down/set writes setvcp 10 100 (max) and it re-applies 100 to both monitors at every shell start; the exact command form it generates works when run by hand, so the fault is its value computation, not ddcutil or the bus. Its msg brightness-set N also takes the monitor as the FIRST positional arg, so a bare brightness-set 50 silently means “target 50, value default” = 100. 2026-09-29 (the fix, 15 lines): ~/.local/bin/brightness up|down [step]|set <1-100>|get calls ddcutil on every detected bus and shows the OSD via noctalia msg brightness-osd; niri’s XF86MonBrightness* bind to it. ddcutil -b takes a bus NUMBER, not /dev/i2c-N. niri msg action spawn-sh takes ONE command string — -- brightness up is rejected (“cannot be used multiple times”), -- "brightness up" is the simulation that works. Both monitors support VCP 0x10 and 0x14 (colour preset); 0x13 contrast is unsupported on both. 2026-09-29 (RETRACTS the 2026-09-29 “the fix, 15 lines” line above, same day): ddcutil is NOT the answer for the Xiaomi. Its DDC block ACCEPTS AND STORES every VCP write - 0x10 brightness and 0x16 red gain both read back exactly what was written - and applies NONE of them, while 0x13 reports DDCRC_REPORTED_UNSUPPORTED and 0x14 fails verification. Only a human eye can tell those apart: a readback is not an application. LG’s DDC is fine. Fix = dim BOTH panels in software over wlr-gamma-control (gammastep -b G:G -t 6500:6500 -r -l 55.75:37.62; the -l is mandatory or it exits on a missing GeoClue, and it is unused because day/night are pinned). gammastep applies to ALL outputs - there is no per-output client in the Arch repos and niri has no gamma IPC - which is why the working LG was moved to software too: two independent backlight percentages do not step together, one global ramp does. niri HAS zwlr_gamma_control_v1 (in the binary) but exposes no action for it. 2026-09-29 (two bugs the same script cost, both invisible without a fast-keypress test): (1) with no lock, 3 rapid down presses moved the level by ONE step - every press read the level file, and the file was written at the END, so concurrent presses all read the same value and the last won; key repeat fires faster than the ~0.2s apply. Fix: exec 9>lock; flock 9 around the read-modify-write. (2) That lock then DEADLOCKED every press after the first: gammastep is a backgrounded child that outlives the script and INHERITED fd 9, holding the flock for as long as it ran, while the next press could only release it by pkill-ing gammastep from inside the lock it was waiting for. Fix: gammastep ... 9>&- &. A lock fd that a surviving child inherits is a deadlock, not a lock. 2026-09-29 (ДИСПЕТЧЕРСКАЯ ОШИБКА, записано чтобы не повторить): запустил 5 агентов одновременно, каждый из которых делает ХОЛОДНУЮ сборку vendor/burn-fused = 686 пакетов / ~1400 s / 41 ГБ target-диска. Нарушил собственное правило “одно тяжёлое за раз” (AGENTS.md 1.5), которое сам же и записал в план двумя часами ранее. Итог: 4 cargo одновременно, 10-12 rustc по 4.5-5.5 ГБ, available RAM упал до 11 ГБ при пороге 25, /proc/pressure/memory some до 8.32%, swap 22 ГБ, /home до 95%. Это предзаморозка - AGENTS.md 2.4 описывает ТРИ полных заморозки именно так. УРОВЕНЬ, КОТОРЫЙ Я ПРОПУСТИЛ: диск это производная. Настоящая ошибка - параллелизм, а не место. Один кран = один кран; несколько агентов на ОДНОМ кране допустимы только если они НЕ строят одновременно. pgrep -x cargo в preflight есть у tools/wt.sh, но агент может звать cargo напрямую и preflight не спасёт - нужен залп, а не проверка. УБИТЬ cargo НЕЛЬЗЯ ЧТОБЫ ОСТАНОВИТЬ АГЕНТА: PID меняются, агент перезапускает сборку, работа сгорает впустую. ram-guard (active) сам убьёт тяжелейшее на 8 ГБ - то есть он защитит систему ценой сожжённой работы агентов. Убивал дважды, эффект оттупил, давление упало само (8.32% -> 0.58%) только когда сборки стали упираться в ram-guard и не расти. ПРАВИЛО НА БУДУЩЕЕ: перед запуском N агентов спрашивать не “свободен ли CPU”, а “сколько из них будут СТРОИТЬ”. Агент на чтение/ревью/исследование - бесплатный. Агент с холодной сборкой vendor/burn-fused - это 41 ГБ и 25 ГБ RAM, и он не параллелится никогда. 2026-09-30 (класс, три раза за ночь, ВАЖНО): выключение DSpark по решению владельца (dspark_weight 0.1 -> 0.0 во всех пресетах, 3b39068) сломало ТРИ теста, и все три требовали от фикстуры того, что выключено намеренно: (1) model_seam::aux_heads/forward_smoke/gradient_flow - .expect("dspark only") и dspark_weight > 0; (2) preset_exec - JEPA-вычитание с клона, где DSpark выключен, даёт None вместо aux; (3) dormouse-train::aux_losses_and_ema_teacher - assert!(cfg.dspark_weight > 0.0, "presets must ship aux ON"). Плюс четвёртый, aux::tests::mini(), наследовал пресет и падал на своём же .expect. ПРАВИЛО, которое из этого следует: тест, который берёт конфиг из ПРЕСЕТА, проверяет не то, что пресет по умолчанию верный, а то, что рука работает. Как только дефолт меняется по решению владельца, такой тест обязан включать руку ЯВНО в своей фикстуре - иначе он либо краснеет (как здесь) либо, что хуже, проходит вхолостую. Все четыре фикстуры теперь включают dspark_weight явно, с причиной в комментарии. СМЕЖНОЕ и более дорогое: model_seam::two_models_one_seed_are_bit_identical был ЗЕЛЁНЫМ и я на нём построил утверждение «CPU детерминирован» в двух rulebook-документах. Оказалось, Device::seed() НЕ перематывает потреблённый поток, Device::flex() возвращает разделяемое устройство, и второй билд видел другой поток - тест мерил сам себя. Позеленел/покраснул за ночь без изменений в коде фреймворка. Общий класс: зелёный тест, структурно неспособный провалиться, хуже отсутствия теста - он даёт ложную уверенность, на которой строятся документы. Теперь этот тест проверяет только то, что проверяемо в одном процессе (два РАЗНЫХ сида не должны совпадать), а остаток репортует с причиной вместо assert_eq!(0). 2026-09-30 (ФАЛЬСИФИКАЦИЯ ТРЁХ ФИКСОВ, один не прошёл — и это важнее двух прошедших): откатил каждый из трёх сегодняшних фиксов и убедился, что тест краснеет. DSpark (логит-форма): откат -> 2 красных, восстановление -> 17+8 зелёных, ДЕРЖИТ. e2m1 (чётный код): откат -> fp4_ties_match_the_formats_rule красный, ДЕРЖИТ. Fused RMSNorm-ядро (#[comptime] threads): откат -> 0 красных, набор проходит. Причина: гейт вообще не исполняет ядро — BURN_DEVICE не встречается ни в одном тесте burn-rmsnorm, required-features в его Cargo.toml НОЛЬ. То есть правка 34c5631 компилируется и НЕ ПРОВЕРЯЕТСЯ ничем. Это не значит, что она неверна (ошибка LLVM-верификации до неё была замерена на реальном запуске), но означает, что у этого ядра нет гейта, который может покраснеть. Пока это так, любой мой или чужой правки в fused.rs придётся верифицировать только через BURN_DEVICE=cuda руками. ПРАВИЛО, которое из этого следует, и оно обратно всем нашим привычкам: скриншот зелёного прогона после фикса — не свидетельство, что фикс держится. Проверка «откатить и посмотреть» сегодня спасла бы два фикса и поймала третий. Агент это делал (mutate_kernel.sh, falsify.sh) — и я должен был тем же для своего фикса, а не ограничился «тест зелёный». 2026-09-30 (НАХОДКА, не исправлено, отдельный кран): после починки e2m1 (dc5d667) выяснилось, что эталон crates/dormouse-core/tests/e2m1_oracle.rs покрывает ТОЛЬКО ActFormat::Fp4. Второй формат, ActFormat::Int(bits), не покрыт ничем: ни одного теста против внешнего эталона. Его реализация на act_quant.rs:96-100 — norm.round().clamp(-l, l), то есть round-half-AWAY-FROM-ZERO на 256 уровнях. Ничьих там 2 из 256, и формат их правила не задаёт; сравнить не с чем. Это ТОТ ЖЕ класс, что закрыт дважды сегодня (dspark-потолок, e2m1-ничьи): формула, которую никто не сверял. Не исправлено: для этого нужен эталон int8/int4 (bitsandbytes или torchao quantize_per_tensor с int8), а это следующий кран, не эта правка. ПОСЛЕДСТВИЕ ДЛЯ ЧИТАТЕЛЯ act_quant.rs: комментарий //! three levels. This is the test that would have caught it. на строке ~293 относится к СТАРОМУ дефекту fp4 и теперь стоит рядом с местом, которое всё ещё не проверено. Читатель может решить, что весь модуль проверен. Стоит поправить формулировку, когда будет сделан int8-эталон. 2026-09-30 (FUSED RMSNORM: 34c5631/9ac0377 ОПРОВЕРГНУТЫ, и найден ВТОРОЙ дефект): ядро не понижалось (Expected operand type llvm.ptr, but found builtin.integer) с момента написания, и виноват оказался НЕ comptime-ширины, а цикл дерева свёртки: while s > 0 { if tid < s { partial[tid] += partial[tid+s] } sync_cube(); s /= 2 } — чтение-изменение общей памяти по индексу из ПЕРЕНОСИМОГО переменной цикла, при runtime-числе итераций. Постоянная лестница vendor/burn-fused/crates/burn-rmsnorm/tests/lower_probe.rs (каждая ступень — отдельный процесс: падение запуска отравляет CUDA-контекст). p2 (shared, comptime-размер, один барьер) — ПОНИЖАЕТСЯ. p4 (барьер в runtime-while БЕЗ shared вообще) — ПОНИЖАЕТСЯ, значит «барьер в цикле» не при чём: chunk_cube.rs:243, sinkhorn_cuda.rs:98, moe_fused.rs:212 так и делают и работают. p9 (дерево БЕЗ единого барьера) — ПАДАЕТ, значит и барьер ни при чём. p6 (та же ядро, свёртка сериализована) — 1.72e-7. p10 (то же свёртка, for k in 0..log_threads с comptime-границей) — 1.72e-7. Фикс — один заголовок цикла, и это ровно форма уже работающего fused_attnres.rs:351-357. Флаг BufferArg move-vs-.clone() из брифа ОПРОВЕРГНУТ: p8 через собственный rmsnorm_cuda (move) падает так же, как ступени с .clone(). После фикса: worst 1.168e-7 против scalar f64 на 84 выходах, asked 6 / skipped 0. ПРАВИЛО, обобщающееся: на этом бэкенде cubecl разворачивает for с comptime-границей, и барьер внутри такого цикла попадает в линейный код; тот же цикл с runtime-границей — нет. ВТОРОЙ ДЕФЕКТ, найден в момент, когда ядро наконец понизилось, и НЕ исправлен: tier-(a) эталон краснеет на case d2 (dims 1 2 2) — 5.245e-1 относительной ошибки, где тензорный путь даёт 7.29e-8. Сентинел -999.0 показал, что хвостовые КУБЫ ПРОСТО НЕ ВЫПОЛНЯЮТСЯ (не «неверно», а «не записано»). tests/d2_isolate.rs — минимальный воспроизводитель и таблица исключений: 4-строчное ядро без shared и без барьера теряет те же кубы; сетка отрабатывает (1..64 куба, все полные); CubeDim 32..1024 режут одинаково; это НЕ гонка чтения (4 чтения совпадают, client.sync() ничего не меняет). Остаётся ФОРМА ВЫХОДНОГО ТЕНЗОРА: то же ядро, та же сетка из 4 кубов, та же длина — [8,2] выполняет 2 куба, [16,1] выполняет 4, [1,1] — 1. Правило живёт внутри launch-пути cubecl и НЕ изолировано. Поэтому rmsnorm_cuda теперь ОТКАЗЫВАЕТСЯ при d < MIN_FUSED_D (4): это замеренная оболочка, а не выведенный закон. Отказ — ответ ADR-0019, а не обход моего бага: тензорный путь корректен и SKIPPED инкрементируется, то есть отказ СЧИТАЕМЫЙ, а не тихая неверная цифра (класс 8fa5d4c). ПОЧЕМУ ГЕЙТ НЕ МОГ ПРОВЕРИТЬ САМ СЕБЯ ДВАЖДЫ: его счётчиковое утверждение было takes == skipped_delta, то есть «один skip на ask» — ЭТО ФОРМА МЁРТВОГО ЯДРА, и пройти оно могло только пока ядро не запускалось (именно так 34c5631 и 9ac0377 и «прошли»). Плюс два теста делили process-global счётчики без блокировки и читали took 7 asked, 1 skipped при шести прогонах. Ошибка в гейте того же класса, что и ошибка в коммит-сообщении: утверждение и его текст говорили разные вещи. 2026-10-01 (ИНЦИДЕНТ, без потерь): mid-lane коррекция отправлена на ОШИБОЧНЫЙ sessionID → создался второй писатель в wt/mhc-model параллельно с живым автором. Двое коммитили в одно дерево; финал согласован (тесты 74+8+15+50+8 зелёные, второй сам починил тип первого). Урок: перед sessionID-продолжением сверять, ЧЬЯ это сессия; коррекции в живую дорожку — только через её собственный sessionID. ADR-0022 существует именно за это. Плюс: гейт Eq.3 mhc «демонстрировался» в отчёте, но НИКОГДА не запускался — упал дважды в собственном тесте (крейт был прав). Третий случай класса «гейт, который не мог упасть» за ночь.

2026-10-01 (КЛАСС, который сегодня закрывается — «гейт, покрывающий не ту половину функции», и он НЕ про tolerances): d8fa449 заявил «fused adjoint НЕВЕРЕН (4.5e-2..2.6e-1 на q/k/v, beta_proj, decay.b_alpha)». fused_adjoint_f64.rs при этом ЗЕЛЁНЫЙ, «fused adjoint верен по слагаемым». Оба правы, потому что это РАЗНЫЕ функции: зелёный гейт грузит ref_bwd_f64.bin = T=16, chunk=16 = ОДИН chunk = только BK1 (внутричанковая), а расхождение d8fa449 измерено на T=256 = 16 chunks = BK2 (обратная рекурсия по состоянию) + склейка d_k_bptt/d_e_bptt/d_s_shift. Заголовок этого файла ПРЯМО говорил, что половины не касается, и даже называл причину: «двухчанковый forward не совпадает с f64-транскрипцией вовсе (8.3e-1)». ПРИЧИНА БЫЛА ОТОЗВАНА c305ec5 (на 5ч38м раньше, чем d8fa449 на неё опёрся): виновата была ОДНА СТРОКА ЭТАЛОНА tools/gen_bwd_f64.py:258 — np.exp(g_last - G), где g_last уже exp(G_last), т.е. cumsum экспонентировали ВТОРОЙ раз. Ни одной строки прод-кода. c305ec5 также ПЕРЕГЕНЕРИРОВАЛ ref_bwd_f64_carry.bin (двухчанковый f64-ГРАДИЕНТНЫЙ эталон, все 7 градиентов, все координаты) и НИКТО его не подключил: load() жёстко брал одночанковый файл. Эталон для непокрытой половины лежал на диске, корректный, неиспользуемый 5.5 часов. ПРАВИЛО, которое это обобщает: заявление «объект X неверен» нельзя сверять с гейтом, пока не названа ФУНКЦИЯ и ЕЁ ДОМЕН. Здесь домен — число chunks, и оно различалось (1 против 16) между двумя гейтами об одном коде. Симптом, по которому это видно: у «неверного» и у «верного» нет общей строки в сообщениях об ошибке — потому что это не два утверждения об одном. Второе, уже общее: когда гейт честно пишет в заголовке, какой scope он НЕ покрывает, это обязательство, а не сноска. Мёртвый scope переживает отзыв его причины, потому что заголовок никто не перечитывает.

2026-10-01 (МАШИНА, дорого, и free -g этого не показывает): cargo build --tests для burn-gdn2+burn-kda = 20 тестовых бинарей, и cargo ЛИНКУЕТ их ПАРАЛЛЕЛЬНО: 20 rustc → 19 collect2 → 38 ld.mold. Измерено: /proc/pressure/io full avg10=86.25, при этом /proc/pressure/cpu = 0.00 и /proc/pressure/memory = 0.00, free -g 28 ГБ avail, load 320. То есть это НЕ медленная сборка, а ДИСКОВОЕ насыщение: ld.mold по 1.6-3.4% CPU, все в D-state. AGENTS.md 2.4 (RAM-дисциплина) назвал бы эту машину здоровой. Отсутствующий сигнал — именно CPU pressure. ХУЖЕ: SIGKILL по cargo/rustc НЕ убирает ld.mold, пока он в D-state — процесс выживает, держит 9 fd в target dir, очередь IO не сливается, и НОВАЯ сборка голодает (мой rustc: 8m23s elapsed, 00:00:00 CPU) и не может закончиться. Утечка самоподдерживающаяся: то, что забивает диск, есть то, что его освободило бы. kill -9 надо слать в ld.mold НАПРЯМУЮ, циклом, повторно (один проход оставил 19 живыми; ушли только вторым sweep’ом, после смерти родителей, IO 86%→53%). Владельца процесса определять ls -l /proc/<pid>/cwd, а НЕ по имени и не по ppid: осиротев, процесс показывает ppid=1, и всё дерево выглядит принадлежащим тому, кто держит лок. ПРАВИЛО: на этой машине не собирать --tests/--all-targets для многобинарного крейта, пока что-то ещё работает. Один таргет (--test <name>) линкует ровно один бинарь — та же заповедь 1.5 «одно тяжёлое за раз», но на слой ниже: единица ЛИНКОВКИ, а не крейт.

2026-10-01 (МАШИНА, dispatcher-лайн, стоило 35 минут прогона): systemd-run --user --scope НЕ ЖДЁТ. Печатает Running as unit: …, возвращает rc=0 СРАЗУ, а payload живёт дальше внутри scope. Скрипт-драйвер, который после запуска делает kill -0 $pid и при смерти pid’а concludes «прогон умер», теряет прогон молча: он стартует, пишет в лог, и его никто не ждёт — а лог выглядит пустым первые ~40 с (guard копирует бинарь в target/release/guard-image/, потом CUDA init и autotune шага 0). Три попытки подряд так и выглядели: Running as unit есть, params= в логе нет, train не в процессах — а через минуту он появляется. ПРАВИЛО: при --scope завершение прогона детектировать по логу (done steps=), живость — по pgrep -x train, и НИКОГДА по pid’у systemd-run. Второе из того же класса: pgrep -f "target/release/train" матчит СОБСТВЕННУЮ командную строку агента, и tools/first_run.sh из-за этого отказался запускаться («a train process is already running») при нуле реальных процессов — паттерн надо писать классом символов ([t]arget/...) либо брать pid из файла. Третье, из того же запуска: --set — это РУКОПИСНЫЙ match на 33 ключа (config/override.rs:28-71), а не serde; use_mhc/use_situ/use_attnres в нём нет, и документированные AB-инвокации этих рук НИКОГДА не доходили до тренера. Живой путь — --preset /path/to/file.toml: loader.rs’s is_explicit() берёт любой путь, а DormouseConfig десериализуется из TOML. Проверка вовлечённости руки через params= в логе окупилась за 32 секунды.

CI-гейты библиотеки: три правила, которые стоили дня (2026-10-01)

Байт-тождество f64-фикстуры не переносимо между хостами. ref_f64*.bin — это f64-numpy редукции: порядок суммирования выбирает runtime CPU dispatch, а матричные умножения идут через OpenBLAS, собранный DYNAMIC_ARCH ( measured: OpenBLAS 0.3.34.106.0 ... DYNAMIC_ARCH), то есть кернели выбираются по CPU хоста. Проверено и НЕ является осью: версия numpy (зелёный и красный прогоны ставили один numpy-2.5.3-cp312-manylinux), версия python (3.14 и 3.12 дали один sha256), OMP_NUM_THREADS. Правильный контракт уже был в дереве — tools/check_f64_fixtures.py (f32 побитово, f64 к 1e-12; замер round-off ≤4.4e-15, ближайшая неверная формула 4.08e-01) — и его гнал только lib_gate.sh, а CI делал git diff --exit-code.

cargo check -p X --features Y НЕ молчит на несуществующей фиче, а падает — вопреки комментарию в workflow. Ручной список крейтов в джобе cuda-compiles содержал burn-mor (нет cuda) и просил cuda,autodiff у четырёх крейтов без autodiff: 6 ошибок, и цикл умирал на третьем крейте из тринадцати, пряча за собой ещё четыре дефекта в коде. Список теперь генерируется: python3 tools/gen_facade.py --cuda-matrix.

Джоба, которая падает на ПЕРВОМ failure, сообщает 1/N правды, а grep "^error" при CARGO_TERM_COLOR: always не находит ничего (ошибка приходит как \e[1m\e[91merror[E0433]). tools/test-feature-matrix.sh печатал FAIL без единой строки причины. Обе джобы были красные сутки, и читать пришлось сырой лог.

Docs-gate anatomy (2026-10-01, docs-wave2): RUSTDOCFLAGS="-D warnings" gates the doc surface; RUSTFLAGS would also deny the train rlib’s 8 rustc warnings (6 in lib.rs, wave 3’s file) and can’t go green until that lane lands. CI’s docs job was blind twice: no -D, no -p dormouse-train. Wave 1’s review landed on main while its code commit (e56cdb9, config-seam docs) did not — report without diff is ADR-0020 in documentation form; the 40 missing_docs it was green through are closed on wt/docs-wave2.

Config-seams lane (2026-10-01, wt/config-seams): the four doc-coverage §3.1-§3.3 + dead-pub §2 fixes landed as 179bdf3..ad3147f; loader warn is COUNTED not LOUD (the dangerous case is when another candidate loads — a terminal Err never fires there). red→green trick that needs no throwaway code: run the OLD test binary from a scratch cwd holding a broken configs/small.toml (cwd candidates come first in candidates()); before = silence, after = the warn.

2026-10-02 (atlas lane, wt/atlas 0bb1d2d+ccc2ebe): DM_LAUNCH_ATLAS=1 считает запуски по стадиям; тёплый шаг small/b8/s512 = 21 427 запусков (бриф подтверждён; ночной 19 300 — другой рецепт fp16+retract-every 4). KDA = 65.5%, teacher 22.3%, experts 15.0%, engram +4.4% запусков но ~4x стены (scatter+host-adam D2H, гипотеза). opt/retr НЕ зависят от глубины (per-group); retr = ровно 4 равные фактор-пары. Roadmap: graph-capture {iter fwd+bwd, opt, retr, ema} = 99.2% запусков, топ-4 цели −413 из 514 ms@24µs.

2026-10-02 (инфра, трижды за lane): systemd-run --scope-детач бьёт и МОЙ собственный раннер — cmd; echo EXIT=$? печатает EXIT мгновенно, а поезд живёт; wait-цикл на pgrep спасает, но ДВА watcher’а на одном pgrep СТАРТОВАЛИ ДВА поезда одновременно (§1.5 нарушен на 4 минуты, cross выжил). Правило: один арбитр очереди, никогда N ожидающих. Плюс: ENOSPC при checkpoint-save убивает прогон ПОСЛЕ печати ATLAS-строк — счётчики печатать до save (инструмент так и устроен). params= не дискриминатор engram-включённости: use_engram гейтит только forward, таблицы строятся всегда.

2026-10-01 (f16 TC, ИЗМЕРЕНО, wt/f16tc): SizedType-патч РАБОТАЕТ — f16 через burn = 40.05 TFLOP/s @ 5120×768×2048 (0.40 ms; cuBLAS 41.4) и 39.75 @ 5120×2048×8192 (4.32 ms; потолок 43.7, 91%); fp32-сиблинги 8.24/8.89; корректность 1e-2 зелёная. Гейт: f16_gemm_perf –ignored –exact, по dtype на процесс. Два грабли: (1) фикс виден ТОЛЬКО в корневом графе — у vendor/dormouse-fused свой воркспейс без [patch.crates-io], registry cubecl-ir фикса не содержит, тест оттуда меряет непатченный стек; (2) мой же guard ms > 1.0 (писался до патча, когда f16 был медленным) паникнул на настоящих 0.474 ms — «гейт, который падает на успехе», переписан на потолок TFLOP/s (60/25). COUNTED-warn в Candidate::fail (cubecl-runtime schedule.rs) теперь показывает ~20 skip’ов кандидатов на прогон (No tile size / TMA unavailable) — раньше всё это было немым.

2026-10-02 (unguard, дефект-инцидент): --guard + guard-image re-exec УДАЛЕНЫ (1949c39) — родитель при --detach выходил 0, оркестраторы читали краш как успех → 15 прогонов на одном GPU. Главная находка: NaN-файрвол ВСЕГДА был безусловен — флаг не доходил до TrainCfg, весь механизм жил в cli/train.rs (−109 строк), lib.rs не тронут (дифф не нужен). --guard теперь громко отказывает в clap. docs/reviews/unguard-2026-10-02.md.

2026-10-02 (checks-sh, финишировано, wt/checks-sh): агрегатор tools/checks.sh готов и запушен (f875564). Три находки: (1) oracle_gate.py собирал путь "vendor"/"burn-fused"/"crates" из ЧАСТЕЙ — grep по токену vendor/burn-fused (клейм C1 «→ 0») и PREFIXES в check_doc_refs его не видят; гейт лежал с переименования, после фикса 05c91e1 жив и красный по существу (3×R1: файлы burn-kda без строк ORACLE-TIERS.tsv — владельцам). (2) doc-refs сканирует tracked-файлы, а существование путей проверяет по ФС — любой untracked-каталог маскирует красный в зелёный (механизм дефекта a0a1dce). (3) doc-warnings (-D warnings cargo doc) компилирует ЗАМЫКАНИЕ зависимостей: 8 rustc-warnings в dormouse-train (optim.rs:63, lib.rs:1118-1328, offload.rs:171, jepa_targets.rs:144) краснят гейт на main; не чинил — владельцу крейта.

CI-final lane (2026-10-02, wt/ci-final)

Cargo.toml gotcha of the day: [package.metadata.cargo-machete] inserted mid-[dependencies] silently turns every following dep into inert metadata — the lock “consistently” drops them and cargo metadata --locked still passes; the crate just stops linking the dep. Metadata tables go AFTER the deps section. clippy -D warnings stops enumerating at the first failing crate (could not compile X then the run ends) — enumerate per-crate or fix-and-recurse; the 114-count shrank to ~46 on the rebased tree because landed lanes had quietly fixed their share. Parallel release test-binary links (lto=thin, units=1) kernel-OOM — -j 1 links them one at a time. machete/clippy/fmt of crates/ closed (f47419a, f315275, de222ea); fmt stays red on train/src/lib.rs (129 hunks, wt/graph holds it) + core/src/routing.rs (8) — closing command is one cargo fmt -p dormouse-core -p dormouse-data -p dormouse-train -p dormouse-cli when the graph lane lands, then drop the lint job’s continue-on-error.

2026-10-02 (ночная волна→утро): --quant fp16 — режим BATCH 8: при b8 −5% ms/step (441 vs 465, fwd 185→162), при b16 выигрыш инвертируется (bwd 504→534), b32 с aux не влезает вообще (OOM step 0, JEPA-учитель — второй форвард). Парное сравнение с 100k-бейзлайном (один сид, одно окно) на согласованных шагах: fp16 ≈ fp8 внутри шума ±0.1-0.2 — качество не просело. Граф v1 упёрся в стену, предсказанную его же §1: окно, исключающее out-of-place оптимизатор, НЕ ТРЕНИРУЕТ — 6 реплеев оставляют параметры bit-identical к capture-шагу (гейты 1/4, wt/graph-trainer не смержен, блокер в continuation-разделе дока). attnres: s1 6.191 был разбросом сида, не сигналом — fresh 3 сида дали range 0.262 (3.6× контроля 0.0730), mean 6.3300 → TIE → удалена; вся волна-3: все руки TIE, в сборку не вошла ни одна. Ночной прогон 44k шагов (b8+fp16) сам дошёл до финиша за 4.97ч, 0 NaN, BEST 5.908@36500.

2026-10-02 (kdaci): kda_oracle «красный на CI» был ложной посылкой — 3 FLA-теста RED ON PURPOSE (b485ad9), красные везде с байт-одинаковыми числами (ratio ровно 2.8284=K^0.5, формульная разница, не ULP); «зелёные локально» = цель никто не гонял (корневой workspace форк исключает). Фикс 23f4b5f: #[ignore = "<причина>"] — COUNTED-форма; фикс формул = A/B arm 5, владелец. rustc на этой коробке сломан для свежих сборок: система подняла LLVM до 23.1, дистрибутивный rustc 1.98.1 слинкован с libLLVM.so.22.1 (64-битной больше нет) — тёплый sccache маскирует, любой cache-miss умирает с exit 127.

2026-10-02 (wgpu): cubecl-wgpu 0.11.0-pre.4 работает — наш rmsnorm_kernel bit-correct на lavapipe (max rel err 0.0), гейт cargo test -p burn-rmsnorm --features wgpu (фича+wgpu-тест в wt/wgpu); CubeTensor в burn 0.22 стирает рантайм — девайс выбирает CUDA-vs-WGSL, тело ядра одно. llvm-libs откатил на 22.1.8 из кэша (иначе rustc умирает: soname 22.1); lavapipe (mesa 26.2.3) требует 23.1 — работает через LD_LIBRARY_PATH=/tmp/opencode/llvm231/usr/lib (распакованный 23.1.1, систему не трогает). 2026-10-02 (wgpu lane): a worktree recovered from a dead session carried a gate test that had NEVER compiled (3 type errors) while its report said PASS — the session’s results came from scratch probes, not the committed file; a recovered “PASS” without its own green run is a hypothesis. 2026-10-02 (wgpu lane): tools/lib_gate.sh masks a red first cell: [ "$rc" -eq 0 ] || rc=$rc2 overwrites the workspace cell’s exit code with the binary-tests cell’s — a disk-full compile failure printed as “PASS”. Needs rc=$(( rc || rc2 )) logic; reported, not fixed by the wgpu lane. 2026-10-02 (wgpu lane): a debug link of one burn-linked test binary eats 1-3 GB of /home transiently; 87 stale test exes were 17 GB in a 19 GB target dir. Guard disk before EVERY cargo call, not between script cells — mold “Disk full?” + bus error at 0 free kills the run mid-suite. 2026-10-02 (fidelity lane): аудит фидельности 4 tie-рук готов (wt/fidelity, 36365a5, пушнут origin/wt/fidelity). ГЛАВНОЕ: moe при top-1 + lb 0.0 имел РОУТЕР БЕЗ ГРАДИЕНТА ВООБЩЕ (ренормализованный гейт = ровно 1.0 у победителя ⇒ d/dlogits ≡ 0 аналитически; градиент роутеру даёт только LB-член, который выключен) — ренн = “замороженный случайный роутер”; k=2 возвращает градиент через ренормализованные веса. mhc: b_res=10I делает руку ReZero до первого сдвига офф-диагонали (~2.1e-4/ед.), alpha_res grad 7.3e-9 — считать ли tie честным тестом механизма, решать после телеметрии b_res. fb: бумага сама обещает n=8 на байтах (+67% MBPP @7B) и «до 30M неэмбеддинг помогает, выше 100M — нет»; у нас n=2 — промах мимо обоих режимов. attnres — самый чистый транскрипт; tie объясним бюджетом (0.262 разброс сидов vs 0.073 контрольного). 2026-10-02 (integration lane): wave merged to main — graphfix f2e9ab3 (keys gate keyed on consumption, +CPU/CUDA contract tests; --no-engram capture refusal fixed), fidelity-fix e790242 (mhc_streams 4 default, b_res off 10I, attnres gain), kdafix2 d65ed16 (Softplus FLA-form, read scale K^-0.5 in one place), byteflow2 (burn-byteflow crate, 14/14). Гейты на слитой вершине: core 89, train-lib 60, mhc 9, attnres 11, kda_oracle 9, fused_cuda 4 (CUDA), summit 1-step smoke green, doc-gate, preset_exec 11/11. Отчёт: docs/reviews/integration-2026-10-02.md. 2026-10-02 (integration): два красных PRE-EXISTING на main, оба проверены на базах и НЕ от волны: (1) graph_seam_cuda the_stale_pointer_trap_is_reproduced_without_the_pin —走廊 краш формы server.rs:144, который убил gbench2_graph в 18:48 (владелец graph-trainer); (2) gpu-gate.sh gated_delta_chunk_path_runs_at_the_production_shape — matmul [10,12,16,64]×[10,12,512,64] уже на базе f4f7a0b (владелец burn-gdn2). Компиляц-CUDA гейты ловят то, что CPU-гейты не могут: fused_cuda после мёржа не компилился (E0382) — чинить ГЕЙТ после мёржа обязательно, не только lib-тесты.

2026-10-02 (dispatch-guard, wt/dispatch-guard): тип трейнера лгал о стратегии — Backend = Autodiff<Cuda, BalancedCheckpointing> при девайсе Enabled(Disabled); type-erased ops не замечали, но каст try_into_primitive::<B> отказывал на КАЖДОМ тренировочном KDA-вызове → 412 fused форвардов/прогон ВЫБРАСЫВАЛОСЬ в ops-путь (fused kda=412/0). Фикс: тип = NoCheckpointing (train/src/lib.rs) → первые живые fused-бэкварды: fused kda=412/412 node_bwd=412. A/B b8: launches −48% (15644→8072), fwd −70%, bwd +33% (adjoint делает реальную работу, тензорный bwd — launch-bound), netto +2.6% = шум; rmsnorm-узел: 515/615, −360 launches/шаг, ms-нейтрален. Гейты: rmsnorm autodiff_node_cuda 3/3 + fused_kernel_gate 3/3 (пин перевёрнут), kda_param_grads_cuda 4/4 (cpu_rel=0). Урок фикстур: GradInBackward-градиент ПОТРЕБЛЯЕТСЯ своим шагом (grads.rs:103) — читать на листьях; per-element rel не имеет f32-оценки на малых элементах — бар scale-relative. Balanced как режим памяти = решение владельца (девайс+тип одновременно). 2026-10-02: patching research landed (wt/patching, 95ebf06, docs/reviews/patching-research-2026-10-02.md): brief’s BLT id was wrong — the paper is arXiv:2412.09871 (2412.09771 is an Ising physics paper). Verdict: P0 zero-code seq-len mould (512/128/85) prices the launch-bound box first; P1 = fixed-stride patch arm ~300-400 LOC with byte CE unchanged and patch_stride=1 default (no ckpt era break); SpaceByte Table 1 is the only small-scale equal-compute pro-patching evidence; a 50-100M entropy oracle is never justified at 9M params; batching-only patching rejected (dense stream, no padding). 2026-10-02 (dispatch-guard, закрытие): tools/lib_gate.sh:95 [ "$rc" -eq 0 ] || rc=$rc2 ПЕРЕЗАПИСЫВАЕТ красный ячейки 2 — зелёная ячейка 3 превращает 6 FAILED в «PASS»; локальный зелёный гейт был ложно-зелёным, фикс = удалить строку 95 (не правил — общий инструмент). fused-library CI красный на MAIN (3/3 прогонов): burn-kda designed-red ×3 (фикс #[ignore] в wt/kdaci 23f4b5f НЕ смержен) + burn-spectral known-red ×3; ветка dispguard2 не добавила ни одного нового красного, корневой ci зелёный. 2026-10-02 (graphfix, wt/graphfix a8ce80c+620f7c6+486e03c, pushed origin/wt/graphfix): ключ-окно граф-руки: сверка ПОДанным, не потреблённым — next_batch всегда считает FNV-ключи (ORDERS безусловно), при –no-engram пин не буферизует ключи, а feed отказывал каждый шаг. Фикс: keys_consumed фиксируется на arm-time (dorm_cfg.use_engram && host.is_none); потребляющее окно без ключей = громкий отказ, потреблённого нет (правильная программа без памяти) = drop; armed line печатает “key window FED|none” (COUNTED). Гейты: новый CUDA-контракт зелёный (capture 1 replay 2 refused 0), 3/4 старых зелёных, negative flake (cuEventCreate 700, известный, pre-recorded), optim.rs:643 красный на HEAD 2ccff38 (stash-проверено, follow-up). Перемер: control 485.8 ms/step (первый 469.0 — стоит); graph arm: capture ОТКАЗАНО на реальной форме — “2331 memory node(s) в окне записи” (§6.2 отвечает НЕТ — priming не покрыл; пул ×20 → ILLEGAL_ADDRESS storm, убит на ~10-м шаге). В1993 прод — НЕТ]; блокер = priming coverage / persistent serving (решение владельца); история в benches/history.tsv. 2026-10-02 (byteflow3 lane): the dynamic coding-rate patcher + the –byteflow arm landed on wt/byteflow3 (base byteflow2) — direct-logdet oracle green, 1-step CPU smoke through the real train_loop; the 200-step GPU A/B is QUEUED (card owned by graph-stage). LogDet path under autodiff is compile-verified only; L2 default is the streamed one. 2026-10-02 (graph-stage lane, wt/graphstage bbf439d, pushed origin/wt/graphstage): стадия под capture = EMA-учитель, не KDA-fwd основного цикла — replay не исполняет host-код, узлы autodiff на replay-шагах не перестраиваются, loss.backward() требует свежий граф → KDA-fwd в training = форма 8fa5d4c (замороженная рука); forward_latent учителя градиентно-свободен по построению (ema_update кончается .no_grad()) и БОЛЬШЕ (атлас ряд 4: 4401 запусков, KDA-копия 3099.4). Гейт (b) бит-точен (stage_capture_cuda.rs), A/B 500×2: 423.0 vs 453.1 ms/step (−30.1, бар 10), captured 1 / replayed 495 — ОДИН capture на жизнь прогона (графу нечего инвалидировать: пины-мастера + retained-срезы, PersistentPool::cleanup освобождает только free). 2026-10-02 (graph-stage lane): класс дефекта: cadence-предикат знал только один режим — ungraphed = !graph_on || … заставила stage-руму кормить 500 шагов и не захватить ни одного (captured 0, 459→1300ms у первого прогона из-за GPU-контеншена соседней дорожки, НЕ кода). Фикс: !(graph_on || stage_on). Бюджет отказов: MAX_REFUSALS 20→2 ПОДРЯД (успех сбрасывает), graph_prepare достижим только под capture_allowed() — пул ×20 → ILLEGAL_ADDRESS невозможен структурно. Урок сессии: git stash в ОБЩЕМ дереве при живых агентах = конфликт на memory.md (разрулен union-merge, stash@{0} оставлен как бэкап) — стэшить только в своём worktree. 2026-10-03 (bfab lane, fdcd030 pushed): byteflow WON the equal-byte smoke and now IS the schema default net — 200-step A/B, both arms stream the same 4096 B/step (equal steps = equal bytes), fixed 81920 B window: bf 4.488/4.539@200 (s1/s2) vs ctl 6.714/6.595@100 → ~2.15 BPB, ~30× ctl seed spread; params NOT matched (+73% bf) and 0.82 MB budget = smoke, 2k×3seed confirm owed. Dormouse presets carry use_byteflow=false explicitly; dormouse-loop fixtures pin it false. Path to 1M: the real blocker is byteflow_max_bytes/RoPE (net.rs:445), ~300-400 crate LOC for a recurrent local window; bf16/stress = trivial. Fleet fact: three silent card-contention kills today — ALWAYS re-pgrep right before launch and verify the log file exists 30s after (my control s2 died twice with 0 bytes while graph/maxopt probed). 2026-10-03 (maxopt lane, wt/maxopt ddc5187..f7d1743, pushed origin/wt/maxopt): (1) head-wise QK NS batched через [heads,dh,d] 3D: opt stage 3914→2257 launches/step (−42%), opt ms 62.2→37.7; per-slice ColRow ТЕНЗОРНЫЙ путь (norm_colrow_cuda walks last-2 dims, на батч-буфере молча рвёт layout — с now-loud refusal; эквивалентность = scale-relative ≤5e-6, побытова НЕ достижима на ndarray-матмуле (порядок редукции, 1.5e-6 измерено)). (2) каденс r-e 10: бпb — ties внутри спреда 8 прогонов (paired same-seed ±0.05-0.09), макс_орто не залился, ms-экстраполяция −16/шаг при N=10 против 4. (3) precompute-JEPA OOM на 3-й записи (cubecl server.rs:144, 12 582 912 B = ровно 1 латент-рекорд) — cleanup-фикс НЕ помог, воспроизводим 3/3; блокер cubecl-дорожки; а главное — сайдкар 12.6 МБ/шаг = 25 ГБ на 2k шагов/1.26 ПБ на 100k: весь offline-JEPA рычаг у потолка само́ архитектуры. Фичи-гейт: the_eval_counter тест — pre-existing red на cuda-feature (falsification: with lever stashed = same red). 2026-10-03 (b16fix lane, wt/b16fix 0841f31): night2b/c/d “step N: device error (loss is not a scalar)” = кубекл OOM (server.rs:144), проступавший через потерянное TensorReadError::Execution, host-side read ломается на первом log-шаге после смерти устройства; b8 (night2e) не OOM-и́т. Фикс: loss-read теперь печатает underlying error. Repro b16 s512 120 шагов и 200-шаговые гейты Fp16+Fp8 — ЖДУТ тихой карты (night2e до ~80000 шагов); cargo test -p dormouse-train –lib 64/64 green. 2026-10-07 (v22 cut lane, b218022..51fb234): самопись cuda-graph/пул/счётчик вырезана, патчи сняты — cut(graph) −3002 стр (graph.rs 985 + stage.rs 349 + inplace.rs 114 + 2 CUDA-гейта; окно шага снова последовательный код; снимок со старыми graph_capture/graph_stage ГРОМКО отказывает в RunCfg::from_snapshot); cut(memory): init_pools → cubecl.toml (size-match/async в корне, cubecl_toml_or_loud() ГРОМКО при отсутствии — дефолты cubecl Enabled/Sync ≠ наша разметка), pool_stats = memory_report(Device).usage(), cleanup = .expect; cut(instrument): cubecl_launches + ATLAS launch-дельты (на стоке нет хука, ms-only); cut(vendor): все 5 патчей — включая topk-reduce (ADR-0015 нужен только для МАСКИРОВАННОГО top-k; единственный потребитель = плотный moe-роутер), vendor/cubecl-fix и cubek-fix удалены, зависимостям — стоки 0.22.0/0.11.0 (один cubecl в графе). Верификация: cargo check ×4 crate cuda zero-error, train –lib 56/56, core –lib 93/93, doc-refs green, cpu-check green; GPU-гейты (f16_gemm_perf, topk_gather_parity) не прогонялись — карта занята llama-server. Косметика: случайный глиф в теле ae80b53; комментарии кода с именами удалённых армов — отдельный docs-заход.

2026-10-06 (v22-port): burn 0.22.0 + cubecl 0.11.0 stock; −79 237 строк — graph.rs(985)/stage.rs(349)/inplace.rs/graph_seam_cuda(972)/stage_capture(150) удалены, init_pools+launch counter+atlas deltas вырезаны, патч-таблица пуста, vendor/cubecl-fix+vendor/cubek-fix удалены (52k). Оптимизм: (1) f16 SizedType апстрим-импл (float_type! macro); (2) cleanup-renumber hazard #1401 у апстрима ТЕПЕРЬ своё (held_binding_survives_explicit_cleanup_renumber в их же тестах); (3) topk OOB (ADR-0015) недостижим нашим плотным роутером без масок. Smoke CUDA: warm step 532-655ms при b8 s512 (против 441ms pre.4 fp16 при b8 — на 20-40% медленнее, но 200 шагов 0 NaN, ce 5.573, clean). Ложный тревога дня: release-билд БЕЗ --features dormouse-cli/cuda дал CPU-тренировку 26s/step (qr_householder в DormouseModel::new на flex-CPU стеке — gdb показал) — CUDA-фича у cli default = “cpu”, билдить всегда с фичей.

2026-10-07 (bisect022 open): fp32 b8 НЕ детерминировано взрывается на 0.22 (3/4 прогонов к шагу 25-100: 1e10→NaN; один до 150 чист; пул disabled и fused-off не спасают). Двойная улика «руки отвалились»: bwd 14-21ms и retr 5ms на 0.22 (pre.4: 205/52-61) — бэквард/ретракция в 10× быстрее = почти пустые. KDA param-grads на 0.22: q/k/v/b_alpha autodiff vs центральная разница ОДНОГО форварда rel 4e-3..9.6e-1 с расходящимся fd(h) vs fd(h/10) — несглаженность; pre.4 тот же тест 11/11. Лейн wt/bisect022 (ses_eebb3570effekqclkCpG1UQntt) бисектит: CPU-flex 2-layer первым — если врёт CPU-0.22-автодифф, это апстрим-дефект.

2026-10-09 (0.22 bisect, ЗАКРЫТ с доказательством): корень порчи НЕ в весах и НЕ в kernels’ math — в ВЫБОРЕ КАНДИДАТА АВТОТЮНОМ. При --lr 0 (no-op апдейт) ВСЕ параметры бит-идентичны шаг0→шаг1, а форвард шага 1 читает ce=1.76e9, и eval на тех же весах читает NaN (“held-out eval is NaN … the model or the allocator is broken”). Ретракция, запись оптимизатора, гонки (racecheck 0), OOB (memcheck 0) и внутрипроцессная недетерминированность (два форварда бит-равны) — исключены каждым своим замером. Математика KDA ops-пути ЗДОРОВА (гейт продакшн-формы зелёный: batched vs loop 3.3e-4, градиенты ≤3.3e-4). Что осталось per-process: 50 из 125 ключей тюнинга получают РАЗНОГО победителя между двумя прогонами ОДНОЙ программы; два ключа (m=512 n=1024 k=128 и m=64 n=2048 k=64-transposed) расходятся 4-взрыв/2-чисто по выбранному кандидату (matmul_simple_cyclic_mma_multi_rows против matmul_ordered_double_mma_..._row_count8, медианы различаются на 1.6%). Всё, что «чинит» один прогон (–opt adamw, –no-kda, –no-engram, n_experts=1, конфиг пула), просто двигает монету: size-match 10/10 взрывов, enabled 1/1, disabled 1/3…3/3, enforced 0/1 — и все варианты стоят ОДНО И ТО ЖЕ по ms/step (198-207). Поэтому конфиг НЕ меняется: band-aid без причины = ADR-0011. ИТОГ: 0.22.0 пока не тренируем для A/B, pre.4 остаётся стеком с доверенными числами; доказательная записка docs/reviews/2026-10-09-022-autotune-corruption.md, лестница пробников vendor/dormouse-fused/burn-fused/tests/matmul_uninit_probe.rs (9 уровней, включая ОПРОВЕРГНУТУЮ гипотезу: uninit-read в узком матмуле реален, но значение маскируется — 0.000e0 против материализованного rhs). Побочно, тоже реально: постоянный кэш автотюна (target/environment) не создаётся ВООБЩЕ (3 прогона из одного cwd = 125 свежих решений каждый, 0 файлов) — при том что в бинарнике 2692 символа persistence. Это в тот же issue апстриму.

2026-10-09 (продолжение, отпечаток назван): порча локализована в ТАБЛИЦЕ ENGRAM. Два одинаковых процесса (один чистый ce=5.911, другой испорченный ce=7319) расходятся в 4 из 54 параметров, и самый большой — loop_block.engram.memory. embedding.weight: 10063 из 32768 строк, худшая на 4.2e18 АБСОЛЮТНО; все KDA-параметры бит-в-бит одинаковы. Три гипотезы опровергнуты тестами (gather backward честно обнуляет нетронутые строки; seeded RNG здоров на голом и автодифф-девайсах, max 5.34; --engram-ram тоже взрывается 3/3 — значит дело НЕ в хранилище таблицы). bf16×bf16 матмул на 0.22 БОЛЬШЕ НЕ ОТКАЗЫВАЕТ: считает и возвращает BF16 (rel 3.09e-3 к fp32 = точность bf16) — наш трипвер красный, апстриму вопрос «путь или тихий каст». Сводный список багов с уровнями доказанности, костылями и приоритетом для burn: docs/reviews/2026-10-09-bug-list-022.md. Issue апстриму написан verbatim, но токен GitHub тут read-only.

2026-10-10 (проверка полноты + инверсия точностей): вопрос «эточно все баги?» — нет. Сплошной свип всех целей обоих клеток корня нашёл ЕЩЁ ПЯТЬ наших мёртвых гейтов: (1) корневые тесты не компилировались (.bytes → .bytes(), model_seam, msa_gate1_flex — тот же класс, что и 53 файла vendor); (2) gr_seam 3/3 красный: фикстура наследовала DormouseConfig::default(), а дефолт — это СЕТ-ПОБЕДИТЕЛЬ byteflow-A/B (use_byteflow=true) при mor_bce_weight=0.05 → validate отказал; (3) bf16_compute_on_cpu красный под –features cuda: стороже был #[cfg(feature)] сборки, а не девайса → на Flex арм bf16 срабатывал и уводил на 1.898 (сырая bf16-опера при этом честная и на голом, и на автодифф-Flex — пробник в param.rs); (4) preset_exec 2 теста: plain9m приехал без COVERED/стоимости, override глубины 2 не учитывает depth-1 контроли, формула Muon+ 4*n_experts+3 предполагала TSCT. Все исправлены, все клетки зелёные (core lib 94/94 CPU и cuda, train 56+все интеграции, data, backend-parity 8/8 + 2 bf16 которые теперь ПРОХОДЯТ, preset_exec 19/19).

ИНВЕРСИЯ ТОЧНОСТЕЙ на 0.22 (2026-10-10, один dtype на процесс, release): fp32 17.19/20.03 TFLOP/s, f16 7.83/8.53 (в 4.7 раза МЕДЛЕННЕЕ pre.4-шных 39.75 и в 2.4x медленнее СВОЕГО fp32 — путь нетензорный, стабильный, НЕ монетка автотюна), bf16 36.84/44.06 — потолок cuBLAS, в 5.2x быстрее fp32. Причина регрессии f16 — НАШ ae80b53: порт срезал все [patch.crates-io] «потому что stock 0.11 закрывает f16 sizing» — замер это опровергает; эксперимент — вернуть патч cubecl-ir. ADR-0016 bug 2 («bf16 не работает, все bf16 медленнее fp32») на 0.22 МЁРТВ: оба bf16-теста паритета проходят. Всё в docs/reviews/2026-10-09-bug-list-022.md (раздел Update 2026-10-10) и AGENTS §2.1 (таблица).

2026-10-11 (ночь, AWAY): (1) КОРЕНЬ ПОРЧИ НАЙДЕН — это ЧТЕНИЕ памяти, которую никто не писал, а не выбор кандидата автотюна. Два процесса при –lr 0 (обновления нет) расходятся в loop_block.engram.memory.embedding.weight (5767 строк, худшая 2.144e14); ОБА файла чекпоинтов содержат мусорные строки (3308 и 2802 при |v|>100, до 2.3e38) и они ПОЧТИ НЕ ПЕРЕСЕКАЮТСЯ (193 общих) — подпись чтения, не записи; сдвиги строк ±1/±2 не дают совпадений (21-22 из 200000 против 160818 при 0). Пулся решает, ЧТО лежит в переработанной странице: size-match+async = 9/9 порч на шаге 1, disabled+sync = 0/3 (один умер на шаге 2) — это и есть костыль БЕЗ правок чужого кода. Мой же провал: 6 чистых прогонов с bench{adaptive=false,max_samples=200} при повторе дали 6/6 мусор — совпадение, не фикс, записано. (2) ПАТЧ ВЕРНУЛ f16: ae80b53 врал про «stock 0.11 закрывает f16 sizing» — кандидат паникует “Expected type builtin.fp16 to implement dyn SizedType” и автотюн падает на медленный путь (8.53 TFLOP/s). Вернул vendor/cubecl-ir с патчом FP16Type → f16 8.53 → 44.04 TFLOP/s (5.2x, потолок cuBLAS), fp32/bf16 не сдвинулись. Единственная [patch.crates-io]. (3) АРXIV-НАХОДКА (iso-depth-2604.21106, уже в docs/papers): φ=0.46 — одна рекурренция стоит 0.46 уникального параметра; обрезанный бэкпроп роняет φ до 0.38 (а лосс всё равно падает!), гиперконнекции поднимают до 0.65. Вывод: глубинные армы A/B (depth 2 vs 4) надо судить по φ + BPB, а не по BPB одному — протокол исправлен.

2026-10-11 (ночь, продолжение): ПОРЧА ПЕРЕСТАЛА ВОСПРОИЗВОДИТЬСЯ и это записано как НЕОБЪЯСНЁННЫЙ ФАКТ, не как победа: 12/12 порчи на шаге 1 (три партии, старый бинарник) → 0/16 чистых (три партии, patched и unpatched бинарники, оба конфига пула, 12 и 40 шагов). Патч cubecl-ir ЭТО НЕ ОБЪЯСНЯЕТ: контрольная сборка БЕЗ патча тоже 4/4 чистая. Добавлен гейт CE_CEILING=100 (конечный мусор — не класс NaN-файрвола; uniform=ln(256)=5.545, минимум наблюдённой порчи 206; тест tests/sanity_ceiling.rs). НОВАЯ НАХОДКА того же класса: гейты headwise-Muon в dormouse-train (headwise_batched_ns_matches_per_head, the_eval_counter_covers_both_muon_implementations, headwise_muon_matches_per_slice_muon) падают 2.27e-3 ТОЛЬКО в полном прогоне и проходят в одиночку — порядковая зависимость, подпись чтения неинициализированной памяти. Не исправлено, требует разбора padded-пути headwise Muon в burn-muon-plus. Также: ретракция TSCT измерена (scalar 75.65 мс, batched 19.69 мс = 3.8x; цена ФИКСИРОВАННАЯ, не на итерацию NS); POWER_ITERS 5→2 даёт 6.31e-5 против 6.46e-5 ортогональности — неразличимо в шуме инициализации, НЕ менял.

2026-10-11 (сс奴лка от владельца): ALoDLM (Amazon, arXiv:2610.04198, 8 окт 2026, веса amazon/ALoDLM-8B, код amazon-science/ALoDLM). Qwen3-бэкбоунь разбит на прелюдию/общее рекуррентное ядро/коду; у 8B ядро = средние 16 слоёв, до 4 проходов; токены коммитятся по энтропии, цикл останавливается learned-гейтом (порог q), обучение — conditional NELBO с outcome credit + depth prior + промежуточный супервижн. Цифры (их): 11-бенчмарк среднее — 1.7B 65.5 против AR 63.8, 8B 80.3 против AR 78.5; ~2.7x throughput vLLM-Qwen3-8B на GSM8K; 133.5 против 154.6 GFLOPs/token у WeDLM; числовые токены учатся с меньшей вероятностью останова на первом проходе. Синтез с вчерашним φ=0.46: рекурсия по качеству ДОРОГАЯ (0.46), но выигрывает когда РАСПИСАНИЕ выучено — глубинные армы судить по φ, а алодаптив — теперь есть рабочий референс. Не отменяет нашего ADR-0013 (тот измерен на нашем стеке): дорожка оценена в docs/research/2026-10-11-alodlm-fang-et-al.md.

2026-10-11 (две ссылки от владельца): (1) ALoDLM amazon arXiv:2610.04198 — replication shared loop с learned halting (порог q) + conditional NELBO, бьёт СВОЙ AR-бэкбоун (8B: 80.3 vs 78.5); synthesis с φ=0.46: рекурсия дорогая по качеству, но выигрывает когда РАСПИСАНИЕ выучено. (2) DeepSeek-V4.1-Flash arXiv:2609.19969 — KV-сжатие: 890 B/токен в HBM (cross-layer reuse + FP4 KV), persistent на SSD/host = 1/8 предыдущей модели через SWA Bounded Replay; CED активирует 8B на prefill и 16B на decode. Для нас: подтверждение RAM-offload playbook (§3.5 item 1) на фронтире; dormouse вообще не несёт per-token KV (состояние KDA фиксировано), так что переносится только направление + идея bounded-resident окна для host-таблиц Engram. Оба разбора: docs/research/2026-10-11-alodlm-fang-et-al.md и docs/research/2026-10-11-deepseek-v41-flash-kv-compression.md; слежки в arxiv MCP стоят (5 топиков).

2026-10-11 (РЕТРАКЦИЯ + исправление): моё «порча перестала воспроизводиться (0/16)» было артефактом — cargo build --release -p dormouse-cli без --features cuda даёт CPU-бинарь (default = [“cpu”] у CLI!), а 16 «чистых» прогонов шли на Flex-CPU, где нет ни автотюна, ни пула, ни чтения неинициализации. Пересобрал с –features cuda и перемерил: size-match 3/3 остановлены гейтом CE_CEILING на шаге 1; disabled 2/3 чисто (1 умер на шаге 2). То есть прежняя таблица 9/9 vs 1/3 в силе, pool-корреляция в силе, ПАТЧ cubecl-ir порчу НЕ вылечил («контроль» был тоже на CPU), и гейт CE_CEILING впервые проверен end-to-end — поймал 3 из 3. Замер стоимости пула (sizematch vs disabled) тоже был на CPU и недействителен — перемерить на CUDA. Урок на будущее: проверять строку backend=Device<Cube(Cuda)> в логе прежде чемtrustить any 0.22 measurement.

• 2026-10-13 disk cleanup: freed 182G (targets in ~95 worktrees incl. vendor/*/target at depth 4, main+pre4 target/debug, vendor fused target, burn-fused target). Kept: target/release (main+pre4 binaries), sccache 21G. Worktree vendor targets live at depth 4 — find -maxdepth 4, not 3.
• 2026-10-15 (владелец, по плану docs/decisions/2026-10-15-1b-readiness-plan.md): цель — модель ~1B total (MoE), 9.2M = тест; лестница 9M→100M→1B одобрена. Субстрат: решать по «меньше кода, легче мейнтейнить, память», потом скорость; torch-спайк (b1-форма) одобрен, дефолт пока он идёт — burn. «1B total» читаю как ≈0.92B на карте (host-Engram — опциональное расширение, не цель). Upstream issue (A1-A3) пока НЕ подавать (драфт живёт в docs/reviews/upstream-issue-autotune-candidate-coin-flip.md). LittleBit (arXiv:2506.13771) — сейчас параллельно, вход через TSCT2-лестницу с kill-switch.
• 2026-10-15 (принцип владельца): лучшие существующие кернелы > свои. На torch-пути кастомными остаются только 3 вещи, которых нет в экосистеме (TSCT STE-квант экспертов, Engram host-таблицы, ByteFlow-патчер); на burn-пути весь hand-rolled слой остаётся нашим. Это меняет учёт долгов: phase-2 спайк обязан дать таблицу «заменилось экосистемой vs осталось кастомным» по LOC, а не только tok/s.
• 2026-10-15 (порт, исправление GPU-фазы поверх fd64cb9): быстрый MoE = cap-padded bmm (moe_padded_bmm: gather → одна [E,cap,·] банк-пачка из трёх bmm → weighted scatter); torch._grouped_mm ИЗМЕРЕН 2× медленнее на E=1024/b1 (44.2 против 21.4 ms fwd, ~19 µs НА ГРУППУ flat) и УДАЛЁН целиком (_grouped_dispatch/_grouped_reason/_stacked + 16-байтовое ABI-условие), naive остаётся CPU-путём и COUNTED-фоллбэком. Порт свой b1-профиль (свои тензоры, банки стекаются per-forward): padded 50.6 ms / 6.05 GiB против naive 571 ms / 3.28 GiB fwd-only при E=1024 d=2048 r=64 f=5461 cap=64, 16384 строк bf16 = 11.3×; parity padded-vs-naive fp32 1.8e-6 rel (16-битный ABI не нужен — ошибка порядка bf16 7.5e-3 на этом шейпе, на E=4 гейт даёт 0.0). Плюс симметрия SDPA-арма KDA: фоллбэк теперь L2-нормирует q/k так же, как in-kernel.
• Port: LFB load-free balancing wired (2408.15664) as a routing bias buffer; MoE fast path = cap-padded bmm (spike said _grouped_mm 2x slower, deleted); b1 measured 1,066,354,113; small 9,476,993 (+3.0% structural, documented).
• 2026-10-15 (порт, ByteFlow): port/src/dormouse/model/byteflow.py — пять стадий burn-byteflow (net/chunk/stream) + интеграция. Стойка владельца: burn = источник формул, НЕ спека интеграции, поэтому дизайн наш, и он записан в docstring модуля (Option A/B/C): use_byteflow + хоть одна петлевая рука = КАНАЛ (front stage → НАШ loop по K латентам → back stage, счётчик bf_channel); use_byteflow без рук = автономная сеть (bf_net), петля вообще не строится. ModelConfig.byteflow_* = ByteFlowConfig::default() дословно (net.rs:290-310); burn’s schema.rs вместо этого шипит уменьшенный byteflow_9m — это его пресетное решение, не дефолт крейта. Отказы: bf16 (у сети нет bf16-пути), use_engram (у памяти нет байтовой позиции на патч-пути), K≤T, max_seq_len≤byteflow_max_bytes, делимость ширин на головы.
• 2026-10-15 (порт, ByteFlow голдены): tests/test_byteflow_parity.py — три оракульных набора из vendor/dormouse-fused/crates/burn-byteflow/tests/ (field 2e-7 abs, rate 2e-7 rel, patcher 1e-9 rel f64-LU-vs-Cholesky) + фикстуры, скопированные байт-в-байт. Сравнение L2 стриминговых гейнов с batch — АБСОЛЮТНОЕ (1e-3): batch-L2 = f32 cumsum через раздутый burst’ом сумму (~1e-4 абсолютного шума), относительная 2.2e-6..3.2e-4 — это мера f32, не дефект.
• 2026-10-15 (порт, ByteFlow GPU-смоук): scripts/smoke_byteflow.py, small + byteflow-оверрайды (d=256, k=128, d_local 96, d_global 256), 10 шагов b4 s512: loss 5.782→5.545, eval bpb 8.111→7.941, 145.8 ms/step warm (308.5 на окне 1), 14 048 tok/s, peak 0.62 GiB, bf_channel=10/10, kda=fla,n=40. Это гейт ПРОВОДКИ, не качества.
• 2026-10-15 (порт, super-kernel шаг 3/3, ОДНО ядро): port/src/dormouse/model/moe_kernels.py — unpadded Triton grouped GEMM для dual-latent GLU (fwd: одна программа на (эксперт, ragged row-block) по offs [E+1], silu(g)*u в регистрах между GEMM’ами, fused-вариант 4.76 ms против split head+@v 6.24 на b1 — мерил оба, шипнул fused; bwd: те же ядра на adjoint-GEMM’ах, три-GEMM паттерн, свой autograd.Function). Гейты b1 (E=1024 d2048 r64 f5461 cap64, 16384 строк bf16): parity vs padded arm fp32 7.7e-8 (tiny), bf16 0.0 tiny / 2.19e-3 b1; градиенты fp32 2.1e-7, bf16 9.8e-3 (2e-2 гейт: две разные bf16-цепочки округления, не два реализации — fp32-число это доказывает); fwd 37.6 против padded 40.6 ms, fwd+bwd 97.8 против 94.5, peak fwd 8.31 против 8.58 GiB (≤ padded). Интеграция: ModelConfig.moe_kernel = padded|triton|naive (неизвестное имя — LOUD), experts._dispatch кидает moe_triton_gemm либо moe_triton_fallback + причину; дефолт остаётся padded (kill-switch для A/B).
• 2026-10-15 (порт, шаг 3/3, ГЛАВНЫЙ вывод): на b1 эксперт-пасс БОЛЬШЕ НЕ GEMM-bound — bmm-цепочка padded’а это 6.7 ms из ~40 (gate 1.4 + up 1.4 + h@v 3.9), остальное общий chrome обеих рук: _banks() ~15 ms host + ~4 ms .to()-копий (1.79 GB на вызов; кэш по _version её не убирает — bf16-конверсия платится каждый forward), fp32 вес-множитель 6.7 ms, scatter 5.5 ms. Поэтому 25-35 ms из research’а недостижимы этим ядром: их надо брать в op-1 (кэшировать банки сразу в bf16) и op-2 (fused permute/scatter), а не в op-3.
• 2026-10-16 (порт, serve): port/src/dormouse/serve.py + port/tests/test_serve.py (88a3bbd) — OpenAI-совместимый сервер, stdlib-only (ThreadingHTTPServer), генерация = ВЫЗОВ model/decode.py (decode_bytes), не копия: stream=true это тот же вызов на растущем контексте под ОДНИМ seeded-генератором, поэтому SSE-текст и один длинный вызов дают идентичную последовательность (тест это утверждает). Загрузка — тоже вызовы CLI (cli._snapshot_run + cli._device), лоад один раз на старте, снапшот чекпоинта авторитет. Деградации LOUD/COUNTED: malformed JSON / неизвестный model id / неизвестная роль / неизвестный путь → JSON-ошибка 400/404, max_tokens выше --max-tokens-cap (дефолт 512) режется с max_tokens_clamped=N в строке serve.
• 2026-10-16 (порт, serve, гоча): позиционный <preset> НЕ источник, а проверка ТОЛЬКО model-половины против снапшота (diff_keys фильтруется по model.): полный diff отказывает ЛЮБОМУ чекпоинту на диске, потому что train всегда шёл с --set (out_dir/data/batch — не progress-ключи). Ещё: load_run(preset) без оверрайдов падает на seq_len=512 > max_seq_len, если у пресета маленький max_seq_len — это и есть правильный лоуд (пресет обязан резолвиться сам). Инструменты: pkill/SIGTERM по процессу с stdout в файл теряет буферизованные строки serve-лога (не дефект счётчика, счётчик тестом проверен).
• 2026-10-16 (порт, турнир активаций, первый вердикт): silu (контроль) 3.0583/3.0568/3.0602, среднее 3.0584 spread 0.0034; situ (K3 Eq.12) 3.0582/3.0472/3.0549, среднее 3.0534 spread 0.0110; memglu 3/3 FAIL — NaN на первых шагах (d/dt[t·sqrt(1−t²)]→∞ при t=tanh(g)→±1, в bf16 tanh доходит ровно до 1.0 → сингулярный градиент; формула численно хрупка в нашей bf16-дороге — честный FAIL, не баг проводки). Situ: выигрыш 0.0050 средних БОЛЬШЕ контроля-spread (0.0034), но МЕНЬШЕ своего (0.0110) — статус ‘tentative, нужен повтор большим числом сидов’, плюс bounded-аргумент для low-precision (независим от BPB).
• 2026-10-16 (порт, потеря при переносе — найдена по вопросу владельца): burn-era модель БЫЛА BitNet-ной — TSCT-факторы в forward шли через ste_ternary_annealed (тернарный STE, b1.58 RoundClip, soft→hard анниляция, “converges better than hard STE from step one (measured)” — их же комментарий), активации — act_quant (8/4/fp4); крейт burn-bitnet: weight_quant_ternary (2402.17764 Eq.1), 2bit, ternary_nm (Sparse-BitNet 2603.05168), act 8bit, bitnet_v2, S3T. В torch-порт весь квантовый слой НЕ перенесён (был заглушён storage-rungs) — это дыра переноса, не ‘новая территория’. Chinyaem: ternary.py (тернарный STE+анниляция+S3T+8bit act), далее интеграция в tsct/experts через alpha-расписание, затем турнир bf16 vs ternary vs mxfp на 9.2M.
• 2026-10-16 (порт, Gram-NS вердикт): eb7e0eb — gram-newton-schulz (2608.11612 §4, референс Dao-AILab v0.1.6, рекурсия в optim.py _gram_via_ns) реализован и эквивалентен (fp64 4.3e-14, fp32 ≤1.8e-6 на b1-формах, 29 тестов, классик пиннут byte-identical). НО на GPU грам 1.2-1.4× МЕДЛЕННЕЕ классика (1.37-1.50 vs 1.09-1.15 мс): NS-шаг host-dispatch-bound (CPU-очередь ≈ wall, GPU-резидент ≈ 0), грам отдаёт больше вызовов — а платим за вызовы. CPU-путь — 1.6-2.2× быстрее. Default остаётся classic; ns_kind="gram" — арм. Вывод для скорости: оптимизатор лечить числом вызовов (CUDA-graph capture шага по K3-плейбуку или compile NS), не арифметикой.
• 2026-10-16 (владелец, фокус-спринт): “всё на паузу — срочно максимально сжатая модель + сверх-TSCT”. Пауза на RL/данные/compile-эксперименты; все ресурсы на квант-трек: тернарные веса b1.58 (+анниляция/S3T), LittleBit-факторы для TSCT (дизайн-док littlebit-design-2026-10-15.md, гейты G-A..G-D), BitNet v2 Hadamard-ротация, a4.8 активации (int4/fp4 + attention-8bit), MXFP4/MXFP8 железный формат, packed-хранение. Цель — b1 в минимальной битности с турниром на 9.2M перед b1.
• 2026-10-16 (порт, factor_qat интеграция, c899351): сверх-TSCT-путь готов — factor_qat: none|ternary|binary + factor_qat_alpha (0..1 анниляция), ОДИН tsct.factor_qat_project через который ходят оба потребителя (TSCTLinear._factors и DualLatentGLU.forward) и SparseMoE._banks (fp32-стек → квант per-expert α dim=(1,2) → .to(dt); грид ±mean(|W|), ε только в знаменателе — как в ternary.ternarize, паритет banked-vs-standalone приколот тестом). 10 gold-тестов (grid, lerp-анниляция точная, STE-градиенты до мастеров, LOUD-отказы), вся сюита 313 passed. GPU-смоук ternary 60 шагов: loss 3.56→2.79, eval bpb 4.02→3.94, 0 NaN, kda=fla/engram живые.
• 2026-10-16 (порт, турнир сжатия, запущен): bf16 vs ternary vs binary × 3 сида × 2k шагов (ab_qat.py, ~40 мин). Вердикт по правилу контрольного spread; при провале ternary — LittleBit row/col scales как реабилитация (дизайн-док готов).
• 2026-10-16 (порт, a4.8 активации, b085afc): model/act_quant.py — порт crates/dormouse-core/src/act_quant.rs. Формула: s = block_max / max_value(fmt) (fp4→6.0, int8→127, int4→7 — НЕ 1, это и есть баг «3-уровневого fp4» из докстринга burn), per-token (group=0) или per-group-of-group по последней оси, e2m1 с ничьими в ЧЁТНЫЙ код (лестница burn), STE x + (q−x).detach(). Грид не переобъявлен — импортируется tsct._NVFP4_MAGNITUDES. LOUD: неизвестный формат, group<0 / не делит последнюю ось, не-finite, не-float. attn_format: fp4/int4/int8 → int8 (правило a4.8, безусловное). Интеграция зеркалит factor_qat: TSCTLinear.forward (+ флаг attn_path, который make_projection прокидывает — в графе порта ни один вызов его пока не включает: q/k/v/g KDA — плотные nn.Linear, а единственный TSCT в loopblock (out_proj) стоит ПОСЛЕ attention+FFN), DualLatentGLU.forward и банк/dense-banked bmm в SparseMoE (там модуль не вызывается — без правки арм был бы молча инертен), счётчик act_quant_arms. Роутер и внутренности KDA — вне объёма. Конфиг: заглушка _unsupported → реальные act_quant (none|int8|int4|fp4) + act_group с LOUD-валидацией (неизвестное имя, отрицательный, не делитель d_model, инертный при none). Гейты: 25 gold-тестов (все 8 уровней e2m1 достижимы, максимум блока ложится на 6.0 — анти-3-уровневый тест; таблица ничьих; аналитические границы: int8 max 1.60e-2 против 1.61e-2, int4 2.92e-1 против 2.93e-1; group == ручной per-block референс; grad STE = 1; идемпотентность; bushed==module паритет; LOUD-отказы; форвард модели двигается и конечен). Сюита 340 passed, ruff чист. CPU-CLI смоук 3 шага act_quant=int4 act_group=32: loss 6.0166→5.9579, act_quant_arms=256, 0 NaN. GPU-смоук ПРОПУЩЕН: карта занята турниром другой полосы (pid 346043, 1904 MiB). НЕ покрыто: (1) attn_path=True не имеет живого вызова — правило a4.8 держат только attn_format + юнит-тест; (2) нет внешнего эталона ошибок int4/int8 (в отличие от e2m1_oracle.rs), границы — аналитические + наши измерения 2026-10-16 (fp32, seed 0); (3) int8+group=0 — тот же объект, что ternary.activation_quant_8bit, но две реализации: расхождение 2.38e-7 abs (2 ULP, порядок двух округлений) приколоно тестом.
• 2026-10-16 (порт, квант-лестница = одна матрица переключателей, d6bf795): модули mxfp/hadamard/ternary были, форвардов не было — теперь 4 рага на двух швах. factor_qat=mxfp4 (mxfp.fake_quant_mx, MX e2m1 + e8m0) и factor_qat=ternary_s3t (ternary.stochastic_ternary) под ТОЙ ЖЕ анниляцией, что ternary/binary; act_quant=mxfp8 и act_quant=v2_int4|v2_int8 (hadamard.v2_quantize) на активационном шве. НОВОЕ ПРАВИЛО ОДНО НА ОБА MX-ПОТРЕБИТЕЛЯ: последняя ось zero-pad’ится ПО СТРОКЕ до кратной 32, квантуется паддированный вид, слайсится назад — это точно, потому что ноль не поднимает amax блока и остаток STE срезается после (сырые fake_quant_mxfp4/8 по-прежнему LOUD на неполном блоке). Именно поэтому пери-строчный пад делает [E,d,r] банк бит-в-бит равным E отдельным [d,r] срезам — и при выровненном r=64, и при паддированном r=8 (тесты), поэтому dim для mxfp4 ИГНОРИРУЕТСЯ как доказанно ненужный. v2-int’ы наоборот: не-2^k последняя ось — LOUD, НЕ пад (пад FWHT меняет базис ротации, а не только распределение шкалы), и d_model=768=3·2^8 не 2^k → конфиг отказывает small с v2_int4/v2_int8 на загрузке (escape: 2^k ширина; тестовый tiny =64 работает). S3T: генератор — модульный, сидируется новым factor_qat_seed через tsct.set_factor_qat_seed из DormouseModel.__init__; ЧЕСТНО ЗАПИСАНО в докстринге И печатается в лог на старте train: проектор без step-индекса, поток продвигается по вызовам → воспроизводимо внутри запуска, но РЕЗЮМ НЕ продолжает поток (ADR-0021 не выполним на этом шве без step-аргумента). Банк vs standalone у S3T совпадают по ШКАЛЕ (α_e), не по маске — один [E,·,·] draw против по-факторных, это единственное расхождение в проекторе и оно приколочено тестом. Тесты: +23 (11/12), сюита 363 passed, ruff чист; GPU-смоук (карта была свободна) 30 шагов b8s512: ternary_s3t+mxfp8 loss 5.5270→4.9789, 0 NaN, act_quant_arms=81920, moe_dense_banked, kda=fla, 140 ms/step; mxfp4 5.2510→3.9495, 0 NaN, 173 ms/step (по одному прогону, не A/B). НЕ покрыто: v2-раги не запускались ни разу ни на GPU, ни на CPU-модели small (только tiny + юнит) — на 768 они отказывают по дизайну; attn_path=True по-прежнему без живого вызова (правило a4.8 от v2 держит только юнит-тест attn_format).
• 2026-10-16 (порт, ВЕРДИКТ турнира сжатия, 3 сида × 2k, b8 s512, окно 81 920 B): tnone (control) 3.0523/3.0517/3.0579 mean 3.0540 spread 0.0062; tternary hard 3.1249/3.0955/3.0906 mean 3.1036 (+0.0497, spread 0.0343); tbinary hard 3.1420/3.1345/3.1476 mean 3.1413 (+0.0873); tanneal (ternary + ramp alpha 0→1 за 1000 шагов, 4f79027) 3.0937/3.0960/3.0911 mean 3.0936 (+0.0396, spread 0.0049). ВЕРДИКТ: квант-форвард факторов ПРОИГРЫВАЕТ bf16 на 9.2M и с анниляцией (+0.040 BPB = 6.4× контроля-spread; анниляция вернула лишь 0.010 из 0.050 — burn-замер “annealed лучше hard” подтвердился как НАПРАВЛЕНИЕ, но не спас). Причина честная: 9.2M не имеет избыточности платить 2-бита на факторы. РЕШЕНИЕ: training-квант весов ЗАКРЫТ на этом масштабе (арм оставлен в коде флагом для больших масштабов, где штраф кванта традиционно падает); storage-рунги (fp8/nvfp4/ternary чекпоинты) НЕ затронуты — это отдельный механизм без изменения форварда. act_quant турнир НЕ гоняем (спекулятивно: на тренировке фейковый квант активаций не экономит ни память, ни время — только QAT-готовность; отложено до инференса). Расширения квант-трека остановлены (принцип владельца “не плодить”).
• 2026-10-16 (порт, TF32-чек 300 шагов 1 сид): tf32 off bpb 2.6803 / on 2.6750 (разница в шуме одного сида), train tok/s идентичны на small (41-42k) — на small tf32 НЕ ускоряет (NS-матмулы малы); на b1 профиль давал +16% (1399→1201 мс b8 s1024, это NS-матмулы). Решение: tf32 остаётся OFF по умолчанию, включается флагом --set tf32=true в b1-запусках (train-ключ, в пресет не кладётся — strict schema запрещает train-ключи в пресетах).
• 2026-10-16 (владелец, принцип позиционирования): «мы тренируем модель не ради тренировки, а ради инференса». Priorities follow: (1) выпуск = максимально умная модель при минимальном footprint (квант как продуктовый слой: QAT-финиш + тернарный экспорт; +0.040 BPB за 8-16× — приемлемая цена в худшем режиме 9.2M, на b1 ожидаемо меньше); (2) скорость генерации и контекст — инференс-фичи первого класса. НАХОДКА: FLA 0.5.2 несёт fused_recurrent_kda (fla/ops/kda/fused_recurrent.py, h0/ht параметры) → декод с O(1)/токен через рекуррентное состояние КДА + НЕограниченный контекст (state держит всю историю), в отличие от текущего decode.py (52 строки, re-forward окна per byte, НЕТ KV-кэша). Это главный инференс-приз; задача: рекуррентный generate (GPU = fused_recurrent_kda, CPU-паритет = существующий naive_recurrent референс; численный контракт chunked-vs-recurrent 1.3e-2 fp32 / 4.9e-2 bf16 из kda.py — декоду ок). Порядок инференс-трека: KV-декод → QAT-финиш/экспорт → спекулятивный декод (DSpark задел).
• 2026-10-16 (порт, NS-вердикт, 6 прогонов 3×2k): ns_steps=5 (control) 3.0543/3.0537/3.0585 mean 3.0555 spread 0.0048; ns3 3.0617/3.0616/3.0605 mean 3.0613 spread 0.0012 (+0.0058 = 1.2× контроля-spread → ПРОИГРЫШ по протоколу; предсказание было TIE — не подтвердилось в сторону ns3). Дефолт остаётся 5; ноб в конфиге есть, но 3 не включаем на b1. Экономия была бы ~130 мс/шаг (11% b1) — цена качества не оправдана.
• 2026-10-16 (порт, MSA GPU-смок, ПЕРВЫЙ в истории): b2 s512 20 шагов — MSA+adaptive работает: loss 4.03→3.21, счётчики живые (msa_blocks=1 313 792, msa_iter_gate=40, msa_truncated=4972 на коротких префиксах, KDA рядом). НО b8 s512 = OOM: наивный attend_selected_blocks материализует kk/vv [b,t,m·r,h,hd] = 8·512·128·2048·2·2 ≈ 4.3 GB ×2 + autograd; для b1 (b16 s1024) это ~17 GB — MSA на b1 ФИЗИЧЕСКИ невозможен без memory-фикса. Предсказанный в доках «fused-CUDA gather drop-in» стал измеренной необходимостью: план — chunked/slot-wise gather (цикл по m слотам, пик O(b·t·r·d) вместо O(b·t·m·r·d)), затем A/B на b8 и только потом b1.
• 2026-10-16 (порт, chunked MSA, 71ef0a7): attend_selected_blocks переписан на слот-чанки (MSA_SLOT_CHUNK=4) + по-чанковый torch.utils.checkpoint (голый цикл не спасал — backward ретенит каждый чанк = целый тензор снова). Замеры: b8 s512 OOM→3.15 GiB (гейт пройден), b16 s512 6.06 GiB, callb: chunk=4 минимальный пик (3.15) и в 4.6% от лучшего времени (661 ms). Паритет против наивного per-query референса 3.6e-7..1.1e-6 abs (намного лучше 2e-3), градиентный паритет <1e-5, тест f пиннит 4× счётчик на чанк (упадёт, если снять checkpoint-регион). 376 тестов. Хвост: b16 s1024 adaptive всё ещё OOM (14.1 GiB, m=64) — следующий шаг position-wise index_add scatter или FLA fused gather; b1-числа проекция.
• 2026-10-16 (порт, 1M-контекст вердикт ресёрча, docs/research/2026-10-16-long-context-1m-recipe.md): НАШ рецепт НЕ верифицируем как лучший — на 1M никогда не запускался (самый длинный конфиг на диске s2048). Ключевые пробелы vs SOTA 2026: (1) наш индексер O(t·⌈t/r⌉) квадратичен — код сам это признаёт; published-решение PISA (2609.31093, O(N log N), Triton train+infer) / HISA (two-stage drop-in) / NSA (2502.11089) — брать их, не изобретать; (2) StateFlow (2608.06838): boundary state+GRADIENT propagation across chunks (2.22-2.45×) — у нас BPTT truncation с неизмеренным штрафом; (3) packing без документной маски = при 1M окно в основном cross-document attention (нужен attention-isolated packing); (4) ДАННЫЕ — make-or-break: 500M-5B токенов length-upsampled + domain-balanced CPT для 4K→128K, у нас корпус коротких веб-доков (S); (5) eval: RULER + HELMET (NIAH не предсказывает downstream), SinkProbe@1M; (6) NoteBank (2610.15715) training-free GDN 1.7%→70.3%@1M — кандидат для Engram-архива. K3 несёт KDA+AttnRes+Stable LatentMoE на 1M окне (2.8T/104B). Решение: 1M — ПОСЛЕ базового прогона; брать published-компоненты (PISA/StateFlow/packing/маска/данные), не строить своё; первый шаг трека — PISA-селектор + документная маска + RULER-гейт.
• 2026-10-16 (определение вех, по вопросу владельца «что осталось до Bulba-1»): v0.1 = base b1 (1.08B, 5-20B байтов, eval-кривая + бенчи на байтах) — ближайшие дни: engram_ram GPU-смок → compile-прогрев → короткий b1-ран (10k шагов, валидация LR на 1B) → длинный ран (~1-2 недели GPU при compile). v1 (чат) = v0.1 + SFT-этап (инструкции/диалоги — КОДА НЕТ, надо собрать) + RLVR (код verifier-first есть, не гонялся) + KV-декод (fused_recurrent_kda найден в FLA, не портирован) + выпуск (QAT-тернарный, механика готова). v2 (1M) = PISA-селектор + StateFlow + документная маска + length-upsampled данные. «Революция» честно = первая byte-level 1B, обученная на одной consumer-карте за ~$429+электричество с полной A/B-дисциплиной; НЕ «умнее frontier».
• 2026-10-16 (владелец, КОРРЕКТИРОВКА ЦЕЛЕВОЙ ФУНКЦИИ): «мы оптимизируем качество на FLOP в целом, не под $429; я хочу лучшую архитектуру, и когда появится лучшее железо — просто масштабирование». Следствия для оценки компонентов: (1) loop×4 — не компромисс бедности, а ставка на latent reasoning / adaptive compute (frontier-тренд test-time compute; φ=0.46 + LOOM); под равным FLOP надо доказать loop vs dense; (2) TSCT low-rank — ЦЕНТРАЛЬНЫЙ научный вопрос: rank-64 эксперты vs dense-эксперты при равном АКТИВНОМ compute (A/B в план, dense control); (3) KDA/linear attn и Engram — валидированы как качество/FLOP (Kimi, Qwen); (4) byte-level БЕЗ патчера = постоянный ×3-4 FLOP-налог → ByteFlow переходит из «интересно» в КРИТИЧЕСКИЙ ПУТЬ (условие масштабируемости архитектуры, BLT-путь); (5) квант-лестница — выпуск/инференс-фича, не качество/FLOP. Новое позиционирование: не «модель за $429», а «FLOP-эффективная архитектура, масштабируемая на любое железо»; $429 — текущий полигон.
• 2026-10-16 (владелец, амбиция-ориентир): «вырасти до API-провайдера и передовой лабы». Честная интерпретация под наш масштаб: (1) API — dormouse serve (OpenAI-совместимый, SSE, landed) уже техническая заготовка; реальный публичный демо-эндпоинт = после v1 (чат+SFT+KV-декод); (2) «передовая лаба» = серия честных результатов и открытых артефактов, не самоназвание: tech report #1 «byte-level 1.08B MoE on one 16GB consumer card» (после v0.1), tech report #2 «аддитивны ли пять FLOP-осей (KDA/MoE/TSCT/Engram/patches/loop)» (после A/B), HF-релизы (bf16 + QAT-тернарный), всё уже открыто (docs-site, логи, A/B-протокол). Ниша: FLOP-эффективные byte-level модели + latent-reasoning loops + on-device. Вехи: v0.1 base → v1 чат+API → публикации.
• 2026-10-16 (владелец, мультимодальный горизонт — идея зафиксирована): «не боюсь радикализма, но 150k токенов на картинку — нельзя, надо думать». Радикальная схема для byte-level мультимодальности: НЕ пихать пиксели (150K байтов), а ДИСКРЕТИЗИРОВАТЬ модальность в НАШ СЛОВАРЬ 0..255 — визуальный патчер (VQ-энкодер с 256-кодовой книгой: 224×224 → 28×28 = 784 «байта») превращает картинку в последовательность байтов ТОГО ЖЕ алфавита; аудио → EnCodec-класс 256-кодов; видео → временной ряд. Итог: один backbone (loop+MoE+KDA+Engram), один vocab, ноль модальностных развилок — буквально «универсальный язык». Прецеденты: Chameleon (early fusion VQ-токенов, но свои vocab), LDM (латент), Fuyu (пиксели напрямую — не наш путь). ByteFlow-семейство: текстовый патчер (8 байт→1) + модальностные патчеры (VQ), единый интерфейс «поток байтов». Горизонт: ПОСЛЕ v1; сейчас архитектура не меняется (vocab=256 — это интерфейс, не ограничение).
• 2026-10-16 (владелец, требование к vision): «зрение крутое, видеть даже самые мелкие незаметные детали». Требование к визуальному патчеру (горизонт после v1): 256 кодов на патч НЕДОСТАТОЧНО для мелких деталей — нужна архитектура «детального зрения»: (1) мульти-масштабная пирамида патчей (грубый уровень = сцена, мелкие = детали; wavelet-подобно, ByteFlow local→global уже правильной формы); (2) foveation/адаптивный zoom — модель решает, ГДЕ смотреть в высоком разрешении (человеческий глаз: фовеа + периферия); (3) zoom-по-запросу — сырые байты региона доступны через tool-вызов («посмотри ближе») без пересэмплинга, byte-level это позволяет нативно; (4) AnyRes-подход (Qwen-VL: тайлинг высокого разрешения) как прецедент. Детализация ограничена не только патчером: frontier-VLM тоже теряют мелкие детали (AnyRes/SPHINX — их ответ).
• 2026-10-16 (уточнение по vision, ответ на «1024 токена и зрение супер»): VLM-токен — это НЕ дискретный код, а НЕПРЕРЫВНЫЙ вектор (~d4096, fp16 → ~8 КБ на токен). 1024 токена VLM ≈ 8 МБ визуальной информации; наши 784 байта VQ ≈ 800 байт — разница ~10⁴×. «Супер-зрение» VLM = ViT/SigLIP-энкодер, обученный на миллиардах изображений + непрерывные эмбеддинги. Пути к паритету для нас: (а) RVQ (residual VQ: 2-3 байта на патч = 65K-16M комбинаций, EnCodec-класс) — остаёмся в байтах, детализация растёт на порядки; (б) прагматичный гибрид: готовый ViT-патчер (SigLIP) + наш backbone (как все VLM); (в) zoom-по-сырым-байтам для точных деталей (наш уникальный козырь). Честно: «зрение как GPT-4V» быстрее всего через (б); байтовый радикализм — через (а)+(в).
• 2026-10-16 (владелец: «я хочу лучшее» — vision-рецепт зафиксирован): не компромисс, а максимум: (1) лучший открытый ViT-энкодер (SigLIP-2 / InternViT-класс, обучены на миллиардах изображений) как база зрения; (2) высокое разрешение через тайлинг (AnyRes-стиль, Qwen-VL прецедент); (3) foveation — адаптивный выбор регионов для детального кодирования; (4) raw-bytes zoom — наш уникальный козырь (точные пиксели по запросу, без пересэмплинга); (5) MoE сам выделит vision-экспертов; (6) RVQ-ветка (2-3 байта/патч) — ОПЦИОНАЛЬНО, для будущей генерации изображений. Порядок: после v1; текстовое ядро — сейчас.
• 2026-10-16 (владелец: «а мы не можем свой энкодер?»): честная градация. «С нуля до SigLIP-качества» — НЕТ (нужны миллиарды изображений + кластер; SigLIP-2 = ~40B пар). Реально «своё»: (1) свой РЕСЕМПЛЕР/патчер поверх SigLIP-выходов (perceiver/Flamingo-класс, 20-50M параметров — сжимает 196-1024 векторов SigLIP в компактные патчи для нашего backbone) — стандарт индустрии, даёт контроль над длиной/детализацией; (2) fine-tune готового энкодера на наших данных; (3) research-ветка: ByteFlow-vision — энкодер-декодер end-to-end с нашим backbone (RVQ-подобный, никто не делал byte-level vision в нашей парадигме) — эксперимент, не гарантия; (4) долгосрочно: дистилляция SigLIP в свой компактный энкодер (автономность стека). SigLIP-base 400M ≈ половина нашей модели — ресемплер обязателен.
• 2026-10-16 (порт, data-mixing вердикт, docs/research/2026-10-16-data-mixing.md): 2026-статус: ПОИСК микса подешевел ~550× (FastMix 1.3 GPU-h), но ВЫИГРЫШ спорный — EACL-2026 survey: веса методов «лишь слегка лучше uniform или хуже»; MEDU: эвристики побеждают. ВЫВОД для нас: fitted law НЕ покупать. Shipped-рецепты: Llama3 50/25/17/8; Nemotron 70/15/15; SmolLM2 4 стадии (S4-decay — рычаг: 58/24/14); Swallow (code +17 HumanEval). Рекомендация под наш корпус: S1 (0-70%) 90% web/10% code; S2 (70-90%) 80/15/5; S3 decay (90-100%) 62/20/13/5%RU; ~1.5GB добрать (Stack v2 permissive, FineMath, FineWeb2-RU); ПЕРВЫМ ДЕЛОМ вырезать eval-хвосты code/math/RU (без них ничего не измеримо); RU в decay-фазе (S-спекуляция).
• 2026-10-16 (владелец, формула стратегии): «кто сказал больше лучше — мы возьмём архитектурой». Уточнение: данные — не гонка объёмов, а ПРАВИЛЬНЫЕ ПРОПОРЦИИ (code/math для способностей, eval-хвосты для измерения; ~1.5GB доменных добавок = «правильные домены», не «больше»). Наш путь: максимизировать КОЭФФИЦИЕНТ (качество на FLOP) архитектурой — loop/MoE/KDA/Engram/ByteFlow/TSCT — а не соревноваться в масштабе с лабораториями; когда появится железо, масштабирование с нашим коэффициентом даст больше, чем с обычным. Честная граница: архитектура даёт ×2-5, масштаб ×10-100 (scaling laws) — поэтому база данных необходима, но приоритет — коэффициент.
• 2026-10-16 (порт, engram_ram GPU-смок ЗЕЛЁН — последний блокер снят): 30 шагов small b8 s512 real corpus: loss 3.63→3.28, rc=0, engram_host_updates=10 (каждый шаг), engram_host_update_rows≈40k/шаг, engram_rows=491520 (чтение из host-таблиц). Host-RAM путь Engram работает на GPU. Осталось перед длинным прогоном: ColRow A/B (агент), msaon A/B перезапуск (s3 шёл на НЕзакоммиченном коде fast-MSA агента — bpb 3.5409 невалиден; s1/s2: 3.0421/3.0433 против контроля 3.0567 — предварительный выигрыш −0.014 = 2× spread), medium-калибровка (141.9M пресет создан, aa0b197).
• 2026-10-17 (ВЕРДИКТ+ФЛИП ColRow): A/B 6 прогонов 3×2k small b8 s512 окно 81 920 B: frobenius (исторический) 3.0517/3.0541/3.0567 mean 3.0542 spread 0.0049; colrow (фикс) 3.0226/3.0070/3.0045 mean 3.0113 spread 0.0181. Δ = −0.0428 BPB = 8.7× контроля, НОЛЬ пересечений — САМЫЙ БОЛЬШОЙ выигрыш A/B в истории порта (больше depth 0.007, MSA 0.014). Баг был: batched-группы получали 1/sqrt(d0) апдейта (8× слабее на [64,5461], 45× на [2048,2048]) — все прогоны до 2026-10-17 шли с ним (все A/B валидны относительно друг друга). ФЛИП: TrainConfig.muon_colrow_3d=“colrow” + дефолты Muon/MixOptimizer/colrow_normalize; frobenius остался arm’ом для воспроизведения истории. Каверзы: кривая пересекается (хуже на 1000, лучше на 2000), spread фикса 3.7× — ре-подтвердить на medium/b1.
• 2026-10-17 (fast MSA, e56903c): Triton fused gather (sparse/msa_kernels.py, 366 LOC): 7.6 ms/вызов vs 95 torch (12.5×), training overhead 7.0×→1.6× (325s vs 1442s за 2k шагов), peak VRAM b8 s512 3.61→2.19 GiB, b16 s512 6.97→4.12. Gradient gate поймал баг первой версии (saving running p = 11× dq error; правильно: raw scores + final (max,den)). MSA_KERNEL=auto|torch|triton (модульная константа, пока не config-поле). MSA-вердикт требует перезапуска msaon A/B на этом коде (старый s3 невалиден: шёл на незакоммиченном коде).
• 2026-10-17 (MSA вердикт на чистой базе): msaon2 (colrow+triton) 3.0120/3.0111/3.0077 mean 3.0103 spread 0.0043 vs colrow-контроль (msaoff) 3.0226/3.0070/3.0045 mean 3.0113 spread 0.0181. Δ=−0.0010 = TIE (внутри обоих spread). Первый A/B (на frobenius-базе) показывал −0.014 для MSA — значит тот сигнал был взаимодействием с ColRow-дефектом или шумом; на исправленной базе MSA ничего не даёт на 2k/512. По AGENTS 1.2 tie → механизм выключен в b1 (use_msa=false). НО: настоящая ниша MSA — длинный контекст (8k-32k+), где он ещё не A/B-ен; код+флаги остаются, Triton-route 12.5× быстрее. b1 вернулся к 1 066 358 209.
• 2026-10-17 (medium-калибровка запущена): 141.9M, b8 s768, 6000 шагов, real corpus, engram_ram+tf32, loss 2.70@400 → 2.29@500, 13.3k tok/s стабильно (~46 мин весь прогон). Первый прогон ВСЕГО рецепта на реальных данных на масштабе, где b1-эффекты видны. Лог: ~/logs/medium_run.jsonl.
• 2026-10-17 (НОЧЬ, честный вердикт по чат-демо): SFT на medium работает end-to-end (serve OpenAI API + шаблон 0x01/0x02 + stop-байты 0x03), НО качество ответов слабое — модель выучила формат, но путает инструкции (мешает фразы из разных пар). Причина фундаментальная: medium pretrain был ВСЕГО 6000 шагов = 37 MB = 0.19% корпуса — базовые языковые способности не сформированы, SFT на 500 парах не спасёт. ВЫВОД: чат-качество = pretrain-бюджет. Запущен длинный medium resume (steps=40000, ~4-5 часов, к утру ~40k шагов ≈ 1.6 эпохи корпуса) → потом SFT заново. Найденные и починенные баги вживую: (1) decode_bytes/serve generator на CPU при CUDA тензоре (crash); (2) stop-байт: decode заканчивал, но _generate продолжал чанковать из финального контекста (маркер оставался в выводе); (3) assemble рендерил ‘User:/Assistant:’ вместо SFT-шаблона 0x01/0x02 — ГЛАВНАЯ причина шума. Все три закоммичены с тестами. SFT-чекпоинты: sft1 (n_tasks=128, 3000 шагов), sft2 (256, 4000), sft3 (64, 2500) — sft2 лучший по фразам, но все путают вопросы.
• 2026-10-17 (ФИНАЛ НОЧИ): medium 40000 шагов → eval BPB 2.5407 (12k:2.764, 30k:2.627) — НИЖЕ всех 5-граммных якорей (2.572-2.911), первый порт-прогон обогнавший 5-граммную черту на честном окне (24KB). 18.3k tok/s. SFT v4 от него (3000 шагов): транскрипт v8 — правильные ответы появились (“Are you a human?”→“no”), маршрутизация ещё путается (141.9M + 500 пар). Serve работает на 3783. Следующий масштаб качества — b1 (в 7.5× больше) + SFT на большом корпусе.
• 2026-10-17 (longctx, 80fe74c): TrainConfig.segment_len (0=off) — сегментированный тренировочный форвард с переносом KDA-состояния по сегментам (StateFlow-паттерн arXiv:2608.06838, НЕ truncated BPTT). fla chunk_kda УЖЕ принимает initial_state/отдаёт final_state (chunk.py:185-186; fp32 оба конца; backward берёт dht, возвращает dh0 — :127/:135/:172), fused_recurrent не нужен. Состояние пер-итерационное. Гейты: seg vs one-shot 1.16e-06 CPU, 1.3e-05 на FLA/CUDA, один сегмент = one-shot bit-for-bit. Долг: scripts/smoke_long.py (ms/step + peak GiB seq 2048/4096/8192 b2 seg1024 vs one-shot) НЕ прогнан — карта была занята; прогнать на свободной.
• 2026-10-17 (longctx НАХОДКА): moe_topk>0 + segment_len = молчаливая смена модели — capacity-drop зависит от состава форварда (0.39 на tiny readout при moe_capacity=1.0), поэтому LOUD-отказ. Следствие: b1/medium (topk=2) не могут использовать segment_len, пока capacity-правило не станет независимым от состава окна (dropless-арм = ragged/triton путь без cap — следующий шаг). Отказы того же коммита: use_msa (выбор блоков внутри окна), use_byteflow, rand_depth, segment_len>=seq_len, <0, не-делитель.
• 2026-10-17 (longctx ЗАМЕР, smoke_long): сегментный путь держит VRAM почти плоско — 8k: 791 ms/шаг / 1.06 GiB, 16k: 1605 / 1.23, 32k: 3214 / 1.56; one-shot: 297 / 5.65, 590 / 11.17, OOM(14.6). Экстраполяция: 128k ~4-5 GiB (~13 с/шаг), 256k ~8-10 GiB. Вывод: 128-256k обучение реально, ценой ~2.6x времени (рекомпьют сегментов). seg=1024 (32 сегмента на 32k).
• 2026-10-17 (b1 VRAM-лестница, ~/logs/b1ladder_*): b8 s768 OOM (256 MB аллок, 15.2 GiB), b4 s768 OK (3 шага, loss 6.44→5.22), b8 s512 OK (6.45→5.10) — и b8 s512 несёт БОЛЬШЕ байтов на шаг (4096 vs 3072). dropless активен (moe_dropless=4, дропов 0). expandable_segments обязателен: без него тот же b8 s768 умирает на 128 MB (b1drop.log). Форма запуска = b8 s512.
• 2026-10-17 (АУДИТ порта, docs/reviews/2026-10-17-port-audit.md): 3 CRITICAL / 15 MAJOR / 14 MINOR; калибровка «well-built project, the strongest of the port’s three weeks; defects are the seams of a fast build». Исправлено в тот же день: C1 счётчик синкал GPU (instrument.py:62 порядок — тензор до сравнения); C2 чекпоинты под compile нечитаемы (_orig_mod. префикс — save срезает, load терпит); C3 b1 cap 2.0 = 77% дропов → dropless; M4 два хост-чтения на шаг → одно; M6 рёнгы квантов через load_model_half (eval/decode/serve); M7 банк-стек по-экспертно в dt (убит 1.43 GB fp32 транзиент — OOM-триггер); миноры: dspark-гейты, _pending утечка, json_log в PROGRESS_KEYS, colrow-проза, qat-паритет. Остаток на столе: per-step sync в SFT (mask.sum), adaptive_msa float(share), _naive_dispatch tolist, MSA isfinite assert, eval-tail 1MiB кап, Muon-моментум bf16 (−1.25 GB, literature-backed).
• 2026-10-17 (b1 ЗАПУЩЕН): первый настоящий прогон 1B-масштаба — b8 s512, 50 000 шагов (204.8 MB байтов), engram_ram+tf32+dropless+compile, ~8-9 ч. Лог ~/logs/b1first.log, чекпоинты checkpoints/b1run/b1first.pt каждые 5000, eval каждые 1000 (16 384 B окно). Это milestone: 1.066B total / 57M active на одной 5060 Ti.
• 2026-10-17 (spec-decode, commit 1466f91): спекулятивный декод приземлён — draft-голова предлагает блок, ОДИН verify-forward цели принимает по стандартному rejection-правилу (min(1,p/q) + residual draw; точный при любой температуре, не только greedy). Гейт эквивалентности: байт-в-байт с обычным декодом при temp→0 (k=1,2,4,8). Замеры ворот: идеальный драфт = 0.32 forward/байт (против 1.00); мусорный драфт = 0 принято, но выход всё равно байты цели. bench_spec.py ждёт карту и head-armed чекпоинт (все существующие — dspark_weight=0).
• 2026-10-17 (НАХОДКА spec-decode, важно): forward порта НЕ префикс-каузален, когда MoE дропает назначения — при moe_capacity=1.0 добавление 4 байтов в конец сдвигает логиты последней позиции на 0.91 и переворачивает её argmax; при dropless (capacity=0, что и шипит b1) — совпадение 8e-7. Причина: capacity-дроп зависит от состава окна, значит функция не от префикса. Следствия: (1) spec-decode легален только на dropless (счётчик spec_non_causal считает нарушения); (2) любой декод/инференс на capacity-режиме неконсистентен с ростом окна — ещё один аргумент за dropless как дефолт; (3) это же объясняет, почему сегментация с capacity запрещена (LOUD отказ).
• 2026-10-17 (Triton NS, ns_kind="triton"): fused Triton Newton–Schulz — port/src/dormouse/train/ns_kernels.py, вся цепочка Джордана в ОДНОМ запуске ядра (Грам [r,r] живёт в регистрах, X стримится; транспонирование = подмена двух страйдов, копии нет). Диспатч-дельта ЗАМЕРЕНА на CPU (scripts/bench_ns_triton.py): classic 52 aten на [2048,64], 48 на [64,5461], 123 на [1024,64,64] батче → triton 1 launch (−51/−47/−122). Оценка исследования (~53) подтвердилась. Cap MAX_RANK=64 (r>64 → COUNTED fallback, [2048,2048] в него и попадает), ns_dtype="bf16" НЕ композится (арм его поглощает — COUNTED), счётчики ns_triton / ns_triton_fallback+reason. Хук в optim.py/config.py/loop.py/test_muon_fast.py НЕ применён (чужая линия держит optim+config) — port/ns_triton_hook.patch, git apply --check зелёный на дереве 6fda506+их правки; после патча полный CPU-прогон 533 passed / 39 skipped. GPU-паритет и bench НЕ прогнаны: карта занята b1 (pgrep + nvidia-smi).
• 2026-10-17 (gotcha NS_KINDS): tests/test_muon_fast.py параметризует bf16-гейты по optim.NS_KINDS — новая арм автоматически попадает под них, и CUDA-only арме там нужен Counters() (fallback обязан быть COUNTED, ADR-0019). Именно этот гейт поймал баг «fallback потерял ns_dtype» при написании арма. Правило: новый член NS_KINDS обязан проходить bf16-гейты на CPU, значит либо он чистый torch, либо его fallback точен по rung.
• 2026-10-17 (gotcha полный прогон на занятой карте): CUDA_VISIBLE_DEVICES="" uv run pytest — иначе torch’овский AdamW health-check (torch.accelerator.current_stream()) лезет в CUDA и ~40 CPU-тестов падают OOM’ом при живом b1. Это пре-существующее состояние среды, не связанное с правкой; сравнивать прогоны надо в одном режиме.
• 2026-10-17 (порт, fused MoE backward, 9876ab8): backward dropless-MoE переписан по ИДЕЕ OLMo-core kernels/cuda/moe_unpermute_bwd_kernel.cu (переосмыслено в нашем стиле, не скопировано; file:line в комментариях). moe_kernels._combine_bwd_kernel + _Combine/combine — scatter стал autograd.Function, backward = ОДНО ядро (per token: grad_out читается один раз, цикл по k, [R]-градиент роутер-веса суммируется в регистрах) → нет [R,f] re-read, нет index_add-backward + mul-backward + редукции, и [R,f] fp32 scaled-тензор больше не узел (не сохраняется). _grouped_gemm_pair_kernel + _grouped_nt_pair — dx = dg@gate_uᵀ + du@up_uᵀ в ОДИН аккумулятор, одна запись (было два grouped GEMM + add_). seg — int32 row→expert из того, что пермьют УЖЕ посчитал (kept, один cast), вместо repeat_interleave в каждом backward; rowmap [n,k] int32 с -1 на дропнутое назначение (token→row, layout [n,k], НЕ OLMo’вский [k,n]). BwdWorkspace — grow-only слоты, владелец SparseMoE (в moe_kernels состояния по-прежнему нет; модуль-глобала нет). _triton_dispatch(fused_bwd=True) — дефолт; False = прежняя адъюнкта (гейт паритета + контроль бенча). _fused_bwd_reason (topk > FUSED_TOPK_MAX=32) — единственный отказ, COUNTED как moe_triton_fallback + fused backward: … на counters.why, при этом moe_triton_gemm считается (grouped GEMM реально отработал).
• 2026-10-17 (порт, fused MoE backward — ЧТО ЗАМЕРЕНО и что нет): GPU-паритет НЕ замерен — карта занята живым b1 (pgrep+nvidia-smi первым делом; прогон не тронут). Прогнано и зелёно на CPU: (1) fused-адъюнкта БИТ-ИДЕНТИЧНА референсу — фейковые fp64-GEMM стабы вместо трёх Triton-лаунчеров, fp32 и bf16, с seg от вызывающего и без; это гейт на порядок операций, .to(dtype), переиспользование слотов workspace’а и порядок возврата; (2) forward combine бит-идентичен заменённому scatter’у; (3) rowmap — обратная к gather, включая -1 (в тесте поймался мой же баг: keep маскирует ОТСОРТИРОВАННЫЕ позиции, а rowmap индексируется flat id → дропнутые это order[~keep]); (4) оба новых ядра AOT-компилируются хостовым triton.compile с явным GPUTarget (ASTSource+compile, ptxas на CPU, карту не трогает) — единственный kernel-гейт, работающий на занятой карте; это же доказало, что tl.static_range + if k < K + tl.where(kk==k, …) компилируются. CUDA-гейты (fp32 1e-6 / bf16 2e-2 на dv/dgate_u/dup_u/dx/dprobs; cap 1.0 / 0.25 / dropless) НАПИСАНЫ и SKIPPED. BLOCK_T=16 — единственный тайл без свипа (карта занята): перемерить scripts/bench_moe_kernel.py/bench_moe_dropless.py (обе печатают current-triton vs new-triton vs padded). 542 passed / 46 skipped, ruff чист.
• 2026-10-17 (порт, gotcha: -q дважды глушит итоговую строку pytest): в pyproject.toml addopts = "-q", поэтому pytest -q печатает только warnings-summary, а число passed/skipped НЕ видно (и grep '^[0-9]+ passed' не находит ничего, хотя rc=0). Для честного счёта: pytest -o addopts="" -q.
• 2026-10-18 (порт, state-carry decode, b513f4f): recurrent_decode — пер-итерационное KDA-состояние переносится, шаг = 1 байт через fla.ops.kda.fused_recurrent_kda (initial_state/final_state, fp32; бэкворда нет → только под no_grad), CPU-фолбэк = точная torch-рекуррента kda._recurrent_step (COUNTED kda_step_torch; SDPA-фолбэк НЕ используется — у него нет O(1) состояния). НЕ переносится h (пер-позиционный): порядок позиция-майор == итерация-майор (CPU-гейт 4.8e-7), т.е. шаг = переупорядоченный one-shot, а не вторая реализация. Контракт kda.py: 1.3e-2 fp32 / 4.9e-2 bf16 от RMS KDA-выхода → байты НЕ гарантированно равны decode_bytes; capacity-drop MoE = COUNTED recurrent_non_causal. Флаги decode --recurrent / chat.py --recurrent (дефолт OFF). Гейты на CPU зелёные (шаг vs рекуррента 7.6e-06, one-byte vs window 9.2e-07, O(1) 43.5/39.7/43.5 мс при контексте 8/64/256), GPU-гейт и scripts/bench_decode.py НАПИСАНЫ и SKIPPED (карта занята: pgrep dormouse trai[n] + ab_*.py + nvidia-smi).
• 2026-10-18 (порт, GOTCHA: ВСЕ чекпоинты в checkpoints/ нечитаемы): снапшоты старше удаления шести мёртвых стабов конфига (0e7d25a) несут aux_fb_weight/jepa_weight/use_gr/use_mhc/use_mor/use_situ, и _snapshot_run их теперь LOUD-отказывает (snapshot.model: unknown key(s)). Значит bench_spec.py, chat.py, bench_decode.py и любой decode/eval не запускаются ни на одном существующем чекпоинте — нужен свежий прогон. Это пре-существующее состояние, не связано с state-carry работой.
• 2026-10-18 (порт, fix 584f070): снапшоты снова читаются — config.DEAD_SNAPSHOT_KEYS (dict key→commit) дропает мёртвые ключи в from_snapshot с COUNTED-строкой; список перечислен ЧТЕНИЕМ всех 26 checkpoints/**/*.config.toml, и в нём оказалось СЕМЬ ключей, не шесть: aux_fb_weight удалён отдельным коммитом 39d0485, и шестиключевой список всё равно отказывал всем 24 снапшотам. Тест обходит снапшоты, чтобы список не отстал. Пре-существующий дефект глубже: eval теперь доходит до load_state_dict и падает на Missing key(s): loop.engram.tables (и med1, и b1first) — снапшот резолвится, но энгрем-таблица не в .pt.
• 2026-10-18 (порт, fix a672e1c): энгрем-чекпоинты снова читаются всеми лоадерами — train.loop.load_model_state есть ЕДИНОЕ определение «как грузится engram_ram-чекпоинт»: переключить модель на host-таблицы ДО load_state_dict, затем восстановить сайдкар <ckpt>.ngram; отсутствие сайдкара — тот же LOUD (require_ngram), что и в resume, никакого молчаливого посева свежих строк. Зовут: train-resume, eval, decode, serve, scripts/chat.py, оба decode-бенча. enable_host_tables (не host_tables): CUDA-отказ — правило VRAM-бюджета ТРЕНИРОВКИ, а загрузка должна работать на --device cpu. Гейты в tests/test_cli.py (round-trip через CLI eval; без .ngram — LOUD; in-VRAM путь неизменен). E2E CPU: eval b1first/med1 проходят загрузку (раньше — Missing key(s): loop.engram.tables).
• 2026-10-18 (порт, GOTCHA, НЕ этот фикс): eval/decode на CPU для конфига с MoE ВКЛ (n_experts>0, moe_topk>0) даёт мусор — med1 fin 10.9 BPB / headline 92.3, per-iter CE 24.7→75.8→97.9→102.9 (растёт с глубиной); БИТ-идентично на host и in-VRAM подложках (сравнил load_model_state с копией строк сайдкара прямо в tables-параметр), и in-VRAM MoE-чекпоинт sft/sft1 (engram_ram=false) на CPU читается так же → это дефект CPU-форварда MoE, не энгрем-лоадера; checkpoints/port (moe_topk=0) на CPU даёт нормальные 3.05 BPB. Отдельная задача.
• 2026-10-18 (порт, gotcha CLI): dormouse eval --eval-batches N ВСЕГДА отказывает — eval_batches не в PROGRESS_KEYS, а _snapshot_run разрешает только PROGRESS_KEYS | {"eval_data"} (флаг объявлен в команде, но через резолвер не проходит). Пре-существующее.
• 2026-10-18 (порт, 55c9cca): --init-from идёт через load_model_state — pretrain→SFT с engram_ram-чекпоинта РАБОТАЕТ (раньше raw load_state_dict(strict=False) умирал на Missing key(s): loop.engram.tables, а engram_ram=true у SFT был LOUD-отказ). _init_cfg (sft.py:625) читает субстрат ИЗ ФАЙЛА (нет engram.tables в model-half ⇒ host) и перецеливает out_dir/ckpt_name на init-файл, поэтому сайдкар ищется у <init>.ngram; несовпадение флага с файлом — LOUD с escape (флаг решает host-switch ДО оптимизатора, шаг хоста и запись .ngram). Цикл SFT теперь владеет host-субстратом как train(): enable_host_tables до MixOptimizer, host_step_all раз в шаг + те же счётчики, drop_pending на NaN (без этого память читалась бы и не тренировалась — SILENT, и _pending рос бы). Команда запуска: dormouse sft <preset> --init-from checkpoints/b1run/b1first.pt --set engram_ram=true ... — флаг ОБЯЗАТЕЛЕН (это VRAM-решение: 402M таблиц b1 = 1.6 GB fp32, в-VRAM форма b8 s512 не влезает). Не прогнано: реальная загрузка b1first (5.3 GB + 3.2 GB сайдкар при живом b1-тренажёре); субстрат реального файла проверен чтением ключей.
• 2026-10-18 (порт, gotcha тестов): sft_run(engram_ram=True) теперь НЕ отказ — гейт test_sft_refuses_engram_ram заменён позитивным (test_sft_engram_ram_trains_the_host_tables_and_saves_their_sidecar); в тесте с lr=1e-6 host-строки остаются там, куда их положила загрузка (так проверяется перенос значений 0.5 из чекпоинта); окно-счётчик engram_host_updates на строке лога = 1 (это TOTAL в report["counters"], а не окно).
• 2026-10-18 (порт, bench-харнесс, port/src/dormouse/bench/): байтовый MC-eval — score(c_i) = Σ log p(байт | C+c_i[:j]), ОДИН forward на вариант (батчить нельзя: right-padding меняет capacity-dropping MoE); headline = per-byte mean, raw sum печатается рядом, они РАСХОДЯТСЯ при разной длине вариантов (на checkpoints/port, arc_easy n=5: 0.40 vs 0.20). Окно = model.max_seq_len, длинный айтем DROP с счётчиком bench_dropped (никогда не обрезать): у hellaswag@512 3121 из 10042 айтемов длиннее 512 — это нормальный отчёт, не сбой. CLI: dormouse bench --download (в data_local/bench/), dormouse bench <preset> --ckpt-name X --tasks arc_easy,synth_math --limit N --json-log f.
• 2026-10-18 (порт, bench-источник данных): parquet с HF читать нечем (pyarrow НЕ в зависимостях), поэтому загрузчик идёт через публичный https://datasets-server.huggingface.co/rows (JSON, 100 строк/страница); он rate-limit’ит БУРСТОМ (39 страниц подряд ок, 40-я = 429), поэтому PAGE_DELAY=1.0 + backoff: arc_easy test 2376 строк / 795 634 B (9 с), hellaswag val 10042 / 12 266 702 B (5.5 мин). load_task на отсутствующий файл — LOUD с URL и escape, никогда не пропуск.
• 2026-10-18 (порт, GOTCHA: полный pytest на ЗАНЯТОЙ карте = 112 падений, это НЕ регрессия): torch.optim.AdamW([p]).step() сам падает AcceleratorError: CUDA-capable device(s) is/are busy or unavailable (torch/optim/adam.py:222 _accelerator_graph_capture_health_check → torch.accelerator.current_stream()), т.е. любой CPU-тест, который тренирует, красный, пока живёт dormouse train medium (pid 739357). Замер: дерево HEAD = 599 passed / 104 F / 8 E / 18 skipped, дерево с bench = 619 passed / те же 104 F / 8 E / 18 skipped (мой коммит = +20 зелёных, 0 новых падений). Гейты, которые САМИ скипаются, — только те, что зовут pgrep -f "dormouse trai[n]"; гейт conftest.gpu_free смотрит pgrep -x train (имя Rust-бинаря) и живую порт-рун НЕ видит.
• 2026-10-18 (порт, shard-режим данных, port/src/dormouse/train/data.py): источник-ДИРЕКТОРИЯ в mix plan открывает ShardStream — sorted(*.txt) -> seeded Fisher-Yates (random.Random(seed ^ fnv1a(имя источника))), один открытый файл за раз, в конце последнего шарда wrap в эпоху 2. Sidecar НЕ нужен: конкатенация периодична по sum(shard sizes), поэтому skip_bytes(n) = n % total, отображённый по кумулятивным размерам — точно mid-shard, через границу шарда и через эпоху; гейт — unbroken-vs-resumed прогон через сам train(resume=True) (батч-в-батч). position = (индекс файла в перемешанном порядке, смещение). open_source выбирает режим по ФОРМЕ пути; директория там, где нужен файл, теперь LOUD (было: молчаливый stat() 4096 B как «корпус»); source_size суммирует шарды, поэтому epoch cap видит то, что реально читается. configs/mix_big.toml: web 0.90/wiki 0.10 -> +ruweb+math -> decay 0.35/0.05/0.20/0.40, таблица эпох в шапке (один полный проход 229.8 GB = 44.8M шагов при b10 s512, все <2x, cap 4x кусает на ~108M шагов); code (90 GB) ИСКЛЮЧЁН — это мислейбл-мусор (спам/новеллы/форумы, проверено сэмплированием), math включён вместе со своим форумным шумом (вес растёт только в decay), reasoning (2.4 GB) исключён арифметикой (4 эпохи = 4.2% одного прохода).
• 2026-10-18 (порт, GOTCHA, не мой таск): прогон с mix_plan всё ещё требует заполненного train.data — loop.py:520 зовёт open_streams(run) безусловно ради eval-стороны, а open_streams LOUD-отказывает на пустом data даже при eval=false. Фоллоу-ап: не звать open_streams, когда eval выключен (и не терять открытый train-стрим, который там же выбрасывается).
• 2026-10-18 (порт, pre-existing, проверено на HEAD): ruff format --check . КРАСНЫЙ на 6 нетронутых файлах (src/dormouse/cli.py, src/dormouse/model/tsct.py, tests/test_decode_recurrent.py, tests/test_post_rl.py, scripts/bench_decode.py, scripts/bench_fp8_mm.py) — ruff check . зелёный; не «чинить» их из чужого диффа. И test_decode_recurrent::test_per_byte_cost_does_not_grow_with_context — CPU-timing флейки под нагрузкой (падает 1 из 2 полных прогонов, в одиночку зелёный).

2026-10-19 — the CUDA-graph version freeze (the medbig2/b1night defect)

A CUDA-graph replay moves a parameter’s VALUE without bumping _version (measured: eager step 0->1, replay frozen). SparseMoE._banks keys its cache on _version, so with opt_graph=true the key froze at capture (~step 5) and the bank served that build for the whole run: the experts were FROZEN in the forward while the optimizer kept stepping them with stale gradients (drifted ~44x; the checkpoint exploded in a fresh process while the live evals looked fine — they reused the same stale bank). Fix: invalidate_banks_all(model) once per trained step (train/loop.py, train/sft.py) + tests/test_bank_invalidation.py pins the premise. Invalid as bases: medium_big2, b1night, sft9. The overnight re-run (mix1) uses the fix.