MB678 continues the progressive decomposition of Mediabot’s Partyline subsystem.
This round extracts the channel moderation/control command family from the historical Mediabot::Partyline parent into Mediabot::Partyline::Commands.
The scope is deliberately limited to:
_cmd_bans
_cmd_ban
_cmd_unban
_cmd_topic
_cmd_kick
_cmd_unmute
The objective is architectural only: move responsibility without changing moderation rules, privilege checks, WHOIS handling, command syntax, IRC effects, or the historical Mediabot::Partyline::* method surface.
The following methods moved from:
Mediabot/Partyline.pm
to:
Mediabot/Partyline/Commands.pm
Methods:
_cmd_bans
_cmd_ban
_cmd_unban
_cmd_topic
_cmd_kick
_cmd_unmute
Together they form a coherent channel-control family:
Before MB678-IV-L:
Mediabot/Partyline.pm : 1577 lines
Mediabot/Partyline/Commands.pm : 3659 lines
After MB678-IV-L:
Mediabot/Partyline.pm : 1322 lines
Mediabot/Partyline/Commands.pm : 3941 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 now stands at:
1322 lines
The parent has therefore lost more than five and a half thousand lines of mixed responsibility while preserving the historical callable surface.
These methods remain callable through:
Mediabot::Partyline
after extraction:
_cmd_bans
_cmd_ban
_cmd_unban
_cmd_topic
_cmd_kick
_cmd_unmute
Focused validation confirmed:
6/6 historical methods available
The dispatcher continues to use the same Partyline method names.
Older tests that depended on the former physical source layout were adapted:
t/cases/12_hotfix_after_claude.t
t/cases/870_mb678_partyline_karma_commands_extraction.t
t/cases/872_mb678_partyline_reload_commands_extraction.t
t/cases/873_mb678_partyline_network_stats_commands_extraction.t
t/cases/874_mb678_partyline_irc_control_commands_extraction.t
t/cases/875_mb678_partyline_ai_commands_extraction.t
t/cases/876_mb678_partyline_runtime_diagnostics_commands_extraction.t
A new extraction contract was added:
t/cases/877_mb678_partyline_channel_moderation_commands_extraction.t
The targeted validation also included existing behaviour contracts relevant to moderation, including the real .kick path.
Focused set:
12
21
586
870
872
873
874
875
876
877
Result:
PASSED : 308/308 (1s)
.kick behaviour preservedThe existing .kick behaviour was not merely checked by source-contract assertions.
The established runtime-oriented test path was included in the targeted suite on the real development environment.
This is important because the sandbox used during patch preparation cannot load the full Perl dependency stack used by those runtime contracts.
Server-side result:
PASS
No product workaround was introduced.
MB678-IV-L does not absorb unrelated responsibilities.
These remain intentionally in Partyline.pm:
.history
.say
.who
.eval
.die
as well as the remaining flood/cooldown/runtime-core logic.
That separation matters more now than raw line count: MB678 is approaching the stage where the remaining parent must be judged by responsibility, not by size alone.
The fast lane was executed with progress mode:
perl t/test_commands.pl --fast --progress
Selection:
322 of 760 discovered test files
Result:
[====================] 100% [322/322 files | 5907 tests]
PASSED : 5907/5907 (65s)
The development service restarted successfully:
mediabot@dev : active
Partyline remained available on:
0.0.0.0:23456
The TCP smoke test returned the expected authentication flow:
Mediabot Partyline
Please enter your nickname.
Enter your password.
Result:
RC_SMOKE=0
No obvious runtime errors appeared in the journal.
The full project security audit remained green:
RC_AUDIT=0
Verdict: GO — all 11 security invariants hold.
The moderation extraction therefore did not weaken any audited authentication, throttling, download-cap, or related security guarantee.
The complete suite was executed with progress mode:
perl t/test_commands.pl --progress
Result:
[====================] 100% [760/760 files | 14945 tests]
PASSED : 14945/14945 (211s)
No follow-up product fix or source-contract repair was required.
Moderation is a real responsibility boundary.
Keeping ban/topic/kick-related commands together in Commands.pm gives the Partyline architecture a clearer separation between:
transport
sessions/authentication
dispatch
commands
runtime diagnostics
AI
moderation
At the same time, the user-visible rules remain unchanged:
same commands
same privilege model
same IRC effects
same method names
same runtime behaviour
After IV-L, Partyline.pm is only:
1322 lines
The next rounds should not pursue line-count reduction as an objective by itself.
The correct question is now:
Which remaining responsibilities genuinely belong in Partyline.pm?
and only secondarily:
Which remaining command families still deserve extraction?
This is the point where a safe refactor can become an over-refactor if architectural judgment is replaced by mechanical movement.
The broader roadmap remains:
finish MB678 on architectural criteria
↓
complete the remaining update/observability work
↓
consolidate documentation
↓
run a full 3.5 readiness audit
↓
publish 3.5 only after explicit GO
The readiness gate must still cover fresh install, upgrade, migrations/schema drift, secrets, security, CI, real updater operation, IRC runtime, documentation, release artefacts, fast suite, and full suite.
Version : 3.4dev-20260821_131229
Commit : ce059f7
Branch : master
🛡️ Give Partyline Moderation Its Own Auror Office Without Changing the Rules
Commit summary:
11 files changed
411 insertions
293 deletions
New test:
t/cases/877_mb678_partyline_channel_moderation_commands_extraction.t
The commit was successfully pushed to GitHub.
🛡️ The Aurors moved offices. The law did not change.
You must be logged in to reply.