服务端检查
185 / 185
在本次核验的 v1.1 证据快照中全部通过。
DispatchGuard - 现场调度可靠性
DispatchGuard 是一个完整的现场调度案例，设计时先从 QA 风险出发。我没有只做顺利流程，而是优先处理真正容易破坏调度工作的情况：并发派单、过期的离线操作、资质规则、重试和时区边界。
已完成 v1.0 已完成 · v1.1 加固已验证 源码私有 · 架构与验证证据在此公开
- TypeScript
- PostgreSQL
- Playwright
- 离线同步
- 并发控制
- RCA / ADR
浏览器证据
23 项通过
此外，5 个 Playwright 项目中有 72 项检查按设计跳过，每一项都记录了具体原因。
决策记录
6 份 ADR · 4 份 RCA
架构取舍和问题复现都能顺着记录回看。
部署边界
仅限 tailnet
最小可运行的 OCI 部署已在私有网络验证，不会包装成公开生产服务。
为什么做这个项目
只演示顺利流程，很容易让调度软件显得过于简单。两名用户可能几乎同时分配同一位技术人员，离线设备也可能在稍后把基于旧状态的操作重新提交回来。
我把这些失败路径放在设计中心，并把问题复现、设计决定、修复、回归测试和 RCA 串在一起。即使不公开仓库，审阅者也能理解推理过程。
关键工程与 QA 决策
在数据库层守住约束
重叠分配由并发写入真正汇合的地方负责拦截，而不是依赖随时可能过期的页面可用状态。
把离线重放写清楚
幂等键、重试规则和明确的冲突结果，避免设备重连后悄悄重复或覆盖操作。
测试真实的本地日历边界
除资质和分配规则外，测试还覆盖新西兰夏令时切换，避免日期时间假设渗进业务逻辑。
可以讲解的证据
仓库保持私有，但对项目的展示不会只剩一张截图和一串工具名称。
- 4 类并发缺陷修复前失败、修复后通过的对照证据
- 关于一致性、同步和部署选择的架构决策记录
- 把症状、复现、修复和回归保护连起来的根因记录
- 将实际执行项与按原因主动跳过项分开的 Playwright 结果
这个案例不声称什么
这些边界是案例的一部分，不是事后补上的免责声明。
- 公司、现场数据和新西兰电气服务场景均为合成内容，不代表 EWRB 或行业背书。
- 部署记录仅限私有 tailnet；没有公开生产服务或真实客户使用声明。
- 会话认证适合当前案例范围，但不会被描述成生产级身份基础设施。
- Playwright WebKit 证据不能替代尚未完成的真机 Safari 测试矩阵。
源码私有，工作可核验
在真实招聘流程中，我可以讲解架构、RCA 和测试证据，不需要把仓库公开。