Check replace semantics before editing

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

A report hasA/B and needsC appended. Teaching R replaces all; I inserts at end. SendingC alone toR removes earlier chapters, and update naming does not establish patch semantics.

Mechanism

Inspect target/current content/semantics. Append where supported; replacement requires merging current full text and version-conditional write. Read back scope and reconcile conflicts instead of overwriting intervening edits from cache.

Bad example

SendC toR assuming patch and claim appended without inspecting lostA/B.

Good example

Verify R/I, useI or merge currentA/B+C forR under supported version checks. Read back retainedA/B and correctC position; preserve intervening edits on conflict. Unknown semantics remain a gap, not guessed patch or success as content evidence.

Why the change matters

Operation semantics define preservation. Proper selection/readback ties successful transport to intended text changes.

Observable expectation

The fixture yieldsA+B+C; R/C-only and wrong insertion fail. Concurrent B2 remains B2 rather than cachedB.

Inspect target/version/content; no cloud document is edited.

Limits

Omitted/null/array semantics differ by API. Reads/writes need conditional or coordination where supported; frozen identifiers establish no current flags.