Add PromptKit configuration comparison

This commit is contained in:
2026-10-12 02:01:10 +00:00
parent c6b4a42287
commit ddd14b70a8
3 changed files with 204 additions and 5 deletions

View File

@@ -1,6 +1,6 @@
# Implement PromptKit comparison and catalogs
Status: Stages 1–2 complete; remaining stages are planned.
Status: Stages 1–3 complete; remaining stages are planned.
## Scope and authority
@@ -210,6 +210,28 @@ side diagnostics. Exercise reachable native failures without adding a public
comparator injection hook solely for tests. Add no reconstructed configuration
model or duplicate ckprompt comparison renderer.
**Completion evidence (2026-10-12)**
- `ConfigScope` now declares `ckconfig.Diff` and supplies a pair callback that
loads left then right with each side's selection/input and the shared state,
collects diagnostics in order, checks cancellation at operation boundaries,
and returns PromptKit's native `ConfigurationInspection.Diff` records. Ordinary
acquisition and the retained nil-loader issue remain available.
- Added fast native-engine adapter coverage for the PromptKit result, equal
selections reaching both loader calls, side inputs/shared state, left failure
stopping right, right ConfigKit load diagnostics and error identity, and
cancellation stopping before right load. `GOTOOLCHAIN=local go test -count=1 .`
passed in `integrations/ckprompt`.
- PromptKit v0.14.0 exposes no public way to add successful inspection warnings,
and valid engine-derived inspection views do not expose a reachable native Diff
failure. Therefore successful left-side warning retention on right failure,
both-side warning retention on native failure, and a native Diff failure are
not exercisable without adding a test-only injection path. The implementation
accumulates reached diagnostics and preserves error causes; these limits remain
recorded alongside Stage 2's warning-retention limitation.
- Installed-command verification and the composed consumer's obsolete negative
comparison expectation remain for Stages 4 and 9 respectively.
## Stage 4: Verify comparison through installed config commands
**Outcome:** the adapter works through public assembly, existing typed-input