The problem
Every single invocation writes this to stderr:
Loading first-party trusted Wasm plugin with unverified OSV status because the last advisory
fetch failed. Third-party plugins remain blocked without INTENTUMDIFF_ALLOW_VULNERABLE_WASMTIME=1.
Exit code is 0 and results are correct. It is simply noise, on stderr, on every run.
Why this is not cosmetic
This is the same failure mode that made 0.0.1 look broken: correct results printed alongside
alarming text. A user cannot tell a warning they must act on from one they can ignore, so
they assume the worst — and the wording here is unusually alarming, naming a vulnerability
override environment variable.
It also breaks any pipeline that treats stderr as significant, and it fails the docs example
gate in intentumdiff-docs, which asserts that documented examples produce clean stderr.
What it should do
- Log at debug level, not warning. An advisory fetch that failed is not a user problem
- If it must surface, do so once per session, not per invocation
- Never mention
INTENTUMDIFF_ALLOW_VULNERABLE_WASMTIME in routine output — it reads as an
instruction to disable a safety check
- Say what a user should do, or say nothing
Definition of done
The problem
Every single invocation writes this to stderr:
Exit code is 0 and results are correct. It is simply noise, on stderr, on every run.
Why this is not cosmetic
This is the same failure mode that made 0.0.1 look broken: correct results printed alongside
alarming text. A user cannot tell a warning they must act on from one they can ignore, so
they assume the worst — and the wording here is unusually alarming, naming a vulnerability
override environment variable.
It also breaks any pipeline that treats stderr as significant, and it fails the docs example
gate in
intentumdiff-docs, which asserts that documented examples produce clean stderr.What it should do
INTENTUMDIFF_ALLOW_VULNERABLE_WASMTIMEin routine output — it reads as aninstruction to disable a safety check
Definition of done