---
phase: 01-framework-kernel-foundation
plan: 01
type: execute
wave: 1
depends_on: []
files_modified:
- go.mod
- go.sum
- go.work
- party/registry.go
- backpack/app.go
- pact/capabilities.go
- compass/config.go
- bonfire/command.go
- bonfire/root.go
- internal/build/build.go
- cmd/summer/main.go
- examples/hello/summer.yaml
- examples/hello/go.mod
- examples/hello/main.go
- examples/hello/plugins.gen.go
- examples/hello/hello_test.go
- examples/hello/plugins/base/go.mod
- examples/hello/plugins/base/plugin.go
- examples/hello/plugins/greeter/go.mod
- examples/hello/plugins/greeter/plugin.go
- examples/hello/config/app.yaml
autonomous: true
requirements: [KERN-01, KERN-02, KERN-03, KERN-04, CLI-01]
must_haves:
truths:
- "D-01 D-02: An installed `summer` tool builds a separate hello app binary, and both entry points use the same `bonfire` root-command constructor."
- "D-03 D-04 D-05: The permanent hello app has separate plugin modules in root `go.work`, imports `git.golem15.com/golem15/summercms`, and uses a concrete Go 1.27 toolchain directive."
- "D-15 D-17: The hello app boots plugins and executes `greeter:hello` through a `bonfire.Command` adapter with injected Input and Output."
- "The generated import list preserves the explicit manifest order while the plugin registry orders lifecycle by `Requires()`."
artifacts:
- path: internal/build/build.go
provides: Manifest-driven code generation and app build
- path: party/registry.go
provides: Required plugin interface and activation
- path: bonfire/root.go
provides: Shared cobra command construction
- path: examples/hello/summer.yaml
provides: Ordered hello plugin manifest
key_links:
- from: cmd/summer/main.go
to: bonfire/root.go
via: Shared root command constructor
- from: examples/hello/main.go
to: party/registry.go
via: Generated app activation with ordered plugin IDs
- from: examples/hello/plugins.gen.go
to: examples/hello/plugins/greeter/plugin.go
via: Blank import triggers self-registration
---
As a framework developer, I can build a tiny app from two compiled plugins and run its namespaced hello command, so the first kernel API is proven by a real binary.
Purpose: Establish the thinnest executable path that future Phase 1 work can extend.
Output: Framework tool, shared runtime command kernel, plugin registry, minimal config, root workspace, and permanent `examples/hello` app.
@$HOME/.codex/get-shit-done/workflows/execute-plan.md
@$HOME/.codex/get-shit-done/templates/summary.md
@.planning/PROJECT.md
@.planning/ROADMAP.md
@.planning/REQUIREMENTS.md
@.planning/phases/01-framework-kernel-foundation/01-CONTEXT.md
@.planning/phases/01-framework-kernel-foundation/01-RESEARCH.md
@.planning/phases/01-framework-kernel-foundation/01-VALIDATION.md
@../modules/summer-compass/README.md
@../modules/summer-bonfire/PLAN.md
Task 1: Make the hello app boot and dispatch a plugin command
go.mod, go.sum, go.work, party/registry.go, backpack/app.go, pact/capabilities.go, compass/config.go, bonfire/command.go, bonfire/root.go, examples/hello/go.mod, examples/hello/main.go, examples/hello/summer.yaml, examples/hello/plugins.gen.go, examples/hello/hello_test.go, examples/hello/plugins/base/go.mod, examples/hello/plugins/base/plugin.go, examples/hello/plugins/greeter/go.mod, examples/hello/plugins/greeter/plugin.go, examples/hello/config/app.yaml
go.mod, go.sum, go.work, .planning/phases/01-framework-kernel-foundation/01-CONTEXT.md, .planning/phases/01-framework-kernel-foundation/01-RESEARCH.md, .planning/research/ARCHITECTURE.md, ../modules/summer-bonfire/PLAN.md, party/registry.go, backpack/app.go, pact/capabilities.go, compass/config.go, bonfire/command.go, bonfire/root.go, examples/hello/go.mod, examples/hello/main.go, examples/hello/summer.yaml, examples/hello/plugins.gen.go, examples/hello/hello_test.go, examples/hello/plugins/base/go.mod, examples/hello/plugins/base/plugin.go, examples/hello/plugins/greeter/go.mod, examples/hello/plugins/greeter/plugin.go, examples/hello/config/app.yaml
The hello binary loads `app.name` from `config/app.yaml`, runs Register for both plugins before Boot, and executes `greeter:hello` through an injected Output writer.
Implement the smallest real boot path. Pin `toolchain go1.27.0` in root and generated/example modules and root `go.work` (D-05). Put the required `Plugin` interface (`ID`, `Requires`, `Register`, `Boot`) and `Register`/`Activate` in `party`, with `Register(*backpack.App) error` and `Boot(*backpack.App) error`; `backpack` must not import `party`. `Activate` must resolve IDs from the manifest order, topologically sort Requires, run every Register before any Boot, and expose the resulting plugins to command collection. Define `pact.HasCommands` returning `[]bonfire.Command` and `pact.HasConfig` returning `fs.FS` as optional type-asserted capabilities; reserve the remaining KERN-03 capability names in documentation for their first consumers. `bonfire.Command` has Name, Description, flag/argument definition and `Run(ctx, Input, Output) error`; its root factory accepts command values, not a party registry, to avoid an import cycle (D-02, D-17). Use `cobra` v1.10.2, `koanf/v2` v2.3.6 and `koanf/parsers/yaml` v1.1.1 with an injected output writer. Create two hello plugin modules with IDs `golem15.hello` and `golem15.greeter`; greeter Requires hello and provides `greeter:hello`. Create `summer.yaml` with `module`, `binary`, and an ordered `plugins` list of `{id, module}` entries; write initial `main.go` and `plugins.gen.go` from those two entries so the app already runs before codegen is automated in Task 2. Add root `go.work` entries for framework, app and both plugins. Keep compass at a working `config/app.yaml` section load and dot-path String lookup here; Plan 02 fills the full precedence contract. Write the smoke test before implementation inside this task, but commit only once both root and hello module tests are green.
go vet ./... && go test ./... && (cd examples/hello && go vet ./... && go test ./...)
- `party.Plugin` has ID, Requires, Register and Boot; `backpack` has no import of `party`.
- `bonfire.NewRoot` or equivalent takes a slice of `bonfire.Command` and is used by the hello main.
- `examples/hello` contains two independently versioned plugin modules and a working `greeter:hello` command.
- Root and hello `go vet ./...` and `go test ./...` exit 0.
The initial hello command executes through a real app activation path with no package import cycle.
Task 2: Generate and build the hello app from its ordered manifest
internal/build/build.go, cmd/summer/main.go, examples/hello/summer.yaml, examples/hello/main.go, examples/hello/plugins.gen.go, examples/hello/hello_test.go, go.sum
go.mod, go.sum, go.work, party/registry.go, bonfire/root.go, examples/hello/go.mod, examples/hello/main.go, examples/hello/summer.yaml, examples/hello/plugins.gen.go, examples/hello/hello_test.go, .planning/phases/01-framework-kernel-foundation/01-CONTEXT.md, .planning/phases/01-framework-kernel-foundation/01-RESEARCH.md, internal/build/build.go, cmd/summer/main.go
Implement `summer build` in the framework-owned `cmd/summer` (D-01, D-04). Parse `examples/hello/summer.yaml` as an explicit ordered `plugins` list of `{id, module}` entries, reject duplicate/invalid entries, generate app-root `main.go` and `plugins.gen.go` containing blank imports plus an ordered plugin-ID slice, and invoke `go build -o bin/hello .` with `exec.CommandContext` in the app directory. Keep generated bytes stable and rewrite only when changed. `main.go` calls the same `bonfire` root constructor as the tool, then activates the manifest IDs; never rely on Go package init order for lifecycle order. Tool `build` prints measured build duration. `go install ./cmd/summer` builds a reusable tool while the app binary remains a distinct artifact. Update the smoke test to run the built binary's `greeter:hello` command and assert its config value. Do not add HTTP, DB, auth or full scaffolding.
go vet ./... && go test ./... && (cd examples/hello && go vet ./... && go test ./... && go run ../../cmd/summer build && ./bin/hello greeter:hello)
- `summer build` creates `examples/hello/plugins.gen.go` with imports in `summer.yaml` order and creates an executable `examples/hello/bin/hello`.
- Two consecutive `summer build` calls produce byte-identical generated files.
- `./bin/hello greeter:hello` exits 0 and prints a value from `config/app.yaml`.
- The tool does not import an example plugin package or contain a hard-coded example module path.
A developer can build and run the independent hello app through the installed framework tool.
## Trust Boundaries
| Boundary | Description |
|---|---|
| App manifest → generated Go and build process | A repository-controlled YAML file supplies module import paths and output name. |
## STRIDE Threat Register
| Threat ID | Category | Component | Disposition | Mitigation Plan |
|---|---|---|---|---|
| T-01-01 | Tampering | `internal/build` manifest parser | mitigate | Validate module path syntax and duplicate IDs before generating code; render imports with Go string quoting. |
| T-01-02 | Elevation of privilege | `summer build` process launch | mitigate | Use `exec.CommandContext("go", ...)` with separate args and fixed app working directory; never invoke a shell string from YAML. |
- Run `go vet ./...` and `go test ./...` in the root and hello modules after each task commit.
- Run `summer build` twice; compare generated file hashes and execute `bin/hello greeter:hello`.
- Confirm the app binary imports the framework module but the framework tool does not import hello.
- A separate `summer` tool and generated hello binary build under Go 1.27.0.
- The hello plugin command runs from the app binary using shared `bonfire` wiring.
- Two plugins Register before either Boots, irrespective of manifest order.