80 lines
3.5 KiB
Markdown
80 lines
3.5 KiB
Markdown
# Future Feature Ideas
|
|
|
|
## Purpose
|
|
|
|
This document catalogs reasonably specific ideas that may be useful in future
|
|
Promptkit development. It is an idea pool, not a commitment, schedule, or
|
|
description of current behavior.
|
|
|
|
Ideas belong here while they are worth retaining but have not been selected
|
|
for active development. Keep each entry at the level of intended capability,
|
|
consumer value, and important scope boundaries. Defer API design,
|
|
implementation details, sequencing, and acceptance criteria until an idea is
|
|
selected.
|
|
|
|
Ideas that have been deliberately postponed rather than left available for
|
|
ordinary selection belong in the [deferred catalog](deferred.md).
|
|
|
|
## Using This Catalog
|
|
|
|
- Add an idea when its purpose and likely value can be stated clearly.
|
|
- Keep entries independent enough that maintainers can evaluate and select
|
|
them individually.
|
|
- Note significant dependencies or boundary concerns, but do not turn entries
|
|
into implementation plans.
|
|
- Treat inclusion as an invitation to evaluate, not as approval or priority.
|
|
- When an idea is selected, move its active planning to a focused roadmap or,
|
|
when it requires a durable architectural decision, an ADR. Update
|
|
current-state documentation only when implementation lands.
|
|
- Move an idea to `deferred.md` when maintainers decide to retain it but wait
|
|
for a stated design dependency, demand signal, or reconsideration trigger.
|
|
- Remove ideas that are no longer relevant. Retain a rejected idea only when
|
|
its rationale is likely to prevent repeated reconsideration.
|
|
|
|
Future capabilities must continue to respect the
|
|
[architecture policy](../policy/architecture.md), particularly Promptkit's
|
|
role as an application-neutral library and its boundary with downstream
|
|
consumers.
|
|
|
|
## Ideas
|
|
|
|
### Field-Level Normalization With Preserved List Provenance
|
|
|
|
Reevaluate normalizing resource fields directly in ConfigKit's effective
|
|
configuration after upstream ConfigKit supports recording changes within a
|
|
list without replacing the source attribution of unchanged fields.
|
|
|
|
This could let configuration inspection show PromptKit-normalized values and
|
|
field-level change history while preserving the origins needed to resolve
|
|
relative resources such as `content_file`. Assess whether that inspection
|
|
benefit justifies changing the execution-owned normalization approach.
|
|
|
|
Include normalization of roles and cache-control values in configured messages
|
|
in this reevaluation. This could make inspection reflect the values used for
|
|
execution and reduce separate normalization paths. Upstream support would need
|
|
to preserve untouched field origins within nested message lists as well as outer
|
|
resource lists. PromptKit would continue owning the normalization rules;
|
|
ConfigKit would record their effects and provenance. Caller-appended messages
|
|
would still need request-time normalization because they do not pass through
|
|
ConfigKit.
|
|
Consider moving these transformations only if it improves inspection consistency
|
|
and simplifies implementation without changing execution behavior.
|
|
|
|
Upstream support is the reconsideration trigger, not a dependency of the
|
|
current ConfigKit migration or a commitment to adopt the enhancement.
|
|
|
|
## Entry Format
|
|
|
|
Use a short heading followed by a concise summary. Add focused bullets when
|
|
they help preserve important scope boundaries without becoming an
|
|
implementation plan:
|
|
|
|
```markdown
|
|
### Idea name
|
|
|
|
Describe the intended capability, who benefits, and the most important scope
|
|
boundary or dependency.
|
|
|
|
- Optionally record an important behavior or boundary.
|
|
```
|