docs(01): create phase plan

.planning/phases/01-framework-kernel-foundation/01-SKELETON.md

@@ -0,0 +1,37 @@
+# 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.