Struct Probing 

pub struct Probing<'a> {
    pub python: &'a Path,
    pub probe: &'a Path,
    pub build: &'a str,
    pub store: Option<&'a Path>,
    pub given: Option<&'a Path>,
    pub recipe: Digest,
}

Everything a probe needs that is the same for every commit it is asked about. Held together so a call says only what varies: the checkout.

Fields

python: &'a Path

probe: &'a Path

build: &'a str

store: Option<&'a Path>

Handed to the probe so it can say what is already computed. Not the store snapshots are remembered in, though it is usually the same one.

given: Option<&'a Path>

recipe: Digest

What identifies this probing, everything but the commit: the build, the input, and the probe’s own source.

That last is not belt and braces. A snapshot is a pure function of a commit only given a fixed probe, so the day declared learned to read an object’s attributes, every snapshot taken before it became wrong — in exactly the way this tool exists to catch.

Implementations

impl Probing<'_>

pub fn named(&self, commit: &str) -> String

The name this checkout’s snapshot is kept under. Content-addressed and immutable: a commit does not change, so neither does the answer.

pub fn recalled(&self, kept: &dyn Store, commit: &str) -> Option<Snapshot>

What was already probed for this commit, without touching a checkout.

Its own method because a walk asks this of every commit first and only then lays out the ones nobody has an answer for. On a line of exploration that has been looked at once, that is no worktrees at all.

pub fn remembered( &self, kept: &dyn Store, working: &Path, commit: &str, ) -> Result<Snapshot, Trouble>

The snapshot for this checkout, from the store if it is there.

A store that cannot answer is not the end of it, exactly as a keeper that cannot answer is not the end of a run: the probe is asked instead and the trouble is said out loud. A cache gone cold is slow; a cache that stops the tool is broken.

pub fn compared( &self, taken: &HashMap<&str, Snapshot>, pairs: &[(String, String)], ) -> Result<Vec<Findings>, Trouble>

What the edit did, for each of these pairs of (older, newer).

Pairs and not an ordered list, because a step is an edge: two entries next to each other in a walk of three branches are two different lines of exploration, and comparing them would answer confidently about an edit nobody made.

One subprocess for the whole walk — comparing needs no checkout and no graph, only the model and the snapshots. The model is somatize.foreseen’s and nothing here decides what a finding means.

pub fn checked(&self, working: &Path, node: &str) -> Result<Value, Trouble>

Whether an edit survives: it parses, a linter is quiet, the graph still builds, and the node runs on what its predecessors left in the store.

Asked in a checkout that is the same tree a fork would commit, so a green light is about the thing that would land and not about something near it.

pub fn prettified(&self, source: &str) -> Result<Value, Trouble>

The same source, formatted — or the same source back and a reason.

ruff format if this environment has one. Refused rather than half-done when it does not: handing back something that looks formatted and is not is worse than a button that says it cannot.

pub fn taken( &self, working: &Path, commit: &str, ) -> Result<(Snapshot, Vec<u8>), Trouble>

Runs the probe in a checkout and reads what it wrote, with the bytes it wrote — which are what gets kept.

A subprocess and not a library call, and it is why this tool has two languages in it: the graph only exists once the checkout’s own code has been imported and run, against the soma that checkout pins. Reaching into it from here would run one version of the engine over another version’s declarations.