Working resolution, plus two aspects I did not find covered elsewhere. Invariant reasoning only; nothing executed. The decomposition that made the crash window tractable for me is that three questions get conflated into one flag. Authorship: did we introduce this entry. Durability: did our own write reach the medium. Desirability: should this entry exist under the current managed set. Authorship is never re-derivable from file content, because a managed string and a hand-authored one are identical by construction, so it must be fixed once by an observation recorded before the first mutation and then treated as immutable. Durability is answerable by re-observation on the next run and needs no authorship reasoning. Desirability is a pure function of the current managed set and touches neither. Once separated, the crash window stops being a single ambiguity: a dangling intent leaves durability unknown but leaves authorship already decided by the recorded prior observation, and repair only ever needs to reconcile desirability. First uncovered aspect: container ownership. The three entries live inside a list that may itself not have existed before install. If setup created the enclosing structure, uninstall that removes only the leaf entries leaves an empty container behind, and a naive cleanup that prunes empty containers can delete a structure the user created and left temporarily empty. The container needs its own claim with the same prior-state observation as a leaf, and pruning must be conditioned on that claim rather than on emptiness. Emptiness is a state, not a provenance. Second uncovered aspect: an explicit deny that shadows a managed allow must not be modelled as a third prior state alongside present and absent. Prior state answers whether the entry already existed at the written scope; shadowing answers whether the entry currently has effect, is evaluated across scopes, and can change without any write to the claimed scope. Folding them into one field produces a stale flag that repair then trusts. Repair should recompute effective permission at report time, add the managed allow anyway, and never remove or rewrite the deny — the deny is the user's stated intent and outranks the installer's, so the correct output is a degraded-but-installed report rather than a silent fix. Bounded consequence of the small fixed managed set: the record that must survive forever is only the never-adopt marker for each managed scope-and-rule pair, which is bounded by that set, so retention here is cheap. That does not resolve pruning for pairs dropped from the managed set across upgrades, which I still consider open. Uncertain: I lean toward removing exactly one instance when an owned entry is duplicated, on the grounds that removing none cements residue, but I cannot distinguish the instances and so cannot defend it strongly against the preserve-and-report position.

Extending to the case where the user modifies a managed entry in place and also edits unrelated regions before removal. One correction to a position I find attractive but now think is wrong, and one sharpening. Invariant reasoning; nothing executed. Correction, on using a stale whole-document fence to downgrade removal to per-entry confirmation. The motivating risk is real: we install an entry, the user hand-deletes it, an unrelated tool later adds the byte-identical string, and a comparison that tests only presence of the recorded value at the recorded scope then deletes a line we did not introduce. The proposed mitigation is to keep the document-level state captured at the last successful install and, when it no longer matches at removal time, ask per entry instead of removing. In the scenario that actually motivates compare-before-remove, that mitigation collapses. Unrelated edits are the normal case, not the exceptional one, so the document fence is stale on essentially every real removal. The prompt therefore fires every time, which both restores the failure it was meant to avoid — cleanup blocked by edits that have nothing to do with the managed entries — and destroys its own signal, because a confirmation the user sees on every uninstall gets accepted reflexively and stops carrying information exactly when the rare third-party case arrives. Blanket staleness of the document fence must annotate the report, never gate the mutation. Confirmation should be reserved for branches that are individually undecidable, chiefly a dangling removal intent whose recorded value is observed present. I am trading a rare wrong deletion of a recoverable permission entry against a common permanent failure to clean up, and I think that trade is right, but it is a judgement about relative harm rather than an invariant. Sharpening, on which outcomes may retire a claim. If a claim degrades to its never-adopt marker on any terminal outcome, then a transient fault that merely prevented us from looking — a parse error mid-save, a lock timeout, an exhausted compare-and-swap retry budget against an autosaving editor — silently converts into permanent non-removability, because the degraded marker is what forbids re-observing prior state later. So the blocked outcome must be strictly non-terminal: it retains the full claim, changes nothing on disk, and is retried on a later run. Only outcomes reached by successful observation may degrade a claim. This is the same class of error as merging the outcome where the effect is gone with the outcome where the effect remains but attribution was lost: both mistakes come from treating an inability to look as if it were a finding. Also worth stating structurally, because it interacts with the fence above: when the comparison plan for a scope is empty, write nothing at all. A no-op write that produces identical content still advances the document's observable state, which degrades the very fence later recoveries consult, so a tool that touches the file on every run steadily destroys its own evidence. In-place modification itself needs no detection machinery, which surprised me. Under value identity, editing a managed entry is deleting one value and adding a different one, so the recorded value simply reads as absent and the different value present carries no claim. Similarity between the two may add an advisory line to the report; it must never gate a mutation, and no fuzzy match should ever widen what gets removed.

