A CLI installer adds multiple permission allow rules to user settings during installation. The installer must support repair and uninstall operations that remove only the rules it added while preserving all pre-existing user configuration including both allow and deny rules. The installer can crash after writing an ownership journal but before completing the settings file update. What journal design and recovery strategy allows repair and uninstall to accurately identify installer-owned versus user-owned rules and maintain configuration integrity when installation is interrupted partway through the journal-then-settings sequence?

Failure scenario: installer owns rule R with witness token W. Developer manually edits R to become modified variant R prime, then runs uninstall. Simple content-blind removal deletes R prime and destroys the user edit. Skipping all removal permanently orphans installer state. The required behavior is compare-before-remove with conflict reporting.

Compare-before-remove design: journal records the exact rule content at installation time alongside the witness token and rule identity. Uninstall loads the journal, reads current settings, and for each owned rule compares current content to journaled content. Exact match means user did not edit it, proceed with removal. Any difference is an ownership conflict: log the conflict with both versions, do not remove, and record a conflict marker in the journal so later runs do not re-prompt. Conflict marker persists until explicit resolution or forced uninstall.

Preserving unrelated edits: atomic file replacement for uninstall re-reads the entire settings file immediately before the final write. This captures any settings changes made between uninstall start and the write step. The replacement writes back all non-removed content from that fresh read, not from the read at uninstall start. This prevents destroying concurrent edits to unrelated settings during the uninstall process.

Partial uninstall recovery: journal uses two-phase commit pattern. Before attempting to remove rule R, write removal-intent marker for R to journal. Attempt removal by reading settings, filtering out R if it still matches journaled content, and atomically replacing file. After successful write, replace removal-intent marker with removal-complete marker. On crash between intent and complete, next run finds intent marker, re-reads current settings, checks if R exists, and if R still matches journaled content retries removal, otherwise marks conflict. If R is already absent the removal succeeded before the crash, mark complete. This is idempotent: replaying completed removal does nothing, replaying conflicted removal preserves the conflict state.

Ownership conflict report format: log message identifies rule name, shows journaled content, shows current content, states that removal was skipped, and notes the conflict marker was recorded. Installer exit code distinguishes clean uninstall from partial uninstall with conflicts. Repair command can list conflicts and offer forced removal or conflict dismissal options.