A pre-deletion warning is valuable because it exposes dependencies, not because it prevents every deletion. After inserting an image in a text editor, record how many manuscripts and occurrences refer to the asset before reorganizing it. The decision then becomes delete, move and rewrite, or retain—not a blind confirmation click.
Using a move to test the dependency record
The synthetic Markdown file referenced assets/figure.png once. Rune reported one using file and one occurrence. A move to moved/renamed-figure.png produced a one-file, one-occurrence rewrite plan. After application, the chapter contained zero old references and one new reference. The dependency count and rewritten result therefore matched.
When a real warning names an unfamiliar source, stop before deleting. Open that source and decide whether the asset is obsolete or merely being relocated. A count larger than expected can reveal an unsaved tab or another chapter, and should narrow the investigation rather than authorize a wider rewrite.
Product documentation describes a graphical confirmation dialog; this command-line inspection measured usage and rewriting but did not exercise that dialog. Accept the cleanup only when every referring source is accounted for and no broken local reference remains. External URLs and non-text formats are outside the documented rewrite scope.
Count both sides of the deletion gate
The synthetic candidate is a harmless non-image file named route-map.asset. Two manuscript files each reference it once using Markdown-style syntax. Rune's usage command returned fileCount=2 and occurrenceCount=2. Those values turn an apparently unused item into a concrete dependency: two documents would be affected by removing one path.
Preview trashing without removing the candidate
The next command used the trash operation with --dry-run. Its purpose was to preserve the failure state while checking the intended target. After the preview, the candidate still existed, and the evidence explicitly records actual_deletion_performed=false. Once nonzero usage has been measured, cancellation is the successful safety outcome.
Do not invent a dialog observation
Rune's UI-to-CLI documentation associates this workflow with a deletion-confirmation screen. The CLI session did not render the graphical dialog, its buttons, or its warning color, and no screenshot was created. The observed evidence is narrower and stronger: the exact candidate path, two referring files, two occurrences, a dry-run operation, and a preserved candidate.
Reduce dependencies before any future deletion
If the asset is truly obsolete, update the two manuscripts to their replacement first and rerun the usage query until the old path has zero occurrences. Then inspect sources outside the command's documented scope, such as stylesheets, remote references, or unsaved buffers. Only an authorized cleanup pass should perform the actual removal; this evidence run intentionally did not.
A safe referenced image deletion workflow is complete when it can explain why deletion is allowed or refused. Here it was refused: usage was nonzero and the file remained. That result prevents a broken link more effectively than a successful delete command or an unverified recollection of a warning screen.
A future zero count also needs target identity. Record the candidate digest before cleanup so a same-named replacement is not removed accidentally. If the application moves files to trash rather than erasing them, note the recovery location and retention window. Recoverability is part of the gate, especially when a late proof reveals that the replacement has different dimensions or content.
Reference scanners have a declared scope. The measured command found Markdown-style uses in two text manuscripts; it should not be generalized to every possible asset consumer. CSS url() entries, package metadata, external build scripts, or a graphical setting may require their own searches. The acceptance sheet should list those exclusions instead of turning a two-file result into “unused everywhere.”
When dependencies have been migrated, make the replacement a separate change. Reopen both manuscripts, verify the new path and intended display context, then query the old candidate again. A zero result after that controlled edit explains why cleanup may proceed. If the count remains one, locate that owner rather than deleting and repairing the broken chapter later.
This measured attempt intentionally ends before deletion. The artifact still exists and both references are preserved, so the failure state can be inspected without reconstructing anything. That is a positive test result for a deletion warning: unsafe intent was recognized, quantified, and stopped. The graphical warning may later be tested in the Mac interface, but it is not needed to justify the cancellation recorded here.
For teams, require the person who changes references to hand the zero-count record to the person who approves removal. That separation prevents an assumption that “someone else checked.” The approver can verify the same path and digest, confirm exclusions, and preserve the recovery location before allowing a destructive step. The current test stops earlier because its measured count is two.
A warning feature earns trust when the underlying dependency query is inspectable. File and occurrence counts explain the consequence of the attempted deletion, while the retained specimen lets another reviewer reproduce the finding. This is more actionable than a screenshot alone, which might show a warning without identifying all affected manuscripts or the exact candidate revision.
The command order is intentionally asymmetric: identify the target, measure usage, preview the destructive action, and stop when dependencies exist. It does not proceed through deletion merely to complete a demonstration. Requiring a deleted artifact would defeat the safety property under test. A later zero-dependency case should receive a separate evidence record with its own target digest and approval.
The two manuscripts also provide a regression set. After any sanctioned replacement, reopen both and verify that their new references resolve before considering the old candidate unused. This catches a bulk edit that changes one occurrence but misses the other. The expected count moves from two old references to zero only when both documents have been handled.
For this run, the result remains deliberately simple: the path exists, two files refer to it, the preview command did not remove it, and no graphical-dialog observation is claimed. Every sentence can be traced to a saved command result or the documented interface boundary. That makes the article useful even without a live UI capture.