"Changing target_date appends a revision to the same crumb. It never tombstones and recreates."
Moving a Crumb Without Losing It
The one date you're allowed to change is target_date — you can re-file a crumb from one day to another, or move it to a different journal, or fix its text. The question is how. The lazy answer is to overwrite the field in place, or worse, delete the crumb and create a fresh one on the new date. Vesta does neither. Re-filing is an append-only revision: a CrumbRevision record is appended that preserves the prior value and the revision timestamp, while the crumb's ULID, captured_at, time zone, and media references stay exactly as they were. The crumb is the same crumb; only its assignment moved, and the move is now part of its history.
Why Delete-and-Recreate Is Poison
Tombstoning a crumb and making a new one looks equivalent — same text, new date — but it quietly destroys three things. First, identity: the new crumb has a new ULID, so anything that pointed at the old one is now dangling. Second, provenance: a draft that cited the original crumb's ID in its source_crumb_ids suddenly references a crumb that no longer exists, and the paragraph's lineage breaks. Third, history: the record that this fragment was originally filed to a different day, then moved, is gone — you can no longer see that you changed your mind. Append-only revision preserves all three; delete-and-recreate throws all three away to save one row.
Identity Is the ULID, Not the Date
The deep reason this works is that a crumb's identity is its ULID, fixed at birth, not any of its mutable fields. Its date can change, its journal can change, its text can be corrected — and through all of it, it remains the same crumb because its ULID never moves. That's what lets a draft cite a crumb once and trust the citation forever, even after the crumb has been re-filed twice. Presentation (which day, which journal, what text) is fluid; identity is bedrock.