From 9e05c3ac8b56785c03dd61164982c1bf47cea359 Mon Sep 17 00:00:00 2001 From: Eric Rakestraw Date: Tue, 3 Nov 2026 15:11:45 +0000 Subject: [PATCH] Clarify bundled profile composition and compatibility --- docs/roadmap/bundled-openrouter.md | 29 +++++++++++++++++++++++++---- 1 file changed, 25 insertions(+), 4 deletions(-) diff --git a/docs/roadmap/bundled-openrouter.md b/docs/roadmap/bundled-openrouter.md index 739e8aa..07e428a 100644 --- a/docs/roadmap/bundled-openrouter.md +++ b/docs/roadmap/bundled-openrouter.md @@ -184,13 +184,29 @@ application supplying only a new model value does not inherit the replaced profile's backend. A distinct sibling using `extends` remains the ordinary way to create a variant while retaining base fields. +These replacement semantics describe ordinary identified-list upsert behavior. +Honor explicit ConfigKit sequence modes as well: `append` rejects duplicate +identities, while `replace` replaces the complete lower list. The bundle adds no +special conflict handling or exception to those composition rules. + Loading definitions by default changes inventory and inspection results, and previously unresolved references matching bundled IDs may become resolvable. -Document these effects. Existing valid application records at higher layers -continue to win through normal composition. Changing a bundled backend may +Document these effects. Higher-layer application records take precedence under +the applicable ConfigKit composition mode. Changing a bundled backend may also affect surviving bundled profiles that reference it; that is ordinary backend completion, not a special override exception. +The five cost-tier profiles inherit from the effective `auto` profile. An +application replacement of `auto` can therefore change their inherited backend +or model while their OpenRouter plugin settings remain present. Cover this +interaction in a focused test and a short example note; it does not require a +new restriction on replacing the parent. + +Bundled profile and backend IDs are consumer-facing names. Review future removal +or repurposing through the ordinary compatibility process, since application +configuration may reference them. This does not introduce a separate catalog +lifecycle or a guarantee that upstream aliases retain fixed behavior. + The embedded data ships with the PromptKit release. No catalog download or automatic refresh mechanism is planned. Provider aliases and routers may change their targets independently of that release; the inspected configured slug @@ -199,7 +215,9 @@ does not identify or pin the concrete model selected upstream. ## Implementation Work 1. Verify the provider endpoint and exact model values for the seventeen selected - root profiles. + root profiles. Local HTTP checks establish payload construction, not provider + acceptance. A live provider check may supplement that verification without + becoming a recurring credential-dependent test requirement. 2. Add the embedded YAML backend and profiles, and integrate their dedicated underlay with engine construction. Add the disable option using the existing facade option pattern. Apply the ordinary load/normalize/validate lifecycle. @@ -208,7 +226,10 @@ does not identify or pin the concrete model selected upstream. Include an application-provided OpenRouter collection and a replaced backend to exercise interaction with external catalogs. Verify all five cost-tier profiles inherit the base backend/model and send the expected top-level - `plugins` array through the built-in HTTP client. + `plugins` array through the built-in HTTP client. Add representative explicit + `append` and `replace` mode cases. Add a targeted case replacing root `auto` + in a higher layer with a different backend/model, then verify its cost-tier + children inherit those effective values and retain their plugin settings. 4. Verify listing and inspection reflect effective definitions and meaningful source evidence. Exercise request preparation with a fake client or local server as appropriate; construction must not depend on provider reachability