62 lines
3.0 KiB
Markdown
62 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. Experience from downstream
|
|
adoption should establish whether an engine-wide operation would add enough
|
|
value to justify its broader contract.
|
|
|
|
Promptkit could provide an explicit offline operation that discovers and
|
|
structurally validates configured prompt, profile, and schema sources without
|
|
model generation. The normal `NewEngine` path would remain lazy.
|
|
|
|
An eager operation would need coherent handling for duplicate prompt IDs and
|
|
versions, strict YAML decoding, referenced content files, profile/backend
|
|
membership, 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.
|