Two real defects surfaced by the gate's first live run against the real
fonoteka-mcp SDK:
- stage_revoke looked up the connected app by a.name; ConnectedAppsIndex
actually serializes client_name (confirmed against
controllers/api/connected_app_controller.go serializeConnectedApp).
- Even with that fixed, stage_revoke ran after stage_replay, by which
point RevokeLineage's forward walk (presenting the pre-refresh spent
secret) had already cascade-revoked the live post-refresh access token
too -- correct, intentional T-08-REFRESH-REPLAY behavior, and the exact
same effect 08-09-PLAN.md's own mcp-lifecycle fixture ordering already
documented ('connected-apps would already be empty if list ran after
replay'). stage_refresh now captures the connected-app id while the
session is still live; stage_revoke DELETEs that id directly instead of
re-listing (ConnectedAppsDestroy has no revoked_at filter on its own
lookup, so this still exercises the real endpoint, idempotently, against
the id the real MCP-driven session actually owned).
SummerCMS (Go)
A Go rewrite of the WinterCMS/OctoberCMS content management framework, built for the Golem15 stack.
SummerCMS keeps what makes WinterCMS productive — plugins that extend each other, YAML-driven admin forms, models/controllers/components, scaffolding commands — and drops the parts that do not survive a compiled language.
Status
Pre-alpha. Planning and research. Nothing runs yet.
Why Go
The first SummerCMS attempt was Scala 3. Three infrastructure modules were built (config, i18n, console) before the effort stalled on ecosystem depth: proven, reusable libraries for things like an OAuth2/OIDC server did not exist, and building them from scratch was out of budget. Go's ecosystem covers every concern in the Illuminate module map with maintained, widely used libraries. See .planning/notes/why-go-not-scala.md and .planning/research/go-ecosystem.md.
v1 target
Port Płytarium (the fonoteka project): a headless WinterCMS backend with a Nuxt 4 frontend, 160 API routes, its own OAuth2 provider, Discogs and AI integrations, queued jobs, realtime notifications, and organization-scoped collections.
Definition of done for v1: vue-fonoteka-app runs unchanged against the Go backend.
See .planning/notes/v1-target-plytarium.md.
Architecture decisions so far
- Compiled plugins, Caddy/xcaddy style: a
plugins/workspace of Go modules, a generated import list, scaffold and rebuild commands, watch-rebuild in dev. - A sandboxed WASM extension API for untrusted third-party extensions comes later, behind a stable core plugin API.
- Headless first. Admin is a schema-driven SPA. Server-rendered themes come with the second port target (keios.eu).
Layout
.planning/ GSD planning artifacts (notes, research, seeds, roadmap)
Everything else will be created by the GSD roadmap phases.