63 lines
3.0 KiB
Markdown
63 lines
3.0 KiB
Markdown
# Deferred Feature Ideas
|
|
|
|
## Purpose
|
|
|
|
This document catalogs feature ideas that remain potentially useful but have
|
|
been deliberately postponed. These ideas are not awaiting ordinary selection
|
|
from the [future feature catalog](future.md); each has a stated reason to wait
|
|
and should be reconsidered only when its trigger becomes relevant.
|
|
|
|
Deferred entries are not commitments, schedules, active implementation plans,
|
|
or descriptions of current behavior. When an entry is reactivated, move it to
|
|
`future.md` for evaluation or directly into a focused roadmap after its open
|
|
design dependencies have been resolved.
|
|
|
|
## Deferred Ideas
|
|
|
|
### Semantic Execution-Target Fingerprints
|
|
|
|
**Reason for deferral:** A stable digest requires a deliberate semantic-
|
|
equality and versioning design. Notarius can safely use conservative source
|
|
hashes and a Promptkit release marker today, while Weatherreporter does not
|
|
currently reuse LLM-dependent checkpoints.
|
|
|
|
Promptkit could expose an opaque equality value for a resolved profile and its
|
|
effective generation target. This would let checkpointing consumers detect
|
|
generation-affecting configuration changes without hashing YAML presentation
|
|
or depending on Promptkit's built-in catalog layout.
|
|
|
|
The digest should change with semantically relevant state such as the resolved
|
|
model, endpoint, backend routing identity, request defaults, extra parameters,
|
|
profile generation settings, and selected built-in profile semantics. It
|
|
should exclude credential values, concurrency and queue policy, source paths,
|
|
comments, formatting, and other representation-only changes. Whether a
|
|
credential environment-variable name affects equality must be decided
|
|
explicitly. The encoding should remain opaque and internally versioned so
|
|
Promptkit can deliberately invalidate earlier digests when its resolution
|
|
semantics change.
|
|
|
|
Reconsider this idea when a downstream consumer needs Promptkit-owned
|
|
checkpoint equality or when a broader semantic identity design is selected.
|
|
|
|
### Eager Source Validation
|
|
|
|
**Reason for deferral:** Exact prompt and profile inspection may already
|
|
provide a sufficiently small validation surface alongside construction-time
|
|
definition validation. Experience from downstream adoption should establish
|
|
whether a separate operation would add enough value to justify its broader
|
|
contract.
|
|
|
|
Promptkit could provide an explicit offline operation that also checks schema
|
|
resources without model generation. `NewEngine` already validates effective
|
|
definitions and captures prompt content; schema resources remain
|
|
request-dependent.
|
|
|
|
Such an operation would need coherent handling for schema syntax and transitive
|
|
references, context cancellation, and source-specific public errors. Credential
|
|
declarations must remain separate from credential values; checking current
|
|
environment availability, if supported at all, should be an explicit option
|
|
and must not expose secrets.
|
|
|
|
Reconsider this idea after downstream use of `InspectPrompt`,
|
|
`InspectProfile`, and fixture-based preparation demonstrates a concrete gap.
|