docs: capture exploration — plugin marketplace (note, research question, Phase 34)

.planning/ROADMAP.md

@@ -1720,6 +1720,26 @@ Plans:
 **Wave 9** *(blocked on Wave 8 completion)*
 - [ ] 33-14-PLAN.md — unit tests, check-phase33.sh --all, release tags in order, app re-pins, changelog post
 
+### Phase 34: Plugin marketplace
+
+**Goal:** People browse the public Golem15 plugins at summercms.io/marketplace and add one to their application with a single command, `summer plugin:install <id>`. The same command installs private plugins straight from a git URL without contacting summercms.io. The admin SPA gains a read-only Plugins screen listing installed plugins and searching the marketplace, which shows the install command with a copy button. v1 has no paid plugins, no developer registration and no installs from the admin panel.
+**Requirements**: TBD
+**Depends on:** Nothing technical; ordered after Phase 33
+**Repos:** `summercms.go` (manifest spec and validation, `plugin:install`, cabana Plugins screen and boardwalk views), `sm-summercmsio-app` and its `golem15.summercms` site plugin (registry API, ingestion, admin presentation fields), `vue-summercmsio-app` (marketplace pages), and a `plugin.yaml` in each public `sm-*-plugin` repo.
+**Context:** decisions in `.planning/notes/2026-10-29-plugin-marketplace.md`; open question on `--module` for private git URLs in `.planning/research/questions.md`.
+**Success Criteria** (what must be TRUE):
+
+  1. Every public `sm-*-plugin` repo carries a `plugin.yaml` manifest (ID, module path, name, description, required framework version, required plugins) that the framework validates, and anyone can fetch the repo anonymously.
+  2. summercms.io ingests manifest, README and versions when a plugin is tagged, serves them through a registry API, and renders /marketplace with list, search, category and detail pages; category, featured, screenshots and icon are edited in the summercms.io admin.
+  3. `summer plugin:install golem15.<name>` resolves the plugin through the registry and installs it as a Go module (`--source` checks it out as a submodule); `summer plugin:install <git-url>` installs from the repo alone as a submodule. Both register the plugin like `plugin:add` and check framework and plugin requirements.
+  4. The admin Plugins screen lists installed plugins with versions and available updates, and its Marketplace tab searches the registry and shows the install command with a copy button.
+  5. The new code has unit tests, delivered in the phase's last plan.
+
+**Plans:** 0 plans
+
+Plans:
+- [ ] TBD (run /msd-plan-phase 34 to break down)
+
 ## Progress
 
 **Execution Order:**
@@ -1775,6 +1795,7 @@ Phases execute in numeric order: 1 → 2 → 3 → 4 → 5 → 6 → 7 → 8 →
 | 31. Chat polish against WavePath clients | 0/TBD | Not started | - |
 | 32. SEO foundation | 6/6 | In Progress|  |
 | 33. SEO output, audit and content | 0/14 | Planned | - |
+| 34. Plugin marketplace | 0/0 | Not started | - |
 
 ## Backlog
 

.planning/notes/2026-10-29-plugin-marketplace.md

