Chains share the execution telemetry channel: one bounded, content-free chain
per inbound platform event (platform event -> routing -> Pipeline/Agent/plugin
processor -> platform API calls), sampled by space.execution_trace
(off | failures | sampled | all). Chains keep only code-defined identifiers,
report routing targets as type:uuid instead of user-defined rule names, and
share the 30-day retention of execution records.
A Workspace installs a plugin once, but that single installation is reused by
several product objects: every processor for a Runner, every knowledge base for
a KnowledgeEngine / Parser / Retriever, and many conversations or page requests
for the other component kinds. The platform storage key carries no processor or
knowledge-base dimension, so a plugin must fold that identity into its own keys.
- certified-plugins: add "one installation, many usages" with the isolation
dimensions per component kind, and "when an installation is revoked"
documenting BasePlugin.on_installation_revoked, its trigger set, the absent
invocation context and the no-op/failure semantics.
- component pages (runner, knowledge-engine, knowledge-retriever, parser, tool,
command, event-listener, page): add a short component-specific section with
that component's own rules and a link to the contract page.
- Align the background-work rule with the SDK contract: the SDK does not track
ownership of detached work, so a plugin must keep its own binding-keyed
registry and stop it in the revocation hook.
All three locales carry the same sections.
Rewrite plugin/certified-plugins in all three locales around the
questions a plugin developer actually asks, and make it the single home
for certification: what it is, why it exists, when it is needed, what
changes after approval, and what the contract requires.
- Decision framing restored, including a needs/does-not-need table and
the explicit statement that most plugins do not need certification.
- Full manifest example, accepted values for both declaration fields and
the SDK version that recognises them.
- Constraints kept and tightened: stateless rules, allowed/forbidden
table, anti-patterns with correct/incorrect snippets, Runner notes,
self-check list.
- Submission flow moved onto this page so it no longer depends on the
publishing page.
- Operator content that duplicates the Core architecture document
removed (Cloud admission matrix, OSS issuer keys, certificate fields,
internal review tiers).
publish/market is now publishing-only with a one-line pointer, and its
misplaced plugin_submission screenshot moves back under the upload
section where it belongs. dev/basic-info replaces the commented-out
manifest fields with a link to the contract page.
ja had been missing whole sections (36 lines); all three locales now
share the same section structure.
* docs(platforms): add HTTP Bot adapter tutorial (zh/en/ja)
Server-to-server HTTP integration guide for the new http_bot platform
adapter: signed inbound webhook, signed outbound callbacks, N->1 aggregation,
1->M multi-reply, session reset, sync convenience mode, error codes, and a
5-minute reference-client demo. Registered in docs.json nav for all three
locales; adds the platform icon.
* docs(http-bot): link the interactive playground in all locales
Add a section pointing at examples/http-bot/playground.py (browser debug
console: sign -> POST -> 202 -> live callbacks) ahead of the CLI reference
clients, in zh/en/ja.
* style(platforms): use </> code icon for http-bot logo
External MCP server connection now offers two modes (local stdio /
remote) instead of three. Remote only needs a URL and the runtime
auto-detects the transport; legacy http/sse entries are auto-normalized
to remote. Updated zh/en/ja usage/mcp pages. Does not touch LangBot's
own /mcp agent-facing server docs.
The deploy 'System Settings' page showed the api: block without the
global API key. Add the field + a note explaining it authenticates both
the HTTP API and the MCP server (/mcp) with no login session, reusing
the same key. Links to docs/API_KEY_AUTH.md.
Mirror the LangBot AGENTS.md addition: MCP server at /mcp, in-repo skills/ as the
single source of truth, global API key, and the API<->MCP<->skills sync rule.
The English and Japanese guide/features pages led their platform
enumerations with China-only platforms (WeChat, WeCom, DingTalk), and
the "AI customer service" example named China-only platforms to a global
/ Japanese audience. Reorder the marketing enumerations and examples so
each locale leads with the platforms mainstream in its region:
- en: Discord, Telegram, Slack first, then QQ/WeChat/WeCom/Lark/DingTalk
- ja: LINE, Slack, Discord, Telegram first, then the China platforms
Only the hero/landing prose and the use-case examples are reordered; the
functional webhook/adapter reference lists are left as-is. The Chinese
docs already lead with China platforms and are unchanged. No platform is
added that LangBot does not actually support.
Hyu