quarantine_finding is documented as the safety net that does not trust
the frontend:
Nothing here trusts a verdict the frontend claims — quarantine_finding
re-classifies, and the restore/purge commands only ever touch paths the
manifest in that directory says Diskern put there itself.
The re-check is a rules lookup and nothing else:
let (_, verdict, _) = RulesDb::embedded().classify(&path);
if matches!(verdict, Verdict::Protected | Verdict::Risky) { ... }
That is the rule's base verdict. The verdict the report shows is the
base verdict after risk::downgrade has applied the impact graph, and the
whole point of #48 was that those two differ. So the command disagrees
with the report exactly where the graph is doing its job.
Scanning a live npm project — package.json beside its node_modules —
and then running what the command runs:
report verdict : Risky
report reasons : ["matched rule node-modules: ...", "referenced by 1 project", ...]
report reclaimable : 0
command re-check : Review
command would refuse: false
actions::quarantine : MOVED to .../quarantine/1788716271__tmp_..._node_modules_react_index.js
The file moved. actions::quarantine refuses Risky, but it is handed
Review, so its own guard never fires either — the caller decides the
verdict, which is the thing this design says never happens.
Not reachable from the shipped UI: FindingRow renders no button for a
risky row, so the command is never invoked with one today. That makes
this a layer that is documented, believed, and not there — the layer that
is supposed to catch a UI bug, a stale report row, or a second frontend.
The fix has to get graph evidence into the command. The cheap version is
to keep the referenced-project count from the scan that produced the
report and consult it here; the honest version is for the command to take
the finding's verdict from the report the backend itself produced rather
than re-deriving a weaker one. Either way docs/ARCHITECTURE.md and the
app README describe the result.
app/src-tauri/src/commands.rs:201 · crates/diskern-core/src/risk.rs:45
quarantine_findingis documented as the safety net that does not trustthe frontend:
The re-check is a rules lookup and nothing else:
That is the rule's base verdict. The verdict the report shows is the
base verdict after
risk::downgradehas applied the impact graph, and thewhole point of #48 was that those two differ. So the command disagrees
with the report exactly where the graph is doing its job.
Scanning a live npm project —
package.jsonbeside itsnode_modules—and then running what the command runs:
The file moved.
actions::quarantinerefusesRisky, but it is handedReview, so its own guard never fires either — the caller decides theverdict, which is the thing this design says never happens.
Not reachable from the shipped UI:
FindingRowrenders no button for arisky row, so the command is never invoked with one today. That makes
this a layer that is documented, believed, and not there — the layer that
is supposed to catch a UI bug, a stale report row, or a second frontend.
The fix has to get graph evidence into the command. The cheap version is
to keep the referenced-project count from the scan that produced the
report and consult it here; the honest version is for the command to take
the finding's verdict from the report the backend itself produced rather
than re-deriving a weaker one. Either way
docs/ARCHITECTURE.mdand theapp README describe the result.
app/src-tauri/src/commands.rs:201·crates/diskern-core/src/risk.rs:45