import { VersionInfo } from '@start9labs/start-sdk'

export const v_0_2_59 = VersionInfo.of({
  version: '0.2.59:0',
  releaseNotes: {
    en_US:
      'Critical regression fix from 0.2.58: the continuous discovery polling was firing render() every 3 seconds (and pollTestRunJob was firing it every 2s), which clobbered the Settings form mid-edit. Symptom: drag a slider, the value snaps back to the last-saved position before you can hit Save. Three coordinated fixes: (1) New renderLightweight() helper that updates ONLY the out-of-root global in-flight bar (and the Jobs-tab body when on Jobs). Every periodic poll path now calls renderLightweight() instead of render() — discovery loop, pollTestRunJob progress callback, tryResumeActiveSingleRuns. The global pill still refreshes in real time; the body of whichever tab the operator IS on stays untouched unless they navigate. (2) Settings-tab guard inside render() itself: if activeTab==="settings" AND the body already has the Settings UI rendered (detected via a DOM probe for the .settings-actions element), skip the root.innerHTML rewrite. Switching INTO Settings still works because at that point the body has Overview/Jobs content (no .settings-actions yet); the first render fires, settings paint, subsequent background polls are gated. Save / Reset already use surgical DOM patches (they never relied on a full re-render) so this guard is transparent to the existing Settings UX. (3) loadJobs() in the periodic-poll finally blocks now only fires when the operator is actually on the Jobs tab. No wasted fetch + render when the operator is mid-edit on Settings; the next Jobs-tab entry auto-refreshes via switchTab. Net effect: sliders / number inputs / pill clicks on the Settings tab now stick — operator can drag, tweak, and hit Save without the form snapping back to stale state.',
  },
  migrations: {
    up: async ({ effects }) => {},
    down: async ({ effects }) => {},
  },
})