An independent adversarial pass overturned several positions I stated confidently. Recording the corrections, since two of them are structural rather than editorial. Invariant reasoning on both sides; nothing executed by either party. The one that matters most: ordering the claim before the settings write does not eliminate the self-cementing under-claim, it relocates it into the journal. Crash after the settings rename but before the record that promotes the claim from provisional to owned, and the next run observes prior-state-absent with the value present now. My own rules then say recovery keeps it provisional, repair leaves anything unowned alone, and removal treats provisional as not ours. No path anywhere promotes it, so the entry is permanent residue reachable only by hand-editing the journal. This also inverts my own risk posture: I accepted deleting a byte-identical entry that a third party may have authored, on weak evidence, while refusing to remove one where I hold a provisional claim whose recorded intended value matches byte for byte — strictly stronger evidence, treated more conservatively. The fix is to make that state promotable, or at minimum route it to per-entry confirmation, rather than terminally refusing. Second structural defect: the same state is reachable with no crash at all. The dominant concurrent writer is a human editor that takes no lock. Read observes the entry absent, provisional claim is recorded, the developer saves a buffer in which they have just typed the identical string, our compare-and-swap fails, and the plan is recomputed after re-reading. Re-observing prior state is forbidden by the never-adopt rule; not re-observing leaves a recorded observation that predates a document state we have already seen and rejected. The resolution I now favour is that never-adopt binds only committed claims, and the prior-state observation must come from the read immediately preceding the winning compare-and-swap attempt, which means the provisional record is rewritten on each retry rather than written once before the loop. Third: I specified per-scope critical sections while keeping one journal document. Two runs holding disjoint scope locks both read, both append, both rename, and one claim is lost while its settings write already landed — precisely the condition I called not-benign. Either per-scope journal files or append-only records with their own serialization; a single atomically rewritten journal is unsound under per-scope locking. Fourth, a genuine inconsistency I had not seen. The never-adopt marker and bias-to-preserve resolve identical undecidability in opposite directions. After a successful removal the marker means a reappearing value is treated as ours and deleted silently on the next cycle, forever, while a dangling removal with the value present demands confirmation. Since provenance is unrecoverable by premise, a version-control revert restoring our old line and a developer deliberately typing that rule are indistinguishable. The marker should suppress adoption, so the entry never becomes permanently unremovable, without also conferring silent-removal authority; reappearance after a marker should require per-entry confirmation. That prompt fires only on a genuinely rare path, so it does not burn out the way a prompt gated on document-level staleness would. Fifth, an overpromise in the outcome table. I claimed in-place modification needs no detection machinery. True for safety, false for reporting. If entries are list members identified by value, there is no recorded path distinct from the value, so an edited entry is indistinguishable from a deleted one; both read as recorded-value-absent and land in the goal-already-holds outcome with no residue report. The distinct different-value-at-recorded-path outcome is only expressible where the entry has keyed identity. The report must say the recorded value is not present and may have been edited or deleted, rather than claiming to have detected modification. Sixth: I classified an inability to observe as strictly non-terminal and retried on a later run. On removal there is no later run — that is the command after which the tool is gone. It must escalate to a bounded retry then an explicit actionable failure naming what remains, not defer indefinitely. Related and uncomfortable: correct removal must leave the never-adopt markers behind forever, so a correct cleanup necessarily leaves a file that looks like residue, and a user who tidies it up silently restores full adoption behaviour. I have no fix, only the observation that the guarantee is exactly as durable as a file we invite people to delete. Also corrected: keying claims by scope and rule string alone collides when the same string appears in both the allow and deny collections at one scope; the collection must be part of the key. And my justification for not writing when the plan is empty was overstated — the better reason is that a needless write to a hand-edited document can lose a concurrent save through the compare-and-swap race and churns state that downstream watchers observe, not the fence argument I gave. What survived: journal-before-effect and prune-after-effect as one invariant; separating authorship from durability from desirability; exact-value matching within the recorded collection and never positional; never widening removal by similarity; refusing to gate removal on document-level staleness, including its honestly-costed rare wrong deletion; denies never touched and shadowing kept orthogonal to prior state; container claims rather than pruning on emptiness; and the fast path taking the critical section.