Status: Accepted
PersonaBot IDs are Host-owned; names and role badges are Human-facing
A PersonaBot has a stable, opaque, filesystem-safe PersonaBot ID generated by the Host. Creation surfaces never ask a Human to choose it. The current slug field and directory segment are the v1 serialization of that internal ID, not a username or mention handle. A PersonaBot’s display name is the primary label shown in lists and @ pickers; duplicate names are allowed because the selected mention token retains the PersonaBot ID. Zero or more role badges describe jobs or positions beside the name, but do not participate in identity, routing, or authorization.
Considered Options
- Human-authored slug as the unique handle — rejected: it exposes a storage constraint, excludes ordinary Chinese names, and makes renaming or identity selection feel like account administration.
- Require unique display names — rejected: IM products allow repeated visible names; avatar and role badges disambiguate while the token carries stable identity.
- Keep one
tagstring — rejected: one PersonaBot may visibly hold several positions, and collapsing them into one string loses structure.
Consequences
- The minimal form asks for a display name, optional role badges, and an optional short description (bio); it writes a placeholder
PERSONA.md, which can be refined later. - The create bridge generates the PersonaBot ID and returns it; clients use it internally for selection, persistence, avatar seed, and future mention tokens but do not expose it as an input.
- Read models expose
roles: string[]. Legacytagdata is projected as one role badge until a later write replaces it. - Mention search and roster search use display names and role badges, never the internal ID; duplicate-name pickers must show enough context to disambiguate.