# Ecosystem Marketplace Unification

> **Status:** Hardened baseline
> **Owner:** `learning_ai_common_plat`
> **Purpose:** Define one marketplace model for reusable ecosystem assets across products.

---

## 1. Problem

Marketplace-like concepts already exist or are implied across the ecosystem:

- JarvisJr agent marketplace ideas
- Cowork plugin marketplace
- Note templates
- FlowMonk workflows
- ChronoMind routines
- EffoRise programs
- prompt packs, skill packs, department agents

Without one shared marketplace model:

- assets are siloed by product
- monetization is fragmented
- entitlement logic is duplicated
- creators cannot publish once and reach multiple products

---

## 2. Goal

Create one inventory and entitlement model that can support multiple asset types while allowing product-specific presentation.

---

## 3. Canonical Inventory Types

The marketplace should support at least:

- `agent`
- `plugin`
- `connector`
- `skill-pack`
- `prompt-pack`
- `workflow-template`
- `note-template`
- `routine-pack`
- `habit-program`
- `review-template`

Each listing should declare:

- `listingId`
- `inventoryType`
- `title`
- `summary`
- `publisher`
- `supportedProducts`
- `deliveryMode`
- `version`
- `entitlementModel`

---

## 4. Canonical Listing Shape

```ts
type MarketplaceListing = {
  listingId: string;
  inventoryType:
    | 'agent'
    | 'plugin'
    | 'connector'
    | 'skill-pack'
    | 'prompt-pack'
    | 'workflow-template'
    | 'note-template'
    | 'routine-pack'
    | 'habit-program'
    | 'review-template';
  title: string;
  summary: string;
  publisher: {
    publisherId: string;
    displayName: string;
    trustLevel?: 'unreviewed' | 'verified' | 'signed';
  };
  supportedProducts: string[];
  deliveryMode:
    | 'config-only'
    | 'template-bundle'
    | 'runtime-plugin'
    | 'connector-integration'
    | 'agent-pack'
    | 'prompt-bundle';
  version: string;
  compatibility: {
    minProductVersions?: Record<string, string>;
    requiredCapabilities?: string[];
  };
  entitlementModel: 'free' | 'one-time-purchase' | 'subscription' | 'org-license' | 'bundled';
};
```

---

## 5. Delivery Modes

Supported delivery modes should include:

- config-only
- document/template bundle
- runtime plugin
- connector integration
- agent behavior pack
- prompt or skill bundle

---

## 6. Entitlement Rules

Default entitlement guidance:

- ecosystem-scoped by default for reusable creator assets
- product-scoped only when the asset depends on a product-exclusive runtime or storage model
- org-scoped when the asset is purchased or managed centrally

Minimum entitlement fields:

- purchaser or owning org
- active status
- allowed products
- seats or usage limits when relevant
- start and end dates when time-bound

---

## 7. Compatibility And Review Rules

- listings should declare supported products explicitly
- compatibility should be version-aware where runtime behavior matters
- executable assets should support review or signing state
- templates may allow lighter review than runtime plugins or connectors

---

## 8. Phase-1 Scope

Start with these inventory types:

- [x] `plugin`
- [x] `workflow-template`
- [x] `note-template`
- [x] `routine-pack`
- [x] `skill-pack`

These map directly to existing ecosystem capabilities.

---

## 9. First Adopters

1. `oss/learning_ai_claw-cowork`
2. `learning_ai_flowmonk`
3. `learning_ai_notes`
4. `learning_ai_clock`
5. `learning_ai_jarvis_jr`

---

## 10. Marketplace Inventory Mapping

- Cowork marketplace items map primarily to:
  - `plugin`
  - `connector`
  - `agent`
- FlowMonk reusable planning assets map primarily to:
  - `workflow-template`
  - `routine-pack`
- NoteLett reusable content assets map primarily to:
  - `note-template`
  - `review-template`
- JarvisJr reusable execution assets map primarily to:
  - `agent`
  - `skill-pack`
  - `prompt-pack`

---

## 11. Open Decisions

1. Should one listing support multiple delivery modes?
2. How should version compatibility be represented when a listing supports many products with uneven capability sets?
3. Which assets require review/signing before distribution?
4. Should orgs be able to hide public listings and allow only approved inventories internally?

---

## 12. Acceptance Criteria

1. One creator asset can target more than one product.
2. Platform entitlements can gate access without per-product duplication.
3. Cowork marketplace assets can map into the shared listing model.
4. Product-specific presentation does not require product-specific listing storage.
5. Review/signing state is available for executable assets.

---

## 13. Implementation Checklist

- [x] define canonical listing schema
- [x] define inventory type taxonomy
- [x] define entitlement model
- [x] define compatibility/version model
- [x] define phase-1 publishing workflow
- [x] define review/signing requirements
- [ ] define org-curated/private marketplace overlay rules

Commits:

- `7a86a76` drafted the initial version
- `617d970` tracked marketplace hardening as remaining work
