Skip to content
C.W.K.
Lesson 05 of 05 · published

A Manual Show Wins — Actions, Not Enforcement

~12 min · user-intent, no-enforcement, manual-show, noLongerApplicable

Level 0Idle Hands
0 XP0/39 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"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.

Code

Undo defers to whatever the person did in between·swift
public override func undo(_ change: JSONValue) async throws -> UndoResult {
  let identity = try decodeValue(ApplicationIdentity.self, change)
  // Dad already showed it (or it quit): our change is no longer in the world.
  guard applications.hidden(identity) == true else { return .noLongerApplicable }
  try await applications.setHidden(false, for: identity)
  return .restored
}
Applying an active preset is a no-op, not a re-enforcement·swift
public func apply(id: String, steps: [CapabilityStep]) async throws {
  guard !executing else { throw TinkerError("Another action is in progress.") }
  executing = true
  defer { executing = false }
  guard !stopped, fault == nil else { throw TinkerError(fault ?? "Tinker is stopped. Resume it in Settings.") }
  if journal.active.contains(id) { return }      // already applied: do nothing
  // ...prepare and apply as usual
}

External links

Exercise

List three tools you use that enforce a state (an MDM profile, a focus blocker, a sync client) and three that perform an action and stop (a script, a shortcut, an undo button). For each enforcing tool, describe one moment when its enforcement fought you. Would a receipt-and-undo design have avoided it?
Hint
Enforcement is right when the state must hold whatever the user does (a security policy). It is wrong when the user is the authority, which is the case for a personal convenience like hiding distractions. Tinker chooses action-plus-receipt precisely because Dad is the authority over his own screen.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign in — Please sign in to comment.

No comments yet — be the first.