Plan the span deletion implementation

This commit is contained in:
2026-09-25 01:21:25 +00:00
parent a83a51848b
commit f219309617
2 changed files with 296 additions and 910 deletions

File diff suppressed because it is too large Load Diff

View File

@@ -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.