Filip 1718b0a8b8 feat(task-repeat): RFC 5545 RRULE recurring schedules — EPIC · Phase 1/13 (Closes #4020) (#7948) ... * feat(task-repeat): add cron / natural-language recurring schedules Add a CRON repeat cycle so a single recurring task can express schedules the day/week/month/year cycles cannot (e.g. every Saturday, March through November). The cron expression drives occurrence generation; all other schedule fields are ignored for CRON cfgs. - Occurrence engine: getNewestPossibleCronDueDate / getNextCronOccurrence in cron-occurrence.util.ts (cron-parser), wired into the existing getNewestPossibleDueDate / getNextRepeatOccurrence dispatchers. Recurrence stays day-granular: sub-daily crons create at most one task per day. - English to cron via the crono-eng WASM module (src/assets/crono-eng.wasm, loaded lazily), with a builtin regex parser as fallback until/if the module is unavailable. naturalLanguageToCron() also passes raw cron through. - Cron to english live preview under the input via cronstrue; the field shows the interpreted cron + humanized reading as the user types and warns when an expression is sub-daily. - Invalid / unrecognized input shows an error snack and blocks save. - Add-task bar: @+<cron-or-phrase> short syntax attaches a CRON repeat cfg. - tools/build-crono-wasm.js regenerates the WASM asset from the sibling crono-eng Zig project (committed asset is the source of truth for builds). * fix(task-repeat): cron edge cases, clearer warnings, and corpus tests Hardening + UX pass on the cron repeat cycle, driven by verifying the full crono-eng corpus (415 phrases) end to end. Fixes - Silent never-fires: crono-eng can translate phrases (a specific year, "nearest weekday"/W, "n-to-last day"/L-n, biweekly #-lists) into Quartz forms the recurrence engine (cron-parser) cannot run. These passed UI validation yet a task would never be created. naturalLanguageToCron now gates its output on cron-parser, so such input is rejected at the field instead. - Off-by-one for midnight crons: cron-parser's next() is exclusive of an exact-boundary currentDate, so getNextCronOccurrence skipped the first eligible day for 00:00 schedules (e.g. first occurrence landed a day late). Seed the search one ms before the lower-bound day so a midnight fire stays eligible; now matches the non-cron daily convention. UX - Live preview shows the interpreted cron + plain-English reading below the field, and warns when the time of day is ignored (day-granular engine) or the schedule is sub-daily ("runs at most once per day"). - Friendlier validation/snack message with examples instead of terse jargon. Tests - tools/test-crono-wasm.js (npm run test:crono): corpus-driven harness asserting the committed WASM matches all 415 corpus crons, and that cron-parser + cronstrue accept them — classifying the 27 known engine-unsupported forms so it stays a regression guard. - cron-occurrence.util.spec.ts: occurrence engine across daily/weekly/monthly/ month-range/sub-daily, varied times, start-date and last-creation gating. - parse-natural-cron.util.spec.ts: raw passthrough, phrase recognition, null cases, loader resilience. - task-repeat-cfg-form.cron.spec.ts: field validator + live-preview/time-warning. * fix(task-repeat): live cron preview + @+ title strip; add E2E Fixes found by adding end-to-end coverage of the cron feature. - Live preview did not render: Formly's mat-hint does not reflect a dynamic expressionProperties.description, so the interpreted-cron/English preview never updated as the user typed. Move it into the dialog template, driven by a computed signal off the form's valueChanges (getCronPreview in cron-preview.util), so it updates live and persists after applying. The time-of-day-ignored and sub-daily warnings now render as proper translated lines. - "@+<phrase>" short syntax left the clause in the title: shortSyntax set taskChanges.title for the cron strip, but the later parseTimeSpentChanges reassignment wiped it, so a bare "Foo @+every day" submitted the raw title. Strip into the working title and emit the cleaned title at the end. - shortSyntax returned cronExpression unconditionally (undefined when absent), breaking 38 exact-match assertions; only include the key when set. Tests - e2e/tests/recurring/cron-repeat.spec.ts: @+ short-syntax attaches a CRON cfg (title stripped); full dialog flow (phrase → live preview + time warning → save → CRON cfg persisted). - short-syntax.spec: @+ extraction/stripping, with and without other syntax. - getCronPreview unit tests (interpreted cron, English, timed/sub-daily flags). * test(task-repeat): property/fuzz/metamorphic/edge cron tests; fix first-occurrence Large second testing pass (≈+58 unit tests, +2 E2E, new property harness), which surfaced one gap and one upstream quirk. Fix - getFirstRepeatOccurrence returned null for CRON cfgs (no case → default), so a timed CRON task's first instance and the startDate-moved-earlier path fell back to today instead of the cron's first fire. Add getFirstCronOccurrence (first fire on/after startDate) and route CRON through it. Tests - cron-occurrence.invariants.spec: property/invariant battery over many crons (no-throw, result strictly-after / on-or-before bounds, determinism, monotonicity), calendar edges (leap-day, year rollover, DST spring/fall), pathological "Feb 30" (null, no hang), and getFirstCronOccurrence / getFirstRepeatOccurrence routing. - parse-natural-cron.metamorphic.spec: relational tests (case/whitespace/order/ irrelevant-text invariance, idempotence, determinism, raw passthrough). - short-syntax.spec: more @+ cases (raw cron after @+, bare @ is not cron, unrecognized phrase ignored, clause stops at the next delimiter). - tools/test-crono-properties.js (npm run test:crono:props): WASM determinism, marshalling fuzz (empty/oversized/unicode/boundary), English→cron→English round-trip, and occurrence simulation across every runnable corpus cron. - e2e: invalid phrase blocks save + shows inline error (Save disabled); raw cron expression preview + save. Shared dialog-open helper. Note: documented a cron-parser DST quirk — prev() skips the spring-forward midnight, so "newest due" can land a day earlier on that date (day-granular, once a year; lastTaskCreationDay prevents duplicates). * test(task-repeat): selector integration, serialization, and WASM buffer-reuse - selectors.spec: CRON cases for the selectors that drive task creation — selectAllUnprocessedTaskRepeatCfgs (due today, overdue, already-created, paused, future start, invalid expr, deleted instance) and selectTaskRepeatCfgsForExactDay (exact-day match). Proves a CRON cfg is picked up by addAllDueToday's selector path. - cron-occurrence.invariants.spec: a CRON cfg survives a JSON round-trip with identical occurrence behavior (sync / backup integrity). - test-crono-properties.js: buffer-reuse checks — a short translation after a long one is uncontaminated, and results stay deterministic across a 600-call interleaved loop (the WASM module reuses static input/output buffers). * test(task-repeat): cross-timezone day-resolution harness The Karma suite only runs in the host timezone (Chrome on Windows ignores the TZ env var — the reason the pre-existing *.tz.spec fails), so cron day-resolution was never verified across zones. Add a Node harness (npm run test:crono:tz) that spawns a child process per timezone — Node honors TZ — and asserts day-class invariants in each: weekly-Monday resolves to a Monday, monthly day-15 to the 15th, daily to the next calendar day, time-of-day never shifts the day, and a full-year daily iteration is monotonic with 366 distinct days (no DST skip in next()). Covers fractional offsets (India +05:30, Chatham +12:45/+13:45) and Southern-hemisphere DST (Sydney). Mirrors getNextCronOccurrence's core math. * fix(task-repeat): DST-safe newest-due; verify real engine across timezones Closes the time-based reliability gaps from the previous testing pass. Fix - getNewestPossibleCronDueDate no longer uses cron-parser's prev(), which skips the spring-forward midnight in DST zones (a daily cron then looked like it didn't fire that day). It now walks days backward and asks "does the cron fire during this local day?" via a next()-based probe (next() is monotonic across DST). Spring-forward and fall-back now resolve the exact day. Tests - main.ts exposes the real occurrence utils on __e2eTestHelpers.cron (dev/stage only, stripped from production). - e2e/cron-timezone.spec: runs the REAL engine under five forced browser timezones (Playwright timezoneId — reliable regardless of host OS, unlike the Karma TZ env). Each asserts the timezone was actually applied (live UTC offset) AND that day-class results are correct, incl. fractional offsets (Chatham +12:45) and the spring-forward day. - test-crono-tz.js: also asserts a daily cron fires on every calendar day of the year in all 8 zones (regression guard for the prev() skip). - invariants.spec: spring-forward / fall-back now assert the exact day for both next() and newest (no longer hedged). - effects.spec: a CRON cfg's first occurrence is computed through the real updateTaskAfterMakingItRepeatable$ effect path (live new Date()). * test(task-repeat): dev jumpDay clock helper + live day-change e2e Adds __e2eTestHelpers.jumpDay(n) / resetClock() (dev/stage only, stripped from production) so recurring/day-change behavior can be fast-forwarded from the DevTools console without touching the OS clock: jumpDay shifts Date.now() by a cumulative day offset and forces the day-change re-sample so addAllDueToday() runs. New e2e asserts jumpDay(1) creates the next daily instance — covering the live day-change -> creation path end to end. * feat(task-repeat): add "create a task for each missed occurrence" option By default, opening the app after several scheduled occurrences were missed creates only a single instance for the most recent occurrence. When enabled (advanced section), a separate overdue task is created for every missed occurrence instead, oldest first, capped at the 30 most recent to avoid flooding the list / emitting a large sync batch. - new getAllMissedDueDates() util reuses getNextRepeatOccurrence so the per-cycle and CRON occurrence logic stays single-sourced and DST-safe - service multi-spawn path is gated to the catch-up flow (target day is today or earlier) and is mutually exclusive with skipOverdue / waitForCompletion; the single newest-occurrence path is unchanged - form checkbox hides when "skip overdue" is set, and vice versa Part of #4020 * fix(task-repeat): re-anchor lastTaskCreationDay when cron expression changes cronExpression was missing from SCHEDULE_AFFECTING_FIELDS, so editing a CRON schedule did not re-run rescheduleTaskOnRepeatCfgUpdate$. A previously computed (often future) lastTaskCreationDay then stuck around and silently suppressed every occurrence until real time caught up to it — e.g. a "Jan-Aug" cron set while the clock was past August anchored to Jan 1 next year and produced no tasks in between. Adding 'cronExpression' makes a cron edit re-anchor from the current date, consistent with repeatCycle / repeatEvery / weekday edits. Part of #4020 * feat(tasks): surface @+ recurring short syntax in autocomplete and help The `@+<schedule>` add-task short syntax existed but was undiscoverable. - add recurring examples to the `@` autocomplete suggestions: typing `@+` now autocompletes phrases like `@+every monday` or `@+every saturday from march through november` - document `@+` in the Settings -> Short Syntax help text Part of #4020 * fix(tasks): remove @+ recurring autocomplete entries The `@+` examples added under the `@` mention trigger kept the suggestion dropdown open while typing `@+<phrase>`, so pressing Enter selected a suggestion instead of submitting the task — breaking the headline type-and-go flow. The `@+` syntax stays documented in Settings -> Short Syntax; only the dropdown entries are removed. Part of #4020 * refactor(task-repeat): show cron only inside Custom recurring config Cron appeared twice in the recurring-config dropdown: as a top-level "Cron / natural language" quick-setting AND as a cycle inside "Custom recurring config". Drop the duplicate top-level option; cron is now reached via Custom -> repeatCycle = Cron. - remove the CRON quick-setting option from the dropdown builder - keep the repeatCycle select visible when CRON is chosen (only hide repeatEvery) so the user can switch back - map existing cron configs (incl. legacy quickSetting 'CRON') to CUSTOM on load so the dropdown matches the stored cycle - update the cron E2E to drive the dialog via Custom -> Cron Part of #4020 * test(task-repeat): make @+ short-syntax e2e date-independent The test asserted the `@+every monday` task appears in the Today view, but a weekly schedule's first instance is the next Monday — so on any non-Monday the task is correctly scheduled for a future day and isn't in Today, making the test fail depending on the day it runs. Verify the attached CRON config and the stripped title via the store instead, which is view- and date-independent. Part of #4020 * feat(task-repeat): RFC 5545 RRULE recurring schedules [WIP] Overhaul recurring tasks from the bespoke repeatCycle format to RFC 5545 RRULE as the canonical recurrence representation (legacy fields kept populated for old-client forward-compat). Adds a structured RRULE builder, RRULE-backed quick presets, per-instance due-date derivation, multiple end conditions (COUNT / UNTIL / after-N-completions), an occurrence heatmap with completion simulation, natural-language @+ short syntax, and a REST API for recurring tasks. Migration is lazy (on dialog open) so existing configs keep firing untouched until edited. WIP: some required features and tests are still outstanding, and it needs much more real-world (user-based) testing before it is merge-ready. * feat(task-repeat): per-occurrence overrides, due-date control move, @+ preview, NL fix [WIP] - RECURRENCE-ID: per-instance overrides (move / re-time / re-title) surfaced to the engine as RDATE + EXDATE so every projection stays consistent. - Move the due-date derivation control out of the rrule builder into the dialog so it applies to all recurring configs (presets + Custom). - Live @+ recurrence preview (humanized rule + next occurrence date) in the add-task-bar, so a far-off rule is obvious before submit. - Fix @+ "every other <weekday> in <month>" mis-parsing to YEARLY;INTERVAL=2 ("every 2 years"); weekly-style interval + weekdays now stays WEEKLY. * refactor(task-repeat): trim PR to engine+builder+migration+preview; fix curator review Trim the WIP recurring-schedules PR to its reviewable core — RFC 5545 occurrence engine, structured RRULE builder, legacy<->RRULE migration (both directions), live text preview, quick-setting presets, and tests — and defer the rest to follow-up sub-MRs: natural-language @+, due-date derivation, ends-after-N- completions, missed-occurrence backfill, heatmap preview + simulation, REST recurring creation, and RECURRENCE-ID per-instance overrides. The full implementation is preserved on branch feat/recurring-full. Curator review fixes: - quickSetting forward-compat: never persist a value outside the released (master) union. The newer preset literals AND 'RRULE' map to 'CUSTOM' at every persist boundary (dialog save, add-task-bar, data-repair downgrade); the rich value drives the dialog UI in-memory only and the builder reconstructs from the opaque rrule on open. Fixes old/mobile typia sync-validation treating such tasks as corrupt. - Malformed rrule now falls back to the legacy schedule fields (guarded by isRRuleValid) instead of silently stopping the task. - Reverse converter maps a BYDAY-less FREQ=WEEKLY onto the start weekday, so the legacy WEEKLY engine still fires on old clients. - Stop logging the raw rule body (the raw-override field makes it free-text user input; log history is exportable). - DRY: share normalizeWeekdays / toNumArray between the two converters. * refactor(task-repeat): clamp quickSetting at the action creators The op-log replays the action payload, not reduced state (operation-capture.service.ts), so a reducer-level clamp would not keep an out-of-union quickSetting off the wire. Clamp in the addTaskRepeatCfgToTask / updateTaskRepeatCfg / updateTaskRepeatCfgs creators instead -- the single boundary every dispatcher passes through, so old/mobile clients always replay a value their typia union accepts. The newer preset literals and 'RRULE' stay in-memory in the dialog form only. Removes the now-redundant per-call-site clamps in the dialog save path and the add-task-bar; the @+ and REST paths inherit the clamp for free when their phases return. Adds an action-creator spec covering the clamp at each entry point. * feat(task-repeat): nth-weekday rows support multiple weekdays per ordinal Each ordinal row (1st/2nd/3rd/4th/last) now multi-selects weekdays via toggle buttons, so one line can mean "the 1st Monday and the 1st Tuesday" -> BYDAY=1MO,1TU. The per-row ordinal dropdown excludes positions already used by other rows (each ordinal anchors at most one line), and the add button hides once all are used. Parsing groups weekdays that share an ordinal back into one row. Applies to both the monthly and yearly nth-weekday modes; updates the helper copy accordingly. * test(task-repeat): complex RRULE coverage + day-by-day create-loop sim Adds high-complexity coverage for the occurrence engine and builder: - engine variants x settings: per-day ordinals, BYSETPOS last-weekday, BYMONTHDAY=-1, seasonal BYMONTH, BYWEEKNO/BYYEARDAY, leap years, mixed with COUNT / UNTIL / EXDATE / lastTaskCreationDay - builder forward + mode-detection + lossless round-trips (incl. multi-weekday ordinals and sub-daily raw-override) - cfg->engine routing for complex rules with deletedInstanceDates and the malformed-rrule legacy fallback - a "day-march" simulator that drives getNewestPossibleDueDate one day at a time with lastTaskCreationDay fed back like the service, asserting the created stream has no dupes/skips, honors EXDATE/COUNT, is idempotent within a day, and documents Phase-1 app-closed catch-up (newest missed only) Also trims the deferred @+ short-syntax e2e (returns with its phase) and fixes the dialog-flow e2e to target the current .rrule-result preview selector. * feat(task-repeat): custom ordinal input for nth-weekday rows and BYSETPOS The nth-weekday ordinal dropdown and the weekday-set 'which occurrence' dropdown each gain a 'custom…' option that reveals a free-form input, allowing any non-zero ordinal (e.g. -2 = 2nd-to-last, 5FR) and comma-separated BYSETPOS lists (e.g. 2,-1). Parsed rules with such values now render structurally instead of falling back to the raw override. * feat(task-repeat): make weekday-set occurrence (BYSETPOS) a multi-select Replace the single-value 'which occurrence' dropdown with toggle buttons matching the weekday toggles, so several occurrences can combine (e.g. first + last weekday = BYSETPOS=1,-1). 'Every' clears the narrowing; the custom input stays for values without a toggle. * fix(task-repeat): address review findings on rrule migration fidelity - Yearly builder rules seed BYMONTH from the start month: a bare FREQ=YEARLY;BYMONTHDAY=n expands across every month (RFC 5545) and fired monthly for fresh yearly configs. - quickSetting change handler passes the selected start date, so date-writing presets no longer overwrite a user-picked future anchor with today. - Remove the createForEachMissed checkbox + copy: the engine has no backfill support yet, so the setting silently did nothing (and wrote an undeclared field into synced state). - rruleToLegacyTaskRepeatCfg always resets the monthly anchor fields so stale nth-weekday/last-day anchors can't survive the merge, sets monthlyLastDay only for a pure BYMONTHDAY=-1 rule, and aligns startDate to the rule's first occurrence for date-anchored monthly/yearly rules (legacy clients read day/month from startDate); save() re-derives the fallback so later startDate edits stay aligned. - _normalizeMonthlyAnchor keeps monthlyLastDay on RRULE saves — it is the derived old-client fallback for BYMONTHDAY=-1, not a stale preset flag. - Legacy CUSTOM migration preserves clamp semantics: day > 28 anchors emit BYMONTHDAY=<d>,-1;BYSETPOS=1 (the day, or the last day of shorter months) instead of a plain BYMONTHDAY that skips such months; the builder serializer emits BYSETPOS in day-of-month modes so these rules round-trip structurally. - Regenerate package-lock.json to drop stale cron-parser/cronstrue entries left over from the earlier cron approach. * fix(task-repeat): harden rrule builder + legacy fallback after deep review Correctness: - Clear bySetPos (and its custom-input state) on monthly/yearly mode and frequency switches: a BYSETPOS left over from the weekday-set mode silently narrowed day-of-month rules (BYMONTHDAY=15;BYSETPOS=2 never fires) with no UI to see or clear it. - Move startDate alignment out of rruleToLegacyTaskRepeatCfg into a new arithmetic getAlignedStartDate, applied once at save and only when the schedule actually changed: the occurrence-search version corrupted the clamp idiom (aligned a day-31 rule onto Feb 28/29 so old clients fired on the wrong day forever), collapsed multi-day BYMONTHDAY lists to their earliest day, rewrote the visible start-date field live on every builder interaction, cost ~60ms/keystroke for sparse rules, and put startDate into the change diff on title-only edits — retriggering the issue-#7373 reschedule. Weekday-anchored rules are no longer aligned. - Emit the monthly-anchor resets as null/false instead of undefined (in the converter AND the presets' MONTHLY_ANCHOR_RESET): JSON.stringify drops undefined keys from op-log payloads, so the reset never reached remote clients and stale nth-weekday/last-day anchors survived there. The anchor model fields now allow null; the nth-weekday engine guard strips it. - Enforce the YEARLY BYMONTH guard in the serializer: yearly date mode without months now emits a plain FREQ=YEARLY (anniversary) instead of a bare BYMONTHDAY that fires monthly; parsed bare yearly rules fall back to the raw override, preserving their semantics verbatim. - Drop the auto-seeded BYMONTH when switching away from YEARLY (it silently constrained the new rule to one month) and seed from the CURRENT start date rather than the ngOnInit-captured month. - Clamp custom nth ordinals per frequency (±5 monthly, ±53 yearly) — BYDAY=10MO is valid RFC but matches nothing, ever — and reject an ordinal another row already anchors (duplicate rows collapse on reload). Re-clamp poses when switching into MONTHLY. - Drop BYSETPOS=0 on parse (parseString accepts it; re-emitting creates a rule the occurrence engine silently treats as dead). - Predefined set-position toggles close the explicitly-opened custom input (both rendered active with contradictory state). Cleanup: - Extract parseIntList (4 cloned int-list sanitizers), pushBySetPos / pushByDaySet (4 copy-pasted emit blocks), _clampedMonthDayPart (monthly/yearly clamp duplication); share the monthly/yearly weekday-set template block via ngTemplateOutlet; parse BYSETPOS via a computed signal instead of per-CD string parsing. - Correct the BYMONTHDAY hint: it claimed short months clamp to their last day, but plain BYMONTHDAY skips them. * test: make timezone demo specs host-independent Six .tz.spec demonstration tests branched on the host's CURRENT getTimezoneOffset() (or a literal 'America/Los_Angeles' name check) while asserting against January test instants. In DST-observing zones the summer offset differs from the January one (e.g. New York: EDT 240 vs EST 300), so the wrong branch was taken and the suite failed every summer on US-east machines, blocking pre-push hooks. Branch on the offset AT the test instant instead, with the correct longitude threshold for each instant (07:00 UTC flips the local day at UTC-7, 06:00 UTC at UTC-6, midnight UTC at UTC±0) — the tests now pass in any host timezone year-round. * test: pin browser timezone to Europe/Berlin in karma config Re-enable the previously commented-out TZ pin so timezone-sensitive specs run deterministically where Chrome honors the env var (Linux/macOS, incl. CI). Verified empirically that headless Chrome on Windows IGNORES TZ and keeps the host zone — the *.tz.spec.ts files keep their offset-at-test-instant branching as the Windows backstop. * test: make supersync dump/restore helpers cross-platform createFullDump/restoreFullDump used POSIX-only shell constructs (output redirection to /tmp, 'cat | psql', 'rm -f'). On Windows the restore pipeline failed AFTER the 'DROP SCHEMA public CASCADE' had already succeeded, leaving the test database without any tables — every subsequent spec in the run then failed in createTestUser with 'table public.users does not exist' (5 cascading failures + dozens of never-ran tests). Capture pg_dump via execSync stdout + fs.writeFileSync, feed the restore through stdin (execSync input), use os.tmpdir() and fs.unlinkSync. Verified: full dump-restore spec plus the three spec files it previously poisoned all pass on Windows (14/14). * test(e2e): round-trip coverage for new rrule builder widgets Covers the four gaps hand-testing would otherwise need to catch, using the dialog's live result band as the oracle (.rrule-result__expr = exact assembled rule, .rrule-result__next = engine-computed upcoming dates — no waiting for real time): - custom nth ordinal (-2 = 2nd-to-last weekday) emits the right BYDAY and persists verbatim - BYSETPOS multi-select (first + last) emits BYSETPOS=1,-1 and persists - mode switch drops a weekday-set BYSETPOS instead of leaking it into a day-of-month rule (dead-rule regression) - switching to YEARLY seeds BYMONTH and the upcoming dates are strictly one per year Persistence asserted via the NgRx store: saving a recurring cfg re-plans the task onto its first occurrence (usually not today), so a UI reopen from the work view is date-dependent; the parse-to-widget rendering side is covered by the dialog/builder unit specs. * fix(add-task-bar): open the repeat dialog for the custom recurring option The repeat quick-setting menu emits the 'RRULE' value for 'Custom recurring config', but the add-task-bar still branched on the legacy 'CUSTOM' value — picking the option fell through to the preset path and silently created a weekly-fallback cfg instead of opening the dialog. Route both 'RRULE' and 'CUSTOM' through the dialog path, preselect the RRULE builder in the dialog via a new initialQuickSetting dialog input (the user explicitly asked for a custom rule), and show the tune icon for the menu entry again. Covered by a new e2e: menu pick → task created → builder dialog opens → saved rule persists verbatim. * fix(task-repeat): address review on rrule alignment + anchor sync safety - getAlignedStartDate re-anchors onto the rule's actual first occurrence (occurrence-set-neutral for INTERVAL/COUNT/UNTIL) instead of pure date math that shifted INTERVAL cadence and skipped valid clamped occurrences - save() always re-derives the legacy fallback fields against the final startDate, not only when alignment moved it - monthly anchors never persist null (released clients' typia schema only allows absent-or-numeric): undefined resets everywhere, null stripped at the action-creator boundary, model reverted to master signature - round-trip guard ignores BYSETPOS=0 so the cleaned rule is emitted instead of being preserved verbatim via raw override * docs(wiki): fix MD024 duplicate headings on repeating-tasks page * fix(task-repeat): harden rrule save guards + restore preset labels on reopen Correctness (from deep review of the branch diff): - reject COUNT combined with repeatFromCompletionDate at save: completion re-anchors startDate/lastTaskCreationDay, restarting the COUNT window, so the series would never terminate - reject parseable rules that yield zero occurrences (e.g. FREQ=YEARLY;BYMONTH=2;BYMONTHDAY=30): they persisted as silently dead recurrences with the legacy fallback bypassed - map the builder's single-weekday BYSETPOS form (BYDAY=FR;BYSETPOS=-1, 'last Friday') onto the legacy nth-weekday anchor; old clients previously fell back to startDate's day-of-month — a wrong recurrence Polish: - infer the preset back from the stored rrule when quickSetting was wire-clamped to CUSTOM, so Weekends & co. reopen under their label instead of the raw builder; new QUICK_SETTING_PRESETS single source replaces the hand-maintained KNOWN_PRESETS set - extract shared safeParseRRuleOptions + FREQ_TO_CYCLE (six drifted hand-rolled parse wrappers); memoize isRRuleValid (per-cfg routing guard on every overdue scan); share noonUtc/toLocalNoon between engine and preview; fold toMonthArray onto toNumArray; merge the duplicate _toPersisted action-creator helpers - trim the wiki section documenting the create-for-each-missed feature that was deliberately cut from this PR * fix(task-repeat): address curator review on anchor validity + fallback phase - never emit/persist an out-of-union monthlyWeekOfMonth: range-guard the BYDAY ordinal in rruleToLegacyTaskRepeatCfg (the builder's custom input allows ±5, the synced model only 1..4|-1), sanitize null AND out-of-range anchors at the action-creator boundary, and mirror the repair in data-repair — an out-of-union value trips released clients' typia validation/repair flow - reject sub-daily frequencies (raw override FREQ=HOURLY/...) at save: the day-granular engine would accept but silently collapse them to ~daily, and they have no legacy repeatCycle for old clients - log hygiene: the update-all-instances flow now logs changed keys + task ids instead of raw changes/task objects (title, notes and rrule body are user content; the log history is exportable); engine warns log the error name only, since rrule.js messages can embed the free-text rule body - align single-BYDAY weekly rules onto the engine's first occurrence: the engine groups weeks by WKST while the legacy fallback counts rolling 7-day blocks from startDate, so biweekly cfgs whose start is off the pattern day fired on OPPOSITE alternating weeks on old vs new clients (and WKST shifted the engine's phase, which legacy cannot express); after re-anchoring the cadence is exactly interval*7 days in both - diff dialog saves against the PROCESSED cfg: the lazy legacy->rrule migration (and preset inference) no longer leak into the change set of a title-only edit — rrule is schedule-affecting, so that leak relocated today's live instance on unrelated edits; empty change sets skip the update dispatch entirely instead of creating a no-op sync op * fix(task-repeat): keep presets rrule-backed + builder mode for completion cfgs - stop stripping the preset-generated rrule at save: getQuickSettingUpdates OVERWRITES the rule with the preset's canonical one, so the old 'clear on switch away from builder' branch broke the every-cfg-carries-its-rrule contract — and an rrule:undefined clear would not even propagate (dropped by the op-log JSON wire, leaving remote clients on the old rule); the spec asserting the stale behavior is inverted - completion-relative cfgs always open in builder mode: the schedule-type toggle only exists there, so preset inference (or a stored faithful preset label) would hide the one control that explains how the cfg fires - monthly anchor clears: document the wire gap properly instead of flipping values again — null trips released clients' blocking data-repair confirm dialog on every sync (typia has no null on these fields), undefined clears only locally; durable clears require shipping '| null' on both fields in a release FIRST, then switching the reset value (sequenced migration note in the model + an op-log JSON round-trip spec pinning current behavior) - replace 6 hardcoded rrule-builder placeholders with translation keys - revert the settings help text advertising the deferred @+ short syntax * test(e2e): drop CUSTOM weekday-checkbox spec superseded by rrule builder The #8025 e2e (merged in from master) drives the legacy CUSTOM recurring form's cycle select + weekday checkboxes, which this branch removes — the RRULE builder replaces that UI and its weekday toggles are covered by rrule-builder-roundtrip.spec.ts. The #8025 failure mode (a saved weekly cfg that never fires) is blocked generally at save by the first-occurrence probe. * test(e2e): de-flake worklog history day-row wait The worklog is rebuilt from the archive on the history navigation, so the day row only appears once that async load + month-expand animation settles. The bare `waitFor` fell back to the 15s action timeout, which CI load (prod build, 3 workers) could exceed. Use a web-first `expect().toBeVisible()` with 30s headroom instead. * fix(task-repeat-cfg): clear repeat-from-completion when switching to a preset The "from completion" schedule-type toggle exists only inside the RRULE builder. Selecting a preset hides it, but the flag stuck on the cfg, so a preset could keep firing relative to completion with no visible control. Clear it at the save() edit boundary, but only when actually set, so an untouched preset save stays an empty-diff no-op (#7373 class) rather than dispatching a spurious undefined->false op. The ADD path already starts from a false default, so the dialog is the only path that needs it. Also reword the monthly-anchor clear comments: the cross-client divergence on an nth-weekday -> day-of-month switch is an inherent, unfixable limitation for pre-rrule clients (no in-schema "no anchor" value; a `| null` migration would help an empty client band), not a deferred TODO. Make the round-trip test pin this explicitly and start the monthlyLastDay case from `true` so it proves the `false` clear survives the wire instead of passing vacuously.		2026-06-09 11:25:35 +02:00
..
recurring-events-implementation-plan.md	feat(task-repeat): RFC 5545 RRULE recurring schedules — EPIC · Phase 1/13 (Closes #4020) (#7948)	2026-06-09 11:25:35 +02:00
snap-wayland-gpu-fix-research.md	docs(research): §18.7 — source-level mechanism for appendSwitch vs argv divergence	2026-04-21 15:03:42 +02:00