feat: re-enable community creation via COMMUNITY_CREATION_ENABLED env…

[Matobi98]

Summary

• Introduces a COMMUNITY_CREATION_ENABLED environment variable (default: false) that controls whether the
  /community command is registered at bot startup
• Replaces the commented-out /community command block in bot/modules/community/index.ts with a conditional
  registration guarded by the env var
• Adds COMMUNITY_CREATION_ENABLED=false to .env-sample with an explanatory comment

Behavior

• COMMUNITY_CREATION_ENABLED=false (default) — /community is not registered; community creation is disabled
• COMMUNITY_CREATION_ENABLED=true — /community is registered and users can create communities through the existing
  wizard flow

The wizard scene itself (COMMUNITY_WIZARD_SCENE_ID) is unchanged — it was already fully implemented.

Test plan

• With COMMUNITY_CREATION_ENABLED unset or false, confirm /community returns no response / unknown command
• With COMMUNITY_CREATION_ENABLED=true, confirm /community enters the community creation wizard correctly
  EOF

Summary by CodeRabbit

• Chores
  • Community creation is now opt-in and can be enabled per instance through environment configuration.

[coderabbitai]

Walkthrough

This PR adds an opt-in feature flag for community creation. A new COMMUNITY_CREATION_ENABLED environment variable is declared in .env-sample (defaulting to false), and the community module now conditionally registers a /community bot command only when this flag is explicitly enabled, entering the community wizard scene with the current user context.

Changes

Community Creation Feature Flag

Layer / File(s)	Summary
Community creation environment configuration .env-sample	New COMMUNITY_CREATION_ENABLED environment variable added with default value false and documentation indicating the feature is opt-in per instance.
Conditional community command registration bot/modules/community/index.ts	Community module now registers /community command only when COMMUNITY_CREATION_ENABLED is 'true', replacing prior commented-out code; command enters wizard scene with bot and user context.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Possibly related issues

• Community creation via environment variable #808: This PR directly implements the same feature-flag gating for community creation that was previously tracked — adding COMMUNITY_CREATION_ENABLED configuration and conditionally registering the /community command.

Poem

🐰 A flag springs to life, modest and bright,
Communities now gated, opt-in by right,
The wizard awaits where the toggle glows true,
One small, steady change—a choice made anew! 🌱

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and specifically describes the main change: introducing an environment variable to control community creation functionality.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Luquitasjeffrey]

tACK

[ermeme]

Code Review Summary

Verdict: Comment

No blocking issues. I found one small deployment-risk suggestion:

• COMMUNITY_CREATION_ENABLED is checked with a string-exact comparison against 'true'. If an operator sets 1, TRUE, or another common truthy value, the command will stay disabled silently. Consider normalizing the flag or documenting the accepted value explicitly.

I did not find an automated test covering the registration gate, so adding one would make this safer to change later.

[ermeme]

This gate is string-exact. If an operator sets COMMUNITY_CREATION_ENABLED=1 or TRUE, /community remains disabled silently. Consider normalizing the flag or documenting the accepted value explicitly.

[ermeme]

LGTM. The env-flag approach is consistent with the repo’s existing exact-string environment parsing, and I don’t see any blocking issue within the scope of this PR.

[mostronatorcoder]

Looks good to me. I reviewed the current head commit 85bad0a.

The change is small and scoped correctly: the /community command is only registered when COMMUNITY_CREATION_ENABLED === "true", and the existing COMMUNITY_WIZARD_SCENE_ID is already present in bot/modules/community/scenes.ts, so this does not introduce a dangling scene reference. The accompanying .env-sample update also documents the flag clearly for operators.

Checks run:

• npm test -- --runInBand could not run in this environment because tsc is not installed here (sh: 1: tsc: not found)
• npm run lint could not run in this environment because eslint is not installed here (sh: 1: eslint: not found)