Skip to main content

​
Channels

Use this page when the base CLI path already works and you need to choose the right delivery surface story before diving into commands or config fields. The base CLI path still comes first. A user should be able to succeed with ask or chat before enabling service channels. If you want the exact per-surface setup contract instead of the conceptual surface map, go directly to Channel Guides. Keep Channel Recipes for representative rollout paths, smoke tests, and multi-channel sequencing. If you already know the provider and channel together, skip the narrower recipe pass and go to Common Setups plus the dedicated playbook that matches the rollout shape. If you specifically need the owner model behind gateway run, continue to Gateway And Supervision.

​
Canonical Channel CLI Story

Public docs now prioritize grouped shells over flat verbs:
  • generic channel actions: loong channels send <surface> ...
  • generic channel serve loops: loong channels serve <surface> ...
  • richer family namespaces stay first-class when they expose more than thin wrappers, but those richer payload workflows should stay on the dedicated family namespace instead of widening the canonical grouped contract

​
Already Know The Rollout Shape?

If the provider and channel are already obvious, skip this concept page and go straight to the matching playbook.

​
Fast Path By Situation

​
Reading Rule

  • Use this page to choose the delivery-surface lane.
  • Use Channel Guides when one surface is already decided and you need the exact built-in contract.
  • Use Channel Recipes when you need commands, smoke tests, or concrete config.
  • Use Common Setups when provider and channel choice belong together.
  • Use Gateway And Supervision when the real question is ownership, selectors, or long-lived supervision.

​
Choose The Right Surface Story

​
Gateway And Runtime Ownership

  • gateway run, gateway status, and gateway stop are the current explicit owner contract for longer-lived delivery surfaces.
  • LINE and Webhook have native serve commands, but they are still standalone native-serve lanes rather than gateway-supervised ones.
  • Loong does not flatten gateway ownership, standalone native serves, plugin-backed bridge surfaces, and outbound-only sends into one vague “channel support” story.
  • Use Gateway And Supervision when you need the command-by-command ownership model, selector syntax, and rollout order in one place.

​
Gateway-Supervised Service Channels

These are the service lanes that can currently join gateway run at the operator/runtime layer. Some still keep implementation_status=plugin_backed in the catalog because their setup and transport contracts preserve managed-bridge-capable or externally bridged history.

​
Standalone Native-Serve Channels

These are Loong-runnable send plus serve lanes, but their runtime owner is still the individual channels serve <surface> loop instead of gateway supervision. Their catalog metadata may still preserve managed-bridge-capable setup truth even though the current operator/runtime grouping is standalone.

​
External Plugin-Backed Bridge Surfaces

These are already operator-visible channel contracts, but they stay honest about runtime ownership.

​
Outbound Surface Families

These surfaces ship direct sends, config validation, and inventory metadata without claiming a full reply-loop runtime. This page keeps the concept layer short on purpose; the fuller field-level inventory remains in Channel Setup.

​
Public Documentation Rule

Loong tries to keep the public channel story truthful:
  • the gateway contract is documented as the runtime owner contract
  • shipped gateway-supervised surfaces are documented as gateway-supervised
  • shipped standalone native-serve surfaces are documented as native serve lanes without overclaiming gateway supervision
  • shipped plugin-backed surfaces are documented as bridge-owned rather than pretending the gateway already owns their listener lifecycle
  • outbound-only surfaces are documented as outbound-only
  • catalog entries are not overclaimed as runtime support

​
Typical Progression

  1. Get the local assistant path healthy first.
  2. Add one gateway-supervised service channel if you need the shortest path into gateway run.
  3. Use a standalone native-serve channel when you need a real built-in channels serve <surface> loop but do not need gateway supervision yet.
  4. Reach for a plugin-backed bridge surface when the ecosystem is real but Loong intentionally delegates login and listener ownership to an external bridge.
  5. Use outbound-only surfaces when you need governed direct sends without pretending they are full runtime surfaces.
  6. Reach for gateway run when you want multiple gateway-supervised service channels attached to the same CLI host.

​
Where To Go Next

  • Continue to Channel Guides for the full actionable channel matrix.
  • Continue to Channel Recipes for representative gateway-supervised, standalone native-serve, and outbound rollout examples.
  • Continue to Channel Setup for the practical public setup guide.
  • Continue to Gateway And Supervision for the longer-lived owner contract and channel-account selection rules.
  • For the broader public runtime contract, continue to Use Loong.
  • The full field-level source spec still lives in the repository’s public Channel Setup markdown.