97 lines
4.0 KiB
Markdown
97 lines
4.0 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.
|
|
|
|
## 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.
|
|
- 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
|
|
|
|
Executable preparation handles have been selected for active planning in the
|
|
[focused feature roadmap](prepared-execution.md). The remaining ideas are
|
|
still available for future selection.
|
|
|
|
### Prompt-independent profile inspection
|
|
|
|
Provide exact profile lookup and structural resolution without requiring a
|
|
synthetic prompt, placeholder inputs, or model generation. This shared need is
|
|
described by
|
|
[Notarius](notarius-promptkit-wishlist.md#priority-2-prompt-independent-profile-inspection)
|
|
and
|
|
[Weatherreporter](weatherreporter-promptkit-wishlist.md#priority-3-prompt-independent-profile-inspection).
|
|
|
|
- Apply ordinary built-in, file-backed, and programmatic profile precedence.
|
|
- Validate referenced backend membership and the structurally resolved
|
|
execution target.
|
|
- Report credential requirements and environment-variable names without
|
|
exposing credential values or requiring current credential availability.
|
|
- Support exact lookup by profile ID; enumeration is not required initially.
|
|
|
|
### Prompt-definition inspection
|
|
|
|
Provide exact prompt-definition lookup without rendering, placeholder inputs,
|
|
profile resolution, or model generation, as requested by
|
|
[Weatherreporter](weatherreporter-promptkit-wishlist.md#priority-2-prompt-definition-inspection).
|
|
|
|
- Return caller-owned identity, version, input definitions, default-profile,
|
|
output-contract, and opaque definition-equality information.
|
|
- Apply ordinary prompt-source precedence and exact ID/version selection.
|
|
- Validate the selected definition and referenced prompt content
|
|
structurally, without returning source bodies or rendered messages.
|
|
- Leave complete cross-source corpus validation and enumeration outside the
|
|
initial inspection contract.
|
|
|
|
### Structured capacity errors
|
|
|
|
Add safe structured context to backend admission rejection, as requested by
|
|
[Notarius](notarius-promptkit-wishlist.md#priority-4-structured-capacity-errors)
|
|
and
|
|
[Weatherreporter](weatherreporter-promptkit-wishlist.md#structured-capacity-errors).
|
|
|
|
- Preserve compatibility with `errors.Is(err, ErrCapacityExceeded)`.
|
|
- Support `errors.As` to obtain the stable backend ID.
|
|
- Do not expose endpoints, credential configuration or values, request
|
|
content, or speculative retry timing.
|
|
- Keep retry and backoff policy with downstream consumers.
|
|
|
|
## 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.
|
|
```
|