Changes touching this path

• loot grep grows the options that make a search usable, and two of the ticket's acceptance criteria turned out to ask for something this verb already did unconditionally: -n wants line numbers, which loot grep has printed since #391 with no flag at all, so making them conditional would silently change the output of every invocation ever typed and -n ships instead as a pinned compatibility spelling of the default, exactly as -F now spells out the fixed-string matcher that stays the default with the regex behind -E. the same compatibility argument decides the row shape, so the change column is printed only when the selector was a REVSET, a thing this verb could not search before, while a point selector keeps the three-column row it always had. the pathspec is the declared option group and not a fourth hand-rolled one, which cost the leaf its NO_PATHS declaration first: a group's trailing list begins where the leaf's own arity ends, so grep declares two opaque positionals and attaches PATHSPEC, and because its selector is optional a bare trailing path still reads as the selector and the operator says which they meant with the separator. -E is a hand-written POSIX ERE over bytes rather than the regex crate, which is loot-cli's standing dependency-light no-clap stance applied rather than a new decision; that stance is argued in the ctrlc note in the workspace manifest, not by adr 0041, which governs loot-core and the server-side dependencies and does not reach this; and the cost is measured rather than guessed, by resolving regex alone and diffing its closure against this lock: three new entries, regex and regex-syntax and aho-corasick, since memchr and regex-automata are already in the graph through bstr from gix, though regex-automata is linked there with default features off and carries no dependencies at all in this lock, so regex would compile far more of it than anything does today, all to serve one optional flag on one read verb. AC7 is a real requirement and it is keyed on the content address rather than the path, since repo.put mints a fresh address per call and only a carried tree entry reuses one: measured, a two-change revset over three paths each opens four objects where the natural walk opens six and returns byte-identical rows, which is why the pin counts ObjectGets instead of reading the answer. AC6's aggregation needed a fixture the engine refuses to build the obvious way, because a path this identity cannot open cannot be re-captured while it sits on disk, and the count is per change and path, so one sealed path carried through two changes is two skips. the per-object read is loot-core's own readable_tree classification lifted out rather than copied, so grep and surface cannot come to disagree about what a burned path is (#1500) c1ad796e · dbf3dbe6…
• three copies of one false sentence collapse into one statement the other five are pinned to: the help for cherry-pick and revert said --continue re-runs the operation while squash, apply and merge said it closes the stop three lines away, so the shipped help disagreed with ADR 0080 section 4, with resume::cont, and with itself, on exactly the two verbs whose re-run was built first and measured wrong. USAGE is a literal and there is no const concatenation, so the fact now lives once as resume::USAGE_NOTE and a new census asserts all five USAGE lines carry those bytes verbatim, which means a reword turns five red together where three hand-typed copies turned none; the comments in pick.rs and in_progress.rs now point at that statement instead of paraphrasing it. ere.rs cited the help of loot grep for a claim the help never made, so the sentence exists now as ere::HELP_NOTE and is pinned the same way: a dot matches one BYTE, and [:alpha:], \d, \b and \s are not implemented. the help for restore asserted that nothing ever recorded those bytes of every run, while the module it documents splits IRRECOVERABLE from OVERWRITTEN precisely because that is false under --source. item 5 was wrong twice: a stop cannot be the FIRST operation of a repo, because loot init records a genesis floor op, and the refusal is not an off-by-one either, since op_index answers 0 for an empty log, no operation 0 exists to hold a captured view, and the pre-operation pointer bytes were never snapshotted, so no other number reaches them. what is true is that .loot/ops is lane-owned and nothing plants a floor in a spawned lane, making the unabortable case an ordinary one: the first view-changing command an agent runs inside a fresh lane. so the refusal stands, the message now says that and names --continue, and it is pinned through a really spawned lane whose empty op log is the control. the ATTACHED census control is now derived from the census rather than kept as a second hand-written list, and resolves each censused group name to its canonical const so an empty group of the same name cannot satisfy it vacuously, proven by a mutation that leaves the census green and turns the control red on grep, the one attached leaf that had no control at all (#1799) 51aea3d1 · dbf3dbe6…diff

Renames are not followed. loot's tree maps a path to an address, so a rename is a delete and an add. This list is the history of the name, not of the bytes.