Function consecutive_failures_made_progress 

pub fn consecutive_failures_made_progress(
    previous: Option<u32>,
    current: u32,
) -> bool

Whether a Validate failure represents forward progress since the last recorded failure (999.66, D-03) — i.e. whether Code produced new commits on the phase’s feature branch since crate::state::State::last_validate_failure_commit_count was last observed.

previous is the baseline recorded at the prior failure; current is the commit count observed at THIS failure.

None for previous reports progress: it means no prior failure has been recorded, so there is no streak to continue — the first failure of a phase, and the first failure observed after resuming state written before this baseline field existed, must both begin a fresh streak rather than extend a nonexistent one.

The comparison is strictly greater, not merely not-equal: a count that went DOWN means the branch was rewound or rebuilt, which is not evidence that the problem Validate reported was addressed. Treating a decrease as progress would hand a free counter reset to exactly the situation least likely to deserve one.

What this predicate does not establish. A true result means new commits exist, not that those commits addressed anything. An agent that commits something trivial on every cycle resets the streak every cycle and never reaches MAX_CONSECUTIVE_FAILURES. This is the accepted, documented weakness of the commit-count signal recorded in 33-RESEARCH.md’s D-03 Recommendation and Assumptions Log A1 — the same weakness evaluate_layer2’s own “no work done” gate already carries, which a single trivial commit also already defeats today. It is a real narrowing of the guarantee that MAX_CONSECUTIVE_FAILURES bounds a genuinely stuck loop, and it is deliberately NOT strengthened here with a lines-changed or files-touched threshold — that is a follow-up if the assumption proves wrong, not a speculative heuristic to add to the safety gate’s path now.