docs(phase-01): complete phase execution
This commit is contained in:
Jakub Zych
@@ -9,19 +9,19 @@ Requirements for v1 (the Płytarium port). Each maps to roadmap phases. "User" b
|
||||
|
||||
### Kernel and plugins (KERN)
|
||||
|
||||
- [ ] **KERN-01**: Application boots from layered YAML config via koanf (base files, env overlay directory, per-plugin namespace, environment variables) with dot-path access and typed section loading
|
||||
- [ ] **KERN-02**: A plugin implements one required interface (ID, Requires, Register, Boot); Register runs for all plugins before any Boot, and order follows a topological sort of Requires
|
||||
- [ ] **KERN-03**: Plugins opt into capabilities through small optional interfaces (models, migrations, routes, middleware, commands, jobs, listeners, admin controllers, navigation, permissions, schedule, mail templates, config, lang) discovered by type assertion
|
||||
- [ ] **KERN-04**: Plugins are Go modules in a go.work workspace that self-register in init(); `summer build` regenerates the blank-import list and rebuilds the binary; `summer plugin:add` wires a new module in
|
||||
- [ ] **KERN-05**: A plugin can check at boot whether an optional plugin is registered and skip its integration without a hard import (replaces PHP class_exists guards)
|
||||
- [ ] **KERN-06**: A typed event bus offers three primitives: fire-and-forget, fire-and-collect (listener return values merged into one payload), fire-until-handled; plugins listen on other plugins' events
|
||||
- [ ] **KERN-07**: Per-request state (user, organization, active collection, locale) travels in context.Context; no package-level globals hold request state
|
||||
- [ ] **KERN-08**: A service registry (backpack) lets a plugin publish a service (job manager, authorizer registry, credential resolver) that other plugins resolve by interface
|
||||
- [ ] **KERN-09**: A dev watch loop rebuilds and restarts the binary on source change
|
||||
- [x] **KERN-01**: Application boots from layered YAML config via koanf (base files, env overlay directory, per-plugin namespace, environment variables) with dot-path access and typed section loading
|
||||
- [x] **KERN-02**: A plugin implements one required interface (ID, Requires, Register, Boot); Register runs for all plugins before any Boot, and order follows a topological sort of Requires
|
||||
- [x] **KERN-03**: Plugins opt into capabilities through small optional interfaces (models, migrations, routes, middleware, commands, jobs, listeners, admin controllers, navigation, permissions, schedule, mail templates, config, lang) discovered by type assertion
|
||||
- [x] **KERN-04**: Plugins are Go modules in a go.work workspace that self-register in init(); `summer build` regenerates the blank-import list and rebuilds the binary; `summer plugin:add` wires a new module in
|
||||
- [x] **KERN-05**: A plugin can check at boot whether an optional plugin is registered and skip its integration without a hard import (replaces PHP class_exists guards)
|
||||
- [x] **KERN-06**: A typed event bus offers three primitives: fire-and-forget, fire-and-collect (listener return values merged into one payload), fire-until-handled; plugins listen on other plugins' events
|
||||
- [x] **KERN-07**: Per-request state (user, organization, active collection, locale) travels in context.Context; no package-level globals hold request state
|
||||
- [x] **KERN-08**: A service registry (backpack) lets a plugin publish a service (job manager, authorizer registry, credential resolver) that other plugins resolve by interface
|
||||
- [x] **KERN-09**: A dev watch loop rebuilds and restarts the binary on source change
|
||||
|
||||
### Console and scaffolding (CLI)
|
||||
|
||||
- [ ] **CLI-01**: The `summer` binary (cobra) discovers commands registered by plugins and offers rich output (spinner, progress bar, table, prompts) with non-TTY degradation, following the summer-bonfire design
|
||||
- [x] **CLI-01**: The `summer` binary (cobra) discovers commands registered by plugins and offers rich output (spinner, progress bar, table, prompts) with non-TTY degradation, following the summer-bonfire design
|
||||
- [ ] **CLI-02**: Scaffolding commands generate a plugin, model, migration, command, job and admin controller with stubs that compile
|
||||
- [ ] **CLI-03**: Migration commands run up, status, and roll back the last migration of a named plugin
|
||||
- [ ] **CLI-04**: Plugins register recurring commands (daily or interval) that a scheduler runs in-process or via `summer schedule:run`
|
||||
@@ -154,16 +154,16 @@ Which phases cover which requirements. Updated during roadmap creation.
|
||||
|
||||
| Requirement | Phase | Status |
|
||||
|-------------|-------|--------|
|
||||
| KERN-01 | Phase 1 | Pending |
|
||||
| KERN-02 | Phase 1 | Pending |
|
||||
| KERN-03 | Phase 1 | Pending |
|
||||
| KERN-04 | Phase 1 | Pending |
|
||||
| KERN-05 | Phase 1 | Pending |
|
||||
| KERN-06 | Phase 1 | Pending |
|
||||
| KERN-07 | Phase 1 | Pending |
|
||||
| KERN-08 | Phase 1 | Pending |
|
||||
| KERN-09 | Phase 1 | Pending |
|
||||
| CLI-01 | Phase 1 | Pending |
|
||||
| KERN-01 | Phase 1 | Complete |
|
||||
| KERN-02 | Phase 1 | Complete |
|
||||
| KERN-03 | Phase 1 | Complete |
|
||||
| KERN-04 | Phase 1 | Complete |
|
||||
| KERN-05 | Phase 1 | Complete |
|
||||
| KERN-06 | Phase 1 | Complete |
|
||||
| KERN-07 | Phase 1 | Complete |
|
||||
| KERN-08 | Phase 1 | Complete |
|
||||
| KERN-09 | Phase 1 | Complete |
|
||||
| CLI-01 | Phase 1 | Complete |
|
||||
| CLI-02 | Phase 4 | Pending |
|
||||
| CLI-03 | Phase 5 | Pending |
|
||||
| CLI-04 | Phase 11 | Pending |
|
||||
|
||||
@@ -2,16 +2,16 @@
|
||||
gsd_state_version: 1.0
|
||||
milestone: v1.0
|
||||
milestone_name: milestone
|
||||
status: executing
|
||||
stopped_at: Phase 2 context gathered
|
||||
last_updated: "2026-09-16T10:53:48.889Z"
|
||||
status: ready_to_plan
|
||||
stopped_at: Phase 01 complete (4/4) — ready to discuss Phase 02
|
||||
last_updated: 2026-09-16T12:44:56.877Z
|
||||
last_activity: 2026-09-16 -- Phase 01 execution started
|
||||
progress:
|
||||
total_phases: 15
|
||||
completed_phases: 0
|
||||
completed_phases: 1
|
||||
total_plans: 4
|
||||
completed_plans: 0
|
||||
percent: 0
|
||||
completed_plans: 4
|
||||
percent: 7
|
||||
---
|
||||
|
||||
# Project State
|
||||
@@ -21,22 +21,22 @@ progress:
|
||||
See: .planning/PROJECT.md (updated 2026-09-16)
|
||||
|
||||
**Core value:** An existing WinterCMS-shaped app can be ported plugin by plugin to a single Go binary without its frontend noticing: the PHP version's API contract is the acceptance test.
|
||||
**Current focus:** Phase 01 — framework-kernel-foundation
|
||||
**Current focus:** Phase 02 — api parity harness bootstrap
|
||||
|
||||
## Current Position
|
||||
|
||||
Phase: 01 (framework-kernel-foundation) — EXECUTING
|
||||
Plan: 1 of 4
|
||||
Status: Executing Phase 01
|
||||
Last activity: 2026-09-16 -- Phase 01 execution started
|
||||
Phase: 02
|
||||
Plan: Not started
|
||||
Status: Ready to plan
|
||||
Last activity: 2026-09-16
|
||||
|
||||
Progress: [░░░░░░░░░░] 0%
|
||||
Progress: [█░░░░░░░░░] 7%
|
||||
|
||||
## Performance Metrics
|
||||
|
||||
**Velocity:**
|
||||
|
||||
- Total plans completed: 0
|
||||
- Total plans completed: 4
|
||||
- Average duration: -
|
||||
- Total execution time: 0 hours
|
||||
|
||||
@@ -44,7 +44,7 @@ Progress: [░░░░░░░░░░] 0%
|
||||
|
||||
| Phase | Plans | Total | Avg/Plan |
|
||||
|-------|-------|-------|----------|
|
||||
| - | - | - | - |
|
||||
| 01 | 4 | - | - |
|
||||
|
||||
**Recent Trend:**
|
||||
|
||||
|
||||
@@ -1,31 +1,36 @@
|
||||
---
|
||||
status: partial
|
||||
status: complete
|
||||
phase: 01-framework-kernel-foundation
|
||||
source: [01-VERIFICATION.md]
|
||||
started: 2026-09-16T12:39:17Z
|
||||
updated: 2026-09-16T12:39:17Z
|
||||
updated: 2026-09-16T12:44:02Z
|
||||
---
|
||||
|
||||
## Current Test
|
||||
|
||||
[awaiting human testing]
|
||||
Human verification approved 2026-09-16.
|
||||
|
||||
## Tests
|
||||
|
||||
### 1. Interactive terminal rendering
|
||||
expected: Run `./bin/hello greeter:hello` and one tool command (`summer make:plugin --help` or a spinner-using command) in a real TTY. Braille spinner / box-drawing table / colored status glyphs appear; prompts are interactive. NO_COLOR=1 or TERM=dumb removes ANSI.
|
||||
result: [pending]
|
||||
expected: Run `./bin/hello greeter:hello` and one tool command (`summer make:plugin --help` or a spinner-using command) in a real TTY. Braille spinner / box-drawing table / colored glyphs appear; prompts are interactive. NO_COLOR=1 or TERM=dumb removes ANSI.
|
||||
result: pass
|
||||
reported: |
|
||||
`./bin/hello greeter:hello` showed a box-drawing plugin/status table, interactive `? show greeting? [Y/n]`, then `name=hello-app posts_per_page=10 debug=false extra=hello-from-optional events=ok collected=greeter handled=true`.
|
||||
`go run ./cmd/summer make:plugin --help` printed the cobra help for `summer make:plugin <id>`.
|
||||
|
||||
### 2. Rebuild feel under `summer dev`
|
||||
expected: In `examples/hello`, run `go run ../../cmd/summer dev`, edit `plugins/greeter/plugin.go`, and watch the terminal. A `rebuild: <duration>` line prints, the child restarts, and generated `main.go` / `plugins.gen.go` writes do not loop.
|
||||
result: [pending]
|
||||
result: pass
|
||||
reported: |
|
||||
`go run ../../cmd/summer dev` from `examples/hello` printed `built hello in 480ms` then `rebuild: 480ms` and started the child (`hello [command]` usage). Approved without a reported watch-loop.
|
||||
|
||||
## Summary
|
||||
|
||||
total: 2
|
||||
passed: 0
|
||||
passed: 2
|
||||
issues: 0
|
||||
pending: 2
|
||||
pending: 0
|
||||
skipped: 0
|
||||
blocked: 0
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
phase: 01-framework-kernel-foundation
|
||||
verified: 2026-09-16T12:37:13Z
|
||||
status: human_needed
|
||||
status: passed
|
||||
score: 5/5 must-haves verified
|
||||
overrides_applied: 0
|
||||
human_verification:
|
||||
@@ -17,7 +17,7 @@ human_verification:
|
||||
|
||||
**Phase Goal:** The `summer` binary boots from layered YAML config, plugins self-register through one required interface plus optional capability interfaces, a typed event bus and service registry are available, and a CLI command framework with a dev watch loop exists — built only as far as the first vertical slice will need it, per the interleaved-not-sequential kernel approach.
|
||||
**Verified:** 2026-09-16T12:37:13Z
|
||||
**Status:** human_needed
|
||||
**Status:** passed
|
||||
**Re-verification:** No — initial verification
|
||||
|
||||
**MVP note:** ROADMAP marks this phase `mode: mvp`, but the phase goal is not a User Story (`gsd-sdk query user-story.validate` → `valid: false`). Direct instruction was to verify and write this report, so verification used the five ROADMAP success criteria as the contract and treated the developer as the user for flow coverage. Individual plan objectives are already in User Story form.
|
||||
|
||||
Reference in New Issue
Block a user