Scheduling supervisor wave staffing tool - four stations from washing to packing, headcount from takt times, cross-cover lists that respect skill boundaries

You are a coding agent. Build a single-file HTML "wave
staffing" tool for a central kitchen scheduling
supervisor: given production waves and station takt
times, compute how many people each station needs, where
the bottleneck is, and who can cross-cover. Runs locally
in the browser - no network, no dependencies, no
external resources.

1. Inputs (four blocks)
   a. Wave tasks: wave / item / task volume (kg or
      portions) / deadline
   b. Station takt table: station (wash/cut, cook, fill,
      pack - extendable) / item / labor minutes per unit
      of task
   c. Station precedence: which station must wait for
      another's output before starting, plus the minimum
      lead (e.g. wash-before-cook by 【90】 minutes)
   d. Skill matrix: name (or ID) / stations they can
      work / available hours this week / consecutive
      day count

2. Computation (fixed rules)
- Station headcount = the wave's total labor minutes at
  that station ÷ available duration, rounded up
- Bottleneck flag: the station with the largest headcount
  on the longest precedence chain, marked red, with "one
  hour's delay here pushes wave completion by X"
- Backward pass for start times: from the wave deadline,
  walk the precedence chain backward to each station's
  latest start - the pre-dawn shift's clock-in time
  comes from this number, not from folklore
- Feasibility under skills: a station needing more
  people than can work it is flagged a "skill gap," and
  the tool pulls a cross-cover list from the matrix
  (people who work adjacent stations and can cover
  short-term), sorted by remaining weekly hours
- Fatigue constraints: anyone past 【6】 consecutive days
  drops off the cross-cover list; anyone already at 【8】
  hours that day drops off the overtime-eligible list

3. Output
- Table 1, per station: headcount needed / latest start
  time / bottleneck flag / skilled people available /
  gap
- Table 2, cross-cover list: who / what they can work /
  which station they'd cover / remaining weekly hours
- Table 3, per-person schedule: each person's station,
  hours, and any fatigue flag for the day
- One-click copy as a text roster (WeChat-ready: name,
  station, time)

4. Error guards
- Cycles in the precedence graph (A waits on B, B on A):
  detect and refuse to compute
- The same person double-booked in one time slot:
  detect and mark red
- Unit mismatch between task volume and takt (kg against
  portions): validate on entry, flag yellow for
  conversion

5. Data
- Takt table, precedence, and skill matrix persist in
  localStorage with JSON export/import; wave tasks are
  paste-and-go, never saved
- No fairness judgments on "who rests, who works" - the
  tool outputs feasible solutions inside constraints;
  trade-offs belong to the supervisor

UI: desktop first; the supervisor's morning starts with
Table 1. Deliver one complete HTML file with all CSS and
JS inlined, plus a Chinese usage note under 200
characters.

Why it is written this way

Headcount from station takt times rather than wave-level totals is the tool's fundamental logic: the four stations don't share skills (cookers who can't fill is the norm), so total headcount that suffices in aggregate still starves the line in structure. Per-station numbers make the most common misallocation - washers stacked, fillers waiting - visible for the first time: Table 1 says outright that what's missing isn't people, it's people who can fill.

The backward pass for start times serves the pre-dawn shift: what time to clock in is the scheduler's first decision every day and the easiest one to make by feel. Walking the precedence chain backward from the deadline puts a provenance on every start time - wash at 4:20, cook at 6:00 - and quantifies the knock-on of lateness (wash runs half an hour late, the wave slips by X). A veteran keeps this table in their head, but a head-table can't be shown to a new supervisor, to the owner, or recomputed when the item mix changes.

Fatigue constraints filter the cross-cover list up front rather than warning afterward, because the list's real moment of use is exactly "short-handed today, grab someone" - and a warning that comes after the fact is no warning at all. The two numbers (six consecutive days, eight hours) are variables that differ by plant, but the mechanism - excluded from the list - is fixed: the short-handed day is precisely when safety and quality incidents are likeliest, and the tool has to be calmer than the person at that moment.

The tool computes feasibility and leaves fairness alone, both a boundary and a protection: whose overtime piles up and whose shifts are ugly is a question of relationships and policy between supervisor and crew, and the moment an algorithm decides it, every unhappy worker has a tool to blame. Feasible solutions, constraints, and gaps on the table; the judgment stays human - which is also what keeps the supervisor irreplaceable.

Variables