MB678 continues the progressive decomposition of Mediabot’s Partyline subsystem.

After separating transport, session/authentication, dispatch, plugin commands, core operator commands, and scheduler/operational commands, MB678-IV-D extracts the next coherent command family: channel and network visibility.

The objective remains conservative and explicit: move implementation responsibility without changing Partyline protocol, command syntax, privilege semantics, output behaviour, or the historical Mediabot::Partyline method surface.

---

🌐 What moved

MB678-IV-D moves the following methods from:

Mediabot/Partyline.pm

into:

Mediabot/Partyline/Commands.pm

Methods moved:

_cmd_channels
_cmd_bcast
_cmd_whochan
_cmd_top

This family covers:

• joined/parted channel visibility;
• IRC and database channel state;
• channel owner and related metadata;
• Master-level Partyline broadcast;
• locating the channels where a nickname is present;
• channel/global top-speaker statistics.

The dispatcher remains unchanged.

It continues to invoke these methods through the historical $self->_cmd_* surface.

Mediabot::Partyline imports the moved methods back from Mediabot::Partyline::Commands, preserving compatibility for existing callers and tests.

---

🧱 Structural result

Before MB678-IV-D:

Mediabot/Partyline.pm          : 3226 lines
Mediabot/Partyline/Commands.pm : 1894 lines

After MB678-IV-D:

Mediabot/Partyline.pm             : 2974 lines
Mediabot/Partyline/Commands.pm    : 2157 lines
Mediabot/Partyline/Dispatcher.pm  :  407 lines
Mediabot/Partyline/SessionAuth.pm :  676 lines
Mediabot/Partyline/Transport.pm   : 1012 lines

This round is a structural milestone:

Partyline.pm < 3000 lines

The original pre-MB678 Partyline.pm was:

6976 lines

It is now less than half that size while preserving the same external Partyline behaviour.

The next command family begins with community/reminder commands and remains intentionally outside IV-D.

---

🧪 Focused validation

The previous operational extraction contract was evolved:

t/cases/867_mb678_partyline_operational_commands_extraction.t

and a new IV-D extraction contract was added:

t/cases/868_mb678_partyline_channel_commands_extraction.t

The targeted IV-D validation covered the existing Partyline top/channel behaviour together with both extraction boundaries.

Result:

PASSED : 110/110

The historical method surface was explicitly checked for:

_cmd_channels
_cmd_bcast
_cmd_whochan
_cmd_top

Result:

4/4 resolved through Mediabot::Partyline

No additional source-contract cleanup was required during IV-D.

---

⚡ Fast suite

The complete fast suite passed cleanly:

PASSED : 5766/5766  (64s)

No fast regression was introduced by the extraction.

---

🛡️ Security audit

The security audit remained completely green:

RC_AUDIT=0
Verdict: GO — all 11 security invariants hold.

The extraction did not weaken any current authentication, transport, sanitisation, process-locking, download-cap, or external-command security invariant.

---

🔌 Real runtime validation

The development service restarted successfully:

mediabot@dev : active

The Partyline listener remained available on:

0.0.0.0:23456

A real TCP smoke test produced:

Mediabot Partyline
Please enter your nickname.
Enter your password.

Result:

RC_SMOKE=0

The service journal showed no obvious runtime errors.

---

🏰 Full suite

The complete regression suite passed without any contract cleanup round:

PASSED : 14678/14678  (206s)

This is the cleanest command-family extraction in the MB678-IV sequence so far.

---

🧠 Why this matters

Channel and network visibility form a natural Partyline responsibility boundary.

Moving .channels, .bcast, .whochan, and .top together improves the architecture without mixing in unrelated reminder, configuration, AI, moderation, or IRC-control commands.

More importantly, MB678-IV-D crosses an important structural threshold:

6976 lines before MB678
2974 lines after MB678-IV-D

The parent Partyline module has lost more than 4000 lines of mixed responsibility while retaining the same public surface.

The subsystem now has clear boundaries for:

• transport;
• session/authentication;
• dispatch;
• plugin commands;
• core operator/session commands;
• scheduler/operational commands;
• channel/network visibility commands.

No Partyline command syntax changed.

No privilege model changed.

No network behaviour changed.

No historical method disappeared.

The Floo Network still connects the same fireplaces; the routing is simply better organized.

---

📦 Commit

Version : 3.4dev-20260821_064155
Commit  : 5f48853
Branch  : master

🌐 Give Partyline Channel Commands Their Own Floo Network Without Changing the Connections

Commit summary:

5 files changed
333 insertions
261 deletions

New test:

t/cases/868_mb678_partyline_channel_commands_extraction.t

The commit was successfully pushed to GitHub.

---

🌐 Every fireplace still leads to the same place. The Floo Network just has a cleaner map now.