source-tracking-is-collision-resistant-and-safe
IN derived (depth 1)
Source integrity tracking uses full 64-character SHA-256 digests with exact string comparison for collision resistance, and backfills hashes additively without overwriting existing values — ensuring high-fidelity drift detection with no accidental data loss
Summary
The system's source-tracking mechanism is built on a solid foundation: it uses full-length SHA-256 hashes for comparing file contents, and when it backfills missing hashes it never overwrites values that already exist. This means drift detection between source files and wiki content is both highly reliable (no collision risk from truncated hashes) and safe to run repeatedly without accidentally losing track of what was already recorded.
Justifications
SL — Three independent hash properties combine into a single integrity claim — collision resistance (full digests), comparison fidelity (exact match), and operational safety (additive-only backfill) are three axes of the same concern
Antecedents (all must be IN):
- hash-file-full-sha256 — `hash_file` returns a full 64-character hex SHA-256 digest (per the fix in PR #40 that removed the earlier `[:16]` truncation).
- staleness-uses-full-sha256 — Staleness detection compares full 64-character SHA-256 hex digests via exact string equality, not truncated prefixes or fuzzy comparison.
- hash-sources-is-additive-by-default — `hash_sources` without `force=True` never overwrites an existing non-empty `source_hash`; it only backfills nodes with empty or missing hashes.
Dependents
These beliefs depend on this one:
- 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.