Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@internal/service/slack/bot.go`:
- Around line 290-294: The code assumes strings.Fields(text) has at least one
element and will panic on whitespace-only input; before accessing [0], ensure
the fields slice is non-empty (e.g., call strings.Fields(text) into a variable,
check len(fields) > 0 or use strings.TrimSpace(text) to early-return), then
extract cmd and only call b.handleTextCommand(ctx, cs, cmd) when a command
exists; update the block around the text handling (referencing the variables
text, cmd and the method b.handleTextCommand) to perform this guard and avoid an
index out of range panic.

In `@internal/service/slack/monitor.go`:
- Around line 177-184: The current loop over m.bot.allowedChannels uses
allDelivered to decide whether to mark the run as seen, which causes retries to
re-notify channels that already succeeded; change the behavior to record
seen/delivery per-channel instead of a single allDelivered flag by updating the
run's seen state (or calling the existing markSeen-like function) each time
m.notifyChannel(ctx, channelID, s, prompt) returns true, or alternatively treat
any success as partial acceptance and do not retry channels that returned true
on subsequent polls; modify the code paths around m.notifyChannel,
m.bot.allowedChannels iteration, and where the run is marked seen so delivery
state is maintained per channel (e.g., store a map keyed by channelID or persist
per-channel markers) to prevent duplicate notifications on retry.
- Around line 214-219: resetChat is called without holding cs.mu, then cs.mu is
locked to set cs.sessionID and cs.ownerUserID, which allows another goroutine to
interleave and cause a race; fix by performing the reset and session assignment
atomically: either modify resetChat (or add a new method like
resetAndSetSession) to accept sessionID and ownerUserID and perform both the
reset and the assignments while holding cs.mu, or acquire cs.mu before calling
resetChat and ensure resetChat does not re-lock internally; update calls to use
the new API so cs.sessionID and cs.ownerUserID are set under the same lock as
the reset to eliminate the race.

---

Outside diff comments:
In `@internal/cmn/config/loader.go`:
- Around line 1102-1147: The early return when def.Bots == nil prevents applying
Slack defaults and environment overrides; stop returning early and instead only
skip copying defaults from def.Bots while still executing the Slack env/default
logic: remove or replace the "if def.Bots == nil { return }" with per-section
nil checks (e.g., check def.Bots.Telegram, def.Bots.Slack individually) and
ensure cfg.Bots.Slack.RespondToAll = true plus the
l.v.GetString("bots.slack.bot_token") / "bots.slack.app_token" overrides and
subsequent conditional copies from def.Bots.Slack still run even when def.Bots
is nil.

In `@internal/service/telegram/monitor.go`:
- Around line 229-243: notifyChat is persisting a completed notification session
by setting cs.sessionID and cs.ownerUserID even though no subscription will
later clear it; update notifyChat (around m.bot.getOrCreateChat /
m.bot.resetChat / m.bot.sendLongText) to avoid persisting the notification
session: either do not assign cs.sessionID and cs.ownerUserID for
notification-only flows, or explicitly clear them (under cs.mu) immediately
after sending the long text so the chat has no active session; keep the mutex
usage (cs.mu.Lock/Unlock) when modifying cs.sessionID and cs.ownerUserID.

---

Nitpick comments:
In `@internal/cmn/config/config.go`:
- Around line 37-63: Add explicit validation in Config.Validate() to ensure
BotsConfig.Provider is one of the allowed constants (BotProviderNone,
BotProviderTelegram, BotProviderSlack); if not, return an error stating the
unsupported provider value. Locate the BotsConfig struct and BotProvider
constants (BotProviderNone, BotProviderTelegram, BotProviderSlack) and add a
guard in Config.Validate() that checks cfg.Bots.Provider and fails fast on any
value outside those three options (include the invalid value in the error
message for easier debugging).

In `@internal/service/slack/bot.go`:
- Around line 354-390: handleSlashCommand duplicates the "/dagu-new" and
"/dagu-cancel" logic found in handleTextCommand; refactor by extracting the
shared actions into helper methods (e.g., performNewSession and
performCancelSession) that accept a chatState (cs) and context/command metadata,
then have both handleSlashCommand and handleTextCommand call those helpers; use
existing symbols like getOrCreateChat, resetChat, sendReply, and
agentAPI.CancelSession to implement the helpers so cancel uses cs.sessionID and
cs.ownerUserID and new calls resetChat and sends the same reply messages.
- Around line 137-142: The goroutine calling b.socketClient.RunContext currently
only logs errors via b.logger.Error, which allows the main event loop to
continue on a closed socket; modify the goroutine to propagate fatal errors to
the main routine by sending the error on a dedicated error channel or invoking
the shared cancellation (e.g., cancel the context passed as ctx) so the main
loop can shutdown or attempt reconnection; specifically update the anonymous
goroutine that calls b.socketClient.RunContext(ctx) to forward returned errors
to a new or existing error handling path (instead of only calling
b.logger.Error) and update the main event loop to listen for that signal and
either perform reconnection logic or exit gracefully.

In `@internal/service/slack/monitor.go`:
- Around line 119-122: Change the log level for failures when listing DAG run
statuses from Debug to Warn so operational I/O failures are visible in
production; locate the logger call that reads m.logger.Debug("Failed to list DAG
run statuses", slog.String("error", err.Error())) (in monitor.go where
ListStatuses is handled) and replace it with m.logger.Warn (preserving the same
message and error field) so the warning shows up at the warn level without
altering the error handling flow.