本报告不构成签约建议。所有数字都标注了出处；标为「未知」的项目，系统不会替你填数。
INVESTIGATE — 关键信息尚未查清
1 项关键信息未确认，另有 1 项待补充（逐条见第 10 节）。
TI allowance（装修补贴）通常在装修完工并开业后才由业主支付，因此不能减少期初所需现金，只能降低项目总成本。
免租期同时给出现金口径与直线摊销口径：现金口径决定你熬不熬得过装修期，摊销口径决定长期真实占用成本。两者不可混用。
「乐观上界」= 假设开业第一天即达到成熟营业额。这是一个数学上界，不是预测：你实际的爬坡速度决定真实跑道比这个数字短多少，请把它当作上限，不要当作可以安排现金的实际月数。
「跑道（乐观上界）」这一行会永远显示未知，不是因为这次分析漏填了什么——这个版本的输入里没有任何字段能表达爬坡假设（开业后各月营业额占成熟期的比例），所以不存在任何一份输入能把这个数字填出来。等价的、不需要爬坡假设就能算出来的另一条边界见上面「零收入撑多久」。
TI allowance 通常在开业后支付，本引擎不将其计入期初可用现金。
「零收入撑多久」不是在告诉你有一笔可以从容动用的缓冲，是在算一个日期：假设开业后完全不开张、一单不卖，只按当前固定成本往外流，现金到第几个月归零。如果开业时免租期还没用完，前面这一段按免租费率算，用完后再切到满租费率——不是从头到尾都按免租费率算，那会把撑多久算得过于乐观。
你的情况：免租期 2 个月，装修工期 3 个月——免租在装修期内（第 2 个月）就已经用完，开业当天起已经是满租，上面两个数字全程按满租费率计算，不是按免租费率算的。
上面给出的两个口径：业主计薪时现金归零得更早；业主不计薪时看起来更晚，但晚出来的这几个月不是生意本身赚出来的现金，而是业主不领工资在补贴这门生意——一旦业主需要靠这份收入生活，真实的倒计时是业主计薪那个更早归零的数字。
当前假设下每单贡献毛利的下界不为负，因此真的开始卖只会让这两个日期推迟或不变：这是一对真正的下界，哪怕完全卖不出去，现金也至少能撑到这里。
「租金压力测试」只回答『要覆盖房租需要卖多少』；「完整盈亏平衡」回答『要覆盖全部固定成本需要卖多少』。两者是不同的量，不可互相替代。
各渠道的贡献毛利分开计算后再加权。外卖的抽佣与包装成本不会被堂食稀释。
已提供 menuItems：全部菜品的配方都带有 packaging 行，配方推导出的加权食材成本率已经把这些包装成本算进了每道菜的 totalDirectCost，因此渠道层面的包装成本按 0 处理——这不是缺口，你不需要再额外填写 costRates.packagingCostPerOrder。
这是理论产能上限：座位数 × 各时段可翻台次数，加上外带出餐能力。它假设每个座位在整个营业窗口内无缝衔接、无空档。
本系统不提供「实际可达比例」：把理论上限折算成可实现单量需要有来源的行业数据，而基准库当前为空，系统不会替你填一个折扣系数。因此这个数字只能当作不可逾越的天花板，不能当作可达成的目标。
要判断所需利用率是否现实，请实地计数同商圈同类店在同一时段的实际翻台情况，然后自行对照。
当前模型把业主人工按不计薪处理：业主的工时未计入 monthlyLaborExcludingOwner 的现金支出。这是一项被隐藏的成本假设——业主的时间不是免费的，若日后需要雇人替代，成本会立刻显现。
报告同时给出「业主计薪」口径（monthlyLaborIncludingOwner）。若在该口径下无法盈亏平衡，说明这门生意实际上是在消耗业主的无偿劳动。
以下岗位的时薪低于法定最低工资（18.25 加元/小时）：prep、cashier。这不是数据缺口，是一个结论：按现在填写的时薪，这份计划不合法，且本模型据此算出的人力成本被低估——下游的贡献毛利、盈亏平衡所需单量因此都偏乐观。把这些岗位的时薪改到不低于法定最低工资，本模型才反映一份合法、成本真实的计划。
当前所有会影响所需日订单量的输入都已确认，没有可供收窄的估计区间。
优先级：now 类型：update_financial_model
优先级：before_lease 类型：update_financial_model
| 数字 | 值 | 出处 |
|---|---|---|
| 月基础租金 | 3000 | 由 areaSqft + baseRentPsfAnnual 推导 |
| 月占用成本（毛） | 4800 | 由 monthlyRentOnly + utilitiesMonthly 推导 |
| 启动成本合计 | 171600 | 由 subtotal + contingencyAmount 推导 |
| 开业时剩余现金 | 82000 | 由 budget + preOpeningOutlay 推导 |
| 所需日订单量 | 71.83 | 由 breakEvenOrdersMonthly + openDaysPerMonth 推导 |
| 理论日订单上限 | 371 | 由 seatedTotal + takeoutTotal 推导 |
区间算术说明：本系统对相关变量采用保守的区间传播 —— 每一步运算只取端点的最坏组合，不做统计意义上的合成，因此区间宽度不是概率意义上的置信区间。这一方向是刻意选择的 —— 宁可显得不确定，也不给出虚假的精确。