Refresh the Donor Without Overwriting the Candidate

Recovery work can last longer than a deployment cycle.

While engineers are cleaning and validating a candidate, the live application may ship a new release. The team then needs fresh evidence without erasing candidate changes or pretending the old conclusions still describe production.

This is a donor-refresh problem, not a source-merge problem.

Preserve ownership boundaries

The editable candidate belongs to the recovery and engineering process. A refresh should not rewrite its source, package manifest, public assets, or build configuration.

The capture-owned surfaces can advance instead:

• donor bytes;
• capture metadata;
• network evidence;
• integrity roots;
• replay graphs and reports;
• the canonical update summary.

Keeping those writes separate prevents a recapture from destroying or silently “fixing” the candidate.

Make promotion transactional

A canonical refresh changes several related artifacts. If the donor tree advances but its integrity document or workspace fingerprint does not, the workspace enters an ambiguous state.

The promotion should stage the new generation, validate it, and replace the capture surfaces as one rollback-managed operation. A write failure restores the prior generation rather than leaving a mixed workspace.

Version control can preserve the earlier canonical donor so the update summary can compare exact bytes without maintaining parallel snapshot directories forever.

Reuse environment policy, not credentials

The original capture environment can preserve safe operational settings such as browser backend, concurrency, retry limits, timeouts, pacing, robots policy, and interaction limits.

Authentication cookies, secrets, referers, and custom credential headers should not be persisted. A protected refresh must require the operator to supply them again and fail closed when they are absent.

This maintains reproducibility without turning a portable capture into a credential archive.

Replay the route trail

If the original capture recorded a navigation flow, refresh can replay that ordered trail before finalizing the new donor.

This is important for states built through in-memory navigation or DOM interaction. Forcing a final return to the landing page can discard the very runtime state the flow was intended to reacquire.

The stored flow remains the authority for route order. Refresh behavior should not invent new application intent.

Report the delta

A refresh summary should distinguish:

• files added, removed, and modified;
• byte totals;
• bundle and asset changes;
• API or realtime hints;
• newly acquired route-local artifacts;
• degraded or unresolved capture continuity;
• the prior and current donor identities.

These facts tell downstream recovery which evidence must be regenerated.

Continuity must be narrow

Sometimes an exact literal dynamic import was captured in an earlier sealed generation but was not exercised in the current session. Carrying its previous exact bytes may preserve a bounded continuity path when current acquisition is exhausted.

That exception must be strict: literal, same-origin, regular-file, digest-authenticated, and not an eager or organically failing import. Current bodies always win. Computed or drifting targets are refused.

The result should record that the byte came from the prior sealed generation rather than presenting it as newly observed.

Refresh invalidates downstream claims

A new donor can change bundle boundaries, dependencies, routes, runtime behavior, and protected surfaces. Old recovery plans or parity baselines may no longer be fresh.

That is not a reason to avoid refresh. It is a reason to bind every downstream artifact to the donor generation it describes.

KodeCapture keeps donor refresh independent from candidate editing so teams can compare a moving deployment with ongoing recovery work. The safe outcome is not an automatic merge. It is a new evidence generation, a reviewable delta, and an explicit decision about what must be revalidated.