用途：当无效数据深入执行链路导致失败时，采用纵深校验（Defense-in-Depth），在数据流经的每一层都加入验证，而不是只在单一位置修复，从而让 Bug 在结构上不可能出现。
主要能力：资料将校验划分为四层。第一层入口校验，在 API 边界拒绝明显无效的输入，例如检查 workingDirectory 非空、存在且为目录。第二层业务逻辑校验，确保数据对该操作有意义，例如 WorkspaceManager 初始化时要求 projectDir 非空。第三层环境守卫，防止在特定上下文执行危险操作，例如测试环境下拒绝在临时目录之外执行 git init。第四层调试埋点，在执行前记录目录、工作目录与堆栈，用于取证分析。
使用方式：发现 Bug 后先追踪数据流，找出坏值来源与使用位置；再列出数据流经的全部检查点；然后按入口、业务、环境、调试四层补充校验；最后逐层测试，尝试绕过第一层并验证后续层能捕获。资料给出的案例是：空 projectDir 导致在源码目录执行 git init，于是在 Project.create()、WorkspaceManager、WorktreeManager 与 git init 前日志四处加入校验，最终 1847 个测试全部通过。
适用场景：需要防止不同代码路径、重构或 mock 绕过单点校验的场景，尤其是涉及文件系统等危险操作的初始化流程。
限制：资料指出四层都必要，因为不同层能捕获不同情况，如其他代码路径绕过入口校验、mock 绕过业务逻辑检查、跨平台边界需要环境守卫、调试日志识别结构性误用。具体项目中的层数、检查内容与平台差异暂未提供，需按实际数据流设计。