Dry-runs, Apply, and Revert
Dry-run
Section titled “Dry-run”A dry-run performs source, mapping, target-read, and planning work, then stores operations without calling target write methods. It does not advance a full baseline, incremental fingerprints, rewatch state, diary ledger, or managed-list state.
Run cards show source and target titles, feature chips, result/apply state, and source-first artwork. Expand Details for mapping provenance, source mapping, the complete captured target snapshot, changed fields, reasons, and opaque-safe audit data.
An unapplied dry-run operation can be applied individually. Filtered bulk Apply is available only when the item history is restricted to one exact run. Before applying prepared custom-list changes, Brokerr revalidates the target version or fingerprint.
Applying selected operations is useful for correcting unmatched mappings, but it does not turn a dry full run into the profile’s authoritative full baseline.
Revert
Section titled “Revert”Live operations persist provider-specific revert payloads. Item-level Revert and Revert All use the target runtime and its shared pacing/retry policy. A run is marked Reverted when all applied changes are restored and Partially reverted when only part was restored.
Revert also updates feature fingerprints so the next incremental run can correctly propose the source state again.
Not every remote object is safely reversible. Letterboxd diary entries are deleted only when Brokerr can prove it created the exact log entry. Pre-existing diary rows are never removed. A custom list created by Brokerr is deleted on Revert only when ownership and unchanged remote state are proven.
Reset profile data
Section titled “Reset profile data”Reset data keeps the profile and provider connections but clears its baseline fingerprints, feature/rewatch state, unmatched/ignored records, and manual mapping overrides. Historical runs remain attached to their old profile lifecycle. Managed-list bindings remain, but require a fresh baseline.