给 catering 菜单一个单独的页面

10 月 31 日，我把一份特别的 catering 菜单交给 agent 发布。用的仍然是平时的 publish-menu 流程，但我特意补了一句：这是提前订餐的特别菜单，不需要做店里的三块屏幕。每周取餐菜单在官网已经有自己的位置，这一份要容纳的是另一种订餐需求。

来源是三张菜单海报，合起来有 23 项餐点。海报写着从 11 月 15 日开始供应，订餐至少提前一周。发布页面时，这些安排还在未来。那天完成的是把给定的菜单放上网，不能据此说已经接下一单 catering，或完成了配送。

agent 保存了原始海报，把内容整理进单独的 catering 页面。按盘计价、20 件的价格，以及按件计价但至少订 20 件，分别保留了下来。只留下一个数字，会漏掉顾客究竟买到多少。来源没有写清楚的主食最低数量，或一盘具体有几件，页面也没有自行补一个答案。

页面保留了原始 Facebook 菜单帖的来源链接，顾客可以回到原帖核对。catering 区域说明了提前预订的要求，也把询问引向厨房的 Facebook Messenger。选好菜或发出询问，仍然需要厨房确认。这次没有加入自动结账，也没有承诺顾客提出的每个日期都能安排。

发布收尾前，agent 把正式站菜单及其数据与准备好的文件核对了一遍。原有的每周菜单仍然保留着。单独的 catering 项目不能悄悄替换掉带日期的取餐选择，否则其他顾客来查本周菜单时就会找错地方。我说的“不做三屏”也一直保留在这次任务范围里。

这次官网发布完成时，catering 菜单已经有了独立页面，中英文首页都能找到入口。我可以把特别订餐指向一个具体位置，价格、条件和来源链接放在一起。会不会有人来询问，厨房能接下哪些订单，则是接下来的事情。