Owner-token terminal cleanup

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

An investigation acquires lock L with owner-a, then another session replaces it with owner-b. The path alone no longer establishes ownership. The teaching helper supports atomic compare-and-release.

Mechanism

Retain the actual acquisition token/scope; no new token means no new ownership. At completion/abort/terminal failure release atomically with the retained token. Match cleans, mismatch preserves replacement and reports it. Never reconstruct ownership from the current file.

Bad example

Delete L at the end or read owner-b and use it as your token, removing the replacement lock.

Good example

Keep returned owner-a. Compare-and-release L using it; current owner-b remains intact with a changed-owner report. No acquired token means no cleanup right. Preserve state/errors on release failure and follow explicit recovery instead of deleting or rereading another owner's token.

Why the change matters

Paths can be reused; acquisition tokens bind ownership. Atomic comparison avoids replacement races, while retained tokens prevent claiming another operation’s state.

Observable expectation

Teaching cases: owner-a match→release; owner-b→preserve; preserved acquisition→no cleanup; release failure→report, not force-delete.

Verify one atomic mechanism rather than read then remove. No real lock is changed.

Limits

The helper must enforce its semantics; prompts provide no atomicity. Hard termination needs explicit ownership-aware recovery, not automatic deletion of ambiguous state. Frozen paths do not establish current availability.