feat: verify S207 @Boehner bounty — NO verdict, duplicate of S036 (#529)

[xliry]

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

Problem (in our own words)

S207 claims _compute_batch_quality in batch/core.py computes dimension_coverage as len(assessments) / max(len(assessments), 1), which is a self-division tautology that always yields 1.0 for non-empty dicts. The metric is supposed to measure what fraction of expected dimensions were assessed, but since expected_dimension_count is never passed to the function, it divides by itself. This renders the entire dimension coverage telemetry pipeline meaningless.

Evidence

• desloppify/app/commands/review/batch/core.py:373-375 — tautological formula len(assessments) / max(len(assessments), 1) confirmed at snapshot commit 6eb2065
• desloppify/app/commands/review/batch/core.py:365-370 — function signature lacks any expected_dimension_count parameter
• desloppify/app/commands/review/batch/core.py:617 — _accumulate_batch_quality collects the always-1.0 values
• desloppify/app/commands/review/batch/merge.py:199-201 — averages the always-1.0 values into final output
• S036 by @Midwest-AI-Solutions (comment 4001669966, 2026-03-05) — identical finding submitted 24 hours earlier

Fix

No fix needed — verdict is NO (duplicate of S036).

Verdict

Question	Answer	Reasoning
Is this poor engineering?	YES	The tautological formula makes dimension_coverage permanently meaningless across the entire quality pipeline
Is this at least somewhat significant?	YES	An entire quality axis (dimension coverage) is unobservable due to self-division

Final verdict: NO — the bug is real but S207 is a duplicate of S036 (@Midwest-AI-Solutions), which was submitted ~24 hours earlier with the same finding and more detailed downstream analysis.

Scores

Criterion	Score
Significance	7/10
Originality	0/10
Core Impact	6/10
Overall	0/10

Summary

The technical claim is fully confirmed — dimension_coverage is computed as N/N and is always 1.0, making the metric permanently uninformative. However, S036 by @Midwest-AI-Solutions reported the exact same bug in the same function a day earlier with even more thorough downstream tracing. S207 is a duplicate and receives a NO verdict.

Why Desloppify Missed This

• What should catch: A mathematical reasoning or tautology detector that flags expressions where numerator and denominator derive from the same variable
• Why not caught: Static analysis typically doesn't evaluate whether a ratio can vary — it only checks for division by zero, not division by self
• What could catch: A semantic lint rule checking that ratio metrics have distinct numerator/denominator sources, or a property-based test that verifies dimension_coverage varies with input

Verdict Files

• Verdict JSON
• Verdict Report

Generated with Lota