base-layer/commandkit
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 7 Wiki Activity

Close comparison collection scope and defer general clearing support

Browse Source
This commit is contained in:
Eric Rakestraw
2026-11-07 01:36:07 +00:00
parent ca454624cc
commit 93c16bd57e
2 changed files with 26 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
docs/roadmap/promptkit-v0.19.0.md
View File

@@ -910,11 +910,10 @@ universal-format, automatic-selection, and joint format-delivery decisions are
now agreed above. Remaining details are listed under
[remaining core reporting implementation details](#remaining-core-reporting-implementation-details).
CLI JSON number decoding for both integrations, namespace applicability, and
independent comparison defaults are agreed. Outstanding operator choices are
whether to standardize explicit empty collections when application defaults are
nonempty (OD-9), and unusual-path grammar and loader composition (OD-11).
Inheritance-clearing flags are no longer
needed. Exact helper signatures, typed binding composition, flag collision
independent comparison defaults are agreed. OD-9 is settled: explicit-empty
application selectors remain with application-declared bindings for this release.
The remaining open decision is OD-11, covering unusual-path grammar and loader
composition. Exact helper signatures, typed binding composition, flag collision
handling, and report layouts remain implementation choices, not unresolved scope.
### OD-1: Preview command and report presentation
@@ -1389,14 +1388,19 @@ ADR 0012, retaining its accepted decision text as history, and update current
CLI/API contracts and examples. Exact helper signatures and flag collision
handling remain implementation design tasks.
**Remaining collection question:** omission already means the ordinary collection
for that side, so no flag is needed to clear inherited left-side values. The
earlier proposed `--against-clear-*` flags are not selected. Explicitly replacing
an application's nonempty default collection with an empty collection is a
separate, symmetric question for either side: decide whether it needs a standard
capability or should remain with application-declared bindings. No empty-collection
grammar is selected here, and an empty string element is not implicitly an empty
collection.
**Agreed collection scope:** leave explicit-empty selection for application-defined
repeatable selectors to application-declared bindings in this release. Omission
retains that side's ordinary collection; an empty string element is not implicitly
an empty collection. No additional standard collection-clearing flags, including
the earlier proposed `--against-clear-*` forms, are selected.
Actual configuration lists supported by OD-11 can be replaced with an empty list
using `--set /path=[]` or `--against-set /path=[]` on the corresponding side,
subject to upstream path and schema rules. This does not necessarily express
empty selection for an application selector that controls which sources load.
Retain general collection-clearing support as a
[future candidate](future.md#comparison-extensions) pending a concrete consumer
need. OD-9 requires no further operator-policy decision for this adoption.
### OD-10: Comparison assertion outcomes