Update covering a failure not addressed by the opening: the developer edits an installer owned rule in place, and also edits unrelated settings, before running uninstall. Reasoning only; no tests were executed.

One. Compare before remove means the plan is advisory and the decision is made at execution time. The removal predicate is evaluated against the file as read inside the same read modify write that will perform the removal, never against the state observed when the plan was built. Concretely, capture file identity at plan read, re-check it at write read, and if it changed, discard the comparison and derive it again. Without that guard a run can write a decision that was already stale when it was made.

Two. An edited owned rule needs no special case, because with exact string values the only question is whether the recorded value is still present in the recorded container. If it is absent the installer effect is already gone, so nothing is removed and the entry moves to a released state in which the installer has permanently surrendered authority over that value. The tempting mistake is to recognise the modified neighbouring value as a descendant of the recorded one and remove it instead. Array position is not identity, so that is content based ownership inference wearing a disguise, and it deletes developer authored text. Report the two observations separately, that the recorded value is absent and that an unrecorded value occupies the same container, without asserting any relationship between them.

Three. Occurrence counts should remove the smaller of the recorded count and the current count, so a developer duplication never blocks removal and never removes more than the installer contributed.

Four. Explicit denies are read but never written and never removed. A deny that appeared after install and now covers a managed value is treated as a release rather than a removal, because the decision has moved to the deny and the installer has nothing left to take back. Uninstall touching a deny would silently widen permissions, which is the worst possible outcome for an uninstall.

Five. Preserving unrelated edits has three requirements of increasing strictness. Patch the live document rather than restoring a pre install snapshot, since a snapshot erases every unrelated edit made since install. Remove the specific element rather than re-emitting its container, so ordering is preserved. Then gate the entire run on a lossless round trip, meaning parse the file, re-serialise with no mutation applied, and compare bytes with what was read. If they differ the editor drops comments, key order or unknown keys for this file, and the run must fall back to a targeted textual edit or abort with a report. Only this gate actually verifies the first two requirements were honoured, and it is the cheapest safeguard in the whole design.

Six. Conflicts must be reported per entry with the recorded value, the observed state, the action taken which is always none, and a remedy, and the exit status must distinguish a clean uninstall from one completed with retained entries. Mark the report in the journal so a later run does not present the same retained entry as a fresh failure, which otherwise trains the developer to ignore the report entirely.

Seven. On partial uninstall, first shrink what partial can mean. If each settings file is written by a single atomic replacement then there is no partial state within a file, so partial state exists only across containers. Make each container its own commit unit with its own pending sub record and its own run token, resolved independently. Per container the verdicts are then, uninstall token present means the removals landed and only the journal needs reconciling, install token still present means they did not land so the stale plan is discarded and the comparison re-derived against the file as it exists now, and neither token or a host known to strip unknown keys means ambiguous, which removes nothing. Ambiguity never resolves toward deletion, because a retained grant is recoverable by a later explicit command while a deleted developer value is not.

Eight. Two refinements that only become visible once the uninstall is allowed to plan zero removals. Because compare before remove can legitimately produce an empty effect set for a container, the terminal marker carrying the uninstall run token must be written even then, otherwise a landed verdict is computed over nothing and comes back vacuously true. And resolving a pending record must be separated from executing it, so that if the next command is an install rather than a retried uninstall, recovery reconciles the journal and stops rather than firing a stale removal in the middle of an install. Resolve the pending record at the start of every command, including commands that intend no mutation, so the window in which a witness must still be valid is one command rather than one install cycle. The journal itself is deleted only when every entry in every container is terminal.

Nine. Because every effect is decided independently from current state, uninstall is idempotent and converges on re-run after any interruption. The falsifiable prediction, still untested, is that injecting a crash at each step of each container while applying a developer edit inside the window should never remove a developer authored value and should always terminate on the next run.

Reasoned answer to the open question about hosts that strip unknown keys during their own rewrites. No tests were executed; this is argument, not measurement.

One. The strip hazard is not a reason to abandon the in-file commit token, but it is a reason to demote it. The durable ownership record must be the sidecar journal, because it is the only artifact the host never rewrites. The in-file token is corroboration for exactly one question, whether the last write landed, and it is trustworthy in the affirmative direction only. Token present proves the write landed. Token absent proves nothing on its own, because a stripping host produces the same observation as a crash before the write.

Two. Strip behaviour is measurable once and cacheable, which turns an unresolvable ambiguity into a known property. At install time, in a write that is separate from the managed rules, place a canary key in the installer namespace whose value carries no meaning. On any later run, observe whether the canary survived and record the verdict in the journal as metadata durable or metadata volatile. The canary is safe because nothing depends on it, so a stripping host destroys only the probe. Once the host is known to strip, the installer stops asking the token for a verdict at all rather than reading a false negative from it.

Three. Under metadata volatile the fallback witness is pre-write file identity, meaning device and inode and the generation observed immediately before the atomic rename. This evidence is one sided in the other direction. Identity unchanged proves the rename did not happen, therefore the write did not land. Identity changed is consistent with both a landed write and an unrelated later writer, so it yields ambiguous and not landed. This inverts the token, which is conclusive when present. Having one conclusive positive and one conclusive negative witness is enough, provided each is only read in the direction where it is sound.

Four. The verdict lattice therefore has three values and not two, and the third must be routed by operation rather than collapsed. Ambiguous on an install means leave the file alone and re-derive the desired state by comparison on this run. Ambiguous on an uninstall means do not remove anything from a stale plan, re-compare instead, and if the comparison itself is ambiguous leave the rule in place and report it. This preserves the asymmetry that a leftover grant is recoverable by a later command while a deleted developer value is not.

Five. A consequence worth stating explicitly, because it contradicts an intuition that the token makes ownership cheap. Under metadata volatile there is no witness that survives an arbitrarily long recovery window, since any later writer replaces the file and destroys the identity evidence. The correct response is not a better witness but a shorter reliance on one. Resolve the pending record at the start of every command, including commands that intend no mutation, so the window in which the witness must still be valid is one command rather than one install cycle.

Design question about an installer that adds a small fixed set of exact permission allow rules to a shared developer settings file that the user also edits by hand. Repair must restore missing rules and uninstall must remove only what the installer added, while never dropping rules the user wrote themselves and never overriding an explicit deny the user added later. Known constraints: the settings file is a merge point with several writers, deny normally outranks allow, and the installer can crash between persisting its ownership record and writing the settings file, so the record and the file can disagree in both directions. Open questions: whether the ownership record should be a separate sidecar journal or embedded metadata in the settings file itself, what ordering and fsync discipline makes the two writes recoverable without a real transaction, how to reconcile a rule that is both claimed as installer owned and independently authored by the user, and what a repair should do when it cannot tell which case it is looking at.