Integrate selected builds with candidate workflows

docs/cli.md

@@ -1,6 +1,6 @@
 # Command line
 
-ReleaseKit currently provides three commands.
+ReleaseKit currently provides four commands.
 
 Print the executable version:
 
@@ -49,3 +49,26 @@ errors, and 3 when the push outcome remains unknown. Unknown status must be
 resolved against the authoritative remote before retrying. The
 [maintainer procedure](release.md) selects the repository profile and gives
 the source-release workflow.
+
+Build selected application targets:
+
+```sh
+go run ./cmd/releasekit build [--repo DIR] [--config FILE] [--output DIR] VERSION
+```
+
+`build` requires a `build` object in the profile. It compiles the selected
+targets with the requested version injected, checks the native `version`
+invocation, and writes binaries plus the private `.releasekit-build.json`
+receipt into `dist` by default. `--output` selects a different directory;
+relative paths are resolved from the repository. Existing files with a selected
+artifact name are preserved and cause an error. A complete nonempty build
+writes a receipt only after compilation and smoke checking succeed. On partial
+failure, standard error lists completed outputs and no receipt is written. An
+empty target list returns the source commit without building or writing a
+receipt.
+
+The command returns status 0 on completion, 1 for build or output failure, and
+2 for usage, profile, or invalid-version errors. It builds the current source
+tree and does not perform candidate validation or remote publication. `check`
+and `publish` run the same configured build after their one candidate
+validation, using temporary output outside the worktree.

docs/config.md

@@ -11,6 +11,7 @@ The current profile fields are:
 | `product` | Yes | Product name used by release operations. |
 | `remote` | No | Selected Git remote; defaults to `origin`. |
 | `checks` | No | Ordered child commands, each with an argument vector and optional environment map. |
+| `build` | No | Optional main package, binary name, and selected `GOOS/GOARCH` target strings. |
 
 Each check requires a nonempty `args` array whose first element names the
 executable. Arguments are passed directly to the child process; ReleaseKit does
@@ -18,14 +19,20 @@ not parse a shell command string. Select a shell explicitly when a check needs
 shell syntax. Each `env` map overlays the current environment for that child.
 The overlay does not modify the ReleaseKit process environment.
 
-Unknown fields are rejected so a setting cannot be silently ignored. Build and
-delivery fields will be added when those operations are implemented. The `check`
-and `publish` commands use `product`, `remote`, and `checks`. If `checks` is
+Unknown fields are rejected so a setting cannot be silently ignored. The
+`build` object contains `main_package`, `binary_name`, and `targets`. A selected
+target requires the package and binary name; each target is written as one
+`GOOS/GOARCH` pair. An omitted or empty target list means no binary work.
+
+The `check` and `publish` commands use `product`, `remote`, and `checks`, and
+build selected targets after the single validation callback. If `checks` is
 omitted or empty, it runs `go test -mod=readonly -count=1 ./...` with Go module
 and toolchain network access disabled. If checks are configured, they replace
-that default and run in order.
+that default and run in order. The `build` command uses the selected build
+settings and writes binaries to `dist` unless `--output` selects another path.
 
 ReleaseKit's source-only publication profile is
 [releasekit.json](../releasekit.json).
-See the [profile example](../examples/releasekit.json). The
+See the [source-only profile](../examples/releasekit.json) and
+[binary profile](../examples/releasekit-binary.json). The
 [CLI contract](cli.md) lists the currently available command.

docs/consumers/build.md

@@ -60,3 +60,9 @@ An empty target list records the source commit and returns without invoking Go,
 creating the output directory, or running a version check. It does not require a
 main package or binary name. This supports source-only operations without
 silently adding a binary check.
+
+The [`build` command](../cli.md) reads the same build specification from the
+profile and writes a private receipt alongside its artifacts. `check` and
+`publish` run selected builds after their one validation callback using
+temporary output outside the worktree; those candidate checks do not write a
+receipt or leave build files in the repository.

docs/internal/overview.md

@@ -25,7 +25,8 @@ Implemented internal packages:
 - `internal/publish` coordinates local and remote guards around one validation
   run and reports the publication state reached by that invocation.
 - `cmd/releasekit/internal/cli` parses implemented commands, loads strict JSON
-  profiles, and adapts configured checks to the process runner.
+  profiles, adapts configured checks, and writes and validates private local
+  build receipts.
 
 The executable controller uses the runtime facade and the command-owned CLI
 adapter. The adapter uses the process runner and imports neither public facade.

docs/roadmap/implementation.md

@@ -1,6 +1,6 @@
 # ReleaseKit staged implementation plan
 
-Status: In progress. Stages 1–10 are complete; later stages remain pending.
+Status: In progress. Stages 1–11 are complete; later stages remain pending.
 
 Date: 2026-10-05
 
@@ -714,7 +714,7 @@ cross-platform execution guarantee is added.
 
 ## Stage 11: Integrate candidate builds and artifact command
 
-Status: Pending. Depends on Stage 10.
+Status: Complete. Depends on Stage 10.
 
 1. Add build profile fields, CLI `build`, and the private artifact receipt.
    Bind receipts to source/build-input identity and generated hashes. Validate

docs/roadmap/releasekit.md

@@ -2,8 +2,8 @@
 
 This is a proposal based on a review of PromptKit, ConfigKit, Audita, Notarius,
 Narratio, and Scriptorium on 2026-09-29. The implementation plan records the
-current implemented boundary; CLI build integration, delivery, and broader
-integrations remain planned. The public facade architecture is accepted in
+current implemented boundary; delivery and broader integrations remain
+planned. The public facade architecture is accepted in
 [ADR 0001](../adr/0001-public-facade.md) and is implemented for runtime version,
 candidate validation, and source publication.
 The [implementation plan](implementation.md) owns ordered stages, execution
@@ -55,9 +55,9 @@ cleanup.
 The [architecture policy](../policy/architecture.md) owns the adopted
 responsibility and dependency rules, including the runtime version boundary.
 The root `releasekit` package provides the public facade for candidate
-validation, source publication, and selected-target builds; CLI build
-integration and delivery remain planned. The separate public `buildinfo`
-package provides lightweight runtime version access.
+validation, source publication, and selected-target builds. Delivery remains
+planned. The separate public `buildinfo` package provides lightweight runtime
+version access.
 
 Each facade owns its public named types and documented contracts. Public
 operations, inputs, outcomes, errors, and callbacks express deliberately