Function phase_has_blocking_human_checkpoint 

pub fn phase_has_blocking_human_checkpoint(
    project_root: &Path,
    phase: PhaseId,
) -> bool

Return true if any plan declared for phase carries a task with the human-blocking checkpoint gate attribute.

Reads declared plan content only — never any runtime capture or agent output (D-02: no re-implementation of “what does the agent mean”). This is the PRIMARY gate for the auto-decide path added in plan 28-03: an agent cannot route itself into that path for a phase whose plans never declared a gate="blocking-human" checkpoint, because this scan runs first and is read from .planning/phases/. Those files are agent-writable during Code, but that is the SAME trust boundary external_verify_commands already documents and accepts — reused, not newly introduced.

The CALLER is responsible for passing the root the phase’s plans actually live under — the execution root (the worktree) in worktree mode, the project root otherwise. .planning/ is tracked content, so an in-flight phase’s {N}-PLAN.md sits on feature/phase-{N} inside the worktree and is absent from the main checkout; a caller passing the main checkout gets a silent false rather than an error (999.76, ROADMAP criterion 6). The caller that does this correctly is pipeline_launch.rs’s Action::GateReview arm, which resolves state.worktree_path first.