promptkit/docs/roadmap/future.md

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.

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, 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:

### Idea name

Describe the intended capability, who benefits, and the most important scope
boundary or dependency.

- Optionally record an important behavior or boundary.