Plugin-Marketplace

Status: backlog: Plugin-System (Phase 06) vollständig in Production + nachweisbarer Product-Market-Fit der Boilerplate + spürbarer Bedarf nach Drittentwickler-Ökosystem (mind. 3 externe Devs fragen aktiv nach Distributionskanal) Task-ID: #24 Phase: 11 (Backlog) Estimated Effort: 6-8 Wochen wenn aktiviert Owner: unassigned

Problem

Sobald Phase 06 (WASM-Sandbox + Hooks-Lifecycle) live ist, können Tenants Plugins lokal installieren — aber es gibt keinen Weg, sie öffentlich anzubieten, zu entdecken, zu monetarisieren. Ohne Marketplace gibt es keinen Anreiz für Dritt-Entwickler, Plugins zu schreiben, und kein Discovery-Kanal für Tenants. Das Plugin-System bleibt damit nur eine interne Erweiterungs-Schicht statt ein Ökosystem-Hebel.

Aktivierung lohnt sich erst, wenn die Boilerplate genug Tenants hat, dass ein Plugin-Marketplace wirtschaftlich wird — sonst sind die ~6-8 Wochen Aufwand + die laufenden Review-/Moderation-Kosten verbrannt.

Depends on

../06-plugin-system/wasm-sandbox.md — Plugin-Runtime + Signaturprüfung müssen stehen
../06-plugin-system/hooks-lifecycle.md — Lifecycle-Events + Versions-Pinning müssen stehen
../06-plugin-system/audit-docs.md — Plugin-Manifest-Schema + Audit-Anforderungen müssen dokumentiert sein
../05-business-features/feature-flags.md — Marketplace-Listing-Flags pro Plugin (z.B. Beta-Phase)
../05-business-features/ai-cost-phase-3.md — Pricing-Backbone wird für Paid-Plugins wiederverwendet

Blocks

nichts (Backlog-Item, blockt keine aktive Roadmap)

Approach

Eigene Marketplace-Site als zweite App-Instanz (eigener Tenant auf eigener Plattform). Begründung gegen Alternativen:

In-App-Marketplace innerhalb der Boilerplate: würde die Tenant-Isolation verwässern (Publisher-Accounts wären cross-tenant) und Admin-Panel mit Marketplace-Verwaltung überfrachten. Verworfen.
Externe SaaS-Marketplace (z.B. ähnlich Stripe Apps): zu viel Vendor-Lock-in für eine self-hosted-first Boilerplate. Verworfen.
Eigener Tenant auf der gleichen Boilerplate-Plattform: dogfooded das Tenant-System, nutzt Auth/Billing/Search/Audit-Infra die bereits da ist, klare Trennung zwischen Marketplace-Operator und Tenants.

Publisher-Onboarding generiert pro Publisher ein Ed25519-Keypair (Private-Key bleibt nur beim Publisher, Public-Key im Marketplace + jedem ausgelieferten Plugin-Manifest). Plugin-Signaturprüfung erfolgt offline beim Install ohne Marketplace-Roundtrip.

Submission-Flow: Publisher lädt signiertes .wasm + manifest.json hoch → Marketplace führt automatisierte Static-Analysis (Capability-Whitelist-Check, Manifest-Schema-Validation, AV-Scan via Phase-01-Layer-1+2) durch → manuelle Review-Pipeline (Marketplace-Operator) bevor Listing live geht. Spätere Iteration: mehr Auto-Approval bei verifizierten Publishern.

Pricing: Free, One-Time-Purchase, Subscription. Subscription-Plugins nutzen Stripe-Connect-Splits (Default 70/30 Publisher/Plattform, pro Plugin konfigurierbar). Tenant-Install pinnt Plugin-Version + öffnet Subscription bei Stripe-Connect-Account des Publishers.

Update-Pipeline: Publisher published neue Version → Marketplace-Backend prüft semver-Kompatibilität → Notifications an alle installierten Tenants (Email + In-App). Auto-Update nur für PATCH-Versions opt-in, MAJOR/MINOR immer manual-confirm pro Tenant.

Implementation Steps

Marketplace-Tenant-Setup — eigene Subdomain marketplace.<domain>, Boilerplate-Stack mit eigener DB, Branding-Theme. Commit: 11-backlog/plugin-marketplace: bootstrap marketplace tenant
Publisher-Onboarding + Ed25519-Keys — Publisher-Account-Modell, Key-Generierung im Browser (WebCrypto), Public-Key-Storage. Commit: 11-backlog/plugin-marketplace: add publisher onboarding with ed25519
Plugin-Submission-Flow — Upload-UI, Static-Analysis-Pipeline (Capability-Check, Manifest-Validation, AV-Scan), Review-Queue für Marketplace-Operator. Commit: 11-backlog/plugin-marketplace: submission + review pipeline
Public Listing-UI — Such-Index (Meilisearch aus Phase 04), Ratings (1-5 Sterne + Review-Text), Screenshots, Pricing-Anzeige, Capability-Liste. Commit: 11-backlog/plugin-marketplace: public listing pages
Stripe-Connect-Integration — Connect-Account-Onboarding pro Publisher, application_fee_amount + transfer_data.destination für Splits, Subscription-Plugins als Stripe-Subscription mit Publisher als Destination-Account. Commit: 11-backlog/plugin-marketplace: stripe connect + revenue splits
Tenant-Side Install-Flow — von Marketplace via Deep-Link in Tenant-Admin → Signature-Verify → Subscription-Confirm → Plugin-Aktivierung mit Capability-Consent-Screen. Commit: 11-backlog/plugin-marketplace: tenant install flow with consent
Update-Pipeline + Notifications — Version-Diff-Anzeige, Notification via Email + Bell-Icon, opt-in Auto-Patch, Rollback-Button für Tenants. Commit: 11-backlog/plugin-marketplace: update pipeline + notifications
Doku — docs/marketplace/publisher-guide.md, docs/marketplace/operator-runbook.md (Review-Standards, Sperren von Plugins, Refund-Handling). Commit: 11-backlog/plugin-marketplace: documentation

