ManagementSurface

The creator's in-chat admin surface over the core's command catalogue — declaring the commands, handling events, rendering command buttons, and calling the same actions the dashboard calls.

Subscriby\Connector\Contracts\Ports\ManagementSurface. Bound by management_surface.

The core publishes an admin command catalogue (ManagementCommand) and the actions behind it; a connector declares the subset it renders and drives those actions from the platform's own idiom: wizards over chat storage on Telegram, slash commands and modals on Discord. The management_commands block is the declaration; this port is the implementation.

Methods

Method	Called when	Returns
`commands()`	The kit compares it with the manifest.	`list<ManagementCommand>`
`handle(InboundEnvelope)`	Your inbound route hands it an event that belongs to the admin surface. The core does not dispatch envelopes itself yet.	`void`

`commands()`

Return exactly the ManagementCommand cases the manifest declares, in any order. The marketplace and the dashboard read the coverage from the manifest; the kit's management.commands_match_manifest makes sure the class agrees.

`handle()`

The envelope's payload is the platform's event as your InboundGateway::decode() built it, its installation the installation that received it (the platform installation for a shared admin bot), its kind your own vocabulary. Resolve the actor (IdentityResolver::resolveInbound()), find the creator (Core\Identities::findCreator()), and drive your screens.

Two rules keep the surface honest:

Every command runs the core's action. A plan created from the chat is created by the same action the dashboard's plan editor calls, with the same validation and the same team authorisation, so a teammate refused on the web is refused in the chat. Today the first-party connector reaches those actions through the application while the Core API grows the contracts a third party will call; a connector built now declares the commands whose actions the Core API already exposes (Core\Installations, Core\Identities, Core\Spaces, Core\Grants, Core\Creators, Core\Alerts) and adds the rest as the contracts land.
State lives in your own storage. A wizard's progress is the connector's (a chat-storage key, a pending row in your own table), never a core column.

Command buttons

The core's messages carry MessageAction::command($label, $command, $params) buttons, a catalogue command with its parameters in the core's words. Your Messenger renders each into the callback your surface answers to, and your handle() recognises it coming back. That is how a sale notice can offer "Manage plan" without the core knowing what a Telegram callback looks like.

The member side

Members have a smaller catalogue of their own, Subscriby\Connector\Enums\MemberCommand: Start (the member's home: memberships, plans, status) and ReissueGrants (fresh access for everything their subscriptions entitle them to). A connector renders them in the same surface or a separate customer conversation; they are not part of management_commands.

How Telegram does it

The platform bot renders the catalogue as the conversations, sections and callback actions its handler has always dispatched; the port names which of the catalogue's commands those cover, so the manifest, the Connectors tab and the docs matrix say the same thing, and it lets the core hand an inbound update to the handler without knowing how the client library builds one: the envelope's payload is the update.

What the kit checks

management.commands_match_manifest: the sorted list commands() returns equals the manifest's management_commands.

Declare what you render

A command in the manifest with no path through handle() passes the kit and fails review, and a creator who reads "manage plans from the platform" on the marketplace will look for it. Start with the reads, add the writes as you build them, bump the manifest each time.