Adopt shared policies and align ReleaseKit documentation and licensing

docs/roadmap/policy.md

@@ -1,21 +1,21 @@
 # Adopt the policy framework
 
-Status: Proposed; adoption has not started.
+Status: Policy adoption complete. Release publication implementation is pending.
 
 Date: 2026-10-05
 
 ## Purpose and scope
 
-Adopt Standard Repository Policies into ReleaseKit as locally maintained rules
-for an opinionated Go library and its proposed release executable. The adoption
-should preserve the project's existing licensing choice, support deliberate
-standardization of release behavior, and keep documentation accurate about what
+Standard Repository Policies are adopted into ReleaseKit as locally maintained
+rules for an opinionated Go library and its proposed release executable. The
+adoption preserves the project's existing licensing choice, supports deliberate
+standardization of release behavior, and keeps documentation accurate about what
 has been implemented.
 
 This roadmap covers policy adoption, contributor navigation, documentation
 ownership, licensing notices, and the preparation of ReleaseKit's own release
 procedure. Product implementation and consumer migrations belong to the separate
-[ReleaseKit proposal](../../ideas.md).
+[ReleaseKit proposal](releasekit.md).
 
 ## Upstream baseline and references
 
@@ -36,7 +36,7 @@ of adaptation rather than copying their product-specific requirements.
 
 ## Policy adaptations
 
-Adopt all seven policies under `docs/policy/`:
+All seven policies are adopted under `docs/policy/`:
 
 | Policy | Base version | ReleaseKit adaptation |
 | --- | --- | --- |
@@ -48,11 +48,11 @@ Adopt all seven policies under `docs/policy/`:
 | `oss.md` | 1.8 | Preserve the library licensing choice, apply the attribution format, and identify separately licensed copied policy material. |
 | `release.md` | 1.4 | Govern releases of ReleaseKit itself, with explicit deliverables and justified checks. Distinguish its maintainer procedure from the release standard offered to consumers. |
 
-## Proposed architectural constraints
+## Adopted architectural constraints
 
-The public facade decision is accepted in
-[ADR 0001](../adr/0001-public-facade.md). Policy adoption will incorporate that
-decision alongside the remaining proposed constraints below.
+The [architecture policy](../policy/architecture.md) owns the adopted boundaries,
+including [ADR 0001](../adr/0001-public-facade.md) and the runtime version
+constraints. The following summarizes those rules for this adoption record.
 
 Evaluate ReleaseKit against both of ConfigKit's relevant success criteria:
 applications should delete substantial infrastructure, and consumers should adopt
@@ -82,41 +82,42 @@ API semantics, and implemented behavior must be documented when they exist.
 
 ### 1. Copy and tailor policies
 
-- [ ] Copy the seven policies from the selected baseline.
-- [ ] Preserve each `Base Policy Version`, set `Last Updated` to the actual
+- [x] Copy the seven policies from the selected baseline.
+- [x] Preserve each `Base Policy Version`, set `Last Updated` to the actual
   adoption date, and add an `Upstream Source` link to that file at the full commit.
