Problem
The core.* config namespace was meant to mirror bot lifecycle events (startup, errors, config changes, cron, cleanup) to dedicated Discord channels. Audit shows:
- Only
core.cleanup.channel_id is actually consumed (src/services/voice-channel-truncation.ts:94).
- The matching
core.cleanup.enabled gate isn't checked — posts happen unconditionally when the channel ID is set.
- Every other
core.* key pair (startup, errors, config, cron) is completely unwired.
So today the namespace half-exists. In the v1.0 admin-panel world, operators have a real UI for surfacing bot events (Dashboard, future Logs page) — Discord-channel mirroring is largely redundant and adds setup friction.
Proposed change
Pick one path during implementation:
Path A (delete it, recommended): Remove the entire core.* namespace. Cleanup notifications move to a future dashboard/notification-center UI. Startup migration drops the keys. Aligns with "WebUI is the source of truth" direction.
Path B (finish it): Implement the wiring for startup, errors, config, cron. Honor .enabled gates uniformly. Define and document what each channel actually receives.
My read: A — the future of operator-facing event surfacing is the WebUI, not a sprawl of Discord channels. Worth a decision before implementation.
Acceptance (path-dependent)
- Path A:
core.* keys gone from ConfigSchema, no orphan rows after migration, no regression beyond losing Discord-channel cleanup notifications.
- Path B: every
core.* key pair has a corresponding emitter, gated by its .enabled, with at least one test per emitter.
Notes
Problem
The
core.*config namespace was meant to mirror bot lifecycle events (startup, errors, config changes, cron, cleanup) to dedicated Discord channels. Audit shows:core.cleanup.channel_idis actually consumed (src/services/voice-channel-truncation.ts:94).core.cleanup.enabledgate isn't checked — posts happen unconditionally when the channel ID is set.core.*key pair (startup,errors,config,cron) is completely unwired.So today the namespace half-exists. In the v1.0 admin-panel world, operators have a real UI for surfacing bot events (Dashboard, future Logs page) — Discord-channel mirroring is largely redundant and adds setup friction.
Proposed change
Pick one path during implementation:
Path A (delete it, recommended): Remove the entire
core.*namespace. Cleanup notifications move to a future dashboard/notification-center UI. Startup migration drops the keys. Aligns with "WebUI is the source of truth" direction.Path B (finish it): Implement the wiring for
startup,errors,config,cron. Honor.enabledgates uniformly. Define and document what each channel actually receives.My read: A — the future of operator-facing event surfacing is the WebUI, not a sprawl of Discord channels. Worth a decision before implementation.
Acceptance (path-dependent)
core.*keys gone fromConfigSchema, no orphan rows after migration, no regression beyond losing Discord-channel cleanup notifications.core.*key pair has a corresponding emitter, gated by its.enabled, with at least one test per emitter.Notes
.enabledkeys); whichever ships second can no-op the redundant work.