import { type RRuleLines } from '../rrule/date.rrule.parse';
import { type ICalendarRecurrence } from './icalendar.model';
/**
 * The RRule property type this bridge reads out of the basic lines. Anything else there is dropped.
 *
 * DTSTART in particular is dropped on purpose: an {@link ICalendarEvent} carries its start as a typed
 * {@link ICalendarDateTimeValue}, so a DTSTART smuggled in through the recurrence would be a second,
 * conflicting source of truth for the same fact.
 *
 * EXDATE and RDATE never reach here: `separateRRuleStringSetValues()` routes them into its own `exdates` /
 * `rdates` sets, because an RDATE left among the basic lines makes rrule's own parser throw.
 */
export declare const ICALENDAR_RECURRENCE_RRULE_PROPERTY_TYPE = "RRULE";
/**
 * Converts the workspace's stored recurrence form into an {@link ICalendarRecurrence}.
 *
 * THE TRAP THIS EXISTS TO CLOSE: {@link ICalendarRecurrence.rules} holds the VALUE PART only
 * ("FREQ=WEEKLY;BYDAY=MO"), because the serializer emits `RRULE:${rule}`. The stored form —
 * {@link RRuleLines}, as carried by ModelRecurrenceInfo.rrule — is a newline-joined blob that KEEPS the
 * "RRULE:" prefix and may also carry EXDATE/RDATE lines. Passing one straight into the other emits
 * "RRULE:RRULE:FREQ=..." and every client silently drops the rule.
 *
 * The expansion path needs none of this: DateRRuleInstance feeds the same string to RRule.parseString(),
 * which handles the prefix natively. The mismatch bites in exactly one place, which is here.
 *
 * @param lines - The stored recurrence lines.
 * @returns The recurrence, with EXDATE lines routed to exceptionDates and RDATE lines to additionalDates.
 *
 * @example
 * ```ts
 * iCalendarRecurrenceForRRuleLines('RRULE:FREQ=WEEKLY;BYDAY=MO'); // { rules: ['FREQ=WEEKLY;BYDAY=MO'] }
 * ```
 *
 * @__NO_SIDE_EFFECTS__
 */
export declare function iCalendarRecurrenceForRRuleLines(lines: RRuleLines): ICalendarRecurrence;