docs(14.3-03): document summer new and the one-command start

- installation: one-liner first, what the script does and its overrides,
  running the generated app, summer new without the script, then the
  examples/hello walkthrough; the obsolete known-issues callout is gone (D-18)
- go modules and workspaces: what summer new writes (relative replace,
  framework detection order, committed relative go.work, no root go.sum);
  plugin:add adds a relative go.work path
- console scaffolding: Creating an application with --framework, --no-plugin,
  --no-git, the files written, first commit and naming convention (D-01)
- console introduction, llms note in site.yaml, root README quick start

docs/console/introduction.md

@@ -10,7 +10,7 @@ WinterCMS has one console entry point, `php artisan`. SummerCMS has two programs
 
 | Program | Where it comes from | What it does |
 |---------|---------------------|--------------|
-| `summer` | Installed once from the framework with `go install ./cmd/summer`. | Builds and watches applications, scaffolds plugins and their parts, records API parity fixtures and builds these docs. |
+| `summer` | Installed once, by the `curl -fsSL https://summercms.io/new \| bash -s -- <name>` one-liner or from a framework checkout with `go install ./cmd/summer`. | Creates, builds and watches applications, scaffolds plugins and their parts, records API parity fixtures and builds these docs. |
 | The application binary, for example `./bin/acme` | Written by `summer build` into the application's `bin/` directory. | Runs the application: the HTTP server, migrations, workers, the scheduler, admin accounts and every command its plugins add. |
 
 The application binary is what you deploy, so everything that must run in production, such as migrations and workers, is a command of the binary rather than of `summer`.
@@ -45,6 +45,6 @@ During development you often work from the application directory with `summer` a
 ## The sections of this chapter
 
 - [Setup and maintenance](setup-and-maintenance.md) lists every command of the application binary.
-- [Scaffolding](scaffolding.md) covers `summer build`, `summer dev` and the `make:` commands.
+- [Scaffolding](scaffolding.md) covers `summer new`, `summer build`, `summer dev` and the `make:` commands.
 - [Writing commands](writing-commands.md) shows how a plugin adds its own commands.
 - [Utilities](utilities.md) covers the parity and documentation commands of `summer`.

docs/console/scaffolding.md

@@ -1,12 +1,12 @@
 ---
 title: Scaffolding
-description: Build and watch an application, and generate plugins, models, migrations, console commands, jobs and admin controllers with the summer make commands.
+description: Create an application with summer new, build and watch it, and generate plugins, models, migrations, commands, jobs and admin controllers.
 section: console
 order: 30
 ---
 # Scaffolding
 
-The `summer` tool builds applications and generates the files a plugin is made of, the way `create:plugin`, `create:model` and the other `create:` commands do in WinterCMS. Every generated file compiles as written, so you can build straight after running a command.
+The `summer` tool creates and builds applications and generates the files a plugin is made of, the way `create:plugin`, `create:model` and the other `create:` commands do in WinterCMS. Every generated file compiles as written, so you can build straight after running a command.
 
 ## Building and watching
 
@@ -22,6 +22,48 @@ summer dev
 
 Do not edit `main.go` or `plugins.gen.go`: `summer build` rewrites them from the manifest.
 
+## Creating an application
+
+`summer new` creates a new application in the current directory, the way `composer create-project` starts a WinterCMS project. It takes the application name and writes `sm-<name>-app`:
+
+```sh
+summer new acme
+```
+
+The name must be lower-case letters and digits, starting with a letter. Go keywords such as `go` or `type`, and the names `main` and `internal`, are refused because the starter plugin package would not compile or could not be imported. `summer new` also refuses any existing `sm-<name>-app`, even an empty directory, and never merges into one. When a step fails after it created the directory, it removes the directory again, so you can rerun the same command.
+
+| Flag | Effect |
+|------|--------|
+| `--framework <path>` | The framework checkout to build against. Without it, `summer new` looks for a sibling `summercms` or `summercms.go` checkout, then the source tree the `summer` binary was built from. [Go modules and workspaces](../architecture/go-modules-and-workspaces.md) describes the detection. |
+| `--no-plugin` | Skip the starter plugin; `summer.yaml` then lists no plugins, and the application still builds and serves. |
+| `--no-git` | Skip `git init` and the first commit. |
+
+The application gets these files:
+
+| File | Contents |
+|------|----------|
+| `go.mod` | Module `git.golem15.com/golem15/sm-<name>-app`, requiring the framework through a relative `replace`. |
+| `go.work` | The workspace with the application and its plugin modules, as relative paths. It is committed. |
+| `summer.yaml` | The manifest: module path, binary name and plugin list. |
+| `config/` | `app.yaml`, `database.yaml`, `http.yaml` and `storage.yaml`, enough for `serve` and `route:list`. |
+| `.env`, `.env.example` | The database DSN and a freshly generated application key. `.env` is readable by its owner only and never committed; `.env.example` lists the variables without the key. |
+| `compose.yaml` | PostgreSQL 16 on `127.0.0.1:54320`, with credentials matching `.env`. |
+| `.gitignore` | `bin/`, `tmp/`, `storage/`, `.env` and `go.work.sum`. |
+| `CLAUDE.md`, `AGENTS.md` | Instructions for AI coding agents: the commands, the layout, the links to the documentation for agents and the naming convention. `AGENTS.md` is a symlink to `CLAUDE.md`. |
+| `plugins/<name>` | The starter plugin `golem15.<name>`, created by the same code as `summer make:plugin` and registered by the same code as `summer plugin:add`. Its `routes.go` answers `GET /` with a JSON greeting. |
+| `main.go`, `plugins.gen.go` | Generated from `summer.yaml`, as `summer build` does. |
+
+Unless you pass `--no-git`, `summer new` initialises a git repository on `main` and commits everything except `.env`. When git has no user name or email configured, that first commit uses the author `SummerCMS <summer@localhost>` and prints a warning; your git configuration is not changed. Finally it prints the next steps to run inside `sm-acme-app`:
+
+```sh
+docker compose up -d --wait
+summer build
+summer migrate
+summer serve
+```
+
+Golem15 names repositories by what they hold: `sm-<name>-app` for an application such as the one `summer new` writes, `sm-<name>-plugin` for a standalone plugin module and `sm-<name>-theme` for a Nuxt or Vue frontend.
+
 ## Creating a plugin
 
 `summer make:plugin` takes a plugin ID in `vendor.plugin` form and creates the plugin module in `plugins/<plugin>` of the current application, with the directory layout described in [Plugin registration](../plugins/registration.md):