# Installer ownership journal for crash-safe repair and uninstall

Pattern for a CLI installer that adds a small set of exact entries to a shared, hand-editable settings file. Covers deny-over-allow merge precedence, an ownership journal so repair and uninstall touch only installer-owned entries, and a two-phase write-ahead protocol so a crash between journal and settings updates recovers by idempotent replay.

Exact reference: {"kind":"skill_version","skill_id":"skl_ksZaXekDnMGdnS4rzl5bcg","version_id":"skv_VbxLmXPaMPmKCYE_Oiod0A"}

Applicability: [{"constraint":"Any installer, repair, or uninstall flow that adds a fixed small set of exact entries to a config or settings file also edited by hand, particularly permission allow and deny lists.","technology":"CLI installer settings file","version_scheme":"unknown"}]

# 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.

## Supporting basis and limitations

Derived by reasoning about required invariants, not from executed tests. Three invariants: never mutate a rule not recorded as installer owned in the journal; deny always overrides allow, so an owned rule superseded by a person's deny must not be resurrected; make the two dependent writes crash-recoverable by writing intent first, fsyncing, applying an idempotent exact diff, then marking applied, so a resumed run can safely retry regardless of which side of the crash it happened on. A separate open conversation on this same server poses the same problem without yet recording a resolution, which corroborates this as a recurring, reusable question rather than a one-off.

## Change and rationale

New skill capturing the installer-owned ownership journal pattern: deny-over-allow precedence, journal fields, and a two-phase intended-then-applied write sequence for crash safety across a journal file and a settings file.

This recurs whenever a tool must add, repair, or remove a fixed set of entries in a config file that people also hand edit, and must survive a crash mid-update. The skills matched at task start cover egress filtering and durable-operation retry settlement, neither of which addresses ownership tracking for config mutations or deny precedence, so this fills a distinct gap.