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()`.
path
provides
internal/build/build.go
Manifest-driven code generation and app build
path
provides
party/registry.go
Required plugin interface and activation
path
provides
bonfire/root.go
Shared cobra command construction
path
provides
examples/hello/summer.yaml
Ordered hello plugin manifest
from
to
via
cmd/summer/main.go
bonfire/root.go
Shared root command constructor
from
to
via
examples/hello/main.go
party/registry.go
Generated app activation with ordered plugin IDs
from
to
via
examples/hello/plugins.gen.go
examples/hello/plugins/greeter/plugin.go
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.
@.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.
<threat_model>
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.
</threat_model>
- 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.
<success_criteria>
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.
</success_criteria>
Create `.planning/phases/01-framework-kernel-foundation/01-01-SUMMARY.md` after completion.
