Record diagnostic adapter decision and flag consumption analysis

This commit is contained in:
2026-11-07 14:45:44 +00:00
parent 2a93b45419
commit 9e0f2d28cd
2 changed files with 59 additions and 19 deletions

View File

@@ -338,17 +338,23 @@ ckconfig and ckprompt independently snapshot ConfigKit diagnostic evidence,
partition severities, construct detail callbacks, label sources, and delegate
native text formatting. Related Reporter scheduling switches are duplicated too.
Consider a narrow public ckconfig adaptation helper returning existing core
diagnostic/explanation values. Any exported helper needs an API decision;
preserve snapshot ownership, ordering, error identity, and diagnostic timing
rather than introducing a universal framework.
**Decision:** expose one narrow public ckconfig diagnostic adaptation helper
and use it in both integrations. Reuse the existing private helper's shape:
accept a caller-supplied heading, native sources, and native diagnostic records;
return existing core diagnostics and an explanation ready for CLI reporting.
Preserve evidence snapshots, severity treatment, ordering within each group,
source labels, and delegation to ConfigKit's native formatter.
**Decision context:** CommandKit is still pre-release with no consumers.
Compatibility and consumer migration are therefore not constraints on this
remediation. The remaining design question is whether a concrete, narrow CLI
adaptation API simplifies both integrations enough to justify maintaining it.
The helper's signature and scope remain to be selected; this clarification does
not itself approve a new public API or a separate reporting-scheduler helper.
Callers retain operation-specific context, outcomes, error causes, and message
scheduling. Core retains visibility and delivery. Leave the smaller scheduling
switches with their callers; no additional public scheduling API or general
diagnostics framework is selected. ckprompt already depends on ckconfig, so no
new module dependency is needed.
CommandKit is pre-release with no consumers; compatibility and migration are
not constraints. The [F21 analysis](remediation-analysis.md#f21--shared-configkit-diagnostic-adaptation)
records the accepted scope and illustrative signature. Implementation remains
pending.
**Original:** [03-complexity M5](03-complexity.md#m5--p3-configuration-diagnostic-adaptation-is-maintained-in-both-integrations).
Also discussed in the [responsibility assessment](A1-responsibility.md#machinery-worth-retaining-under-the-selected-contracts).