···7777- [leveva KNOCK (slices 198–200, 209)](leveva-knock.md) — leveva-native charybdis-style KNOCK to a +i/+k/+l channel (710/711); shares the JOIN check_join gate; S2S propagation done (199, `ENCAP * KNOCK`); per-channel 712 flood throttle done (200, `knock_throttle::KnockThrottle`, local-path only); per-user throttle done (209, `knock_delay` 300s, second `knock_user_throttle` keyed by UID, `cooling`/`arm` peek-then-arm split); family complete; 210 = both `knock_delay`/`knock_delay_channel` are now REHASH-able `options { knock-delay / knock-delay-channel }` knobs (0 disables)
7878- [leveva flood penalty (slices 201–208, COMPLETE)](leveva-flood-penalty.md) — command-rate flood protection (the IRCnet "fakelag" penalty clock), deferred since the start; `flood::FloodClock` (idle-decay, Excess Flood kill), armed by the serve loop NOT `Session::new` (heartbeat opt-in precedent — synthetic-burst tests don't trip it unless they call `enable_flood_protection()`); lit up the dead can-flood/no-penalty privileges; 202 = per-command cost table (`command_penalty`: PONG exempt, WHO/LIST/etc +4, JOIN/KNOCK/INVITE +2); 203 = pre-registration guard (charge the same clock in the `Registering` phase too, after QUIT/before CAP); 204 = `options { flood-kill-ahead N }` config knob (REHASH-reloadable via ConfStore, parser rejects 0, NO ServerContext field — flood is serve-loop-armed); 208 = the fakelag *delay/smoothing* half (`MAX_PENALTY`=10 const; serve loop `sleep_until`-parks the read arm when the clock is past the threshold, output arms stay live; `delay_secs`/`flood_delay_secs`, `charge` unchanged) — family now COMPLETE; 210 = `MAX_PENALTY` is now a REHASH-able `options { max-penalty }` knob (default 10, 0=aggressive smoothing) — no flood threshold remains a const
7979- [leveva +C no-CTCP + flag-mode wiring](leveva-noctcp-and-flag-mode-wiring.md) — slice 220 `+C` (charybdis MODE_NOCTCP, PRIVMSG-only, distributed enforcement); THE GOTCHA: adding a channel flag mode needs BOTH `ChanMode` (mode.rs) AND `command::mode::supported_flag` (the second allowlist) or the MODE command 472s; `channel::is_blocked_ctcp` + `Channels::blocks_ctcp` seam; family extended with `+T` no-NOTICE (239) and `+g` free-invite (240, charybdis MODE_FREEINVITE — any member may INVITE; gate `channel::free_invite_allows` in `Channels::invite`; `g` is the *channel* letter, disjoint from user-mode `+g` CallerId) and `+r` registered-only join (241, charybdis MODE_REGONLY — hard JOIN gate via `channel::regonly_blocks` in `check_join`, 477 reusing ErrNochanmodes; reclaiming the ripped-out reop letter `r` hit the unknown-chanmode-letter-is-gt hazard)
8080-- [golden read_until timeout flake](golden-read-until-timeout-flake.md) — boot-golden tests flake under load (read_until breaks on socket read-timeout, returns partial buffer, panic point shifts between runs); stash-and-rerun to confirm pre-existing, not a slice regression (observed golden_restricted_op 2026-06-16)
8080+- [golden read_until timeout flake — FIXED](golden-read-until-timeout-flake.md) — FIXED 2026-06-17 (commit 7718cdc1): read_until now waits to a 30s overall deadline instead of bailing on the first per-read timeout, so the load-induced partial-buffer "no NNN" panic is gone; a load read_until panic now means a real bug, not this flake (deterministic fakelag-parking failures were separate, fixed slice 238)
8181- [leveva stale deferral comments](leveva-stale-deferral-comments.md) — many "out of scope"/"deferred" doc comments in leveva src are STALE (feature landed in a later slice, comment never updated); verify against code first — confirmed stale: connlimit max_global_* (done slice 150), kill inbound-S2S notice (185), wss +Z (213+227); slice 229 closed metadata SYNC (774 ruled a deliberate divergence) → the draft/metadata-2 track is now COMPLETE, no metadata follow-ons remain
8282- [leveva +z op-moderation](leveva-opmod-plus-z.md) — `+z` (charybdis MODE_OPMODERATE): a `+n`/`+m`/`+b`-blocked message on a `+z` channel redirects to ops not 404; slices 235 (PRIVMSG/NOTICE local), 236 (TAGMSG/REDACT local), 237 (PRIVMSG/NOTICE S2S via the `@<chan>` statusmsg op-redirect seam), 238 (TAGMSG/REDACT S2S on that same seam) — **track COMPLETE, no follow-on**
···11---
22name: golden-read-until-timeout-flake
33-description: leveva boot-golden tests can flake under load — read_until breaks on a socket read-timeout and returns a partial buffer; not a regression
33+description: FIXED 2026-06-17 — leveva boot-golden read_until now waits to an overall deadline instead of bailing on the first per-read timeout; the load-induced partial-buffer flake is gone
44metadata:
55 node_type: memory
66 type: project
77 originSessionId: 29eaf964-8bde-4b89-952c-0208be9c6a10
88---
99+1010+**FIXED 2026-06-17 (commit 7718cdc1).** The shared `read_until` (now a single
1111+`read_until_impl` in `leveva/tests/harness/mod.rs`, used by both `Client` and `Peer`)
1212+no longer breaks on the first per-read timeout. A `WouldBlock`/`TimedOut` is treated
1313+as a **transient stall** — keep reading until a generous 30s overall deadline; break
1414+early only on real EOF (`Ok(0)`) or a genuine socket error. This is exactly the
1515+"wall-clock deadline that distinguishes timed-out-mid-reply (retry) from stream-closed
1616+(stop)" the old note below called for. Common path (sentinel arrives) is unchanged;
1717+negative tests never depend on the timeout path (they use a second PING/PONG
1818+observable) so the higher ceiling costs them nothing. Verified: `golden_restricted_op`
1919+green 6/6 under concurrent golden-suite load; full `cargo test -p leveva` exit 0.
2020+**So: a load-induced `read_until` partial-buffer "no NNN" panic should no longer
2121+happen** — if you see one now, suspect a real logic bug, not this flake. (The
2222+*deterministic* fakelag-parking failures below were separate and already fixed in
2323+slice 238 via per-test `max-penalty` headroom.)
2424+2525+---
2626+*Historical context (pre-fix):*
9271028The `leveva/tests/harness` boot-golden `Client::read_until(sentinel)` loops
1129`stream.read()` and **breaks on `Err(_)`** (a socket read-timeout) as well as on