返回 TeachFlow 项目总览 · 交互图：工程 · 演进
项目早期曾出现一个典型假象：生产构建可以跳过 TypeScript 或 ESLint，于是“build 成功”掩盖了类型与规则错误。后来又出现另一类问题：数据库专项脚本本身向共享演示库写入测试提案和记忆，回归通过了，演示事实却被污染。
TeachFlow 因此不再寻找一个万能的“全绿命令”，而是让不同门禁回答不同问题。
每层检查只证明自己的范围
tsc --noEmit：类型合同能否独立成立；next lint：静态规则与 Hook 等约束；next build：生产打包与服务端/客户端边界；- focused contract checks：确定性内核、拒绝案例和幂等；
- database checks：迁移、事务、权限、恢复与投影；
- browser checks：真实加载、空态、失败、成功和窄屏交互；
- capacity/recovery：在明确数据与环境边界下测量延迟、吞吐和可恢复性。
任何一层都不能替另一层背书。HTTP 200 不证明 WebSocket 或后台 Worker，截图不证明数据库提交，合成 P95 不等于学校 SLA。
Golden Path 也必须与回归隔离
Golden Demo 使用同一课程、发布、学生作答、Current、图投影与教材引用贯穿固定演示链路；准备脚本只读检查关键状态，写链在临时数据库和临时服务中完成。测试产生的提案、图版本和记忆不能进入共享演示事实。
证据状态进入交付物
项目材料把结论标为 verified、code-confirmed、partial 或 blocked。这不是文档装饰，而是避免把历史回执、本地演示和生产结论混为一谈。本文也沿用相同的证据边界。
一个最小的假绿色案例
假设 next build 因配置跳过类型和 lint 后成功，浏览器首页也返回 200，但作业审核接口在真实 PostgreSQL 迁移后因缺列失败。三个信号中只有“构建产物被生成”和“首页路由可访问”成立；它们没有覆盖数据库 schema、角色权限或审核事务。若交付报告只写“构建通过”，读者便无法判断哪些用户流程仍可能失败。
另一个假绿色来自共享状态：专项脚本往演示数据库写入提案，第二次运行因为数据已存在而通过，实际幂等键或清理合同可能从未被验证。隔离数据库、固定 seed 和稳定输入哈希不仅为了测试整洁，而是为了让失败能够复现、让成功不依赖历史残留。
如何组织一次比例合适的验收
小型源码修改先跑独立类型、lint 和相关 focused check；涉及数据库合同再加隔离迁移与事务回归；涉及用户页面再检查真实浏览器的加载、空态、失败、成功与窄屏；只有待发布版本才运行一次有理由的完整门禁。容量、故障注入和长期 soak 必须对应未解决风险，不能为了“测试数量好看”无限扩张。
最终回执还要固定 Git commit、工作树脏状态、命令、数据集和环境。verified 必须能回答在哪里运行、验证了什么；没有这些信息的历史数字只能作为背景。
本轮实际复验
最近一次 npm run check:fast 执行了 tsc --noEmit 与 next lint，两者通过。production build、数据库合同和浏览器端到端检查需要分别运行。
当前边界
历史档案记录过 build、数据库恢复、Neo4j 重建、容器 readiness、浏览器与容量检查，但本文没有把旧数字冒充本轮执行。要升级对应结论，必须在当前 HEAD、固定数据和隔离环境重新运行。
结论
每层门禁都有独立的问题、输入和运行环境。出现失败时，先定位受影响的层，再补充对应验证，避免用一次构建结果代替整条教学工作流的检查。