# 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.