Hyu
e279f2fae8
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.
LangBot Official Documentation
This repository is the documentation repository for LangBot. Code repository:
LangBot Code Repository
This is the documentation for LangBot 4.0. For 3.0 documentation, please see thev3branch
Contributing to Documentation
The documentation is built with Fumapress and Fumadocs. Local development requires Node.js 24 or later.
Clone this repository and execute the following command in the directory to install dependencies:
npm ci
After completion, you can modify the documentation. After modifications, use the following command to start locally:
npm run dev
Using Images
Place images in the images directory, then reference them using the absolute path (relative to the project root), such as:
Deployment Details
The documentation is built as a static site in dist/public and hosted on Cloudflare Pages. Type checking, documentation contract tests, and a full static build run before deployment.
Agent-readable exports
npm run build generates agent text after finalizing the /docs base path and
sitemaps. Every published page has a canonical .md companion, advertised by an
HTML rel="alternate" type="text/markdown" link without changing the visible UI.
/docs/llms.txtand/docs/llms-full.txt: all-language index and complete text./docs/{en,zh,ja}/llms.txtandllms-full.txt: language-specific exports.llm.txtis an identical compatibility alias for eachllms.txtindex./docs/openapi/service-api-{en,zh,ja}.json: complete API specifications.
The generator reads canonical MDX with a Markdown AST (not compiled image
variables), preserves callout titles and literal image URLs, and exports every
API operation with its request/response contract, security and transitive schema
references. Unknown semantic JSX or executable expressions fail the build rather
than silently losing content. Generated files stay in dist/public; edit source
MDX/OpenAPI, not generated Markdown. npm test covers conversion, and
npm run test:static verifies sitemap coverage, discovery, links and API contracts
after a build. Run npm run generate:agent-docs to regenerate text in an existing
finalized build.
Some Standardization Guidelines
- Folder and file naming: Use all lowercase, separate words with
-, such asplugin-intro.mdx - Sub-file (folder) naming: No prefix (i.e., the folder name), such as: in the
deployfolder, the folderlangbot, themanualfile in thelangbotfolder is calledmanual.mdx - Documentation files should use
.mdx; the build adapter converts existing Mintlify-compatible components into Fumadocs-renderable markup. - Configure sidebar navigation structure in
docs.json.