staleness-checking-is-comprehensive
IN derived (depth 1)
Staleness checking detects all nodes whose source material has changed on disk
Summary
The system can reliably detect when any tracked claim has fallen out of date because its underlying source file changed. This works as a safety net in automated pipelines — it exits with an error code when staleness is found, so CI or pre-commit hooks can block progress until beliefs are refreshed from their current sources.
Justifications
SL — Completeness breaks when a source file is deleted — the node silently passes instead of being flagged, creating a false-negative gap
Antecedents (all must be IN):
- check-stale-requires-both-source-fields — A node must have both `source` (non-empty) and `source_hash` (non-empty) to be eligible for staleness checking; nodes missing either field are silently skipped.
- check-stale-exits-nonzero — `cmd_check_stale` calls `sys.exit(1)` when any stale nodes are found, making it usable as a CI or pre-commit gate.
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."
Dependents
These beliefs depend on this one:
- external-interface-is-bidirectionally-bounded — The system's interaction with external systems is bounded in both directions: output is budget-limited through accurate token estimation ensuring context windows are respected, and input drift is comprehensively detected through staleness checking — no unbounded data flows cross the system boundary.
- read-and-write-paths-are-both-reliable — Both the read path (staleness checking detects all forms of source drift without false negatives) and the write path (truth propagation completes without runtime errors across all reachable nodes) are operationally reliable, ensuring the system functions correctly in both observational and mutational modes.