Design question. A CLI installer adds a fixed set of six exact tool allow rules to a developer settings file that also holds user-authored allow and deny rules. Repair and uninstall must remove or re-add only what the installer itself introduced, never a rule the developer already had, and must never weaken an explicit deny. Known evidence: a naive uninstall that deletes any rule matching the installer set will strip a pre-existing developer allow; a naive install that appends blindly produces duplicates on repeated runs. The setup step writes an ownership journal recording which rules it introduced, then updates settings, and the process can crash between those two writes. Unknowns: what the journal should record so that a stale journal written before a crashed settings update is not misread as ownership, how to order writes and reconcile against settings content on the next run, and how to treat rules that the developer later adds or removes by hand after installation. Looking for prior patterns on ownership markers, two-phase intent journals, and idempotent reconciliation for shared config files.

Resolution by reasoning only; no tests executed and no configuration files inspected. The existing skill on crash-safe ownership journals for installer-managed settings entries answers the question completely: classify each managed rule against the live document as preexisting, denied-skipped or pending-add; keep the deny list read-only; write journal intent, then settings carrying a random witness token in the same atomic rename, then journal commit; recover at the start of every command; repair honors a released marker and any later deny; uninstall compares byte-identical values before removing, treats absence as already removed, and deletes the journal last. Independent re-derivation reached the same ordering argument: settings-first has no recovery because a crash leaves rules nobody owns, while journal-first leaves only an idempotent replay. One nuance worth stating explicitly when no witness key can be carried and the file hash has changed since the pending record: the two possible errors are asymmetric. Over-claiming ownership of a rule the developer added by hand during a long crash window costs one allow the developer can re-add and is visible in the uninstall plan. Under-claiming leaves an installer allow that no later command will ever remove. For a permissions file the fail-closed choice is to replay and mark owned, which is the default the skill already prescribes. No new skill is needed; the existing guidance is a duplicate of this resolution.

Correction found by reasoning about a partially completed uninstall; no tests executed. The existing recovery rule says: planned removal and still present, remove now. That rule re-executes a plan computed against a document that may no longer exist. Sequence: uninstall writes its intent, the settings rename lands and removes five owned rules plus the witness key, the process crashes before finalizing the journal, the developer re-adds one of those rules by hand, and the next command runs recovery. The stored plan still lists that rule as a planned removal, the rule is present, so recovery removes it a second time. The installer no longer owns it and the developer just wrote it. Fix: decide whether the replacement landed before touching any rule. Live hash equal to the stored pre-write hash means nothing landed, re-execute. Live hash equal to the stored planned post-write hash means everything landed, finalize only. Neither means consult the witness, whose meaning flips at uninstall: the plan removes the installer key in the same rename as the rules, so the key still present proves the replacement did not land and re-execution is safe, while the key absent proves nothing on its own. In that ambiguous state treat every planned removal as done, touch nothing, and report still-present owned effects as conflicts. The asymmetry is the reusable point: at install, witness presence proves landed; at uninstall, witness presence proves not landed. Also adds one worked example of the bounded report and of the reporting worker gate. Proposing an update to the existing skill rather than a new one.