Use external catalogs for maintained backends

docs/formats.md

@@ -283,7 +283,7 @@ Profile sources resolve matching IDs in this order:
 2. the ordinary configured source selected by a profile file, `fs.FS`, or
    configured profile directory;
 3. application fallback profiles supplied with `WithFallbackProfileFS`; and
-4. embedded built-in profiles.
+4. maintained external catalog profiles.
 
 A profile source supplies a complete definition; definitions and their fields
 are not merged across sources. A higher-precedence source falls back only when

docs/internal/overview.md

@@ -14,7 +14,7 @@ contributor workflow and validation.
 | Root `promptkit` package | Provides the supported engine facade, source, backend-registration, and injection options, public request, result, prompt-inspection, and profile-inspection values, opaque prepared-execution handles, profile construction, extension interfaces, value conversion, redacted formatting, typed capacity and generation error mapping, engine-local profile-source assembly including application fallbacks, and bounded output-repair assembly. | [Package GoDoc](../../doc.go), [prepared execution](../../prepared_execution.go), [backend API](../../backends.go), [engine assembly](../../engine.go) |
 | `examples/go-library/prepare` | Demonstrates an offline downstream consumer using a prompt file, in-memory profile, inline input, and `Prepare`. It is not a public library package. | [Example program](../../examples/go-library/prepare/main.go) |
 | `examples/go-library/run` | Demonstrates an offline downstream consumer using a prompt file, in-memory profile, inline input, an injected deterministic model client, and `Run`. It is not a public library package. | [Example program](../../examples/go-library/run/main.go) |
