docs: establish module versioning boundaries (#4)

Record the accepted rule for root-module versions and nested modules
for heavy dependencies or independent releases. Update repository
instructions and link implementation evidence to the ADR.

Closes #2

docs/adr/20261025T214616275Z-version-light-core-packages-in-the-root-module-and-nest-heavy-dependency-modules.md

@@ -0,0 +1,51 @@
+---
+title: "Version light core packages in the root module and nest heavy-dependency modules"
+date: 2026-10-25
+status: accepted
+implementation: implemented
+summary: Keep light core packages on root-module versions and isolate heavy or independently versioned packages in nested modules from their first commit.
+tags:
+  - modules
+  - versioning
+supersedes: []
+superseded_by: []
+related: []
+tracking:
+  - https://gitea.auvem.com/corestack/go/issues/2
+implemented_by:
+  - https://gitea.auvem.com/corestack/go/pulls/4
+---
+
+# Version light core packages in the root module and nest heavy-dependency modules
+
+## Context and Problem Statement
+
+The repository currently has one Go module, `go.auvem.com/corestack`. A plain `vX.Y.Z` tag versions every package in that module together and triggers a release of the `docs` binary. Light core packages can share this version stream and one changelog per tag; packages with heavy dependencies or independent release needs benefit from their own module boundaries.
+
+Carving a package out after it has shipped in the root module is the expensive case: older root versions still contain it, while the new nested module supplies the same import path. Consumers can encounter ambiguous imports until coordinated releases and dependency upgrades remove the overlap. Starting a package as a nested module from its first commit avoids that migration.
+
+The fixed dependency list in AGENTS.md described only the docs checker. It would block the planned Bob and Goose dependencies for `page` and `migrate`; dependency placement needs a module-boundary rule instead of a repository-wide allowlist.
+
+## Considered Options
+
+* Keep every package in the root module: simplest releases, but couples heavy and independently versioned packages to core releases and makes later extraction costly.
+* Give every package a nested module immediately: avoids later extraction, but adds module and release bookkeeping to light core packages that can share a version.
+* Keep light core packages in the root module and start heavy or independently versioned packages as nested modules: retain simple core releases while avoiding the costly extraction case.
+
+## Decision Outcome
+
+Choose the mixed boundary: light core packages share the root module; heavy-dependency or independently versioned packages begin as nested modules.
+
+* Root module, plain `v*` tags: `lifecycle`, `lifecycle/cli`, `migrate`, `page`, and `cmd/docs`. They share one version stream and one changelog per root tag. Before 1.0, breaking changes use minor version bumps.
+* Nested modules from their first commit: `gql`, `connect`, and any future package that brings heavy dependencies, such as gqlgen or protobuf, or is likely to need independent versioning. Each has its own `go.mod` and directory-prefixed tags, for example `gql/v0.1.0` and `connect/v0.1.0`.
+* Add dependencies only to the module that needs them. The named core packages remain in the root module; heavy dependencies belong in the relevant nested module.
+* Keep `cmd/docs` in the root module. The [release workflow](/.gitea/workflows/release.yml) listens only for plain `v*` tags, and [GoReleaser](/.goreleaser.yaml) builds `./cmd/docs`, so only root-module tags publish binaries. Prefixed library tags never publish binaries.
+
+This decision establishes the boundary before the planned packages are added. The rule is implemented in [AGENTS.md](/AGENTS.md), and the existing release configuration already follows it. Future packages apply the rule when introduced; no empty modules are needed.
+
+### Consequences
+
+* Light core packages retain coordinated versions and releases. Consumers do not compile dependencies of packages they do not import; module graph pruning helps limit the dependency graph they load.
+* Heavy-dependency and independently versioned packages avoid overlapping ownership of an import path with older root-module versions.
+* Each nested module needs its own dependency maintenance, checks, and prefixed release tags. That bookkeeping is reserved for packages that need the boundary.
+* Root-module consumers share version bumps even when only another core package changes. Moving a shipped root package into a nested module later still requires coordinated releases and consumer upgrades.