38 lines
2.3 KiB
Markdown
38 lines
2.3 KiB
Markdown
# 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.work` with 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.
|