Skip to content

docs: define plugin marketplace and sdk boundary contracts#1196

Open
chumyin wants to merge 3 commits intoeastreams:devfrom
chumyin:plugin-sdk-openclaw-compat-architecture-20260408
Open

docs: define plugin marketplace and sdk boundary contracts#1196
chumyin wants to merge 3 commits intoeastreams:devfrom
chumyin:plugin-sdk-openclaw-compat-architecture-20260408

Conversation

@chumyin
Copy link
Copy Markdown
Collaborator

@chumyin chumyin commented Apr 10, 2026

Summary

  • Problem:
    LoongClaw already had a manifest-first plugin package contract, an OpenClaw compatibility contract, an ecosystem strategy document, and a marketplace contract, but it still lacked one explicit boundary contract for the author-facing SDK family. Without that layer, future SDK work can sprawl across guest-side helpers, host-native extension APIs, and compatibility tooling without a clear separation rule.
  • Why it matters:
    Without an SDK boundary contract, the project risks letting a single bridge-targeted SDK slice (such as the WASM guest SDK in #426) become the accidental shape of the whole plugin SDK story, while helper crates drift into parallel metadata or policy models.
  • What changed:
    • added docs/design-docs/plugin-sdk-boundary-contract.md
    • linked the SDK boundary contract from the design-doc index
    • linked the SDK boundary contract from the plugin SDK strategy doc
    • tightened the package and marketplace docs so native host-extension ABI and marketplace/install semantics stay distinct from compatibility and helper layers
    • preserved the earlier strategy and marketplace contract work already present on this branch
  • What did not change (scope boundary):
    • no implementation of the #426 WASM guest SDK
    • no runtime bridge behavior changes
    • no new package manager, registry backend, or crates.io publication flow
    • no change to package, compatibility, preflight, or marketplace authority semantics beyond boundary clarification

Linked Issues

Change Type

  • Bug fix
  • Feature
  • Refactor
  • Documentation
  • Security hardening
  • CI / workflow / release

Touched Areas

  • Kernel / policy / approvals
  • Contracts / protocol / spec
  • Daemon / CLI / install
  • Providers / routing
  • Tools
  • Browser automation
  • Channels / integrations
  • ACP / conversation / session runtime
  • Memory / context assembly
  • Config / migration / onboarding
  • Docs / contributor workflow
  • CI / release / workflows

Risk Track

  • Track A (routine / low-risk)
  • Track B (higher-risk / policy-impacting)

Validation

  • cargo fmt --all -- --check
  • cargo clippy --workspace --all-targets --all-features -- -D warnings
  • cargo test --workspace --locked
  • cargo test --workspace --all-features --locked
  • Relevant architecture / dep-graph / docs checks for touched areas
  • Additional scenario, benchmark, or manual checks when behavior changed
  • If this changes config/env fallback, limits, or defaults: include before/after behavior and regression coverage for explicit path, fallback path, and boundary values
  • If tests mutate process-global env: document how state is restored or serialized

Commands and evidence:

env CARGO_TARGET_DIR=<redacted-target-dir> cargo fmt --all -- --check
env CARGO_QUEUE_BYPASS=1 CARGO_QUEUE_ALLOW_BYPASS=1 CARGO_TARGET_DIR=/private/tmp/loongclaw-plugin-sdk-boundary-target cargo clippy --workspace --all-targets --all-features -- -D warnings
env CARGO_QUEUE_BYPASS=1 CARGO_QUEUE_ALLOW_BYPASS=1 CARGO_TARGET_DIR=/private/tmp/loongclaw-plugin-sdk-boundary-target cargo test --workspace --locked
env CARGO_QUEUE_BYPASS=1 CARGO_QUEUE_ALLOW_BYPASS=1 CARGO_TARGET_DIR=/private/tmp/loongclaw-plugin-sdk-boundary-target cargo test --workspace --all-features --locked
LOONGCLAW_RELEASE_DOCS_STRICT=1 scripts/check-docs.sh

The docs check still fails on untouched baseline release-trace and debug-doc gaps under `.docs/` and `docs/releases/`:
- missing `.docs/releases/v0.1.0-alpha.2-debug.md`
- missing `.docs/releases/v0.1.0-alpha.1-debug.md`
- missing `.docs/traces/index.jsonl`
- missing `.docs/traces/latest`
- missing by-tag trace pointers and metadata for the two released versions

User-visible / Operator-visible Changes

  • Public plugin architecture guidance now defines an explicit SDK boundary contract that separates stable contract types, bridge-targeted runtime helpers, compatibility helpers, and the separately governed native host-extension ABI lane.

Failure Recovery

  • Fast rollback or disable path:
    Revert the documentation changes or drop the SDK boundary contract from this branch before merge.
  • Observable failure symptoms reviewers should watch for:
    Boundary drift between package truth, marketplace truth, compatibility truth, and future SDK helper responsibilities.

Reviewer Focus

  • Verify that the SDK boundary contract keeps package, marketplace, and governance truth authoritative instead of letting SDK layers redefine them.
  • Verify that the native host-extension ABI remains clearly separate from compatibility-origin packages and marketplace review state.
  • Verify that #426 is now framed as one implementation slice rather than the total plugin SDK architecture.

Summary by CodeRabbit

  • Documentation
    • Added three active design documents to the index: Plugin Marketplace & Interface Contract, Plugin SDK Boundary Contract, and Plugin SDK & Ecosystem Strategy.
    • Introduced a Plugin Marketplace & Interface Contract specifying catalog/listing schema, install/auth policies, interface metadata, and precedence rules.
    • Added an SDK Boundary Contract and an SDK & Ecosystem Strategy outlining layered SDKs, compatibility levels, and migration pathways.
    • Updated plugin package and compatibility documents with cross-references to the new specs.

chumyin added 2 commits April 10, 2026 22:08
The existing plugin package and compatibility contracts already define strong
kernel and governance boundaries, but future SDK and marketplace work still
lacked one strategy document that tied native authoring, foreign-dialect
compatibility, marketplace packaging, and migration together.

This adds that strategy layer and links it from the existing package and
OpenClaw compatibility contracts so follow-on SDK and ecosystem work has one
public architecture source of truth.

Constraint: Existing plugin package and compatibility documents remain the
normative source for manifest and activation behavior
Rejected: Copy OpenClaw runtime registration semantics into the native SDK |
conflicts with kernel-first, fail-closed boundaries
Rejected: Fold marketplace metadata into kernel activation metadata |
would blur display/install policy with activation authority
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Treat the named SDK layers as illustrative architecture slices, not
as a locked future crate layout, unless a later RFC explicitly commits to that
packaging
Tested: cargo fmt --all -- --check; cargo clippy --workspace --all-targets --all-features -- -D warnings; cargo test --workspace --locked; cargo test --workspace --all-features --locked
Not-tested: LOONGCLAW_RELEASE_DOCS_STRICT=1 scripts/check-docs.sh still fails on untouched release-trace/debug-doc baseline gaps under .docs/ and docs/releases
The package, compatibility, and SDK strategy docs already describe runtime
truth, but marketplace, install-policy, and interface-metadata concerns were
still implied across multiple places without one contract. That left future
catalog and install work vulnerable to parallel metadata drift.

This adds a dedicated marketplace contract and links it from the existing
plugin package, compatibility, and SDK strategy docs so future catalog work has
one explicit package-versus-marketplace boundary.

Constraint: Marketplace metadata must remain listing-scoped and may not widen
activation or governance authority
Rejected: Let catalog metadata double as activation truth | would create shadow
authority outside manifest, preflight, and attestation boundaries
Rejected: Delay marketplace contract until the full SDK crate lands | leaves
registry and install tooling without a stable catalog contract
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep future marketplace implementations aligned with this catalog
contract and the existing `marketplace_submission` preflight lane instead of
introducing a separate policy parser
Tested: cargo fmt --all -- --check; cargo clippy --workspace --all-targets --all-features -- -D warnings; cargo test --workspace --locked; cargo test -p loongclaw-app channel::http::tests::outbound_http_client_does_not_follow_redirects -- --exact --nocapture; cargo test --workspace --all-features --locked
Not-tested: LOONGCLAW_RELEASE_DOCS_STRICT=1 scripts/check-docs.sh still fails on untouched release-trace/debug-doc baseline gaps under .docs/ and docs/releases
@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Apr 10, 2026

📝 Walkthrough

Walkthrough

Adds three new design documents (marketplace contract, SDK boundary contract, SDK & ecosystem strategy), updates the design-doc index to list them as Active, and adds cross-references from existing compatibility and manifest contract docs to the new documents. All changes are documentation-only.

Changes

Cohort / File(s) Summary
Design-doc index
docs/design-docs/index.md
Added three new Active rows for the marketplace contract, SDK boundary contract, and SDK & ecosystem strategy.
Marketplace contract
docs/design-docs/plugin-marketplace-contract.md
New doc defining a marketplace catalog artifact (loongclaw.marketplace.json), catalog root and per-listing schemas, typed source descriptors, install/auth policy vocabularies, interface metadata overlay (display-only), trust/review hints, compatibility projection rules, and explicit package vs marketplace vs host precedence.
SDK boundary
docs/design-docs/plugin-sdk-boundary-contract.md
New doc specifying four SDK-related layers (contract, runtime helper, compatibility helper, native host-extension ABI), boundary rules for ownership of truth, dependency-direction constraints, anti-patterns, and a phased extraction plan.
SDK & ecosystem strategy
docs/design-docs/plugin-sdk-and-ecosystem-strategy.md
New doc describing a five-layer ecosystem model, three-family SDK strategy (contract/schema, runtime helper, compatibility), OpenClaw compatibility levels, marketplace responsibilities, migration lanes, phased implementation order, and validation standards.
Cross-references / clarifications
docs/design-docs/openclaw-plugin-compatibility-contract.md, docs/design-docs/plugin-package-manifest-contract.md
Added cross-references to the new SDK/marketplace docs; clarified manifest contract scope (version/baseline display metadata) and native-extension non-goals and host-approval requirement.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related issues

Possibly related PRs

Suggested labels

size: L

Poem

🐰 Contracts sprout in tidy rows,

Marketplace and SDKs grow,
Manifests keep their honest light,
Boundary lines drawn neat and right,
I nibble docs and hop—hooray! 🥕✨

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The PR title clearly summarizes the primary change: adding plugin marketplace and SDK boundary contracts to the design documentation.
Linked Issues check ✅ Passed The PR successfully fulfills issue #1193's requirements: a marketplace contract document is added with typed schemas, install/auth policy vocabularies, interface metadata, precedence rules, and cross-references to package/compatibility/SDK strategy docs.
Out of Scope Changes check ✅ Passed All changes remain within scope: five design documents added or updated for architecture clarity, design-doc index updated, and no runtime code or implementation changes introduced.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
⚔️ Resolve merge conflicts
  • Resolve merge conflict in branch plugin-sdk-openclaw-compat-architecture-20260408

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@github-actions github-actions Bot added documentation Improvements or additions to documentation. spec Architecture boundaries, product specs, and design docs. size: XL Very large pull request: more than 1000 changed lines. labels Apr 10, 2026
The plugin package, compatibility, marketplace, and ecosystem strategy docs
already define lower-level truth, but future SDK work still lacked one explicit
boundary for contract types, bridge helpers, compatibility helpers, and the
separate native host-extension lane.

This adds that boundary contract and links it back into the existing docs so
future SDK work can advance in smaller slices without re-opening the whole
architecture question.

Constraint: SDK helper layers must consume package, marketplace, and governance
truth rather than redefining it
Rejected: Treat the WASM guest SDK RFC as the total plugin SDK architecture |
would overfit one helper slice into the whole SDK story
Rejected: Expose host internals through one broad default SDK crate | would
blur guest-side helpers, host-native extension lanes, and compatibility tooling
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep future SDK implementations aligned with this boundary and keep
native host-extension APIs separately host-approved, non-default, and distinct
from compatibility-origin helper lanes
Tested: cargo fmt --all -- --check; cargo clippy --workspace --all-targets --all-features -- -D warnings; cargo test --workspace --locked; cargo test --workspace --all-features --locked
Not-tested: LOONGCLAW_RELEASE_DOCS_STRICT=1 scripts/check-docs.sh still fails on untouched release-trace/debug-doc baseline gaps under .docs/ and docs/releases
@chumyin chumyin changed the title docs: define plugin marketplace contract docs: define plugin marketplace and sdk boundary contracts Apr 10, 2026
Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (1)
docs/design-docs/plugin-sdk-and-ecosystem-strategy.md (1)

124-172: Trim detailed external comparison content in public strategy docs.

This section is very detailed about an external project’s internal paths and structure. Consider reducing it to a short, LoongClaw-focused principle summary and moving detailed comparisons to the knowledge-base.

Based on learnings: Public-repo issues, PRs, and public documentation should stay LoongClaw-centric; keep detailed external project comparisons in loongclaw-ai/knowledge-base unless naming an external project is strictly necessary.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@docs/design-docs/plugin-sdk-and-ecosystem-strategy.md` around lines 124 -
172, The "What Codex Teaches" section exposes too many external-project
internals (e.g., references to `.codex-plugin/plugin.json` and
`.agents/plugins/marketplace.json`)—trim this to a short LoongClaw-focused
principles summary (keep the three high-level lessons: separate marketplace
policy from runtime contract, plugin bundles compose product surfaces, and
interface metadata belongs in a stable contract) and move the detailed
external-path comparisons into the knowledge-base (loongclaw-ai/knowledge-base)
or an appendix; preserve the conceptual points and remove or genericize explicit
external file-path examples so the public doc remains LoongClaw-centric.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@docs/design-docs/plugin-sdk-and-ecosystem-strategy.md`:
- Around line 52-66: The executive summary currently claims "five layers" but
lists only four and omits the previously defined foreign-dialect normalization
layer (Layer 2); update the paragraph to include the missing "Foreign-dialect
normalization" layer and renumber the list 1–5 so each named layer matches its
detailed definition: insert a new item "2. Foreign-dialect normalization layer —
one normalization/translation boundary for foreign dialects and compatibility
transforms" (or similar wording), shift "Marketplace and interface contract" to
3, "Runtime bridge contract" to 4, and "SDK and migration contract" to 5, and
ensure the opening line still reads "The mature ecosystem shape has five layers"
to reflect the corrected mapping.

---

Nitpick comments:
In `@docs/design-docs/plugin-sdk-and-ecosystem-strategy.md`:
- Around line 124-172: The "What Codex Teaches" section exposes too many
external-project internals (e.g., references to `.codex-plugin/plugin.json` and
`.agents/plugins/marketplace.json`)—trim this to a short LoongClaw-focused
principles summary (keep the three high-level lessons: separate marketplace
policy from runtime contract, plugin bundles compose product surfaces, and
interface metadata belongs in a stable contract) and move the detailed
external-path comparisons into the knowledge-base (loongclaw-ai/knowledge-base)
or an appendix; preserve the conceptual points and remove or genericize explicit
external file-path examples so the public doc remains LoongClaw-centric.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 776154e2-7fea-4e8f-b6e5-519b2ebb5373

📥 Commits

Reviewing files that changed from the base of the PR and between b7597fd and 7e2daa3.

📒 Files selected for processing (5)
  • docs/design-docs/index.md
  • docs/design-docs/plugin-marketplace-contract.md
  • docs/design-docs/plugin-package-manifest-contract.md
  • docs/design-docs/plugin-sdk-and-ecosystem-strategy.md
  • docs/design-docs/plugin-sdk-boundary-contract.md
✅ Files skipped from review due to trivial changes (4)
  • docs/design-docs/index.md
  • docs/design-docs/plugin-sdk-boundary-contract.md
  • docs/design-docs/plugin-package-manifest-contract.md
  • docs/design-docs/plugin-marketplace-contract.md

Comment on lines +52 to +66
The mature ecosystem shape has five layers:

1. **Native package contract**
- one stable host-facing plugin contract
- one typed manifest-first package shape
2. **Marketplace and interface contract**
- one user-facing catalog shape for install, auth, category, and display
- decoupled from kernel activation semantics
3. **Runtime bridge contract**
- one bridge-oriented execution boundary for `process_stdio`, `http_json`,
`mcp_server`, future WASM, and related lanes
4. **SDK and migration contract**
- one native SDK family for LoongClaw packages
- one compatibility SDK family for OpenClaw ingestion and migration

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Fix the executive-summary layer count and mapping.

Line 52 says “five layers,” but only four are listed, and the list omits the foreign-dialect normalization layer that is later defined as Layer 2. This creates architectural ambiguity for readers implementing the strategy.

Suggested doc fix
-The mature ecosystem shape has five layers:
+The mature ecosystem shape has five layers:
 
 1. **Native package contract**
    - one stable host-facing plugin contract
    - one typed manifest-first package shape
-2. **Marketplace and interface contract**
+2. **Foreign dialect normalization contract**
+   - one normalization seam that projects foreign descriptors into canonical LoongClaw truth
+   - explicit compatibility-mode selection before activation
+3. **Marketplace and interface contract**
    - one user-facing catalog shape for install, auth, category, and display
    - decoupled from kernel activation semantics
-3. **Runtime bridge contract**
+4. **Runtime bridge contract**
    - one bridge-oriented execution boundary for `process_stdio`, `http_json`,
      `mcp_server`, future WASM, and related lanes
-4. **SDK and migration contract**
+5. **SDK and migration contract**
    - one native SDK family for LoongClaw packages
    - one compatibility SDK family for OpenClaw ingestion and migration
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
The mature ecosystem shape has five layers:
1. **Native package contract**
- one stable host-facing plugin contract
- one typed manifest-first package shape
2. **Marketplace and interface contract**
- one user-facing catalog shape for install, auth, category, and display
- decoupled from kernel activation semantics
3. **Runtime bridge contract**
- one bridge-oriented execution boundary for `process_stdio`, `http_json`,
`mcp_server`, future WASM, and related lanes
4. **SDK and migration contract**
- one native SDK family for LoongClaw packages
- one compatibility SDK family for OpenClaw ingestion and migration
The mature ecosystem shape has five layers:
1. **Native package contract**
- one stable host-facing plugin contract
- one typed manifest-first package shape
2. **Foreign dialect normalization contract**
- one normalization seam that projects foreign descriptors into canonical LoongClaw truth
- explicit compatibility-mode selection before activation
3. **Marketplace and interface contract**
- one user-facing catalog shape for install, auth, category, and display
- decoupled from kernel activation semantics
4. **Runtime bridge contract**
- one bridge-oriented execution boundary for `process_stdio`, `http_json`,
`mcp_server`, future WASM, and related lanes
5. **SDK and migration contract**
- one native SDK family for LoongClaw packages
- one compatibility SDK family for OpenClaw ingestion and migration
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@docs/design-docs/plugin-sdk-and-ecosystem-strategy.md` around lines 52 - 66,
The executive summary currently claims "five layers" but lists only four and
omits the previously defined foreign-dialect normalization layer (Layer 2);
update the paragraph to include the missing "Foreign-dialect normalization"
layer and renumber the list 1–5 so each named layer matches its detailed
definition: insert a new item "2. Foreign-dialect normalization layer — one
normalization/translation boundary for foreign dialects and compatibility
transforms" (or similar wording), shift "Marketplace and interface contract" to
3, "Runtime bridge contract" to 4, and "SDK and migration contract" to 5, and
ensure the opening line still reads "The mature ecosystem shape has five layers"
to reflect the corrected mapping.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation. size: XL Very large pull request: more than 1000 changed lines. spec Architecture boundaries, product specs, and design docs.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Feature]: Define a plugin SDK boundary contract

1 participant