"Manual shows are not re-hidden." — Tinker architecture, hide invariant 5
Dad Changes His Mind Mid-Edit
Editing mode is on; Claude, Voyager and Eagle are hidden. Twenty minutes in, Dad needs to check something in Voyager and clicks its Dock icon. Voyager comes forward. What should Tinker do? A policy engine — the kind of thing that enforces a configuration — would notice Voyager is visible in violation of the active preset and hide it again. Tinker does nothing at all. It is not watching. It made a change at a moment Dad asked for it, and that change has now been overruled by the same person who asked. His most recent action wins.
No Watcher, by Design
Tinker contains no loop that compares the screen to the active presets. There is no observer on application visibility that would fire when Voyager reappears. That absence is the feature: a tool that re-hides apps you just opened is a tool you fight, and a tool you fight gets uninstalled. The architecture describes Tinker as an actuator and explicitly not a monitor; enforcement would turn it into both.
What Happens to the Receipt
Voyager's receipt is still in the journal, still owned by the editing preset. Nothing updates it when Dad shows Voyager. When he later finishes editing, restore calls undo on that receipt; undo checks that the same process is still hidden, finds it visible, returns .noLongerApplicable and touches nothing. The receipt is cleared. Undo's job was to make sure Tinker's change is no longer in the world — and Dad already did that.
Re-applying Is a New Request
Applying the editing preset again while it is active — edit.apply, or Pippa's preset.apply — does nothing; the engine sees the owner is active and returns. (The toggle key is different on purpose: pressed again, it restores.) Another preset that lists Voyager will find the existing applied receipt and simply join its owners without calling the OS. Only after the editing preset is restored, and Voyager's receipt is gone, does a fresh apply hide Voyager again — because that is a new request from Dad, made with Voyager visible in front of him.
The Same Rule in Recovery
The principle extends to the hardest case. When a record is uncertain, the Recovery tab says "Inspect this app manually first. Forget keeps its current visibility unchanged." Forgetting an uncertain record removes Tinker's claim; it never shows or hides anything to "fix" the screen. Whatever Dad sees is left exactly as he sees it.