MB678 continues the progressive decomposition of Mediabot’s Partyline subsystem.
This round extracts the anti-flood / cooldown operator-control family from the historical Mediabot::Partyline parent into Mediabot::Partyline::Commands.
The scope is deliberately narrow:
_cmd_floodset
_cmd_cmdcooldown
_cmd_netsplit
_cmd_floodstatus
_cmd_flushcooldown
These commands form a coherent operational responsibility around in-memory anti-flood, cooldown, and netsplit protection controls.
The objective remains architectural only: move responsibility while preserving behaviour, historical method names, dispatcher routing, and runtime policy.
The following methods moved from:
Mediabot/Partyline.pm
to:
Mediabot/Partyline/Commands.pm
Methods:
_cmd_floodset
_cmd_cmdcooldown
_cmd_netsplit
_cmd_floodstatus
_cmd_flushcooldown
Together they cover:
Before MB678-IV-M:
Mediabot/Partyline.pm : 1322 lines
Mediabot/Partyline/Commands.pm : 3941 lines
After MB678-IV-M:
Mediabot/Partyline.pm : 1127 lines
Mediabot/Partyline/Commands.pm : 4153 lines
Mediabot/Partyline/Dispatcher.pm : 407 lines
Mediabot/Partyline/SessionAuth.pm : 676 lines
Mediabot/Partyline/Transport.pm : 1012 lines
The original pre-MB678 Partyline.pm contained:
6976 lines
It is now down to:
1127 lines
At this stage, line-count reduction is no longer the goal by itself. The remaining parent is small enough that each remaining responsibility must now be judged architecturally.
The following methods remain available through:
Mediabot::Partyline
after extraction:
_cmd_floodset
_cmd_cmdcooldown
_cmd_netsplit
_cmd_floodstatus
_cmd_flushcooldown
Focused validation confirmed:
5/5 historical methods available
The dispatcher therefore keeps using the same historical Partyline surface.
The existing anti-flood source contract:
t/cases/338_antiflood_partyline_floodstatus.t
was adapted so it no longer assumes _cmd_floodstatus must physically live in the parent module.
A new extraction contract was added:
t/cases/878_mb678_partyline_antiflood_commands_extraction.t
The targeted server-side validation covered:
338
870
872
873
874
875
876
877
878
Result:
PASSED : 272/272 (1s)
This server result is the reference count for the exact IV-M targeted selection.
IV-M does not touch the remaining Partyline core or unrelated operator commands.
Still intentionally present in Partyline.pm after this round are responsibilities such as:
new / get_port / runtime-status
.history
.say / .who
.eval / .die
.logs / .nickinfo / .who_chan
.kv
.achievementprofile
Whether all of these belong permanently in the parent is now a question for the final boundary audit, not an assumption.
The fast lane was executed with progress mode:
perl t/test_commands.pl --fast --progress
Selection:
322 of 761 discovered test files
Result:
[====================] 100% [322/322 files | 5907 tests]
PASSED : 5907/5907 (64s)
The development service restarted successfully:
mediabot@dev : active
The Partyline listener remained available:
0.0.0.0:23456
The TCP smoke test returned:
Mediabot Partyline
Please enter your nickname.
Enter your password.
Result:
RC_SMOKE=0
No obvious runtime error appeared in the service journal.
The security audit remained fully green:
RC_AUDIT=0
Verdict: GO — all 11 security invariants hold.
The anti-flood control extraction therefore did not weaken the audited authentication or runtime protections.
The complete suite was run with progress enabled:
perl t/test_commands.pl --progress
Result:
[====================] 100% [761/761 files | 14987 tests]
PASSED : 14987/14987 (211s)
No corrective follow-up was required.
Anti-flood and cooldown controls form a real operator-control responsibility. Keeping them grouped in Commands.pm makes the remaining Partyline.pm substantially easier to reason about.
More importantly, IV-M marks a transition in the MB678 project:
Before:
identify obvious command families and extract them.
Now:
determine what the parent itself should legitimately own.
This is exactly the right moment to stop using file size as the primary signal.
After IV-M:
Partyline.pm : 1127 lines
The next round should begin with an exhaustive boundary audit.
Every remaining subroutine should be classified as one of:
A. legitimate Partyline core
B. remaining autonomous command family
C. transverse helper better owned by an existing module
D. dead / obsolete / suspicious residue
MB678 should close when the parent has a coherent responsibility, not when it reaches an arbitrary line count.
The broader trajectory remains:
finish MB678 on architectural criteria
↓
complete remaining update / observability work
↓
documentation / architecture consolidation
↓
full 3.5 readiness audit
↓
3.5 stable only after explicit GO
The future readiness gate still includes clean Debian 13 installation, upgrade path, migrations/schema drift, secrets review, security, CI, updater runtime, IRC runtime, documentation, public artefacts, fast suite, and full suite.
Version : 3.4dev-20260821_134534
Commit : 90c3d40
Branch : master
🌊 Give Partyline Anti-Flood Its Own Dam Without Changing the Flow
Commit summary:
5 files changed
316 insertions
202 deletions
New test:
t/cases/878_mb678_partyline_antiflood_commands_extraction.t
The commit was successfully pushed to GitHub.
🌊 The dam moved. The current kept exactly the same course.
You must be logged in to reply.