SpaceCatalog

Subscriby\Connector\Contracts\Ports\SpaceCatalog. Optional; no capability binds it. A connector with access_control almost always binds it, because it is how a creator links a place.

Linking is asked through the connector because only the platform can prove the installation administers a place: Telegram answers a chat picker, Discord a guild pick. The connector parks the request under the creator's account with its own handle, the platform answers, and the chosen place is filed under the request's purpose.

Methods

Link requests

A LinkRequest carries the kind of place wanted (one of your resource kinds), the purpose and the subject:

One request per purpose is open at a time for a creator; asking again replaces it. The IdentityRef is the creator's account on your connector, the one to ask in; the core refuses the request itself when the creator has no reachable account there.

linkInstructions() is the one or two plain sentences the dashboard shows while the request is open, translated: "Our bot sent you a button to pick the chat. Tap it from your Telegram account…". Only the connector knows whether the creator taps a keyboard, picks a guild or approves a prompt.

Completing a request

When the platform answers with the chosen place, your inbound handler files it under the purpose it parked. Record the place first with Core\Spaces::record(new SpaceRecord(...)), then:

• a Resource request: Core\Resources::create($project, $space, ResourceKind::for($key, $kind), $title) writes the resource, binds it to the space and announces it; idempotent, so a replayed answer creates nothing twice;
• a Standby request: Core\Recovery::registerStandby($resource, $space) files the place as the resource's reserve;
• a Replacement request: Core\Recovery::replaceSpace($resource, $space) points the resource at the new place and re-admits everyone with access.

Each write is the action the dashboard runs, so the owner guard, the tier gate and the allowance are the same whichever road the creator took, and each refusal reaches you as ResourceRefused or RecoveryRefused with the sentence to relay. Core\Spaces::bindResource() stays for a place that should gate an existing resource outside the ledger, which is what a migration uses.

Linking the group a support relay posts into for a SupportRelay request is not on the SDK yet: it lands with Core\Support, scheduled with the second first-party connector, and until then a third-party connector that declares support_relay says so on its listing and watches the SDK changelog.

diagnose()

Whether the installation can grant and revoke in a place, and if not why: SpaceAccess with ready, a state word your connector defines (ready, not_admin, missing_right, gone), a detail sentence for the creator and creatorActionable. The doctor renders it with your resource_health_detail slot when you fill one.

How Telegram does it

Telegram cannot list the chats a bot administers, so a place is linked by asking the creator to pick it: the bot sends a reply keyboard whose one button opens Telegram's chat picker filtered to the kind wanted, Telegram makes the bot an administrator of the chosen chat with the two rights it needs, and answers with a chat_shared update carrying the request id parked under the creator's chat. diagnose() is getChatMember on the bot's own id, the one call that tells a deleted chat from a removed bot from a missing right.

What the kit checks

Nothing beyond the port's shape: a bound SpaceCatalog is exercised by the doctor and the dashboard, not by the kit. Test diagnose() against your platform's fake for each state you return.