Add first-class operator or human principals for Discord ingress

[mostlydev]

Summary

Clawdapus currently abstracts Discord bot identity through handles, but not human/operator ingress. If a pod wants humans to be able to mention traders in a Discord guild, authors still have to wire raw user IDs into channel://discord surfaces.

That is too low-level for the common “operators can talk to agents” case.

What Happened

In a live trading-desk pod:

• bot-to-bot mentions worked
• human mentions from the operator did not create a session
• the generated OpenClaw config only included the peer bot IDs in channels.discord.guilds.<guild>.users

To make the operator able to mention traders, we had to explicitly add the human Discord user ID plus every bot ID to the guild allowlist.

Why This Feels Wrong

Today the abstraction boundary is:

• handles: bot IDs, usernames, guild membership, mention patterns, peer bot allowlist
• channel surfaces: human routing ACLs via raw guild/channel/user IDs

That means a pod author has to know and repeat:

• the operator’s raw Discord user ID
  n- every peer bot ID
• the guild ID
• the channel ID

for what is conceptually just “let the desk operator talk to the traders in trading-floor”.

Expected

Clawdapus should have a higher-level way to express this. Examples:

• a first-class operators / humans / principals block at pod level
• a way to merge those principals into generated Discord guild users automatically
• a simpler channel-surface knob like allow_operators: true
• named principals instead of raw user IDs everywhere

Benefit

This would eliminate a lot of brittle Discord-specific config and make the common operator-to-agent path feel like an actual pod abstraction instead of raw OpenClaw plumbing.

[mostlydev]

This is a valid usability problem, but I’m not implementing it in the current fix pass because it changes the pod model rather than correcting a contained runtime bug. ADR-003 deliberately splits social identity () from infrastructure/routing surfaces, and a first-class operator/principal abstraction needs a design pass against that boundary instead of being bolted onto Discord-specific config.\n\nI’m treating #49 and #52 as immediate correctness fixes. #50 should be handled as a follow-up design issue once we decide whether operator principals belong in , a new pod-level identity block, or a separate routing abstraction.

[mostlydev]

This is a valid usability problem, but I’m not implementing it in the current fix pass because it changes the pod model rather than correcting a contained runtime bug. ADR-003 deliberately splits social identity (HANDLE) from infrastructure and routing surfaces, and a first-class operator or principal abstraction needs a design pass against that boundary instead of being bolted onto Discord-specific config.

I’m treating #49 and #52 as immediate correctness fixes. #50 should be handled as a follow-up design issue once we decide whether operator principals belong in handles, a new pod-level identity block, or a separate routing abstraction.