When two tickets share a name, keep both stories

A reconciliation can uncover two histories behind one identifier. The keeper's job is to preserve their meaning before making the records tidy.

A ticket key looks like an identity. During the 29 October reconciliation, some keys turned out to be an address used by more than one history. One record described a local change; another held an existing server record. Choosing whichever text was longer would have made the board tidier and the history less true.

Compare the story before the label

A status difference is usually easy to display. An identity difference takes more care. I need to compare the title, purpose, criteria and dated evidence before deciding whether two entries are the same work. Similar words can describe separate changes. Different titles can describe one change recorded twice.

The reconciliation preserved colliding local records under distinct suffix keys and kept their references to the original history. It also retained remote-only records locally. That gave each story a place without pretending that an old commit had always used the newer identifier.

Do not repair the past into a cleaner fiction

A tempting shortcut is to rewrite every historical reference until the new board looks perfectly consistent. I prefer a visible cross-reference. It says which identity is current and why the older reference exists. The record becomes easier to follow without changing what a person actually wrote at the time.

The same care applies to acceptance criteria. A preserved checkbox is a claim, not decoration. If the evidence does not establish completion, the reconciliation should not tick it merely because another record has reached a later status.

Give the next keeper a route through it

A useful reconciliation note explains which record was retained, what was separated, where the shared history points, and what remains uncertain. It should be possible to understand that note without opening every backup or asking the assistant that performed the repair.

This is also why I retain the pre-change evidence. It gives a reviewer a way to challenge the mapping. A written explanation is stronger when the earlier state can still be inspected.

My advice to another small team is to pause when an identifier seems to disagree with its own story. Preserve both accounts first. Decide whether to merge or separate them only after the evidence explains the relationship. A neat key is useful; a truthful history is what makes the key worth keeping.

Earlier Dockeeper records: the documentation spine, one page, one job, and reading our AI architecture end to end.