C.W.K.
Stream
Lesson 04 of 05 · published

When Proof Fails, Fall to the Clipboard

~10 min · clipboard-fallback, safety-over-convenience, graceful-degradation, visible-failure

Level 0Cold Flint
0 XP0/34 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"The best thing a careful tool can do when it isn't sure is nothing — plus hand you the result so you can finish it yourself."

The Refusal Is the Feature

Every proof in this track has a failure branch, and they all lead to the same place: the clipboard. When Flint cannot prove the target is still the one you meant — native re-read mismatched, opaque re-copy didn't reproduce, window changed — it does not insert. It copies the transformed result to the clipboard and tells you. The refusal to paste into an unproven target is not a limitation Flint apologizes for; it is the single most important thing the insertion layer does. A guard that never refuses isn't a guard.

Recoverable Beats Irreversible

The whole calculus is recoverability. If Flint guesses and pastes into the wrong place, the damage can be irreversible: your text posted into a chat, or the wrong content overwritten with no clean undo. If Flint declines and puts the result on the clipboard, the worst case is a small inconvenience — you paste it yourself, one keystroke, wherever you actually want it. Between a rare catastrophe and a routine minor step, you choose the minor step every time. Safety outranks convenience after an async call, always.

native target proven?  -- yes --> direct AX replace   (best)
        | no
opaque target proven?  -- yes --> paste replace        (good)
        | no
                       ---------> CLIPBOARD + notify    (safe fallback)

Every unproven path lands in the same safe place. There is no branch
that inserts into a target Flint could not prove.

Tell the User, Don't Fail Silently

The fallback only works if the user knows it happened. A result that silently lands on the clipboard with no signal feels like the strike did nothing — the exact 'this app is broken' impression the whole design fights. So the fallback is visible: a brief HUD or notification says the result is on the clipboard, ready to paste. Now the user understands the outcome — 'it couldn't safely replace, so it handed me the text' — and knows exactly what to do next. Visible degradation is a feature working as designed; silent degradation is indistinguishable from a bug.

After an async effect you can't prove safe, do the recoverable thing and surface it. The pairing matters: refusing the risky action protects the user, and telling them what you did instead keeps them in control. Do one without the other and you either gamble with their data or leave them confused. A careful tool's failure mode should be quiet in its damage and loud in its communication — nothing broken, and nothing hidden.
This connects to spending model calls wisely: the same philosophy says Flint shouldn't even make the inference call if it already knows it can't insert (for example, Accessibility permission is missing — Track 7). Here the call already happened and the target went stale, so the result is salvaged to the clipboard. Upstream, Flint avoids spending calls it can't land; downstream, it never wastes a result it did produce.

Code

The decision, with the clipboard as the universal safe exit·swift
func place(_ result: String, into snap: TargetSnapshot) {
    if let element = proveNative(snap) {
        replaceSelection(with: result, in: element)      // best: direct AX
    } else if proveOpaque(snap) {
        pasteReplace(result)                             // good: verified paste
    } else {
        copyToClipboardAndNotify(result)                 // safe: never guess
    }
}

func copyToClipboardAndNotify(_ result: String) {
    NSPasteboard.general.clearContents()
    NSPasteboard.general.setString(result, forType: .string)
    notify("Result copied to clipboard — target moved, so it wasn't inserted.")
    // Visible, recoverable, honest. The user pastes it where they want.
}

External links

Exercise

Compare two designs for the 'target went stale' case: (A) insert into whatever is frontmost now, and (B) copy to clipboard and notify. Work through the best case, the typical case, and the worst case for each. Then explain why 'silently copy to clipboard with no notification' is worse than B even though it's safer than A.
Hint
(A) best case it happens to be right, worst case it posts your text into the wrong app irreversibly. (B) best/typical/worst are all 'you paste it yourself' — bounded and recoverable. Silent-copy is safer than A (no wrong insertion) but worse than B because the user can't tell the strike from a no-op: the result sits unmentioned, the app reads as broken, and the recoverability is wasted because the user doesn't know there's anything to recover.

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 inPlease sign in to comment.

No comments yet — be the first.