# M2 Marketplace — Unified Concept Paper

*Version 0.2 — 2026-07-01. Merges the M2 Platform Concept v0.1 (pitch + long-form), the
fedlearn-rails extension (v0.2 supersedes the earlier CONCEPT.md, see git history), the
existing **cargstore** asset, and the **Solution Scout** in-session proposal agent.*

---

## 0. One line

**M2 is a work store**: operators package repeatable outcomes as installable **Solutions**,
sell them to other operators for **M2 credits**, and an in-session **Solution Scout** proposes
the right package at the exact moment an operator needs it — few clicks to deployed.

---

## 1. Problem (compressed)

AI work is rebuilt from scratch: good sessions disappear into chat history; supply (skills,
tools, GPUs, operators, agencies) is fragmented; nobody remembers whether a request is a
10-minute job, a 2-day build, or already-solved inventory. The missing product is a system
that **remembers, packages, routes, prices, and sells repeatable work.**

## 2. Primitives

**Solution** — the sellable unit. An installable bundle of:
`intent + agent behavior (prompts/skills/playbooks) + tools (MCP/APIs/connectors) + runtime
(Hermes/desktop/browser/Guacamole/OpenClaw) + memory schema + permissions + deployment recipe
+ price + evidence`.

**Capability** — a repeatable kind of work (bookkeeping, agentic ops, sales work, marketing
audits, creative build, analysis, support). Capability is the supply; Solution is the packaged
outcome; Hermes composes both.

**Four inventory types in one catalog:**

| Type | What | Examples |
|---|---|---|
| Solutions | packaged outcomes | eBay listing workflow, bookkeeping flow, competitor scan |
| Capabilities | repeatable work categories | bookkeeping, research, support, creative |
| Resources | capacity M2 can spend against | GPUs, model endpoints, browser sessions, vision workers, hosting |
| Services | human/operator/agency units | setup, audit, migration, design pass, website build |

The buyer never thinks in these terms — they describe the outcome; M2 composes inventory.

---

## 3. What we already have (the asset map)

This is the decisive point: **almost every component already exists in our stack.** The
marketplace is an assembly job, not a greenfield build.

| Marketplace component | Existing asset | Gap to close |
|---|---|---|
| **Package format + registry of record** | fedlearn `m2-core-manifest` + artifacts in Forgejo `m2/m2-core` (MVP in execution NOW) | `solution.schema.json` superset: price, seller, license, revenue split |
| **Install path** (signed, idempotent, role/tenant-aware) | `m2-core-sync` / `m2-core pull --apply` + state.json (fedlearn W4) | pre-install ledger debit + license grant |
| **Semantic catalog + search** | memory-api/Qdrant, `fedlearn:core-index` partition | `market:catalog` partition; listing records |
| **Pricing evidence** ("10 min or 2 days?") | fedlearn submissions carry provenance (machine, session, herdr runs, tokens/time) | aggregate per-job cost telemetry onto listings |
| **Trust/curation pipeline** | auto-curate → scored PR → human veto → merge | third disposition: `commercialize`; listing review = same PR/veto |
| **Storefront UI (in-desktop)** | **cargstore** (github.com/machine-machine/cargstore): Electron+React store, JSON catalog, one-click install, persistent-volume storage, WebSocket agent integration, update manager, `web/` variant | swap Flatpak backend for Solution installs; point catalog at `market:catalog`; rebrand Clawdbot→M2 |
| **Conversational surface / proposal engine** | Hermes baked into every primus desktop; m2-memory skill for similar-work recall | `market-propose` skill (search + cost-estimate + build-vs-install paths) |
| **In-the-moment discovery** | herdr (session/lifecycle awareness, baked fleet-wide), openclaw session events | **Solution Scout** agent (§5) |
| **Execution surfaces** | m2o desktops (Guacamole VNC/RDP), embeddable workspace, herdr worker herds | permission modes: observe/suggest/take-control/hand-back |
| **Identity + tenancy** | fleet.json + tenant map (sdjs→gst, …), operator = human over N machines | `operator_id` + wallet |
| **Payments rail (internal)** | m2-gpt gateway already meters tokens/tenants | `m2-ledger` (small append-only credit service) — the one genuinely new component |
| **Distribution to mixed fleet** | fedlearn propagation design (bake vs runtime-sync vs config) | none — Solutions ride runtime-sync |

**Cargstore verdict:** don't build a new storefront — *evolve cargstore into the M2 Store*.
Its catalog schema (`id/name/summary/category/icon/featured/keywords` + install ref) maps
1:1 onto Solution listings; its install manager + persistent-volume pattern is exactly the
Solution deployment UX; its agent WebSocket channel is the hook the Scout needs to deep-link
"install this" proposals. The `web/` variant seeds the browser-facing marketplace later.

## 4. Where the marketplace lives (options considered)

