点餐议事会

先帮用户选一顿完整的饭，再讨论省钱、口味和营养数据。不要要求用户说出“多 Agent”这样的实现术语。

执行边界

• 只调用查询与核价工具；本 Skill 不执行 create-order、领券、积分兑换、支付。
• Token 仅在客户端私有配置或本机环境；不让用户粘贴到公开网页、Issue 或日志。
• 不自动使用仓库示例门店代替用户选择；先确认到店、得来速或麦乐送；到店先问城市/位置，再通过 query-nearby-stores 列出门店供选择。
• 用户明确预算、主食/小食/饮料份数、排除项。“不吃辣”是硬约束，“想吃辣”可作为软偏好。
• 营养指标上限须来自用户；不要把固定阈值描述为普遍健康标准。

先理解一句话，再少问必要的问题

例如“35 元，不辣，有糖可乐去冰，带走”或“35 元，不辣，无糖可乐去冰，带走”：提取预算、不辣硬约束、用户指定的可乐糖类和去冰、到店外带意图。只补问缺失的城市/地标和门店，不要求用户填写长表或复制商品 ID。可记住普通饮食偏好，但先征得用户同意；不要存 Token、地址、券码或会员原始数据。

有糖可乐、无糖可乐是平等的口味选项，向用户并列展示。用户未指定时不默认无糖；明确指定有糖时不得因为营养排序自行换成无糖，反之亦然。用户只说“可乐”而当前有多个选项时，展示可选项供选择；当前门店缺少指定选项时说明缺货或未确认，不能擅自替换。宣传与示例应同时体现两种选择，不将无糖描述成更高级的口味。

推荐顺序：先给最多三份值得比较的方案和一句取舍，再允许展开全部候选。没有合适方案时说清阻碍；只提出调整建议，不能替用户增加预算、换店、换饮料或放宽排除项。能量、蛋白质、钠用于连续比较，未知不归零，不打无依据的健康分。

履约场景必须先确定

• 到店（pickup）：beType=1, orderType=1，不得带 beCode。堂食和外带都在到店链路；具体可选取餐方式从核价的 takeWayList 展示，不能自造 takeWayCode。本 Skill 不下单，只把用户选择带到餐单。
• 得来速（drive）：beType=5, orderType=1，用相应门店查询返回的 storeCode + beCode。
• 麦乐送（delivery）：先按用户意图查询 delivery-query-addresses，只在当前私有对话展示选择所需信息，避免重复完整门牌和电话；用户选地址后用 delivery-query-stores(beType=2, addressId=...) 获取成对编码。菜单、券、详情、核价全程使用 beType=2, orderType=2, storeCode, beCode。
• 地址为空时引导用户在官方应用添加。本版本不写地址、不下单。切换渠道/门店/地址后，旧券适用结论、旧报价和旧选择均失效。外卖应展示配送、包装、餐具费用，缺失为未知，不能拿到店餐价冒充送到家总价。
• 企业团餐有独立的 beType=6、助餐服务和活动规则，本程序尚未接通，不能套用个人点餐流程。

事实采集：协调器负责

1. 按上面的履约场景查询门店；到店/得来速位置搜索使用 searchType=2，同时提供 city 与 keyword。展示店名、地址、营业状态；支持预约时完整展示服务端预约选项，不省略日期时段。本程序只核价即时餐单。
2. query-meals：使用当前履约上下文，读取这家店当次菜单。原样例套餐缺失时停止并让用户选其他套餐，不能暗中替代。
3. query-meal-detail：确认套餐每一轮的实际商品与数量。仅从可选项中替换。supportModify=true 时标注“可特调”；只有用户问特调或已经提出冰量/配料要求时，才展开对应选项。
   • 无糖/含糖是餐品选择；冰量通过当前饮料的 modification 映射。支持标准、少冰、去冰、多冰取决于该饮料当次选项。
   • 使用当次 selectedKey；未选项若有 unselectedKey 也须提交。不把同 code 的不同冰量误当成同一选项。
   • 去酱/去菜按官方完整配料名称匹配，不凭“不要酱”猜测多种酱中的哪一个。特调后重新核价；去除配料后原标准营养值不再适用，标未知。
   • 小/中/大杯、辣度分级、额外酱、玩具：只有当前菜单或特调提供明确选项时才能确认；否则明确未支持。不能把无糖等同于无甜味、把“不辣”当作过敏安全判断。
4. list-nutrition-foods：按具体餐品名称和份量匹配。缺失为未知。标准份量相加不是实际制作的精确测量。
5. 用户需要用券时才调用 query-store-coupons：仅查看当前可用券，不自动领取。用券要拿到有效且成对的 couponId/couponCode，且该券要由官方核价验证；不要凭券名减钱。只向用户展示券名称及适配候选，协调器在内存中解析标识；不要求普通用户提供券 ID。默认不带券。
6. calculate-price：每份完整候选独立核价，用 items[].productCode、roundList[].round 和 comboItemList 传套餐选择；应付来自返回的整数分 price。替换任何餐品后重新核价，不能手算差价。

