[BBYU26]

Part of #884. C9a-3b-2, the second half of C9a-3b: a "this and following" change now survives PM closing halfway, and PM won't stack another change on a series that an earlier split still overlaps. 3.148.8-alpha. Stacked on #968 (this week's security advisories): the base is fix/sidecar-pillow-13, and there's no closing link while the base isn't main. Still inert for users: release builds refuse every repeating-event write until C9b-1b's dialog.

What it does

Remembers a split while it runs. Before its first write to Google, a "this and following" change is recorded in the encrypted settings store (calendar_split_journal: Google's ids, the plan digest, the original's repeat rule before and after the cut, and its start; never a title or description). The record goes once the change lands or is settled. If PM closes halfway, the next look at that event reads the record against what Google holds now:

• The change landed (the original holds the cut rule) and had occurrences to move: said once ("occurrences you changed on their own may not have moved… check them in Google Calendar"), then forgotten.
• The original was never cut and still repeats past the split: it shows twice. PM refuses every change that reaches it and points to Google Calendar. After a restart PM never deletes anything and offers no delete, not even of the duplicate (your Q4 answer, as narrowed by critique 1 H1).
• The rule was changed in Google since, or nothing overlaps any more: said once, then forgotten.
• PM can't read Google right now: refuses what it reaches, and keeps the record.

The overlap backstop. Every series read now also lists the parts PM split off it (privateExtendedProperty=pmSplitOf=…). If one still overlaps the original, or PM couldn't list them, "This and following" and "All events" refuse; "This event" stays open. It measures from the occurrence each part was split at, which a new part now carries in a private pmSplitAt note.

Reviews

Seven rounds, each finding checked by a skeptic, every fix pinned by a test checked by mutation. They found:

• a "shows twice" reading made from the repeat rule alone (the original's occurrences could have been deleted one by one in Google);
• the original's exceptions left unread on one side;
• two unrelated writes hiding a record;
• the order of the "this change is running" mark;
• three wrong readings of the overlap (an extra date earlier on the split day, a part moved later that day, a part moved to a later day), settled by measuring from the split occurrence itself.

One low limit kept (in the design doc): if the split occurrence had itself already been moved on its own, and nothing of the original follows it in the window, a crash mid-split reads "changed" rather than "shows twice". Counting it would refuse forever after a clean split that left it behind, which is worse. PM deletes nothing either way.

Checks

The full just check passes at the tip: 2,094 Rust tests and 2,005 frontend tests, plus clippy, fences and audits.

Live test (optional, once merged, dev build)

Probe R2 in the "C9a probes" section of docs/calendar-live-tests-2026-10-10.md, run after W4. It confirms Google accepts the parts filter. If Following/All refuse with "PM couldn't check for a part it split off", Google rejected it: tell me.

Moved 21-10-2026: the dependency advisories now live in #968

The certificate fix that sat here (4dda153, 20-10) moved into #968, together with this week's Pillow advisories, and this PR now stacks on it. It is renumbered 3.148.8-alpha, and its own changes are unchanged (range-diff: every commit identical apart from its version lines). The full just check passes on the rebased branch (c676088), including deny and pip-audit.

🤖 Generated with Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.