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

Prove an Opaque Target by Reproduction

~11 min · recopy-compare, opaque-target, window-match, reproduction

Level 0Cold Flint
0 XP0/34 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"If you can't inspect the target, reproduce it. Copy again — if the same words come back, the same selection is still there."

No Element to Re-Read

The native re-proof leaned on reading the focused element and its range. Opaque targets — the Chromium and Electron apps from Track 3 — don't give you that element to re-read, so the whole 'compare the range' approach is off the table. You can't inspect what you can't see. But you can still prove the target a different way, using the one thing these apps do reliably support: copy.

Prove by Reproduction

The idea is to prove the selection by reproducing it. If you re-issue a Cmd+C and the exact text you captured at the strike comes back onto the clipboard, then the same selection is still active in the same place — the app just demonstrated it for you. If a different string comes back (or nothing), the selection changed during the wait, and you must not replace. Reproduction stands in for inspection: you can't look at the target, but you can ask it to show you the selection again and check that it's unchanged.

NATIVE:  re-read element -> compare range        (inspection)
OPAQUE:  same window? + re-copy -> compare text   (reproduction)

Both answer the same question — 'is the exact selection I captured
still the one that's active?' — by whatever means the target allows.

Same Window, Same Selection

The opaque proof has two parts. First, confirm the same focused window is still frontmost — the coarser identity these apps do expose. Second, run the reproduction: a fresh, reversible Cmd+C (the same reversible probe from Track 3, full pasteboard preservation and all) whose result must equal the captured selection. Only if the window matches and the re-copy reproduces the exact text does Flint treat the target as proven. Either check failing sends the result to the clipboard instead.

When you can't inspect state, reproducing it is a valid proof. Verification doesn't always mean reading a value directly. Sometimes the honest way to know a condition still holds is to re-trigger the thing that produced it and confirm you get the same result. Reproduction is weaker than inspection in what it can tell you, but where inspection is impossible, a faithful re-trigger that yields the identical output is a real, defensible proof — far better than assuming the state held.
The re-copy is another reversible probe — it owes the same full restore. Proving an opaque target borrows the clipboard exactly as the original read did, so it carries the same obligation: snapshot the whole pasteboard first, do the compare copy, restore everything after — success or mismatch. A proof step that quietly ate the user's clipboard would trade one safety for another. The reversible-probe discipline from Track 3 isn't a one-time trick; it's reused every time Flint touches the clipboard to learn something.

Code

Prove an opaque target: same window + reproduce the selection·swift
func proveOpaque(_ snap: TargetSnapshot) -> Bool {
    // 1. Same focused window still frontmost (the identity opaque apps expose).
    guard let front = NSWorkspace.shared.frontmostApplication,
          front.processIdentifier == snap.pid,
          sameFocusedWindow(as: snap) else { return false }

    // 2. Reproduce the selection with a fresh REVERSIBLE copy (Track 3).
    //    capturePasteboard -> Cmd+C -> read -> restorePasteboard, always.
    let reproduced = probeSelectionViaCopy()   // fully clipboard-preserving

    // Same text back == same selection still active == safe to replace.
    return reproduced == snap.selection
}

External links

Exercise

For an Electron chat app, design the full opaque proof and name what each step rules out: (1) same focused window check, (2) reversible re-copy, (3) compare to the captured selection. Then explain why reproduction is an acceptable proof here even though it's weaker than the native range inspection, and what obligation the re-copy inherits from Track 3.
Hint
The window check rules out 'user switched windows/apps'; the re-copy rules out 'selection changed or collapsed'; the compare rules out 'different text now selected.' Reproduction is acceptable because inspection is impossible for opaque targets, and a faithful re-copy yielding the identical text genuinely demonstrates the same selection is active. Its inherited obligation is the reversible-probe discipline: snapshot and restore the entire pasteboard around the compare copy, on every path.

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.