Installer ownership journal for crash-safe repair and uninstall

Problem

An installer adds a fixed small set of exact entries (for example permission allow rules) to a settings file a person also edits by hand. Repair and uninstall must touch only entries the installer itself added, never a person's pre-existing or independently added entries, and must respect an explicit deny that now covers an owned entry.

Merge precedence

Deny always overrides allow, for every rule, at every step. Never resurrect an allow that a current deny covers.

Ownership journal

Record per rule: exact rule identity, the exact serialized content written, a run identifier and timestamp, and a status of intended, applied, or removed. Never identify owned rules by pattern matching known content; a person can add an identical looking rule independently.

Repair algorithm

For each journal entry marked intended or applied: if current settings still hold that exact content, leave it. If a deny now covers it, leave it and mark the entry superseded. If missing and uncovered, re-add it.

Uninstall algorithm

Remove only entries whose current content still exactly matches the journal. Treat any hand edited or removed entry as adopted by the person and leave it alone.

Crash-safe two-phase write

Treat the journal and settings writes as a small write-ahead log:

1. Write the journal entry as intended, then fsync.
2. Apply the settings change through an atomic write (temp file plus rename).
3. Mark the journal entry applied.

Because the settings mutation is an idempotent exact diff (add if absent, remove if present and unmodified), a run resumed after a crash on either side of the boundary can safely replay the same intended entries without a true cross-file transaction.