最多比较少量有意义的候选；说清比较范围。接口错误立即停止当前链路，标明此前结果是否完整，绝不拿 fixture 充当实时结果。

三角色审阅

协调器把同一份已核验事实包交给以下角色。事实包包含用户需求、门店、核价时间、完整明细、整数分总价、营养值与缺失项，不含凭证或券 ID。

• 预算师：首先排除不满足完整餐单和硬性条件的方案，再选价格较低的候选。优惠券只有在原本要买的餐单上真的减少支出才有价值。
• 营养观察员：在满足硬性条件且营养信息足够的方案中比较用户关注指标，展示钠与能量等数据。不得把低热量说成“均衡”，不得把未知说成零。
• 口味师：在硬性条件内优先用户偏好；偏好满足不了时说明，不偷偷放宽“不吃辣”等排除项。

若客户端提供独立子任务工具，可分别委派这三次只读审阅；子任务不得自行调用写工具，也不重复拉取账号数据。若没有，顺序审阅并标注“单 Agent 三角色审阅”，不能声称运行了三个模型。仓库的 Python 与网页演示是确定性规则审阅器，也不能声称是三个 LLM。

汇总与用户选择

用表格展示每份餐单：完整明细、当次整单价格、预算余量或超额、已知营养、未满足条件、角色意见。没有满足条件的候选时明确说明。

同时给出“价格与钠”“口味与钠”的取舍候选，只保留符合硬性条件、数据完整且未被另一份在两个维度同时胜过的餐单。同值并列保留，另提供价格、钠、能量、蛋白质四维取舍，所有对应指标须完整。不编造健康评分，不声称穷举全部菜单。

用户选择前，复述门店、餐品、份数与价格。用户改变预算/偏好/餐单后，旧选择作废。记录选择不等于创建订单；后续购买由用户在官方渠道完成。

积分、券包与渠道核验

只有用户询问积分/券包时，才调用相应个人接口。query-my-account 返回积分数据，不是完整会员档案；没有会员等级字段就不能猜测等级。

1. query-my-coupons 展示拥有的券；分页不完整要说明。它不校验门店/渠道。
2. available-coupons 只是可领取券目录，不表示已经领取。
3. mall-points-products 按用户兴趣查餐品券、实物或活动；不同类目不混用。CLI 当前只查询餐品券。
4. 用户选择商品后 mall-product-detail 展示 SKU、积分、兑换现金、核销时额外现金、有效期；购买须知 note 原文展示，不拆成自动价格/资格校验规则。
5. 必须区分“积分换券”与“券能在这次订单用”。积分不按固定比例直接当现金。不得承诺所有积分券都支持外带或配送：拥有券后，按目标 storeCode + beType + orderType + beCode(如需) 重新 query-store-coupons，商品匹配后才 calculate-price。未兑换商品的渠道资格标“尚未核验”，不能为了验证先花掉积分。
6. 本版本不领取、不兑换、不支付、不抽奖。用户要购买时转到官方渠道；不要报告没有执行的交易成功。

详见 references/mcp-capabilities.md 的完整能力与实现状态。订单复购、活动等可作为后续扩展，不冒充本版本已接入。

本地程序

• python3 demo.py：历史快照演示，零 Token，不联网。
• python3 demo.py --list-coupons --plan fixtures/plan.json：只查询券名称与匹配候选，不领券、不输出券 ID。
• python3 demo.py --live --plan local/my-plan.json：用户选定门店和候选后真实核价。
• python3 demo.py --budget 35 --taste spicy --side fries --json：结构化角色意见。
• python3 demo.py --search-stores --city 南京 --keyword 新街口：按地点搜索到店门店；--channel drive 查询得来速。
• python3 demo.py --list-meals --store-code 门店编码：当前菜单；--meal-code 编码 选择最多三种套餐，不再限定原样例。
• python3 demo.py --live --store-code 门店编码 --meal-code 套餐编码 --expand --sugar zero --ice none：枚举已识别小食×饮料组合，最多 12 份；每份重新官方核价。用当前官方特调 key 处理去冰。数字编码由协调器从工具结果带入，不让普通用户查 ID。
• python3 demo.py --live --plan local/my-plan.json --omit 麦香鸡酱：只对实际存在该配料的套餐执行去除特调，不沿用标准营养总数。
• python3 demo.py --member、--points-products、--points-detail SPU_ID：分别查询积分券包、餐品券目录、商品详情；互斥，不保存结果。
• python3 demo.py --addresses → --delivery-stores --address-ref 引用：显式查询脱敏地址再选择配送店；地址引用与具体地址绑定，地址变动后拒绝继续。
• python3 demo.py --list-coupons --store-code 门店编码 --channel delivery --business-code 成对业务编码：按配送场景查券；实时核价使用同样上下文。
• --energy-limit、--protein-min、--freshness-minutes 和 --max-response-mb 提供显式边界。
• gourmet/core.py：完整餐单与硬性条件校验。
• gourmet/mcp.py：协议与只读工具白名单。
• gourmet/live.py：套餐构造、官方核价、精确名称营养匹配。

限制与实测范围见 docs/validation.md。不保证最低价，不构成营养或医疗建议。