Remove algorithmic_dos metric due to compounding heuristic failures
Description
The algorithmic_dos measurement in gitgalaxy/metrics/signal_processor.py needs to be completely removed. An investigation into the ML Threat Intelligence engine's massive false positives (like flagging static UI files as O(N^6) threats) reveals that this metric is fundamentally flawed and structurally unsound.
Why it is broken
The calculation for algorithmic_dos is mathematically built on top of two underlying heuristics that we have already proven to be entirely hallucinated:
big_o_depth (Whitespace Indentation): The engine uses depth**2 as the baseline func_threat. Because big_o_depth derives its value purely by counting whitespace indentation, any deeply nested but completely safe code (like standard server listeners or nested JSON configuration files) instantly generates an exponential Algorithmic DoS threat base score.db_complexity (Regex String Matching): The base threat is then compounded by a multiplier derived from db_complexity. Because this metric naively counts regex occurrences of words like select and join regardless of semantic context, standard string manipulation combined with deep indentation triggers catastrophic false positives.
Conclusion: The algorithmic_dos metric does not measure actual Denial of Service vulnerability; it simply measures whitespace indentation depth multiplied by arbitrary string matches. This causes standard framework files (like Django's runserver.py) and purely static frontend components to be falsely flagged with 100% Algorithmic DoS risk.
Action Items
Remove
algorithmic_dosmetric due to compounding heuristic failuresDescription
The
algorithmic_dosmeasurement ingitgalaxy/metrics/signal_processor.pyneeds to be completely removed. An investigation into the ML Threat Intelligence engine's massive false positives (like flagging static UI files asO(N^6)threats) reveals that this metric is fundamentally flawed and structurally unsound.Why it is broken
The calculation for
algorithmic_dosis mathematically built on top of two underlying heuristics that we have already proven to be entirely hallucinated:big_o_depth(Whitespace Indentation): The engine usesdepth**2as the baselinefunc_threat. Becausebig_o_depthderives its value purely by counting whitespace indentation, any deeply nested but completely safe code (like standard server listeners or nested JSON configuration files) instantly generates an exponential Algorithmic DoS threat base score.db_complexity(Regex String Matching): The base threat is then compounded by a multiplier derived fromdb_complexity. Because this metric naively counts regex occurrences of words likeselectandjoinregardless of semantic context, standard string manipulation combined with deep indentation triggers catastrophic false positives.Conclusion: The
algorithmic_dosmetric does not measure actual Denial of Service vulnerability; it simply measures whitespace indentation depth multiplied by arbitrary string matches. This causes standard framework files (like Django'srunserver.py) and purely static frontend components to be falsely flagged with 100% Algorithmic DoS risk.Action Items
_calc_algorithmic_dosfromgitgalaxy/metrics/signal_processor.py.algorithmic_dosfromRISK_SCHEMAand all upstream/downstream aggregators.