Settle collection configuration decisions around simplicity

docs/roadmap/namespaces.md

@@ -4,12 +4,20 @@ Status: feature roadmap; not implemented. The reserved-slash naming convention,
 reference-resolution rules, decisions 1–3 (scope shape, validation, and integrated
 discovery filtering), and decision 4's move to application/operator-supplied
 configuration are accepted target behavior. Decision 5 selects mounted collections
-and shared source-version checking; its remaining policy and API choices are
-tracked in the collection roadmap, subject to the ConfigKit boundary. Exact Go
+and optional source-version checking. Its six configuration decisions are
+accepted in the collection roadmap, subject to the ConfigKit boundary. Exact Go
 names and option types remain delivery details.
 
 ## Purpose
 
+Simplifying configuration is a primary goal of this round: YAML collections
+replace mandatory catalog Go-module imports, unused prompt-version selection is
+removed, and specification declarations are optional. Publishers may declare a
+specification in an entry document without adding headers to every file.
+Conventions should ease authoring without prescribing consumer layout or
+precedence. The [collection roadmap](configuration-collections-mounted-fragments.md)
+owns the configuration decisions and delivery details.
+
 Let consumers select a namespace once and use convenient local names within
 that namespace across PromptKit operations. An assembled engine may contain
 multiple application prompt libraries and provider profile catalogs with
@@ -84,8 +92,8 @@ still the identifier passed to the provider; qualifying the profile ID does
 not modify that value. Both example profiles may retain the configured model
 `google/gemma-4-31b-it`. Different profiles may select the same model with
 different settings. Prompt version labels remain separate from namespaces. The
-selected collection format installs one definition per prompt ID; optional
-request-version handling remains a decision in the collection roadmap.
+selected collection format installs one definition per prompt ID and removes
+request-side version selection and assertions. Optional labels are descriptive.
 
 Retain unqualified and dotted IDs. Existing slash-containing IDs need review:
 those with one slash and nonempty components become qualified identities, while
@@ -137,8 +145,8 @@ The accepted resolution rules, independent of the final scope API, are:
 
 Keep qualification consistent across execution, preparation, request validation,
 prompt/profile inspection, and applicable smoke-test selections. Namespace
-selection must not change request override precedence, the chosen request-version
-semantics, or provider model strings.
+selection must not change request override precedence or provider model strings.
+Prompts resolve by ID alone.
 
 ### Local And Qualified References In One Operation
 
@@ -180,7 +188,7 @@ namespaces are outside the accepted grammar.
 Collection namespace/release metadata and an API for reporting effective
 collection declarations are desired additions. They are distinct from resource
 namespace enumeration. Their configuration shape and specification-version
-handling remain pending in [decision 5](#5-collection-metadata-and-specification-versioning-open).
+handling are accepted in [decision 5](#5-collection-metadata-and-specification-versioning-accepted).
 
 ## Composition And Compatibility
 
@@ -240,7 +248,8 @@ would supply reusable scope and resolution semantics.
 ## Work Not Included In The Initial Proposal
 
 - Package installation, collection registries, and dependency resolution.
-- Caller-selected collection mount points or import alias rewriting.
+- Automatic rewriting of stored references when mounting or renaming collections.
+  Explicit source destinations and namespace selection are supported by proposal 3.
 - Implicit namespace search paths or fallback to whichever resource exists.
 - Namespace-based access control or filesystem isolation.
 - Changes to model names, inference behavior, or configuration precedence.
@@ -250,24 +259,24 @@ if a concrete consumer need emerges.
 
 ## Delivery Outline
 
-1. Resolve decision 5's ConfigKit integration question and audit existing
-   identifier usage against the accepted grammar. Record migration mappings,
-   application provisioning guidance, and any separately required ConfigKit
-   work. Finalize Go names and option types for accepted decisions 1–3.
+1. Adopt the ConfigKit capabilities selected in decision 5 and audit existing
+   identifier usage against the accepted grammar. Record migration mappings and
+   application provisioning guidance. Finalize Go names and option types for
+   the accepted namespace and collection APIs.
 2. Remove automatic catalog inclusion, catalog-module dependencies, and built-in
    profiles under decision 4. Use caller-selected configuration sources and
    update examples/tests to supply their own definitions.
 3. Implement the smallest public scope surface with shared name qualification
    and existing engine collaborators. Cover supported operations consistently.
 4. Add integrated namespace filtering and representative consumer examples.
-   Implement collection metadata/inventory only after decision 5 is resolved.
+   Implement collection metadata/inventory under the accepted decision 5.
 5. Verify compatibility and scoped resolution through focused offline tests,
    following the [testing policy](../policy/testing.md). Update GoDoc, the
    format reference, consumer guide, and relevant internal documentation as
    behavior lands; retire this roadmap when its work is complete.
 
-Acceptance cases for the settled rules; collection metadata/versioning cases
-follow the eventual decision 5:
+Acceptance cases for the settled rules; the collection roadmap owns additional
+configuration and metadata acceptance cases:
 
 - Two prompt scopes resolve the same local name to their respective prompts;
   a missing name never resolves from the other scope or an unqualified entry.
@@ -308,8 +317,8 @@ follow the eventual decision 5:
 
 Decisions 1–3 are accepted; their alternatives are retained as considered but
 not selected. Decision 4 records the accepted change in collection ownership
-and supersedes the earlier catalog-only migration proposal. Decision 5 retains
-the unresolved metadata/versioning question and its alternatives.
+and supersedes the earlier catalog-only migration proposal. Decision 5 records
+the accepted collection configuration direction and links its delivery details.
 
 ### 1. Public Scope Shape (Accepted)
 
@@ -486,9 +495,9 @@ provisioning but preserve some provider-data coupling. The accepted direction
 places optional defaults in consuming applications and removes those core
 dependencies instead.
 
-### 5. Collection Metadata And Specification Versioning (Open)
+### 5. Collection Metadata And Specification Versioning (Accepted)
 
-**Selected direction: [mounted collections](configuration-collections-mounted-fragments.md).**
+**Accepted direction: [mounted collections](configuration-collections-mounted-fragments.md).**
 Proposal 3 is the active configuration roadmap. It uses collection-local mapping
 keys, one installed definition per prompt, and an optional flat prompt version.
 Input destinations, relative imports, and shared source-version checks are
@@ -515,8 +524,15 @@ collection declarations captured by the engine, not historical manifests or
 proof of unchanged published releases. Source explanation remains ConfigKit's
 inspection concern.
 
-**Still open:** the [six remaining PromptKit decisions](configuration-collections-mounted-fragments.md#remaining-promptkit-decisions)
-cover main declaration requirements, exposing stricter checking, resources named
-`version`, request-version assertions, cross-collection inheritance, and consumer
-APIs/packaging. Selecting proposal 3 and retiring its alternatives does not settle
-those choices. Removal of bundled catalogs and built-in profiles remains accepted.
+The [six configuration decisions](configuration-collections-mounted-fragments.md#accepted-configuration-decisions)
+are now accepted: optional main declarations, if-present checking without a new
+strict-mode option, no global ban on resources named `version`, removal of
+request-version machinery, existing ConfigKit inheritance, and flexible source
+assembly with a small convenience API. Entry names and layouts are conventions;
+consumers retain source and precedence choices. Cross-path inheritance and
+stricter header options are deferred, not prerequisites.
+
+No configuration-policy question remains open from that discussion. Exact API
+signatures, metadata representations, dependency release selection, and migration
+examples remain [delivery details](configuration-collections-mounted-fragments.md#remaining-delivery-details).
+Removal of bundled catalogs and built-in profiles remains accepted.