| Option | Verdict |
|---|---|
| (a) **Cargstore evolution** — in-desktop store app | ✅ the *storefront surface*, not the system of record |
| (b) **Forgejo-native** — repos/releases as registry, PRs as review | ✅ the *registry of record* (versioned, signed, veto-gated) |
| (c) **memory-api catalog** — Qdrant partition + CLI | ✅ the *semantic index* (search/recommend), never the truth |
| (d) Hosted web marketplace (public site) | later — grows out of cargstore `web/` once inventory exists |
| (e) Third-party (npm-style registry, Stripe store) | ❌ loses the memory/evidence moat and tenant model |

**Answer: the marketplace is a protocol + registry, not one app.** Forgejo holds truth
(listings = repo releases, review = PRs, veto = labels); memory indexes it for meaning;
cargstore renders it in the desktop; Hermes + the Scout speak it in-session; the CLI
(`m2-market`) automates it. Same layering that won for fedlearn (git = truth, memory = index)
— one architecture, two tiers (free core / paid market).

---

## 5. The Solution Scout (in-session proposal agent)

The user's envisioned moment: *an operator is mid-session, starts building something a
Solution already solves — and an agent proposes the link right then; few clicks; deployed.*

**Mechanics (all existing rails):**

1. **Watch** — the Scout runs per-desktop (supervised, like hermes-gateway). Inputs, in
   privacy order: herdr lifecycle/run summaries (already structured), Hermes/OpenClaw session
   summaries, optionally window titles. **Never raw keystrokes; never raw client data.**
2. **Match** — periodically (or on "agent started working on X" events) embed the current
   intent summary and query `market:catalog` semantically (same BGE-M3 path as memory recall).
   Matching runs against tenant-allowed listings only.
3. **Propose** — on a high-confidence hit, a non-blocking toast (herdr notification or XFCE
   notify) + a cargstore **deep link**: *"This looks like 'eBay Listing Workflow' (12 installs,
   ★4.6, ~70% coverage, 40 credits). Install?"* Also surfaced in Hermes chat if that's the
   active channel.
4. **Deploy** — click → cargstore Solution page (evidence, price, permissions diff) →
   *Install* → ledger debit → license grant → `m2-core-sync` applies the bundle → Scout
   reports back "installed, here's how to invoke it."
