rootiest
100cb478bc
Verified an agy audit of every bare rm call (the trash-routing C1 shadow) by hand rather than trusting its report. Confirmed correct: scrub.fish's custom_rm strategy and logs.fish's Ctrl-D delete both deliberately want trash for a real, user-facing deletion. Confirmed and fixed three cases where a function's own throwaway scratch file was going to the user's trash instead of being wiped: fc.fish's edited-command tmpfile, dng2avif.fish's intermediate PNM (inconsistent with its own failure-path cleanup two lines up, which already used -f), and _scrollback_prune_junk.fish's junk log files (its sibling _prune_terminal_logs.fish already documents this exact pitfall in its header). Also went further than the report and classified every bypasses-shadow(rm) caller found by grep that had never been audited at all: config-settings.fish and edit.fish (own scratch cleanup, no destructive data at stake) and key-crypt.fish (--remove deletes the user's real input file after encryption, genuinely destructive, already documented in its own header as 'not a secure wipe'). Corrected scrub.fish's tag, which was missing uses-shadow(rm) for its deliberate trash-routing branch alongside the bypass branch it already had tagged. Added a note to the schema doc: rm's flag-based fallback lives inside the shadow itself, so a bare rm -f/rm -rf call is not the caller bypassing anything -- only an explicit command rm/builtin rm earns the tag. This is why dng2avif.fish's fix needed no CLASSIFICATION change: it already used rm -f, which was never actually the bug -- the missing -f on line 122 was.
4.1 KiB
Function CLASSIFICATION schema
This is the canonical definition of the # CLASSIFICATION function
doc-header label. It's referenced from code comments and commit messages —
link here, not to anything under AGENTS/ (that tree is git-ignored local
agent state, not part of the repo).
See Public function documentation header
in CONTRIBUTING.md for where CLASSIFICATION fits among the other header
labels, and C1 — Command Shadows
for the full list of C1-shadowed commands this schema's shadow tags refer to.
Format
Optional. Comma-separated tags from the closed set below, on the indented body line directly under the label:
# CLASSIFICATION
# uses-shadow(ls), destructive
Omit the label entirely when nothing applies — omission means "nothing to flag," not "not yet audited," so don't add it speculatively, and don't add it empty as a placeholder.
Tags
uses-shadow(name[,name...])— calls a C1-shadowed command (see the C1 doc linked above) bare, deliberately wanting the overridden behavior (e.g.lswanting eza's icons for a human to read).bypasses-shadow(name[,name...])— callscommand <name>,builtin <name>, or (forhelpspecifically)__original_help $argv, deliberately forcing stock behavior because the shadow's override would break this function's logic: timestamps leaking into a parsed capture,-iprompting on a path meant to run unattended, structural output changes breaking astring/sedparse, etc.destructive— can irreversibly delete or overwrite data:rm -f,rm -rf, truncating or force-overwriting a file,git push --force. Routine cleanup of the function's own$tmpdir/$_tmpdir/mktempoutput (or other output it just created in this same call) is expected behavior, not a hazard — don't tag it.network— makes an outbound network call:curl,wget,ssh,git fetch/pull/push/clone,paru/yay(package-manager network ops), talking to an API, etc.blocking-prompt— can block waiting on interactive confirmation with no non-interactive escape hatch: a shadow's forced-i, fish'sread(genuinely waiting on a terminal — not astring split | readorwhile readconsuming a pipe, which never blocks), aconfirm-style prompt with no--yes/--force/--silentbypass. Don't tag a function that's only ever meant to be run interactively at a prompt (a keybinding handler, an fzf-driven picker) — the hazard this tag exists for is a script or another function calling it unexpectedly, not a human running it themselves.
Placement
Directly under # DEPENDENCIES if the header has one; otherwise directly
under # COMPONENT; otherwise directly under # CATEGORY; otherwise as
the first label in the header block (this is the common case for internal
_-prefixed helpers, which usually carry none of the three).
Judgment calls
uses-shadow vs bypasses-shadow is the easiest place to get subtly
wrong — verify against the actual code, not just whether the name appears
in the file. A function that only calls a helper which itself interacts
with a shadow does not get the tag; the tag belongs on the helper. When
generating these tags in bulk (e.g. delegating the sweep to another
model), review every result against the source before trusting it — this
schema's own rollout caught several false positives this way: a piped
read misread as an interactive prompt, a documented --yes flag missed
as an escape hatch, and cleanup of a function's own temp output flagged
as destructive despite the explicit exclusion above.
rm specifically has its own internal flag check (any flag other than
-r/-R/--recursive falls back to command rm inside the shadow
itself, before it ever touches trash) — a caller writing plain rm -f
or rm -rf is not bypassing anything itself, the shadow is. Only tag
bypasses-shadow(rm) when the caller explicitly writes command rm or
builtin rm; a bare rm -f/rm -rf call gets no shadow tag at all.