pub fn phase_verification_mtime_nanos(
evidence_root: &Path,
phase: PhaseId,
) -> Option<u64>Expand description
The mtime of the same {phase:02}-VERIFICATION.md
phase_verification_fingerprint hashes, in nanoseconds since the Unix
epoch, or None when no such artifact exists under evidence_root.
WR-06 (35-REVIEW): the second input the freshness rule needs. A content fingerprint cannot see an IDEMPOTENT rewrite — a Validate agent that re-authors byte-identical content on a later cycle produces the same hash as an artifact nobody touched — so a hash-only rule classifies its own agent’s work as inherited and re-runs every plan in the phase from then on. An inherited file’s mtime does not advance during a run; a rewritten one’s does, whatever the bytes say.
Resolved through the same [phase_verification_path] and returning None
on the same “no artifact” condition, so the two readings can never disagree
about whether the artifact exists.
This is not provenance either. Any writer advances an mtime, so the limitation the fingerprint’s doc comment records — a mid-run branch switch or an operator edit reading as authored-this-run — is not closed by this and is marginally widened by it: a checkout restoring byte-identical content used to read as inherited and now reads as authored. That is accepted deliberately, because the case it fixes (a deterministic verification writer on cycle 2 of an unresolved gap) is ordinary rather than exotic.