/**
 * 定时任务写侧总闸 —— `PAC_SCHEDULER_DISABLED=1` 时本实例不跑任何**会改数据**的定时任务。
 *
 * 【为什么需要】服务器迁移 / 蓝绿发布 / 备用实例这类「新旧实例并存」的窗口里,新实例要能
 * 起来接流量、验证配置,但绝不能同时对 DW 做增量摄入 + persona/plan 重算:
 *   - 各连各库:两边各拉各的,待迁移的数据快照持续偏移,dump 出来就是旧的
 *   - 同连一库:互抢 sync_logs 的 partial UNIQUE(host_id) WHERE status='running' 锁,
 *     还会把对方**正在跑**的锁当"僵尸"回收掉(回收判据只看 startedAt 早于本进程启动)
 *
 * 【为什么必须是代码开关,不能用 env 现有机制】
 *   - jvs-dw 的 manifest 写死 `auto_sync: true`,scheduler 启动即自动发现并注册
 *   - cron 表达式也写在 manifest(`incremental_cron`),优先级高于全局 env
 *   - `PAC_INCREMENTAL_HOSTS=` 留空只会 fallback 到自动发现,关不掉
 *   - 改 manifest 能关,但 `deploy-prod.sh` 会 `git pull`,改动被覆盖
 *
 * 【边界:只关"写",不关"读"】本闸刻意**不覆盖** dw-lag-monitor / daily-health-report ——
 * 那两个只发告警和报表、不碰业务数据,备用实例照常跑反而能多一双眼睛。真要静音它们,
 * 各自的 `PAC_*_CRON` 不设即为「永不执行」(代码默认 `0 0 31 12 *`)。
 *
 * 【别忘了关掉】迁移完成、旧实例下线后,**务必移除该 env 并重启** —— 否则新生产静默不摄入,
 * 表现只有"数据越来越旧",没有任何报错。DW 滞后监控能兜住(它不受本闸影响),但那是 24h 后的事。
 */
export function schedulerDisabled(): boolean {
  return process.env.PAC_SCHEDULER_DISABLED === '1';
}
