feat(operator): Discord auto-registration (--auto-register)

[chaodu-agent]

Summary

Adds --auto-register flag to oabctl apply that automatically provisions Discord bots via the Discord API.

Usage

# Set Discord developer token (or store in SSM at /oab/discord-developer-token)
export DISCORD_DEVELOPER_TOKEN=your_bearer_token

# Apply with auto-registration
oabctl apply -f agents/ --auto-register

# Output:
#   ✓ kiro-01  https://discord.com/oauth2/authorize?client_id=...
#   ✓ kiro-02  https://discord.com/oauth2/authorize?client_id=...

What it does

1. Loads Discord developer bearer token from DISCORD_DEVELOPER_TOKEN env var or SSM
2. For each agent without a pre-existing DISCORD_TOKEN secret:
   • Creates Discord application + bot (idempotent: skips if name already exists)
   • Resets bot token
   • Stores token in SSM at /oab/{ns}/{name}/discord-token
   • Adds secret reference to ECS task definition
3. Returns OAuth invite URLs — user pastes into browser to add bot to server

Files

• operator/src/discord.rs — Discord API client (provision_bot, find_existing)
• operator/src/apply.rs — integration with apply flow
• operator/src/main.rs — --auto-register CLI flag

Notes

• Without --auto-register, behavior is unchanged (Phase 1 mode: pre-created tokens)
• Idempotency: uses bot name matching to avoid duplicate applications
• Discord API rate limits may apply when provisioning many bots at once

cc @pahud

[github-actions]

⚠️ This PR is missing a Discord Discussion URL in the body.

All PRs must reference a prior Discord discussion to ensure community alignment before implementation.

Please edit the PR description to include a link like:

Discord Discussion URL: https://discord.com/channels/...

This PR will be automatically closed in 3 days if the link is not added.

[shaun-agent]

OpenAB PR Screening

This is auto-generated by the OpenAB project-screening flow for context collection and reviewer handoff.
Click 👍 if you find this useful. Human review will be done within 24 hours. We appreciate your support and contribution 🙏

• Title: feat(operator): Discord auto-registration (--auto-register)
• Source: feat(operator): Discord auto-registration (--auto-register) #853
• Status: moved to PR-Screening
• Generated at: 2026-05-19T04:07:00.259Z
• Discord thread: not available

Screening report

screening pass complete.

GitHub comment: #853 (comment)
Project action: moved PVTI_lADOEFbZWM4BUUALzgtIxWY from Incoming to PR-Screening in https://github.com/orgs/openabdev/projects/1

Intent

This PR tries to remove the manual Discord bot provisioning step from oabctl apply. The operator-visible problem is that deployers currently need to pre-create Discord applications, manage bot tokens, place those tokens into AWS SSM, and wire task definitions by hand before an agent can come online.

Feat

Feature work. It adds an opt-in --auto-register path to oabctl apply that uses a Discord developer bearer token to create or reuse Discord applications, reset bot tokens, store those tokens in SSM, update ECS task secret references, and print OAuth invite URLs.

Who It Serves

Deployers and agent runtime operators.

Rewritten Prompt

Implement an opt-in oabctl apply --auto-register flow for Discord-backed agents. Preserve existing behavior when omitted. Add focused tests or dry-run coverage for skip behavior, SSM path construction, idempotent lookup, missing credential errors, and Discord/API failure handling.

Merge Pitch

Worth advancing because it shortens a fragile deployer workflow. Risk is medium: deployment automation, secrets, Discord API calls, and ECS task mutation. Main reviewer concern: name-based idempotency, token reset safety, and rate-limit/error handling.

Best-Practice Comparison

OpenClaw and Hermes Agent are only partially relevant because this is provisioning during apply, not scheduling. The useful comparison is operational durability: clear per-agent logs, explicit identity, retry/backoff, and avoiding half-mutated Discord/SSM/ECS state.

Implementation Options

1. Conservative: experimental opt-in, create only missing bots/tokens.
2. Balanced: deterministic naming, SSM storage, invite output, guarded reset semantics, dry-run/tests.
3. Ambitious: full reconciler with persisted app IDs, rollback/resume, audit logs, and repair/rotation commands.

Comparison Table

Option	Speed	Complexity	Reliability	Maintainability	User impact	Fit for OpenAB now
Conservative	Fast	Low	Medium	High	Useful but limited	Good
Balanced	Moderate	Medium	High if guarded	Good	Strong	Best fit
Ambitious	Slow	High	Highest long-term	Medium	Excellent	Too much

Recommendation

Advance the balanced path. Review should focus on avoiding mutable-name-only identity, making token reset intentional, and producing clear per-agent results on Discord/API failures.