feat: verify S188 @ufct bounty — NO verdict, duplicate of S172 (#521)

[xliry]

Issue: #204
Submission: #204 (comment)
Author: @ufct

Problem (in our own words)

The submission claims _DetectorNamesCacheCompat in cli.py is dead production code — a full dict-interface class (__contains__, __getitem__, __setitem__, pop) maintained solely so legacy tests can write to and read from a _DETECTOR_NAMES_CACHE global. Production caching uses @lru_cache on _get_detector_names_cached() and never reads from _DETECTOR_NAMES_CACHE.

Evidence

Verified at commit 6eb2065:

• cli.py:28-45 — _DetectorNamesCacheCompat defines 4 dict-like methods.
• cli.py:47 — _DETECTOR_NAMES_CACHE = _DetectorNamesCacheCompat().
• cli.py:50-52 — Real cache: @lru_cache(maxsize=1) on _get_detector_names_cached().
• cli.py:55-57 — _get_detector_names() calls _get_detector_names_cached(), never reads _DETECTOR_NAMES_CACHE.
• cli.py:64 — Only production usage: .pop("names", None) — clearing unused state during invalidation.
• tests/commands/test_cli.py:520,530 — Only actual consumers: test writes and asserts on _DETECTOR_NAMES_CACHE.

Finding is factually correct, but S172 (@allornothingai, 2026-03-05T16:13:28Z) reported the identical issue ~4 hours earlier.

Fix

No fix needed — verdict is NO (duplicate).

Verdict

Question	Answer	Reasoning
Is this poor engineering?	YES	Dead production code maintained solely for test compatibility is a valid slop pattern
Is this at least somewhat significant?	YES	Constrains refactoring of the detector registry to preserve a test-only interface

Final verdict: NO — duplicate of S172

Scores

Criterion	Score
Significance	5/10
Originality	0/10
Core Impact	4/10
Overall	0/10

Summary

The finding is valid — _DetectorNamesCacheCompat is genuinely dead production code never read in any production path, existing only so tests can poke internals. However, S172 (@allornothingai) identified the exact same class, same files, and same issue ~4 hours earlier. S179 (@willtester007-web) and S220 (@g5n-dev) also cover this. Verdict is NO due to duplicate.

Why Desloppify Missed This

• What should catch: A dead-code or unused-symbol detector scanning production call graphs
• Why not caught: Desloppify's current detectors focus on code smells and patterns, not production-vs-test reachability analysis
• What could catch: A call-graph-based dead code detector that distinguishes test-only usage from production paths

Verdict Files

• Verdict JSON
• Verdict Report

Generated with Lota