快餐店设备维修：保养日历生成小工具——让编码代理做一个单文件页面，录设备清单和营业高峰时段，排出不撞高峰的周/月/季保养表

你是一个编码代理。请为我做一个单文件 HTML 的「设备保养日历」工具，给快餐店设备维修技师用：录入设备清单和本店营业时段，工具排出全年周/月/季保养计划，并保证保养时段不撞营业高峰。不联网、不装依赖、不引外部资源，手机和电脑浏览器都能打开。

一、技师录入（「设备库」页）
- 设备清单：每台设备录 名称 / 型号 / 保养项列表
- 每个保养项录：名称 / 周期（周/月/季/年）/ 预计耗时 / 是否需要停机（停机类：冷凝器除尘、炸炉深度清洁、制冷系统检查；非停机类：门封条检查、外观紧固、线路目视巡检）
- 本店营业信息：营业时段、高峰时段（如午市 11:00-13:00、晚市 17:00-19:00）、每周不可动日（盘点日、大进货日）、打烊时间与开店时间

二、排程规则（工具的核心，全部硬规则，不做「智能优化」）
1. 停机类保养只排非营业时段（打烊后或开店前），且单次连续作业不超过打烊到下次开店的实际间隔
2. 非停机类可排营业低峰时段，但高峰时段内不排任何保养
3. 同一台设备的多个保养项尽量合并到同一次（冷凝器除尘与门封条检查合成一次上门）——省的是拆装与往返
4. 周/月/季项落位后按设备分散排布：不给同一个晚上堆三台设备的停机保养
5. 排不下时明确报冲突：列出哪几项挤在哪一天、各自耗时，让技师取舍——工具不许自动把停机项改排到营业时段来「解决」冲突

三、视图与执行
- 周视图：本周每天该做什么，每项随行标注排程理由（「停机类·打烊后 21:30」）——理由可见，技师才看得出规则有没有被破坏
- 完成打勾；同一保养项连续漏做【N】次标红并提示「该设备的风险在积累」——只提示，不弹窗轰炸
- 年度总览：每台设备全年保养次数与停机保养总时长

四、数据
- 全部存 localStorage，支持导出/导入 JSON 备份（换手机不丢日历）
- 设备库页与执行页分开，执行页（店员也能看）入口简单

防错：
- 周期必填、时段格式校验，错了保存时拦下
- 营业时段信息为空时拒绝生成日历——没有高峰数据就排程，等于默认高峰不重要
- 不预填任何设备与保养周期模板——每家店设备型号与工况不同（日营业 8 小时和 16 小时的炸炉不该共用周期），预填模板会把技师引向错误的周期；这个工具只做排程，保养周期必须技师自己定

界面：执行页大字大按钮、一屏一天；设备库页桌面优先。交付一个完整 HTML 文件，内联全部 CSS 与 JS，附两百字以内的中文使用说明。

为什么这样写

排程的核心冲突不是「排什么」，是「排什么时候」。保养计划在快餐店落地失败的第一原因不是技师懒，是计划撞上营业——停机保养排在午市前，到点做不了，一拖一周。工具的第一条硬规则就是停机类只进非营业时段，且连续作业不超过打烊间隔：把「排了但做不成」在设计里堵死。

冲突必须显式报告而不是自动解决。排不下时让技师取舍，是因为工具没有资格替人决定「哪个保养可以牺牲」；自动把停机项挪进营业时段来消冲突，表面上日历完整了，实际是把规则的破坏藏进了好看的界面——这种「智能」恰恰是工具失去信任最快的方式。宁可日历上留一个显眼的冲突清单，也不留一个悄悄错误的完整日历。

不预填设备模板和保养周期，和分诊工具不预填故障树是同一个道理：周期长在具体设备型号和本店工况上，日营业 8 小时和 16 小时的炸炉不该共用一张周期表。工具只做它擅长的约束求解与日历，专业判断全部留在技师手里——预填的「通用模板」会把技师引向一个别人的周期。

排程理由随行显示是审计线。半年后没人记得规则是什么，但每项保养都带着自己的理由（「停机类·打烊后 21:30」），规则被破坏的那天一眼就能看出来——日历自己解释自己，就不需要有人守着它。

变量