Splitting: individual-message selection (#926) Analyst page: the "what moves" flow is now a checklist of every message with This-and-newer / All / Clear helpers, not "this one + newer". Drops the "cannot tick arbitrary messages" limitation. Developer guide: splitMessagesByIds + the email_ids path, the marker-aware emptiness guard (splitMarkerEmailIds / splitMovableCount), list_all preview mode, .split-pick-* CSS, the cache-buster gotcha, and arbitrary-selection marked done with notes-splitting as the next step.
Splitting tickets pair + undo on both merge and split (#914–#916) New: Splitting-Tickets + Splitting-Tickets-Developer-Guide, same format as the other pairs — colour-keyed file table, the reasoning, and the traps. The dev guide leads on why split is NOT the mirror of merge: a merge protects a reference the customer already holds (pointer + inbound redirect), a split mints one nobody has ever seen (no pointer, no redirect, both tickets live, linked `related` not `duplicate_of`). That table is the thing worth reading. Also written up where they will be read: - the empty-ticket guard, and why the preview and the split share one function - the thread renders NEWEST-FIRST, so every string says "newer" not "after" - the control was hover-only and nobody could find it; a control nobody can find is a missing feature, not a subtle one - splitPlural() exists because "1 message(s)" reads as a bug Merge pages updated for undo, including the contrast that matters: undo-split REFUSES on any activity (the new ticket was brand new), unmerge deliberately does NOT (the survivor is the live ticket and collects replies within the hour). Plus what unmerge records and why the source's previous status must be stored rather than inferred. Every file, function and column named in the tables verified to exist; every internal link resolves. Linked from the sidebar under Tickets and from Tickets.md.