---
phase: 01-framework-kernel-foundation
plan: 03
type: execute
wave: 3
depends_on: ["01-02"]
files_modified:
  - internal/build/build.go
  - internal/build/manifest.go
  - internal/build/scaffold.go
  - internal/dev/watch.go
  - cmd/summer/main.go
  - bonfire/root.go
  - bonfire/command.go
  - bonfire/output.go
  - bonfire/widgets.go
  - bonfire/prompts.go
  - bonfire/output_test.go
  - bonfire/prompts_test.go
  - internal/build/build_test.go
  - internal/dev/watch_test.go
  - examples/hello/plugins/greeter/plugin.go
  - go.mod
  - go.sum
autonomous: true
requirements: [KERN-04, KERN-09, CLI-01]
must_haves:
  truths:
    - "D-01 D-03 D-04 D-05: `summer make:plugin` scaffolds a compiling plugin and `summer plugin:add` adds it to the ordered manifest/workspace; `summer build` regenerates imports and a separate app binary."
    - "D-14: Spinner, progress, table, ask/confirm/choice/secret prompts and color policy use standard library plus `x/term`, with deterministic non-TTY output."
    - "D-15 D-17: Tool and app commands use colon-style names; plugin command metadata, flags, arguments and injected Output are wrapped by the shared cobra kernel."
    - "D-16: `summer dev` watches sources/config/manifests, debounces, calls the same build function, restarts the app only after successful build, and prints measured rebuild latency."
  artifacts:
    - path: internal/build/scaffold.go
      provides: Minimal plugin scaffold and manifest/workspace registration
    - path: bonfire/widgets.go
      provides: Spinner, progress and table rendering
    - path: bonfire/prompts.go
      provides: Prompt handling and non-TTY fallback
    - path: internal/dev/watch.go
      provides: Built-in watch rebuild loop
  key_links:
    - from: cmd/summer/main.go
      to: internal/build/scaffold.go
      via: `make:plugin` and `plugin:add` tool commands
    - from: internal/dev/watch.go
      to: internal/build/build.go
      via: One shared build function
    - from: bonfire/root.go
      to: bonfire/output.go
      via: Output injection into plugin commands
---

<objective>
As a framework developer, I can add a plugin, rebuild, see useful CLI output, and keep an app running while editing source, so compiled plugins have a practical development loop.

Purpose: Complete the Phase 1 tool experience around the already bootable hello app.
Output: `make:plugin`, `plugin:add`, rich CLI output and built-in `summer dev` watch loop.
</objective>

<execution_context>
@$HOME/.codex/get-shit-done/workflows/execute-plan.md
@$HOME/.codex/get-shit-done/templates/summary.md
</execution_context>

<context>
@.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
@.planning/phases/01-framework-kernel-foundation/01-02-SUMMARY.md
@../modules/summer-bonfire/PLAN.md
</context>

<tasks>

