- Plan 10-02: Added explicit UserMailService wiring in Account.scala
onRegister handler for activation emails when activateMode == User
- Plan 10-04: Split into backend-only (models, services, admin controller)
reducing from 16 to 15 files, estimated context ~50%
- Plan 10-05: New plan for frontend components (Posts, Post, Categories,
RelatedPosts), Wave 3 depends on 10-04
- Updated ROADMAP.md to reflect 5 plans for Phase 10
Phase 10: Core Plugins
- User plugin patterns from Golem15.User reference
- Blog plugin patterns from Golem15.Blog reference
- TinyMCE for WYSIWYG editing
- Frontend authentication with cookie/JWT hybrid
- Nested set model for categories
- Component patterns for posts/account/session
- Plan 02: Added key_link clarifying CmsPageService.render populates
PageRenderContext.components before template rendering. Updated
Task 2/3 actions to emphasize component initialization flow.
- Plan 03: Split into 03 (storage + library core) and 03b (image
processing + routes) to reduce scope from 9 files to 7+4 files.
Estimated context reduced from ~65% to ~45% each.
- Plan 03b: New plan for ImageProcessor and MediaRoutes. Added
specific curl command with -F flags and expected JSON response.
- Plan 05: Added plugin integration test (MenuPluginIntegrationSpec)
demonstrating custom menu item type registration, resolution, and
template rendering per CONT-09 requirement.
- Plan 06: Reframed must_haves truths from implementation details
to user-observable outcomes (e.g., 'Developer edits template file,
browser refresh shows changes without server restart')
- Roadmap: Updated Phase 9 from 6 to 7 plans.
Phase 9: Content Management
- Standard stack: Scrimage for images, ZIO S3 for storage, CodeMirror 6 for editor
- CMS page patterns from WinterCMS with Pebble templates
- Media library with storage abstraction (local/S3)
- Content revision history with document versioning pattern
- Navigation menu system with polymorphic item types
- Hot reload via WatchService + Pebble cache invalidation
- 02-01 Task 3: Add concrete REPL verification command for PluginManifest.parse
- 02-02 Task 1: Add FieldDef case class to placeholder types in PluginRegistration.scala
- 02-02 Task 1: Document PluginEnv as placeholder to be expanded in 02-03
- 02-03 Task 3: Remove duplicate Main.scala code, keep only corrected version
- 02-03: Add SummerPlugin.scala to files_modified for PluginEnv update
Phase 02: Plugin System
- 3 plans in 3 waves (sequential)
- 02-01: Plugin discovery and manifest parsing
- 02-02: Lifecycle management and dependency resolution
- 02-03: Extension API with type-safe plugin-to-plugin communication
- Ready for execution
Phase 2: Plugin System
- Standard stack identified: circe-yaml, semver-parser-scala, directory-watcher
- Architecture patterns documented: ZIO service traits, Hub events, Ref state
- Dependency resolution via topological sort with cycle detection
- Type-safe extension API patterns from Scala 3 features
- Pitfalls catalogued from WinterCMS experience
- Add GET /ready endpoint that checks database connection
- Returns 200 'ready' when connected, 503 when not
- Update Routes to require DataSource dependency
- Provide dataSourceLayer in Main.scala
- Use 'hikari' prefix for HikariCP config to avoid ZIO config conflict
- Add Migrator trait with migrate/status ZIO effects
- Create V1 migration for summer_users table
- Configure Flyway with summer_migrations table and classpath location
- Migrations run manually via CLI, not on startup
- Add QuillContext with dataSourceLayer and quillLayer
- Update application.conf for HikariCP-compatible format
- Export combined quillLive layer for database access
- HealthRoutes with GET /health returning 'ok'
- Routes composition point for all route modules
- Main extends ZIOAppDefault with HOCON config
- ASCII sun banner with SUMMERCMS branding
- Server reads port from application.conf
- Updated 01-02-PLAN.md Task 3 to NOT run migrations on startup
- Updated must_haves truth: 'run via ZIO effect when invoked' (not 'on startup')
- Updated verification/success_criteria to reflect manual migration
- Updated ROADMAP success criteria #3 to match CONTEXT.md decision
Per CONTEXT.md line 22-23: migrations run manually via CLI command
