Plugin Marketplace Boundaries
Read this page when you need the accepted architecture boundary for Holon's future plugin marketplace without treating the marketplace as broad current implemented behavior.
Current-State Summary
Holon's current implemented plugin surface remains the holon-plugin/v1 register, import, inventory, and discovery slice described in Plugin Packages.
- There is no current marketplace, remote registry sync, uninstall, disable, update, signing, or broad live plugin execution claim.
- Current live execution remains intentionally narrow and runtime-governed.
- Current subprocess execution posture remains bounded and policy-governed, but not OS-confined.
This page records accepted design boundaries for future marketplace work while also noting the small bounded runtime-only migration slice that now exists for plugin-package import normalization. It does not claim that the broader marketplace surfaces are implemented today.
Accepted Boundary
Holon should use one user-facing umbrella term, plugin, while preserving typed internal asset records so the runtime can reason explicitly about execution lanes, permissions, dependencies, evidence, and trust.
The marketplace is a governed discovery, packaging, trust, and promotion surface over one or more registries. It is not itself the execution authority. Holon runtime policy, approvals, secrets, execution, and evidence remain host-owned.
The first marketplace package contract should be holon-plugin/v2-core, not a universal manifest for every future asset family.
Core Definitions
| Term | Meaning | Must Not Hide |
|---|---|---|
| Plugin | User-facing installable package grouping one or more typed assets under one identity. | Asset kinds, execution lanes, dependencies, permissions, trust level. |
| Asset | Typed component inside a plugin, such as a skill, workflow, eval pack, resource pack, or executable binding. | Runtime authority, secret values, approval state. |
| Registry | Searchable index of package metadata plus immutable artifact references. | Execution authority or install trust by presence alone. |
| Marketplace | Product and governance surface over registries. | Local runtime policy, approvals, or install decisions. |
| Core plugin | Bundled or first-party package shown through the same inventory model as user-installed plugins. | Hidden privileged execution or manifest-declared bypass of runtime invariants. |
| Private plugin | Package distributed through personal-private or private-org lanes. | Public audit claims, broad trust, or cross-user secret sharing. |
Asset Families
holon-plugin/v2-core should standardize only the bounded asset families needed for the first marketplace slice.
| Asset family | Role | Notes |
|---|---|---|
skill | Reusable instructions and domain guidance. | Inert by default. |
capability-contract | Portable operation declaration, schemas, and fixtures. | Not executable until Holon binds it locally. |
adapter-binding | Future v2-core executable binding envelope with adapterKind. | Keeps lane-specific execution under one family without flattening all lanes into peer asset kinds. |
pilot-adapter | Pilot adapter descriptor with target, operations, lanes, readiness, verification, and implementation binding. | Holon-owned piloting surface. Fail-closed: only api and file_format lanes are allowed for live execution in this phase. |
mcp-descriptor | Inert MCP metadata and schemas. | Metadata is not execution trust. |
workflow | Reusable graph or playbook over capabilities, gates, and evidence. | Governed composition, not implicit authority. |
harness-profile-package | Distribution wrapper for a self-upgrade-owned profile artifact. | Marketplace transports the artifact; self-upgrade owns profile semantics. |
eval-pack | Fixtures, tasks, scoring, replay data, and expected evidence. | Validation asset, not automatic proof of safety. |
resource-pack | Non-executable templates, examples, schemas, models, or documents. | Still needs provenance, licensing, and storage review. |
provider-profile | Optional model/provider routing preset. | Must not carry secrets or policy overrides. |
Deferred Items
The following are not current implemented behavior and remain deferred:
- Remote marketplace browsing, registry sync, package signing, and authenticated private registries
- Native
holon-plugin/v2-coremanifest and storage ui-surface-extension,bridge-adapter-extension, andspecialist-harness-extensionfamilies- Executable forge outputs beyond the current bounded runtime lanes
- Activatable third-party UI or live piloting extension families (vision, browser, desktop_semantic, raw_input)
Compatibility Note
Current V1 manifests and runtime protocol use components.capabilityBindings and CapabilityBindingRecord.
capabilityBindingsis the current implementedholon-plugin/v1manifest field.CapabilityBindingRecordis the current runtime and protocol record shape.adapter-bindingis the accepted futureholon-plugin/v2-coreasset-family term.
Phase 1 canon should preserve the current V1 and runtime names while documenting adapter-binding as a future package-contract term. No runtime or manifest rename is implied by this page.
Asset Tiering
Marketplace direction should preserve explicit risk tiers:
| Tier | Posture |
|---|---|
| Tier 0 inert | Schema-valid, listable, and importable without execution authority. |
| Tier 1 governed composition | Installable or draftable, but execution still depends on bound tools and runtime policy. |
| Tier 2 bounded execution | Requires dependency probes, schemas, side-effect class, approvals, and evidence. |
| Tier 3 deferred surface code | Not activatable until a reviewed UI isolation and code-loading model exists. |
| Tier 4 deferred piloting | Partially implemented: native holon.piloting core plugin and pilot-adapter asset family are live with fail-closed lane policy. Full piloting (vision, browser, desktop_semantic, raw_input) remains deferred until lease, target binding, observation evidence, approvals, readiness, and containment exist. |
Core Plugin Model
Holon should present first-party capabilities through the same plugin inventory model used for other packages, while keeping privileged behavior modeled as host-owned runtime authority rather than manifest-granted power.
Two forms are accepted:
- Projected native core plugin: runtime-native capability projected into inventory and search through metadata.
- Bundled package core plugin: shipped package imported through the normal package path with pinning and readiness diagnostics.
Core plugin status does not allow bypass of host invariants, approvals, or evidence requirements.
Elegy Boundary
Elegy remains the portable contract substrate. Holon remains the runtime authority.
Belongs in Elegy when portability is the goal:
- capability contracts
- portable skills
- portable eval packs
- deterministic tool shapes
- compatibility metadata and fixtures
Belongs in Holon when the artifact decides local behavior:
- install state
- runtime trust
- approvals
- execution
- evidence
- dependency probing
- secrets
- workspace binding
- UI and local governance
Holon may package portable Elegy artifacts, but Holon should not create one-off marketplace rules for specific Elegy features.
Trust Vocabulary
The accepted trust-channel vocabulary is:
coreofficialaudited-publicverified-publishercommunityprivate-orgpersonal-privatelocal-draft
These are accepted classification terms, not a complete policy matrix. Install friction, activation friction, update posture, retroactive disable behavior, provenance requirements, and incident response remain later design work.
Harness Profile Ownership
Marketplace packaging may carry a harness-profile-package, but marketplace does not own profile semantics.
The following remain self-upgrade-owned concerns:
- profile schema
- non-overridable invariants
- metrics
- routing policy
- verification policy
- rollout and activation rules
Marketplace is responsible only for packaging, transport, discovery, and review surfaces around that artifact family.
Current Bounded Migration Slice
One bounded runtime-only migration slice is now implemented:
holon-plugin/v1package manifests can be translated internally to aholon-plugin/v2-core-shaped import form during runtime import.- That translation stays internal to runtime normalization and diagnostics.
- Current user-facing register, store, protocol, and inventory truth remains the V1
plugin-package/*surface andCapabilityBindingRecordnormalization target. - Fail-closed fallback to the V1 path remains required whenever translation loses fidelity, omits required translated
adapterKinddata, uses reserved or unsupported translated kinds, or would widen authority.
This does not mean native holon-plugin/v2-core package registration, storage, registry publication, or broad user-facing migration is implemented.