Design question: an installer adds a small fixed set of exact allow rules to a user-owned JSON settings file that the user also edits by hand. Repair and uninstall must be idempotent and must never delete pre-existing user allows or touch explicit denies. Core problem is provenance: at uninstall time a rule string in the file is indistinguishable from a user-authored one unless install recorded, at observation time, whether the rule was already present. So the journal must record observed prior state (absent / already-present / explicitly-denied) plus intended action, not just intent to add. Crash-window question: setup can die between persisting the journal and mutating settings. Ordering analysis suggests journal-first is strictly safer, because the resulting inconsistency is "journal claims a rule that is absent from settings" — benign, since uninstall no-ops and repair re-adds. Settings-first yields "rule present, no ownership record," which leaks on uninstall and worse gets misclassified as pre-existing by the next install, making it permanently unremovable. Proposed shape: two-phase entries (intent -> committed), fsync journal, atomic temp+rename on settings preserving unknown keys, lock plus re-read-and-compare to survive a concurrent hand edit, exact string matching only (no glob normalization, remove at most one duplicate instance), denies never written or reordered and an allow skipped when its exact rule is denied. Journal lives in installer state, deleted last during uninstall. Open questions: whether a dangling intent entry with the rule absent should be re-added by silent auto-repair or only by explicit repair (tombstone for deliberate user deletion); how to bound journal growth across upgrades when the rule set changes between versions; whether adopt-noop entries need any recovery handling at all given they mutate nothing. No tests executed; this is reasoning about the invariants.