[LeMyst]

Closes #622.

A Rename button in the editor, next to Picture and Delete, and POST /api/recipe_rename/{*path} ({ "name": "New name" }) behind it. The file stays in its folder; its title and step pictures are renamed with it, and the references to it in the collection's .cook and .menu files are rewritten to the new name.

Rename dialog	A refused name

What it touches, and what it never does

A rename changes several files at once, so it is held to more than the other write endpoints:

Risk	How it is ruled out
Overwriting a file	Every move is hard link + unlink (link never replaces its target), or, where hard links are unavailable (FAT/exFAT, Android), a copy into a create_new file — the refusal is the file system's own, so there is no race between the check and the move. rename() is never called (#349). A failed move rolls back the ones before it. A case-only rename on a case-insensitive FS goes through a hidden temporary name.
Reaching another file	The source goes through recipe_file like save/delete (#545): an existing .cook/.menu, nothing hidden, nothing outside. A source that is a link, or whose folder leads outside the collection, is refused. The new name is one plain file name: no / \ : * ? " < > |, no control or invisible characters, no leading dot, no trailing dot, no Windows device name (CON, COM1, COM¹…), and none of @ # ~ { } [ ], -- or double spaces, which a reference could not hold.
Pictures	Stem.jpg, Stem.N.jpg, Stem.S.N.jpg in the four extensions cooklang-find reads. One another recipe or menu can claim stays (Pasta.2.jpg is also Pasta.2.cook's title; Plan.jpg is shared by Plan.cook and Plan.menu). One that would land on a taken name, or on another recipe's picture name, stops the rename (409).
Changing what a reference means	Renaming Foo.cook to Week beside Week.menu is refused: @./Week{} would reach the recipe before the menu. When the new name needs it (a . in it, or a menu beside a recipe of its new name), rewritten references spell the extension out.
Rewriting the wrong text	References are found with the parser's own spans (PullParser, no extensions, as cook parses) and resolved with resolve_reference from the writer's folder, so ./ vs ../ is read the way the rest of cook reads it. Only the last segment is replaced, and only when it is written exactly as the old name; every other byte stays. A reference with an escape, comment or double space in its name, another letter case, or a ./Pasta/. spelling is reported in references_skipped, not guessed.
Missing a reference	The collection is walked directly (build_tree keys a folder's entries by title, so two recipes with one title, or a recipe beside a folder of its name, hide each other). A collection that cannot be read in full is not renamed (500, nothing moved).
Writing where it must not	A referencing file is rewritten only if it still holds what was read, atomically (hidden create_new temp + replace), never through a link or outside the collection — those are reported. .shopping-list is never written; shopping_list_stale says when it still names the old path.
Half-done renames, lost saves	The work runs in a spawned task, so a client that goes away cannot stop it between two moves. Save, delete and picture writes share its lock. The editor saves pending text first and holds autosave back — otherwise a late autosave PUTs the old path and recreates the old file.

Access: listed in the WRITES table at EditRecipes, like save and delete; write_guard covers it (POST, JSON body).

Tests

• tests/recipe_rename_api_test.rs (9): every refusal compares the whole collection byte for byte before and after; pictures, menus, sub-folder ../ references, title clashes, an unreadable folder, symlinks (unix).
• Unit tests for the name validator, the reference rewriter (byte-exact output, CRLF, front matter, comments, escapes), picture ownership, move_no_replace / move_file / write_replace, the capability table.
• server_auth_test.rs: guest 401, reader/shopper 403, editor/admin allowed.
• tests/e2e/editor-rename.spec.ts: the dialog, the autosave race, refused names.

cargo fmt, cargo clippy --all-targets and cargo test --workspace pass. Playwright chromium: all editor specs pass; on the full run the only failures were static-file-search (needs ./target/debug/cook in the checkout, absent in my setup) and shopping-list specs that race on the shared .shopping-list across workers — they pass with --workers=1 and are untouched here.

Left out

• Moving a file to another folder (same-folder only, on purpose).
• Other open editor tabs still hold the old path; their next autosave would recreate it, since PUT creates a missing file. Same as with delete today.
• References in the saved shopping list are reported, not rewritten.

🤖 Generated with Claude Code