feat(chart): expose maxBotTurns for Slack and Discord adapters

[dogzzdogzz]

Closes #609.

Summary

Wires the existing Rust max_bot_turns config field through the Helm chart so deployers can set the soft cap from chart values instead of being stuck on the hardcoded default of 20.

What changed

• charts/openab/templates/configmap.yaml — two short, gated blocks (Discord and Slack) that emit max_bot_turns = <int> into config.toml when agents.<name>.discord.maxBotTurns / …slack.maxBotTurns is set. When unset, no line is rendered → Rust's default_max_bot_turns() (20) applies, matching previous behaviour exactly.
• charts/openab/values.yaml — adds a commented maxBotTurns placeholder under both discord: and slack: default blocks, alongside the existing allowBotMessages / trustedBotIds knobs, with a doc-comment noting the 20 default and the compiled-in hard cap of 100.
• docs/messaging.md — adds a "Helm chart" example block under the existing config.toml example so deployers see the chart-side equivalent of the same keys.

What did not change

• No Rust code change. Same src/config.rs field, same src/bot_turns.rs semantics, same HARD_BOT_TURN_LIMIT = 100 (still compiled-in, intentionally not chart-tunable).
• No new tests. The existing bot_turns.rs tests cover soft-limit semantics; this PR only wires an existing value through a new surface.
• Default-rendered config.toml is byte-for-byte identical to the previous chart output when maxBotTurns is unset.

Verification

• helm lint charts/openab — clean.
• helm template … --set agents.claude.discord.maxBotTurns=50 → emits max_bot_turns = 50 in the rendered config.toml.
• helm template … without that flag → emits no max_bot_turns line (default 20 from Rust applies).

Test plan

• Reviewer confirms helm lint is clean
• Reviewer confirms helm template with and without maxBotTurns set produces the expected diff
• After merge + chart bump + image deploy, fleet-infra-side tenants set agents.claude.{discord,slack}.maxBotTurns: 50 and verify the rendered ConfigMap on the cluster contains max_bot_turns = 50

Discord Link

Discord Link: https://discord.com/channels/1491295327620169908/1491365157010542652/1498547660540608602

🤖 Generated with Claude Code

[dogzzdogzz]

Discussion: https://discord.com/channels/1491295327620169908/1491365157010542652/1498547660540608602

[thepagent]

request review from @masami-agent

[masami-agent]

PR Review: #610

Summary

• Problem: The Helm chart does not render the existing max_bot_turns config field, so deployers using Helm are stuck on the hardcoded default of 20 with no override path.
• Approach: Add gated template blocks in configmap.yaml for both Discord and Slack, plus values.yaml documentation and a Helm example in docs/messaging.md.
• Risk level: Low

Core Assessment

1. Problem clearly stated: ✅ — Well-documented in both issue #609 and PR description. Real use case (multi-agent collaboration exceeding 20 turns).
2. Approach appropriate: ✅ — Minimal chart-only change, no Rust code modified. Uses the same hasKey + gated rendering pattern as existing fields (allowBotMessages, trustedBotIds, etc.).
3. Alternatives considered: ✅ — PR explicitly scopes out making HARD_BOT_TURN_LIMIT chart-tunable (correct decision — that should remain compiled-in).
4. Best approach for now: ✅ — Zero-risk additive change. When maxBotTurns is omitted, no line is rendered and the Rust default of 20 applies. Byte-for-byte backward compatible.

Findings

charts/openab/templates/configmap.yaml

The two new blocks follow the established pattern correctly:

• Uses hasKey ($cfg.discord | default dict) "maxBotTurns" — consistent with how optional fields are gated elsewhere.
• Uses | int to ensure the value is rendered as an integer — correct for a TOML integer field.
• Placement is right: after allow_user_messages and before the section-closing {{- end }}, which keeps the TOML output logically grouped with the other bot-interaction knobs.
• Discord and Slack blocks are symmetric — good.

One observation: the existing fields like allowBotMessages and trustedBotIds use a slightly different guard pattern ({{- if $cfg.discord.allowBotMessages }} vs {{- if hasKey ... }}). The hasKey approach used here is actually more correct because it distinguishes between "key not set" and "key set to a falsy value" (e.g., maxBotTurns: 0 would still render with hasKey, but would be swallowed by a simple if). Since 0 is a valid value for max_bot_turns (even if unusual), hasKey is the right choice.

charts/openab/values.yaml

• The maxBotTurns placeholder is commented out (prefixed with #) — correct, this means the default behavior is preserved.
• Documentation comment is clear: mentions the default (20), the use case (multi-agent), and the hard cap (100).
• Placement is logical: right after trustedBotIds in both Discord and Slack blocks, grouping all bot-interaction knobs together.

docs/messaging.md

• Adds a "Helm chart" subsection showing the values.yaml equivalent of the existing config.toml example — helpful for deployers.
• Correctly notes the Rust default of 20 and the compiled-in hard cap of 100.

Minor nit: the last sentence is missing a period:

The hard cap of 100 is compiled-in
(HARD_BOT_TURN_LIMIT in src/bot_turns.rs) and is not chart-tunable.

Missing period at the end. (Not blocking.)

Review Summary

🔴 Blockers

(none)

💬 Questions

(none)

🔧 Suggested Changes

(none)

ℹ️ Info

• The hasKey guard pattern used here is more robust than the {{- if $cfg.discord.X }} pattern used by some existing fields. If the project ever standardizes on one pattern, hasKey is the better choice.
• The PR description mentions helm lint passes — good. The verification plan is thorough.

⚪ Nits

• docs/messaging.md: Missing period at the end of the last sentence in the new "Helm chart" section.

Verdict

APPROVE — Clean, minimal, well-scoped chart-only change. Backward compatible. No Rust code touched. Good documentation.

[obrutjack]

LGTM — clean chart-only change, backward compatible. Waiting on code owner review.