83 lines
3.6 KiB
Markdown
83 lines
3.6 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
|
|
|
|
### Public bounded output repair
|
|
|
|
After the codebase-audit remediations are complete, Promptkit should make its
|
|
bounded output-repair capability available through the public engine. A
|
|
consumer should be able to request a limited number of corrective generation
|
|
attempts when JSON or JSON Schema output fails content validation, without
|
|
having to reproduce Promptkit's generation, validation, capacity, and result-
|
|
accounting orchestration.
|
|
|
|
- Repair is validation recovery, not a general provider retry, failover, or
|
|
backoff policy. Transport failures, cancellation, and operational schema or
|
|
validation errors must retain their ordinary error behavior.
|
|
- Repair must stop after the first valid result or the configured attempt
|
|
bound. Exhausting the bound should preserve the final invalid result and its
|
|
validation diagnostics rather than inventing success.
|
|
- Initial generation and every repair attempt must use the same resolved
|
|
backend, effective execution settings and presence semantics, session,
|
|
credential boundary, structured-output contract, and backend-capacity
|
|
policy.
|
|
- Results should report the number of repair attempts and cumulative usage for
|
|
every model call made by the run.
|
|
- Ordinary and prepared execution should expose coherent behavior, including
|
|
cancellation, frozen prepared state, error identity, and capacity lifetime.
|
|
|
|
Select this work only after the accepted audit findings affecting shared
|
|
execution invariants, validation, orchestration, transport, and repair
|
|
internals have been remediated.
|
|
|
|
## 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.
|
|
```
|