<task type="auto">
  <name>Task 1: Add and rebuild a compiling plugin from the tool</name>
  <files>internal/build/build.go, internal/build/manifest.go, internal/build/scaffold.go, internal/build/build_test.go, cmd/summer/main.go</files>
  <read_first>internal/build/build.go, internal/build/manifest.go, internal/build/scaffold.go, internal/build/build_test.go, cmd/summer/main.go, examples/hello/summer.yaml, examples/hello/go.mod, examples/hello/plugins.gen.go, examples/hello/plugins/base/plugin.go, go.work, .planning/phases/01-framework-kernel-foundation/01-CONTEXT.md, .planning/phases/01-framework-kernel-foundation/01-RESEARCH.md</read_first>
  <action>Complete D-01/D-03/D-04/D-05 using `summer.yaml` as the sole ordered source of plugin IDs and module paths. `summer make:plugin <vendor.plugin>` scaffolds `plugins/<plugin>/go.mod` with module path `<app-module>/plugins/<plugin>` and `toolchain go1.27.0`, `plugin.go` implementing ID/Requires/Register/Boot and `init(){ party.Register(...) }`, plus an empty `config/` placeholder; no model/migration/controller/command stubs. `summer plugin:add <local-plugin-dir>` reads the module path from that directory's `go.mod`, validates the ID and module path, adds the plugin once to `summer.yaml`, updates the nearest app `go.work` with `go work use`, and updates app `go.mod` as needed for a portable dependency graph. Preserve manifest order and reject conflicting IDs. `summer build` must regenerate both app files from the updated manifest and print elapsed build time; no map iteration controls output. Keep tool source independent of app/plugin imports. Exercise the commands on a temporary copy of `examples/hello` so the permanent testbed stays small.</action>
  <verify><automated>go test ./internal/build ./cmd/summer &amp;&amp; (cd examples/hello &amp;&amp; go test ./...)</automated></verify>
  <acceptance_criteria>
    - `make:plugin golem15.demo` produces a compiling plugin module with only `go.mod`, `plugin.go` and `config/`.
    - `plugin:add` adds one manifest entry and workspace module; repeating it is idempotent.
    - `summer build` produces byte-stable `main.go` and `plugins.gen.go` from the updated manifest.
    - The framework tool has no import of an app-specific plugin package.
  </acceptance_criteria>
  <done>A new local plugin can be scaffolded, added and compiled into the hello app.</done>
</task>

<task type="auto">
  <name>Task 2: Give tool and plugin commands deterministic rich output</name>
  <files>bonfire/root.go, bonfire/command.go, bonfire/output.go, bonfire/widgets.go, bonfire/prompts.go, bonfire/output_test.go, bonfire/prompts_test.go, cmd/summer/main.go, examples/hello/plugins/greeter/plugin.go, go.mod, go.sum</files>
  <read_first>bonfire/root.go, bonfire/command.go, bonfire/output.go, bonfire/widgets.go, bonfire/prompts.go, bonfire/output_test.go, bonfire/prompts_test.go, cmd/summer/main.go, examples/hello/plugins/greeter/plugin.go, go.mod, go.sum, ../modules/summer-bonfire/PLAN.md, .planning/phases/01-framework-kernel-foundation/01-CONTEXT.md, .planning/phases/01-framework-kernel-foundation/01-RESEARCH.md</read_first>
  <action>Implement D-14/D-15/D-17 with stdlib formatting and `golang.org/x/term` v0.46.0 only for terminal capability/raw/password primitives. `bonfire.Output` is constructed once from injected stdin/stdout/stderr and terminal/color policy; the cobra adapter passes `ctx`, parsed `Input`, and that Output to every `bonfire.Command`. Command metadata defines arguments and flags without duplicating root wiring; reject plugin command names without `<namespace>:<verb>`, while kernel tool commands are `make:plugin`, `plugin:add`, `build`, `dev`. Implement braille spinner and gradient progress for TTY, box-drawing table, ask/confirm/choice/secret prompts. For non-TTY: spinner prints one `[...] message`; progress prints `[N/M] pct%` at 10% steps; table is tab-separated; ask/choice/secret read stdin lines; confirm uses its default. `NO_COLOR` or `TERM=dumb` disables ANSI; `FORCE_COLOR` enables it only when neither disable condition is present. `secret` uses `term.ReadPassword` on TTY and a plain stdin line otherwise. Make the hello plugin command exercise table and one prompt without hanging when stdin is closed.</action>
  <verify><automated>go test ./bonfire ./cmd/summer &amp;&amp; (cd examples/hello &amp;&amp; go test ./...)</automated></verify>
  <acceptance_criteria>
    - `summer make:plugin --help` and the app's `greeter:hello --help` are generated through the shared `bonfire` cobra adapter.
    - Non-TTY output has no ANSI when `NO_COLOR=1` or `TERM=dumb` and uses the exact spinner/progress/table fallback shapes above.
    - Injected streams let tests capture Output and feed prompt answers without a real TTY.
    - Plugin command names without `:` fail registration with a named error.
  </acceptance_criteria>
  <done>Both binaries expose namespaced commands and usable output in interactive and CI environments.</done>
