Marketplace

The marketplace governance surface in the web app and the companion nous pkg discover CLI seam expose the same canonical browse, moderation, and advisory discovery truth.

These surfaces are projections over canonical registry and nudge-runtime truth. They do not own separate package governance, moderation, or suppression state.

What the Marketplace Surface Covers

The marketplace surface lets you:

• Browse governed registry packages with trust tier, distribution status, and compatibility posture
• Open package detail views for provenance, release history, maintainer verification, governance actions, and appeals
• Review moderation dashboard posture for holds, delistings, pending appeals, and escalation continuity
• Inspect advisory discovery suggestions with mandatory suppression controls
• Follow trust-preserving deep links into Projects and MAO

Browse and Detail Views

The browse page is the main entry point for package discovery. It shows canonical registry projections, including:

• Trust tier
• Distribution status
• Compatibility state
• Current release metadata
• Links into related package detail views

Package detail views extend that with:

• Provenance and maintainer records
• Release history
• Governance timeline
• Appeal history
• Project-scoped trust-eligibility posture when you open the page with a project context

If a package is blocked for a project, treat that trust-eligibility result as authoritative runtime truth rather than as a UI hint.

Moderation Dashboard

The moderation dashboard is an inspect-first projection over package governance state. Use it to review:

• Packages on distribution hold
• Delisted packages
• Packages with recent governance actions
• Packages with pending or resolved appeals
• Escalation IDs linked from package, governance, or appeal evidence

This surface does not resolve appeals or invent moderation state locally. It shows canonical registry projections so the same posture remains visible across surfaces.

Advisory Discovery Feed

Discovery suggestions are advisory only.

Each suggestion card can include:

• Why the suggestion appeared
• Source trust posture
• Project-specific trust eligibility
• Available suppression controls

Available suppression actions are:

• dismiss_once
• snooze
• mute_category
• mute_project
• mute_global

Suppression is canonical runtime truth and applies across enabled delivery surfaces, not only where the action was taken.

Acceptance and Execution Boundary

Accepting a marketplace package suggestion does not install the package directly.

Marketplace-package acceptance currently routes to runtime_authorization_required, which records lifecycle authorization intent and then stops at the existing runtime membrane. Install and enable flows still belong to the governed lifecycle path.

From Discovery to Install and Settings

Discovery stays advisory until you choose a governed install path for a specific project.

For installable app packages, the web package detail view can now launch the canonical install wizard when you open the package with a project context. That wizard keeps the host in charge of the flow:

• Permission review — you must explicitly approve the package's declared runtime permissions before install work continues
• Configuration — fields are rendered directly from the package manifest instead of a package-authored custom install UI
• Validation and activation — the runtime reports success, partial, or failed results and returns you to a recoverable configuration state if required input is missing or activation fails

Secrets and OAuth setup stay vault-mediated during this flow. Non-secret configuration remains project-scoped runtime truth rather than browser-owned state.

If the package is already installed for that project, the same package detail view swaps from the install wizard into the shared settings surface instead of inventing a second UI path. That settings surface:

• Reuses the same manifest-derived grouped fields, required/optional semantics, and vault-backed secret controls
• Shows the active runtime/config-version summary before save
• Runs the governed deactivate -> update config -> reactivate flow and reports explicit applied, reverted, or blocked outcomes
• Pushes host-owned config refreshes to active app panels after a successful save instead of remounting the iframe or storing panel-local settings truth

You can still use the CLI when you want to move from a reviewed suggestion into an actual project-scoped install:

pnpm dev:cli -- pkg discover --project <id>
pnpm dev:cli -- pkg install <package-id> --project <id>

You can also target a specific release or constrain the version range:

pnpm dev:cli -- pkg install <package-id> --project <id> --release rel_123
pnpm dev:cli -- pkg install <package-id> --project <id> --version ^2.0.0

That install path:

• Resolves dependencies through the shared canonical resolver
• Applies the same lifecycle and trust gates used by first-party surfaces
• Writes packages only into canonical package-store roots
• Returns explicit installed, blocked, or rolled_back status with reason-coded failures

Cross-Surface Continuity

Marketplace links can preserve context into other surfaces instead of rebuilding it locally.

• Projects can receive project, package, release, and evidence continuity when you follow a marketplace handoff
• MAO can receive the same context for operator inspection and escalation follow-up
• CLI can project the same advisory feed through nous pkg discover

That continuity is read-side only. Projects and MAO do not become secondary stores for marketplace governance or suppression state.

CLI Companion: nous pkg discover

Use the CLI when you want the same advisory feed in a terminal workflow.

pnpm dev:cli -- pkg discover --project <id>

The command:

• Reads the same canonical discovery feed used by the web marketplace surface
• Prints trust-eligibility posture directly from runtime truth
• Records card-open feedback automatically
• Can apply suppression actions back through the canonical marketplace runtime

Current Boundary

Marketplace does not install packages directly from the discovery feed itself.

If you need to act on an accepted package suggestion, continue through the governed install path such as nous pkg install, which keeps dependency resolution, lifecycle enforcement, and package-store writes inside the canonical runtime membrane.