Move option source construction into the internal engine

docs/internal/capacity.md

@@ -14,7 +14,7 @@ stable JSON values.
 
 ## Construction And Pool Lifecycle
 
-Each root `NewEngine` call obtains a normalized capacity-policy snapshot from
+Each internal engine construction obtains a normalized capacity-policy snapshot from
 its immutable backend registry and constructs a new `Manager`. The manager
 creates one pool for each limited backend ID. It has no package-global mutable
 state, background workers, shutdown protocol, or persistence, so engines with

docs/internal/llm.md

@@ -10,7 +10,7 @@ owns the observable outbound HTTP contract. The
 [framework format reference](../formats.md) owns the profile and prompt
 settings consumed by the client.
 
-The concrete client remains under `internal/llm`. The root engine assembles it
+The concrete client remains under `internal/llm`. The internal engine assembles it
 as the default implementation behind Promptkit's public client boundary.
 
 ## Components And Flow

docs/internal/overview.md

@@ -30,7 +30,7 @@ contributor workflow and validation.
 | `internal/llm` | Defines the internal generation boundary and implements outbound OpenAI-compatible chat requests from resolved execution targets, including bounded structured non-success response decoding, successful-response decoding, authentication, deadline handling, and ownership of the OpenAI-compatible reserved request-field policy. | [Internal model client](llm.md) |
 | `internal/usecase` | Resolves prompt definitions and hashes, profiles, backends, and targets for exact inspection and request settings for preparation, and coordinates ordinary execution and one-attempt prepared execution across internal sources, rendering, artifact loading, operation-local validation plans, generation, capacity, and bounded repair. | [Internal runner](runner.md), [prepared-execution implementation](../../internal/usecase/prepared_execution.go) |
 
-The root package assembles these internal components without exposing their
+The internal engine assembles these internal components without exposing their
 representations. Consumers depend only on the root facade.
 
 ## Maintenance

docs/internal/sources.md

@@ -69,7 +69,7 @@ repositories described above.
 `internal/catalog` validates the imported immutable OpenRouter and
 Rakestrawhome asset modules as one private adapter boundary. It enforces their
 manifest, layout, profile ownership, inheritance, and secret-safety rules
-before returning raw catalog sources. Root assembly uses those validated
+before returning raw catalog sources. Internal engine assembly uses those validated
 catalogs as the maintained lowest-precedence profile source.
 
 The overlay repository consults the next repository only when the

docs/policy/architecture.md

@@ -55,15 +55,15 @@ packages or participate in internal assembly.
 
 The internal engine assembles one immutable backend registry, one capacity manager,
 the internal repositories, renderer, validator, outbound client, and use-case
-runner while translating public values and errors at the library boundary. The
-registry contains validated maintained definitions plus engine-scoped consumer
-additions.
-The facade constructs the capacity manager from the registry's immutable
+runner. The registry contains validated maintained definitions plus engine-scoped
+consumer additions. The root facade translates public values and errors at the
+library boundary.
+The internal engine constructs the capacity manager from the registry's immutable
 policy snapshot, wraps the selected built-in or injected model client, and
 supplies bounded admission to the runner. The defaults and renderer depend on
 the domain model. Prompt-definition and profile repositories use the domain
 model, file catalog, and YAML decoder. The catalog adapter validates imported
-immutable maintained data before root assembly supplies it to the profile
+immutable maintained data before internal engine assembly supplies it to the profile
 package. Artifact reading uses the domain
 model and application-neutral defaults. Validation uses the domain model, file
 catalog, and JSON Schema implementation. The model client uses the domain

docs/roadmap/implementation.md

@@ -229,6 +229,17 @@ capacity managers, catalogs, or runners. Public options still have their existin
 names, signatures, ordering, capture, and error behavior. No transitional state
 mapping or duplicate source-assembly path remains.
 
+### Completion
+
+- [x] Wrapped the root option state around internal engine options with private
+  construction state.
+- [x] Moved filesystem and file source setup, source replacement, profile
+  repository construction, validator construction, and backend accumulation
+  into internal option methods.
+- [x] Kept ordered public option application, boundary conversion, collaborator
+  adaptation, and error translation in the root facade.
+- [x] Updated current architecture and internal ownership documentation.
+
 ## Stage 5: Guard The Public Boundary And Dependency Direction
 
 Purpose: protect the intended architecture without freezing private layout.