Accept optional integration modules architecture

docs/roadmap/modules.md

@@ -1,6 +1,7 @@
 # Optional integration modules
 
-Status: proposed implementation roadmap; no module extraction has begun.
+Status: module boundary accepted in ADR 0010; implementation planning remains
+in progress and no module extraction has begun.
 
 ## Purpose and authority
 
@@ -11,11 +12,13 @@ module dependencies. ConfigKit-only consumers should not acquire PromptKit.
 
 This roadmap records the targeted end state, selected module layout, and
 migration work. Recommendations under [Open Decisions](#open-decisions) remain
-proposals. It does not supersede accepted ADRs or describe these changes
-as implemented. The [architecture policy](../policy/architecture.md) and
-[ADR 0003](../adr/0003-public-facade.md) govern the current boundary; an accepted
-successor decision is needed before changing it. Current contracts remain in
-GoDoc, the [CLI reference](../cli.md), and the
+proposals. It does not describe 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. Current implemented contracts remain in GoDoc, the
+[CLI reference](../cli.md), and the
 [consumer guide](../consumers/guide.md).
 
 ## Current baseline
@@ -108,21 +111,24 @@ is an intentional consumer migration.
 
 ## Work sequence
 
-### 1. Settle boundaries and record the decision
+### 1. Align policy and settle implementation boundaries
+
+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.
 
 - Resolve the remaining choices under Open Decisions before moving public
   symbols, using the selected module paths and package names above.
-- Create a successor ADR for the changed facade/module boundary and mark
-  ADR 0003 superseded according to the
-  [documentation policy](../policy/documentation.md#architecture-decision-records).
-  Preserve its decision history. Align the architecture policy and review other
+- Align the architecture policy with ADR 0010 and review other
   ADRs for affected ownership statements without reopening unrelated decisions.
 - Inventory root exports, imports, private helper use, and family registration
   behavior. Assign each to core or an integration; document the consumer-facing
   old-to-new API mapping rather than freezing a full inventory in this roadmap.
 - Sketch three representative consumers: core only, ConfigKit only, and both
   libraries. Confirm that combined configuration scopes remain straightforward
-  and that moving code does not replace removed boilerplate with new plumbing.
+  and that registration meets ADR 0010's convenience principle without replacing
+  removed boilerplate with new plumbing. Use these examples to evaluate the
+  registration API; no fixed call count or particular options pattern is selected.
 
 Completion: the dependency direction, public migration, and registration approach
 are concrete enough to implement without inventing a general plugin framework.
@@ -220,6 +226,10 @@ Semantic comparison retains the upstream-contract dependency recorded in
 
 ### Registration across the new public boundary
 
+ADR 0010 selects convenient family registration with specialized composition
+where needed. The remaining decision is how to support it across module
+boundaries.
+
 **Recommendation:** first reuse public command/group registration and duplicate
 path checks. Add only a narrow core registration capability if preserving the
 existing standard-family ownership contract requires it. This keeps integrations