Overview
OrchardCore mattered because it is a real .NET repo, not a toy starter.
Even a narrow slice of the repo carries several differ...
For further actions, you may consider blocking this person and/or reporting abuse
Making restore first-class is the move, and it quietly names two inputs at once that fail differently. The command names the dependency, which packages, but the restore's flakiness usually lives in the other one, the feed it reaches at run time. Same restore, same lockfile, green on Tuesday and red on Thursday because the feed moved or went slow, not because anything in the repo changed. So the honest version of dependency_hydration declares the feed posture too, which feed, pinned to what, offline or online, not just the verb, because that is where the non-determinism actually hides.
And the narrow proof is only as honest as where its boundary lives. You scoped out the functional lanes and the db paths in the writeup, but a downstream agent reads the contract, not the blog. The honest-narrow-net holds only if the contract carries its own "here is what I did not prove" as a first-class field, so the boundary travels with the artifact. Otherwise the scope is honest today and silently over-read tomorrow. Bounded honesty is exactly right, make the bound machine-readable too.
You are right that restore is really two truths at once: the dependency verb and the feed posture behind it. If the contract only names the verb, it still hides a big part of where nondeterminism lives.
Same with narrow proof. The scope should not only live in the writeup. If the proof is intentionally bounded, that boundary should travel with the contract and artifact in machine-readable form so it cannot be over-read later.
I’m going to add both of those to Ota.
If you had to choose, which would be more valuable first in practice: feed posture on hydration, or machine-readable proof boundaries on narrow runtime lanes?
Proof boundaries first, and the tiebreaker is failure mode. A restore that flakes because the feed moved fails loud: the lane goes red, someone reruns it, time is lost, nobody is deceived. A narrow proof without its boundary fails silent: it stays green while a downstream reader acts on a guarantee it never made. Loud failures cost minutes, silent ones cost correctness, and a proof tool's credibility survives flakiness far better than it survives one over-read proof.
It is also the smaller lift with the bigger contract change: a first-class "not proven" field on the artifact, plus the rule that consumers must read it, can ship almost immediately, while feed posture reaches into how restore executes and deserves to be done properly. So boundary first to make the claims safe, feed posture second to make the runs quiet. Glad to hear both are landing in Ota.
That makes a lot of sense.
Proof boundaries first is the right call. A flaky restore fails loud, but a green proof that gets over-read fails silent, and that is the worst trust failure.
The “claims safe first, runs quiet second” framing is very useful. I’m going to use that ordering in Ota too.
If Ota added a first-class
not_provenboundary, what would you want it to name first, so a downstream reader cannot over-read the proof: skipped lanes, unproven dependencies, unproven external state, or something else?I'd order it by how invisible the gap is to someone reading only the top line, not by category.
Skipped lanes I'd name last, not first. A skip is already loud, it announces itself. The reader can see "we didn't run this." That's the honest kind of gap.
The dangerous one, the true silent failure, is what the green rested ON without exercising. Unproven external state first, unproven dependencies right after. A restore that passes against synthetic state and breaks against real prod state is the textbook case: the proof never touched the state that actually matters, so nothing in the green warns the reader. That is the over-read that costs you.
So my
not_provenorder would be:One more thing: whatever
not_provennames has to be non-collapsible. If the top-line PASS can swallow it, it gets over-read again. The boundary has to travel attached to the proof, not sit in a footnote the reader skips. "proven, assuming X" with X always in frame beats "proven" with an asterisk.Very insightful. That is the distinction Ota needs. A skipped lane is visible; the dangerous boundary is what a green proof assumed without exercising. I’m refining Ota’s proof model around that order: external state first, dependencies next, skipped lanes last, with the boundary carried in the top-level proof verdict rather than buried under a green result.
When a proof depends on a neighbouring service or dependency, what evidence would make you trust that it was actually exercised rather than merely reachable?