-- [ ] Customize the policies for ReleaseKit and remove their `Base Policy
+- [x] Customize the policies for ReleaseKit and remove their `Base Policy
   Template` sections.
-- [ ] Adapt upstream `agents/AGENTS.md` into root `AGENTS.md`, preserving the
+- [x] Adapt upstream `agents/AGENTS.md` into root `AGENTS.md`, preserving the
   existing knowledge-graph discovery instructions.
-- [ ] Create `docs/development.md` with contributor orientation and the selective
+- [x] Create `docs/development.md` with contributor orientation and the selective
   policy reading guide. Route tasks to applicable policies instead of requiring
   the entire suite for every task.
 
 ### 2. Establish documentation ownership
 
-- [ ] Move the substantive contents of `ideas.md` to
+- [x] Move the substantive contents of `ideas.md` to
   `docs/roadmap/releasekit.md`, preserving the proposal, and retain `ideas.md` as a
   navigation pointer. Update this roadmap's proposal link in the same change.
-- [ ] Update README with accurate current status and navigation.
-- [ ] Define ownership for GoDoc, consumer guidance, architecture constraints,
+- [x] Update README with accurate current status and navigation.
+- [x] Define ownership for GoDoc, consumer guidance, architecture constraints,
   internal implementation, release procedures, ADRs, and unfinished work.
-- [ ] Create consumer, CLI, configuration, integration, and internal documents
-  when substantive implemented responsibilities justify them. Avoid empty owners
-  and speculative command or API references.
+- [x] Reserve consumer, CLI, configuration, integration, and internal ownership
+  in the documentation policy. Their documents await corresponding implementation;
+  no empty owners or speculative command references were created.
 
 ### 3. Complete notices and attribution
 
-- [ ] Add root `COPYRIGHT` using the upstream library example and verified project
-  details. The recommended grant is `LGPL-3.0-or-later`, consistent with the two
-  library examples; preserve any established author choice.
-- [ ] Verify the existing LGPLv3 and incorporated GPLv3 texts in `LICENSE` are
-  complete and faithful. Keep project-specific grant statements in `COPYRIGHT`.
-- [ ] Add `docs/oss/attribution.md` with the supplied policy attribution entry,
+- [x] Add root `COPYRIGHT` using the upstream library example and verified project
+  details. The grant is `LGPL-3.0-or-later`, consistent with the existing library
+  licensing choice and the two library examples.
+- [x] Restore the complete, verbatim LGPLv3 and incorporated GPLv3 texts in
+  `LICENSE`; the original contained reformatted text and a customized appendix.
+  Keep project-specific grant statements in `COPYRIGHT`.
+- [x] Add `docs/oss/attribution.md` with the supplied policy attribution entry,
   describing the actual adapted policies, agent orientation, and reading guide.
-- [ ] Copy the CC-BY-SA 4.0 text to `docs/oss/licenses/CC-BY-SA-4.0.txt` and identify
+- [x] Copy the CC-BY-SA 4.0 text to `docs/oss/licenses/CC-BY-SA-4.0.txt` and identify
   the copied material's separate licensing scope in `COPYRIGHT`.
-- [ ] Add README links to the project grant and attribution document. Keep source
+- [x] Add README links to the project grant and attribution document. Keep source
   and notice links pinned to the adopted commit and reference examples upstream.
 
 The library's selected license remains the project grant. A future executable
@@ -125,18 +126,24 @@ policy has separate defaults for applications and libraries.
 
 ### 4. Define ReleaseKit's own release path
 
-- [ ] Adopt the general versioning, compatibility, integrity, immutability, and
+- [x] Adopt the general versioning, compatibility, integrity, immutability, and
   successful-tag-push completion rules.
-- [ ] Select ReleaseKit's own deliverables explicitly. Supporting downstream
-  cross-builds does not by itself require ReleaseKit to distribute binaries.
+- [x] Select source only as ReleaseKit's initial deliverable in the release
+  policy. Supporting downstream cross-builds does not declare ReleaseKit binaries.
 - [ ] Add `docs/release.md` alongside the first working publication command,
   documenting real prerequisites, authoritative remote, branch, validation,
   publication, and failure recovery.
-- [ ] Account for the first-release bootstrap before a released ReleaseKit tool
-  is available for its own publication.
+- [x] Account for first-release bootstrap: the initial publication command must
+  run from the captured candidate source with dependencies prepared separately.
+  The first release uses that source execution path before a released ReleaseKit
+  tool exists. Document and verify the actual command when it is implemented.
 - [ ] Add executable delivery declarations and target checks when corresponding
   deliverables exist. Keep source completion and asynchronous delivery status
-  separate.
+  separate. This task is deferred unless executable deliverables are selected.
+
+The publication command, its automated guards and offline candidate validation,
+and the executable maintainer runbook remain product implementation work. This
+adoption does not claim an available release command or perform publication.
 
 ## Validation and completion
 
@@ -154,3 +161,18 @@ Do not inherit PromptKit's or ConfigKit's extra release gates automatically.
 Select additional checks only for identified ReleaseKit risks, recording their
 justification in the adopted policy. Upstream synchronization, recurring license
 approval, and CI polling are not additional adoption or release gates.
+
+## Adoption result
+
+The seven policies, root agent orientation, developer reading guide, documentation
+ownership, project grant, attribution, and license texts are in place. The product
+proposal lives at `docs/roadmap/releasekit.md`; `ideas.md` remains a navigation
+pointer. Future capabilities retain their proposed status, and facade
+implementation remains pending in the product roadmap.
+
+Verification covers local file and fragment links, per-policy source revision and
+base version, removed template adoption sections, attribution scope and pinned
+notice destinations, verbatim license bytes, and prose whitespace. The preserved
+ADR decision and relocated proposal are checked against their pre-adoption source.
+Release automation and its runbook remain pending under stage 4 as permitted by
+this roadmap's completion criteria.