-| `internal/backend` | Constructs each engine's immutable registry from the maintained built-in definitions and consumer additions, validates and defensively copies definitions through the shared JSON-value package, and consumes the LLM-owned OpenAI-compatible reserved request-field rule. | [Backend registry](../../internal/backend/registry.go) |
+| `internal/backend` | Constructs each engine's immutable registry from maintained definitions and consumer additions, validates and defensively copies definitions through the shared JSON-value package, and consumes the LLM-owned OpenAI-compatible reserved request-field rule. | [Backend registry](../../internal/backend/registry.go) |
 | `internal/catalog` | Strictly validates imported immutable maintained backend and profile catalog assets before runtime cutover. | [Catalog adapter](../../internal/catalog/catalog.go), [internal sources](sources.md#profiles-and-built-ins) |
 | `internal/capacity` | Owns engine-local bounded execution admission and FIFO model-generation permits for limited backend IDs, including cancellation-safe waiter removal and client wrapping. | [Internal capacity management](capacity.md) |
 | `internal/domain` | Defines internal framework values for requests, artifacts, prompt definitions, profiles, execution targets, rendering, generation, and validation, and owns source-neutral invariants for shared execution settings, OpenAI-compatible base endpoints, session identifiers, and output contracts. Source parsing, required fields, other source-specific normalization, defaulting, and boundary-specific error classification remain with their callers. | [Domain declarations](../../internal/domain/domain.go), [endpoint invariant](../../internal/domain/endpoint.go) |
@@ -23,7 +23,6 @@ contributor workflow and validation.
 | `internal/jsonvalue` | Validates and deeply copies bounded JSON-compatible extra-parameter and prepared-schema trees while preserving supported concrete value types and rejecting cycles or excessive depth and work. | [JSON values](../../internal/jsonvalue/jsonvalue.go) |
 | `internal/promptdef` | Loads strictly decoded, validated prompt definitions from filesystem and `fs.FS` sources, including version selection and contained file-backed message content. | [Framework formats](../formats.md), [prompt-definition repository](../../internal/promptdef/filesystem_repository.go) |
 | `internal/profile` | Loads strictly decoded, locally validated execution profiles from filesystem and `fs.FS` sources, overlays raw sources with error-preserving fallback, and resolves inherited profiles. | [Framework formats](../formats.md), [profile repositories](../../internal/profile/filesystem_repository.go), [internal sources](sources.md#profiles-and-built-ins) |
-| `internal/profile/builtin` | Embeds the built-in profile catalog, whose entries select maintained built-in backends. | [Built-in catalog](../formats.md#built-in-profile-catalog), [repository](../../internal/profile/builtin/repository.go) |
 | `internal/prompt` | Renders prompt messages from Go templates with artifact, variable, session, and cache-control data. | [Go-template renderer](../../internal/prompt/go_renderer.go) |
 | `internal/artifact` | Resolves ordinary inline and unrestricted caller-selected file references into copied artifacts with metadata and hashes. | [Internal sources and validation](sources.md) |
 | `internal/validate` | Validates basic, JSON, and JSON Schema output using operating-system filesystem or `fs.FS` schema sources and creates operation-local validation plans with canonical contained schema resources. | [Framework formats](../formats.md#schemas), [internal sources and validation](sources.md) |

docs/internal/sources.md

@@ -62,14 +62,13 @@ catalog consumers. It discovers and strictly validates every raw profile once,
 preserves safe source metadata including explicitly present YAML fields, and
 publishes independently copied values from memory. It does not resolve profile
 inheritance. Configured consumer sources continue to use the lazy point lookup
-repositories described above; engine assembly still uses the embedded built-in
-catalog at this point.
+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. The root engine continues to use the
-embedded built-ins until runtime cutover.
+before returning raw catalog sources. Root assembly uses those validated
+catalogs as the maintained lowest-precedence profile source.
 
 The overlay repository consults the next repository only when the
 higher-precedence repository reports that a profile is absent. A reliably
@@ -81,7 +80,7 @@ profile inspection.
 
 The root engine assembles one raw composite catalog in precedence order:
 in-memory profiles, one ordinary configured source, an application fallback
-source, then the embedded built-in catalog. An explicit file or `fs.FS` profile
+source, then the maintained external catalog. An explicit file or `fs.FS` profile
 source replaces `Config.ProfileDir` within the ordinary configured-source
 category. One outer resolving repository wraps that complete raw catalog, so
 each base lookup observes the same precedence and shadowing rules.
@@ -99,15 +98,11 @@ or schema sources. It does not retain that lookup for a later execution.
 Prepared execution instead freezes the fully resolved target; a later ordinary
 operation performs a fresh traversal.
 
-`internal/profile/builtin` embeds the maintained built-in profile catalog.
-Every embedded profile selects a maintained built-in backend and inherits that
-backend's endpoint and credential environment-variable name from the built-in
-backend registry rather than repeating those values. Profile loading and
-overlay behavior are owned by the
+The maintained external catalog provides every built-in profile and its
+matching backend definition. Profile loading and overlay behavior are owned by the
 [profile repository tests](../../internal/profile/repository_test.go), while
-catalog completeness, the backend-selection invariant, and duplicate IDs are
-owned by the
-[built-in repository tests](../../internal/profile/builtin/repository_test.go).
+catalog completeness, backend selection, and duplicate IDs are owned by the
+[catalog adapter tests](../../internal/catalog/catalog_test.go).
 
 ## Ordinary Artifacts
 

docs/policy/architecture.md

@@ -22,7 +22,7 @@ The implemented internal components consist of:
 - `internal/domain`, which owns framework data values and source-neutral
   invariants shared by later internal components;
 - `internal/backend`, which owns validated immutable OpenAI-compatible backend
-  definitions and the maintained built-in definitions;
+  definitions;
 - `internal/capacity`, which owns engine-local bounded run admission and
   model-generation scheduling for limited backends;
 - `internal/defaults`, which owns application-neutral framework defaults and
@@ -37,8 +37,6 @@ The implemented internal components consist of:
   filesystem and `fs.FS` sources;
 - `internal/profile`, which loads, validates, and overlays execution profiles
   from filesystem and `fs.FS` sources;
-- `internal/profile/builtin`, which embeds the built-in execution profile
-  catalog;
 - `internal/prompt`, which renders prompt messages from Go templates;
 - `internal/artifact`, which resolves ordinary inline and unrestricted
   caller-selected file references;
@@ -56,13 +54,15 @@ packages or participate in internal assembly.
 The root facade 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 built-ins plus validated engine-scoped consumer additions.
+registry contains validated maintained definitions plus engine-scoped consumer
+additions.
 The facade 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 built-in profile repository supplies
-an embedded `fs.FS` to the profile package. Artifact reading uses the domain
+model, file catalog, and YAML decoder. The catalog adapter validates imported
+immutable maintained data before root 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
 model, application-neutral defaults, and an injected or standard-library HTTP

docs/roadmap/implementation.md

@@ -503,7 +503,7 @@ source as the active implementation.
 
 ## Stage 6: Cut Promptkit Over To The External Catalogs
 
-**Status:** Pending
+**Status:** Complete
 
 ### Repository