docs: add CLAUDE.md and document the release process

AGENTS.md

@@ -0,0 +1 @@
+CLAUDE.md

CLAUDE.md

@@ -0,0 +1,57 @@
+# Sprout
+
+Sprout is a programmable UEFI bootloader written in Rust, for `x86_64` and `aarch64`. It is a `no_std` workspace
+built for the `*-unknown-uefi` targets, so it cannot be run or tested like a normal binary.
+See [README.md](README.md) for the configuration format and features.
+
+## Layout
+
+- `crates/boot`: the bootloader entrypoint (`edera-sprout-boot`).
+- `crates/bls`: Boot Loader Specification parsing and sorting.
+- `crates/build`: build logic.
+- `crates/config`: serialization structures for the Sprout configuration file.
+- `crates/eficore`: core EFI helpers.
+- `crates/parsing`: value stamping and other parsing helpers.
+- `hack/`: build and dev scripts; `hack/dev` boots QEMU, `hack/dev/run` drives it headless.
+- `docs/setup`: setup guides for signed and unsigned installs.
+
+The crate list and the scripts are described in [DEVELOPMENT.md](DEVELOPMENT.md).
+
+## Building and checking
+
+The toolchain and both UEFI targets are pinned in `rust-toolchain.toml`. Always pass a UEFI target, as the
+host target will not build.
+
+```bash
+cargo build --target x86_64-unknown-uefi
+cargo clippy --target x86_64-unknown-uefi
+cargo fmt --all
+./hack/assemble.sh
+```
+
+CI runs `cargo fmt --check`, `cargo build` and `cargo clippy` for both targets, so run these for both
+`x86_64` and `aarch64` before opening a PR. `./hack/autofix.sh` applies clippy and rustfmt fixes.
+
+To try a change in a real environment, use `./hack/dev/boot.sh [arch]`, or the scripts in `hack/dev/run`
+(for example `smoke.sh`) when there is no terminal or window to use.
+
+## Conventions
+
+- Write code that matches the surrounding code, including naming, idioms and comment style.
+- Dependencies are declared in the root `Cargo.toml` under `[workspace.dependencies]`.
+- GitHub Actions are pinned to a commit SHA with the version in a comment.
+
+## Commits and pull requests
+
+- Do not add coding agent attribution anywhere. No `Co-Authored-By` trailers, no "Generated with" lines, in
+  commits or in PR descriptions.
+- Commits use [Conventional Commits](https://www.conventionalcommits.org/), in the form `type(scope): subject`,
+  for example `fix(boot): count tries without using them`. Types in use are `feat`, `fix` and `docs`, and
+  scopes are usually a crate name such as `boot`, `bls` or `eficore`, or `ci`, `hack` and `readme`.
+- PR titles are also conventional commits, because PRs are squashed. The only exception is a release PR,
+  which is titled `sprout: version x.y.z`.
+- Keep PR descriptions short prose.
+
+## Releasing
+
+See [RELEASING.md](RELEASING.md). A release PR only bumps the version in `Cargo.toml` and `Cargo.lock`.

DEVELOPMENT.md

@@ -74,3 +74,7 @@ coding agents. QEMU runs in the background with a QMP socket, and its consoles a
 - `smoke.sh [arch]`: Starts, drives the graphical menu, waits for the Linux shell and stops.
 
 `boot.sh` supports this with `QEMU_HEADLESS`, `QEMU_QMP`, `QEMU_SERIAL_FILE`, `QEMU_CONSOLE_FILE` and `QEMU_EXTRA_ARGS`.
+
+## Releasing
+
+Maintainers cut releases as described in [RELEASING.md](RELEASING.md).

RELEASING.md

@@ -0,0 +1,36 @@
+# Releasing Sprout
+
+This describes how a maintainer cuts a release of Sprout. A release is a signed tag plus a GitHub release
+that holds the built EFI binaries and their attestations.
+
+The release is built and published by the `release` workflow, so the release is never visible
+until its artifacts are attached.
+
+## Steps
+
+1. Bump `version` in the `[workspace.package]` section of `Cargo.toml` to the new version, then run
+   `./hack/assemble.sh` to update `Cargo.lock`.
+
+2. Open a pull request with the result. The commit and the PR title are `sprout: version x.y.z`, which is the
+   one place we do not use a conventional commit. Once squashed, the commit on `main` is
+   `sprout: version x.y.z (#PR_NUMBER)`.
+
+3. Once the PR has merged, create a signed tag on the merged commit. The tag message is just the tag name.
+
+   ```bash
+   git tag -s v0.0.8 -m v0.0.8
+   git push origin v0.0.8
+   ```
+
+4. Draft a new release on GitHub for that tag, named after the tag, and click Generate Release Notes.
+   Add a blank line after every section header, as GitHub does not always do that. **Do not click Publish.**
+
+5. Run the `release` workflow from the Actions tab, selecting the tag as the ref to run from, and set the
+   `Release Tag` input to the tag name (for example `v0.0.8`). The workflow builds the tagged commit,
+   uploads the binaries to the draft release, attests them, and then publishes the release.
+
+## Notes
+
+- The release workflow builds the tag, not the branch it was dispatched on, so check the tag points at the
+  version bump commit before running it.
+- Re-running the workflow for the same tag replaces the uploaded assets, and runs for one tag never overlap.