and [execution/observation contract](library-boundary-findings.md#execution-and-failure-mapping).
Do not build an adapter to feed the old LLM runtime or introduce an interim
`process` rejection mode.
| New setting or control | Interim disposition |
| --- | --- |
| `profiles_dir`, proposal/validation profile IDs | Honor for relative-path profile loading, final inheritance, inspection, and target assembly. |
| `backends.<id>.endpoint` and `credential` | Honor for selected target validation and client setup; keep ConfigKit secret resolution and redaction. |
| Profile model and `timeout_seconds` | Convert for old client setup checks; old transport can consume these per-attempt values. |
| `validation.max_prompt_tokens`; retained domain, output, and diagnostics fields | Honor through existing domain/batching/report inputs after validation. |
| `backends.<id>.concurrency` and `queue_capacity` | Validate and inspect; old global/role pools cannot enforce independent per-backend admission or queue semantics. |
| `llm.transient_retries` | Validate and inspect; old retry eligibility and explicit-zero behavior differ. |
| `llm.repair_attempts` | Validate and inspect; old runtime has no PromptKit structural-repair contract. |
| `llm.operation_timeout` | Validate and inspect; old per-call timeout is not the full logical-operation deadline. |
| Other PromptKit profile generation controls and execution observations | Inspect only; old transport/reporting cannot claim equivalent behavior. |
The old global/role pools and retry loop must not be presented as equivalents. The
selected interim behavior is to reject `process` before any LLM request with a
clear unsupported-runtime classification while ConfigKit has landed but PromptKit
has not. `config validate` and effective/profile inspection remain usable. This
is an unreleased development interval, not a user-visible mode or compatibility
switch. The process gate is removed only when the PromptKit package below proves
the complete settings through controlled calls.
**Acceptance/tests:** conversion tests verify the representable values and
redaction; a process subprocess test proves the interim rejection occurs before
provider transport or output mutation. No test should assert that old retries or
schedulers implement new settings. The combined migration cannot release with
this gate in place.
**Acceptance/tests:** controlled HTTP tests prove both roles' final model/backend
selection, overlays and explicit overrides, finite per-backend capacity, explicit
zero retries, positive structural repair, total-operation deadlines, cancellation,
domain acceptance/rejection, and safe observations including partial failures.
Processing uses the new configuration and execution path together. Reuse existing
domain coverage and the prototype's integration evidence; update tests tied to the
retired transport and scheduler contracts.
### 5. Remove superseded configuration paths and update maintained contracts
@@ -278,80 +271,21 @@ semantics. Do not leave dual loaders or a permanent translation mode.
**Acceptance/tests:** maintained examples validate offline; removed flags and old
schema are rejected; relevant config/CLI/subprocess/report tests pass; documentation
links and `git diff --check` pass. The interim process restriction remains explicit
until package 6 and is not documented as a released product feature.
links and `git diff --check` pass. Remove the isolated prototype when its useful
coverage and examples have moved into the production suite.
### 6. Replace execution with PromptKit, then prepare the combined release
### 6. Validate the combined end state and prepare release
**Depends on:** packages 1–5. This is the later PromptKit work unit, not part of
this ConfigKit implementation. Replace the old provider transport, prompt loader,
structural-output handling, and scheduler composition as described by the
@@ -311,9 +311,9 @@ claims of completion for the prototype.
The new profile/credential/capacity and deadline choices are explicit above; no
unresolved upstream requirement prevents starting the ConfigKit implementation
plan. Production report field names and the exact temporary bridge implementation
must be finalized in their respective implementation units, guided by the outcome
and observation contract here.
plan. Production report field names and final runtime wiring follow the outcome
and observation contract here. The coordinated refactor targets both libraries
directly; intermediate commits do not require a working legacy runtime.
### Component-Level Next Unit
@@ -324,10 +324,9 @@ Implement ConfigKit adoption first, against this target model:
| `internal/core/config` | Replace file/env merge and custom duration parsing with ConfigKit definitions, presence-aware resolution, domain validation, and explicit override paths. Retain domain defaults and validation rules identified in the inventory. |
| `internal/cli` | Separate invocation paths from persistent settings; select one file; parse only supplied setting flags into overrides; remove legacy LLM/role-budget/direct-key flags and all environment overlays. Assemble/inspect selected profiles for validation. |
| CLI config inspection and diagnostics snapshot | Use ConfigKit redacted output plus Audita-owned selected-profile summary; update command tests and diagnostic snapshot consumers. |
| ConfigKit-to-old-runtime bridge | Temporary adapter from selected profile/backend to legacy LLM inputs, only until PromptKit migration. It must not pretend to implement structural repair, independent backend pools, explicit-zero retry behavior, or new observations through the old adapter. Keep those execution features unavailable until the PromptKit stage, document the intermediate state, and do not release it. Avoid reconstructing PromptKit mechanics to make the bridge feature-complete. |
| Configuration tests/examples | Replace v1 discovery/overlay/alias expectations with v2 presence, inheritance, secret, profile, and override contracts; preserve domain validation tests. Add actual production discovery and CLI tests not exercised by this prototype. |
The following PromptKit unit replaces `internal/framework/llm` provider execution
The PromptKit portion of the refactor replaces `internal/framework/llm` provider execution
and scheduler composition, `internal/prompts` parsing/rendering, and duplicated
structural-output validation. Keep a small Audita adapter behind the existing
structured-call boundary where that contract remains sufficient; revise its return
@@ -341,7 +340,7 @@ assembly, and artifact lifecycle. Update their integration wiring rather than
rewriting those algorithms. Move all nine prompt definitions and schema references,
checking each module/validator's variables and helpers; this prototype proves only
one pair. Migrate actual diagnostic redaction and error classification, then remove
the old transport/schedulers/prompt loader and the ConfigKit bridge.
the old transport/schedulers/prompt loader. No temporary runtime bridge is needed.
Documentation work during the respective implementation stages: update
- Record new results separately from the historical v0.3.1 findings. Expand the
existing ConfigKit roadmap into a concrete production implementation handoff,
including the interim runtime boundary and removal of legacy configuration.
including final runtime integration and removal of legacy configuration.
Target end state: reviewers can run the prototype with and without the testing
selection and see both LLM roles switch models. The offline test suite establishes
@@ -254,8 +254,8 @@ This unit is complete only when:
code is clearly isolated and has a removal/integration destination during the
production migrations; no second supported runtime is introduced.
- A component-level follow-up identifies code to replace, domain code to retain,
tests to update, documentation/migration-guide work, and any temporary bridge
needed while ConfigKit lands ahead of PromptKit.
tests to update, documentation/migration-guide work, and direct integration of
the final configuration and PromptKit runtime.
- Licensing/distribution follow-up for the selected dependency graph is identified
for the later release stage; this prototype does not claim release compliance.
- Roadmap links and examples resolve, appropriate checks pass, and commits contain
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
