staleness-gate-catches-all-drift
IN derived (depth 2)
The staleness CI gate detects all forms of source material drift without false negatives.
Summary
The CI pipeline's staleness check is claimed to never miss cases where source material has changed underneath a belief — if something drifted, the gate will catch it and fail the build. This is a strong correctness guarantee that, if true, means teams can trust the gate as a complete safety net rather than needing additional manual checks for outdated beliefs.
Justifications
SL — The conservative read-only checking with CI exit codes provides strong detection, but silently skipping deleted source files and 64-bit hash collision risk create blind spots
Antecedents (all must be IN):
- staleness-is-conservative-ci-gate — Staleness checking is designed as a safe CI gate: it never mutates state, only checks IN nodes, requires both source fields, and exits nonzero to fail the pipeline
Unless (any of these IN defeats this justification):
- missing-source-file-is-silent — If a node's source file no longer exists on disk, `check_stale` silently skips it; callers cannot distinguish "file deleted" from "file never tracked."
- hash-truncation-is-16-hex — Source hashes are SHA-256 truncated to the first 16 hex characters (64 bits), reducing collision resistance to ~32 bits for birthday attacks compared to the full 256-bit hash.
Dependents
These beliefs depend on this one:
- automated-sync-achieves-full-lifecycle-coverage — Automated repeated sync safely reconciles external beliefs with complete lifecycle coverage including full source staleness detection — idempotent cascade-preserving sync combined with conservative staleness gating ensures no lifecycle gap between sync runs.
- belief-currency-is-actively-managed — The system actively manages belief currency bidirectionally: the production-ready derive pipeline safely introduces new beliefs through defensive validation, while the staleness CI gate detects drift in existing beliefs against source material — together preventing both unsafe additions and undetected obsolescence.
- lifecycle-management-is-gapless — The system manages belief lifecycle without gaps across all operation types: staleness checking detects all forms of source drift, propagation respects node lifecycle states, and both read and write paths enforce consistent lifecycle semantics — no operation ignores or corrupts lifecycle state.
- source-integrity-spans-hashing-through-detection — Source integrity forms a complete end-to-end pipeline with no gap between measurement and verification: collision-resistant SHA-256 hashing with additive backfill computes integrity markers without overwriting existing hashes, while comprehensive staleness detection with CI gating and nonzero exit codes consumes those markers to catch all source drift.