feat(ai-bot): make bot account email configurable via AI_BOT_EMAIL env var

[dnplkndll]

Summary

Makes the AI bot account email configurable via AI_BOT_EMAIL env var instead of hardcoded to huly.ai.bot@hc.engineering.

Resolves hcengineering/huly-selfhost#239

Motivation

The bot email huly.ai.bot@hc.engineering is an @hc.engineering address embedded in every self-hosted deployment's account system. Self-hosters have no control over this domain, and it can cause bounce-back noise if an external SMTP notification service attempts to email all workspace members.

Design

• setAiBotAccountEmail() / getAiBotAccountEmail() on @hcengineering/ai-bot — mutable at startup, defaults to original email
• getAiBotEmailSocialKey() — derives social key from configured email at call time
• Original aiBotAccountEmail and aiBotEmailSocialKey constants kept for client-side code
• Client plugin unchanged — queries by default constant (bot retains original social identity)

Env vars

Service	Var	Default	Required
ai-bot	AI_BOT_EMAIL	huly.ai.bot@hc.engineering	No
transactor	AI_BOT_EMAIL	huly.ai.bot@hc.engineering	No

Both must use the same value if set.

Changes (12 files)

File	Change
plugins/ai-bot/src/index.ts	Add get/setAiBotAccountEmail(), getAiBotEmailSocialKey()
services/ai-bot/pod-ai-bot/src/config.ts	Add Email from AI_BOT_EMAIL (imports default from plugin)
services/ai-bot/pod-ai-bot/src/start.ts	Call setAiBotAccountEmail(config.Email) on startup
services/ai-bot/pod-ai-bot/src/utils/account.ts	Use getter functions
services/ai-bot/pod-ai-bot/src/utils/platform.ts	Use getter functions
pods/server/src/__start.ts	Read AI_BOT_EMAIL, call setAiBotAccountEmail()
foundations/server/packages/middleware/src/identity.ts	Import from @hcengineering/ai-bot (was duplicate hardcoded string)
foundations/server/packages/middleware/src/pluginConfig.ts	Use getter function
server-plugins/ai-bot-resources/src/index.ts	Use getter function
**/package.json + pnpm-lock.yaml	Add @hcengineering/ai-bot dependency

Not changed: plugins/ai-bot-resources/src/utils.ts (client-side, correctly uses constant), models/contact/src/migration.ts and dev/tool/src/db.ts (hardcoded strings reference historical data).

Testing

Deployed to self-hosted K8s cluster with AI_BOT_EMAIL=aibot@ledoweb.com:

• ai-bot: 0 restarts, registers new social identity in CockroachDB
• Original identity preserved (backwards compat)
• DM with Huly AI works — bot receives and responds
• Default behavior (no env var) unchanged

🤖 Generated with Claude Code

[huly-github-staging]

Connected to Huly®: UBERF-16033

[dnplkndll]

Alternative approach: Since no actual email is ever sent to or from this address (it's purely an account identity key), a simpler fix would be to just change the hardcoded default from huly.ai.bot@hc.engineering to something domain-neutral like ai-bot@huly — no env var needed.

The reason I went with the configurable approach is backwards compatibility: existing deployments already have the bot registered with huly.ai.bot@hc.engineering in their social_id table. Changing the constant would require a migration to update the social identity, otherwise the bot would create a duplicate account on next startup.

If a migration is acceptable, the simpler rename would be a ~5-line change. Happy to pivot to that approach if preferred.

[aonnikov]

It is idiomaic to use metadata for such kind of configuration, i.e. something like:

setMetadata(serverAiBot.metadata.Email, process.env.AI_BOT_EMAIL)

and in the ai-bot plugin:

export function getAiBotEmailSocialKey (): string {
  return buildSocialIdString({
    type: SocialIdType.EMAIL,
    value:getMetadata(...) ?? aiBotAccountEmail
  })
}

[aonnikov]

Honestly, I don't think it has to be a email, ideally that should be a separate SocialIdType, but this is something that requires larger refactoring.