Test Requirements

Unit-Tests: Signaturprüfung (Ed25519 sign/verify mit bekannten Vektoren), Manifest-Schema-Validation, Revenue-Split-Berechnung, Semver-Diff-Logik
Integration-Tests: Submission-Flow End-to-End (Upload → Analysis → Approve → Listing), Install-Flow (Listing → Stripe-Checkout → Tenant-Aktivierung), Update-Notification-Fan-out
E2E-Tests (Playwright): Publisher-Onboarding, Submit-Plugin-Happy-Path, Tenant-Install + Capability-Consent, Subscription-Cancel mit Stripe-Webhook-Simulation
Coverage-Target: ≥75% für Marketplace-spezifische Pakete (apps/marketplace/, neue Module unter app/modules/marketplace/)
Test-Files: neben Source-Files (*.test.ts), E2E unter apps/marketplace/playwright/

NICHT als completed markieren bevor alle Tests grün sind.

Acceptance Criteria

Marketplace erreichbar unter eigener Subdomain mit eigener Tenant-Datenbank
Publisher kann sich registrieren, Ed25519-Keypair generieren und ein erstes Plugin submitten
Review-Queue im Marketplace-Admin-Panel funktional, mit Approve/Reject + Begründung
Stripe-Connect-Onboarding für Publisher abgeschlossen, KYC-Status sichtbar
Subscription-Plugin kann gekauft werden, Splits werden korrekt verbucht (70/30 default)
Tenant kann Plugin installieren, sieht Capability-Consent-Screen, Plugin läuft in WASM-Sandbox
Update-Notification erreicht Tenants binnen 5 Minuten nach Publish
Rollback eines aktualisierten Plugins pro Tenant funktioniert
Tests grün (lint, typecheck, unit, integration, e2e)
Docs docs/marketplace/publisher-guide.md + docs/marketplace/operator-runbook.md angelegt
Progress-Log + PROGRESS.md aktualisiert

Rollback Strategy

Marketplace ist eine eigene App-Instanz — Take-down ohne Auswirkung auf andere Tenants möglich
Feature-Flag marketplace.public_listings_enabled schaltet öffentliche Sichtbarkeit ab, ohne dass bereits installierte Plugins betroffen sind
Stripe-Connect-Onboarding kann pausiert werden, neue Subscriptions verhindert; bestehende laufen ungestört weiter
DB-Migration: alle Marketplace-Tables haben prefix mp_, einfacher Drop möglich

Security Notes

Ed25519-Private-Keys verlassen nie den Publisher-Browser, Storage-Empfehlung (Hardware-Token / Password-Manager) im Publisher-Guide
Plugin-Manifest muss Capabilities explizit listen — Marketplace-Review verifiziert, dass die deklarierten Capabilities dem WASM-Modul-Verhalten entsprechen (statische Analyse + Stichproben-Dynamic-Test)
AV-Scan (Phase 01) ist Pflicht für jeden Upload
Stripe-Connect: application_fee_amount und transfer_data.destination müssen serverseitig validiert sein (kein Client-Tampering)
Capability-Consent-Screen muss Capabilities in verständlicher Sprache erklären, nicht nur als Manifest-Keys
Plugin-Revocation: Marketplace kann signiertes Revocation-Statement broadcasten, das Tenants beim nächsten Plugin-Load durchsetzen (Kill-Switch für kompromittierte Plugins)

Subagent Recommendations

Planning: Plan-Subagent mit dieser MD + Phase-06-Outputs als Input
Research: Explore-Subagent für Stripe-Connect-Best-Practices und Plugin-Marketplace-Prior-Art (VSCode-Marketplace, Stripe-Apps, Shopify-Apps)
Implementation: ein general-purpose-Subagent pro Step (8 Subagents über die Phase)
Tests: separater general-purpose-Subagent pro Test-Block (unit/integration/e2e separat)
Verification: gsd-verifier für jede Acceptance-Criteria-Gruppe
Code-Review: gsd-code-reviewer nach jedem Step, finaler Phase-Review nach Schritt 8

Staging-Deployment-Steps

Branch agent/11-backlog-plugin-marketplace pushen
Coolify deployed Marketplace-App als zweite Stack-Instanz auf Hetzner
Stripe-Connect im Test-Mode mit Test-Keys verkabeln
Mit Test-Publisher-Account ein Test-Plugin durch den kompletten Flow schicken
Tenant-Install + Subscription + Cancel verifizieren

Deviations from Plan

(Wird vom ausführenden Agent gefüllt.)

Progress Log