Skip to content

Remove remaining Discord registry duplication and strengthen runtime assertions #76

@jcodog

Description

@jcodog

Follow up the completed #72 registry unification with the remaining runtime hardening found during review.

Current state

#72 correctly made one explicit command registry drive both runtime loading and slash-command deployment, and unsupported event names now fail before being logged as loaded. The accepted implementation still leaves a small amount of duplicated runtime knowledge and incomplete behavioural testing.

Scope

  • Remove the manual event-name allowlist from BotClient.registerLoadedEvent by registering the typed loaded event generically, or centralise the supported-event type so the event registry remains the only source of truth
  • Preserve each event's declared on or once mode
  • Add runtime command-name uniqueness validation before populating the client command collection, so duplicate names cannot silently overwrite each other even before command deployment is run
  • Strengthen tests so a synthetic once event is emitted twice and executes exactly once
  • Add a runtime duplicate-command test proving startup fails loudly rather than silently replacing a command
  • Keep the explicit command and event registries and avoid filesystem discovery

Completion criteria

  • Adding a valid typed event requires editing only the event registry and handler, not a second allowlist in Client.ts
  • Unsupported or malformed event definitions still fail clearly
  • Runtime startup rejects duplicate command names
  • Tests verify real once listener behaviour, not only the once property
  • Discord bot tests, typecheck, and lint pass
  • No welcome, moderation, audit logging, config caching, shutdown, or incident-reporting behaviour is implemented

Metadata

Metadata

Assignees

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions