用途：这是规划侧的单一仓库门禁，plan-feature 与 plan-fix 共用该契约，而非各自重复读取规范化仓库状态（NRS）并做架构分类。适用于任何可能写入规划产物的规划路由：plan-feature 的各类脚手架路由，以及 plan-fix 的修复 SPEC 草稿。组合内部件（plan-feature-from-issue、plan-feature-scaffold）通过路由器创建的当轮规划上下文复用同一结果，不重新运行发现或分类。
主要能力：采用两阶段契约解决矛盾——规划者需尽早只读读取 NRS 作为架构上下文，但最终架构分类只能在完整工程计划形成后进行。
第一阶段（规划中的轻量 NRS 读取）：计划构建期间可只读消费 NRS 获取架构上下文，只分类 NRS 端口，架构分类延后，记录为“Preflight: Stage 1 — NRS <consumed|n/a> · arch: deferred”，不阻塞产出。
第二阶段（计划切割后的最终分类）：完整工程计划存在后，每份计划只运行一次完整架构分类。查找文档映射中声明的可选项目不变量文档（通常为 docs/architecture/ARCHITECTURAL_INVARIANTS.md），若缺失则记 n/a 并通过。对每条适用规则，引用其 ID 与仓库证据，将计划变更分类为 preserves、violates、introduces 或 changes，仅 preserves 可进入产出。违规、新规则或变更规则须停下，交由项目声明的决策权限作出明确架构决定，不得转为工程任务或从 SPEC 推断批准。已有冻结 NRS 事实可用，但仓库检查仍具权威性。记录为“Preflight: NRS <consumed|n/a> · invariant classification: <...> (n/a when no invariants declared)”。
使用方式：第二阶段在工程计划完成之后、路由器产出产物之前立即运行，是决定能否产出的门禁。当已通过的计划因工程计划变更而重新验证时也须运行，此时只重跑可能受影响的规则。第 0 步：若 docs/workflow/REPOSITORY_STATE.md 存在，基于其冻结事实与决策规划；缺失事实可检查，冲突属解析器矛盾而非重写；计划工作与文档不是实现证据；账本状态为 draft、contradicted 或 resolved 时停止规划，先转发现或解决；无账本则直接检查仓库并记 n/a。
限制：每次计划仅一次分类，绝不按组合内部件分别执行。不得让 SPEC、通过的测试或路线图行推断决定。仅文档操作，无代码、分支或 forge 写入。第二阶段在产出决策上取代第一阶段。