@@ -0,0 +1,44 @@
+# Decision: Plugin marketplace on summercms.io and `summer plugin:install`
+
+**Date:** 2026-10-29  
+**Status:** Accepted (exploration)  
+**Context:** `/msd-explore` session on summercms.io/marketplace, modelled on octobercms.com/marketplace
+
+## Scope of v1
+
+- The marketplace lists the public Golem15 plugins (`sm-*-plugin` repos that stay public). No paid plugins and no developer registration: Golem15 publishes every listing.
+- Its job is browsing plugins and getting the install command, nothing more.
+
+## Decisions
+
+### Listing data: facts in the repo, presentation on summercms.io
+
+- Each plugin repo carries a `plugin.yaml` manifest next to `plugin.go`: plugin ID, module path, name, description, required framework version, required plugins. The README and git tags (`vX.Y.Z`) complete the facts.
+- summercms.io ingests the manifest, README and tags when a plugin is tagged. The hook is the existing `scripts/changelog-post.py publish … --repo ../sm-<name>-plugin` step or a webhook.
+- Presentation fields (category, featured flag, screenshots, icon, sort order) are edited in the summercms.io admin, in the `golem15.summercms` site plugin.
+- Reason: install-critical data (module path, versions, requirements) cannot drift from the repo, while marketing details change without a plugin release. A repo manifest also leaves room for third-party submissions later (submit a repo URL).
+
+### `summer plugin:install`
+
+The form of the argument decides where the plugin comes from:
+
+| Argument | Lookup | Default install mode | Override |
+|----------|--------|----------------------|----------|
+| Plugin ID, e.g. `golem15.journal` | summercms.io registry API: module path, versions, requirements | Go module (`require` in `go.mod`, `go mod download`) | `--source`: git submodule checkout at `plugins/<vendor>/<name>`, as `plugin:add` does today |
+| Git URL, e.g. `git@github.com:acme/sm-servers-plugin.git` | None. summercms.io is never contacted. ID and requirements come from the repo's `plugin.yaml`, module path from its `go.mod` | Git submodule checkout, which reuses the SSH access the user already has | `--module` (see the open research question on private modules) |
+
+- Git URLs cover closed or private plugins from repositories the user has access to.
+- Both modes end with the same registration that `plugin:add` does (`summer.yaml`, `go.mod`, `go.work` where applicable), then `summer build`.
+- Precondition: public plugin repos on git.golem15.com fetch anonymously (HTTPS clone and `?go-get=1` meta). Confirmed as the intent for public plugins on 2026-10-29.
+
+### Admin "Plugins" screen (read-only)
+
+- **Installed** tab: the activated plugins from `backpack.App`, with version and description, and updates available compared against the registry.
+- **Marketplace** tab: searches the summercms.io registry and shows `summer plugin:install <id>` with a copy button. There is no install button.
+- The running binary never installs plugins. Plugins are compiled in; runtime loading stays rejected (`why-go-not-scala.md`, `.planning/research/FEATURES.md` anti-features). Queued installs and dev-mode live installs were considered and dropped as unnecessary for v1.
+
+## Out of scope for v1
+
+- Paid plugins, licensing, developer accounts and submissions.
+- Themes in the marketplace.
+- Installing from the admin panel.

.planning/phases/34-plugin-marketplace/.gitkeep

@@ -0,0 +1 @@
+

.planning/research/questions.md

@@ -12,3 +12,7 @@
 
 - **Should the full OIDC provider extend the hand-written `wristband` server, or put zitadel/oidc v3 behind it?** Phase 8 hand-wrote `wristband` on the standard library (`.planning/notes/oauth2-wristband-direct-port.md`). Phase 19.4 adds discovery, JWKS with RS256/ES256 rotation, `id_token`, userinfo, consent and pairwise subjects. That is protocol and security code where a maintained library is preferred, and zitadel/oidc v3 is already named in the stack. Settle it in a decision note before code lands. Phase: 19.4.
 - **Do WavePath's user-plugin tokens carry custom scopes?** If they do, `sm-user-plugin` needs a `RegisterAPITokenScope` hook in place of the static `AllowedAPITokenScopes`. Ask the WavePath side. Phase: 19.3 or the WavePath milestone.
+
+## From the plugin marketplace exploration (2026-10-29)
+
+- **Is `--module` for git-URL installs worth supporting?** `summer plugin:install <git-url>` defaults to a submodule checkout. Installing a private repo as a Go module needs `GOPRIVATE`/`GONOSUMDB` and git `insteadOf` rules so `go` can authenticate, which is fragile across GitHub, GitLab and Gitea and across SSH and HTTPS tokens. Find out what the setup costs in practice, whether `plugin:install` can detect and explain a misconfiguration, and decide whether `--module` ships or git URLs stay submodule-only. See `.planning/notes/2026-10-29-plugin-marketplace.md`. Phase: plugin marketplace.