Fast food restaurant equipment technician - maintenance calendar generator tool - have a coding agent build a single-file page that takes your equipment list and rush-hour windows and lays out a weekly/monthly/quarterly schedule that never collides with service

You are a coding agent. Build a single-file HTML "equipment maintenance calendar" tool for a fast food restaurant equipment technician - the technician enters the equipment list and this store's operating hours, and the tool lays out a full-year weekly/monthly/quarterly maintenance plan with the guarantee that maintenance never collides with peak service. No network, no dependencies, no external resources; opens in phone and desktop browsers alike.

1. Technician input (the "Equipment Library" page)
- Equipment list: per unit - name / model / task list
- Per task - name / interval (weekly/monthly/quarterly/annual) / estimated duration / whether the unit must be shut down (shutdown-type - condenser coil cleaning, fryer deep clean, refrigeration circuit check; non-shutdown - door gasket inspection, fastener check, visual wiring walk)
- Store operating info - opening hours, rush windows (e.g. lunch 11:00-13:00, dinner 17:00-19:00), weekly no-touch days (inventory day, big delivery day), closing and opening times

2. Scheduling rules (the tool's core - all hard rules, no "smart optimization")
1) Shutdown-type tasks go only into non-service hours (after close or before open), and a single continuous session never exceeds the actual close-to-open gap
2) Non-shutdown tasks may land in off-peak service hours, but nothing - shutdown or not - is scheduled inside rush windows
3) Multiple tasks on the same unit merge into the same visit (condenser cleaning plus gasket inspection become one trip) - what this saves is teardown and travel
4) Once weekly/monthly/quarterly items are placed, spread them across units - three units' shutdown tasks never pile onto the same evening
5) When the calendar does not fit, report the conflict explicitly - which tasks collide on which day, at what durations each - and let the technician choose; the tool may never "resolve" a conflict by quietly rescheduling a shutdown task into service hours

3. Views and execution
- Week view - what is due each day this week, each task labeled inline with its scheduling reason (shutdown type - 21:30 after close) - with the reason visible, the technician can tell at a glance whether a rule has been broken
- Tick completed; a task missed [N] times in a row turns red with the note that risk on that unit is accumulating - a note, not a popup barrage
- Year overview - per unit, total tasks per year and total shutdown hours

4. Data
- Everything in localStorage, with JSON export/import for backup (changing phones loses no calendar)
- The equipment library page and the execution page are separate; the execution page (readable by staff too) has the simple entrance

Guard rails:
- Interval required, time-range format validated; invalid entries blocked at save
- Refuse to generate the calendar while operating info is empty - scheduling without rush-window data implicitly declares that rush windows do not matter
- Pre-fill no equipment and no maintenance-interval templates - every store's equipment and duty cycle differ (a fryer on an 8-hour day and one on a 16-hour day should not share an interval), and a pre-filled template steers the technician toward someone else's schedule; this tool does scheduling only, and intervals are always the technician's own call

UI - execution page with large type and large buttons, one day per screen; equipment library desktop-first. Deliver one complete HTML file with all CSS and JS inlined, plus a usage note in Chinese under two hundred characters.

Why it is written this way

The core conflict in scheduling is not what to schedule but when. Maintenance plans in fast food die first not from laziness but from collision with service - a shutdown task placed before the lunch rush cannot be executed at its moment, and one slip stretches into a week. The tool's first hard rule puts shutdown tasks only into non-service hours and caps continuous sessions at the close-to-open gap - "scheduled but undoable" is designed out at the root.

Conflicts must be reported, never auto-resolved. When the calendar does not fit, the technician chooses, because a tool has no standing to decide which maintenance may be sacrificed. Silently moving a shutdown task into service hours to clear a conflict produces a complete-looking calendar with a broken rule hidden inside a pretty interface - and that kind of cleverness is exactly how a tool forfeits trust. An honest conflict list on the calendar beats a quietly wrong complete one.

No pre-filled equipment templates or intervals, for the same reason triage tools ship with no pre-filled fault trees - intervals grow out of the specific model and this store's duty cycle, and a fryer on an 8-hour day should not share a table with one on a 16-hour day. The tool does only what it is good at - constraint solving and the calendar - while every professional judgment stays with the technician; a generic template steers them toward somebody else's schedule.

The inline scheduling reason is the audit trail. Six months later nobody remembers the rules, but every task carries its own justification (shutdown type - 21:30 after close), so the day a rule gets broken it shows at a glance - a calendar that explains itself needs no one guarding it.

Variables