reborn-extension-surfaces

Add a single [channel] section to the extension manifest with id, display_name, inbound/outbound flags, and a required conversation_model, plus ingress, verification, connection, egress, and presentation subsections. Implement behavior in a ChannelAdapter and supply it through the RebornHostBindings composition seam.

Declare each capability as a [[tools]] entry with id, description, effects, default_permission, input_schema_ref, and a [[tools.credentials]] block naming vendor, audience, and injection. Messaging-shaped tools bind a standard_op instead of declaring their own schemas.

Yes, extensions share a vendor id when the credential authority is the same, such as google across gmail, drive, and calendar. Recipes for one vendor must be identical except scopes and display_name, and scopes union across active extensions.

The extension is the top-level product object with one manifest and one installed identity. A channel is just one capability surface declared in that manifest, alongside tools and auth — it is not a sibling product type.

The reborn_retired_taxonomy.rs gate pins deleted vocabulary like connectable channels, slack_bot, and extension kind strings at zero. Tripping it means your change reintroduces a removed model; express the concept through manifest surfaces instead.

A hosted-MCP extension declares one [mcp] section with server, namespace, max_tools, effects, and credentials instead of [runtime] and usually instead of [[tools]]. It may also pin static [[tools]] entries that a successful tools/list discovery later replaces.