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

One Tinker per Mac — Hands Don't Reach Across the Room

~12 min · per-mac, registry, enrollment, state, accessibility

Level 0Idle Hands
0 XP0/39 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"There is no default Mac: a command that changes what is on a screen runs where it was asked to, or not at all." — Tinker architecture

An Actuator Is Local by Nature

Most family services live on one host and are reached from everywhere: one Coop writer, one Kiln engine, one Watchfire. Tinker cannot work that way. Hiding an app is an AppKit call made inside the logged-in user session of the Mac whose screen you want to change. A Tinker on one Mac has no way to hide a window on another, and should not be given one. So Tinker is a per-Mac member: every Mac that takes it runs its own resident agent, with its own settings, its own journal, its own shortcuts and its own Accessibility grant.

Which Macs Is Registry Data

Nothing in Tinker's code or prose names a machine. The family registry says which Macs take Tinker — its per-Mac enrollment places it on the workbenches group, the Macs where Pippa needs hands. A new workbench gets Tinker by joining that group; no file in the Tinker repo changes. The port works the same way: Tinker's claim in the family port ledger is an @each claim, like Delta's and Smolder's, meaning the same loopback port number on every enrolled Mac rather than one port on one host.

Pippa Names the Mac

Because every instance listens on the same port, "call Tinker" is not a complete sentence. Pippa's app door for a per-Mac member takes a mac argument — a fleet label from that enrollment — and reaches that Mac's loopback door over the family control route. It never picks a Mac by itself. If Dad has two workbenches open and says "editing mode", the honest answer to "which one?" is a question, not a guess, and running the command on both is two separate requests with two separate outcomes.

State Never Crosses Macs

Presets are per Mac. On a Mac's first launch Tinker copies its bundled seed into that Mac's settings; every later install preserves whatever Dad has changed there, and no other Mac's settings ever overwrite it. That is not an accident of implementation but a consequence of what a preset is: a list of apps that matter on this screen. The video Mac and the coding Mac have different distractions.

Each Grant Is Dad's Own Click

Hiding another app's windows needs the Accessibility permission, and macOS grants that per Mac, per app, by a person in System Settings. Tinker never prompts at launch, never edits the privacy database, and never synthesizes consent. On each Mac the first live hide waits until Dad is present and has granted Accessibility there himself. A success on one Mac is never reported as a success on another.

Code

Per-Mac member vs single-host service·text
single-host service (e.g. Kiln)        per-Mac member (Tinker)
-------------------------------        -----------------------
one engine, one port                   one agent per enrolled Mac
reached from every Mac                 same @each port on every Mac
one database                           settings + journal per Mac
caller needs no Mac name               caller MUST name the Mac
grant (if any) once                    Accessibility granted per Mac by Dad
How a caller should treat a per-Mac member: no Mac, no call·python
def tinker_call(action: str, args: dict, mac: str | None) -> dict:
    """Illustrative client rule, not the family transport itself."""
    if not mac:
        # A command that changes a screen runs where it was asked to,
        # or not at all. Never fall back to 'the usual Mac'.
        raise ValueError("Name the Mac: Tinker acts only on the Mac it runs on.")
    enrolled = registry_per_machine_labels("cwkTinker")
    if mac not in enrolled:
        raise ValueError(f"{mac} does not take Tinker")
    return app_door(member="cwkTinker", mac=mac).invoke(action, args)

External links

Exercise

You add a third workbench Mac to the family. List every step needed before Tinker can hide an app on it, and mark each step as either registry data, an install action, or something only Dad can do. Which step would a fully automated rollout be tempted to skip?
Hint
Joining the workbenches group is data; creating the runtime environment and receiving the signed bundle are install actions; the Accessibility grant and being present for the first live hide are Dad's. Automation is always tempted to treat the grant as a checkbox — Tinker treats it as a person's decision on that Mac.

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.