Upgrading 5.0 → 5.1

Three deliberate type breaks, two corrected dasha tables, two festival-timing corrections, and one opt-in flag. The breaks ship in a minor on purpose — v5 was days old — so pin 5.0.x until you have applied them. All three type breaks correct fields that did not match DrikPanchang, the project's parity oracle.

Three fields became arrays

Each of these published a single window (or a fixed pair) where the day can genuinely carry a different number. The migration is mechanical.

- if (r.inauspicious.varjyam) show(r.inauspicious.varjyam);   // TimePeriod | null
+ r.inauspicious.varjyam.forEach(show);                       // TimePeriod[], [] when none

- const [dm1, dm2] = r.inauspicious.durMuhurta;               // fixed 2-tuple
+ r.inauspicious.durMuhurta.forEach(show);                    // DurMuhurtaPeriod[], 1-2 windows

- if (r.muhurtas.amritKala) show(r.muhurtas.amritKala);       // TimePeriod | null
+ r.muhurtas.amritKala.forEach(show);                         // TimePeriod[], 0-2 windows

• inauspicious.varjyam is now TimePeriod[]. 5.0 evaluated only the sunrise nakshatra and dropped the second window printed panchangs show on transition days. 5.1 publishes every window whose start falls in the Hindu day (DrikPanchang's attribution rule), in start order, unclamped. Mula's second tyajya spell (elapsed ghatikas 20 and 56) is also emitted now. New export: computeVarjyamWindows; the single-window computeVarjyam primitive keeps its signature and returns the earliest overlapping spell.
• inauspicious.durMuhurta is now DurMuhurtaPeriod[]. The old table emitted two day windows every day and matched drik on none of the seven weekdays. The corrected Muhurta-Chintamani table gives one window on Sunday and Wednesday and two elsewhere — and Tuesday's second falls at night (the 7th of the fifteen sunset→sunrise muhurtas), so a fixed two-day-window tuple could not survive. Each entry carries segment, 'day' or 'night'. Verified against 58 consecutive drik day-pages across two cities.
• muhurtas.amritKala is now TimePeriod[]. Amrit Kala shares Varjyam's architecture — drik prints them from the same frame. Each window anchors at its own nakshatra's start, offset by a per-nakshatra count of nakshatra-elastic ghatikas, spans exactly four such ghatikas, and belongs to the Hindu day its start falls in: 0–2 per day. The old sunrise-anchored single window disagreed with drik by up to ~16 h. computeAmritKala is replaced by computeAmritKalaWindows(sunriseUtc, nextSunriseUtc, getMoon).

Two dasha starting lords corrected

Both were wrong for every birth, so any output recorded from 5.0 or earlier should be discarded rather than reconciled.

• Yogini starting lord corrected. Was nakshatraIndex % 8 — off by three for every birth. Now the classical Devi-Bhagavata formula ((1-based nakshatra + 3) mod 8): Ashwini → Bhramari, Pushya → Dhanya.
• Ashtottari starting lord corrected. Was a years-proportional split from a Krittika anchor, matching no source. Now the classical Ardradi group table (malefics four nakshatras each, benefics three; exported as ASHTOTTARI_NAKSHATRA_GROUPS), balance from the elapsed fraction of the group.

Full tables and the group model live in Dashas & Transits.

Ekadashi splits and regional new years move

Neither of these changes a type, so the compiler will not flag them — the dates simply move on affected days.

• Ekadashi splits: Smarta first, Vaishnava second. On the days drik prints an Ekadashi twice, the earlier day is the Smarta fast and the later one the Vaishnava fast. Callers that keyed off smarta_ekadashi / vaishnava_ekadashi on split days will see the two swap places. computeEkadashiDatesForYear is unchanged; custom locale packs need the renamed viddha description keys.
• Regional solar new years land on their own days. vishu, baisakhi and pohela_boishakh no longer share Puthandu's day — each keys off the Mesha transit moment its own way. In 2027 Vishu and Pohela Boishakh fall on April 15 while Puthandu falls on April 14; in 2028 Vaisakhi falls on April 13 while the rest fall on April 14. getHinduNewYear follows the same per-region rules.

// Dashami-viddha day (e.g. Rama Ekadashi, 2027-10-25)
- ['vaishnava_ekadashi', 'smarta_ekadashi' /* deferred */, 'ekadashi']
+ ['smarta_ekadashi', 'ekadashi']          // vaishnava_ekadashi is tomorrow

  // First day of a vriddha Dwadashi (e.g. 2026-08-24)
- []
+ ['vaishnava_ekadashi']

Opt-in Gana-dosha cancellation

computeAshtakoot(boy, girl, { ganaCancellation: true }). Default output is byte-identical to 5.0. See Matching & Doshas.

Corrections without shape changes

These ride along in 5.1 without moving a type. Times and verdicts move on affected days, so re-run anything you cached.

• Dur muhurta ordinals, night choghadiya names, and Bhadra vasa — now Moon-rashi keyed, with a piecewise vasa segment list on BhadraInfo.
• Night-transit Sankranti dates, plus a new moment field on SankrantiEvent; the kshaya-Dwadashi Ekadashi advance; and the Kali Yuga year boundary.
• Vijayadashami / Karva Chauth / Janmashtami kala rules, scoreMuhurta special-yoga parity, eastern-longitude Gulika/Mandi, and the opt-in Ashtakavarga reductions.