A case subtree has been cloned once per release, and one release's copy gets a corrected step. How does that correction reach the other releases' copies?

## Nothing propagates, and that is the whole model When a case subtree is cloned per release, each release ends up with its own records. The repository stores an edit as a write to one record's fields. It has no notion that two cases in different folders are the same logical case, so an edit in one has no effect anywhere else - not on the source it was copied from, not on the sibling copies, not on any case that merely reads identically. That is worth stating flatly in an interview, because candidates often assume a copy behaves like a reference and will refresh itself. It will not. Any provenance note a product writes at clone time is descriptive text: useful for finding the source, but not a channel through which anything travels. ## How the correction actually travels 1. **Classify the change first.** Is this a correction to the *case* - a wrong expected result, a step that names the wrong screen, a typo - or a description of how *this release* behaves? Only the first kind should travel. Copying a behaviour description into an older release's copy makes that copy wrong for the release it describes. 2. **List the sibling copies** for every release still supported. This is the step that is cheap or expensive depending on decisions made at clone time. 3. **Open each copy and read it before editing.** A copy may carry deliberate release-specific wording; blind overwrite is how that wording is lost. 4. **Apply the edit, then record that you did.** A short note or a field value on each copy tells the next reader the set was reconciled, and on which day. ## Finding the siblings is the expensive half - **A shared lineage value** stamped into a field on every copy at clone time - the same value on all copies of one logical case. A filter on it lists the whole set in seconds. This is the only approach that stays reliable for years. - **Title matching**, which works until somebody edits a title, fixes a typo on one side, or splits a case in two. Its failures are silent: the match simply returns nothing, or the wrong case. - **Folder position**, which works until either tree is reorganised - and release trees get reorganised precisely because the releases diverge. - **Export and compare outside the repository**, which is the fallback when nothing was stamped: pull both subtrees into a flat file and match on text. Slow, lossy, and the reason to stamp a key in the first place. ## Three ways this goes wrong | Shortcut | What it costs | |---|---| | Re-cloning the source subtree over a stale copy to refresh it | Wipes the target's release-specific edits, and the results already recorded against the replaced cases are orphaned or point at cases that no longer exist | | Bulk-editing a selection that was assembled by search | Sweeps in cases from releases you did not mean to touch, and bulk edits are rarely reversible in one action | | Fixing only the release being worked on | The older supported release quietly keeps the wrong expected result, and the next person to run it either files a false defect or records a false pass | ## When the copies should stay different Divergence is not automatically a defect. Two supported releases genuinely can behave differently, and their copies *should* say so. The discipline is not *keep every copy identical* - that discards the only benefit of copying - but *know which differences are intentional*. A difference someone deliberately made and recorded is an asset. A difference nobody knows about is a trap, because the next reader cannot tell whether they are looking at a real release difference or a fix that never got carried across. The cheapest habit that makes all of this tractable costs one decision at clone time: stamp a stable lineage value on every copied case, and never derive it from the title, the folder or the release name. Derived values change when the thing they were derived from changes - which is exactly the moment you needed the value to still match.