Accept the captured declaration architecture and align documentation

docs/roadmap/modules.md

@@ -1,7 +1,8 @@
 # Optional integration modules
 
 Status: module boundary accepted in ADR 0010; implementation planning remains
-in progress and no module extraction has begun. The next minor ReleaseKit
+in progress and no module extraction has begun. The consumer API is finalized
+and its ADR/architecture-policy alignment is complete. The next minor ReleaseKit
 release will support individual module releases; CommandKit adoption is pending.
 
 ## Purpose and authority
@@ -18,9 +19,10 @@ examples. Neither document describes these changes as implemented.
 [ADR 0010](../adr/0010-optional-integration-modules.md) owns the accepted module
 boundary and convenient registration principles; it partially supersedes
 [ADR 0003](../adr/0003-public-facade.md), whose remaining principles still apply.
-Alignment of the [architecture policy](../policy/architecture.md) remains part of
-the work below. GoDoc, the [CLI reference](../cli.md), and the
-[consumer guide](../consumers/guide.md) describe the prototype baseline; they do
+[ADR 0011](../adr/0011-captured-declarations-and-installation.md) records the
+finalized registration and invocation-lifetime decisions. The
+[architecture policy](../policy/architecture.md) is aligned with those decisions.
+GoDoc, the [CLI reference](../cli.md), and the [consumer guide](../consumers/guide.md) describe the prototype baseline; they do
 not make its incidental API shapes compatibility requirements for this sprint.
 
 ## Organizing principle: design the final API
