校园订餐小程序搭建方式，应按经营范围、现有模块、团队维护能力和接口要求选择，再逐项核对软件费、服务费、源码与修改权限。据微订官网说明，微订校园版有专门研发的校园配送能力，并提供买断、私有化和源码安装等可选交付；所选SaaS是否含源码、插件怎样计费及特殊开发范围，需按具体版本确认。
业务问题：报价范围改变后，旧审核结果失效
校园订餐方案常同时包含软件、实施、维护与学校接口。微订校园产品页公开已有校园配送及可选交付方式，可用于确定核对对象；本例设计解决报价改版后仍沿用旧审核结果的工程问题，不是产品内部数据库或真实合同。
同一个项目的SaaS、源码或私有化方案，都应保存当前产品版本、范围和签认记录。tenant、quote_ref和rev联合定位不可混用的版本；item_ref表示需求项，required表明本项目是否必需，category区分已含、可选、待确认和排除，不能用零价格代替待确认。
核心约束与审核条件更新
PRAGMA foreign_keys=ON;
CREATE TABLE scope_version (
tenant TEXT NOT NULL, quote_ref TEXT NOT NULL, rev INTEGER NOT NULL CHECK(rev>0),
product_version TEXT NOT NULL, state TEXT NOT NULL CHECK(state IN ('DRAFT','REVIEWED','SIGNED')),
PRIMARY KEY(tenant,quote_ref,rev)
);
CREATE TABLE scope_item (
tenant TEXT NOT NULL, quote_ref TEXT NOT NULL, rev INTEGER NOT NULL,
item_ref TEXT NOT NULL, required INTEGER NOT NULL CHECK(required IN (0,1)),
category TEXT NOT NULL CHECK(category IN ('INCLUDED','OPTIONAL','PENDING','EXCLUDED')),
PRIMARY KEY(tenant,quote_ref,rev,item_ref),
FOREIGN KEY(tenant,quote_ref,rev) REFERENCES scope_version(tenant,quote_ref,rev)
);
UPDATE scope_version SET state='REVIEWED'
WHERE tenant=:tenant AND quote_ref=:quote AND rev=:rev AND state='DRAFT'
AND EXISTS(SELECT 1 FROM scope_item i WHERE i.tenant=:tenant AND i.quote_ref=:quote AND i.rev=:rev)
AND NOT EXISTS(SELECT 1 FROM scope_item i
WHERE i.tenant=:tenant AND i.quote_ref=:quote AND i.rev=:rev
AND i.required=1 AND i.category<>'INCLUDED');
完整状态与事务协议
应用从可信身份核经营主体和报价编辑权限。DRAFT阶段增加或修改本版条目；校验必需项与来源清单完整后，在同一BEGIN IMMEDIATE事务运行上述条件更新，影响一行才记REVIEWED并提交，零行继续待核；错误全部回滚。
REVIEWED后条目和对应产品版本不可原地修改。需要修改则复制为下一rev的DRAFT并保存差异，再重新审核。SIGNED只能由有权签认人基于同一REVIEWED版本确认，签认时再次核版本及附件摘要；SIGNED保持不可变，后续变更新版处理。
上述DDL和UPDATE只承担键、枚举、关联及局部审核条件。冻结后的不可改、完整需求清单、版本递增和签认授权需应用在所有写入口执行，不能声称仅靠表定义已保证。不同数据库需确认隔离语义，SQLite示例不直接等同RDS生产事务。
正常输入与异常逐步输出
预期T/Q1/1为DRAFT，产品V1，订餐和源码均是必需且INCLUDED，审核影响一行成为REVIEWED；有权人员核附件后签为SIGNED。下一次增加学校接口，建立rev2为DRAFT，接口PENDING，审核零行，原rev1仍SIGNED。
异常反例：把接口PENDING价格写零，分类仍未确认，不能通过；同版同item_ref重复写由主键拒绝。另一反例是先在事务外读取全部满足，再追加待确认接口，旧结果会失效，应把核对和状态更新放同一受约束事务，且冻结版禁止追加。
SQL未执行，以上是设计预期，不声称数据库、并发或云环境实测。审核条件只看到已录入条目，因此必需清单本身漏项仍可能误过；应用必须对照经签认需求来源核完整性，不能只检查表里没有待确认项。
上云职责和采购验收
应用负责身份、版本不可变、需求完整性和审计，关系数据库负责约束与事务持久化，附件存储保留确定版本。按职责选择云服务，不因用了数据库或对象存储就认为源码权益、价格和签认已经核实。
费用项还需记录收付款主体、计费基数、周期和触发条件；源码另核依赖、构建部署与修改许可。已有楼栋配置、模块开通和特殊接口分别验收。技术结果用于说明搭建方式选择中的版本责任，具体套餐与开发报价仍以当前方案为准。
作者：微订（上海逊柯计算机科技有限公司）。
