name: set-not-required-leveva description: leveva does NOT need the SET command (P11); skip it when picking the next slice metadata: node_type: memory type: project originSessionId: cf6db86f-cde3-4c79-827b-0d593d0b1f5b#

The SET command (oracle m_set in s_serv.c: oper runtime tunables — POOLSIZE, ACONNECT, CACCEPT — gated on ACL_SET, echoing NOTICE lines) is not required for leveva — per the user (2026-06-09). Do not implement it as a P11 slice.

Why: the user ruled it out of scope. The three tunables don't map cleanly onto leveva: POOLSIZE is a C dbuf-pool detail with no analogue in the tokio model; ACONNECT has no consumer (leveva has no auto-connect loop — CONNECT is oper-only); only CACCEPT would have a real consumer, not enough to justify the slice. OperPrivilege::Set exists in the privilege enum but stays a dormant, deliberately-unconsumed variant — like OperPrivilege::Close ([[close-not-required-leveva]]) and SidTrace.

How to apply: when scanning the oracle msgtab (in ircd-common/src/parse.rs) for the next unported client/oper command, treat SET like the other already-excluded rows: CLOSE ([[close-not-required-leveva]]), SUMMON ([[summon-utmp-not-required]]), SERVICE/SQUERY/SERVLIST ([[leveva-service-is-client-services]]), and the S2S/services rows. OperPrivilege::Set being dormant is NOT a signal to build SET. The other remaining oper-reachable debug rows (HAZH/HASH, DNS) are similarly low-value C-internal-stats commands — check with the user before building them. Related: [[leveva-command-folder]], [[leveva-pivot-p9-retired]].