@@ -139,8 +141,8 @@ shapes merely because they already exist.
   signatures and the [input/shared-state separation](registration-api.md#why-inputs-and-shared-state-have-separate-types).
 - Follow the selected [namespace lifetime and reconciliation requirements](registration-api.md#namespace-reconciliation-and-implementation-handoff).
   Built-in help/version remain reserved; optional integration roots are owned
-  when their real family is installed. Complete the identified durable-document
-  alignment before implementing that lifetime.
+  when their real family is installed. ADR 0011 and the architecture policy now
+  record that lifetime; implementation remains pending.
 - Core diagnostics use a small CommandKit-owned severity type. Upstream
   diagnostic conversion belongs in the integrations, preserving selected
   classification, delivery, and error semantics without copying ConfigKit's
@@ -194,17 +196,18 @@ needed for CommandKit's source-only releases.
 
 ## Work sequence
 
-### 1. Align policy and prepare the selected API for implementation
+### 1. Prepare the selected API for implementation
 
 Completed: ADR 0010 is accepted and ADR 0003 is marked partially superseded,
-with its decision text preserved. The partial status follows the explicitly
-authorized exception to the documentation policy for this decision.
+with its decision text preserved. The consumer API is finalized, ADR 0011
+records its registration and input-lifetime choices, ADR 0001 remains accepted
+with refinements recorded in ADR 0011, and ADR 0010's consumer-migration consequence is superseded for the
+unreleased prototype transition. The architecture policy reflects the selected
+core/integration facades and installed-family ownership. Earlier accepted decision text remains
+intact.
 
 - Use the finalized [registration API](registration-api.md) and selected module
   layout as the implementation target before moving public symbols.
-- Align the architecture policy with ADR 0010 and complete the registration
-  API document's namespace reconciliation. Review other ADRs for affected
-  ownership statements without reopening unrelated decisions.
 - Inventory root exports, imports, private helper use, and family registration
   behavior. Use the inventory as evidence of responsibilities and coupling, not
   as a list of APIs to preserve. Implement final exports and ownership from the
@@ -230,8 +233,8 @@ are concrete enough to implement without inventing a general plugin framework.
   supported interactions needed by those integrations. Preserve duplicate
   registration handling and standard-family ownership; audit these boundaries
   rather than assuming package relocation preserves them automatically.
-- Design core outcomes, diagnostics, bindings, and command declarations as shared
-  contracts for the final API. Replace ConfigKit severity in core diagnostics
+- Implement core outcomes, diagnostics, bindings, and command declarations using
+  the finalized API. Replace ConfigKit severity in core diagnostics
   with the selected CommandKit-owned type. Place report encoding and upstream
   diagnostic conversion with their owners. Remove redundant prototype state and
   helpers; avoid copying ConfigKit's data model merely to remove imports.

docs/roadmap/registration-api.md

@@ -18,10 +18,12 @@ completed alternatives comparison is retained in Git history.
 [ADR 0001](../adr/0001-command-dispatch-and-inputs.md) owns explicit registration,
 typed inputs, and command ownership.
 [ADR 0010](../adr/0010-optional-integration-modules.md) owns optional module
-boundaries and convenient integration registration. The
-[module roadmap](modules.md) tracks extraction work. Reconcile the namespace
-lifetime decision below with the relevant ADR and architecture-policy wording
-before implementation; this API design does not silently rewrite those records.
+boundaries and convenient integration registration.
+[ADR 0011](../adr/0011-captured-declarations-and-installation.md) records the
+captured-declaration model, optional-family namespace lifetime, and separated
+input/shared-state lifetimes. The [architecture policy](../policy/architecture.md)
+reflects those boundaries. The [module roadmap](modules.md) tracks extraction
+work; this API design remains a target rather than implemented behavior.
 
 Design for the best consumer API without preserving current implementation
 signatures or machinery. Existing code can supply evidence and reusable work,
@@ -200,9 +202,9 @@ Scope-specific parsed values stay separate from shared acquisition state through
 the selected `Suite[I, S]`: `NewInput` initializes each selected scope's input,
 while `NewState` initializes `S` once for the selected inspection invocation.
 Providers receive both explicitly. Pointer inputs are independently initialized,
-not shallow copies of a single pointer. The detailed lifetime table below makes
-this change from the comparison's mixed context model explicit; it does not
-require arbitrary deep copies or prohibit pointer inputs or shared pointer state.
+not shallow copies of a single pointer. The detailed lifetime table below
+spells out those calls without requiring arbitrary deep copies or prohibiting
+pointer inputs or shared pointer state.
 
 ## Selected core declarations
 
@@ -1208,19 +1210,18 @@ is installed. An absent/no-op family reserves nothing. A domain group using an
 uninstalled integration name is permitted, but blocks later installation of the
 same root with a collision. Root-only placement is independent of that lifetime.
 
-This clarifies an ambiguity rather than assuming that earlier broad reservation
-wording already specifies the same lifetime. The durable documents need deliberate
-alignment before implementation:
+The documentation alignment is complete:
 
-| Owner | Required alignment before implementation |
+| Owner | Recorded decision |
 | --- | --- |
-| ADR 0001 | Clarify the reservation lifetime through the ADR change process if its accepted wording is interpreted as unconditional reservation |
-| ADR 0010 | Retain core/integration dependency and convenient-composition boundaries; exact factories now return captured declarations |
-| Architecture policy | State installed-family ownership uniformly for config and promptkit; align its public facade rules with ADR 0010 |
-| Staged module implementation plan | Specify eager capture, error retention, neutral bindings, scope isolation, examples, and release adoption using this finalized API |
+| [ADR 0011](../adr/0011-captured-declarations-and-installation.md) | Captured declarations, atomic installation batches, installed-family ownership, root-only placement, and separate input/shared-state lifetimes |
+| [ADR 0001 status](../adr/0001-command-dispatch-and-inputs.md#status) | Remains accepted, with refinements recorded in ADR 0011 and its decision text preserved |
+| [ADR 0010](../adr/0010-optional-integration-modules.md) | Core/integration dependency boundaries remain in effect; ADR 0011 refines registration and supersedes the migration-guide requirement for this unreleased prototype |
+| [Architecture policy](../policy/architecture.md) | Uniform installed-family ownership, optional integration facades, and declaration/input boundaries |
+| [Module roadmap](modules.md) | Final API selected; documentation alignment completed; extraction and release adoption still pending |
 
-A new or superseding ADR can record the lifetime clarification where needed;
-accepted decision text is not revised silently. The [module roadmap](modules.md)
-now references this finalized API. Policy/ADR reconciliation and a staged
-implementation plan remain pending; this document does not claim that those
-records are already aligned or authorize implementation.
+A staged module implementation plan remains to be written from this finalized
+API and the module roadmap. It should specify eager capture, error retention,
+neutral bindings, scope isolation, maintained examples, and release adoption.
+The documentation alignment neither implements these changes nor authorizes
+implementation by itself.