Plan the span deletion implementation
This commit is contained in:
File diff suppressed because it is too large
Load Diff
@@ -2,10 +2,9 @@
|
|||||||
|
|
||||||
**Last updated:** 2026-09-25
|
**Last updated:** 2026-09-25
|
||||||
|
|
||||||
**Status:** Accepted feature direction; not implemented. This document defines
|
**Status:** Accepted target; not implemented. This document owns the desired
|
||||||
the target behavior and work required. A staged implementation plan will be
|
behavior and user intent. [implementation.md](implementation.md) owns the concrete
|
||||||
prepared separately; the existing implementation plan covers the completed
|
steps, selected implementation details, and completion evidence.
|
||||||
resilience work.
|
|
||||||
|
|
||||||
## Purpose and User Intent
|
## Purpose and User Intent
|
||||||
|
|
||||||
@@ -109,6 +108,11 @@ proposal prompts. Validators must understand the before/after effect of deletion
|
|||||||
and assess it under their existing criteria. A correct negative editorial decision
|
and assess it under their existing criteria. A correct negative editorial decision
|
||||||
remains ordinary processing, not a defect that should be regenerated until approved.
|
remains ordinary processing, not a defect that should be regenerated until approved.
|
||||||
|
|
||||||
|
The resulting-segment validator's name and documented identity should describe
|
||||||
|
that responsibility accurately, rather than imply that the replacement string
|
||||||
|
itself must be nonempty. Preserve the existing blank-result failure reason and
|
||||||
|
validation order while making that deliberate identity change.
|
||||||
|
|
||||||
## Outcomes and Reporting
|
## Outcomes and Reporting
|
||||||
|
|
||||||
A legitimate deletion is an ordinary correction. Empty replacement alone must
|
A legitimate deletion is an ordinary correction. Empty replacement alone must
|
||||||
@@ -127,28 +131,6 @@ purpose; no new report schema, incident category, or deletion-specific counter i
|
|||||||
needed. Unrelated structural defects may still exhaust PromptKit repair and produce
|
needed. Unrelated structural defects may still exhaust PromptKit repair and produce
|
||||||
an error for the operation, as today.
|
an error for the operation, as today.
|
||||||
|
|
||||||
## Work Required
|
|
||||||
|
|
||||||
This is a description of the change surface, not an ordered implementation plan.
|
|
||||||
|
|
||||||
- Relax the shared correction schema's replacement-length constraint while
|
|
||||||
retaining its required string field and the other structural checks.
|
|
||||||
- Align proposal prompts, relevant validator prompts, and validation payloads with
|
|
||||||
the selected semantics. Reuse the existing source/result preview behavior.
|
|
||||||
- Rename the misleading resulting-segment validator and associated package,
|
|
||||||
registry, chain, metadata, test, and documentation references consistently.
|
|
||||||
Choose a name that states the resulting-segment requirement. Treat any exposed
|
|
||||||
validator identity change deliberately; do not rename the existing failure
|
|
||||||
reason merely to match the new validator name.
|
|
||||||
- Review preview and application paths for consistency, including successive edits
|
|
||||||
to the same segment. Preserve existing safeguards without adding new deletion
|
|
||||||
abstractions, configuration controls, or independent retry loops.
|
|
||||||
- Replace tests that enforce nonempty replacement strings with meaningful contract
|
|
||||||
tests, and add representative integration coverage through the real schema,
|
|
||||||
PromptKit adapter, validation chain, application, and outcome mapping.
|
|
||||||
- Update canonical module, validator, prompt, and affected output documentation
|
|
||||||
when implementation lands. Keep current behavior references accurate until then.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
## Acceptance Criteria
|
||||||
|
|
||||||
- A controlled valid response containing an empty replacement reaches Audita's
|
- A controlled valid response containing an empty replacement reaches Audita's
|
||||||
@@ -176,7 +158,7 @@ no live-provider or paid evaluation is a prerequisite. Representative production
|
|||||||
examples can inform prompt quality without expanding this into an evaluation
|
examples can inform prompt quality without expanding this into an evaluation
|
||||||
framework or guaranteeing that models always follow the instructions.
|
framework or guaranteeing that models always follow the instructions.
|
||||||
|
|
||||||
## Deferred Work and Planning Boundary
|
## Deferred Work
|
||||||
|
|
||||||
[Whole-segment removal](future.md#whole-segment-removal) is only potential future
|
[Whole-segment removal](future.md#whole-segment-removal) is only potential future
|
||||||
work and first requires deciding whether its benefit warrants implementation.
|
work and first requires deciding whether its benefit warrants implementation.
|
||||||
@@ -184,7 +166,6 @@ Domain-aware regeneration and independent whole-pipeline traversal also remain
|
|||||||
in [future.md](future.md). This feature changes neither retry budgets nor the
|
in [future.md](future.md). This feature changes neither retry budgets nor the
|
||||||
Audita/PromptKit ownership boundary and requires no upstream library feature.
|
Audita/PromptKit ownership boundary and requires no upstream library feature.
|
||||||
|
|
||||||
The product choices above are settled. The next planning pass should select
|
Implementation sequencing and concrete names belong to the
|
||||||
concrete names and integration-test placement and produce a staged implementation
|
[implementation plan](implementation.md). The target remains consistent deletion
|
||||||
plan. No implementation stages or application changes are introduced by this
|
of spans within surviving segments, with no new operator controls or report types.
|
||||||
roadmap-writing pass.
|
|
||||||
|
|||||||
Reference in New Issue
Block a user