Record empty replacement handling as future work

docs/roadmap/future.md

@@ -49,3 +49,25 @@ deterministic despite different completion orders, and fatal cancellation must
 still stop and join active work. Assess whether the scheduling change materially
 improves real workloads before introducing additional orchestration machinery.
 No new scheduler, global limiter, or execution mode is selected by this entry.
+
+## Empty Replacement Text and Segment Removal
+
+Address a frequent proposal failure reported in production: the LLM supplies an
+empty string as `corrected_text`, possibly because it intends to remove the
+entire segment. That interpretation is a hypothesis, not a reliable signal of
+intent. Improve both prompting and handling so this case has a clear, consistent
+outcome rather than repeatedly producing unusable proposals.
+
+Review representative examples and distinguish deletion of a text span from
+removal of an entire segment. Define whether either operation is supported, how
+it is represented, and what validation is required. Align proposal prompts,
+response contracts, validators, application behavior, and error/recovery reporting
+with the selected semantics. If an operation is unsupported, prompts should give
+clear guidance on what the model should return instead.
+
+Do not infer authorization to delete a segment from an empty replacement alone.
+Any future support for segment removal must address meaning preservation and the
+effect on segment identity, timestamps, fixed chunks, later stages, and output.
+Coordinate with domain-aware response recovery where feedback could resolve an
+invalid proposal. Exact deletion semantics and recovery behavior remain undecided;
+this entry does not relax current validation or expand the resilience workstream.