Plan configuration collections implementation

This commit is contained in:
2026-10-17 05:26:42 +00:00
parent 683689a4f8
commit 89af2a1281
2 changed files with 698 additions and 790 deletions

View File

@@ -2,8 +2,9 @@
Status: accepted feature roadmap; not implemented in PromptKit. This document Status: accepted feature roadmap; not implemented in PromptKit. This document
consolidates the namespace roadmap and selected collection proposal 3. The consolidates the namespace roadmap and selected collection proposal 3. The
configuration and namespace design decisions are settled; public API details configuration and namespace design decisions are settled. The companion
and staged implementation planning remain delivery work. [implementation plan](implementation.md) defines concrete API delivery choices
and the staged work needed to reach this target state.
## Purpose ## Purpose
@@ -25,11 +26,10 @@ and provenance guarantees.
## Prerequisite: Adopt ConfigKit v0.8.0 ## Prerequisite: Adopt ConfigKit v0.8.0
Adopt released ConfigKit **v0.8.0** before implementing the new collection schema The target selects released ConfigKit **v0.8.0** for the collection schema and
and loading APIs. PromptKit currently selects v0.7.1. Update the module dependency loading APIs. PromptKit currently selects v0.7.1. Dependency adoption and its
and checksums, review affected public API compatibility and attribution, and verification belong to the [implementation plan](implementation.md); local
verify the existing ConfigKit integration as the prerequisite implementation filesystem replacements are not part of the distributed module.
unit. Do not use a committed local filesystem replacement for adoption.
The v0.8.0 tag was reviewed at `137769f` on 2026-10-17. It supplies input The v0.8.0 tag was reviewed at `137769f` on 2026-10-17. It supplies input
placement, relative import destinations, and shared source-version checks needed placement, relative import destinations, and shared source-version checks needed
@@ -164,7 +164,8 @@ below.
Provide a lightweight, immutable view over an existing engine with independent Provide a lightweight, immutable view over an existing engine with independent
prompt, profile, and backend scopes. The following sketch illustrates the prompt, profile, and backend scopes. The following sketch illustrates the
accepted shape; method/type names and final signatures remain provisional: accepted shape; concrete declarations are specified in the
[implementation plan](implementation.md):
```go ```go
weather, err := engine.WithNamespaces(Namespaces{ weather, err := engine.WithNamespaces(Namespaces{
@@ -266,7 +267,7 @@ listings for the supported resource types, adding a backend inventory surface
as part of this work if needed. Namespace filtering is an explicit option in as part of this work if needed. Namespace filtering is an explicit option in
the library listing API, not a consumer-side filtering helper. Preserve unfiltered the library listing API, not a consumer-side filtering helper. Preserve unfiltered
engine listing behavior, with the accepted removal of prompt-version identity engine listing behavior, with the accepted removal of prompt-version identity
and selection; the exact Go option shape remains to be specified. and selection. The companion implementation plan defines the Go filter shape.
| Selection | Listing behavior | | Selection | Listing behavior |
| --- | --- | | --- | --- |
@@ -655,7 +656,8 @@ Derive collection inventory from the final `collections` mapping: namespace
plus optional effective `release_version`, sorted and detached from the captured plus optional effective `release_version`, sorted and detached from the captured
engine. Metadata-only and resource-only entries can both appear. Root unqualified engine. Metadata-only and resource-only entries can both appear. Root unqualified
resources do not invent a named collection; resource-based namespace enumeration resources do not invent a named collection; resource-based namespace enumeration
remains separate. Exact exported inventory types remain API design work. remains separate. The companion implementation plan defines exported inventory
types.
An inventory describes effective configuration, not immutable package identity, An inventory describes effective configuration, not immutable package identity,
historical source ownership, or proof of unchanged published contents. Operator historical source ownership, or proof of unchanged published contents. Operator
@@ -724,20 +726,16 @@ Explicit source destinations, direct fragments, programmatic sources, and
consumer-selected precedence remain supported in the design. Deferred features consumer-selected precedence remain supported in the design. Deferred features
can be reconsidered for concrete needs; none blocks implementation. can be reconsidered for concrete needs; none blocks implementation.
## Delivery And Validation ## Target Acceptance
The next work is a staged implementation plan grounded in these accepted The target includes the collection schema and final configuration adapter,
contracts. Its first prerequisite is [ConfigKit v0.8.0 adoption](#prerequisite-adopt-configkit-v080). catalog and built-in removal, ID-only prompt selection, immutable scoped views,
Then cover the collection schema and final configuration adapter, catalog and integrated filtering, and collection inventory. Runtime indexes use full
built-in removal, prompt-version API removal, immutable scoped views, integrated identities after ConfigKit handoff. Current contracts and consumer migration
filtering, and collection inventory. Build qualified runtime indexes after guidance describe the implemented behavior when it lands. The
ConfigKit handoff. Select exact helper signatures, listing options, and metadata [implementation plan](implementation.md) owns sequencing, concrete public shapes,
representations using representative consumer examples. documentation tasks, and focused offline validation under the
[testing policy](../policy/testing.md).
Plan focused offline validation under the [testing policy](../policy/testing.md).
Update GoDoc, the format reference, consumer guidance, affected release policy,
and internal documentation when behavior lands. Retire this roadmap after the
work is complete. This outline is not yet the staged implementation plan.
### Namespace And Consumer Acceptance ### Namespace And Consumer Acceptance
@@ -802,14 +800,13 @@ replacement, inheritance limits, header consumption, and final identity validati
boundaries. The latter review informed the decision to retain mappings. These boundaries. The latter review informed the decision to retain mappings. These
checks establish upstream behavior, not an implemented PromptKit feature. checks establish upstream behavior, not an implemented PromptKit feature.
## Remaining Delivery Details ## Delivery Reference
No substantive design question remains before staged implementation planning. No substantive design question remains. ConfigKit v0.8.0 is the selected
ConfigKit v0.8.0 is the selected prerequisite, not an unresolved release choice. dependency. The [implementation plan](implementation.md) specifies helper
Finalize public helper signatures, inventory and optional-label representations, signatures, inventory and optional-label representations, identifier migration
identifier migration mappings, and concrete consumer migration examples in the mappings, and consumer migration work. Its delivery choices implement these
plan and implementation. Do not reopen settled workflows or add speculative accepted contracts without adding speculative options or reopening workflows.
options merely to complete API shapes.
## Consolidation And Retired Alternatives ## Consolidation And Retired Alternatives

File diff suppressed because it is too large Load Diff