2.3 KiB
2.3 KiB
Walking Skeleton — SummerCMS (Go)
Phase: 1
Generated: 2026-09-16
Capability Proven End-to-End
A framework developer can run summer build in examples/hello, boot a separately compiled app from YAML config and generated plugin imports, then execute a plugin command through the app binary.
Architectural Decisions
| Decision | Choice | Rationale |
|---|---|---|
| Framework | Go 1.27.0, module git.golem15.com/golem15/summercms |
Locked by Phase 1 context. |
| Plugin linkage | App summer.yaml → generated plugins.gen.go blank imports |
Compiled plugins with an explicit ordered manifest. |
| App composition | party lifecycle, backpack.App, compass, festival, bonfire |
The smallest Phase 1 kernel path with a real consumer. |
| Data layer | Phase 3: Postgres + GORM/gormigrate | Phase 1 context excludes ORM and DB; the first real data slice is GET /_fonoteka/api/v1/genres. |
| HTTP/auth/UI | Phase 3 HTTP/auth; existing Nuxt UI remains the app frontend | Phase 1 is a framework CLI phase and excludes router, auth and UI. |
| Dev target | Local summer build and summer dev in examples/hello |
Makes plugin development observable before deployment is introduced. |
| Directory layout | Framework packages at root, tool in cmd/summer, app/modules under examples/hello |
Proves two-binary and two-repository architecture without importing the real app. |
Stack Touched in Phase 1
- Framework module and root
go.workwith separate hello app/plugin modules - Generated app entry point and plugin import list
- YAML config → Register-all → Boot-all → plugin command
- Built-in watch rebuild and restart loop
- Local run command:
cd examples/hello && summer build && ./bin/hello greeter:hello
Phase Boundary
The generic Walking Skeleton recipe calls for routing, a DB read/write and a UI interaction. Phase 1's locked CONTEXT.md explicitly excludes surf, lagoon, bouncer and UI until Phase 3. This skeleton proves the complete kernel developer path and records the later app slice as its handoff. No substitute fake DB/UI is added to satisfy a generic template.
Subsequent Slice Plan
- Phase 2 builds the API parity harness independently.
- Phase 3 adds the first real Postgres-backed Płytarium endpoint and exercises the framework from the separate app repository.