04 — Scanner Reality Check (v_rp_scanner_automation_reality)

Question: do the scanners really run, or only look scheduled? Answer: the pipeline is REAL_AUTOMATION, proven by independent live evidence — but two provenance tables lie about it, and that lie is now surfaced.

Proof the scanner really ran (live)

• systemd: wf-universal-scanner.timer enabled/active; last fire 2026-06-05 04:10:01 CEST = 02:10 UTC; service exited 0/SUCCESS (54.9s CPU); next 2026-06-06 04:10.
• scan log scan-20260605T021001Z.log: adapters → map (dotbin 186, cron 7) → census_v2 → rp_v2 (universe 453 / host_unmanaged 80 / rp_assigned 0 / fs_orphan 143) → orphan_v2 (143) → adapter_health 16/16 → remediation 143 → registry flip UPDATE 6 → rc=0.
• DB evidence: wf_adapter_run_log max started_at 02:10:44; wf_orphan_remediation_queue.computed_at max 02:10:50; snapshot observed_at 02:10.

Classification (per component)

component	class	last proven run	age
orchestrator_pipeline	REAL_AUTOMATION	2026-06-05 02:10:44	6.5h
scanner_v2_functions	REAL_AUTOMATION	2026-06-05 02:10:50	6.5h
wf_scanner_run_log	STALE_PROVENANCE_NOT_WIRED	2026-06-04 09:53	22.8h
workflow_scanner_registry.freshness	STALE_PROVENANCE_NOT_WIRED	2026-06-04 10:25	22.2h
kb_sop_adapter	MANUAL_ONLY	2026-06-04 10:15	22.4h
wf_process_candidate_refresh	MANUAL_ONLY	2026-06-04 10:42	21.9h

The provenance lie (P1 finding)

The orchestrator runs the v2 functions and writes the digests/adapter-log, but it never inserts into wf_scanner_run_log and its "registry flip" updates only status — so workflow_scanner_registry.last_run_at and wf_scanner_run_log.run_at are frozen at the 06-04 manual proof runs. A naive UI reading those would report "last scanned 06-04" when the truth is 06-05 02:10. Rule enforced downstream: read scanner freshness from wf_adapter_run_log / orphan-queue computed_at, never from the run-log/registry. Fix is a small, reversible orchestrator edit — staged for operator/T1 (deferred this run to keep the scheduler untouched).