Changes touching this path

• loot apply-patch lands as the inbound half of patch interchange, and the limit 1512 deliberately left open is CLOSED BY REFUSING: CRLF is refused on both sides, because the two halves are not the same kind of problem. A patch declaring lossy: crlf-normalized cannot reconstruct the bytes the change it names recorded - that is fidelity, read off the exporters own measurement rather than re-derived, since by the time the content is in the file it is LF. The half that actually bites is the LOCAL one: a hunks line space is LF, so writing an applied result back over a CRLF working file rewrites EVERY line ending in it, a whole-file change no hunk describes, that no report would show as more than the lines the patch touched, and that the next capture would sign. Reconstruction was rejected as a guess - the line space carries no endings at all, so an inserted line in a mixed file has nothing to decide from - and documentation as too weak for a silent whole-file rewrite. The cost is named rather than hidden: a CRLF repo cannot use patch interchange in either direction, and the remedy is a bundle, which carries content verbatim because it carries objects. Refusing is also what makes the round-trip pin true rather than approximately true. This is a separate verb from loot apply and not a mode of it, since a bundle carries objects, keys and signed change nodes while a patch carries none of those; dispatch is an exact-name lookup so nothing can collide there, and the place that DOES match loosely is verb_usage, which compares the token after loot rather than a prefix - pinned, because a prefix match would have dragged the whole apply-patch usage line into loot apply --help. Hunks apply strictly at the lines they declare, and what does not falls back to the ADR 0044 three-way against the change the patch names in its own parent row, which is the git am -3 shape and the reason that row is full width; loot-core gains one narrow door, converge::compose, because the theirs side of a patch is text at NO address while three_way_merge exists to pick between two addresses. A contended path is recorded and the run stops with the tree untouched, which makes this the sixth member of the 1506 resume family, and the census is what said so. Three of the ticket premises moved under it. The AC3 re-seal under the local .lootattributes is a SENTENCE and not a step, exactly as 1499 found for restore: the verb writes plaintext and then captures, so the tier is todays local policy by construction, and the export side already carries no tier for it to have inherited - the work was pinning it and saying it in the report. The AC4 no-partial-application rule forced the capture-first snapshot to run AFTER the plan rather than before, found by a fixture rather than reasoned out: a repo holding a path it cannot open has that paths plaintext on disk, capture_uncaptured_edits refuses to re-seal content it cannot read, and with the capture first the verbs own refusal was never reached at all. And a hunk body must be consumed by the counts in its @@ header and never by scanning for the closing separator, because a deleted line whose content is exactly a dash renders as two dashes, byte-identical to it. ADR 0082 freezes the header grammar now that a reader exists, which is why the 1786 fidelity rows went in before this ticket rather than after; the machine shape 1512 expected this ticket to name is deferred, with the reason written into ADR 0066 and PROSE_ONLY_CEILING, because it is one shape shared by both verbs and freezing the import side alone is the same half-contract 1512 declined on its own side (#1513) d5fba81e · dbf3dbe6…
• the cardinal beside a growing list is deleted rather than corrected, and a census now refuses its return: every prose count of the stopping verbs is gone from resume.rs, pick.rs, lib.rs, main.rs and ADR 0080, and no_prose_beside_stopping_states_a_count fails any comment paragraph whose subject is that family and that puts a quantifier within three words of a noun the family comes one of per member. scope is a paragraph rather than a file because a cardinal is ordinary english and this crate is full of correct ones; run over the whole crates tree it selected the wrong sentences and nothing else, in both directions, and both controls sit in the body. the ADR half is amended by hand and left unguarded, said so rather than implied, because the same gate cannot be made quiet over a document whose every paragraph is about that family and which states correct cardinals about other closed sets. the class was also wider than the eleven sites the ticket listed: hand written verb enumerations in change.rs, in resume.rs and in ADR 0080 had gone false on the same day and are now derived or generalised. the detached doc block is reattached to resolve_sub with subcommand_word given its own, and the sweep the ticket asked for found a SECOND instance it did not name, since 1799 inserted STOPPING between the no positionals census and its 45 line doc, leaving that test undocumented ever since; both are repaired and no guard is offered, because a correct sentence attached to the wrong item is lexically identical to a wrapped paragraph. ADR 0082 is brought to house style and pinned, and what is pinned is less than the ticket claimed: 81 of 82 do not open with a numbered heading, only 25 do, so the census holds the three lines all 82 agree on, an h1 title, a blank line and the Status section. buoy --nearest name is kept and recorded in CONTEXT.md as the deliberate git describe match pattern it is, named there as having shipped undisclosed in 1509 so the record carries the finding rather than the flag alone. and apply-patch stops refusing a patch that only DELETES a CRLF file: a deletion writes no result and so rewrites no line ending, which is the entire cost ADR 0082 states, so the check moved below the deletion arm, the ADR sentence was narrowed to match, and the pin carries a modify patch refused over the very same bytes in the same fixture as its control (#1807) eff3dc92 · dbf3dbe6…diff
• apply-patch keeps refusing a stanza that deletes a file whose bytes here are not text, and the asymmetry with the crlf deletion rule is now a recorded decision rather than a comment: format-patch never writes a deletion of a file that was binary on the authors side, since the seam classifies that row as binary and the exporter omits it, so such a stanza is either one loot wrote for other bytes or a hunkless one from elsewhere, and git apply refuses the git spelling of the latter without full index hashes, which apply-patch does not read. ADR 0082 and the comments at the deletion arm and in the module header say so, and a new test pins both halves in one fixture: the export of a change deleting a binary and a text file carries a stanza for the text file alone, the git binary deletion stanza spliced into that patch is refused and nothing is written, and the exported patch then applies over the same bytes. moving the binary refusal below the deletion arm turned it red (11 passed, 1 failed), and letting the seam treat a binary deletion as text turned it red at the exporter half (0 passed, 1 failed). no behaviour changed, and the workspace suite is green (#1809) 1bb3f26f · dbf3dbe6…diff
• loot resolve no longer refuses a delete/modify conflict that ours deleted: the #1988 guard reads a conflict record whose ours is its base as a deletion, so a disk with no file there matches it and a file written back there is still refused over, and on a shared primary its refusal names loot describe --allow-primary, the capture that works there. spawned-binary tests on a ferry-bounced two-head home position went red before the change for the ours-deleted resolve and the restored file (1 passed, 3 failed with the primary hint test), and with the deleted-ours arm removed (3 passed, 1 failed), with ours read as bytes whatever the record says (2 passed, 2 failed) and with a position-blind hint (3 passed, 1 failed). the implement brief now takes the job cap as a placeholder, keeps deploys inside the warrant and names SKILL.md, cites only what AGENTS.md says, says which commands need the lane position and gives the CR count and describe in PowerShell too; AGENTS.md gains the cargo fmt ban, ADR 0062 names the per-ticket safeguard that replaced the implement review, and the redeploy commands in workflow.md and diagnose-push-rejected name the new tag, scope the relay override to a forward bump and say the forge takes none, as the scripts repo reads them. ADR 0082 and apply-patch say the text deletion arm checks no preimage either (#1992) and pin that --check refuses a binary deletion the same way, the line-ending docs say CRLF and NUL, nul_offenders is private, and the sweep 10 wrap leftovers are fixed. the workspace suite is green (#1993) 7ecaa467 · dbf3dbe6…diff
• loot apply-patch no longer deletes a file its deletion stanza does not describe: the deletion arm now checks its preimage, so the lines the stanza removes, with its no-newline marker, must equal the file on disk in the patch line space or the whole run is refused naming the path and why, a stanza with no hunks deletes only an empty file, and --check gives the same refusal. the binary test is now the exporters own delta::is_binary, so a NUL-bearing file is refused as binary too. spawned-binary tests went red before the change (1 passed, 4 failed), with the preimage check removed (2 passed, 3 failed), with the old utf8-only binary test (4 passed, 1 failed), with a hunkless deletion always applied (4 passed, 1 failed) and with the trailing newline ignored (4 passed, 1 failed), and the format-patch round trips of a text file, a file with no trailing newline and an empty file stay green. the comparison is in the line space, so the #1807 CRLF deletion still applies; its fixture now holds the lines its stanza deletes, which it did not, and comparing with the carriage returns kept turned that pin red (11 passed, 1 failed). ADR 0082 section 2, the #1809 and #1993 comments and CONTEXT.md state the preimage rule, and the workspace suite is green (#1992) 98894a0a · dbf3dbe6…diff
• loot apply-patch closes the preimage gaps #1992 and #1995 left: an add is refused over a path holding bytes other than the ones it adds, which it used to write in front of them, a modify stanza with no hunks is refused, which wrote an empty file at an absent path, a deletion of an absent path is refused rather than reported as done, and a patch that writes or deletes one path in more than one stanza or renames one old path twice is refused. the similarity index, dissimilarity index and index rows are read past, so a git format-patch -M rename applies as a rename where it used to write an empty file at the new path, and another unread row above hunks is refused by name. apply_strict now reads a deleted last line without the no-newline marker as a claim that the file ends with a newline, the deletion arm compares through apply_strict, and the writer no longer discards a removal error. ten new spawned-binary tests went red before the change (deletion 5 passed, 2 failed; preimage 0 passed, 4 failed; rename 8 passed, 4 failed), a new pin for a deleted file that grew a line holds the unified deletion check, and over the apply-patch and format-patch test files the pins went red with the add check removed (46 passed, 2 failed), the hunkless modify refusal removed (47 passed, 1 failed), the git rows unread (47 passed, 1 failed), the unread-row refusal removed (46 passed, 2 failed), an absent deletion planned as a delete (47 passed, 1 failed), the shared path check removed (47 passed, 1 failed), the shared rename source check removed (47 passed, 1 failed), the newline claim removed (46 passed, 2 failed) and leftover lines ignored by the deletion check (47 passed, 1 failed). the format-patch round trips stay green, ADR 0082 gains section 4, one table of what each stanza class checks, its rename paragraph no longer claims more than the hunks compare, CONTEXT.md states the rules, and the workspace suite is green (#1997) 15e2d13e · dbf3dbe6…diff
• loot apply-patch no longer records a conflict base equal to its ours: the header-disagreement stop took the parent content as the base, which is the ours object when the path is unchanged since the parent, and the loot resolve guard from #1993 reads a record whose ours is its base as a deletion, so a file on disk holding those bytes could be refused over. the stop now leaves such a base out. a new verb-tier test went red before the change (0 passed, 1 failed, the recorded base equal to ours) and with the filter disabled (12 passed, 1 failed), and the resolve guard doc and ADR 0080 now say the deletion reading is only as true as the records it is handed. the sweep 11 prose fixes ride along: hygiene.rs states that tests already check docs and skills files instead of naming them, workflow.md uses <jobs> for the build job cap and gives the relay and forge redeploy commands a Set-Location <scripts> prefix with the placeholder defined, afk-loop points at the brief for its placeholders instead of listing them, the rewrap leftovers in afk-loop and diagnose-push-rejected are fixed, and the README apply-patch line no longer says CRLF on either side is refused. runbook_portability and the workspace suite are green (#1999) f221956f · dbf3dbe6…diff
• every place that repeats a stop now says what --continue will and will not do, and an F row carries the role as it was signed. resume::continue_clause is the one wording, read through ways_out, once_resolved and stop_advice by the stops, by the in-progress note status and conflicts print (which said only --continue once loot conflicts is empty), by the wrong-verb refusal (which said --continue finishes it), by apply-patch (whose own copy never said its clean paths stay unwritten), and by the apply and merge stops, which now name both ways out without the disclaimer, the reason written at stop_advice. a census in resume.rs refuses a production line of loot-cli outside that module that spells --continue, USAGE lines carrying USAGE_NOTE excepted, and its first run caught the move --before USAGE line paraphrasing the note without its disclaimer, which every_stopping_verb_documents_one_resume_sentence misses because it reads one line per verb. the note fold carries each live record role as signed (loot_core::note::LiveNote), so notes show --json role is the signed bytes for a generation spelled +2 where it was re-encoded as 2; every other row byte is pinned unchanged through the spawned binary, ADR 0023 records the amendment, and Note::parse is not made stricter, since this repo lane held no records to measure and refusing would reclassify signed records held elsewhere. manifest prose names an attester through attestation_shape::attester_name, the naming its JSON used, so the own key stops printing as hex there; unprintable is one const in delta_shape; ADR 0066 says notes stands for notes show; the ChangeGraph insert doc states its rule instead of a caller list; Pathspec::matches names the crate-private policy items instead of linking them, which removes five cargo doc warnings. declined: compile_fail,E0624, measured inert on the pinned stable toolchain (a probe edited to E0599 stayed green) and honoured only under RUSTC_BOOTSTRAP=1, the reason written at the probe. red first: the new pins failed before the fix (resume 21 passed, 2 failed; attestation_machine_shape 3 passed, 1 failed; apply_patch 12 passed, 1 failed); with the fixes undone in two rounds, the in-progress note, apply-patch copy, apply advice, re-encoded role and hex naming redden the census (1267 passed, 1 failed), apply_patch (12 passed, 1 failed), attestation_machine_shape (2 passed, 2 failed) and resume (21 passed, 2 failed), and the fold re-encoding, the old wrong-verb sentence and the old merge sentence redden the codec pin (158 passed, 1 failed), the census (1267 passed, 1 failed), attestation_machine_shape (3 passed, 1 failed) and resume (22 passed, 1 failed). no migration, no wire or format byte moves, and no forge or relay byte moves, so this owes no deploy. the workspace suite ran 3917 tests over 122 binaries with 7 ignored, and all passed but concurrent_stage_of_same_address_does_not_tear, an os error 5 in untouched persist_codec code that passed on a loot-core rerun (637 passed) and three times alone (#2052) d5fad7c8 · dbf3dbe6…diff
• loot apply-patch names each applied path by the tier its seal records, and loot new --no-snapshot lists the paths the signed change first seals: the apply-patch report printed the .lootattributes resolution, a Visibility, which cannot spell published, so a path this repo publishes read internal while loot show said published, and it now reads each row through Workspace::tiers_as_sealed, the #2219 read generalized from first_seals_as_sealed to any paths of a recorded change, rendered through render::tier_label. the first-seal summary took its set of paths from the disk walk of seal_gate, so under --no-snapshot a .lootattributes the earlier capture first sealed and the disk had since lost was left off; finalize_capturing_over now returns the paths the signed change holds and the anchor the gates judged does not (Workspace::first_seals_of), paths alone, since the tier is the seal. both pinned red first (0 passed and 1 failed each): published, internal and restricted rows through the apply-patch verb, and a --no-snapshot summary listing the lost rules file and neither a path the disk gained since nor one the anchor holds. red with each piece undone, counts read each time, each restored green: the marker ignored, published claimed for every row, the rule resolution printed (0 and 1 each on the apply-patch pin), the set taken from the disk gate, the anchor filter dropped, the anchor read after the finalize (0 and 1 each on the summary pin). reproduced through the 0.4.24 binary before and a lane build after. CONTEXT.md and the Workspace width move with it. no format, wire or migration byte moves, so this owes no deploy. the workspace suite is green (4532 passed over 139 binaries, 13 ignored) (#2353) 22faa0d6 · 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.