5. **Learn** — accepted/dismissed proposals feed back as evidence (proposal→install
   conversion is a listing quality signal; dismissals tune the Scout's threshold).

**Guardrails:** opt-in per desktop (`pull-policy.toml`), rate-limited (max N proposals/day),
tenant-scoped matching, on-box summarization before anything leaves the machine, and the
Scout can only *propose* — the install click is always the human's.

This is the marketplace's demand-side engine: instead of hoping operators browse a store,
the store meets them at the moment of need.

## 6. Hermes as proposal engine (pull-side complement to the Scout)

The Scout is push-in-the-moment; Hermes is pull-on-request. User: *"I want to automate my
eBay listing process."* Hermes: searches memory (similar past work + real cost) and the
catalog (Solutions/Capabilities/Resources/Services), then proposes paths **with evidence**:

> "From scratch: ~2 days / ~8M tokens. Existing inventory covers ~70%: browser automation,
> listing workflow, product image generation. Three paths: install+adapt (40 cr, today),
> operator-assisted (120 cr, 2 days), full custom (est. 300 cr, 1 week)."

Approve → agents/operators/resources execute → completed work becomes new evidence and,
where repeatable, new inventory. **Every serious job leaves behind:** what was wanted, tools
used, who contributed, tokens/time/resources spent, what failed/succeeded, and whether a
Solution/Capability should be created or updated. That record is the pricing intelligence —
and the moat (§10).

---

## 7. Economy — M2 Credits

- **Internal ledger first** (`m2-ledger`: append-only tx `{ts, from, to, amount, reason:
  install|payout|grant|route|earn, ref}`, balances derived, X-API-Key auth, daily balance
  snapshot committed to Forgejo for audit). **No public coin/exchange** until worth the
  legal/tax/custody/fraud complexity.
- **Actors:** users buy outcomes · builders publish · operators deliver · resource owners
  sell capacity · agents spend within budgets. One identity may be several.
- **Value routing:** install → debit buyer, credit seller minus platform cut (default 10%,
  configurable). Operator work and resource usage settle through the same ledger. Payouts
  manually reconciled at first.
- **Earning credits** (participant economy): publishing reusable Solutions, testing Solutions,
  structured feedback, data labeling, paid surveys, contributing resources. Bootstrap: starter
  grants to active operators; platform earns cut only.
- **Agent budgets:** agents spend credits within operator-set budgets (m2-gpt gateway already
  meters tokens per tenant — the ledger federates with it rather than duplicating).

## 8. Resource & infrastructure marketplace

Spare capacity we already run (GPU boxes, spark nodes, vision/generation workers, browser
sessions, hosting) becomes internal supply: an agent needing batch visual checks routes to
internal vision workers instead of a random external API. Priced in credits through the same
ledger; listed as `Resource` inventory in the same catalog.

## 9. Co-driving workspace (the visible wedge)

The embeddable remote workspace — Guacamole/VNC/browser desktop + M2 side pane + shared
context — with permission modes **observe / suggest / take control / hand back**. Not the
platform; one execution surface. Example: a bookkeeping Solution opens the desktop, logs into
a portal, extracts documents, asks approval, hands back a report. Our m2o gateway + primus
fleet + RDP/VNC standard *is* this wedge's infrastructure, already live.

## 10. Positioning, moat, operators

- **Not** an app store / plugin market / cloud marketplace / agency / agent framework — parts
  of all: **a work store.** Buyers buy completed work; the unit is not software, it's outcomes.
- **Moat:** accumulated operational memory + packaged inventory + cost history + operator
  network + deployment/permission layer + credit economy. Each completed job strengthens
  future proposals — the compounding loop.
- **Operators & multiple M2s:** an operator runs personal/client/specialist M2 instances and
  fleets of agents; delivers client jobs; packages the repeatable ones back into the
  marketplace. `Client job → delivered → packaged → reused → operator earns from future use.`

## 11. Free core vs paid market (the boundary)

Fleet-standard infra learnings (Xorg self-heal, RDP standard, …) stay **free in shared
m2-core** — the commons that keeps the fleet healthy. Outcome-shaped packages become priced
Solutions. Curation gains a third disposition: `promote-to-core (free) | commercialize (list)
| reject/park`. Tenant-derived work can be commercialized **only** owner-initiated and
doubly-scrubbed; raw client data never crosses the tenant firewall.

---

## 12. First wedge (concrete, on our fleet)

Sequenced behind the fedlearn MVP (its rails are the dependency — in herd execution now):

1. **Schemas:** `solution.schema.json` + `listing.schema.json` (manifest superset; frozen v1).
2. **`m2-ledger`** on the host (SQLite, API, starter grants, platform cut, snapshot-to-git).
3. **Curation `commercialize` disposition** + listing PR template (evidence + price +
   permissions + rollback), riding the existing veto pipeline.
4. **`market:catalog`** partition + `m2-market search|show|install` CLI (install = ledger tx →
   existing sync/apply).
5. **Cargstore revival:** point catalog at `market:catalog`, add a Solution install backend
   beside Flatpak, rebrand → **M2 Store**; deploy on canaries (chris-m2o, gunnar-m2o).
6. **Package 3–5 real Solutions** from proven outcomes: mm-pdf branded-report generator,
   agent-scaffold workspace generator, competitor-scan report, client-site template,
   bookkeeping document assistant.
7. **Solution Scout v0** on one canary: herdr-run summaries → catalog match → toast + deep
   link (propose-only, opt-in).
8. **One real paid install** between two operators (e.g. m2bd buys sdjs-operator's package).

**Success:** a Solution listed with evidence → discovered via Scout or Hermes → bought with
credits → installed through the standard apply path → ledger reflects it → install telemetry
lands back in memory as pricing evidence. The loop closes commercially once.

## 13. Top risks

| Risk | Mitigation |
|---|---|
| Commons erosion (everything monetizes) | policy: fleet-infra learnings always free; curation enforces boundary |
| Client-data leakage via productization | owner-initiated only, double scrub, tenant firewall unchanged |
| Junk/fake listings | provenance refs required; PR/veto review; ratings + conversion signals on listings |
| Scout = surveillance creep | opt-in, on-box summarization, no raw keystrokes, rate-limited, propose-only |
| Ledger trust | append-only + daily snapshot to Forgejo; internal-only scope |
| Two-sided cold start | seed supply from our own proven outcomes; Scout drives demand at moment of need; starter grants |

## 14. Open forks (operator decisions)

1. **Ledger substrate:** standalone `m2-ledger` (recommended) vs extend m2-gpt gateway billing vs Forgejo-as-ledger.
2. **Pricing v1:** fixed per install (recommended) vs metered vs both.
3. **Cargstore path:** revive as Electron in-desktop store (recommended) vs web-first vs both at once.
4. **Scout host:** standalone supervised watcher (recommended) vs Hermes plugin vs herdr plugin.
5. **First Solutions to package** (proposed: mm-pdf, agent-scaffold, competitor-scan).
6. **Platform cut % + starter grant size** (defaults: 10%, 100 cr).

## 15. The simple story

- **Customers:** "Tell M2 what you want done. It finds what exists, estimates cost, proposes the best path, executes."
- **Builders:** "Package repeatable work once. Earn whenever M2 routes demand to it."
- **Operators:** "Deploy outcomes faster; every successful project becomes sellable inventory."
- **Resource owners:** "Offer spare compute/models/workers as routable capacity."
- **M2:** "Every job makes the platform smarter, cheaper, and more valuable."