The code remembers.

The excavation began with an uncomfortable mismatch. Customer support had two receipts for one purchase, yet the payment service dashboard showed a clean morning. Requests returned success. Error rate remained at zero. Latency stayed beneath the alert threshold. Queue depth never moved. The ordinary instruments said nothing had happened, but the ledger contained two settled entries carrying the same business intent. That contradiction made the retry wrapper at services payments capture lines eighty eight through one hundred six more interesting than the payment gateway itself. The wrapper looked disciplined. It limited attempts, waited between failures, logged completion, and returned a familiar result. Every line resembled code that experienced engineers approve without discussion. Familiarity was the first warning.

A repository scan found the same control shape in catalog reads, notification delivery, profile loading, invoice lookup, and payment capture. Names differed, comments praised different goals, and formatting reflected several teams. After comments were removed and local identifiers became canonical symbols, the shared skeleton remained. Each copy caught a broad failure, slept, and repeated the operation. This was not proof that authors lacked understanding. It was proof that one mechanism had traveled farther than its documented contract. The detector therefore framed a narrower question. Which hidden assumption made the source safe, and did each descendant still satisfy it? For the catalog source, repetition only fetched data. For payment capture, repetition could create money movement. Similar syntax concealed opposite consequences.

The analysis is deliberately local and mechanical. A small lexer walks each bundled snippet without evaluating it. It tracks quoted strings, line comments, and block comments so decorative language cannot create a match. Remaining tokens are classified. Keywords and operators retain their identity. String and number literals become stable placeholders. Each newly encountered identifier receives a canonical name according to first appearance. Renaming request to operation or result to response therefore changes presentation but not structure. The resulting stream is divided into overlapping groups of five tokens. A stable hash fingerprints every group, and Jaccard overlap measures how many fingerprints two snippets share. This procedure is modest, inspectable, and genuinely running in the page.

The fingerprints establish structural kinship, not human intention. They cannot say who copied whom, whether a model generated either version, or whether an engineer understood the pattern. Direction comes from the fictional commit dates and paths. Meaning comes from counterfactual behavior. That boundary matters because cargo cult is an accusation when used carelessly. The useful engineering claim is less theatrical: these implementations share enough lexical structure to justify comparing their assumptions. Exact citations make that claim reviewable. The catalog helper at src catalog fetch with retry lines eighteen through thirty one predates the shared wrapper and payment descendant. Its surrounding tests call only read operations. The later payment file adds no idempotency key, transaction lookup, or duplicate suppression. Evidence stops there; origin remains probable.

Under its original assumption, the helper is boring. A catalog read times out before returning, the wrapper repeats it, and both attempts describe the same inventory. No durable state changes. The first mutation adds ordinary latency but preserves that property. The second mutation moves the timeout across the commit boundary. Payment capture reaches the processor, the processor commits the charge, and the acknowledgement is delayed long enough for the client deadline to expire. The wrapper sees an exception rather than a receipt. Because exceptions are classified as retryable and no idempotency key accompanies the request, attempt two creates another charge. One checkout intent now owns two ledger entries. The invariant fails silently because each local branch behaved as designed.

Silence is the signature of this case. The second processor response is successful, so the final HTTP status is green. Both attempts complete quickly enough that aggregated latency remains green. Caught timeouts never increment the terminal error counter. The work queue drains. The circuit breaker sees a successful dependency. No alarm knows that two technically valid captures correspond to one order. Only a business invariant can detect the damage, and that invariant is absent from the copied wrapper. The danger ranking therefore combines four measured dimensions rather than visual suspicion: violated invariants, consequence impact, supported lineage spread, and observability stealth. Moving the assumption slider changes those inputs. The page does not ask a reviewer to bless boxes; it makes the failure execute as a deterministic state transition.

The commit trench reconstructs a plausible route without pretending certainty. Commit c4a91ef introduces the payment copy during a gateway migration on February eleventh, 2026. Its message says the shared retry policy is being reused for consistency. Commit 27bb09d created that shared policy in 2021 by extracting repeated network handling. The oldest repository specimen appears in commit 8d31c2a from 2016 inside catalog fetching. A nearby architecture note links reliable read behavior to a conference example, but no surviving source establishes direct copying. Every layer therefore carries the word probable. The label is not cosmetic caution. It separates observed repository facts from the story that best connects them and invites a reviewer to replace inference with stronger evidence.

The likely drift is familiar. Advice begins inside a narrow context where retries are cheap because requests are idempotent. A useful helper removes noise from call sites. Extraction erases the noun catalog, leaving a general name such as with retry. General naming expands perceived jurisdiction. Later engineers find a tested utility and prefer consistency over reinvention. The call type still satisfies the compiler, and staging rarely produces a timeout in the few milliseconds after remote commitment. Each move is locally rational. Across a decade, however, the precondition becomes folklore and then disappears. The code retains the procedure while shedding the explanation. That is why excavation must descend through commits. The dangerous change may be the removal of context rather than the addition of a line.

The remaining candidates demonstrate why resemblance alone cannot rank danger. A certificate verification override began in a localhost fixture and later reached an internal production client. Its mutated assumption is network trust: once traffic crosses a hostile boundary, a successful connection can authenticate an attacker. A cache helper copied a seconds based time to live value into an interface expecting milliseconds. Its mutation is load, because a nearly instant expiry stays invisible until repeated misses saturate the backing store. An authorization fallback copied from an optional feature flag returns allow when policy data is unavailable. Partition the policy service and absence becomes permission. A timezone normalizer copied from reporting silently assigns server midnight to customer dates and shifts records across billing periods.

All four deserve attention, yet the payment retry leads because its strongest counterfactual combines immediate monetary impact, broad structural spread, and near perfect stealth. The ranking is sensitive to assumptions. If certificate verification faces only a sealed test network, its present consequence is low despite ugly syntax. If the network boundary moves, its rank climbs. If cache traffic is tiny, unit confusion wastes little. Under launch load, the same confusion can create an outage. This is the purpose of mutation driven review. Static rules can find broad catches, disabled verification, suspicious defaults, and unit conversions, but danger belongs to the environment around them. A ranked excavation should expose the variables that could reorder findings instead of presenting one permanent score with false authority.

The immediate repair is not merely deleting retries. Payment capture needs resilience, but resilience must operate at the business boundary. Generate one idempotency key for each checkout intent, persist it before the first remote attempt, and send it on every retry. After any ambiguous timeout, query by that key before creating another capture. Enforce a unique ledger constraint that rejects a second settled charge for the same intent. Record attempt count separately from charge count. Alert on invariant violations even when transport health is perfect. Narrow retry classification to documented transient failures and place a finite deadline around the entire operation, not a fresh deadline around each attempt. These controls make duplicate money movement difficult and visible.

The broader repair is documentation that travels with abstraction. Name helpers according to their safe domain, such as retry idempotent read, rather than with retry. Encode requirements in types where practical. Require an idempotency strategy when a write operation enters the policy. Add fault injection that delays acknowledgement after commitment, because failure before commitment tests the easy half of distributed uncertainty. Search every fingerprint descendant and assign an owner; fixing only the discovered payment path leaves the next copy ready to drift. Preserve the excavation record with observed facts, probable history, rejected explanations, and exact citations. Future maintainers should not need another decade of commits to rediscover the same missing sentence: repetition is safe only when repeated intent cannot create repeated effect.

Finally, treat the green dashboard as evidence about transport, not truth about business outcomes. Instrument intent, effect, and reconciliation as separate events. When they disagree, preserve the trace before retries erase ambiguity. A reliable system does not merely recover from failure. It knows which promises survived, which repeated, and which still require a human decision.