check-stale-output-is-deterministic-and-structured
IN derived (depth 1)
Staleness checking produces deterministic (sorted by node ID), uniformly structured (consistent 6-key schema across all result types), and exception-free (returns structured dicts for missing files rather than raising) output suitable for programmatic consumption and diffing.
Summary
The staleness checker is designed to be fully predictable and safe for automation. Its output is always sorted the same way, uses the same fields regardless of what changed, and gracefully handles missing files instead of crashing, so any code consuming its results can rely on a stable contract without special-case handling.
Justifications
SL — Three output-shape guarantees unify into a programmatic consumption contract
Antecedents (all must be IN):
- check-stale-results-sorted-by-node-id — The list returned by `check_stale` is sorted ascending by `node_id`, providing deterministic output for consumers.
- check-stale-result-schema-uniform — All `check_stale` result dicts share the same 6-key schema (`node_id`, `old_hash`, `new_hash`, `source`, `source_path`, `reason`) regardless of reason type, so consumers can iterate results without type-checking.
- check-stale-never-raises-on-missing-files — `check_stale()` returns a structured `source_deleted` dict for nodes whose source files don't exist on disk; it never raises `FileNotFoundError` or any exception.
Dependents
These beliefs depend on this one:
- inspection-outputs-are-uniformly-normalized — Both inspection mechanisms — belief review and staleness checking — produce normalized, schema-consistent, fail-safe output with deterministic structure suitable for automated consumption.
- staleness-output-is-ci-pipeline-ready — Staleness checking produces deterministic, uniformly-structured, machine-parseable output with conservative non-mutating semantics and nonzero exit codes, making it directly consumable by automated CI pipelines without wrapper scripts