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.