</task>

<task type="auto">
  <name>Task 3: Rebuild and restart the hello binary during source edits</name>
  <files>internal/dev/watch.go, internal/dev/watch_test.go, internal/build/build.go, cmd/summer/main.go, go.mod, go.sum</files>
  <read_first>internal/build/build.go, internal/dev/watch.go, internal/dev/watch_test.go, cmd/summer/main.go, go.mod, go.sum, examples/hello/summer.yaml, .planning/phases/01-framework-kernel-foundation/01-CONTEXT.md, .planning/phases/01-framework-kernel-foundation/01-RESEARCH.md</read_first>
  <action>Implement `summer dev` with `github.com/fsnotify/fsnotify` v1.10.1 (D-16). Watch app workspace directories recursively by walking them and adding new directories on Create; include `.go`, `.yaml`, `.yml`, `.env`, `go.mod`, `go.work` and plugin manifests. Ignore `.git`, `bin`, temp build outputs and generated app files to prevent loops. Debounce bursts (for example 200ms) and serialize builds. Call the exact `internal/build` function used by `summer build`; after success stop and reap the old child, start the new app binary with inherited streams, and print `rebuild: <duration>` measured from build start to completion. On build failure keep the old process running and print the build error; on context cancellation stop/reap the child and close the watcher. Do not execute manifest-derived shell commands. Add a smoke test with a temporary workspace to assert one restart after a source edit, no restart after ignored generated output and a latency line.</action>
  <verify><automated>go test ./internal/dev ./internal/build ./cmd/summer &amp;&amp; (cd examples/hello &amp;&amp; go test ./...)</automated></verify>
  <acceptance_criteria>
    - Editing a watched hello plugin `.go` file causes one debounced rebuild and successful restart.
    - Build failure leaves the last successful child running; cancellation reaps it.
    - A generated `plugins.gen.go` write does not cause an infinite rebuild loop.
    - Every rebuild cycle prints measured elapsed time, including the cycle after a single-plugin edit.
  </acceptance_criteria>
  <done>The local development loop rebuilds and restarts without an external watcher install.</done>
</task>

</tasks>

<threat_model>
## Trust Boundaries

| Boundary | Description |
|---|---|
| CLI plugin input → filesystem | Plugin ID and directory values select paths and module names. |
| Filesystem event → build/restart | File changes trigger local tool execution and process replacement. |
| Prompt → terminal | Secret values may be echoed or captured if mode detection is wrong. |

## STRIDE Threat Register

| Threat ID | Category | Component | Disposition | Mitigation Plan |
|---|---|---|---|---|
| T-01-06 | Tampering | `make:plugin` and `plugin:add` paths | mitigate | Validate lowercase vendor.plugin ID and keep generated paths under the app root; reject traversal and duplicate/conflicting entries. |
| T-01-07 | Denial of service | `summer dev` watcher | mitigate | Debounce, ignore output dirs, serialize builds, and reap child processes on cancellation. |
| T-01-08 | Information disclosure | `bonfire` secret prompt | mitigate | Use `term.ReadPassword` for TTY and document plain stdin fallback; never log answers. |
</threat_model>

<verification>
- After each task commit, run `go vet ./... && go test ./...` in root and hello modules.
- Smoke-test `make:plugin`, `plugin:add`, `build` and `dev` against temporary copies of `examples/hello`.
- Capture non-TTY output with pipes; manually inspect one TTY command during phase verification.
</verification>

<success_criteria>
- A new plugin is scaffolded, registered and built using only the framework tool.
- CLI output degrades predictably without a TTY.
- A plugin source change triggers a measured rebuild and app restart.
</success_criteria>

<output>
Create `.planning/phases/01-framework-kernel-foundation/01-03-SUMMARY.md` after completion.
</output>