local-notifications-scheduler

用途：为 Flutter 应用建立统一、可验证的本地通知与提醒调度引擎。核心约束是本地数据库为唯一真实来源，操作系统的待处理通知集只是可重建的缓存，任何提醒在进程结束、重启、Doze 或恢复后都应能从数据库单独重建。\n\n主要能力：所有调度变更必须经由唯一的 syncNotifications() 对账入口，禁止在功能或 UI 代码中直接调用 gateway.schedule()/cancel()。flutter_local_notifications 只允许在一个适配器文件中导入，其余代码包括测试都面向 NotificationGateway 端口。调度计算保持纯函数、无副作用并注入 Clock，便于在设备外用 FakeNotificationGateway 做单元测试。重复计划以墙上时钟加重复规则存储，仅在调度时解析为 TZDateTime；一次性时刻存 UTC 毫秒。启动时设置 tz.local。\n\n使用方式：项目按 core/（纯数学，无 Flutter）与 services/（端口、实现、对账）分层，通过 Riverpod 提供者注入依赖。仓库提供检查脚本：scripts/check-single-fln-import.sh、scripts/check-scheduler-purity.sh、scripts/check-adhoc-schedule-calls.sh、scripts/check-manifest-permissions.sh，提交 PR 前运行。参考文档位于 references/ 下，涵盖端口契约、重复与 DST 规则、平台启动与精确闹钟。\n\n适用场景：需要在 Android 与 iOS 上可靠调度、取消和推理本地提醒的 Flutter 应用。\n\n限制与注意事项：iOS 待处理通知有约 64 条上限，建议预算约 50 条并在前台补充；Android 默认使用不精确模式，精确闹钟需通过可撤销权限并静默回退，不应声明 USE_EXACT_ALARM；后台点击处理运行在独立 isolate，不应写数据库；备份恢复后应先 cancelAll() 再完整对账。重启、后台 tick 与 OEM 存活均为尽力而为，可靠性由前台对账保证。具体版本要求、依赖安装命令和平台配置细节资料未提供。