A command line installer manages six exact tool permission allow rules in a developer settings document the user also edits by hand. Repair must converge without duplicating entries, uninstall must remove only what the installer introduced, and explicit deny entries must never be weakened, reordered or removed.

Known evidence: rule identity is textual, so a digest of an exact rule string proves integrity but never authorship. Ownership therefore has to be recorded out of band, in a journal bound to a resolved target and to a managed set generation.

Unknowns: setup can crash between flushing the journal and replacing settings, or after replacing settings but before marking the journal committed. That yields either a claim with no rule, or a rule whose claim is only pending. Which write ordering and which reconciliation rule are safest when journal and settings disagree, and what should repair do with an entry that is present but unclaimed?

Resolution, reached by reasoning. Nothing was implemented and no crash injection was executed.

First, a correction to my own opening position. I had concluded that because settings land by a single atomic rename, landing is one bit, and therefore any single planned entry visible afterwards that was recorded absent at plan time proves the batch landed. That is unsound. The counter-example is an install that crashes before its settings write while the developer hand adds one of the managed values inside the crash window. The by example rule reads that entry as proof the write landed, claims ownership of a value the developer authored, and a later uninstall deletes it. That is precisely the failure the whole pattern exists to prevent. Landing must be inferred by agreement across every effect that is not a no-op, with an explicit undecided branch that changes nothing and disclaims ownership, rather than by a single witness.

Second, a correction in the other direction. I treated a not landed verdict as restoring prior ownership. That fails when an uninstall write landed but was never marked committed and the developer then re-created the values by hand. Rollback reads them as proof the uninstall never happened and re-owns developer entries. Ownership may return only on positive evidence of not landing, such as all effects still at their base counts with unchanged file identity. Otherwise the entries return as unverified and require an explicit adopt before they can ever be removed.

Third, I had conflated two artifacts under one pending to committed state machine. The durable ownership journal and the transient pending record have different lifetimes. The journal survives until an uninstall completes and every entry is terminal. The pending record describes one in flight change and is cleared at the end of the command. Collapsing them leads an implementer to delete the ownership record at the end of a normal install, which leaks every grant permanently.

Now the finding I did not find stated anywhere, which is a gap in the agreement rule itself.

The agreement rule is sound only when the set of effects that are not no-ops has more than one member. It is standard and correct to ignore no-op effects when judging whether the write landed, since they carry no signal. But that filtering is what determines the size of the agreement set, and the size is not fixed by the size of the managed set. With six managed rules, a repair run on a nearly converged installation can easily have five already present as preexisting and exactly one effect to apply. At that cardinality the phrase all effects at their expected counts denotes exactly one observation, so inference by agreement silently degenerates into inference by example, which is the unsound rule this design replaced. The same crash window counter-example applies again, unchanged, and nothing in the procedure signals that the guarantee has lapsed.

The degeneracy is quiet, which is what makes it dangerous. The rule is stated once, looks sound when read against a full six effect install, and becomes unsound only on the runs that are most common in practice, namely repeated repair on an installation that is already almost correct.

Two corrections, either sufficient.

Consult file identity on the landed branch as well, not only on the not landed branch. An atomic rename replaces the target, so an unchanged file identity contradicts the claim that our rename occurred. As stated, identity is checked only when concluding not landed, so the single effect case reaches landed without ever testing the one cheap observation that could refute it. Checking identity on both branches costs nothing and turns the one witness case from a false positive into a contradiction, which routes to undecided.

(continued, part 2 of 2)

Independently, require corroboration whenever the agreement set has exactly one member. Either a matching result hash or a changed file identity must be present before concluding landed. Absent both, the verdict is undecided, ownership of that effect is disclaimed, and the entry is reported. This is the conservative direction the rest of the design already commits to, and it costs at most one leaked grant recoverable by explicit adopt.

A related consequence worth stating. Because a matching result hash is a sound positive test while a mismatch proves nothing, the hash is the only observation that rescues the single effect case without ambiguity. That makes recording the expected result hash more load bearing than it first appears. It is not merely an optimisation that short circuits counting, it is the sole source of redundancy on exactly the runs where counting has none.

I also withdraw an earlier claim that occurrence counts are vestigial once entries are treated as a set. A developer can add a duplicate copy after install, so a legitimate plan can go from two occurrences to one, and a set model cannot express that. Counts are load bearing. What I still hold is the narrower point that the installer should not write a second copy of a value it observed as already present, because a host that deduplicates the list would then cause a later uninstall to remove the developer copy.

Suggested verification, none of it run. A repair run engineered so that exactly one effect is not a no-op, crashed before the settings write, with the developer hand adding that one value inside the window, asserting that recovery reaches undecided rather than claiming ownership. The same scenario with file identity checked on both branches, asserting the contradiction is detected. An uninstall whose write landed but was never committed, followed by the developer re-creating every value by hand, then an unrelated command, asserting that nothing is re-owned. A host driven reformat between runs, asserting that a failed result hash match never by itself causes a removal.