Add public API boundary checks

docs/cli.md

@@ -0,0 +1,13 @@
+# Command line
+
+ReleaseKit currently provides one command:
+
+```sh
+go run ./cmd/releasekit version
+```
+
+It prints `releasekit <version>` followed by a newline and exits with status 0.
+The version comes from [`buildinfo.Version`](consumers/runtime-version.md).
+
+Any other argument sequence prints `usage: releasekit version` to standard
+error and exits with status 2.

docs/consumers/runtime-version.md

@@ -14,11 +14,3 @@ Otherwise it returns the executable's main module version when that metadata is
 available and is not `(devel)`. It returns `dev` when neither source provides a
 release identifier. Applications should use this accessor for version output;
 the runtime implementation and ReleaseKit's builder own the injection detail.
-
-ReleaseKit's current command prints its own runtime version:
-
-```sh
-go run ./cmd/releasekit version
-```
-
-The output has the form `releasekit <version>`.

docs/development.md

@@ -42,10 +42,16 @@ Run the offline Go test suite from the repository root with:
 go test ./...
 ```
 
-The implemented package inventory currently contains the root `releasekit`
-facade and `buildinfo` runtime facade, plus the `cmd/releasekit` executable.
-Orchestration operations are added as their behavior is implemented; see the
-[implementation plan](roadmap/implementation.md) for current progress.
+Run the compiled public API and dependency-boundary checks from the repository
+root with:
+
+```sh
+go run ./internal/apicheck
+```
+
+See the [internal package inventory](internal/overview.md) and
+[implementation plan](roadmap/implementation.md) for current implementation
+progress.
 
 For prose changes, review the diff and check local links, fragment destinations,
 provenance, template residue, and consistency with current repository contents.

docs/internal/overview.md

@@ -0,0 +1,18 @@
+# Internal package inventory
+
+Public facades and their contracts are defined in Go declarations and GoDoc.
+The [runtime consumer guide](../consumers/runtime-version.md) covers application
+usage, and the [CLI contract](../cli.md) covers command behavior.
+
+Implemented internal packages:
+
+- `internal/runtimeinfo` holds the injected version value and selects the
+  executable's main-module version when no injected value is present.
+- `internal/versioncontract` names the linker symbol shared with the future
+  release builder.
+- `internal/apicheck` checks compiled exports with `go/types` and checks import
+  direction. Run it with `go run ./internal/apicheck` from the repository root.
+
+The executable currently imports only the runtime facade. Release orchestration,
+process execution, build, Git, and Gitea implementation packages are introduced
+as their responsibilities are implemented.

docs/roadmap/implementation.md

@@ -481,7 +481,7 @@ guidance and documented the command contract.
 
 ## Stage 3: Protect public contracts and dependency direction
 
-Status: Pending. Depends on Stage 2.
+Status: Complete. Depends on Stage 2.
 
 1. Add a compiled-export boundary checker for both facades using `go list` export
    data and `go/types`. Inspect exported signatures, fields, callbacks, aliases,
@@ -499,6 +499,15 @@ Acceptance: actual exports pass and meaningful negative fixtures fail. Tests
 inspect contracts and imports, with no fixed inventory of future internal
 package names. Extend these checks as subsequent exports land.
 
+Completion evidence: added `internal/apicheck`, which loads compiled exports
+from `go list -deps -export` and inspects signatures, fields, aliases, generic
+constraints, and pointer and value method sets through `go/types`. The checks
+pass for both public facades and enforce internal import direction and the
+runtime dependency boundary. Negative fixtures detect leaked types, aliases,
+callbacks, generic constraints, and promoted implementation methods; a private
+implementation field and selected standard-library contracts pass. Added the
+checker command and internal package inventory to the canonical developer docs.
+
 ## Stage 4: Implement profile loading and command adaptation
 
 Status: Pending. Depends on Stage 3.