feat: verify S217 @admccc bounty — YES_WITH_CAVEATS, registry coupling confirmed

[xliry]

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

Problem (in our own words)

The submission claims desloppify/base/registry.py is a "god object" that couples unrelated policy — display order, scoring dimensions, action types, LLM judgment routing, queue thresholds, and review invalidation — all in one DetectorMeta dataclass. It argues detector changes are no longer local because the registry is imported across engine, scoring, queueing, narrative, and CLI layers.

Evidence

• base/registry.py:45-56 — DetectorMeta frozen dataclass has 12 fields spanning identity, scoring, planning, queueing, LLM routing, and review invalidation
• 20+ production files import from base/registry.py across engine (_plan/, _scoring/, _work_queue/, concerns.py), CLI (cli.py, scan/reporting/), narrative (intelligence/narrative/), and base (output/issues.py) layers
• All fields verified at snapshot commit 6eb2065

Fix

No fix needed — verdict is YES_WITH_CAVEATS. The coupling is real but the registry pattern is a deliberate, pragmatic design choice. The module is data-only (frozen dataclass + ~6 getter functions) — not a behavior-rich god object.

Verdict

Question	Answer	Reasoning
Is this poor engineering?	YES (mild)	DetectorMeta does pack 12 fields spanning 6 behavioral axes into one type, creating a wide coupling surface
Is this at least somewhat significant?	YES	20+ production files depend on this single registry, so the coupling is real and broadly felt

Final verdict: YES_WITH_CAVEATS

Scores

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

Summary

The registry IS a wide coupling point — DetectorMeta has 12 fields spanning display, scoring, planning, queue thresholds, and review staleness, imported by 20+ production files across all layers. However, calling it a "god object" overstates the issue: registry.py is a data-only metadata table (frozen dataclass + dict) with ~6 small getter functions, not a behavior-rich class. This is a deliberate registry pattern where centralization prevents config drift. The alternative (scattering config across modules) would create worse maintenance problems.

Why Desloppify Missed This

• What should catch: A "responsibility cohesion" or "coupling" detector analyzing how many distinct behavioral axes a single type spans
• Why not caught: The existing responsibility_cohesion detector focuses on module-level responsibilities (too many functions), not dataclass field cohesion across behavioral concerns
• What could catch: A "data class cohesion" sub-detector that flags types whose fields are consumed by disjoint sets of modules (high afferent coupling with low field co-usage)

Verdict Files

• Verdict JSON
• Verdict Report

Generated with Lota