Bubble tea weekly schedule builder (single-file tool) - demand derived straight from last week's cup curve, student availability as hard constraints, shortfalls flagged in red instead of silently relaxed

You are a coding agent building an internal tool for a
bubble tea shop. Build a single-file HTML tool (HTML,
CSS, JS all inline - no external dependencies, no network
requests, opens by double-click) that generates a weekly
schedule for the scheduling supervisor.

What makes this shop different from a generic scheduler
(build for this, not the generic case):
- Demand is not hand-entered; it is derived from last
  week's cup curve
- The crew is mostly student part-timers; availability
  windows are hard constraints
- Two anchor shifts exist: the opening prep shift
  (brewing tea, cooking pearls) and the closing clean-up
  shift - each must get someone with the matching skill,
  no exceptions

Input section:
- Last week's cups: cups per hour slot, with a global
  multiplier (e.g. expect +10% next week)
- Capacity: drinks one person steadily makes per hour
  at peak; plus a role-mix rule (e.g. "slots needing
  2 or fewer people: all assembly; 3+: include one
  prep person" - rule editable by the user)
- Staff table: name / skills (opening prep, assembly,
  register, closing - multi-select) / weekly available
  windows (hour granularity checkboxes) / weekly hour
  cap
- Constraint settings (defaults editable): max
  consecutive hours on shift, minimum hours between
  shifts, at least one opener and one closer with the
  matching skill

Solving logic (include a "how this works" section on the
page):
1. Demand derivation: people needed per slot =
   ceil(slot cups / per-person hourly capacity), then
   split into roles by the role-mix rule
2. Fixed allocation priority, not adjustable by the
   algorithm: anchor shifts (open/close) > hard
   constraints (availability, weekly caps) > peak-slot
   coverage > hour balance
3. Every assignment must be explainable as one of:
   skill match, most slack in that slot, most weekly
   hours remaining
4. Behavior when constraints cannot all be met (the
   core requirement of this tool): never silently relax
   a constraint. Output the closest plan, flag every
   unmet item in red - which slot is short how many
   people, which role, blocked by which constraint -
   and suggest which lever to loosen first (widen one
   part-timer's availability / lower that slot's demand
   / move an anchor shift). After the user adjusts,
   re-solve and re-flag.

Output section:
- Weekly grid (person x day, cells with start/end/role)
- Each person's weekly hours vs cap
- Red-flagged unmet list + loosening suggestions
- "Export text" button: plain-text schedule in the
  format you would paste into the staff group chat

Constraints:
- No accounts, no cloud, no network calls - data lives
  in localStorage only, with a "clear this shop's data"
  button
- A explainable greedy or backtracking solver is fine;
  do not chase optimality. Comment the code so a
  part-time supervisor can read it and tweak the
  parameters.
- Ship no built-in "industry default" cup rates or
  hours - capacity and constraints come entirely from
  user input, and first open shows an empty form with
  no sample data.

Why it is written this way

Deriving demand from the cup curve instead of hand-entering it is the biggest divergence from a generic scheduler. The weekly hand-filled demand sheet is the most fudgeable step in scheduling - "we had about this many people last week, keep it" - which photocopies last week's mismatch into next week. Letting the tool do the arithmetic (slot cups / per-person capacity, rounded up) leaves the supervisor maintaining only two honest inputs: cup counts and the capacity figure.

Availability as a hard constraint rather than a preference reflects the part-timer reality: a window blocked by a class schedule cannot be negotiated by an algorithm, and a scheduler that treats it as soft produces a beautiful table that fails on day one. For the same reason the two anchor shifts get top priority - an empty opening-prep shift (tea unbrewed, pearls uncooked) or a skipped close damages the store worse than one lean rush slot.

"Never silently relax a constraint" is the tool's entire reason to exist. Its user is a supervisor, not a programmer; if it quietly stretches a rule, the output still looks like a complete schedule and the failure surfaces only when Friday's rush implodes. Red flags plus "loosen this first" hand the trade-off back to a human - add availability, lower demand, or move an anchor - with each option's cost visible.

The empty-first-open rule is deliberate too: sample data has a way of becoming the default capacity figure and quietly living there for a year. A schedule built on a wrong capacity number is worse than no schedule, because it wears the halo of "the tool computed it."

Variables