Summary
Buzz Desktop recreates the built-in Welcome Team agents (Fizz, Honey, and Pollen) after a user explicitly removes them from My Agents. There is no persistent opt-out state, so the Welcome Team reconciliation path reactivates the built-in personas and recreates their managed-agent instances.
Environment
- Buzz Desktop:
desktop-v0.5.20
- Self-hosted relay:
v0.5.2
- Platform: macOS
- Relay membership required: enabled
Steps to reproduce
- Complete Desktop onboarding against a self-hosted relay.
- Remove Fizz, Honey, and Pollen from My Agents, or delete their managed-agent instances.
- Restart Buzz Desktop or re-enter the Welcome channel/onboarding flow.
- Observe the Welcome Team reconciliation run again.
Actual behavior
- The built-in personas are forced active again.
- Missing managed-agent instances are recreated.
- Welcome channel bot membership is restored.
- The relay receives new revisions for the same kind
30177 managed-agent coordinates.
Expected behavior
An explicit user removal should persist across restarts and Welcome channel reconciliation. Removed Welcome Team agents should not be recreated unless the user explicitly chooses to restore them.
Source-level diagnosis
desktop/src/features/onboarding/welcomeGuide.ts calls ensureWelcomeTeam() / provisionWelcomeTeam(), which:
- calls
ensureWelcomeTeamPersonasActive(),
- looks up the three starter personas and relay-scoped instances,
- creates missing managed-agent instances,
- updates runtime/access settings, and
- restores Welcome channel membership.
The in-process promise map prevents concurrent duplicate provisioning, but it is not a persistent user opt-out.
The supported managed-agent deletion path correctly emits an owner-signed NIP-09 coordinate tombstone for 30177:<owner>:<d-tag> and an identity archive request. The problem is that Welcome reconciliation can subsequently provision the instances again.
Suggested fix
- Persist a
welcome_team_opt_out=true state when the user removes the built-in Welcome Team.
- Check the opt-out before
ensureWelcomeTeam() performs persona activation, agent provisioning, membership reconciliation, or Welcome intro work.
- Add an explicit Restore Welcome Team action that clears the opt-out.
- Add a regression test covering: remove agents → restart Desktop → enter Welcome channel → no new kind
30177 create/update events.
Additional note
This is a Desktop lifecycle issue rather than a relay database cleanup issue. Direct deletion of relay event rows is neither necessary nor desirable; the existing signed tombstone/archive flow should remain the removal mechanism.
Summary
Buzz Desktop recreates the built-in Welcome Team agents (Fizz, Honey, and Pollen) after a user explicitly removes them from My Agents. There is no persistent opt-out state, so the Welcome Team reconciliation path reactivates the built-in personas and recreates their managed-agent instances.
Environment
desktop-v0.5.20v0.5.2Steps to reproduce
Actual behavior
30177managed-agent coordinates.Expected behavior
An explicit user removal should persist across restarts and Welcome channel reconciliation. Removed Welcome Team agents should not be recreated unless the user explicitly chooses to restore them.
Source-level diagnosis
desktop/src/features/onboarding/welcomeGuide.tscallsensureWelcomeTeam()/provisionWelcomeTeam(), which:ensureWelcomeTeamPersonasActive(),The in-process promise map prevents concurrent duplicate provisioning, but it is not a persistent user opt-out.
The supported managed-agent deletion path correctly emits an owner-signed NIP-09 coordinate tombstone for
30177:<owner>:<d-tag>and an identity archive request. The problem is that Welcome reconciliation can subsequently provision the instances again.Suggested fix
welcome_team_opt_out=truestate when the user removes the built-in Welcome Team.ensureWelcomeTeam()performs persona activation, agent provisioning, membership reconciliation, or Welcome intro work.30177create/update events.Additional note
This is a Desktop lifecycle issue rather than a relay database cleanup issue. Direct deletion of relay event rows is neither necessary nor desirable; the existing signed tombstone/archive flow should remain the removal mechanism.