docs(phase-01): evolve PROJECT.md after phase completion

.planning/PROJECT.md

@@ -14,17 +14,19 @@ An existing WinterCMS-shaped app can be ported plugin by plugin to a single Go b
 
 ### Validated
 
-(None yet — ship to validate)
+Validated in Phase 1: Framework kernel foundation
+
+- [x] A single `summer` binary boots an application from layered YAML config via koanf (base + env overlays + per-plugin namespaces + environment variables), the layering design carried over from summer-compass (HOCON syntax itself is not used: no maintained Go parser exists)
+- [x] Plugins are Go modules registered at build time through a generated import list; `summer make:plugin` scaffolds one and `summer build` rebuilds the binary; a dev watch loop rebuilds on change
+- [x] A typed in-process event bus lets plugins subscribe to each other's events
+- [x] Console command framework with registration, dispatch and rich output (spinners, progress, tables, prompts), the design carried over from summer-bonfire; `summer make:plugin` / `plugin:add` shipped in Phase 1 (model, controller, migration, command, job scaffolds remain for Phase 4)
 
 ### Active
 
 Framework kernel
 
-- [ ] A single `summer` binary boots an application from layered YAML config via koanf (base + env overlays + per-plugin namespaces + environment variables), the layering design carried over from summer-compass (HOCON syntax itself is not used: no maintained Go parser exists)
-- [ ] Plugins are Go modules registered at build time through a generated import list; `summer make:plugin` scaffolds one and `summer build` rebuilds the binary; a dev watch loop rebuilds on change
 - [ ] Plugins declare models, migrations, routes, console commands, jobs, event listeners, admin controllers and navigation through one plugin descriptor, and can extend other plugins' models through ordinary Go interfaces and events
-- [ ] A typed in-process event bus lets plugins subscribe to each other's events
-- [ ] Console command framework with registration, dispatch and rich output (spinners, progress, tables, prompts), the design carried over from summer-bonfire; scaffolding commands for plugin, model, controller, migration, command, job
+- [ ] Scaffolding commands for model, controller, migration, command, job
 - [ ] i18n with CLDR plurals and namespaced keys (`vendor.plugin::group.key`), pl and en, the design carried over from summer-phrasebook
 - [ ] YAML `rules:` validation mapped onto go-playground/validator with translated messages
 
@@ -114,7 +116,7 @@ Quality
 |----------|-----------|---------|
 | Go instead of Scala 3 | Ecosystem depth: the OAuth2/OIDC test had a maintained Go answer (zitadel/oidc) and no Scala one; a CMS is glue over solved problems | ✓ Good (2026-09-16, `notes/why-go-not-scala.md`) |
 | v1 target is the Płytarium port | Headless, actively used, forces every ecosystem claim at once, three times the size of the `inventory` alternative but finishable | — Pending |
-| Compiled plugins, Caddy/xcaddy model | Full type safety, plugins extend each other through Go interfaces, `go test` works; rebuild cost is seconds | — Pending |
+| Compiled plugins, Caddy/xcaddy model | Full type safety, plugins extend each other through Go interfaces, `go test` works; rebuild cost is seconds | ✓ Good (Phase 1 hello app, 2026-09-16) |
 | Headless first; admin is a schema-driven SPA | Płytarium needs no theme engine; PocketBase-style schema-driven admin is the best-fit reference | — Pending |
 | GORM over ent | Closest to Eloquent's mutable-model DX, simplest line-by-line port of 25 PHP models; ent's codegen deferred | — Pending (chosen at init, 2026-09-16) |
 | Postgres only for v1 | One migration target; River requires it; Płytarium cuts over as part of go-live | — Pending |
@@ -148,4 +150,4 @@ This document evolves at phase transitions and milestone boundaries.
 4. Update Context with current state
 
 ---
-*Last updated: 2026-09-16 after requirements definition*
+*Last updated: 2026-09-16 after Phase 1 completion*