4.2 KiB
Span Deletion Review: Required Remediation
Reviewed: 2026-09-25, source commit 24b8992.
Scope: The four implementation commits after 31979d4, compared with
span-deletion.md, implementation.md,
the agreed user intent, and repository policies.
Status: R15 open. Earlier findings R1–R14 are resolved; their evidence and
resolution records remain in Git history through 24b8992.
Architecture Assessment
The intended span-deletion behavior is implemented without introducing another processing path. PromptKit accepts required string replacements including the empty string; Audita retains responsibility for literal matching, module-specific validation, and safe application. Nonempty whitespace-only original spans are eligible. The renamed resulting-segment validator and application guard prevent blank segments, while existing module scopes and replacement policies remain.
Validator requests carry the replacement and full before/after segment text. Approved proposals apply sequentially, with applicability rechecked after earlier edits. The runner distinguishes original proposal defects from later conflicts. Debug ledger mapping preserves explicit empty proposed/applied replacements and keeps absent values distinct. Existing resilience and reporting boundaries remain.
No production defect or unintended strengthening of the agreed requirements was identified in this review. The finding below concerns a regression test that does not actually protect one explicitly agreed reporting distinction.
R15 — P2: Exercise Operation Accounting in the Deletion Conflict Test
Category: Ineffective regression coverage for conflict classification.
Evidence: TestRunnerApplyConflictAfterTwoInitiallyValidDeletions in
runner_test.go correctly checks
that the first deletion applies and the second is skipped to prevent a blank
segment. However, it uses fakeModule, whose Propose returns proposals without
operation outcomes. Its two deterministic validators also return no operations.
The final loop asserting absence of errors/recoveries therefore checks an empty
operation list.
In runner.go,
mergeFilteredProposals can attach a recovery only to a successful proposal
operation. Without that operation, even incorrectly attributing the conflict as
a defective proposal cannot produce the recovery the test is meant to detect.
A temporary Go build overlay that removed the initially-applicable guard in
attributeApplyFiltering still passed this exact test. The production guard was
not changed and appears correct.
Required change: Revise this existing test to supply a successful proposal
operation alongside its two candidates, using the existing outcomeModule helper
or equivalent small fixture. Assert that the proposal operation is present before
checking that it has no failure, filtering recovery, or filtered-proposal records.
Retain the existing final-text and skipped-decision assertions. No production
change, additional CLI scenario, or new test framework is needed.
Acceptance: The revised test passes with the current production behavior and fails if an initially valid deletion made unsafe by an earlier edit is incorrectly recorded as proposal filtering. It continues to prove that only the first deletion applies and that the second remains visible as a skipped decision. Fix the existing test rather than adding overlapping coverage.
Review Verification and Limits
go test ./...passed against the committed implementation.- Reviewed schema, domain checks, prompt changes, validator payloads, sequential application/accounting, debug serialization, new tests, and updated contracts.
- The focused overlay experiment passed despite deliberately removing the conflict-classification guard, confirming R15. The overlay existed only in a temporary directory and did not modify repository source.
- No live-provider evaluation was performed. Offline fixtures establish pipeline behavior, not a guarantee that a model will always propose or approve good edits.
- This review records remediation only; it does not implement the test correction or any deferred feature.