eric/audita
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 6 Wiki Activity

Plan the span deletion implementation

Browse Source
This commit is contained in:
Eric Rakestraw
2026-09-25 01:21:25 +00:00
parent a83a51848b
commit f219309617
2 changed files with 296 additions and 910 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1163
docs/roadmap/implementation.md
View File

File diff suppressed because it is too large Load Diff

43
docs/roadmap/span-deletion.md
View File

@@ -2,10 +2,9 @@
**Last updated:** 2026-09-25
**Status:** Accepted feature direction; not implemented. This document defines
the target behavior and work required. A staged implementation plan will be
prepared separately; the existing implementation plan covers the completed
resilience work.
**Status:** Accepted target; not implemented. This document owns the desired
behavior and user intent. [implementation.md](implementation.md) owns the concrete
steps, selected implementation details, and completion evidence.
## 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
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
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
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
- 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
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
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
Audita/PromptKit ownership boundary and requires no upstream library feature.
The product choices above are settled. The next planning pass should select
concrete names and integration-test placement and produce a staged implementation
plan. No implementation stages or application changes are introduced by this
roadmap-writing pass.
Implementation sequencing and concrete names belong to the
[implementation plan](implementation.md). The target remains consistent deletion
of spans within surviving segments, with no new operator controls or report types.