Workflow-first MVPDocs Center liveHelp routes reservedProjects & Billing in codeSupply & Marketplace in code

Marketplace

Marketplace now acts as the Day 7 catalog source of truth: listing category, version, and install posture are fixed before checkout, activation mutations, and settlement release go live.

Help CenterDocs Center

Module Entry Map

Marketplace module entry map

Day 9 keeps listing catalog, review queue, version history, and install contract as explicit subroutes now, so later moderation and transaction work can plug into a stable module structure.

Module 5 Day 9 shipped

Marketplace

把 listing、review、version、install 这些市场二级入口先留全，避免后面接交易或 moderation 时再重排结构。

打开模块查看文档

Listings

In Code

为 listing catalog、category mapping、pricing summary 与 provider attribution 预留独立目录入口。

listingsReserved route

Review Queue

In Code

为 listing review、supplier exception、activation block 与 moderation 决策预留独立队列入口。

review-queueReserved route

Version History

In Code

为 version channel、compatibility summary 与 active release 切换预留独立版本入口。

versionsReserved route

Install Contracts

In Code

为 project-bound install、activation state 与 buyer-side contract 预留独立安装入口。

installsReserved route

Marketplace

Marketplace listing and install contracts now share one catalog foundation

Module 5 Day 7 now fixes how category, listing version, and install posture enter the catalog before live checkout, activation mutations, and moderation workflows exist. Listing shape is no longer just page copy; it is now shared platform truth.

Service boundary: foundation-control-plane-service

State demoLiveEmptyError
Module 5 Day 7 shipped

Live listings

1

In review

1

Draft

1

Marketplace category map

Day 7 fixes category as explicit catalog truth before live review queues, checkout, or activation workflows exist.

Shared catalog truth

Forms

Submit structured input to a target form or intake surface.

Best for autofill, submission, intake, and other workflows where the buyer expects deterministic field contracts.

Review target specificity, field contract clarity, selector drift risk, and whether the listing describes a bounded submission surface instead of vague automation.

Install boundary

Form listings should install against an explicit project and should stay traceable to the target contract or equivalent schema boundary they rely on.

Typical install

Project-gatedManual activation

Sync

Move data between systems on a repeatable contract instead of one-off manual export.

Best for recurring data movement, ingestion, publication, and state reconciliation across products or sites.

Review source and destination ownership, activation prerequisites, and whether the install contract makes the sync scope understandable before activation.

Install boundary

Sync listings should install into a project-owned integration boundary so operators can audit which project accepted the data flow.

Typical install

Manual activationProject-gated

Automation

Add a reusable MCP capability that can be activated quickly inside a project workspace.

Best for general-purpose actions or assistants where the buyer mainly needs a stable capability contract and clear activation scope.

Review outcome clarity, commercial scope, and whether the install contract explains what becomes active immediately versus what still needs setup.

Install boundary

Automation listings should still bind to a buyer project even when activation is instant, so later usage, review, and settlement can trace back to the install contract.

Typical install

InstantProject-gated

Install contract map

Install selection and activation now resolve through explicit contract shapes instead of staying hidden in listing copy.

Shared install truth

Instant

project-scoped install activates immediately

Best for trusted listings that can become available as soon as the buyer project accepts the contract.

Instant installs still need an explicit project record and a pinned listing version, but they do not wait on a second supplier or operator step after installation.

Activation boundary

The install should remain traceable to one project and one version label even when activation happens immediately.

Project-gated

project-scoped install with required setup step

Best when a listing must be attached to buyer configuration, target mapping, or project-specific policy before it becomes usable.

Project-gated installs separate the commercial act of selecting the listing from the operational act of configuring it inside the buyer project.

Activation boundary

The install record may exist before activation, but activation should not complete until the project-level contract is configured.

Manual activation

install waits on supplier or operator confirmation

Best when the listing still needs domain proof, review completion, support verification, or another human-confirmed activation step.

Manual activation keeps listing selection visible without pretending the buyer can use the capability before the supplier-side prerequisites are complete.

Activation boundary

The install record should remain pending until both buyer project context and supplier-side readiness are explicitly satisfied.

Listings

Keep category, active version, install mode, and install count queryable before purchase, checkout, and activation mutations arrive.

ListingProviderStatusVersionInstallInstalls

Marketplace contract rules

Every listing must resolve to an explicit service contract

A marketplace listing should point to a bounded service offering or equivalent contract instead of acting as a loose wrapper around arbitrary third-party code.

Every listing must declare one category explicitly

Category should remain queryable and reviewable as first-class metadata instead of being inferred from marketing copy or provider branding.

Public listing posture must stay separate from version history

Listing review state, active version, and supplier endpoint health should remain related but separate so the catalog can explain what is installable without collapsing everything into one status field.

Every install record must bind to a buyer project first

Marketplace installs should resolve to the buyer project boundary before activation or later usage is allowed to accumulate against the listing.

Every install should pin a listing version explicitly

Install records should reference a concrete version label so activation, support, and rollback do not depend on an implicit floating latest release.

Install selection and activation must remain separate concepts

A buyer may select a listing before it becomes active, so install count, activation posture, and purchase readiness should not collapse into one hidden flag.