奶茶店周排班表生成小工具——需求直接从上周杯速曲线推，兼职时段是硬约束，缺口红着喊出来不许静默放宽

你是给奶茶店做内部工具的编码代理。请做一个单文件
HTML 工具（HTML/CSS/JS 全部内嵌，无外部依赖、无
网络请求，浏览器双击打开即用），给排班主管生成
周排班表。

这个店的排班特点（按这个做，不要做成通用排班器）：
- 需求不是手填的，是从上周杯速曲线自动推的
- 员工以学生兼职为主，可用时段是硬约束
- 有两个锚点班：开档煮茶备料班、收档清洁班，
  各必须排到会做的技能者，不能空

输入区：
- 上周杯速：按小时槽填上周杯数，可整体乘一个
  系数（如预期下周涨一成）
- 产能口径：单人每小时稳定出杯上限【】杯；
  岗位配置规则（如「槽需求 ≤2 人时全部排
  出杯岗，>2 人时含 1 名备料岗」——规则用户
  可改）
- 员工表：姓名 / 技能（开档煮制、出杯、收银、
  收档，可多选）/ 每周可用时段（按小时粒度
  勾选）/ 每周工时上限
- 约束设置（默认值可调）：连续在岗不超过【】
  小时、两班间隔不少于【】小时、开档班与
  收档班各至少 1 名对应技能者

生成逻辑（页面上要有「方法说明」区）：
1. 需求推导：每槽需求人数 = 向上取整（槽杯数 ÷
   单人小时上限），再按岗位配置规则拆成岗位需求
2. 分配优先级固定，不许算法自行调整：锚点班
  （开档/收档）> 硬约束（可用时段、周上限）>
   峰槽覆盖 > 工时均衡
3. 每次分配要能说明「为什么是他」：技能匹配、
   该槽余量最多、当周工时余量最大，三者之一
4. 约束满足不了时的行为（本工具的核心要求）：
   不许静默放宽任何约束。输出最接近的方案，
   红标所有未满足项：哪个槽差几个人、差什么
   岗位、卡在哪条约束；并给「先松哪条」的
   建议（加一名兼职的可用时段 / 调低该槽需求 /
   挪锚点班时间），用户调整后重新求解、重新
   红标

输出区：
- 周排班表（人 × 天，格子含到店/离店/岗位）
- 每人当周工时合计 vs 上限
- 未满足项红标清单 + 松约束建议
- 「导出文本版」按钮：纯文本周表，贴到员工群
  里用的那种格式

限制：
- 不做账号、不做云存储、不请求网络——数据只存
  浏览器 localStorage，提供「清空本店数据」按钮
- 算法用可解释的贪心或回溯即可，不追求最优解；
  代码注释要让兼职主管看得懂、能改参数
- 不内置任何「行业默认杯速」「行业默认工时」
  ——产能与约束全部由用户输入；首次打开是
  空表，不带示例假数据

为什么这样写

需求从杯速曲线推、而不是每周手填，是这条与通用排班器最大的差别。手填需求表是排班流程里最容易糊弄的一步——「上周大概几个人就还几个人」，抄完上周的错配。把推导交给工具（上周杯数 ÷ 单人上限，向上取整），主管每周只需要维护两个真实的输入：杯数和产能口径。

可用时段设为硬约束而不是优先级项，是学生兼职业态的现实：课表钉死的时段调不开就是调不开，把它做成软约束的排班器会生成一张漂亮的、第一天就执行不了的表。同理，锚点班（开档煮茶、收档清洁）单列优先级最高——这两个班空一天，开店时间和卫生状态直接出问题，比峰槽缺人后果更重。

「不许静默放宽约束」是整条工具的立身之本。排班器的用户是主管，不是算法工程师；如果工具悄悄放宽了某条约束，主管拿到的仍是一张看起来完整的表，问题要等周五晚峰爆出来才被发现。红标 + 「先松哪条」建议把取舍权还给主管：加兼职时段、调需求上限还是挪锚点班，每条松法的代价都看得见。

首次打开不带示例数据也是刻意的：示例假数据会被当成默认产能口径留下来，一用一年——产能口径错的排班表比没有排班表更糟，因为它带着「工具算的」这个光环。

变量