Align discovery ownership and contributor documentation

docs/roadmap/discovery.md

@@ -1,10 +1,10 @@
 # Composable Configuration Discovery Roadmap
 
-Status: proposal with OD-1 through OD-5 and the final review clarifications
-settled and integrated below.
-This document describes future work, not an implemented contract. The
-[implementation plan](implementation.md) owns the staged work and concrete API
-decisions.
+Status: implemented. This document preserves the design rationale and agreed
+direction. The [configuration contract](../config.md#configuration-discovery)
+owns current behavior, [ADR 0019](../adr/0019-explicit-configuration-discovery.md)
+records the decision, and the [implementation plan](implementation.md) records
+the completed work sequence.
 
 ## Purpose And Ownership
 
@@ -24,23 +24,22 @@ Discovery selects one source for the existing loading lifecycle. It does not
 create additional configuration tiers or merge every matching file. Existing
 layered loading remains available when consumers intentionally combine sources.
 
-## Current Baseline
+## Baseline Before Implementation
 
-The [source contract](../config.md#sources) provides explicit host files, native
-filesystem files, bytes, readers, mappings, and `NoSource()`. A missing explicit
-file fails. The zero source is invalid. There is no conventional main-file search.
+Before this work, sources included explicit host files, native filesystem files,
+bytes, readers, mappings, and `NoSource()`, with no conventional main-file search.
+That baseline also restricted `NoSource()` with imports and overlays. The
+implemented discovery behavior now lets an exhausted optional search follow the
+absent-main lifecycle, including enabled imports and an active overlay when its
+required explicit context is supplied. The current [source contract](../config.md#sources),
+[single-source loading](../config.md#single-source-loading), and
+[layered loading](../config.md#layered-loading) sections define the behavior;
+this baseline is retained only to explain the original design problem.
 
-[Ordinary loading](../config.md#single-source-loading) infers a selected overlay's
-filesystem context from the main source. `NoSource()` currently rejects enabled
-imports, active overlays, and filesystem context. In
-[layered loading](../config.md#layered-loading), an absent main input can coexist
-with underlays; a selected overlay requires an explicit `OverlayFilesystem`.
-These distinctions matter when an optional search finds nothing.
-
-The [architecture policy](../policy/architecture.md#responsibility-boundaries)
-assigns search conventions to consumers and currently excludes implicit main-file
-discovery. The addition should clarify that consumers may explicitly select
-library-provided search conventions. Consumer ownership remains unchanged.
+Applications still choose search conventions and ordering. The architecture
+policy now distinguishes those consumer choices from explicitly selected search
+descriptions resolved during loading, while continuing to exclude implicit
+discovery and network acquisition.
 
 ## Agreed Direction
 
@@ -92,11 +91,10 @@ Different directories may select different lists, so ordered expansion and
 concatenation describes the complete model. Set union does not express its
 precedence semantics.
 
-The eventual documentation should explain this model using the applicable
-mathematical nomenclature: ordered lists, ordered concatenation, and Cartesian
-product where a shared filename list applies. Retain these names in relevant
-implementation comments where they help readers understand the operations. The
-model describes ordering without requiring eager construction of every candidate.
+The [configuration contract](../config.md#configuration-discovery) explains this
+model using ordered lists, ordered concatenation, and the directory-first
+Cartesian product where a shared filename list applies. These terms describe
+ordering without requiring eager construction of every candidate.
 
 ### Unix System Preset
 
@@ -242,8 +240,8 @@ platform's convention. User, home, and working-directory presets use their nativ
 Go directory helpers.
 
 This keeps search priority predictable when directory resolution fails. Consumers
-select the presets appropriate to their application and environment; this proposal
-does not add an option to skip unavailable bases or unsupported presets.
+select the presets appropriate to their application and environment; there is no
+option to skip unavailable bases or unsupported presets.
 
 ### No Match, Imports, And Selected Overlays (OD-3 — Settled)
 
@@ -273,10 +271,9 @@ the normal lifecycle. Main-version checking receives an absent main input and
 may reject it under the application's existing policy. Create no synthetic empty
 document or source record for the absent main file.
 
-This deliberately relaxes the current `NoSource()` restrictions on imports and
+This deliberately relaxes the former `NoSource()` restrictions on imports and
 on overlays with explicit context. Both ways of obtaining an absent main input
-have the same behavior. Implementation must cover this lifecycle change as well
-as candidate selection.
+have the same behavior, as defined in the [configuration contract](../config.md#configuration-discovery).
 
 ### Empty Composition And Implicit Preset Selection (OD-4 — Settled)
 
@@ -339,8 +336,8 @@ Missing candidates are not acquired sources and do not create source IDs,
 configuration history, or explicit input presence. An entirely absent search
 contributes no synthetic empty configuration file. Diagnostics should distinguish
 an exhausted required search from a failed candidate. Existing selected-source
-inspection remains the foundation; a new public per-attempt trace is not needed
-for this proposal.
+inspection remains the foundation; a new public per-attempt trace is not part of
+the implemented API.
 
 Preserve collection policies, inheritance, source-version rules, CLI ordering,
 final validation, and frozen inspection after selection. Search-list order does

docs/roadmap/implementation.md

@@ -1,6 +1,6 @@
 # Configuration Discovery Implementation Plan
 
-Status: in progress. Stages 1, 2, 3, 4, 5, 6, 7, and 8 are complete.
+Status: in progress. Stages 1 through 9 are complete.
 
 Implement the target behavior in [the discovery roadmap](discovery.md). That
 document owns the selected conventions and OD-1 through OD-5; this plan owns the
@@ -402,7 +402,7 @@ Acceptance: representative consumers need no application-side fallback loader
 or provenance reconstruction. Run maintained consumer tests, relevant executable
 examples, and the everyday check. Mark and commit.
 
-## Stage 9 — Align Architecture And Contributor Documentation
+## Stage 9 — Align Architecture And Contributor Documentation (Complete)
 
 1. Update the architecture policy's responsibility boundary narrowly: applications
    choose main-file conventions; explicit library-provided searches execute