`dotnet event` CLI Extension

[tsutomi]

A dotnet global tool that adds a first-class event command group to the .NET CLI — covering event scaffolding, schema export, schema validation, and breaking-change detection — so all event tooling is reachable from the same terminal session as the rest of the .NET toolchain.

The problem today: Tasks like scaffolding a new annotated event class, exporting schemas to AsyncAPI or OpenAPI, or checking whether a schema change is backwards-compatible have no standard CLI surface inside the dotnet ecosystem. Developers must hand-write boilerplate, invoke the application host to export schemas, and rely on ad-hoc scripts for validation — all outside the familiar dotnet workflow.

What we will build: A Deveel.Events.Tools NuGet package distributable as a dotnet global or local tool (dotnet tool install -g Deveel.Events.Tools), adding the top-level command group dotnet event with the following sub-commands:

• dotnet event new <EventName> [--namespace <ns>] [--version <ver>] [--output <path>] — scaffolds a new partial C# class pre-annotated with [Event], [EventProperty] stubs derived from optional property definitions passed on the command line or from an interactive prompt; emits the file ready for the code generators to act on.
• dotnet event list [--assembly <path>] [--project <path>] — discovers all [Event]-annotated types in a compiled assembly or by building the target project, and prints a structured table of event type names, versions, property counts, and content types.
• dotnet event schema export [--assembly <path>] [--format asyncapi|openapi|json-schema] [--output <file>] — loads the GeneratedEventSchemas metadata emitted by the schema generator from the target assembly and serialises it to the requested schema format without starting the application host.
• dotnet event schema validate <payload-file> --event-type <type> [--assembly <path>] — deserialises a JSON file and validates it against the schema of the named event type, reporting constraint violations in a structured, CI-friendly format (exit code 1 on failure).
• dotnet event schema diff <before-assembly> <after-assembly> [--fail-on-breaking] — compares the event schemas exported from two compiled assemblies, classifying each change as backward-compatible or breaking, and optionally returning a non-zero exit code when breaking changes are detected (suitable for a CI quality gate).
• dotnet event channel add <transport> [--name <name>] — scaffolds the DI registration boilerplate for a named channel of the given transport type (e.g., dotnet event channel add rabbitmq --name OrderEvents) into the project's Program.cs or a nominated partial class.

Benefits:

• All event-related tasks are reachable via the single dotnet event entry point, consistent with the rest of the .NET CLI toolchain and discoverable via dotnet event --help.
• schema export and schema diff can run as zero-dependency CI steps against a pre-built assembly, with no running application host required — a direct consequence of the compile-time metadata emitted.
• dotnet event schema diff --fail-on-breaking provides an automated breaking-change gate that complements the compatibility checker planned in item 10, requiring no custom scripting.
• dotnet event new bootstraps correctly-annotated event classes in seconds, reducing friction for teams onboarding to the framework.
• Local and global tool modes allow teams to pin the tool version alongside the project (via dotnet-tools.json) for reproducible CI builds.