MEE6 replacement — temporary voice channels (hub → personal VC, cleanup)

[SyniRon]

7Cav has asked CavBot2 to subsume MEE6 features. First concrete ask: temp VC management.

Behavior: a user joins a configured "hub" voice channel → the bot creates a personal channel for them → the channel is deleted when empty.

Open design questions:

• Creation trigger config (which hub channel(s), per-guild config shape)
• Permission / ownership model on the spawned channel
• Channel naming convention
• Cleanup logic (delete-on-empty timing, edge cases like everyone disconnecting simultaneously)
• Persistence across bot restarts (in-memory map vs. recoverable state)

Likely promotes to a multi-day project once design is settled.

[SyniRon]

This was generated by AI during triage.

Triage Notes

What we've established so far:

• This is the first concrete slice of the broader MEE6 → cavbot2 migration; MEE6 replacement audit — enumerate current MEE6 features on the 7Cav guild #99 covers the full audit but this can proceed in parallel without waiting on it.
• cavbot2 has no gateway-event subscriptions today. Temp VC management is the first feature that needs them — modest architectural shift, but limited surface (only VOICE_STATE_UPDATE is required).
• GuildVoiceStates is an unprivileged intent — code-side enable only, no Developer Portal toggle needed.
• No voice audio handling involved (this is channel-lifecycle management, not audio plumbing — much lighter than [CavBot2] Implementing Craig-Like Recording Features #10).

Proposed defaults — please confirm, change, or push back on each:

1. Hub channel config.
   Proposed: Single hardcoded hubVoiceChannelID constant (matches the 7Cav-specific pattern used for role IDs in /warden and the Star Citizen role in Add recurring report for recent joiners with Star Citizen role #98). Future multi-hub support deferred to YAGNI.
   Need from you: The hub voice channel ID (or "I'll set one up and tell you").

2. Permission / ownership model on the spawned channel.
   Proposed: Creator becomes the temporary "owner" — granted MANAGE_CHANNELS + MOVE_MEMBERS via a per-channel PermissionOverwrite scoped to themselves only. This lets them rename the channel, set a user limit, and kick/move others (matches MEE6 default UX). Owner status is implicit (not stored); the permission overwrite IS the marker.
   Question: Accept MEE6-style owner, or simpler "anyone in channel has equal say" model?

3. Naming convention.
   Proposed: <Username>'s Channel (MEE6 default). Alternative: 7Cav-flavored like 🎙 <Username> or rank-aware like <Rank> <Username>.
   Question: Default name? (Note: owner can rename via Discord UI once channel exists, given the permission overwrite above.)

4. Cleanup logic.
   Proposed: Subscribe to VOICE_STATE_UPDATE. When member count in a temp channel reaches 0, delete after a 15-second grace period (handles quick disconnect/reconnect, momentary "everyone joined another channel then came back" cases). On bot startup, sweep the temp-channel parent category and delete any empty channels (handles orphans from restarts).
   Question: 15s grace OK, or shorter/longer?

5. Persistence across restarts.
   Proposed: Use a dedicated parent category ("Temp Voice" or similar) as the marker for temp channels. In-memory map for ownership tracking during runtime. On restart, the category sweep cleans up empty channels; surviving non-empty channels are "adopted" with no recorded owner (owner permission overwrite already on the channel, so functionality is preserved — the bot just doesn't know who created it). No external persistence layer (no DB, no JSON file).
   Question: Accept "in-memory + category sweep on startup", or do you want recoverable per-channel ownership (would need a small persistence layer)?

Additional questions (not in original body but blocking scope):

• Temp channel parent category — does one exist already, or should the bot create it on startup (or assume it exists and error if not)?
• Max concurrent temp channels per user — cap at 1 (joining hub while already owning a temp channel = move them to their existing channel)? Or unlimited?
• What happens if the owner leaves but others stay — channel persists with owner gone; permission overwrite goes stale. Acceptable (channel deletes when last person leaves), or should ownership transfer to the next-longest-tenured member?
• Audit log — should the bot log create/delete events to a staff channel for visibility, or run silently?

Once these are settled I can post a ready-for-agent brief. Expect the implementation to be a single PR, but with meaningful architectural surface (first gateway-event handler + first multi-step lifecycle logic in the codebase).