Watch a review go stale

This is the idea the whole tool is built upon: a review expires when the code it described no longer exists.

Where you are

One reviewed unit, and nothing stale:

$ vidi status
NEUTRAL: 1/5456 reviewed · stale 0 · orphans 0 · requirement failures 0 · default shortfalls 0

Change the code you vouched for

Open crates/vidi-core/src/digest.rs and edit line 55 — the unit you approved:

#![allow(unused)]
fn main() {
pub struct Blake3Digest([u8; 16]);    // before
pub struct Blake3Digest([u8; 32]);    // after
}

Save the file.

Run status again

$ vidi status
FAILURE: 0/5456 reviewed · stale 1 · orphans 0 · requirement failures 0 · default shortfalls 0

Three things changed on their own:

• 1/5456 → 0/5456 — the unit is no longer covered
• stale 0 → stale 1 — and vidi knows why it is uncovered
• NEUTRAL → FAILURE — the gate now fails

Vidi recomputed the unit’s fingerprint, compared it to the one stored in your review, and they no longer matched, leading it to go stale.

fingerprint stored in the vouch    76b53b0c9cfd57d07d2a4802263e6856
fingerprint of the code now        (different, so the bytes changed)
                                   ─────────────────────────────────
                                   this review no longer describes
                                   the code that is there

The gate agrees

$ vidi verify
FAIL: stale 1 · orphans 0 · requirement failures 0 · default shortfalls 0 · rejected ledger lines 0
  ▲ stale      crates/vidi-core/src/digest.rs::struct:Blake3Digest

verify exits non-zero, which is what blocks a merge in CI. It also names the exact unit, so nobody has to guess what went wrong.

This happened with no policy file. Staleness is not a rule you configure, it is an integrity property. A review claiming to cover bytes that no longer exist is broken regardless of your policy, so it fails even in an unconfigured repo. That is why the verdict is FAILURE rather than NEUTRAL.

Put it back

#![allow(unused)]
fn main() {
pub struct Blake3Digest([u8; 16]);
}

$ vidi status
NEUTRAL: 1/5456 reviewed · stale 0 · orphans 0 · requirement failures 0 · default shortfalls 0

Restoring the original bytes restores the original fingerprint.

Why this matters

A normal pull-request approval says “Ada approved this change” and stays true forever, even after the code is rewritten. It ages into a lie that nothing detects.

A vouch says “Ada read exactly these bytes”, and the moment those bytes change the claim stops applying. Every other reviewed unit in the file is untouched.

That is the entire design. Everything else: addressing, the ledger, the policy, all exist to make this one comparison possible.

Next

Turn on the gate