Plugin submission verify pipeline via GitHub Actions (reusable workflow + catalog gate)

[ReBoticsAI]

Goal

Use GitHub Actions as disposable verification VMs for marketplace plugin submissions, so community/SaaS sellers cannot list a plugin until a pinned commit has passed an isolated build (and optional GodMode smoke) on GitHub-hosted runners.

This repo (GodMode-Marketplace) owns catalog gates, CONTRIBUTING requirements, and reusable workflows. GodMode core remains the runtime install host; it should later consume pinned refs/digests from verified listings (follow-up in GodMode if needed). Related design discussion: ReBoticsAI/GodMode#172 (VM-grade isolation deferred in favor of GitHub intake).

Why here (not GodMode core)

• Catalog PRs, pluginRepo / pluginRef policy, and submission CONTRIBUTING live in this repo today
• Public plugin repos get free Actions minutes; Marketplace can publish a reusable workflow sellers call
• Core OSS stays free of marketplace intake orchestration; Bridge only needs to honor pins at install time

Design (locked intent from GodMode #112 hardening discussion)

Plugin public GitHub repo @ immutable SHA
  → reusable workflow (Marketplace) on ubuntu-latest (isolated VM)
  → build against pinned GodMode package/image
  → optional: docker smoke (boot GodMode, install plugin, health)
  → attest green run + artifact hash
  → catalog / publish gate requires that SHA + proof
  → Bridge installs pinned ref/asset (not floating main)

This is verification-time isolation (same class as a review VM). It is not a substitute for runtime plugin permissions on buyer Bridges.

Proposed deliverables

1. Reusable workflow under .github/workflows/ (e.g. plugin-verify.yml or reusable-plugin-verify.yml) that plugin repos can uses:

   • Checkout plugin at caller SHA
   • Pin GodMode core (tag/image or packages/plugin-api contract)
   • npm ci / esbuild (or documented build script)
   • Validate godmode.plugin.json (kernelApiVersion, entries)
   • Optional job: compose/run GodMode + install plugin + /api/health smoke
   • Output: checksum of built dist (or release asset)

2. CONTRIBUTING + catalog policy

   • installType: "plugin" requires public pluginRepo
   • pluginRef must be tag or commit SHA (discourage floating main for Official/Community sell)
   • PR / publish checklist: linked green Actions run for that ref
   • Update note that today''s npm run validate still does not fetch pluginRepo (replace with this gate)

3. Catalog / listing metadata (schema + examples)

   • Store pluginRef (SHA), optional artifactSha256, ciRunUrl / attestation
   • Fail closed on catalog validate if plugin entry lacks pin + verify proof (phase in)

4. Docs

   • Seller guide: add workflow to plugin repo, cut release/tag, open Marketplace PR / publish
   • Clarify: CI VM verifies submission; buyers still get Bridge runtime trust model

Acceptance

• Reusable Actions workflow exists in this repo and is documented for sellers
• CONTRIBUTING requires public repo + pinned ref + green verify for new plugin entries
• Catalog schema/validator (or CI) can reject unpinned / unverified plugin submissions
• At least one example plugin repo (or docs fixture) shows the uses: pattern
• Explicit note: does not replace runtime sandboxing on GodMode Bridge

Out of scope

• Firecracker / first-party VMs on SaaS hubs (GodMode #172)
• Windows/Sierra native DLL verify pipelines
• Changing Stripe/commerce flows
• Softening GodMode Layer 1–4 authoring isolation

Follow-ups (GodMode core, separate issues)

• Install path honors pinned pluginRef / release asset digest (no drift to main)
• Optional: SaaS Community publish API checks GitHub Check Suite for the SHA before MarketplaceListing.publish

References

• GodMode epic isolation: SaaS coding isolation: tenant worktrees, sandboxed shell, optional build containers GodMode#112
• VM-grade design (defer / GitHub intake): Design: path to Cursor-Cloud-like VM-grade coding isolation GodMode#172
• Current CONTRIBUTING gap: marketplace validate does not fetch or build pluginRepo

[ReBoticsAI]

Buyer protection (companion to this intake gate)

This issue = verification before listing. It does not fully protect buyer runs installed plugin.

How we protect buyers (layered)

1. Intake gate (this issue) — public repo, pinned SHA, green Actions (+ optional GodMode smoke)
2. Pinned install (GodMode core follow-up) — Bridge installs that SHA/artifact only; no drift to main
3. Runtime capability / least privilege (GodMode core) — limit plugin network, tools/shell, record scope; confirmations for dangerous actions; CSP for plugin web
4. Trust tiers — Official vs Community, verified publisher, revoke/kill switch (#96)
5. True plugin runtime sandbox (optional later) — run plugin code in a separate process/container on the buyer hub, not only test it once in CI

Extending smoke tests / Copilot in CI

Worth doing as defense in depth on this pipeline:

• Broader smoke: multi-tenant fixture, deny unexpected egress, exercise install/uninstall
• Static checks: audit:oss-style, dependency audit, block obvious child_process / raw fetch patterns if policy says so
• Optional: Copilot/code-scanning PR review on the plugin repo

Limits: smoke and LLM review raise the bar; they cannot prove absence of malice (time bombs, env-gated exfil, abuse of allowed APIs). Those need runtime least privilege on Bridge (# GodMode companion issue).

CI smoke vs true runtime sandbox

	GitHub verify VM (this issue)	Buyer Bridge today	True plugin runtime sandbox
When	Once at submit	Every install/use	Every install/use
Data	Empty fixtures	Real tenant data	Real tenant data, stronger boundary
Goal	Broken/malformed/out	Plugin must work	Limit blast radius if plugin is evil

Companion core issue: (will link after filing)

[ReBoticsAI]

Core companion (buyer runtime / pins / least privilege): ReBoticsAI/GodMode#177

[ReBoticsAI]

Tracked from GodMode #180 (marketplace intake + buyer protection). Priority 3 on the SaaS coding scale path after #178/#179.