bug(helm): agents.*.discord not rendered on upgrade from 0.7.6 — discord.enabled backward-compat missing for per-agent configs

[JARVIS-coding-Agent]

Description

Upgrading from 0.7.6 → 0.7.7 causes per-agent (non-default) deployments to crash with no adapter configured even though discord.botToken and discord.allowedChannels are present in their values. Only the top-level default agent (kiro) renders the [discord] config section; additional agents defined under agents.* do not.

This contradicts #394 ("Backward-compatible default so existing installs keep working").

Affected version: Chart openab-0.7.7, upgrading from openab-0.7.6

Root cause: templates/configmap.yaml uses a strict boolean check:

{{- if ($cfg.discord).enabled }}

In 0.7.6 there was no discord.enabled field. Existing values files carry discord.botToken, discord.allowedChannels, and discord.allowBotMessages — but not discord.enabled.

The default values.yaml in 0.7.7 only sets discord.enabled: true for the built-in kiro agent. Any user-defined agent under agents.* does not inherit this default, so ($cfg.discord).enabled evaluates to nil and the [discord] TOML section is never rendered.

Steps to Reproduce

1. Have a running 0.7.6 deployment with multiple agents:

agents:
  claude:
    command: claude-agent-acp
    discord:
      allowBotMessages: mentions
      allowedChannels:
        - "1234567890123456789"
      botToken: <token>
    image: ghcr.io/openabdev/openab-claude:0.7.6
  copilot:
    command: copilot
    discord:
      allowBotMessages: mentions
      allowedChannels:
        - "1234567890123456789"
      botToken: <token>
    image: ghcr.io/openabdev/openab-copilot:0.7.6
  kiro:
    discord:
      allowBotMessages: mentions
      allowedChannels:
        - "1234567890123456789"
      botToken: <token>
image:
  tag: 0.7.6

2. Back up values and upgrade:

helm get values openab > values.yaml
sed -i "s/0.7.6/0.7.7/g" values.yaml
helm upgrade openab openab/openab --version 0.7.7 -f values.yaml

3. Observe that claude and copilot pods enter CrashLoopBackOff:

Error: no adapter configured — add [discord] and/or [slack] to config.toml

4. Verify with helm template:

helm template openab openab/openab --version 0.7.7 \
  --show-only templates/configmap.yaml -f values.yaml

The rendered configmaps for claude and copilot contain no [discord] section, while kiro does.

Expected Behavior

Per-agent discord configs with botToken present should automatically render the [discord] TOML section, matching the backward-compatible behavior described in #394. Existing 0.7.6 values should work without modification on upgrade to 0.7.7.

Environment

• Helm chart: openab-0.7.7
• Upgraded from: openab-0.7.6
• Kubernetes: k3s
• Helm: v3

Workaround

Manually add discord.enabled: true to every per-agent discord config before upgrading:

agents:
  claude:
    discord:
      enabled: true  # ← required for 0.7.7
      ...

Proposed fix

In templates/configmap.yaml, replace the strict check with a backward-compatible fallback that also considers the presence of botToken:

- {{- if ($cfg.discord).enabled }}
+ {{- if and (ne (($cfg.discord).enabled | toString) "false") (or ($cfg.discord).enabled ($cfg.discord).botToken) }}

discord.enabled	discord.botToken	Result
true	(any)	✅ Rendered — explicit opt-in
(absent)	present	✅ Rendered — backward-compat with 0.7.6 values
false	(any)	❌ Skipped — explicit opt-out
(absent)	(absent)	❌ Skipped — no discord config at all

One-line change, no impact on other templates, aligns per-agent behavior with what #394 intended.

[thepagent]

Design Decision: Explicit over Inference

We closed #417 because we prefer explicit defaults over inference logic. Here's the direction:

Decision

• All adapters default to disabled (enabled: false or absent)
• Users must explicitly set discord.enabled: true or slack.enabled: true to activate an adapter
• No implicit "if botToken is present, assume enabled" logic in templates

0.7.6 → 0.7.7 Migration

This is a known breaking change for 0.7.6 users. The mitigation is documentation, not template magic:

• Release notes must clearly state: add discord.enabled: true to your values before upgrading
• The upgrade guide (ai-install-upgrade.md) should include this as a migration step
• Pod should log a clear error when no adapter is enabled (e.g. no adapter enabled — set discord.enabled: true or slack.enabled: true)

Rationale

• Explicit > implicit — one code path, no guessing
• A one-liner values change is an acceptable migration cost
• Keeps the chart permanently cleaner and more maintainable
• Loud failure with a clear message is better than silent inference

[thepagent]

Next Step

We need a PR to ensure all adapters default to disabled in the chart's values.yaml until explicitly set to enabled: true. This makes the breaking change intentional and well-defined rather than accidental.

The PR should:

• Confirm discord.enabled and slack.enabled default to false (or are absent) in values.yaml
• Add a clear startup error message when no adapter is enabled
• Update release notes and upgrade guide to document the migration step